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 Python Bindings
This package is the canonical Python bindings for the MuJoCo physics engine. These bindings are developed and maintained by Google DeepMind, and is kept up-to-date with the latest developments in MuJoCo itself.
The mujoco package provides direct access to raw MuJoCo C API functions,
structs, constants, and enumerations. Structs are provided as Python classes,
with Pythonic initialization and deletion semantics.
It is not the aim of this package to provide fully fledged
scene/environment/game authoring API, as there are already a number of existing
packages that do this well. However, this package does provide a number of
lower-level components outside of MuJoCo itself that are likely to be useful to
most users who access MuJoCo through Python. For example, the egl, glfw, and
osmesa subpackages contain utilities for setting up OpenGL rendering contexts.
Installation
The recommended way to install this package is via PyPI:
pip install mujoco
A copy of the MuJoCo library is provided as part of the package and does not need to be downloaded or installed separately.
Source
IMPORTANT: Building from source is only necessary if you are modifying the Python bindings (or are trying to run on exceptionally old Linux systems). If that's not the case, then we recommend installing the prebuilt binaries from PyPI.
If you need to build the Python bindings from source, please consult the documentation.
Usage
Once installed, the package can be imported via import mujoco. Please consult
our documentation for
further detail on the package's API.
We recommend going through the tutorial notebook which covers the basics of
MuJoCo using Python:
Versioning
The major.minor.micro portion of the version number matches the version of
MuJoCo that the bindings provide. Optionally, if we release updates to the
Python bindings themselves that target the same version of MuJoCo, a .postN
suffix is added, for example 2.1.2.post2 represents the second update to the
bindings for MuJoCo 2.1.2.
License and Disclaimer
Copyright 2022 DeepMind Technologies Limited
MuJoCo and its Python bindings are 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.