chenlin/Mujoco_WASM
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix documentation typos.

Browse Source 
PiperOrigin-RevId: 720232771
Change-Id: I176db4d4168c37b2819df14b439c4cde838e2025
This commit is contained in:
Yuval Tassa
2025-01-27 10:57:06 -08:00
committed by Copybara-Service
parent 9605990648
commit 8c22181156
14 changed files with 59 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/APIreference/APItypes.rst
+2 -2
View File
@@ -28,7 +28,7 @@ MuJoCo defines a large number of types:
- :ref:`mjOption` (embedded in :ref:`mjModel`).
- :ref:`mjData`.
- :ref:`Auxillary struct types<tyAuxStructure>`, also used by the engine.
- :ref:`Auxiliary struct types<tyAuxStructure>`, also used by the engine.
- Structs for collecting :ref:`simulation statistics<tyStatStructure>`.
- Structs for :ref:`abstract visualization<tyVisStructure>`.
- Structs used by the :ref:`openGL renderer<tyRenderStructure>`.
@@ -752,7 +752,7 @@ modifiable inputs and write their outputs.
.. _tyAuxStructure:
Auxillary
Auxiliary
^^^^^^^^^
These struct types are used in the engine and their names are prefixed with ``mj``. :ref:`mjVisual`
doc/APIreference/functions.rst
+1 -1
View File
@@ -504,7 +504,7 @@ found, the function will return ``distmax`` and ``fromto``, if given, will be se
.. TODO: b/339596989 - Improve mjc_Convex.
For some colliders, a large, positive ``distmax`` will result in an accurate measurement. However, for collision
pairs which use the general ``mjc_Convex`` collider, the result will be approximate and likely innacurate.
pairs which use the general ``mjc_Convex`` collider, the result will be approximate and likely inaccurate.
This is considered a bug to be fixed in a future release.
In order to determine whether a geom pair uses ``mjc_Convex``, inspect the table at the top of
`engine_collision_driver.c <https://github.com/google-deepmind/mujoco/blob/main/src/engine/engine_collision_driver.c>`__.
doc/APIreference/functions_override.rst
+1 -1
View File
@@ -228,7 +228,7 @@ found, the function will return ``distmax`` and ``fromto``, if given, will be se
.. TODO: b/339596989 - Improve mjc_Convex.
For some colliders, a large, positive ``distmax`` will result in an accurate measurement. However, for collision
pairs which use the general ``mjc_Convex`` collider, the result will be approximate and likely innacurate.
pairs which use the general ``mjc_Convex`` collider, the result will be approximate and likely inaccurate.
This is considered a bug to be fixed in a future release.
In order to determine whether a geom pair uses ``mjc_Convex``, inspect the table at the top of
`engine_collision_driver.c <https://github.com/google-deepmind/mujoco/blob/main/src/engine/engine_collision_driver.c>`__.
doc/XMLreference.rst
+9 -9
View File
@@ -591,7 +591,7 @@ from its default.
.. _option-flag-autoreset:
:at:`autoreset`: :at-val:`[disable, enable], "enable"`
This flag disables the automatic reseting of the simulation state when numerical issues are detected.
This flag disables the automatic resetting of the simulation state when numerical issues are detected.
.. _option-flag-override:
@@ -604,7 +604,7 @@ from its default.
This flag enables the computation of potential and kinetic energy in ``mjData.energy[0, 1]`` respectively,
and displayed in the simulate GUI info overlay. Potential energy includes the gravitational component summed over
all bodies :math:`\sum_b m_b g h` and energy stored in passive springs in joints, tendons and flexes
:math:`\tfrac{1}{2} k x^2`, where :math:`x` is the displacement and and :math:`k` is the spring constant. Kinetic
:math:`\tfrac{1}{2} k x^2`, where :math:`x` is the displacement and :math:`k` is the spring constant. Kinetic
energy is given by :math:`\tfrac{1}{2} v^T M v`, where :math:`v` is the velocity and :math:`M` is the
mass matrix. Note that potential and kinetic energy in constraints is not accounted for.
@@ -1271,7 +1271,7 @@ The full list of processing steps applied by the compiler to each mesh is as fol
:at:`maxhullvert`: :at-val:`int, "-1"`
Maximum number of vertices in a mesh's convex hull. Currently this is implemented by asking qhull
`to teminate <http://www.qhull.org/html/qh-optt.htm#TAn>`__ after :at:`maxhullvert` vertices. The default
`to terminate <http://www.qhull.org/html/qh-optt.htm#TAn>`__ after :at:`maxhullvert` vertices. The default
value of -1 means "unlimited". Positive values must be larger than 3.
.. _asset-mesh-vertex:
@@ -2122,7 +2122,7 @@ rotations as unit quaternions.
(``mjData.qfrc_actuator``) rather than passive forces (``mjData.qfrc_passive``). Notionally, this means that gravity
compensation is the result of a control system rather than natural buoyancy. In practice, enabling this flag is
useful when joint-level actuator force clamping is used. In this case, the total actuation force applied on a joint,
including gravity compensation, is guaranteed to not exceeed the specified limits. See :ref:`CForceRange` and
including gravity compensation, is guaranteed to not exceed the specified limits. See :ref:`CForceRange` and
:ref:`actuatorfrcrange<body-joint-actuatorfrcrange>` for more details on this type of force limit.
.. _body-joint-margin:
@@ -2505,7 +2505,7 @@ helps clarify the role of bodies and geoms in MuJoCo.
<COrientation>`. The frame position is in the middle between the end points. If this attribute is specified, the
remaining position and orientation-related attributes are ignored. The image on the right demonstrates use of
:at:`fromto` with the four supported geoms, using identical Z values. The model is `here <_static/fromto.xml>`__.
Note that the :at:`fromto` semantics of *capsule* are unique: the two end points specify the segement around which
Note that the :at:`fromto` semantics of *capsule* are unique: the two end points specify the segment around which
the radius defines the capsule surface.
.. _body-geom-pos:
@@ -2736,7 +2736,7 @@ and the +Y axis points up. Thus the frame position and orientation are the key a
:at:`mode`: :at-val:`[fixed, track, trackcom, targetbody, targetbodycom], "fixed"`
This attribute specifies how the camera position and orientation in world coordinates are computed in forward
kinematics (which in turn determine what the camera sees). "fixed" means that the position and orientation specified
below are fixed relative to the the body where the camera is defined. "track" means that the camera position is at a
below are fixed relative to the body where the camera is defined. "track" means that the camera position is at a
constant offset from the body in world coordinates, while the camera orientation is constant in world coordinates.
These constants are determined by applying forward kinematics in qpos0 and treating the camera as fixed. Tracking can
be used for example to position a camera above a body, point it down so it sees the body, and have it always remain
@@ -4052,7 +4052,7 @@ cases, the user will specify a :el:`flexcomp` which will then automatically cons
which is why the number of indices equals (dim+1) times the number of elements. In 2D, the vertices should be listed
in counter-clockwise order. In 1D and 3D the order is irrelevant; in 3D the model compiler will rearrange the
vertices as needed. Repeated vertex indices within a flex element are not allowed. The topology of the flex is not
enforced; it could corespond to a continuous soft body, or a collection of disconnected stretchable elements, or
enforced; it could correspond to a continuous soft body, or a collection of disconnected stretchable elements, or
anything in-between.
.. _deformable-flex-flatskin:
@@ -4140,7 +4140,7 @@ stress-strain relationship.. See also :ref:`deformable <CDeformable>` objects.
:at:`thickness`: :at-val:`real(1), "-1"`
Shell thickness, units of length; only for used 2D flexes. Used to scale the stretching stiffness.
This thickness can be set equal to 2 times the :ref:`radius <deformable-flex-radius>` in order to match the geometry,
but is exposed seperately since the radius might be constrained by considerations related to collision detection.
but is exposed separately since the radius might be constrained by considerations related to collision detection.
.. _flex-contact:
@@ -7099,7 +7099,7 @@ pipeline. These 3 sensors share some common properties:
.. TODO: b/339596989 - Improve mjc_Convex.
For some colliders, a positive :at:`cutoff` will result in an accurate measurement. However, for collision
pairs which use the general ``mjc_Convex`` collider, the result will be approximate and likely innacurate.
pairs which use the general ``mjc_Convex`` collider, the result will be approximate and likely inaccurate.
This is considered a bug to be fixed in a future release.
In order to determine whether a geom pair uses ``mjc_Convex``, inspect the table at the top of
`engine_collision_driver.c <https://github.com/google-deepmind/mujoco/blob/main/src/engine/engine_collision_driver.c>`__.
doc/changelog.rst
+6 -6
View File
@@ -88,7 +88,7 @@ General
4. The not-useful ``convexhull`` compiler option (to disable computation of mesh convex hulls) has been removed.
5. Removed the deprecated ``mju_rotVecMat``, ``mju_rotVecMatT`` and ``mjv_makeConnector`` functions.
6. Sorting now uses a faster, native sort function (fixes :github:issue:`1638`).
7. The PBR texture layers introduced in 3.2.1 were refactored from seperate sub-elements to a single
7. The PBR texture layers introduced in 3.2.1 were refactored from separate sub-elements to a single
:ref:`layer<material-layer>` sub-element.
8. The composite types box, cylinder, and sphere have been removed. Users should instead use the equivalent types
available in :ref:`flexcomp<body-flexcomp>`.
@@ -178,7 +178,7 @@ General
4. Added the :ref:`nativeccd<option-flag-nativeccd>` flag. When this flag is enabled, general convex collision
detection is handled with a new native code path, rather than `libccd <https://github.com/danfis/libccd>`__.
This feature is in early stages of testing, but users who've experienced issues related to collsion detection are
This feature is in early stages of testing, but users who've experienced issues related to collision detection are
welcome to experiment with it and report any issues.
.. youtube:: kcM_oauk3ZA
@@ -316,7 +316,7 @@ General
The older functions have been removed from the Python bindings and will be removed from the C API in the next
release.
5. Removed the ``actuator_actdim`` callback from actuator plugins. They now have the ``actdim`` attribute, which
must be used with actuators that write state to the ``act`` array. This fixed a crash which happend when
must be used with actuators that write state to the ``act`` array. This fixed a crash which happened when
keyframes were used in a model with stateful actuator plugins. The PID plugin will give an error when the wrong
value of actdim is provided.
@@ -577,7 +577,7 @@ General
1. Improved the :ref:`discardvisual<compiler-discardvisual>` compiler flag, which now discards all visual-only assets.
See :ref:`discardvisual<compiler-discardvisual>` for details.
2. Removed the :ref:`timer<mjtTimer>` for midphase colllision detection, it is now folded in with the narrowphase
timer. This is because timing the two phases seperately required fine-grained timers inside the collision
timer. This is because timing the two phases separately required fine-grained timers inside the collision
functions; these functions are so small and fast that the timer itself was incurring a measurable cost.
3. Added the flag :ref:`bvactive<visual-global-bvactive>` to ``visual/global``, allowing users to turn off
visualisation of active bounding volumes (the red/green boxes in this :ref:`this changelog item<midphase>`). For
@@ -1050,7 +1050,7 @@ Simulate
:width: 240px
6. Added Visualization tab to simulate UI, corresponding to elements of the :ref:`visual<visual>` MJCF element. After
modifying values in the GUI, a saved XML will contain the new values. The modifyable members of
modifying values in the GUI, a saved XML will contain the new values. The modifiable members of
:ref:`mjStatistic` (:ref:`extent<statistic-extent>`, :ref:`meansize<statistic-meansize>` and
:ref:`center<statistic-center>`) are computed by the compiler and therefore do not have defaults. In order for these
attributes to appear in the saved XML, a value must be specified in the loaded XML.
@@ -1169,7 +1169,7 @@ Python bindings
passive viewer now also requires an explicit call to ``sync`` on its handle to pick up any update to the physics
state. This is to avoid race conditions that can result in visual artifacts. See
:ref:`documentation<PyViewerPassive>` for details.
#. The ``viewer.launch_repl`` function has been removed since its functionality is superceded by ``launch_passive``.
#. The ``viewer.launch_repl`` function has been removed since its functionality is superseded by ``launch_passive``.
#. Added a small number of missing struct fields discovered through the new ``introspect`` metadata.
Bug fixes
doc/computation/fluid.rst
+1 -1
View File
@@ -135,7 +135,7 @@ also disables the inertia-based model for the parent body. The
Elements of the model are a generalization of :cite:t:`andersen2005b` to 3 dimensions.
The force :math:`\mathbf{f}_{\text{ellipsoid}}` and torque
:math:`\mathbf{g}_{\text{ellipsoid}}` exerted by the fluid onto the solid are
the sum of of the terms
the sum of the terms
.. math::
\begin{align*}
doc/computation/index.rst
+6 -6
View File
@@ -241,7 +241,7 @@ The computation of the constraint force is the hard part and will be described l
description of the general framework by summarizing how the above quantities up to the constraint Jacobian are computed.
- The applied force :math:`\tau` includes :ref:`passive <gePassive>` forces from spring-dampers and fluid dynamics,
:ref:`actuation <geActuation>` forces, and additonal forces specified by the user.
:ref:`actuation <geActuation>` forces, and additional forces specified by the user.
- The bias force :math:`c` includes Coriolis, centrifugal and gravitational forces. Their sum is computed using the
Recursive Newton-Euler (RNE) algorithm with acceleration set to 0.
- The joint-space inertia matrix :math:`M` is computed using the Composite Rigid-Body (CRB) algorithm. This matrix is
@@ -414,7 +414,7 @@ with MuJoCo's operation as long as such user forces depend only on position and
MuJoCo can compute three types of passive forces:
- Spring-dampers in joints and tendons. See the following attribues for details.
- Spring-dampers in joints and tendons. See the following attributes for details.
|br| **Joints:**
:ref:`stiffness<body-joint-stiffness>`, :ref:`springref<body-joint-springref>`,
:ref:`damping<body-joint-damping>`, :ref:`springdamper<body-joint-springdamper>`.
@@ -576,8 +576,8 @@ Fast implicit-in-velocity (``implicitfast``)
increased stability, and is therefore a strict improvement. It is the recommended integrator for most models.
**implicit**:
The benefit over ``implicitfast`` is the implicit integration of Coriolis and centripetal forces, including
gyroscopic forces. The most common case where integrating such forces implicitly leads to noticable improvement is
when free objects with assymetric inertia are spinning quickly. `gyroscopic.xml <../_static/gyroscopic.xml>`__
gyroscopic forces. The most common case where integrating such forces implicitly leads to noticeable improvement is
when free objects with asymmetric inertia are spinning quickly. `gyroscopic.xml <../_static/gyroscopic.xml>`__
shows an ellipsoid rolling on an inclined plane which quickly diverges with ``implicitfast`` but is stable with
``implicit``.
**RK4**:
@@ -646,7 +646,7 @@ Control: ``ctrl``
generalized forces directly (stateless actuators), or affect the actuator activations in ``mjData.act``, which then
produce forces.
Auxillary Controls: ``qfrc_applied`` and ``xfrc_applied``
Auxiliary Controls: ``qfrc_applied`` and ``xfrc_applied``
| ``mjData.qfrc_applied`` are directly applied generalized forces.
| ``mjData.xfrc_applied`` are Cartesian wrenches applied to the CoM of individual bodies. This field is used for
example, by the :ref:`native viewer<saSimulate>` to apply mouse perturbations.
@@ -1722,7 +1722,7 @@ The top-level function :ref:`mj_inverse` invokes the following sequence of compu
Derivatives
-----------
MuJoCo's entire computational pipline including its constraint solver are analytically differentiable in principle.
MuJoCo's entire computational pipeline including its constraint solver are analytically differentiable in principle.
Writing efficient implementations of these derivatives is a long term goal of the development team. Analytic derivatives
of the smooth dynamics (excluding constraints) with respect to velocity are already computed and enable the two
:ref:`implicit integrators<geIntegration>`.
doc/mjx.rst
+1 -1
View File
@@ -50,7 +50,7 @@ The recommended way to install this package is via `PyPI <https://pypi.org/proje
pip install mujoco-mjx
A copy of the MuJoCo library is provided as part of this package's depdendencies and does **not** need to be downloaded
A copy of the MuJoCo library is provided as part of this package's dependencies and does **not** need to be downloaded
or installed separately.
.. _MjxUsage:
doc/modeling.rst
+6 -6
View File
@@ -629,7 +629,7 @@ Group disable
The :ref:`actuatorgroupdisable<option-actuatorgroupdisable>` attribute, which can be changed at runtime by setting the
:ref:`mjOption.disableactuator<mjOption>` integer bitfield, allows the user to disable sets of actuators according to
their :ref:`group<actuator-general-group>`. This feature is convenient when one would like to use multiple types of
actuators for the same kinematic tree. For example consider a robot with firmware that supports mutiple control modes
actuators for the same kinematic tree. For example consider a robot with firmware that supports multiple control modes
e.g., torque-control and position-control. In this case, one can define both types of actuators in the same MJCF
model, assigning one type of actuator to group 0 and the other to group 1.
@@ -1452,7 +1452,7 @@ elements available in MuJoCo. In addition to standard URDF files, MuJoCo can loa
viewpoint of URDF) :el:`mujoco` element as a child of the top-level element :el:`robot`. This custom element can have
sub-elements :ref:`compiler <compiler>`, :ref:`option <option>`,
:ref:`size <size>` with the same functionality as in MJCF, except that the default compiler settings
are modified so as to accomodate the URDF modeling convention. The :ref:`compiler <compiler>` extension
are modified so as to accommodate the URDF modeling convention. The :ref:`compiler <compiler>` extension
in particular has proven very useful, and indeed several of its attributes were introduced because a number of
existing URDF models have non-physical dynamics parameters which MuJoCo's built-in compiler will reject if left
unmodified. This extension is also needed to specify mesh directories. Also note that the compiler attributes
@@ -1607,8 +1607,8 @@ dedicated section :ref:`therein<MjxPerformance>`.
:ref:`Numerical Integration<geIntegration>` section. The default recommended choice is the ``implicitfast``
integrator.
3. :ref:`Constraint Jacobians<option-jacobian>`: Try switching the Jacobian setting between "dense" and "sparse". These
two options use seperate code paths using dense or sparse algebra, but are otherwise computationally identical, so the
faster one is always preferred. The default "auto" heuristic does not always make the right choice.
two options use separate code paths using dense or sparse algebra, but are otherwise computationally identical, so
the faster one is always preferred. The default "auto" heuristic does not always make the right choice.
4. **Constraint solver:** If the profiler reports that a large chunk of time is spent in the solver, consider the
following:
@@ -1617,8 +1617,8 @@ dedicated section :ref:`therein<MjxPerformance>`.
freedom than constraints, the PGS solver will be fastest, though this situation is not common.
- :ref:`iterations<option-iterations>` and :ref:`tolerance<option-tolerance>`: Try reducing the number of iterations
or, equivalently, increasing the solver's termination tolerance. In particular for the Newton solver, which
typically acheives numerical convergence in 2-3 (expensive) iterations, the last iteration increases the precision
to a level that has no noticable effect, and can be skipped.
typically achieves numerical convergence in 2-3 (expensive) iterations, the last iteration increases the precision
to a level that has no noticeable effect, and can be skipped.
5. **Collisions:** If the profiler reports that collision detection takes up a large chunk of the computation
time, consider the following steps:
doc/overview.rst
+2 -2
View File
@@ -591,7 +591,7 @@ Flex
Flexes were added in MuJoCo 3.0. They represent deformable meshes that can be 1, 2 or 3 dimensional (thus their elements
are capsules, triangles or tetrahedra). Unlike geoms which are static shapes attached rigidly to a single body, the
elements of a flex are deformable: they are constructed by connecting multiple bodies, thus the body positions and
orientations determine the shape of the flex elements at runtime. These deformable elements suport collisions and
orientations determine the shape of the flex elements at runtime. These deformable elements support collisions and
contact forces, as well as generate passive and constraint forces which softly preserve the shape of the deformable
entity. Automation is provided to load a mesh from a file, construct bodies corresponding to the mesh vertices,
construct flex elements corresponding to the mesh faces (or lines or tetrahedra, depending on dimensionality), and
@@ -939,7 +939,7 @@ positions and orientations as well as the linear and angular velocities of such
The semantics of free joints are as follows. The position data is 7 numbers (3D position followed
by unit quaternion) while the velocity data is 6 numbers (3D linear velocity followed by 3D angular velocity).
The linear postions of free joints are in the global frame, as are
The linear positions of free joints are in the global frame, as are
linear velocities. The orientation of a free joint (the quaternion) is also in the global frame. However, the rotational
velocities of a free joint are in the local body frame. This is not so much a design decision but rather correct
use of the topology of quaternions. Angular velocities live in the quaternion tangent space, which is defined locally
doc/programming/modeledit.rst
+1 -1
View File
@@ -76,7 +76,7 @@ Loading a spec from XML can be done as follows:
Model elements
^^^^^^^^^^^^^^
Model elements coresponding to MJCF are exposed to the user as C structs with the ``mjs`` prefix, the definitions are
Model elements corresponding to MJCF are exposed to the user as C structs with the ``mjs`` prefix, the definitions are
listed under the :ref:`Model Editing<tySpecStructure>` section of the struct reference. For example, an MJCF
:ref:`geom<body-geom>` corresponds to an :ref:`mjsGeom`.
doc/python.rst
+19 -16
View File
@@ -718,31 +718,34 @@ The ``mujoco`` package contains two sub-modules: ``mujoco.rollout`` and ``mujoco
rollout
-------
``mujoco.rollout`` and ``mujoco.rollout.Rollout`` shows how to add additional C/C++ functionality, exposed as a Python module
via pybind11. It is implemented in `rollout.cc <https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.cc>`__
and wrapped in `rollout.py <https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.py>`__. The module
performs a common functionality where tight loops implemented outside of Python are beneficial: rolling out a trajectory
(i.e., calling :ref:`mj_step` in a loop), given an intial state and sequence of controls, and returning subsequent
states and sensor values. The rollouts are run in parallel with an internally managed thread pool if multiple MjData instances
(one per thread) are passed as an argument. The basic usage form is
``mujoco.rollout`` and ``mujoco.rollout.Rollout`` shows how to add additional C/C++ functionality, exposed as a Python
module via pybind11. It is implemented in `rollout.cc
<https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.cc>`__ and wrapped in `rollout.py
<https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.py>`__. The module performs a common
functionality where tight loops implemented outside of Python are beneficial: rolling out a trajectory (i.e., calling
:ref:`mj_step` in a loop), given an initial state and sequence of controls, and returning subsequent states and sensor
values. The rollouts are run in parallel with an internally managed thread pool if multiple MjData instances (one per
thread) are passed as an argument. The basic usage form is
.. code-block:: python
state, sensordata = rollout.rollout(model, data, initial_state, control)
``model`` is either a single instance of MjModel or a sequence of compatible MjModel of length ``nbatch``.
``data`` is either a single instance of MjData or a sequence of compatible MjData of length ``nthread``.
``initial_state`` is an ``nbatch x nstate`` array, with ``nbatch`` initial states of size ``nstate``, where
``nstate = mj_stateSize(model, mjtState.mjSTATE_FULLPHYSICS)`` is the size of the
:ref:`full physics state<geFullPhysics>`. ``control`` is a ``nbatch x nstep x ncontrol`` array of controls. Controls are
by default the ``mjModel.nu`` standard actuators, but any combination of :ref:`user input<geInput>` arrays can be
specified by passing an optional ``control_spec`` bitflag.
- ``model`` is either a single instance of MjModel or a sequence of homogeneous MjModels of length ``nbatch``.
Homogeneous models have the same integer sizes, but floating point values can differ.
- ``data`` is either a single instance of MjData or a sequence of compatible MjDatas of length ``nthread``.
- ``initial_state`` is an ``nbatch x nstate`` array, with ``nbatch`` initial states of size ``nstate``, where
``nstate = mj_stateSize(model, mjtState.mjSTATE_FULLPHYSICS)`` is the size of the
:ref:`full physics state<geFullPhysics>`.
- ``control`` is a ``nbatch x nstep x ncontrol`` array of controls. Controls are by default the ``mjModel.nu`` standard
actuators, but any combination of :ref:`user input<geInput>` arrays can be specified by passing an optional
``control_spec`` bitflag.
If a rollout diverges, the current state and sensor values are used to fill the remainder of the trajectory.
Therefore, non-increasing time values can be used to detect diverged rollouts.
The ``rollout`` function is designed to be computationally stateless, so all inputs of the stepping pipeline are set and any
values already present in the given ``MjData`` instance will have no effect on the output.
The ``rollout`` function is designed to be computationally stateless, so all inputs of the stepping pipeline are set and
any values already present in the given ``MjData`` instance will have no effect on the output.
By default ``rollout.rollout`` creates a new thread pool every call if ``len(data) > 1``. To reuse the thread pool
over multiple calls use the ``persistent_pool`` argument. ``rollout.rollout`` is not thread safe when using
doc/templates/layout.html
Vendored
+3 -3
View File
@@ -11,10 +11,10 @@
#}
<script>
document.addEventListener('DOMContentLoaded', (event) => {
let home_link = document.querySelector('a.icon');
let homeLink = document.querySelector('a.icon');
{# Be extra safe and don't break the page if theme changes and querySelector can't match. #}
if (home_link) {
home_link.href="https://mujoco.org";
if (homeLink) {
homeLink.href="https://mujoco.org";
}
});
</script>
doc/unity.rst
+1 -1
View File
@@ -20,7 +20,7 @@ Installation instructions
The `plug-in directory <https://github.com/google-deepmind/mujoco/tree/main/unity>`__ includes a
``package.json`` file. Unity's package manager recognizes this file and will import the plug-in's C# codebase to your
project. In addition, Unity also needs the native MuJoCo library, which can be found in the corrsponding `platform
project. In addition, Unity also needs the native MuJoCo library, which can be found in the corresponding `platform
archive <https://github.com/google-deepmind/mujoco/releases>`__. If you wish to simply use the plug-in and not
develop it, you should use one of the version-specific stable commits of the repository, identified by git tags. Check
out the relevant version of the cloned repository with git (``git checkout 3.X.Y`` where X and Y specify the engine