Fix typos in MuJoCo documentation.
PiperOrigin-RevId: 656068822 Change-Id: I5ebbb3701148ea4d978a6a1ad3f762ffcc7e57cb
This commit is contained in:
Google DeepMind
committed by
Copybara-Service
Copybara-Service
parent
5ac5cfb618
commit
70d70bc3b7
@@ -323,7 +323,7 @@ frame (``point``) treated as attached to the body, the Jacobian has both transla
|
||||
(``jacr``) components. Passing ``NULL`` for either pointer will skip that part of the computation. Each component is a
|
||||
3-by-nv matrix. Each row of this matrix is the gradient of the corresponding coordinate of the specified point with
|
||||
respect to the degrees-of-freedom. The :ref:`pipeline stages<piStages>` required for Jacobian computations to be
|
||||
consistenst with the current generalized positions ``mjData.qpos`` are :ref:`mj_kinematics` and :ref:`mj_comPos`.
|
||||
consistent with the current generalized positions ``mjData.qpos`` are :ref:`mj_kinematics` and :ref:`mj_comPos`.
|
||||
|
||||
.. _mj_jacBody:
|
||||
|
||||
@@ -1882,7 +1882,7 @@ Twice continuously differentiable sigmoid function using a quintic polynomial:
|
||||
Interaction
|
||||
^^^^^^^^^^^
|
||||
|
||||
These function implement abstract mouse interactions, allowing control over cameras and perturbations. Their use is well
|
||||
These functions implement abstract mouse interactions, allowing control over cameras and perturbations. Their use is well
|
||||
illustrated in :ref:`simulate<saSimulate>`.
|
||||
|
||||
.. _mjv_defaultCamera:
|
||||
@@ -2066,8 +2066,8 @@ an illustration.
|
||||
Visualization
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The functions in this section implement abstract visualization. The results are used by the OpenGL rendered, and can
|
||||
also be used by users wishing to implement their own rendered, or hook up MuJoCo to advanced rendering tools such as
|
||||
The functions in this section implement abstract visualization. The results are used by the OpenGL renderer, and can
|
||||
also be used by users wishing to implement their own renderer, or hook up MuJoCo to advanced rendering tools such as
|
||||
Unity or Unreal Engine. See :ref:`simulate<saSimulate>` for illustration of how to use these functions.
|
||||
|
||||
.. _mjv_defaultOption:
|
||||
|
||||
@@ -180,7 +180,7 @@ frame (``point``) treated as attached to the body, the Jacobian has both transla
|
||||
(``jacr``) components. Passing ``NULL`` for either pointer will skip that part of the computation. Each component is a
|
||||
3-by-nv matrix. Each row of this matrix is the gradient of the corresponding coordinate of the specified point with
|
||||
respect to the degrees-of-freedom. The :ref:`pipeline stages<piStages>` required for Jacobian computations to be
|
||||
consistenst with the current generalized positions ``mjData.qpos`` are :ref:`mj_kinematics` and :ref:`mj_comPos`.
|
||||
consistent with the current generalized positions ``mjData.qpos`` are :ref:`mj_kinematics` and :ref:`mj_comPos`.
|
||||
|
||||
.. _mj_jacBody:
|
||||
|
||||
@@ -270,7 +270,7 @@ bodyexclude=-1 can be used to indicate that all bodies are included.
|
||||
|
||||
.. _Interaction:
|
||||
|
||||
These function implement abstract mouse interactions, allowing control over cameras and perturbations. Their use is well
|
||||
These functions implement abstract mouse interactions, allowing control over cameras and perturbations. Their use is well
|
||||
illustrated in :ref:`simulate<saSimulate>`.
|
||||
|
||||
.. _mjv_select:
|
||||
@@ -283,8 +283,8 @@ an illustration.
|
||||
|
||||
.. _Visualization-api:
|
||||
|
||||
The functions in this section implement abstract visualization. The results are used by the OpenGL rendered, and can
|
||||
also be used by users wishing to implement their own rendered, or hook up MuJoCo to advanced rendering tools such as
|
||||
The functions in this section implement abstract visualization. The results are used by the OpenGL renderer, and can
|
||||
also be used by users wishing to implement their own renderer, or hook up MuJoCo to advanced rendering tools such as
|
||||
Unity or Unreal Engine. See :ref:`simulate<saSimulate>` for illustration of how to use these functions.
|
||||
|
||||
.. _OpenGLrendering:
|
||||
|
||||
@@ -1328,7 +1328,7 @@ representations of the constraint Jacobian and related matrices.
|
||||
**PGS** : Projected Gauss-Seidel method
|
||||
This is the most common algorithm used in physics simulators, and used to be the default in MuJoCo, until we
|
||||
developed the Newton method which appears to be better in every way. PGS uses the dual formulation. Unlike
|
||||
gradient-based method which improve the solution along oblique directions, Gauss-Seidel works on one scalar component
|
||||
gradient-based methods which improve the solution along oblique directions, Gauss-Seidel works on one scalar component
|
||||
at a time, and sets it to its optimal value given the current values of all other components. One sweep of PGS has
|
||||
the computational complexity of one matrix-vector multiplication (although the constants are larger). It has
|
||||
first-order convergence but nevertheless makes rapid progress in a few iterations.
|
||||
|
||||
+2
-2
@@ -1407,7 +1407,7 @@ Using the :ref:`flexcomp<body-flexcomp>` element, we can create flexes from mesh
|
||||
automatically generate all the bodies/vertices and connect them with suitable elements. We can also create grids and
|
||||
other topologies automatically. This machinery makes it easy to create very large flexes, involving thousands or even
|
||||
tens of thousands of bodies, elements and edges. Obviously such simulations will not be fast. Even for medium-sized
|
||||
flexes, pruning of collision pairs and essential. This is why we have developed elaborate methods for pruning
|
||||
flexes, pruning of collision pairs is essential. This is why we have developed elaborate methods for pruning
|
||||
self-collisions; see XML reference.
|
||||
|
||||
In case of 3D flexes made of tetrahedra, it may be useful to examine how the flex is "triangulated" internally. We have
|
||||
@@ -1724,7 +1724,7 @@ better visualize and understand the contact configuration and resulting forces.
|
||||
model by design, since without it the inverse dynamics are not defined. This is discussed in detail in the
|
||||
:ref:`softness and slip<Soft>` clarification. This type of slippage can be addressed in two ways.
|
||||
|
||||
a. Increase the :ref:`impration<option-impratio>` parameter. This will reduce (but not entirely prevent) slow
|
||||
a. Increase the :ref:`impratio<option-impratio>` parameter. This will reduce (but not entirely prevent) slow
|
||||
slippage. Note that high impratio values work well only with :ref:`elliptic cones<option-cone>`.
|
||||
b. Enable the noslip solver by increasing :ref:`noslip_iterations<option-noslip_iterations>` to a positive integer.
|
||||
A small number (1, 2 or 3) is usually sufficient. The noslip post-processing solver will entirely prevent slip,
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ aims to facilitate research and development in robotics, biomechanics, graphics
|
||||
other areas that demand fast and accurate simulation of articulated structures interacting with their environment.
|
||||
Initially developed by Roboti LLC, it was acquired and made `freely available
|
||||
<https://github.com/google-deepmind/mujoco/blob/main/LICENSE>`__ by DeepMind in October 2021, and open sourced in May
|
||||
2022. The MuJoCo codebase is available at the `deepmind/mujoco <https://github.com/google-deepmind/mujoco>`__ repository
|
||||
2022. The MuJoCo codebase is available at the `google-deepmind/mujoco <https://github.com/google-deepmind/mujoco>`__ repository
|
||||
on GitHub.
|
||||
|
||||
MuJoCo is a C/C++ library with a C API, intended for researchers and developers. The runtime simulation module is tuned
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
+1
-1
@@ -328,7 +328,7 @@ ___________________________________
|
||||
|
||||
Roboti’s `MuJoCo plug-in for Unity <https://roboti.us/download.html>`_ steps the simulation in an external Python
|
||||
process, and uses Unity only for rendering. In contrast, our plug-in relies on Unity to step the simulation. It should
|
||||
be possible to use our plug-in while an external process "drives" the simulation, for example by seting ``qpos``,
|
||||
be possible to use our plug-in while an external process "drives" the simulation, for example by setting ``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.
|
||||
|
||||
@@ -57,7 +57,7 @@
|
||||
<site name="weight2" pos="-.013 -.013 .013" size="0.005"/>
|
||||
</body>
|
||||
|
||||
<!-- The gravcomp value of 7.2 is the ratio of air and helium desities at room temperature. -->
|
||||
<!-- The gravcomp value of 7.2 is the ratio of air and helium densities at room temperature. -->
|
||||
<body name="pink" gravcomp="7.2" pos="-.2 .1 .2" childclass="pink">
|
||||
<freejoint />
|
||||
<geom name="pink" type="ellipsoid" size=".11 .11 .15"/>
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
The `mujoco.pid` actuator plugin implements a configurable [PID controller](https://en.wikipedia.org/wiki/Proportional%E2%80%93integral%E2%80%93derivative_controller):
|
||||
|
||||
$$f(t) = K_\text{p} e(t) + K_\text{i} \int_0^t e(\tau) \,\mathrm{d}\tau + K_\text{d} \frac{\mathrm{d}e(t)}{\mathrm{d}t},$$
|
||||
$$f(t) = K_\text{p} e(t) + K_\text{i} \int_0^t e(\tau) \mathrm{d}\tau + K_\text{d} \frac{\mathrm{d}e(t)}{\mathrm{d}t},$$
|
||||
where $e(t) = u(t) - \ell(t)$ is the difference between the control $u$ and the actuator length $\ell$.
|
||||
|
||||
You can use it like:
|
||||
@@ -43,5 +43,5 @@ The available options are:
|
||||
|`kp` | 0 | **P** gain for the controller. |
|
||||
|`ki` | 0 | **I** gain for the controller.<p/>If nonzero, one activation variable will be added to `mjData.act`, containing the current I term (in units of force). |
|
||||
|`kd` | 0 | **D** gain for the controller. |
|
||||
|`imax` | Optional | If specified, the force produced by the I term will be clipped to the range `[-imax, -imax]`. |
|
||||
|`imax` | Optional | If specified, the force produced by the I term will be clipped to the range `[-imax, imax]`. |
|
||||
|`slewmax` | Optional | The maximum rate at which the setpoint for the PID controller can change.<p/>If a bigger change is requested between two timesteps, it will be clipped to the range `[ctrl - slewmax * dt, ctrl + slewmax * dt]`<p/>If specified, one activation variable will be added to `mjData.act` containing the previous value of `ctrl`. |
|
||||
|
||||
Reference in New Issue
Block a user