@possumtech/rummy 2.1.0 → 2.2.0

package/audit/sweep/tune-mjcf/turns/turn_029.md

@@ -0,0 +1,565 @@
+# turn 029
+
+tokens: prompt=12384 cached=2139 completion=224 reasoning=0 total=12608 cost=0
+created: 2026-05-01 23:55:17
+
+update: status=155 body=promoting model_ref.xml + MuJoCo modeling docs for model analysis
+
+---
+
+## reasoning (think)
+
+```
+* We're in Distillation Stage, resolving unknown://mujoco/model_ref_content (needs real model_ref.xml content for analysis).
+* /app/model_ref.xml exists as placeholder from turn_13 (71 tokens); promote it.
+* Search turn_28 found MuJoCo modeling docs (67k tokens - too big) with examples; use line-limited get for snippets.
+* Also promote MuJoCo modeling docs for model examples/tuning guidance.
+* Distill into known://mujoco/model_ref_content after promotion.
+* Budget ok: model_ref.xml 71t, modeling docs slice cheap.
+* After distill, check if all unknowns resolved (only 2 total, other is goal).
+```
+
+## assistant emission
+
+```
+<think>
+* We're in Distillation Stage, resolving unknown://mujoco/model_ref_content (needs real model_ref.xml content for analysis).
+* /app/model_ref.xml exists as placeholder from turn_13 (71 tokens); promote it.
+* Search turn_28 found MuJoCo modeling docs (67k tokens - too big) with examples; use line-limited get for snippets.
+* Also promote MuJoCo modeling docs for model examples/tuning guidance.
+* Distill into known://mujoco/model_ref_content after promotion.
+* Budget ok: model_ref.xml 71t, modeling docs slice cheap.
+* After distill, check if all unknowns resolved (only 2 total, other is goal).
+</think>
+
+<get path="/app/model_ref.xml"/>
+<get path="https://mujoco.readthedocs.io/en/stable/modeling.html" line="1" limit="500"/>
+<get path="https://mujoco.readthedocs.io/en/stable/modeling.html" line="-500"/>
+
+<update status="155">promoting model_ref.xml + MuJoCo modeling docs for model analysis</update>
+```
+
+## actions (chronological log entries)
+
+### `log://turn_29/get/app/model_ref.xml`
+scheme=log action=get attrs={"path":"/app/model_ref.xml","action":"get"}
+
+```
+/app/model_ref.xml not found
+```
+
+### `log://turn_29/get/https%3A/mujoco.readthedocs.io/en/stable/modeling.html`
+scheme=log action=get attrs={"path":"https://mujoco.readthedocs.io/en/stable/modeling.html","lineStart":1943,"lineEnd":2442,"totalLines":2442,"action":"get"}
+
+```
+https://mujoco.readthedocs.io/en/stable/modeling.html
+[lines 1943–2442 / 2442 total]
+[compiler](https://mujoco.readthedocs.io/en/stable/XMLreference.html#compiler)
+for example, can be defined multiple times. MuJoCo allows this, and uses the
+last definition encountered in the composite model, after all include elements
+have been processed. So if model A is defined in degrees and model B is defined
+in radians, and A is included in B after the compiler element in B, the entire
+composite model will be treated as if it was defined in degrees – leading to
+undesirable consequences in this case. The user has to make sure that models
+included in each other are compatible in this sense; local vs. global
+coordinates is another compatibility requirement.
+
+Finally, as explained next, element names must be unique among all elements of
+the same type. So for example if the same geom name is used in two models, and
+one model is included in the other, this will result in compile error. Including
+the same XML file more than once is a parsing error. The reason for this
+restriction is that we want to avoid repeated element names as well as infinite
+recursion caused by inclusion.
+
+### Naming elements[#](#naming-elements "Link to this heading")
+
+Most model elements in MJCF can have names. They are defined with the attribute
+name of the corresponding XML element. When a given model element is named, its
+name must be unique among all elements of the same type. Names are
+case-sensitive. They are used at compile time to reference the corresponding
+element, and are also saved in mjModel for user convenience at runtime.
+
+The name is usually an optional attribute. We recommend leaving it undefined (so
+as to keep the model file shorter) unless there is a specific reason to define
+it. There can be several such reasons:
+
+*   Some model elements need to reference other elements as part of their creation.
+    For example, a spatial tendon needs to reference sites in order to specify the
+    via points it passes through. Referencing can only be done by name. Note that
+    assets exist for the sole purpose of being referenced, so they must have a name,
+    however it can be omitted and set implicitly from the corresponding file name.
+    
+*   The visualizer offers the option to label all model elements of a given type.
+    When a name is available, it is printed next to the object in the 3D view;
+    otherwise a generic label in the format “body 7” is printed.
+    
+*   The function
+    [mj\_name2id](https://mujoco.readthedocs.io/en/stable/APIreference/APIfunctions.html#mj-name2id)
+    returns the index of the model element with given type and name. Conversely, the
+    function
+    [mj\_id2name](https://mujoco.readthedocs.io/en/stable/APIreference/APIfunctions.html#mj-id2name)
+    returns the name given the index. This is useful for custom computations
+    involving a model element that is identified by its name in the XML (as opposed
+    to relying on a fixed index which can change when the model is edited).
+    
+*   The model file could in principle become more readable by naming certain
+    elements. Keep in mind however that XML itself has a commenting mechanism, and
+    that mechanism is more suitable for achieving readability – especially since
+    most text editors provide syntax highlighting which detects XML comments.
+    
+
+### URDF extensions[#](#urdf-extensions "Link to this heading")
+
+The Unified Robot Description Format (URDF) is a popular XML file format in
+which many existing robots have been modeled. This is why we have implemented
+support for URDF even though it can only represent a subset of the model
+elements available in MuJoCo. In addition to standard URDF files, MuJoCo can
+load files that have a custom (from the viewpoint of URDF) mujoco element as a
+child of the top-level element robot. This custom element can have sub-elements
+[compiler](https://mujoco.readthedocs.io/en/stable/XMLreference.html#compiler) ,
+[option](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option) ,
+[size](https://mujoco.readthedocs.io/en/stable/XMLreference.html#size) with the
+same functionality as in MJCF, except that the default compiler settings are
+modified so as to accommodate the URDF modeling convention. The
+[compiler](https://mujoco.readthedocs.io/en/stable/XMLreference.html#compiler)
+extension in particular has proven very useful, and indeed several of its
+attributes were introduced because a number of existing URDF models have
+non-physical dynamics parameters which MuJoCo’s built-in compiler will reject if
+left unmodified. This extension is also needed to specify mesh directories. Also
+note that the compiler attributes
+[strippath](https://mujoco.readthedocs.io/en/stable/XMLreference.html#compiler-strippath)
+,
+[angle](https://mujoco.readthedocs.io/en/stable/XMLreference.html#compiler-angle)
+,
+[fusestatic](https://mujoco.readthedocs.io/en/stable/XMLreference.html#compiler-fusestatic)
+and
+[discardvisual](https://mujoco.readthedocs.io/en/stable/XMLreference.html#compiler-discardvisual)
+have different default values for URDF and MJCF.
+
+Note that the while MJCF models are checked against a custom XML schema by the
+parser, URDF models are not. Even the MuJoCo-specific elements embedded in the
+URDF file are not checked. As a result, mis-typed attribute names are silently
+ignored, which can result in major confusion if the typo remains unnoticed.
+
+Here is an example extension section of a URDF model:
+
+<robot name="darwin"\>
+  <mujoco>
+    <compiler meshdir="../mesh/darwin/" balanceinertia="true" discardvisual="false"/>
+  </mujoco>
+  <link name="MP\_BODY"\>
+    ...
+</robot>
+
+The above extensions make URDF more usable but still limited. If the user wants
+to build models taking full advantage of MuJoCo and at the same time maintain
+URDF compatibility, we recommend the following procedure. Introduce extensions
+in the URDF as needed, load it and save it as MJCF. Then add information to the
+MJCF using
+[include](https://mujoco.readthedocs.io/en/stable/XMLreference.html#include)
+elements whenever possible. In this way, if the URDF is modified, the
+corresponding MJCF can be easily re-created. In our experience though, URDF
+files tend to be static while MJCF files are often edited. Thus in practice it
+is usually sufficient to convert the URDF to MJCF once and after that only work
+with the MJCF.
+
+### MoCap bodies[#](#mocap-bodies "Link to this heading")
+
+`mocap` bodies are static children of the world (i.e., have no joints) and their
+mocap attribute is set to “true”. They can be used to input a data stream from a
+motion capture device into a MuJoCo simulation. Suppose you are holding a VR
+controller, or an object instrumented with motion capture markers (e.g. Vicon),
+and want to have a simulated object moving in the same way but also interacting
+with other simulated objects. There is a dilemma here: virtual objects cannot
+push on your physical hand, so your hand (and thereby the object you are
+controlling) can violate the simulated physics. But at the same time we want the
+resulting simulation to be reasonable. How do we do this?
+
+The first step is to define a mocap body in the MJCF model, and implement code
+that reads the data stream at runtime and sets
+[mjData.mocap\_pos](https://mujoco.readthedocs.io/en/stable/programming/simulation.html#simocap)
+and
+[mjData.mocap\_quat](https://mujoco.readthedocs.io/en/stable/programming/simulation.html#simocap)
+to the position and orientation received from the motion capture system. The
+[simulate.cc](https://mujoco.readthedocs.io/en/stable/programming/samples.html#sasimulate)
+code sample uses the mouse as a motion capture device, allowing the user to move
+mocap bodies around:
+
+[![particle](https://mujoco.readthedocs.io/en/stable/_images/particle.gif)
+](https://mujoco.readthedocs.io/en/stable/_images/particle.gif)
+
+The key thing to understand about mocap bodies is that the simulator treats them
+as being fixed. We are causing them to move from one simulation time step to the
+next by updating their position and orientation directly, but as far as the
+physics model is concerned their position and orientation are constant. So what
+happens if we make contact with a regular dynamic body, as in the particle
+examples provided with the MuJoCo distribution (recall that in those example we
+have a capsule probe which is a mocap body that we move with the mouse). A
+contact between two regular bodies will experience penetration as well as
+relative velocity, while contact with a mocap body is missing the relative
+velocity component because the simulator does not know that the mocap body
+itself is moving. So the resulting contact force is smaller and it takes longer
+for the contact to push the dynamic object away. Also, in more complex
+simulations the fact that we are doing something inconsistent with the physics
+can cause instabilities.
+
+There is however a better-behaved alternative. In addition to the mocap body, we
+include a second regular body and connect it to the mocap body with a weld
+equality constraint. In the plots below, the pink box is the mocap body and it
+is connected to the base of the hand. In the absence of other constraints, the
+hand tracks the mocap body almost perfectly (and much better than a
+spring-damper would) because the constraints are handled implicitly and can
+produce large forces without destabilizing the simulation. But if the hand is
+forced to make contact with the table for example (right plot) it cannot
+simultaneously respect the contact constraint and track the mocap body. This is
+because the mocap body is free to go through the table. So which constraint
+wins? That depends on the softness of the weld constraint relative to the
+contact constraint. The corresponding solref and solimp parameters need to be
+adjusted so as to achieve the desired trade-off. See the Modular Prosthetic Limb
+(MPL) hand model available on the MuJoCo Forum for an example; the plots below
+are generated with that model.
+
+[![image18](https://mujoco.readthedocs.io/en/stable/_images/mocap1.png)
+](https://mujoco.readthedocs.io/en/stable/_images/mocap1.png)
+[![image19](https://mujoco.readthedocs.io/en/stable/_images/mocap2.png)
+](https://mujoco.readthedocs.io/en/stable/_images/mocap2.png)
+
+### Memory allocation[#](#memory-allocation "Link to this heading")
+
+MuJoCo preallocates all the memory needed at runtime in
+[mjData](https://mujoco.readthedocs.io/en/stable/APIreference/APItypes.html#mjdata)
+, and does not access the heap allocator after model creation. Memory in
+[mjData](https://mujoco.readthedocs.io/en/stable/APIreference/APItypes.html#mjdata)
+is allocated by
+[mj\_makeData](https://mujoco.readthedocs.io/en/stable/APIreference/APIfunctions.html#mj-makedata)
+in two contiguous blocks:
+
+*   `mjData.buffer` contains fixed-size arrays.
+    
+*   `mjData.arena` contains dynamically-sized arrays.
+    
+
+There are two types of dynamic arrays allocated in the `arena` memory space.
+
+*   contacts and constraint-related arrays are laid out from the beginning of the
+    `arena` .
+    
+*   [stack](https://mujoco.readthedocs.io/en/stable/programming/simulation.html#sistack)
+    arrays are laid out from the end of the `arena` .
+    
+
+By allocating dynamic quantities from both sides of the `arena` space,
+variable-sized memory allocation is controlled by a single number: the memory
+attribute of the
+[size](https://mujoco.readthedocs.io/en/stable/XMLreference.html#size) MJCF
+element. Unlike the fixed-size arrays in the `buffer` , variable-sized arrays in
+the arena can be `NULL` , for example after a call to
+[mj\_resetData](https://mujoco.readthedocs.io/en/stable/APIreference/APIfunctions.html#mj-resetdata)
+. When `arena` memory runs out, one of three things will happen, depending on
+the type of memory requested:
+
+*   If memory runs out during contact allocation, a warning will be raised and
+    subsequent contacts will not be added in this step, but simulation continues as
+    usual.
+    
+*   If memory runs out during constraint-related allocation, a warning will be
+    raised and the constraint solver will be disabled in this step, but simulation
+    continues as usual. Note that physics without the constraint solver will
+    generally be very different, but allowing the simulation to continue can still
+    be useful, e.g. during scene initialization when many bodies are temporarily
+    overlapping.
+    
+*   If memory runs out during stack array allocation, a hard error will occur.
+    
+
+Unlike the size of the `buffer` , the size of the `arena` cannot be
+pre-computed, since the number of contacts and stack usage is not known in
+advance. So how should one choose it? The following simple heuristic is
+currently used, though it may be improved in the future: enough memory is
+allocated for 100 contacts and 500 scalar constraints, under worst-case
+conditions. If this heuristic is insufficient, we recommend the following
+procedure. Increase the `arena` memory significantly using the memory attribute,
+and inspect the actual memory used at runtime. `mjData.maxuse_arena` keeps track
+of the maximum `arena` memory utilization since the last reset. The
+[simulate](https://mujoco.readthedocs.io/en/stable/programming/samples.html#sasimulate)
+viewer shows this number as a fraction of the total arena space (in the info
+window in the lower-left corner). So one can start with a large number, simulate
+for a while, and if the fractions are small go back to the XML and reduce the
+allocation size. Keep in mind though that memory utilization can change
+dramatically in the course of the simulation, depending on how many constraints
+are active and which constraint solver is used. The CG solver is the most memory
+efficient, followed by the Newton solver, while the PGS solver is the most
+memory intensive. When we design models, we usually aim for 50% utilization in
+the worst-case scenario encountered while exploring the model. If you only
+intend to use the CG solver, you can get away with significantly smaller arena
+allocation.
+
+## Tips and tricks[#](#tips-and-tricks "Link to this heading")
+
+Here we provide guidance on how to accomplish some common modeling tasks. There
+is no new material here, in the sense that everything in this section can be
+inferred from the rest of the documentation. Nevertheless the inference process
+is not always obvious, so it may be useful to have it spelled out.
+
+### Performance tuning[#](#performance-tuning "Link to this heading")
+
+Below is a list of steps one can take in order to maximize simulation
+throughput. All of the recommendations involve parameter tweaking. It is
+recommended that these be carried out in interactive fashion while looking at
+the
+[simulate](https://mujoco.readthedocs.io/en/stable/programming/samples.html#sasimulate)
+utility’s built-in profiler. A detailed and sometimes more useful profile is
+also reported by the
+[testspeed](https://mujoco.readthedocs.io/en/stable/programming/samples.html#satestspeed)
+utility. When embarking on the more elaborate steps below, target the most
+expensive pipeline component reported by the profiler. Note that some of these
+are subtly different for MJX, see dedicated section
+[therein](https://mujoco.readthedocs.io/en/stable/mjx.html#mjxperformance) .
+
+1.  [Timestep](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-timestep)
+    : Try to increase the simulation timestep. As explained at the end of the
+    [Numerical Integration](https://mujoco.readthedocs.io/en/stable/computation/index.html#geintegration)
+    section, the timestep is the single most important parameter in any model. The
+    default value is chosen for stability rather than efficiency, and can often be
+    increased. At some point, increasing it further will cause divergence, so the
+    optimal timestep is the largest timestep at which divergence never happens or is
+    very rare. The actual value is model-dependent.
+    
+2.  [Integrator](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-integrator)
+    : Choose your integrator according to the recommendations at the end of the
+    [Numerical Integration](https://mujoco.readthedocs.io/en/stable/computation/index.html#geintegration)
+    section. The default recommended choice is the `implicitfast` integrator.
+    
+3.  [Constraint Jacobians](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-jacobian)
+    : Try switching the Jacobian setting between “dense” and “sparse”. These two
+    options use separate code paths using dense or sparse algebra, but are otherwise
+    computationally identical, so the faster one is always preferred. The default
+    “auto” heuristic does not always make the right choice.
+    
+4.  **Constraint solver:** If the profiler reports that a large chunk of time is
+    spent in the solver, consider the following:
+    
+    *   [solver](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-solver)
+        : The default Newton is often the fastest solver, as it requires the smallest
+        number of iterations to converge. For large models the CG solver might be
+        faster, for models with more degrees of freedom than constraints, the PGS solver
+        will be fastest, though this situation is not common.
+        
+    *   [iterations](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-iterations)
+        and
+        [tolerance](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-tolerance)
+        : Try reducing the number of iterations or, equivalently, increasing the
+        solver’s termination tolerance. In particular for the Newton solver, which
+        typically achieves numerical convergence in 2-3 (expensive) iterations, the last
+        iteration increases the precision to a level that has no noticeable effect, and
+        can be skipped.
+        
+5.  **Collisions:** If the profiler reports that collision detection takes up a
+    large chunk of the computation time, consider the following steps:
+    
+    *   Reduce the number of checked collisions using the
+        [contype](https://mujoco.readthedocs.io/en/stable/XMLreference.html#body-geom-contype)
+        /
+        [conaffinity](https://mujoco.readthedocs.io/en/stable/XMLreference.html#body-geom-conaffinity)
+        mechanism described in the
+        [Collision detection](https://mujoco.readthedocs.io/en/stable/computation/index.html#collision)
+        section.
+        
+    *   Modify collision geometries, replacing expensive collision tests (e.g.
+        mesh-mesh) with cheaper primitive-primitive collisions. As a rule of thumb,
+        collisions which have custom pair functions in the collision table at the top of
+        [engine\_collision\_driver.c](https://github.com/google-deepmind/mujoco/blob/main/src/engine/engine_collision_driver.c)
+        are significantly cheaper than those that use the generic convex-convex collider
+        `mjc_Convex` . The most expensive collisions are those involving SDF geometries.
+        
+    *   If replacing collision meshes with primitives is not feasible, decimate the
+        meshes as much as possible. Open source tools like trimesh, Blender, MeshLab and
+        CoACD are very useful in this regard.
+        
+6.  [Friction cones](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-cone)
+    : Elliptic cones are more accurate and better at preventing slip with high
+    [impratio](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-impratio)
+    , but are more expensive. If accurate friction is not important, try switching
+    to pyramidal cones.
+    
+7.  For custom builds, MuJoCo can be compiled with 32-bit floating point precision
+    (rather than the default 64-bit). For large models where memory bandwidth is the
+    bottleneck, this can improve performance. See
+    [mjtNum](https://mujoco.readthedocs.io/en/stable/APIreference/APItypes.html#mjtnum)
+    for more information. Note that float32 rarely yields measurable speedups in
+    typical models.
+    
+
+### Preventing slip[#](#preventing-slip "Link to this heading")
+
+Below is a list of steps one can take in order to diagnose and solve contact
+slippage, which is especially problematic in manipulation tasks. In order to
+diagnose slippage, it is recommended to use the
+[simulate](https://mujoco.readthedocs.io/en/stable/programming/samples.html#sasimulate)
+utility’s built in visualization options to inspect contacts and contact forces.
+It is often helpful to tweak the visual size of contacts and forces (using the
+global
+[meansize](https://mujoco.readthedocs.io/en/stable/XMLreference.html#statistic-meansize)
+or the specific
+[contactwidth](https://mujoco.readthedocs.io/en/stable/XMLreference.html#visual-scale-contactwidth)
+,
+[contactheight](https://mujoco.readthedocs.io/en/stable/XMLreference.html#visual-scale-contactheight)
+and
+[forcewidth](https://mujoco.readthedocs.io/en/stable/XMLreference.html#visual-scale-forcewidth)
+attributes) and the
+[force scaling](https://mujoco.readthedocs.io/en/stable/XMLreference.html#visual-map-force)
+attribute, to better visualize and understand the contact configuration and
+resulting forces.
+
+**Slip-preventing contact forces are outside the friction cone**
+
+This implies that the physics cannot prevent slip, even in principle. This
+occurs when:
+
+1.  _The normal force is too small._ Ensure that the maximum force that can be
+    applied by the gripper multiplied by the sliding friction coefficient is
+    significantly greater than the weight of the object.
+    
+2.  _The sliding friction coefficient is too low._ Increase the sliding
+    [friction](https://mujoco.readthedocs.io/en/stable/XMLreference.html#body-geom-friction)
+    coefficient.
+    
+3.  _Torsional friction is insufficient to apply the required torques._ Increase
+    [condim](https://mujoco.readthedocs.io/en/stable/XMLreference.html#body-geom-condim)
+    to 4 or 6 and choose appropriate friction coefficients. **condim 4** enables
+    torsional friction, preventing rotation around the normal. **condim 6** also
+    enables rolling friction, preventing rotation around the tangential directions.
+    See the
+    [Contact](https://mujoco.readthedocs.io/en/stable/computation/index.html#cocontact)
+    section for details and the specific semantics of these coefficients.
+    
+
+**The geometry does not support the required forces or torques**
+
+This is a common real-world problem, solved by improved design of grippers and
+handles.
+
+1.  Improve the geometry of the contacting geoms in order to add more contact
+    points, possibly with non-flat geometry (e.g., bumps), so slippage is prevented
+    by the normal force and not only frictional components.
+    
+2.  If contacts are between flat surfaces, make sure that the flag
+    [multiccd](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-flag-multiccd)
+    is not disabled (enabled by default), as it allows the detector to find more
+    contacts than the single contact returned by the convex-convex collider.
+    
+3.  Make sure that the flag
+    [nativeccd](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-flag-nativeccd)
+    is not disabled (enabled by default), as NativeCCD is a more accurate and
+    efficient convex collision detection algorithm.
+    
+
+**High-frequency vibration**
+
+High-frequency, low-amplitude vibrations are also a real-world problem in many
+industrial settings, but unlike in simulation, in the real world they are
+audible. Such vibration is often caused by controllers with very high gains and
+sometimes by stick-slip feedback from contacts or joints, resonating with the
+eigen-modes of the mechanism. The easiest way to diagnose such vibration is to
+visualize contact forces in
+[simulate](https://mujoco.readthedocs.io/en/stable/programming/samples.html#sasimulate)
+. The solution is usually to reduce the
+[timestep](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-timestep)
+and/or add some
+[armature](https://mujoco.readthedocs.io/en/stable/XMLreference.html#body-joint-armature)
+to the relevant joints. Another reason for vibration is feedback from explicit
+damping. Use the implicit or implicitfast integrators, as documented in the
+[Numerical Integration](https://mujoco.readthedocs.io/en/stable/computation/index.html#geintegration)
+section.
+
+**Slow slippage**
+
+Unlike the above problems which lead to fast slippage, slow, gradual slippage is
+a property of MuJoCo’s contact model by design, since without it the inverse
+dynamics are not defined. This is discussed in detail in the
+[softness and slip](https://mujoco.readthedocs.io/en/stable/overview.html#soft)
+clarification. This type of slippage can be addressed in two ways.
+
+1.  Increase the
+    [impratio](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-impratio)
+    parameter. This will reduce (but not entirely prevent) slow slippage. Note that
+    high impratio values work well only with
+    [elliptic cones](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-cone)
+    .
+    
+2.  Enable the NoSlip solver by increasing
+    [noslip\_iterations](https://mujoco.readthedocs.io/en/stable/XMLreference.html#option-noslip-iterations)
+    to a positive integer. A small number (1, 2 or 3) is usually sufficient. The
+    NoSlip post-processing solver will entirely prevent slip, at the cost of making
+    inverse dynamics ill-defined and additional computational cost.
+    
+
+### Backlash[#](#backlash "Link to this heading")
+
+Backlash is present in many robotic joints. It is usually caused by small gaps
+between gears in the gearbox, but could also be caused by some sloppiness in the
+joint mechanism. The effect is that the motor can turn for a small angle before
+the joint turns, or vice versa (when external force is applied on the joint).
+Backlash can be modeled in MuJoCo as follows. Instead of having a single hinge
+joint within the body, define two hinge joints with identical position and
+orientation:
+
+<body>
+  <joint name="J1" type="hinge" pos="0 0 0" axis="0 0 1" armature="0.01"/>
+  <joint name="J2" type="hinge" pos="0 0 0" axis="0 0 1" limited="true" range="-1 1"/>
+</body>
+
+Thus the overall rotation of the body relative to its parent is J1+J2. Now
+define an actuator acting only on J1. The small joint range on J2 keeps it near
+0, yet allows it to move a bit in the direction of the force acting on it,
+producing a backlash effect. Note the armature attribute in J1. Without it the
+joint-space inertia matrix will be singular, because the two joints could
+accelerate in opposite directions without encountering any inertia. The physical
+gears responsible for the backlash actually have rotational inertia (which we
+call armature) so this is a realistic modeling approach. The numbers in this
+example should be adjusted to obtain the desired behavior. The solref and solimp
+parameters of the joint limit constraint could also be adjusted, to make the
+backlash rotation end at a softer or a harder limit.
+
+Instead of specifying joint limits in J2, one can specify a soft equality
+constraint keeping J2=0. The constraint impedance function should then be
+adjusted so the constraint is weak near J2=0 and gets stronger away from 0. The
+new parameterization of impedance functions shown in
+[Solver parameters](#csolver) enables this. Compared to joint limits, the
+equality constraint approach will generate a softer transition between the
+backlash regime and the limit regime. It will also be active all the time, which
+is convenient in user code that needs the constraint violation or constraint
+force as input.
+
+### Restitution[#](#restitution "Link to this heading")
+
+Another mechanism exists for specifying solref, as explained in
+[Solver parameters](#csolver) . When both numbers are non-positive, they are
+interpreted as (-stiffness, -damping) and scaled by the constraint impedance. To
+achieve perfect restitution for contacts and other constraints, set stiffness to
+some reasonably large value and damping to zero. Below is an example of a sphere
+bouncing on a plane with restitution coefficient of 1, so that the energy before
+and after contact is approximately preserved. It is not exactly preserved
+because the contact itself is soft and takes several time steps, and the
+(implicit) deformations during those time steps are not exactly
+energy-preserving. But the overall effect is that the ball bounces for a very
+long time without changing its peak height in a visible way, and the energy
+fluctuates around the initial value instead of drifting.
+
+<worldbody>
+  <geom type="plane" size="1 1 .1"/>
+
+  <body pos="0 0 1"\>
+    <freejoint/>
+    <geom type="sphere" size="0.1" solref="-1000 0"/>
+  </body>
+</worldbody>
+```
+
+### `log://turn_29/update/promoting_model_ref.xml_%2B_MuJoCo_modeling_docs_for_model_analysis`
+scheme=log action=update attrs={"status":155,"action":"update"}
+
+```
+promoting model_ref.xml + MuJoCo modeling docs for model analysis
+```
+