Alessio Quaglino
ea230a950c
This CL replaces the post-hoc implicit flex correction (`flexInterp_cgsolve`) with a **linearly-implicit effective metric** `M̃ = M + (h² + h·damping)·K` carried by the CG constraint solver itself. Contact/friction forces and implicit flex elasticity are now computed against one consistent metric, instead of the solver seeing `M` and a post-solve correction changing `qacc` behind its back. Gate (unchanged semantics): `solver="CG"` + implicit/implicitfast integrator + pyramidal cones + flex stiffness present. Newton and PGS are untouched. `solver="CG"` remains the user-facing contract — the factorization is an implementation detail of the preconditioner. ### What's in the metric - **mjData `efm_*`** (arena, efc-like lifetime/skip semantics; built in `mj_fwdPosition`, value-refreshed in `mj_fwdVelocity`): the per-step stiffness CSR `efm_B_*`, its reverse-Cholesky factor `efm_dofid` + `efm_L_*` (nested-dissection ordered, separators-first for the reverse factorization), and the smooth-force shift `efm_c = h·K·qvel`. - **`mjd_flexStiff_assemble`** now assembles stretch (Gauss–Newton), standard dim-2 bending, and — via the cached corotated stiffness `d->flexelem_krot` — interp stiffness (all node bodies on simple sliders: point Jacobian is I₃, `flex_centered` not required; fixed nodes drop like pins) into one dof-level CSR. `mjd_effMulAdd`/`mjd_effSolve` apply the metric, with matrix-free operator fallbacks where assembly does not apply. - **mjModel `efm0_*`** (`nefm0dof`/`nefm0L`): the constant part of the metric factor — currently the dim-2 bending factor, computed once in `mj_setConst` — so bending-only models pay zero per-step factorization cost. Naming mirrors mjData's `efm_*` with the standard `0`-suffix (reference/constant) idiom, and is deliberately not bending-specific: future constant contributors extend it without renames. - The solver consumes the metric through pre-shifted `qfrc_smooth` and the metric products `Ma`/`Mv`/`Mgrad`; `qacc_smooth` becomes the unconstrained minimizer of the implicit dynamics, which makes the no-constraint shortcut and the warmstart choice consistent by construction. - **`mj_inverse` adds `B·qacc − c`**, making inverse dynamics discrete-consistent with the gated forward dynamics — exact, since the gated path has no qDeriv term (new test `ForwardTest.GatedFlexInverseConsistency`). ### Performance All numbers: ms/step over the same 2000-step window, models as shipped on each side (old code with the old model settings vs this CL with the new ones). The new solver path activates on exactly two shipped models — the ponchos, the only flex models that need an implicit integrator (poncho on Euler degenerates to >200 ms/step). For them, this CL trades speed for consistency: the implicit bending solve now runs inside every solver iteration, where the contact solve can see the stiffness, instead of once after the solve. Solver iterations drop because the curvature is visible, but each iteration pays for the implicit solve: | model | before | after | solver iters/step | |---|---|---|---| | poncho | 2.47 | 3.30 (1.33×) | 16.8 → 11.8 | | poncho_edgeequality | 1.96 | 2.72 (1.39×) | 13.2 → 10.0 | What that price buys: contact forces consistent with the implicit elasticity (previously the post-hoc correction changed `qacc` after the constraint solve), discrete-consistent inverse dynamics, and the removal of the post-hoc special case from the integration path. Raising poncho's timestep from 2 to 5 ms leaves its per-step cost nearly flat, so the consistency price can be recovered by taking fewer steps where accuracy allows. Every other flex model was measured stable on Euler at its shipped timestep and switches to it (these models predate the post-hoc integrator; implicit was never load-bearing for them). They end up equal or faster than before: bunny_multicell 0.47 → 0.40, trampoline 0.28 → 0.25, plate 1.02 → 0.99, pancake 0.34 → 0.33. Finally, the per-step factorization makes configurations practical that the old code could only integrate explicitly: implicit stretch elasticity (`elastic2d="stretch"`/`"both"`, dim-3 solids) and factorized interp stiffness. No before/after exists for these — stock has no implicit treatment of stretch at all. ### Behavior changes - With the post-hoc correction deleted, interp/bending models running `solver="Newton"` (or elliptic cones, or islands) now integrate flex elasticity **explicitly** (previously: post-hoc implicit). Affects e.g. `gripper_trilinear` (stable, and faster, but different semantics). Follow-up options: Newton-side metric support, or a documented fallback. - With the gate on, `mj_forward` outputs are timestep-dependent for gated models (they answer the linearly-implicit discrete problem); `qacc_smooth` and `mj_inverse` change accordingly. Non-gated models are bit-identical (full suite green throughout). ### Validation - 1737/1737 tests, including new: `FlexStretchDerivatives` (FD-validated GN operator), `FlexStiffAssemble`/`FlexStiffAssembleInterp` (CSR ≡ operators), `GatedFlexInverseConsistency` (fails pre-change), equivalence tests vs the old post-hoc treatment (bending matches to 2e-11). - Fingerprint discipline throughout: bending-only models bit-exact across every refactor; permutation/kernel changes verified iteration-identical. ### Known follow-ups (not in this CL) 3×3-block sparse Cholesky kernel (the numeric factorization is index-bound; projected ~3× on the factor); mjModel persistence of the factor's symbolic pattern (rest-pose ND makes sizes compile-time); the general effective-metric mode (all solvers, all PSD-safe force classes, behind an enable flag). PiperOrigin-RevId: 948561856 Change-Id: I8b8e32ebd0428042af71647d0470d10773bf6daf
MuJoCo stands for Multi-Joint dynamics with Contact. It is a general purpose physics engine that aims to facilitate research and development in robotics, biomechanics, graphics and animation, machine learning, and other areas which demand fast and accurate simulation of articulated structures interacting with their environment.
This repository is maintained by Google DeepMind.
MuJoCo has a C API and is intended for researchers and developers. The runtime simulation module is tuned to maximize performance and operates on low-level data structures that are preallocated by the built-in XML compiler. The library includes interactive visualization with a native GUI, rendered in OpenGL. MuJoCo further exposes a large number of utility functions for computing physics-related quantities.
We also provide Python bindings and a plug-in for the Unity game engine.
Documentation
MuJoCo's documentation can be found at mujoco.readthedocs.io. Upcoming features due for the next release can be found in the changelog in the "latest" branch.
Getting Started
There are two easy ways to get started with MuJoCo:
-
Run
simulateon your machine. This video shows a screen capture ofsimulate, MuJoCo's native interactive viewer. Follow the steps described in the Getting Started section of the documentation to getsimulaterunning on your machine. -
Explore our online IPython notebooks. If you are a Python user, you might want to start with our tutorial notebooks running on Google Colab:
- The introductory tutorial teaches MuJoCo basics:
- The Model Editing tutorial shows how to create and edit models procedurally:
- The rollout tutorial shows how to use the multithreaded
rolloutmodule: - The LQR tutorial synthesizes a linear-quadratic controller, balancing a
humanoid on one leg:
- The least-squares tutorial explains how to use the Python-based nonlinear
least-squares solver:
- The MJX tutorial provides usage examples of
MuJoCo XLA, a branch of MuJoCo written in JAX:
- The differentiable physics tutorial trains locomotion policies with
analytical gradients automatically derived from MuJoCo's physics step:
Installation
Prebuilt binaries
Versioned releases are available as precompiled binaries from the GitHub releases page, built for Linux (x86-64 and AArch64), Windows (x86-64 only), and macOS (universal). This is the recommended way to use the software.
Building from source
Users who wish to build MuJoCo from source should consult the build from
source section of the documentation. However, note that the commit at
the tip of the main branch may be unstable.
Python (>= 3.10)
The native Python bindings, which come pre-packaged with a copy of MuJoCo, can be installed from PyPI via:
pip install mujoco
Note that Pre-built Linux wheels target manylinux2014, see
here for compatible distributions. For more
information such as building the bindings from source, see the Python bindings
section of the documentation.
Versioning
We aim to release MuJoCo in the first week of each month. Our versioning standards changed to modified Semantic Versioning in 3.5.0, see versioning for details.
Contributing
We welcome community engagement: questions, requests for help, bug reports and feature requests. To read more about bug reports, feature requests and more ambitious contributions, please see our contributors guide and style guide.
Asking Questions
Questions and requests for help are welcome as a GitHub "Asking for Help" Discussion and should focus on a specific problem or question.
Bug reports and feature requests
GitHub Issues are reserved for bug reports, feature requests and other development-related subjects.
Related software
MuJoCo is the backbone for numerous environment packages. Below we list several bindings and converters.
Bindings
These packages give users of various languages access to MuJoCo functionality:
First-party bindings:
- Python bindings
- dm_control, Google DeepMind's related environment stack, includes PyMJCF, a module for procedural manipulation of MuJoCo models.
- JavaScript bindings and WebAssembly support (inspired stillonearth and zalo's community projects; mjswan extends these with real-time policy control, interactive force application, and more).
- C# bindings and Unity plug-in
Third-party bindings:
- MATLAB Simulink: Simulink Blockset for MuJoCo Simulator by Manoj Velmurugan.
- Swift: swift-mujoco
- Java: mujoco-java
- Julia: MuJoCo.jl
- Rust: MuJoCo-rs
Converters
- OpenSim: MyoConverter converts OpenSim models to MJCF.
- SDFormat: gz-mujoco is a two-way SDFormat <-> MJCF conversion tool.
- OBJ: obj2mjcf a script for converting composite OBJ files into a loadable MJCF model.
- onshape: Onshape to Robot Converts onshape CAD assemblies to MJCF.
Citation
If you use MuJoCo for published research, please cite:
@inproceedings{todorov2012mujoco,
title={MuJoCo: A physics engine for model-based control},
author={Todorov, Emanuel and Erez, Tom and Tassa, Yuval},
booktitle={2012 IEEE/RSJ International Conference on Intelligent Robots and Systems},
pages={5026--5033},
year={2012},
organization={IEEE},
doi={10.1109/IROS.2012.6386109}
}
License and Disclaimer
Copyright 2021 DeepMind Technologies Limited.
Box collision code (engine_collision_box.c)
is Copyright 2016 Svetoslav Kolev.
ReStructuredText documents, images, and videos in the doc directory are made
available under the terms of the Creative Commons Attribution 4.0 (CC BY 4.0)
license. You may obtain a copy of the License at
https://creativecommons.org/licenses/by/4.0/legalcode.
Source code is licensed under the Apache License, Version 2.0. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.
This is not an officially supported Google product.