Fix typos and minor corrections in MuJoCo documentation and comments.

PiperOrigin-RevId: 875163889
Change-Id: Ic604d6235bf9cb999058f191e3ee41e47ec1a567

doc/programming/modeledit.rst

@@ -160,7 +160,7 @@ or :ref:`attach a frame or an mjSpec to a body<mjs_attach>`:
 
 Note that in the above examples, the parent and child models have different values for ``compiler.degree``,
 corresponding to the :ref:`compiler/angle<compiler-angle>` attribute, specifying the units in which angles are
-interperted. Compiler flags are carried over during attachment, so the child model will be compiled using the child
+interpreted. Compiler flags are carried over during attachment, so the child model will be compiled using the child
 flags, while the parent will be compiled using the parent flags.
 
 Note also that once a child is attached by reference to a parent, the child cannot be compiled on its own.

doc/programming/samples.rst

@@ -210,7 +210,7 @@ data file into a playable movie file:
 Note that the offscreen rendering resolution of the model and ffmpeg's video_size must be identical.
 
 This sample can be compiled in three ways which differ in how the OpenGL context is created: using GLFW with an
-invisible window, using OSMesa, or using EGL. The latter two options are only available on Linux and are envoked by
+invisible window, using OSMesa, or using EGL. The latter two options are only available on Linux and are invoked by
 defining the symbols MJ_OSMESA or MJ_EGL when compiling record.cc. The functions ``initOpenGL`` and ``closeOpenGL``
 create and close the OpenGL context in three different ways depending on which of the above symbols is defined.
 

doc/programming/simulation.rst

@@ -267,7 +267,7 @@ The *physics state* (:ref:`mjSTATE_PHYSICS<mjtState>`) contains the main quantit
 stepping. These are ``mjData.{qpos, qvel, act, history}``:
 
 Position: ``qpos``
-  The configuration in generalized coodinates, denoted in the :ref:`Numerical Integration<geIntegration>` section as
+  The configuration in generalized coordinates, denoted in the :ref:`Numerical Integration<geIntegration>` section as
   :math:`q`.
 
 Velocity: ``qvel``
@@ -322,7 +322,7 @@ Control: ``ctrl``
   Controls are defined by the :ref:`actuator<actuator>` section of the XML. ``mjData.ctrl`` values either produce
   generalized forces directly (stateless actuators), or affect the actuator activations in ``mjData.act``, which then
   produce forces. Note that while all actuators produce forces, the semantics of ``ctrl`` and ``act`` depend on the
-  specifc parameters of the :ref:`actuation model<geActuation>`.
+  specific parameters of the :ref:`actuation model<geActuation>`.
 
 Auxiliary Controls: ``qfrc_applied`` and ``xfrc_applied``
   | ``mjData.qfrc_applied`` are directly applied generalized forces.

doc/programming/visualization.rst

@@ -435,7 +435,7 @@ window buffer size changes whenever the user resizes or maximizes the window. Th
 fixed viewport size. In the code sample :ref:`simulate.cc <saSimulate>` we use a callback which is triggered whenever
 the window size changes, while in :ref:`basic.cc <saBasic>` we simply check the window size every time we render. On
 certain scaled displays (only on OSX it seems) the window size and framebuffer size can be different. So if you are
-getting the size with GLFW functions, use glfwGetFramebuferSize rather than glfwGetWindowSize. On the other hand,
+getting the size with GLFW functions, use glfwGetFramebufferSize rather than glfwGetWindowSize. On the other hand,
 mouse coordinates are returned by the operating system in window rather than framebuffer units; thus the mouse
 interaction functions discussed earlier should use glfwGetWindowSize to obtain the window height needed to normalize
 the mouse displacement data.