chenlin/Mujoco_WASM
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Improve rendering of [state section](https://mujoco.readthedocs.io/en/latest/computation.html?highlight=qfrc_applied#the-state) in documentation.

Browse Source 
PiperOrigin-RevId: 526023870
Change-Id: If650cefa0cc6c22d63e909fb763767a77067af4e
This commit is contained in:
Yuval Tassa
2023-04-21 07:07:48 -07:00
committed by Copybara-Service
parent da17fdfcfd
commit 967b07314f
1 changed files with 42 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/computation.rst
+42 -42
View File
@@ -569,20 +569,20 @@ resetting the state and computing dynamics derivatives are also well-defined. Th
Physics state Physics state
^^^^^^^^^^^^^ ^^^^^^^^^^^^^
| The *physics state* contains all quantities which are time-integrated during stepping. The *physics state* contains all quantities which are time-integrated during stepping.
| They are ``mjData.{qpos, qvel, act, time}``: These are ``mjData.{qpos, qvel, act, time}``:
Mechanical state: ``qpos`` and ``qvel`` Mechanical state: ``qpos`` and ``qvel``
The *mechanical state* of a simulation is given by the generalized position (``mjData.qpos``) and velocity The *mechanical state* of a simulation is given by the generalized position (``mjData.qpos``) and velocity
(``mjData.qvel``) vectors, denoted above as :math:`q` and :math:`v`, respectively. (``mjData.qvel``) vectors, denoted above as :math:`q` and :math:`v`, respectively.
Actuator activations: ``act`` Actuator activations: ``act``
``mjData.act`` contains the internal states of stateful actuators, denoted above as :math:`w`. ``mjData.act`` contains the internal states of stateful actuators, denoted above as :math:`w`.
Time: ``time`` Time: ``time``
The time of the simulation is given by the scalar ``mjData.time``. Since physics is time-invariant, it is The time of the simulation is given by the scalar ``mjData.time``. Since physics is time-invariant, it is
often excluded from the *physics state*; an exception could be a time-dependent user callback (e.g., an open-loop often excluded from the *physics state*; an exception could be a time-dependent user callback (e.g., an open-loop
controller), in which case time should be included. controller), in which case time should be included.
.. _geInput: .. _geInput:
@@ -591,53 +591,53 @@ User inputs
These input fields are set by the user and affect the physics simulation, but are untouched by the simulator. All input These input fields are set by the user and affect the physics simulation, but are untouched by the simulator. All input
fields except for MoCap poses default to 0. fields except for MoCap poses default to 0.
Controls: ``ctrl`` Controls: ``ctrl``
Controls are defined by the :ref:`actuator<actuator>` section of the XML. ``mjData.ctrl`` values either produce 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 generalized forces directly (stateless actuators), or affect the actuator activations in ``mjData.act``, which then
produce forces. produce forces.
Auxillary Controls: ``qfrc_applied`` and ``xfrc_applied`` Auxillary Controls: ``qfrc_applied`` and ``xfrc_applied``
| ``mjData.qfrc_applied`` are directly applied generalized forces. | ``mjData.qfrc_applied`` are directly applied generalized forces.
| ``mjData.xfrc_applied`` are Cartesian wrenches applied to the CoM of individual bodies. This field is used for | ``mjData.xfrc_applied`` are Cartesian wrenches applied to the CoM of individual bodies. This field is used for
example, by the :ref:`native viewer<saSimulate>` to apply mouse perturbations. example, by the :ref:`native viewer<saSimulate>` to apply mouse perturbations.
| Note that the effects of ``qfrc_applied`` and ``xfrc_applied`` can usually be recreated by appropriate actuator | Note that the effects of ``qfrc_applied`` and ``xfrc_applied`` can usually be recreated by appropriate actuator
definitions. definitions.
MoCap poses: ``mocap_pos`` and ``mocap_quat`` MoCap poses: ``mocap_pos`` and ``mocap_quat``
``mjData.mocap_pos`` and ``mjData.mocap_quat`` are special optional kinematic states :ref:`described here<CMocap>`, ``mjData.mocap_pos`` and ``mjData.mocap_quat`` are special optional kinematic states :ref:`described here<CMocap>`,
which allow the user to set the positions and orientations of static bodies in real-time, for example when streaming which allow the user to set the positions and orientations of static bodies in real-time, for example when streaming
6D poses from a motion-capture device. The default values set by :ref:`mj_resetData` are the poses of the bodies at 6D poses from a motion-capture device. The default values set by :ref:`mj_resetData` are the poses of the bodies at
the default configuration. the default configuration.
User data: ``userdata`` User data: ``userdata``
``mjData.userdata`` acts as a user-defined memory space untouched by the engine. For example it can be used by ``mjData.userdata`` acts as a user-defined memory space untouched by the engine. For example it can be used by
callbacks. This is described in more detail in the :ref:`Programming chapter<siSimulation>`. callbacks. This is described in more detail in the :ref:`Programming chapter<siSimulation>`.
.. _geWarmstart: .. _geWarmstart:
Warmstart accelerations Warmstart accelerations
^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
``qacc_warmstart`` ``qacc_warmstart``
``mjData.qacc_warmstart`` are accelerations used to warmstart the constraint solver, saved from the previous step. ``mjData.qacc_warmstart`` are accelerations used to warmstart the constraint solver, saved from the previous step.
When using a slowly-converging :ref:`constraint solver<Solver>` like PGS, these can speed up simulation by reducing When using a slowly-converging :ref:`constraint solver<Solver>` like PGS, these can speed up simulation by reducing
the number of iterations required for convergence. Note however that the default Newton solver converges so quickly the number of iterations required for convergence. Note however that the default Newton solver converges so quickly
(usually 2-3 iterations), that warmstarts often have no effect on speed and can be disabled. (usually 2-3 iterations), that warmstarts often have no effect on speed and can be disabled.
Different warmstarts have no perceptible effect on the dynamics but should be saved if perfect numerical Different warmstarts have no perceptible effect on the dynamics but should be saved if perfect numerical
reproducibility is required when loading a non-initial state. Note that even though their effect on physics is reproducibility is required when loading a non-initial state. Note that even though their effect on physics is
negligible, many physical systems will accumulate small differences `exponentially negligible, many physical systems will accumulate small differences `exponentially
<https://en.wikipedia.org/wiki/Lyapunov_exponent>`__ when time-stepping, quickly leading to divergent trajectories <https://en.wikipedia.org/wiki/Lyapunov_exponent>`__ when time-stepping, quickly leading to divergent trajectories
for different warmstarts. for different warmstarts.
.. _gePlugin: .. _gePlugin:
Plugin state Plugin state
^^^^^^^^^^^^ ^^^^^^^^^^^^
``plugin_state`` ``plugin_state``
``mjData.plugin_state`` are states declared by :ref:`engine plugins<exPlugin>`. Please see the :ref:`exPluginState` ``mjData.plugin_state`` are states declared by :ref:`engine plugins<exPlugin>`. Please see the :ref:`exPluginState`
section for more details. section for more details.
.. _geIntegrationState: .. _geIntegrationState: