Merge pull request #2336 from xela-95:patch-2

PiperOrigin-RevId: 713991183
Change-Id: I0869a068f463513e89fe2f88bca4b82177cfffa3

doc/programming/simulation.rst

@@ -267,7 +267,7 @@ control laws obtained from trajectory optimizers would normally be indexed by ``
 The reason for the "official" caveat above is because user callbacks may store additional state variables that change
 over time and affect the callback outputs; indeed the field ``mjData.userdata`` exists mostly for that purpose. Other
 state-like quantities that are part of mjData and are treated as inputs by forward dynamics are ``mjData.mocap_pos`` and
-mjData.mocap_quat. These quantities are unusual in that they are meant to change at each time step (normally driven by a
+``mjData.mocap_quat``. These quantities are unusual in that they are meant to change at each time step (normally driven by a
 motion capture device), however this change is implemented by the user, while the simulator treats them as constants. In
 that sense they are no different from all the constants in mjModel, or the function callback pointers set by the user:
 such constants affect the computation, but are not part of the state vector of a dynamical system.
@@ -286,7 +286,7 @@ Next we turn to the controls and applied forces. The control vector in MuJoCo is
      u = (mjData.ctrl, mjData.qfrc_applied, mjData.xfrc_applied)
 
 These quantities specify control signals (``mjData.ctrl``) for the actuators defined in the model, or directly apply
-forces and torques specified in joint space (``mjData.qfrc_applied``) or in Cartesian space (mjData.xfrc_applied).
+forces and torques specified in joint space (``mjData.qfrc_applied``) or in Cartesian space (``mjData.xfrc_applied``).
 
 Finally, calling mj_forward which corresponds to the abstract dynamics function ``f(t,x,u)`` computes the
 time-derivative of the state vector. The corresponding fields of mjData are