- Added new `cable` composite type:
* The `initial` parameter specifies the joint at the starting boundary: `free`, `ball`, or `none`.
* The boundary bodies are exposed with the names:`B_left` and `B_right`.
* The vertex initial positions can be specified directly in the XML with the parameter `vertex`.
* The orientation of the body frame **is** the orientation of the material frame of the curve.
- Added new `cable` passive force plugin:
* Twist and bending stiffness can be set separately with the parameters `twist` and `bend`.
* The stress-free configuration can be set to be the initial one or flat with the flag `flat`.
* New cable example showing the formation of plectoneme.
* New coil example.
* New belt example showing interaction between twist and anisotropy.
* Added test using cantilever exact solution.
PiperOrigin-RevId: 480033694
Change-Id: I491271bce8fccb185961477e903e5a72d172c8a3
- Add private function `mj_arenaAlloc`. This is used internally to allocate memory from the arena.
- Add private function `mj_nefc` to count constraints. This function returns a tight upper bound on `d->nefc`. The number of counted constraints can be slightly bigger than exact `d->nefc` in the case of constraints with empty Jacobian, as when placing a frictional tendon between two world sites.
- Add new `memory` attribute to the `size` XML element for specification of arena memory size. This attribute is mutually exclusive with `nstack` and `njmax` specifications, which are now deprecated (but left around for the time being for legacy compatibility).
- Move `d->stack` to the end of the new arena space. The stack now grows in reverse from the end.
PiperOrigin-RevId: 479341539
Change-Id: Ie019c202e0908577ffc6f833a37920858116f667
This is an amendment to 4bfc2c0311.
Add an autolimits compiler option. When true, *limited will be inferred from the presence of the *range attributes.
When false, models where limited is not specified, and range is will fail to compile.
PiperOrigin-RevId: 472438650
Change-Id: I489098e879ee695030f44e0d8cd969787e75fb90
This is a very subtle leak caused interaction between longjmp and compiler optimisation. Specifically, at the point where the setjmp takes places, these pointers have never been reassigned from its nullptr initialization. Without the volatile keyword, the compiler is free to assume that these pointers remain nullptr when the setjmp returns, and therefore to pass nullptr directly to the mj_deleteModel and mj_deleteData calls in the subsequent catch block, without ever reading the actual pointer values.
PiperOrigin-RevId: 466649447
Change-Id: I51e82ec8b566deb144221e11a99d5124a8267de4
- Mesh inertias can now be computed exactly for well-formed (no holes) non-convex meshes.
- To activate this feature, set `<compiler exactmeshinertia="true">` (defaults to `false`). This default may change in the future.
- Added `<geom shellinertia="true/false">` (defaults to `false`). When true, geom inertia is computed assuming all the mass is concentrated on the surface, and `density` is interpreted as surface density (mass/area). Currently only mesh geoms are supported.
PiperOrigin-RevId: 464368395
Change-Id: I17afd99b9b221c9d24ae951f6e63d5c61ff89820
- Add basic test for keyframes.
- Add missing documentation for keyframe mocap positions and quaternions.
PiperOrigin-RevId: 459021649
Change-Id: I91cf7ecbddc6262e8c72a868eeb82d627f389fb3
Inertias of moving bodies are enforced to be greater mjMINVAL at model compilation, there is no need to enforce inertias at mesh load time. Tiny meshes could be static or part of a larger geom assembly, in which case their tiny inertia is not a problem.
Also, make error message for small masses/inertias more precise.
PiperOrigin-RevId: 451625216
Change-Id: I4b48d7a881e620d6fbb591ec77fbdacc7c03496c
Added analytic derivatives of smooth (unconstrained) dynamics forces, with respect to velocities:
- Centripetal and Coriolis forces computed by the Recursive Newton-Euler algorithm.
- Damping and fluid-drag passive forces.
- Actuation forces.
A new implicit-in-velocity integrator is implemented using the analytic derivatives. This integrator lies between the Euler and Runge Kutta integrators in terms of both stability and computational cost.
PiperOrigin-RevId: 450377010
Change-Id: Ie192b441876c22e732fb749333926f296e0a09cc
Alessio Quaglino