Standardise tags of MJCF elements in XMLreference.rst

PiperOrigin-RevId: 479541059
Change-Id: I98cb7933469f7010870d04608fbb931539769c2e

doc/modeling.rst

@@ -103,14 +103,14 @@ special and is called :el:`worldbody`. This tree organization is in contrast wit
 links and then connects them with joints that specify a child and a parent link. In MJCF the child body is literally a
 child of the parent body, in the sense of XML.
 
-When a :ref:`joint <joint>` is defined inside a body, its function is not to connect the parent and child but rather to
+When a :ref:`joint <body-joint>` is defined inside a body, its function is not to connect the parent and child but rather to
 create motion degrees of freedom between them. If no joints are defined within a given body, that body is welded to its
 parent. A body in MJCF can contain multiple joints, thus there is no need to introduce dummy bodies for creating
 composite joints. Instead simply define all the primitive joints that form the desired composite joint within the same
 body. For example, two sliders and one hinge can be used to model a body moving in a plane.
 
-Other MJCF elements can be defined within the tree created by nested body elements, in particular :ref:`joint <joint>`,
-:ref:`geom <geom>`, :ref:`site <site>`, :ref:`camera <camera>`, :ref:`light <light>`. When an element is defined within
+Other MJCF elements can be defined within the tree created by nested body elements, in particular :ref:`joint <body-joint>`,
+:ref:`geom <body-geom>`, :ref:`site <body-site>`, :ref:`camera <body-camera>`, :ref:`light <body-light>`. When an element is defined within
 a body, it is fixed to the local frame of that body and always moves with it. Elements that refer to multiple bodies, or
 do not refer to bodies at all, are defined in separate sections outside the kinematic tree.
 
@@ -387,7 +387,7 @@ Contact parameters
 
 The parameters of each contact were described in the :ref:`Contact <coContact>` section of the Computation
 chapter. Here we explain how these parameters are set. If the geom pair is explicitly defined with the XML element
-:ref:`pair <pair>`, it has attributes specifying all contact parameters directly. In that case the
+:ref:`pair <contact-pair>`, it has attributes specifying all contact parameters directly. In that case the
 parameters of the individual geoms are ignored. If on the other hand the contact is generated by the dynamic mechanism,
 its parameters need to be inferred from the two geoms in the contact pair. If the two geoms have identical parameters
 there is nothing to do, but what if their parameters are different? In that case we use the geom attributes
@@ -459,7 +459,7 @@ User parameters
 A number of MJCF elements have the optional attribute :at:`user`, which defines a custom element-specific parameter
 array. This interacts with the corresponding "nuser_XXX" attribute of the :ref:`size <size>` element. If for example we
 set :at:`nuser_geom` to 5, then every geom in mjModel will have a custom array of 5 real-valued parameters. These geom-
-specific parameters are either defined in the MJCF file via the :at:`user` attribute of :ref:`geom <geom>`, or set to 0
+specific parameters are either defined in the MJCF file via the :at:`user` attribute of :ref:`geom <body-geom>`, or set to 0
 by the compiler if this attribute is omitted. The default value of all "nuser_XXX" attributes is -1, which instructs the
 compiler to automatically set this value to the length of the maximum associated :at:`user` attribute defined in the
 model. MuJoCo does not use these parameters in any internal computations; instead they are available for custom
@@ -468,7 +468,7 @@ nuser_XXX.
 
 Some element-specific parameters that are normally used in internal computations can also be used in custom
 computations. This is done by installing user callbacks which override parts of the simulation pipeline. For example,
-the :ref:`general <general>` actuator element has attributes :at:`dyntype` and :at:`dynprm`. If
+the :ref:`general <actuator-general>` actuator element has attributes :at:`dyntype` and :at:`dynprm`. If
 :at:`dyntype` is set to "user", then MuJoCo will call :ref:`mjcb_act_dyn` to compute
 the actuator dynamics instead of calling its internal function. The user function pointed to by
 :ref:`mjcb_act_dyn` can interpret the parameters defined in :at:`dynprm` however it
@@ -547,11 +547,11 @@ Actuator shortcuts
 
 As explained in the :ref:`Actuation model <geActuation>` section of the Computation chapter, MuJoCo offers a flexible
 actuator model with transmission, activation dynamics and force generation components that can be specified
-independently. The full functionality can be accessed via the XML element :ref:`general <general>` which allows the user
+independently. The full functionality can be accessed via the XML element :ref:`general <actuator-general>` which allows the user
 to create a variety of custom actuators. In addition, MJCF provides shortcuts for configuring common actuators. This is
-done via the XML elements :ref:`motor <motor>`, :ref:`position <position>`, :ref:`velocity <velocity>`,
-:ref:`intvelocity <intvelocity>`, :ref:`damper<damper>`, :ref:`cylinder<cylinder>`, :ref:`muscle <muscle>`, and
-:ref:`adhesion <adhesion>`. These are *not* separate model elements. Internally MuJoCo supports only one actuator type -
+done via the XML elements :ref:`motor <actuator-motor>`, :ref:`position <actuator-position>`, :ref:`velocity <actuator-velocity>`,
+:ref:`intvelocity <actuator-intvelocity>`, :ref:`damper<actuator-damper>`, :ref:`cylinder<actuator-cylinder>`, :ref:`muscle <actuator-muscle>`, and
+:ref:`adhesion <actuator-adhesion>`. These are *not* separate model elements. Internally MuJoCo supports only one actuator type -
 which is why when an MJCF model is saved all actuators are written as :el:`general`. Shortcuts create general actuators
 implicitly, set their attributes to suitable values, and expose a subset of attributes with possibly different names.
 For example, :el:`position` creates a position servo with attribute :at:`kp` which is the servo gain. However
@@ -582,8 +582,8 @@ Activation clamping
 
 As described in the :ref:`Actuation model <geActuation>` section of the Computation chapter, MuJoCo supports actuators
 with internal dynamics whose states are called "activations". One useful application of these stateful actuators is the
-"integrated-velocity" actuator, implemented by the :ref:`intvelocity<intvelocity>` shortcut. Different from the
-:ref:`pure velocity<velocity>` actuators, which implement direct feedback on transmission target's velocity,
+"integrated-velocity" actuator, implemented by the :ref:`intvelocity<actuator-intvelocity>` shortcut. Different from the
+:ref:`pure velocity<actuator-velocity>` actuators, which implement direct feedback on transmission target's velocity,
 *integrated-velocity* actuators couple an *integrator* with a *position-feedback* actuator. In this case the semantics
 of the activation state are "the target of the position actuator", and the semantics of the control signal are "the
 velocity of the target of the position actuator". Note that in real robotic systems this integrated-velocity actuator is
@@ -694,8 +694,8 @@ adjusting any parameters. Constructing a more detailed model will of course requ
 in this section.
 
 Keep in mind that even though the muscle model is quite elaborate, it is still a type of MuJoCo actuator and obeys the
-same conventions as all other actuators. A muscle can be defined using :ref:`general <general>`, but
-the shortcut :ref:`muscle <muscle>` is more convenient. As with all other actuators, the force
+same conventions as all other actuators. A muscle can be defined using :ref:`general <actuator-general>`, but
+the shortcut :ref:`muscle <actuator-muscle>` is more convenient. As with all other actuators, the force
 production mechanism and the transmission are defined independently. Nevertheless, muscles only make (bio)physical
 sense when attached to tendon or joint transmissions. For concreteness we will assume a tendon transmission here.
 
@@ -757,7 +757,7 @@ muscle-specific constant :math:`F_0` to obtain the actual force:
 
 The negative sign is because positive muscle activation generates pulling force. The constant :math:`F_0` is the peak
 active force at zero velocity. It is related to the muscle thickness (i.e., physiological cross-sectional area or PCSA).
-If known, it can be set with the attribute force of element :ref:`muscle <muscle>`. If it is not known, we set it to
+If known, it can be set with the attribute force of element :ref:`muscle <actuator-muscle>`. If it is not known, we set it to
 :math:`-1` which is the default. In that case we rely on the fact that larger muscles tend to act on joints that move
 more weight. The attribute scale defines this relationship as:
 
@@ -814,7 +814,7 @@ are two time constants specified with the attribute timeconst, namely :math:`\te
       \tau_\text{deact} / (0.5 + 1.5\cdot\texttt{act}) & \texttt{ctrl} \leq \texttt{act}
    \end{cases}
 
-Now we summarize the attributes of element :ref:`muscle <muscle>` which users may want to adjust,
+Now we summarize the attributes of element :ref:`muscle <actuator-muscle>` which users may want to adjust,
 depending on their familiarity with the biomechanics literature and availability of detailed measurements with regard
 to a particular model:
 
@@ -842,7 +842,7 @@ lmin, lmax, vmax, fpmax, fvmax
    change the :math:`\text{\small FLV}` parameters for all muscles, do so in the :ref:`default <default>` element.
 Custom model
    Instead of adjusting the parameters of our muscle model, users can implement a different model, by setting gaintype,
-   biastype and dyntype of a :ref:`general <general>` actuator to "user" and providing callbacks at
+   biastype and dyntype of a :ref:`general <actuator-general>` actuator to "user" and providing callbacks at
    runtime. Or, leave some of these types set to "muscle" and use our model, while replacing the other components. Note
    that tendon geometry computations are still handled by the standard MuJoCo pipeline providing actuator_length,
    actuator_velocity and actuator_lengthrange as inputs to the user's muscle model. Custom callbacks could then simulate
@@ -916,7 +916,7 @@ Composite objects were introduced in MuJoCo 2.0, along with solver optimizations
 objects. They are not new model elements. Instead, they are (large) collections of existing elements designed to
 simulate particle systems, ropes, cloth, and soft bodies. These collections are generated by the model compiler
 automatically. The user configures the automatic generator on a high level, using the new XML element
-:ref:`composite <composite>` and its attributes and sub-elements, as described in the XML reference
+:ref:`composite <body-composite>` and its attributes and sub-elements, as described in the XML reference
 chapter. If the compiled model is then saved, :el:`composite` is no longer present and is replaced with the collection
 of regular model elements that were automatically generated. So think of it as a macro that gets expanded by the model
 compiler.
@@ -935,7 +935,7 @@ of these equality constraints can be adjusted by the user, thereby adjusting the
 composite objects.
 
 In addition to setting up the physics, the composite object generator creates suitable rendering. 2D and 3D objects
-can be rendered as :ref:`skins <skin>` which are also new in MuJoCo 2.0. The skin is generated
+can be rendered as :ref:`skins <asset-skin>` which are also new in MuJoCo 2.0. The skin is generated
 automatically, and can be textured as well as subdivided using bi-cubic interpolation. The actual physics and in
 particular the collision detection are based on the element bodies and their geoms, while the skin is purely a
 visualization object. Yet in most situations we prefer to look at the skin representation. To facilitate this, the
@@ -948,7 +948,7 @@ addition to geoms).
 
 We have designed the composite object generator to have intuitive high-level controls as much as possible, but at the
 same time it exposes a large number of options that interact with each other and can profoundly affect the resulting
-physics. So at some point users should read the :ref:`reference documentation <composite>` carefully.
+physics. So at some point users should read the :ref:`reference documentation <body-composite>` carefully.
 As a quick start though, MuJoCo 2.0 comes with an example of each composite object type. Below we go over these
 examples and explain the less obvious aspects. In all examples we have a static scene which is included in the model,
 followed by a single composite object. The static scene has a mocap body (large capsule) that can be moved around with