@possumtech/rummy 2.2.0 → 2.3.1

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

@@ -1,565 +0,0 @@
-# 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
-```
-