Fix documentation typos.

PiperOrigin-RevId: 720232771
Change-Id: I176db4d4168c37b2819df14b439c4cde838e2025

doc/APIreference/APItypes.rst

@@ -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

@@ -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

@@ -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

@@ -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

@@ -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

@@ -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

@@ -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
+     gyroscopic forces. The most common case where integrating such forces implicitly leads to noticeable improvement is
-     when free objects with assymetric inertia are spinning quickly. `gyroscopic.xml <../_static/gyroscopic.xml>`__
+     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

@@ -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

@@ -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
+   two options use separate code paths using dense or sparse algebra, but are otherwise computationally identical, so
-   faster one is always preferred. The default "auto" heuristic does not always make the right choice.
+   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
+     typically achieves 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.
+     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

@@ -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

@@ -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

@@ -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
+``mujoco.rollout`` and ``mujoco.rollout.Rollout`` shows how to add additional C/C++ functionality, exposed as a Python
-via pybind11. It is implemented in `rollout.cc <https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.cc>`__
+module via pybind11. It is implemented in `rollout.cc
-and wrapped in `rollout.py <https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.py>`__. The module
+<https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.cc>`__ and wrapped in `rollout.py
-performs a common functionality where tight loops implemented outside of Python are beneficial: rolling out a trajectory
+<https://github.com/google-deepmind/mujoco/blob/main/python/mujoco/rollout.py>`__. The module performs a common
-(i.e., calling :ref:`mj_step` in a loop), given an intial state and sequence of controls, and returning subsequent
+functionality where tight loops implemented outside of Python are beneficial: rolling out a trajectory (i.e., calling
-states and sensor values. The rollouts are run in parallel with an internally managed thread pool if multiple MjData instances
+:ref:`mj_step` in a loop), given an initial state and sequence of controls, and returning subsequent states and sensor
-(one per thread) are passed as an argument. The basic usage form is
+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``.
+- ``model`` is either a single instance of MjModel or a sequence of homogeneous MjModels of length ``nbatch``.
-``data`` is either a single instance of MjData or a sequence of compatible MjData of length ``nthread``.
+  Homogeneous models have the same integer sizes, but floating point values can differ.
-``initial_state`` is an ``nbatch x nstate`` array, with ``nbatch`` initial states of size ``nstate``, where
+- ``data`` is either a single instance of MjData or a sequence of compatible MjDatas of length ``nthread``.
-``nstate = mj_stateSize(model, mjtState.mjSTATE_FULLPHYSICS)`` is the size of the
+- ``initial_state`` is an ``nbatch x nstate`` array, with ``nbatch`` initial states of size ``nstate``, where
-:ref:`full physics state<geFullPhysics>`. ``control`` is a ``nbatch x nstep x ncontrol`` array of controls. Controls are
+  ``nstate = mj_stateSize(model, mjtState.mjSTATE_FULLPHYSICS)`` is the size of the
-by default the ``mjModel.nu`` standard actuators, but any combination of :ref:`user input<geInput>` arrays can be
+  :ref:`full physics state<geFullPhysics>`.
-specified by passing an optional ``control_spec`` bitflag.
+- ``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
+The ``rollout`` function is designed to be computationally stateless, so all inputs of the stepping pipeline are set and
-values already present in the given ``MjData`` instance will have no effect on the output.
+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

@@ -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) {
+        if (homeLink) {
-          home_link.href="https://mujoco.org";
+          homeLink.href="https://mujoco.org";
         }
     });
   </script>

doc/unity.rst

@@ -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