Fix broken links in the documentation.

PiperOrigin-RevId: 520657874
Change-Id: Idd01c40f87e0f2afcbd2d2bfd98fab95edc2371e

doc/APIreference/APItypes.rst

@@ -337,7 +337,7 @@ These are the possible sensor data types, used in ``mjData.sensor_datatype``.
 Data
 ^^^^
 
-The enums below are defined in `mjmdata.h <https://github.com/deepmind/mujoco/blob/main/include/mujoco/mjmdata.h>`_.
+The enums below are defined in `mjdata.h <https://github.com/deepmind/mujoco/blob/main/include/mujoco/mjdata.h>`_.
 
 
 .. _mjtWarning:

doc/changelog.rst

@@ -830,7 +830,7 @@ General
 #. Fixed: The array of sensors in ``mjCModel`` was not cleared.
 #. Cleaned up cross-platform code (internal changes, not visible via the API).
 #. Fixed a bug in parsing of XML ``texcoord`` data (related to number of vertices).
-#. Fixed a bug in `simulate.cc <https://github.com/deepmind/mujoco/blob/main/sample/simulate.cc>`_ related to ``nkey``
+#. Fixed a bug in `simulate.cc <https://github.com/deepmind/mujoco/blob/main/simulate/simulate.cc>`_ related to ``nkey``
    (the number of keyframes).
 #. Accelerated collision detection in the presence of large numbers of non-colliding geoms (with ``contype==0 and
    conaffinity==0``).

doc/programming/samples.rst

@@ -218,14 +218,3 @@ of unilateral constraints, numerical derivatives are hard to compute and there i
 would not even be defined if it wasn't for our soft-constraint model. Making the constraints softer results in more
 accurate results. This effect is so strong that in some situations it makes sense to intentionally work with the wrong
 model, i.e., a model that is softer than desired, so as to obtain more accurate derivatives.
-
-.. _saUItools:
-
-uitools
-~~~~~~~
-
-`(uitools.h) <https://github.com/deepmind/mujoco/blob/main/simulate/uitools.h>`_ `(uitools.cc)
-<https://github.com/deepmind/mujoco/blob/main/simulate/uitools.cc>`_ This is not a stand-alone code sample, but rather
-a small utility used to hook up the new UI to GLFW. It is used in :ref:`simulate.cc <saSimulate>` and can also be used
-in user projects that involve the new UI. If GLFW is replaced with a different window library, this is the only file
-that would have to be changed in order to access the UI functionality.

doc/unity.rst

@@ -140,7 +140,7 @@ When the user selects an MJCF file, the importer first loads
 the file in MuJoCo, saves it to a temporary location, and then processes the generated saved file.  This has several
 effects:
 
-- It validates the MJCF - we are guaranteed that the saved MJCF matches the `schema <CSchema>`_.
+- It validates the MJCF - we are guaranteed that the saved MJCF matches the :ref:`schema <CSchema>`.
 - It validates the assets (materials, meshes, textures) and imports these assets into Unity, as well as creating new
   material assets for geom RGBA specification.
 - It allows the importer to handle :ref:`\<include\> <include>` elements without replicating MuJoCo’s file-system
@@ -331,4 +331,4 @@ process, and uses Unity only for rendering.  In contrast, our plug-in relies on
 be possible to use our plug-in while an external process "drives" the simulation, for example by seting ``qpos``,
 calling ``mj_kinematics``, synchronizing the transforms, and then using Unity to render or compute game logic. In order
 to establish communication with an external process, you can use Unity's `ML-Agents
-<https://github.com/Unity-Technologies/ml-agents>`_ package.
+<https://github.com/Unity-Technologies/ml-agents>`_ package.