diff --git a/doc/APIreference/APItypes.rst b/doc/APIreference/APItypes.rst index 5e854f87..6a61f75c 100644 --- a/doc/APIreference/APItypes.rst +++ b/doc/APIreference/APItypes.rst @@ -18,7 +18,7 @@ MuJoCo defines a large number of types: Note that the API does not use these enum types directly. Instead it uses ints, and the documentation/comments state that certain ints correspond to certain enum types. This is because we want the API to be compiler-independent, and the C standard does not dictate how many bytes must be used to represent an enum type. Nevertheless, for improved - readiblity, we recommend using these types when calling API functions which take them as arguments. + readability, we recommend using these types when calling API functions which take them as arguments. - :ref:`C struct types`. These can be classified as: @@ -806,7 +806,7 @@ Struct types ------------ The three central struct types for physics simulation are :ref:`mjModel`, :ref:`mjOption` (embedded in :ref:`mjModel`) -and :ref:`mjData`. An introductory discussion of these strucures can be found in the :ref:`Overview`. +and :ref:`mjData`. An introductory discussion of these structures can be found in the :ref:`Overview`. .. _mjModel: @@ -1708,7 +1708,7 @@ mjfOpenResource typedef int (*mjfOpenResource)(mjResource* resource); -This callback is for opeing a resource; returns zero on failure. +This callback is for opening a resource; returns zero on failure. .. _mjfReadResource: diff --git a/doc/XMLreference.rst b/doc/XMLreference.rst index 5b5392a9..dfe68cc3 100644 --- a/doc/XMLreference.rst +++ b/doc/XMLreference.rst @@ -1005,7 +1005,7 @@ compilation. This attribute specifies the maximum number of contacts that will be generated at runtime. If the number of active contacts is about to exceed this value, the extra contacts are discarded and a warning is generated. This is a deprecated legacy attribute which prior to version 2.3.0 affected memory allocation. It is kept for backwards - compatibillity and debugging purposes. + compatibility and debugging purposes. .. _size-nstack: @@ -1992,7 +1992,7 @@ attribute and :el:`layer` child elements is an error. - opacity (alpha channel) * - :at:`emissive` - 4 - - RGB light emmision intensity, exposure weight in 4th channel + - RGB light emission intensity, exposure weight in 4th channel * - :at:`orm` - 3 - packed 3 channel [occlusion, roughness, metallic] @@ -3676,7 +3676,7 @@ saving the XML: **direct** allows the user to specify the point and element data of the flexcomp directly in the XML. Note that flexcomp will still generate moving bodies automatically, as well as automate other settings; so it still provides - convenience compared to specifing the corresponding flex directly. + convenience compared to specifying the corresponding flex directly. .. _body-flexcomp-count: @@ -3869,7 +3869,7 @@ multiple times is allowed. .. _flexcomp-pin-id: :at:`id`: :at-val:`int(n), required` - Zero-based ids of points to pin. When the points are automatically-generaged, the user needs to understand their + Zero-based ids of points to pin. When the points are automatically-generated, the user needs to understand their layout in order to decide which points to pin. This can be done by first creating a flexcomp without any pins, loading it in the simulator, and showing the body labels. @@ -4455,7 +4455,7 @@ be clear from the above specification. .. _deformable-skin-face: :at:`face`: :at-val:`int(3*nface), optional` - Trinagular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1. + Triangular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1. .. _deformable-skin-inflate: @@ -6608,7 +6608,7 @@ points (spheres) and the surface normals (arrows). regardless of the ray origin. If this data type is included along with either :at-val:`dist` or :at-val:`point`, normals will be visualized as arrows at the intersection points. - :at-val:`depth`: **real(1)**: The distance of the hit point from the camera plane, -1 if no surface was hit. Note - that this depth sematic corresponds to depth images in the computer graphics sense. + that this depth semantic corresponds to depth images in the computer graphics sense. .. _sensor-rangefinder-name: @@ -7864,7 +7864,7 @@ See :ref:`collision-sensors` for more details about sensors of this type. .. _sensor-distance-cutoff: :at:`cutoff` - See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories. + See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories. If no collision is detected, the distance sensor returns the :at:`cutoff` value, so in this case :at:`cutoff` acts as a maximum clipping value, in addition to the special semantics. @@ -7919,7 +7919,7 @@ See :ref:`collision-sensors` for more details about sensors of this type. .. _sensor-normal-cutoff: :at:`cutoff` - See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories. + See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories. If no collision is detected, the :ref:`normal` sensor returns (0, 0, 0), otherwise it returns a normalized direction vector. For this sensor, :at:`cutoff` does not lead to any clamping. @@ -7975,7 +7975,7 @@ See :ref:`collision-sensors` for more details about sensors of this type. .. _sensor-fromto-cutoff: :at:`cutoff` - See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories. + See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories. If no collision is detected, the :ref:`fromto` sensor returns 6 zeros. For this sensor, :at:`cutoff` does not lead to any clamping. diff --git a/doc/changelog.rst b/doc/changelog.rst index 74178e54..83d80fea 100644 --- a/doc/changelog.rst +++ b/doc/changelog.rst @@ -1095,7 +1095,7 @@ General forces on the joint are treated as applied by actuators. See attribute documentation for more details. The example model `refsite.xml `__, - which demostrates Cartesian actuation of an arm, has been updated to use this attribute. + which demonstrates Cartesian actuation of an arm, has been updated to use this attribute. 3. Added support for gmsh format 2.2 , tetrahedral mesh, as generated by e.g. `fTetwild `__. 4. Added :ref:`mju_euler2Quat` for converting an Euler-angle sequence to quaternion. @@ -2620,7 +2620,7 @@ UI 11. Figure selection type changed from ``int`` to ``float``. #. Figures now show data coordinates, when selection and highlight are enabled. #. Changed ``mjMAXUIMULTI`` to 35, ``mjMAXUITEXT`` to 300, ``mjMAXUIRECT`` to 25. -#. Added collapsable sub-sections, implemented as separators with state: ``mjSEPCLOSED`` collapsed, ``mjSEPCLOSED+1`` +#. Added collapsible sub-sections, implemented as separators with state: ``mjSEPCLOSED`` collapsed, ``mjSEPCLOSED+1`` expanded. #. Added ``mjITEM_RADIOLINE`` item type. #. Added function ``mjui_addToSection`` to simplify UI section construction. diff --git a/doc/computation/fluid.rst b/doc/computation/fluid.rst index 24c259c2..6248a3c3 100644 --- a/doc/computation/fluid.rst +++ b/doc/computation/fluid.rst @@ -72,7 +72,7 @@ body coordinates are g_{V, i} = \quad &- 8 \beta \pi r_{eq}^3 \omega_i \\ \end{aligned} -One can also affect these forces by specifing a non-zero :ref:`wind`, which is a 3D vector subtracted +One can also affect these forces by specifying a non-zero :ref:`wind`, which is a 3D vector subtracted from the body linear velocity in the fluid dynamics computation. .. _flEllipsoid: @@ -357,7 +357,7 @@ of symmetry because under this assumption the kinetic energy greatly simplifies .. math:: 2 \mathcal{T} = m_{A, x} v_x^2 + m_{A, y} v_y^2 + m_{A, z} v_z^2 + - I_{A, x} \omega_x^2 + I_ {A, y} \omega_y^2 + I_{A, y} \omega_z^2 + I_{A, x} \omega_x^2 + I_ {A, y} \omega_y^2 + I_{A, z} \omega_z^2 For convenience we introduce the added-mass vector :math:`\mathbf{m}_A = \{m_{A, x}, m_{A, y}, m_{A, z}\}` and added-moment of @@ -429,7 +429,7 @@ bagheri2016`. See screen capture of the We derive a formula for :math:`\mathbf{f}_\text{D}` based on two surfaces :math:`A^\text{proj}_\mathbf{v}` and :math:`A_\text{max}`. The first, :math:`A^\text{proj}_\mathbf{v}`, is the cylindrical projection of the body onto a plane normal to the velocity :math:`\mathbf{v}`. The second is the maximum projected surface -:math:`A_\text{max} = 4 \pi r_{max} r_{min}`. +:math:`A_\text{max} = \pi r_{max} r_{mid}`. .. math:: \mathbf{f}_\text{D} = - \rho~ \big[ C_{D, \text{blunt}} ~ A^\text{proj}_\mathbf{v} ~ + @@ -541,7 +541,7 @@ onto the surface. The lift force per unit length can be computed with the Kutta :math:`\mathbf{f}_K / L = \rho \Gamma_\text{K} \times \mathbf{v}`. In order to extend the lift force equation to three-dimensional motions, we consider the normal -:math:`\mathbf{n}_{s, \mathbf{v}} = \{\frac{r_y r_z}{r_x}v_x, \frac{r_z r_x}{r_y}v_y, \frac{r_x r_x}{r_z}v_z\}` +:math:`\mathbf{n}_{s, \mathbf{v}} = \{\frac{r_y r_z}{r_x}v_x, \frac{r_z r_x}{r_y}v_y, \frac{r_x r_y}{r_z}v_z\}` to the cross-section of the body which generates the body's projection :math:`A^\text{proj}_\mathbf{v}` onto a plane normal to the velocity given in the :ref:`lemma` above and the corresponding unit vector :math:`\hat{\mathbf{n}}_{s, \mathbf{v}}`. diff --git a/doc/computation/index.rst b/doc/computation/index.rst index 537d9884..7d99ae2a 100644 --- a/doc/computation/index.rst +++ b/doc/computation/index.rst @@ -531,7 +531,7 @@ All three single-step integrators in MuJoCo use the update :eq:`eq_implicit_upda Semi-implicit with implicit joint damping (``Euler``) For this method, :math:`D` only includes derivatives of joint damping. Note that in this case :math:`D` is diagonal and :math:`\widehat{M}` is symmetric, so :math:`L^TL` decomposition (a variant of Cholesky) can be used. This - factorization is stored ``mjData.qLD``. If the model has no joint damping or the + factorization is stored in ``mjData.qH``. If the model has no joint damping or the :ref:`eulerdamp` disable-flag is set, implicit damping is disabled and the semi-implicit update :eq:`eq_semimplicit` is used, rather than :eq:`eq_implicit_update`, avoiding the additional factorization of :math:`\widehat{M}` (*additional* because :math:`M` is already factorized for the acceleration update @@ -579,11 +579,11 @@ Fast implicit-in-velocity (``implicitfast``) step is "just right", but that range is model-dependent. :ref:`integrator` - Summary: The recommended integrator is ``implicitfast`` which usually has the best tradeoff of stabillity and + Summary: The recommended integrator is ``implicitfast`` which usually has the best tradeoff of stability and performance. **Euler**: - Use ``Euler`` for compatibillity with older models. + Use ``Euler`` for compatibility with older models. **implicitfast**: The ``implicitfast`` integrator has similar computational cost to ``Euler``, yet provides increased stability, and is therefore a strict improvement. It is the recommended integrator for most models. @@ -839,14 +839,14 @@ as defined later. The ``condim`` parameter determines the contact type, and has ``condim = 3`` : 3 for elliptic, 4 for pyramidal This is a regular frictional contact, which can generate normal force as well as a tangential friction force opposing - slip. An interpertation of this number is the slope of a surface above which a flat object will begin to slip + slip. An interpretation of this number is the slope of a surface above which a flat object will begin to slip under gravity. ``condim = 4`` : 4 for elliptic, 6 for pyramidal In addition to normal and tangential force, this contact can generate torsional friction torque opposing rotation around the contact normal, corresponding to a torque generated by a contacting surface patch. This is useful for modeling soft fingers, and can substantially improve the stability of simulated grasping. Torsional friction - coefficients have **units of length** which can be interperted as the diameter of the surface contact patch. + coefficients have **units of length** which can be interpreted as the diameter of the surface contact patch. ``condim = 6`` : 6 for elliptic, 10 for pyramidal This contact can oppose motion in all relative degrees of freedom between the two geoms. In particular it adds diff --git a/doc/includes/references.h b/doc/includes/references.h index 9bc868ab..8622ba24 100644 --- a/doc/includes/references.h +++ b/doc/includes/references.h @@ -571,7 +571,7 @@ typedef enum mjtTextureRole_ { // role of texture map in rendering mjTEXROLE_ROUGHNESS, // roughness mjTEXROLE_METALLIC, // metallic mjTEXROLE_NORMAL, // normal (bump) map - mjTEXROLE_OPACITY, // transperancy + mjTEXROLE_OPACITY, // opacity mjTEXROLE_EMISSIVE, // light emission mjTEXROLE_RGBA, // base color, opacity mjTEXROLE_ORM, // occlusion, roughness, metallic diff --git a/doc/modeling.rst b/doc/modeling.rst index cf9b056c..934df664 100644 --- a/doc/modeling.rst +++ b/doc/modeling.rst @@ -495,7 +495,7 @@ are as follows: in mjData.contact actually has all 5 of them, even if condim is less than 6 and not all coefficients are used. In contrast, geoms have only 3 friction coefficients: tangential (same for both axes), torsional, rolling (same for both axes). Each of these 3D vectors of friction coefficients is expanded into a 5D vector of friction coefficients by - replicating the tangetial and rolling components. See the :ref:`Contact` section in the Computation + replicating the tangential and rolling components. See the :ref:`Contact` section in the Computation chapter for an intuitive description of the semantics of tangential, torsional and rolling coefficients. The contact friction coefficients are then computed according to the following rule: if one of the two geoms has @@ -1113,7 +1113,7 @@ Here we describe the XML attributes common to all sensor types, so as to avoid r :at:`noise`: :at-val:`real, "0"` The standard deviation of the noise model of this sensor. In versions prior to 3.1.4, this would lead to noise being added to the sensors. In release 3.1.4 this feature was removed, see :doc:`3.1.4 changelog ` for a - detailed justification. As of subsequent versions, this attrbute serves as a convenient location for saving standard + detailed justification. As of subsequent versions, this attribute serves as a convenient location for saving standard deviation information for later use. .. _sensor-cutoff: @@ -1454,7 +1454,7 @@ that applies to all edges of a given flex, which permits large time steps, or a where each element is in a constant stress state, which is equivalent to piecewise linear finite elements and achieves improved realism and accuracy. The edge-based model could be seen as a "lumped" stiffness model, where the correct coupling of deformation modes (e.g. shear and volumetric) is averaged in a single quantity. The continuum model enables -instead to specify shear and volumetic stiffnesses separately using the `Poisson's ratio +instead to specify shear and volumetric stiffnesses separately using the `Poisson's ratio `__ of the material. For more details, see the `Saint Venant-Kirchhoff `__ hyperelastic model. @@ -1631,7 +1631,7 @@ perfectly (and much better than a spring-damper would) because the constraints a large forces without destabilizing the simulation. But if the hand is forced to make contact with the table for example (right plot) it cannot simultaneously respect the contact constraint and track the mocap body. This is because the mocap body is free to go through the table. So which constraint wins? That depends on the softness of the weld -constraint realtive to the contact constraint. The corresponding :at:`solref` and :at:`solimp` parameters need to be +constraint relative to the contact constraint. The corresponding :at:`solref` and :at:`solimp` parameters need to be adjusted so as to achieve the desired trade-off. See the Modular Prosthetic Limb (MPL) hand model available on the MuJoCo Forum for an example; the plots below are generated with that model. @@ -1735,7 +1735,7 @@ dedicated section :ref:`therein`. - Reduce the number of checked collisions using the :ref:`contype` / :ref:`conaffinity` mechanism described in the - :ref:`Collison detection` section. + :ref:`Collision detection` section. - Modify collision geometries, replacing expensive collision tests (e.g. mesh-mesh) with cheaper primitive-primitive collisions. As a rule of thumb, collisions which have custom pair functions in the collision table at the top of `engine_collision_driver.c `__ @@ -1766,7 +1766,7 @@ better visualize and understand the contact configuration and resulting forces. **Slip-preventing contact forces are outside the friction cone** This implies that the physics cannot prevent slip, even in principle. This occurs when: - a. *The normal force is too small.* Ensure that the maximum force that can be applied by the gripper mutiplied by + a. *The normal force is too small.* Ensure that the maximum force that can be applied by the gripper multiplied by the sliding friction coefficient is significantly greater than the weight of the object. b. *The sliding friction coefficient is too low.* Increase the sliding :ref:`friction` coefficient. @@ -1774,7 +1774,7 @@ better visualize and understand the contact configuration and resulting forces. 4 or 6 and choose appropriate friction coefficients. **condim 4** enables torsional friction, preventing rotation around the normal. **condim 6** also enables rolling friction, preventing rotation around the tangential directions. - See the :ref:`Contact` section for details and the specifc semantics of these coefficients. + See the :ref:`Contact` section for details and the specific semantics of these coefficients. **The geometry does not support the required forces or torques** This is a common real-world problem, solved by improved design of grippers and handles. @@ -1790,7 +1790,7 @@ better visualize and understand the contact configuration and resulting forces. High-frequency, low-amplitude vibrations are also a real-world problem in many industrial settings, but unlike in simulation, in the real world they are audible. Such vibration is often caused by controllers with very high gains and sometimes by stick-slip feedback from contacts or joints, resonating with the eigen-modes of the - mechanism. The easist way to diagnose such vibration is to visualize contact forces in + mechanism. The easiest way to diagnose such vibration is to visualize contact forces in :ref:`simulate`. The solution is usually to reduce the :ref:`timestep` and/or add some :ref:`armature` to the relevant joints. Another reason for vibration is feedback from explicit damping. Use the implicit or implicitfast integrators, as documented in the diff --git a/doc/programming/modeledit.rst b/doc/programming/modeledit.rst index d2fc31c9..1c2851be 100644 --- a/doc/programming/modeledit.rst +++ b/doc/programming/modeledit.rst @@ -160,7 +160,7 @@ or :ref:`attach a frame or an mjSpec to a body`: Note that in the above examples, the parent and child models have different values for ``compiler.degree``, corresponding to the :ref:`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. diff --git a/doc/programming/samples.rst b/doc/programming/samples.rst index 1271de19..263ee833 100644 --- a/doc/programming/samples.rst +++ b/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. diff --git a/doc/programming/simulation.rst b/doc/programming/simulation.rst index c172b785..451f2724 100644 --- a/doc/programming/simulation.rst +++ b/doc/programming/simulation.rst @@ -267,7 +267,7 @@ The *physics state* (:ref:`mjSTATE_PHYSICS`) 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` section as + The configuration in generalized coordinates, denoted in the :ref:`Numerical Integration` section as :math:`q`. Velocity: ``qvel`` @@ -322,7 +322,7 @@ Control: ``ctrl`` Controls are defined by the :ref:`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`. + specific parameters of the :ref:`actuation model`. Auxiliary Controls: ``qfrc_applied`` and ``xfrc_applied`` | ``mjData.qfrc_applied`` are directly applied generalized forces. diff --git a/doc/programming/visualization.rst b/doc/programming/visualization.rst index e8caa12c..70c20a96 100644 --- a/doc/programming/visualization.rst +++ b/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 ` we use a callback which is triggered whenever the window size changes, while in :ref:`basic.cc ` 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. diff --git a/doc/python.rst b/doc/python.rst index 5f43c64a..f3dc0673 100644 --- a/doc/python.rst +++ b/doc/python.rst @@ -922,7 +922,7 @@ custom cameras and lights. The constructor arguments of a ``USDExporter`` instan - ``model``: An MjModel instance. The USD exporter reads relevant information from the model including details about cameras, lights, textures, and object geometries. -- ``max_geom``: Maximum number of geoms in a scene, required when instatiating the internal . +- ``max_geom``: Maximum number of geoms in a scene, required when instantiating the internal . `mjvScene `__. - ``output_directory``: Name of the directory under which the exported USD file and all relevant diff --git a/include/mujoco/mjmodel.h b/include/mujoco/mjmodel.h index 97de5c2f..9fc191db 100644 --- a/include/mujoco/mjmodel.h +++ b/include/mujoco/mjmodel.h @@ -161,7 +161,7 @@ typedef enum mjtTextureRole_ { // role of texture map in rendering mjTEXROLE_ROUGHNESS, // roughness mjTEXROLE_METALLIC, // metallic mjTEXROLE_NORMAL, // normal (bump) map - mjTEXROLE_OPACITY, // transperancy + mjTEXROLE_OPACITY, // opacity mjTEXROLE_EMISSIVE, // light emission mjTEXROLE_RGBA, // base color, opacity mjTEXROLE_ORM, // occlusion, roughness, metallic diff --git a/src/engine/engine_core_constraint.c b/src/engine/engine_core_constraint.c index 982463d7..05fc62fe 100644 --- a/src/engine/engine_core_constraint.c +++ b/src/engine/engine_core_constraint.c @@ -1502,21 +1502,21 @@ void mj_makeImpedance(const mjModel* m, mjData* d) { KBIP[4*(i+j)] = 0; } - // standard: K = 1 / (dmax^2 * timeconst^2 * dampratio^2) + // standard: K = 1 / (d_width^2 * timeconst^2 * dampratio^2) else if (ref[0] > 0) KBIP[4*(i+j)] = 1 / mju_max(mjMINVAL, solimp[1]*solimp[1] * ref[0]*ref[0] * ref[1]*ref[1]); - // direct: K = -solref[0] / dmax^2 + // direct: K = -solref[0] / d_width^2 else { KBIP[4*(i+j)] = -ref[0] / mju_max(mjMINVAL, solimp[1]*solimp[1]); } - // standard: B = 2 / (dmax*timeconst) + // standard: B = 2 / (d_width*timeconst) if (ref[1] > 0) { KBIP[4*(i+j)+1] = 2 / mju_max(mjMINVAL, solimp[1]*ref[0]); } - // direct: B = -solref[1] / dmax + // direct: B = -solref[1] / d_width else { KBIP[4*(i+j)+1] = -ref[1] / mju_max(mjMINVAL, solimp[1]); }