Yuval Tassa
2f1843f4a7
The dcmotor input block is any subset of the canonical list [pos, vel, ff, voltage], selected with input="pos vel ff voltage" and recorded as mjtCtrlInput bits in actuator_ctrlspec like pid. Tokens are required in canonical order: the attribute denotes a set, the block always packs canonically, and accepting permutations invites reading the string as a layout choice. The mode flag in gainprm[8] is retired (reserved, written 0). Controller gains are now in torque space, as for pid: the controller commands tau = kp*(q*-l) + kd*(v*-ldot) + ki*x_I + tau_ff over the present inputs (absent setpoints frozen at zero) and converts to drive voltage V = R/K * tau + K*ldot. The second term compensates back-EMF, as the current loop of a real torque-mode driver does (torque commands are current commands): commanded torque is delivered exactly until a limit binds, and the torque-speed envelope emerges from the Vmax clamp. The map uses the nameplate R: thermal resistance growth is not compensated, so a hot motor under-delivers by R/R(T). A stateless setpoint dcmotor now matches <pid> exactly, for any K and R; the old back-EMF droop remains available as the physical behavior of the raw voltage path. Voltage-space datasheet gains convert by K/R. Controller inputs require a positive motor constant (the map divides by K), and controller gains require a controller input. ff and voltage are distinct inputs, different in kind: ff is a torque feedforward added to the controller output, uniform with pid's ff (feedforward in the actuator's output space), while voltage is the raw terminal voltage of the physical device, injected downstream of the controller and its Vmax clamp, unclamped (ctrlrange bounds it if desired). input="voltage" is the default: the plain voltage-commanded motor, whose behavior is unchanged by this commit. The integrator always accumulates position error; the old velocity mode's integral term, ki*(int(u)dt - theta), which tracked the integral of the velocity command, is retired without replacement, keeping ki mode-independent -- commanded integrated velocity belongs to an integrator activation state, not to controller gains. slewmax rate-limits the first controller input -- position setpoint (rad/s), velocity setpoint (rad/s^2) or torque feedforward (N*m/s), each a real driver feature (reference ramping, ramped-velocity and ramped-torque input modes); the raw voltage input is never rate-limited and slewmax requires a controller input. input="none" selects the empty signature: the actuator owns no controls at all (nu = 0 is now legal with actuators present) and is purely passive -- LuGre friction, cogging and back-EMF braking as passive joint forces. This exists because auxiliary dynamic states (the LuGre bristle) attach to actuators, not joints. The terminal voltage is identically zero, i.e. a shorted motor (dynamic braking); motorconst=0 decouples the electrical branch. mjINPUT_NONE is a distinct enum value because ctrlspec = 0 means "unset, use the type default". History and delay require an input; the controller voltage override and input read in mj_fwdActuation are gated on a nonempty block. The analytic velocity derivative of the controller becomes dV/dw = -kd*R/K + K, whose second term cancels the back-EMF bias exactly: the net damping of an unclipped torque-mode motor is -kd, and of a voltage-mode or passive motor -K^2/R. Viewers label inputs via mj_actuatorInputName: pos, vel, ff, voltage. The dcmotor LaTeX design doc is updated accordingly: torque-space units, the tau->V map and its saturation-generated envelope, the input-block pipeline figure, and a Passive Operation section. PiperOrigin-RevId: 965795351 Change-Id: Ibc308ca21bd6bad014e77f950ee08feaad449b73
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.