Fix typos in MuJoCo documentation.

PiperOrigin-RevId: 656068822
Change-Id: I5ebbb3701148ea4d978a6a1ad3f762ffcc7e57cb

doc/programming/extension.rst

@@ -185,7 +185,7 @@ faithfully restored.
 
 Plugins must declare the number of floating point values required for each instance via the ``nstate`` callback of its
 :ref:`mjpPlugin` struct. Note that this number can depend on the exact configuration of the instance. During
-:ref:`mj_makeData`, MuJoCo allocate the requisite number of slots in the ``plugin_state`` field of :ref:`mjData` for
+:ref:`mj_makeData`, MuJoCo allocates the requisite number of slots in the ``plugin_state`` field of :ref:`mjData` for
 each plugin instance. The ``plugin_stateadr`` field in :ref:`mjModel` indicates the position within the overall
 ``plugin_state`` array at which each plugin instance can find its state values.
 

doc/programming/modeledit.rst

@@ -20,7 +20,7 @@ Overview
 The new API augments the traditional workflow of creating and editing models using XML files, breaking up the *parse* and
 *compile* steps. As summarized in the the :ref:`Overview chapter<Instance>`, the traditional workflow is:
 
- 1. Create an XML model description file (MJCF or URDF) and ascociated assets. |br|
+ 1. Create an XML model description file (MJCF or URDF) and associated assets. |br|
  2. Call :ref:`mj_loadXML`, obtain an :ref:`mjModel` instance.
 
 The new workflow is:
@@ -107,7 +107,7 @@ Known issues
   to `user_api_test.cc <https://github.com/google-deepmind/mujoco/blob/main/test/user/user_api_test.cc>`__ and the MJCF
   parser in `xml_native_reader.cc <https://github.com/google-deepmind/mujoco/blob/main/src/xml/xml_native_reader.cc>`__,
   which is already using this API.
-- One of the central design consideration of the new API is incremental compilation, meaning that after making small
+- One of the central design considerations of the new API is incremental compilation, meaning that after making small
   changes to a spec that has already been compiled, subsequent re-compilation will be very fast. While the code is
   written to support incremental compilation, this functionality is not fully implemented and will be added in the
   future, resulting in faster re-compilation times.

doc/programming/simulation.rst

@@ -945,7 +945,7 @@ this body quaternion, the quaternions of all other objects attached to the body
 multiplication. The function :ref:`mj_local2Global` converts from local body coordinates to global Cartesian
 coordinates.
 
-:ref:`mju_negPose` and :ref:`mju_trnVecPose`. A pose is a grouping of a 3D position and a unit quaternion orientation.
+A pose is a grouping of a 3D position and a unit quaternion orientation.
 There is no separate data structure; the grouping is in terms of logic. This represents a position and orientation in
 space, or in other words a spatial frame. Note that OpenGL uses 4-by-4 matrices to represent the same information,
 except here we use a quaternion for orientation. The function mju_mulPose multiplies two poses, meaning that it