MuJoCo Physics Engine for Robot Learning Research

MuJoCo became the leading physics engine for robot learning research because its contact model, numerical stability, and speed-accuracy trade-off meet the needs of policy training and control. Those choices also explain its limits. Researchers who understand them can tune simulations more deliberately, distinguish useful approximations from misleading artifacts, and decide when MuJoCo belongs in training, validation, or both.

What MuJoCo is and where it came from

MuJoCo stands for Multi-Joint dynamics with Contact and was designed for scientific work in robotics, biomechanics, and model-based control. Created in the Movement Control Laboratory at the University of Washington, it was described in a 2012 paper by Emanuel Todorov, Tom Erez, and Yuval Tassa and commercialized under Roboti LLC. Google DeepMind acquired it in October 2021 and open-sourced it under the Apache 2.0 license in May 2022, making it freely accessible to the wider research community. Its scientific purpose preceded that broader access.

That purpose is reflected in the software’s structure. MuJoCo is written in C/C++, with Python and JavaScript/TypeScript (WASM) bindings, while declarative XML files separate robot descriptions from simulation code. The separation lets a model describe the physical system without embedding that description in the program running it. MuJoCo was therefore not an engine adapted from gaming or cinema, but a tool built around articulated systems interacting with their environments.

Why simulators built for other purposes fall short of research needs

Gaming and cinema simulators often prioritize visual stability over physical accuracy. That is reasonable for their intended use. Rendering throughput and collisions that look plausible can matter more than physically consistent contact forces when the goal is an image that looks real. Preventing visible interpenetration may satisfy that objective without reproducing the forces a robot controller must handle.

Robot learning places a different demand on simulation because a policy learns from the dynamics it encounters. If a contact model exposes an artifact, the policy can learn to exploit it at the expense of learning behavior that works on hardware. Sim-to-real transfer is the downstream test, and contact quality is central to whether the gap can be bridged. For research, the relevant compromise is not simply accuracy against speed, but which approximations preserve the dynamics needed for training and control.

The core technical choices that set MuJoCo apart

MuJoCo answers that problem through three linked choices, namely soft-constraint contact, generalized-coordinate rigid-body dynamics, and an implementation calibrated for rapid research iteration. The contact model allows some penetration instead of requiring strict geometric non-penetration. It penalizes penetration through a normal force related to penetration depth and damping rate. Researchers control the response through time-constant and damping-ratio parameters in solref and impedance parameters in solimp.

Friction follows an ellipsoidal dry-friction law, with complementarity enforced in a soft sense. This produces a convex contact formulation that avoids the numerical fragility associated with strict hard-contact discontinuities. The deliberate compromise trades a small loss of exactness for smoother, differentiable trajectories suited to gradient-based reinforcement learning and model-predictive control. For a researcher tuning a policy, this means contact transitions are less likely to undermine the numerical calculations on which optimization depends.

Generalized coordinates address the cost of articulated-body dynamics. MuJoCo formulates motion in joint space, computing the mass and inertia matrix, Coriolis effects, gravity, contact Jacobian, and actuator torques in a consistent coordinate frame. That makes whole-body dynamics tractable at real-time rates. Semi-implicit Euler integration at a fixed timestep, typically in the millisecond range, supports simulation steps at roughly 1 kHz. At that rate, the engine can run online model-predictive control schemes such as single-shooting iLQR as well as collect training samples.

The runtime data model supports that same emphasis on iteration. The C engine separates mjModel, the compiled robot and world description, from mjData, the instantaneous simulation state, minimizing memory overhead per step. Thin bindings connect this runtime to Python reinforcement learning libraries. Sensor outputs, including joint positions and velocities, IMU, force-torque, and camera signals, are exposed through mjData at every step. A training loop can read those signals without a separate middleware layer.

How MuJoCo's XML model format and Gym interface lowered the barrier to entry

MuJoCo’s XML format makes its physical parameters accessible without requiring changes to the engine. Bodies, joints, geometries, actuators, tendons, and contact parameters are declared in a single file, then compiled into a model reusable across training runs. Tuning does not require editing C code. Named attributes expose inertia, mass, friction coefficients, actuator gains, solver stiffness, and damping, allowing researchers to sweep the parameters that shape behavior.

Early integration with the OpenAI Gym API reduced another source of friction, which was connecting simulation to learning algorithms. Wrapping environments in the Gymnasium Robotics API, with step/reset/observe semantics, made them compatible with reinforcement learning libraries standardized on that interface. Researchers could concentrate on algorithms with less attention to simulator internals. This accessibility helped turn useful physics into shared infrastructure, as reusable environments accumulated into a benchmark ecosystem.

The benchmark ecosystem that locked in MuJoCo as the standard

HumanoidBench shows how that ecosystem tests more than basic locomotion. Presented at RSS 2024 and used widely through 2026, it evaluates whole-body locomotion and manipulation using the Unitree H1 robot with Shadow Hands. Its 27 tasks include walking, running, shelf rearrangement, and package unloading. The demands extend across sensing and actuation. Proprioception, egocentric vision, and dense tactile feedback accompany an action space spanning dozens of actuators, putting pressure on the contact and actuation model across complex whole-body behavior.

An algorithm’s result is produced under a particular set of dynamics. Changing those dynamics changes the comparison. Once earlier results use MuJoCo, researchers have a reason to use it for new work beyond what the engine itself can do.

Other projects show the breadth of that dependence. DexJoCo, MuBlE (MuJoCo + Blender), and HumanoidArena, published or posted in 2025–2026, use MuJoCo as a substrate. HARBOR, a framework for agentic robot reinforcement learning automation from Li et al. in 2026, supports MuJoCo together with IsaacLab, Genesis, and Sapien.

Sim-to-real transfer as the practical test MuJoCo passes

Benchmark adoption alone does not establish hardware relevance. The stronger practical argument is that physically grounded contact helps trained policies transfer more reliably than contact handling aimed primarily at plausible motion. Comparisons of simulated and real leg-swing joint trajectories have found closer agreement for calibrated MuJoCo dynamics than for GPU-native alternatives. These findings support its use without establishing universal superiority. Calibration remains part of the result, and the sim-to-real gap does not disappear.

With MuJoCo’s dynamics and finite-difference derivatives, whole-body model-predictive control can plan online in real time. Here, the model must let the controller plan through contact as well as generate samples from it. Numerical stability and forces that match the physics feed directly into the control calculation.

Google DeepMind’s MuJoCo Playground, introduced in 2025, extends this practical focus through GPU-accelerated environments built with MuJoCo MJX. It covers quadruped and bipedal locomotion, non-prehensile manipulation, and dexterous manipulation, all task classes in which transfer is consequential. UC Berkeley’s mjlab shows how the engine was used for training in 2026. Students in its graduate robotics course trained their first legged locomotion policies using the framework, which open-source projects beyond the course also adopted. These uses establish practical relevance.

Where MuJoCo still falls short, and what the objections reveal about using it well

The soft-contact compromise produces recognizable artifacts, including foot drift in locomotion. Increasing friction can reduce that drift, but it can also introduce unrealistic traction. The correction creates a different modeling error. Although solref and solimp expose control over contact behavior, no setting perfectly reproduces hard-contact physics. A gait that looks better can be a poorer match for the real system.

Throughput presents a separate limitation in conventional CPU-based MuJoCo. Matching the sample throughput of GPU-native environments at scale requires substantially more compute, which constrains tasks dependent on massive parallelism. Some researchers respond by separating training from validation. They train policies in high-throughput GPU-native environments, then run them in MuJoCo to check how well the physics matches before hardware transfer.

Sensor requirements can also favor another simulator. Tasks requiring high-fidelity vision at scale or the richest sensor stack out of the box expose a weakness distinct from contact dynamics. MuJoCo’s strength remains fast, batched, non-vision reinforcement learning. The appropriate choice therefore depends on which constraint dominates the task, whether contact fidelity, sample throughput, or sensor richness.

How MuJoCo is addressing its throughput gap in 2025–2026

MuJoCo Warp, or MJWarp, targets the throughput limitation while preserving MuJoCo’s contact model. Google DeepMind and NVIDIA announced the GPU-optimized version at GTC 2025 and maintain it jointly for NVIDIA hardware. The work extends MuJoCo’s physics to a different execution platform. Disney Research, Google DeepMind, and NVIDIA separately started Newton together as part of a wider effort to develop GPU simulation.

MJWarp reports more than 100× faster simulation than MJX on complex manipulation tasks. Benchmarks on an RTX 4090 show up to 152× acceleration for locomotion and up to 313× for manipulation. MJWarp also includes a high-throughput GPU batch renderer for cameras across parallel simulation worlds, using ray-tracing to render MuJoCo scenes at millions of frames per second on NVIDIA GPUs. That development addresses vision throughput as well as physics throughput.

Once MJWarp exits alpha, its planned integration into MJX will give existing MJX users the speedup without code changes. It should not be treated as an already completed transition. Meanwhile, version 3.10.0, released June 22, 2026, introduced mju_threadpool, and version 3.14.0 followed on September 22, 2026. Monthly releases, together with competitive pressure from Genesis, a new entrant as of December 2024, and continued GPU-native development, show an active effort to narrow the throughput gap.

What understanding MuJoCo's design choices means for how researchers should use it

Researchers should configure MuJoCo around the task rather than accept defaults as a physical specification. Researchers should tune the solver through solref and solimp to get the contact behavior the task needs. Friction adjustments need the same discipline. In locomotion, reducing foot drift through higher friction changes the model’s bias, so the resulting traction must be understood as part of the approximation. They should also choose the timestep to match the real system’s control bandwidth and controller update rate, which reduces one source of sim-to-real mismatch.

The training architecture should follow the workload’s dominant constraint. For GPU-scale work now, MuJoCo Playground or MJX provides batched simulation while retaining MuJoCo physics. Playground exposes quadrupeds, humanoids, dexterous hands, and arms through a Gym-style API. When another environment has the training throughput needed, researchers can still validate policies in MuJoCo before hardware transfer. That division of labor uses its physical fidelity without making conventional CPU throughput the bottleneck.

These choices also explain why automation frameworks can build on the engine. HARBOR’s workflow, from environment setup through policy training, needs an engine that behaves in predictable ways and has clearly defined parameters. Automation makes understanding those parameters and their clarity more valuable as workflows expand.