https://youtu.be/17XpwnqyCXs New transmission type mjTRN_SO3: a relative orientation, targeting a ball joint or a site+refsite pair. It is the first transmission with more than one force output: its length is the norm of the expmap vector of the relative rotation and its moment axes are the 3 rows of the relative rotational Jacobian, without projecting onto per-actuator gears. New force law mjGAIN_SO3/mjBIAS_SO3: a geodesic PD servo, force = kp * log(q_current^-1 * q_target) - kv * velocity, exact for arbitrary axis combinations with a unique equilibrium at every commanded orientation. Error, moment rows and velocity all live in the child frame (joint or site): the right-difference error is the gradient of the geodesic potential in that frame. The parent-frame (left) error is not: driving child-frame torques with it pumps energy at large angles, settling into steady-spinning limit cycles (the SO3LargeAngleConvergence test). The integrator variant stores the 3D orientation setpoint in act (actnum = 3, re-anchored to a bounded representative at integration time). Exposed in MJCF as <orientation joint=|site=+refsite= kp kv|dampratio>, or via <general gaintype="so3" biastype="so3">. The setpoint input has two charts: an expmap target (3 controls, default) or a quaternion target (4 controls) -- <orientation input="quat">, the first actuator with different input and output widths. The signature is recorded in a new per-actuator field actuator_ctrlspec (mjtCtrlChart), whose meaning is scoped by the gain type the way gain/bias parameters are; ctrlnum is derived from it at compile time and remains the layout authority. An explicit field rather than width inference or a prm slot: width-as-chart cannot express same-width signatures (upcoming servo input subsets), and prm slots are the input_mode pattern this stack retires. The force law normalizes the commanded quaternion, making it scale- and antipodally-invariant. The all-zero ctrl still maps to the identity via mju_normalize4, but it is a degenerate point (a nudge of any component commands a half-turn), so quat inputs reset to the identity quaternion: new mj_resetCtrl sets neutral ctrl values (zero, except qw = 1), called by mj_resetData and the viewers' Clear All. The quat chart is restricted to dyntype 'none': integrating a quaternion setpoint linearly is not meaningful on the manifold. New mjsActuator.ctrlspec field carries the signature through the spec and XML round-trip. Actuator sensors (actuatorpos/vel/frc) now report one value per force output; dim = 3 on an SO3 actuator. As the first actuator with nu != nactuator, this commit also makes the viewers multi-input aware: the control sliders in simulate and studio, which indexed per-actuator arrays by control index (out of bounds on this model class), are generated per control and labeled with the actuator name plus an input suffix ("orient/qw"), via the new introspection helper mj_actuatorInputName -- the single source of truth for input names, extended by each new multi-input type (quaternion components are w-first: qw, qx, qy, qz). Slider ranges now honor a defined ctrlrange even when ctrllimited is false: range is the UI hint, limited is the clamp -- wrapped and expmap setpoints are unbounded but still want finite sliders, while quat components are truly bounded. The rotational demo model is orientation.xml under test/engine/testdata/actuation/, upgraded to a three-way contrast: per-axis wrapped servos vs an expmap-commanded vs a quat-commanded orientation actuator, on identical checker-textured boxes. It is loaded by the mixed-axis contrast and input-name tests, and doubles as the viewer test model (slider groups of 3 independent, 3 grouped, 4 grouped). PiperOrigin-RevId: 951607063 Change-Id: If235dba8e2f2ca72672e7c62531a27e967c6a373
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.
