This attribute specifies the scaling that will be applied to the vertex data along each coordinate axis. Negative values are allowed, resulting in flipping the mesh along the corresponding axis. Maximum number of vertices in a mesh's convex hull. Currently this is implemented by asking qhull `to terminate <http://www.qhull.org/html/qh-optt.htm#TAn>`__ after maxhullvert vertices. The default value of -1 means "unlimited". Positive values must be larger than 3. This attribute controls how the mesh is used when mass and inertia are inferred from geometry. The default value is legacy for backward compatibility, but convex is recommended. convex: Use the mesh's convex hull to compute volume and inertia, assuming uniform density. exact: Compute volume and inertia exactly, even for non-convex meshes. This algorithm requires a well-oriented, watertight mesh and will error otherwise. legacy: Use the legacy algorithm, leads to volume overcounting for non-convex meshes. Though currently the default to avoid breakages, it is not recommended. shell: Assume mass is concentrated on the surface of the mesh. Use the mesh's surface to compute the inertia, assuming uniform surface density. Name of the texture, like the texture attribute. Role of the texture. The valid values, expected number of channels, and the role semantics are: :widths: 1 1 8 :header-rows: 1 * - value - channels - description * - rgb - 3 - base color / albedo [red, green, blue] * - normal - 3 - bump map (surface normals) * - occlusion - 1 - ambient occlusion * - roughness - 1 - roughness * - metallic - 1 - metallicity * - opacity - 1 - opacity (alpha channel) * - emissive - 4 - RGB light emission intensity, exposure weight in 4th channel * - orm - 3 - packed 3 channel [occlusion, roughness, metallic] * - rgba - 4 - packed 4 channel [red, green, blue, alpha] If this attribute is specified, the material has a texture associated with it. Referencing the material from a model element will cause the texture to be applied to that element. Note that the value of this attribute is the name of a texture asset, not a texture file name. Textures cannot be loaded in the material definition; instead they must be loaded explicitly via the texture element and then referenced here. The texture referenced here is used for specifying the RGB values. For advanced rendering (e.g., Physics-Based Rendering), more texture types need to be specified (e.g., roughness, metallic). In this case, this texture attribute should be omitted, and the texture types should be specified using layer child elements. Note however that the built-in renderer does not support PBR properties, so these advanced rendering features are only available when using an external renderer. Emission in OpenGL has the RGBA format, however we only provide a scalar setting. The RGB components of the OpenGL emission vector are the RGB components of the material color multiplied by the value specified here. The alpha component is 1. Specularity in OpenGL has the RGBA format, however we only provide a scalar setting. The RGB components of the OpenGL specularity vector are all equal to the value specified here. The alpha component is 1. This value should be in the range [0 1]. Shininess in OpenGL is a number between 0 and 128. The value given here is multiplied by 128 before passing it to OpenGL, so it should be in the range [0 1]. Larger values correspond to tighter specular highlight (thus reducing the overall amount of highlight but making it more salient visually). This interacts with the specularity setting; see OpenGL documentation for details. This attribute should be in the range [0 1]. If the value is greater than 0, and the material is applied to a plane or a box geom, the renderer will simulate reflectance. The larger the value, the stronger the reflectance. For boxes, only the face in the direction of the local +Z axis is reflective. Simulating reflectance properly requires ray-tracing. This renderer uses the stencil buffer and suitable projections instead to approximate it. Only the first reflective geom in the model is rendered as such. This adds one extra rendering pass through all geoms, in addition to the extra rendering pass added by each shadow-casting light. This attribute corresponds to uniform metallicity coefficient applied to the entire material. This attribute has no effect in MuJoCo's native renderer, but it can be useful when rendering scenes with a physically-based renderer. In this case, if a non-negative value is specified, this metallic value should be multiplied by the metallic texture sampled value to obtain the final metallicity of the material. This attribute corresponds to uniform roughness coefficient applied to the entire material. This attribute has no effect in MuJoCo's native renderer, but it can be useful when rendering scenes with a physically-based renderer. In this case, if a non-negative value is specified, this roughness value should be multiplied by the roughness texture sampled value to obtain the final roughness of the material. Color and transparency of the material. All components should be in the range [0 1]. Note that the texture color (if assigned) and the color specified here are multiplied component-wise. Thus the default value of "1 1 1 1" has the effect of leaving the texture unchanged. When the material is applied to a model element which defines its own local rgba attribute, the local definition has precedence. Note that this "local" definition could in fact come from a defaults class. The remaining material properties always apply. This attribute applies to textures of type "2d". It specifies how many times the texture image is repeated, relative to either the object size or the spatial unit, as determined by the next attribute. For cube textures, this attribute controls how cube mapping is applied. The default value "false" means apply cube mapping directly, using the actual size of the object. The value "true" maps the texture to a unit object before scaling it to its actual size (geometric primitives are created by the renderer as unit objects and then scaled). In some cases this leads to more uniform texture appearance, but in general, which settings produces better results depends on the texture and the object. For 2d textures, this attribute interacts with texrepeat above. Let texrepeat be N. The default value "false" means that the 2d texture is repeated N times over the (z-facing side of the) object. The value "true" means that the 2d texture is repeated N times over one spatial unit, regardless of object size. Type of the joint. The keywords have the following meaning: The **free** type creates a free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits. The **ball** type creates a ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed. The **slide** type creates a sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes. The **hinge** type creates a hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. Position of the joint, specified in the frame of the body where the joint is defined. For free joints this attribute is ignored. This attribute specifies the axis of rotation for hinge joints and the direction of translation for slide joints. It is ignored for free and ball joints. The vector specified here is automatically normalized to unit length as long as its length is greater than 10E-14; otherwise a compile error is generated. When both numbers are positive, the compiler will override any stiffness and damping values specified with the attributes below, and will instead set them automatically so that the resulting mass-spring-damper for this joint has the desired time constant (first value) and damping ratio (second value). This is done by taking into account the joint inertia in the model reference configuration. Note that the format is the same as the solref parameter of the constraint solver. This attribute specifies if the joint has limits. It interacts with the range attribute. If this attribute is "false", joint limits are disabled. If this attribute is "true", joint limits are enabled. If this attribute is "auto", and autolimits is set in compiler, joint limits will be enabled if range is defined. This attribute specifies whether actuator forces acting on the joint should be clamped. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. This attribute interacts with the actuatorfrcrange attribute. If this attribute is "false", actuator force clamping is disabled. If it is "true", actuator force clamping is enabled. If this attribute is "auto", and autolimits is set in compiler, actuator force clamping will be enabled if actuatorfrcrange is defined. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating dry friction. See also Friction. Constraint solver parameters for simulating dry friction. See also Friction. Joint stiffness coefficients a, b, c. A positive a produces the standard restorative linear spring force f = -a x, where x is the joint displacement from equilibrium given by springref. If the optional second and third components are set, they define a nonlinear polynomial spring force f(x) = -(a x + b x^2 + c x^3). See Polynomial forces for details. The joint limits. Limits can be imposed on all joint types except for free joints. For hinge and ball joints, the range is specified in degrees or radians depending on the angle attribute of compiler. For ball joints, the limit is imposed on the angle of rotation (relative to the reference configuration) regardless of the axis of rotation. Only the second range parameter is used for ball joints; the first range parameter should be set to 0. See the Limit section in the Computation chapter for more information. Setting this attribute without specifying limited is an error if autolimits is "false" in compiler. Range for clamping total actuator forces acting on this joint. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. The compiler expects the first value to be smaller than the second value. Setting this attribute without specifying actuatorfrclimited is an error if compiler-autolimits is "false". If this flag is enabled, gravity compensation applied to this joint is added to actuator forces (mjData.qfrc_actuator) rather than passive forces (mjData.qfrc_passive). Notionally, this means that gravity compensation is the result of a control system rather than natural buoyancy. In practice, enabling this flag is useful when joint-level actuator force clamping is used. In this case, the total actuation force applied on a joint, including gravity compensation, is guaranteed to not exceed the specified limits. See CForceRange and actuatorfrcrange for more details on this type of force limit. The distance threshold below which limits become active. Recall that the Constraint solver normally generates forces as soon as a constraint becomes active, even if the margin parameter makes that happen at a distance. This attribute together with solreflimit and solimplimit can be used to model a soft joint limit. The reference position or angle of the joint. This attribute is only used for slide and hinge joints. It defines the joint value corresponding to the initial model configuration. Note that the initial configuration itself is unmodified, only the value of the joint at this configuration. The amount of spatial transformation that the joint applies at runtime equals the current joint value stored in mjData.qpos minus this reference value stored in mjModel.qpos0. The meaning of these vectors is discussed in the Kinematic tree section in the Overview chapter. The joint position or angle in which the joint spring (if any) achieves equilibrium. Similar to the vector mjModel.qpos0 which stores all joint reference values specified with the ref attribute above, all spring reference values specified with this attribute are stored in the vector mjModel.qpos_spring. The model configuration corresponding to mjModel.qpos_spring is also used to compute the spring reference lengths of all tendons, stored in mjModel.tendon_lengthspring. This is because tendons can also have springs. Additional inertia associated with movement of the joint that is not due to body mass. This added inertia is usually due to a rotor (a.k.a `armature <https://en.wikipedia.org/wiki/Armature_(electrical)>`__) spinning faster than the joint itself due to a geared transmission. In the illustration, we compare (*left*) a 2-dof system with an armature body (purple box), coupled with a gear ratio of 3 to the pendulum using a joint equality constraint, and (*right*) a simple 1-dof pendulum with an equivalent armature. Because the gear ratio appears twice, multiplying both forces and lengths, the effect is known as "reflected inertia" and the equivalent value is the inertia of the spinning body multiplied by the *square of the gear ratio*, in this case 9=3^2. The value applies to all degrees of freedom created by this joint. Besides increasing the realism of joints with geared transmission, positive armature significantly improves simulation stability, even for small values, and is a recommended possible fix when encountering stability issues. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v, where v is the joint velocity. Despite its simplicity, larger damping values can make numerical integrators unstable, which is why our Euler integrator handles damping implicitly. See Integration in the Computation chapter. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Friction loss due to dry friction. This value is the same for all degrees of freedom created by this joint. Semantically friction loss does not make sense for free joints, but the compiler allows it. To enable friction loss, set this attribute to a positive value. See CUser. Type of geometric shape. The keywords have the following meaning: The **plane** type defines a surface which is infinite for collision detection purposes. It can only be attached to the world body or static children of the world. The plane passes through a point specified via the pos attribute. It is normal to the Z axis of the geom's local frame. The +Z direction corresponds to empty space. Thus the position and orientation defaults of (0,0,0) and (1,0,0,0) would create a ground plane at Z=0 elevation, with +Z being the vertical direction in the world (which is MuJoCo's convention). Since the plane is infinite, it could have been defined using any other point in the plane. The specified position however has additional meaning with regard to rendering. If either of the first two size parameters are positive, the plane is rendered as a rectangle of finite size (in the positive dimensions). This rectangle is centered at the specified position. Three size parameters are required. The first two specify the half- size of the rectangle along the X and Y axes. The third size parameter is unusual: it specifies the spacing between the grid subdivisions of the plane for rendering purposes. The subdivisions are revealed in wireframe rendering mode, but in general they should not be used to paint a grid over the ground plane (textures should be used for that purpose). Instead their role is to improve lighting and shadows, similar to the subdivisions used to render boxes. When planes are viewed from the back, the are automatically made semi-transparent. Planes and the +Z faces of boxes are the only surfaces that can show reflections, if the material applied to the geom has positive reflection. To render an infinite plane, set the first two size parameters to zero. The **hfield** type defines a height field geom. The geom must reference the desired height field asset with the hfield attribute below. The position and orientation of the geom set the position and orientation of the height field. The size of the geom is ignored, and the size parameters of the height field asset are used instead. See the description of the hfield element. Similar to planes, height field geoms can only be attached to the world body or to static children of the world. The **sphere** type defines a sphere. This and the next four types correspond to built-in geometric primitives. These primitives are treated as analytic surfaces for collision detection purposes, in many cases relying on custom pair- wise collision routines. Models including only planes, spheres, capsules and boxes are the most efficient in terms of collision detection. Other geom types invoke the general-purpose convex collider. The sphere is centered at the geom's position. Only one size parameter is used, specifying the radius of the sphere. Rendering of geometric primitives is done with automatically generated meshes whose density can be adjusted via quality. The sphere mesh is triangulated along the lines of latitude and longitude, with the Z axis passing through the north and south pole. This can be useful in wireframe mode for visualizing frame orientation. The **capsule** type defines a capsule, which is a cylinder capped with two half-spheres. It is oriented along the Z axis of the geom's frame. When the geom frame is specified in the usual way, two size parameters are required: the radius of the capsule followed by the half-height of the cylinder part. However capsules as well as cylinders can also be thought of as connectors, allowing an alternative specification with the fromto attribute below. In that case only one size parameter is required, namely the radius of the capsule. The **ellipsoid** type defines a ellipsoid. This is a sphere scaled separately along the X, Y and Z axes of the local frame. It requires three size parameters, corresponding to the three radii. Note that even though ellipsoids are smooth, their collisions are handled via the general-purpose convex collider. The only exception are plane-ellipsoid collisions which are computed analytically. The **cylinder** type defines a cylinder. It requires two size parameters: the radius and half-height of the cylinder. The cylinder is oriented along the Z axis of the geom's frame. It can alternatively be specified with the fromto attribute below. The **box** type defines a box. Three size parameters are required, corresponding to the half-sizes of the box along the X, Y and Z axes of the geom's frame. Note that box-box collisions can generate up to 8 contact points. The **mesh** type defines a mesh. The geom must reference the desired mesh asset with the mesh attribute. Note that mesh assets can also be referenced from other geom types, causing primitive shapes to be fitted; see below. The size is determined by the mesh asset and the geom size parameters are ignored. Unlike all other geoms, the position and orientation of mesh geoms after compilation do not equal the settings of the corresponding attributes here. Instead they are offset by the translation and rotation that were needed to center and align the mesh asset in its own coordinate frame. Recall the discussion of centering and alignment in the mesh element. The **sdf** type defines a signed distance field (SDF, also referred to as signed distance function). In order to visualize the SDF, a custom mesh must be specified using the mesh/plugin attribute. See the `model/plugin/sdf/ <https://github.com/google-deepmind/mujoco/tree/main/model/plugin/sdf>`__ directory for example models with SDF geometries. For more details regarding SDF plugins, see the Extensions chapter. Position of the geom, specified in the frame of the body where the geom is defined. Orientation of the geom frame. See COrientation. This attribute and the next specify 32-bit integer bitmasks used for contact filtering of dynamically generated contact pairs. See Collision in the Computation chapter. Two geoms can collide if the contype of one geom is compatible with the conaffinity of the other geom or vice versa. Compatible means that the two bitmasks have a common bit set to 1. Bitmask for contact filtering; see contype above. The dimensionality of the contact space for a dynamically generated contact pair is set to the maximum of the condim values of the two participating geoms. See coContact in the Computation chapter. The allowed values and their meaning are: +--------+----------------------------------------------------------------------------------------------------------+ | condim | Description | +========+==========================================================================================================+ | 1 | Frictionless contact. | +--------+----------------------------------------------------------------------------------------------------------+ | 3 | Regular frictional contact, opposing slip in the tangent plane. | +--------+----------------------------------------------------------------------------------------------------------+ | 4 | Frictional contact, opposing slip in the tangent plane and rotation around the contact normal. This is | | | useful for modeling soft contacts (independent of contact penetration). | +--------+----------------------------------------------------------------------------------------------------------+ | 6 | Frictional contact, opposing slip in the tangent plane, rotation around the contact normal and rotation | | | around the two axes of the tangent plane. The latter frictional effects are useful for preventing | | | objects from indefinite rolling. | +--------+----------------------------------------------------------------------------------------------------------+ This attribute specifies an integer group to which the geom belongs. The only effect on the physics is at compile time, when body masses and inertias are inferred from geoms selected based on their group; see inertiagrouprange attribute of compiler. At runtime this attribute is used by the visualizer to enable and disable the rendering of entire geom groups. By default, groups 0, 1 and 2 are visible, while all other groups are invisible. The group attribute can also be used as a tag for custom computations. The geom priority determines how the properties of two colliding geoms are combined to form the properties of the contact. This interacts with the solmix attribute. See CContact. Geom size parameters. The number of required parameters and their meaning depends on the geom type as documented under the type attribute. Here we only provide a summary. All required size parameters must be positive; the internal defaults correspond to invalid settings. Note that when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh. In that case the sizes are obtained from the mesh, and the geom size parameters are ignored. Thus the number and description of required size parameters in the table below only apply to geoms that do not reference meshes. +---------+--------+------------------------------------------------------------------------------------------------+ | Type | Number | Description | +=========+========+================================================================================================+ | plane | 3 | X half-size; Y half-size; spacing between square grid lines for rendering. If either the X or Y| | | | half-size is 0, the plane is rendered as infinite in the dimension(s) with 0 size. | +---------+--------+------------------------------------------------------------------------------------------------+ | hfield | 0 | The geom sizes are ignored and the height field sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ | sphere | 1 | Radius of the sphere. | +---------+--------+------------------------------------------------------------------------------------------------+ | capsule | 1 or 2 | Radius of the capsule; half-length of the cylinder part when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ 3 | X radius; Y radius; Z radius. | +---------+--------+------------------------------------------------------------------------------------------------+ |cylinder | 1 or 2 | Radius of the cylinder; half-length of the cylinder when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ | box | 3 | X half-size; Y half-size; Z half-size. | +---------+--------+------------------------------------------------------------------------------------------------+ | mesh | 0 | The geom sizes are ignored and the mesh sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ If specified, this attribute applies a material to the geom. Otherwise, if unspecified and the type of the geom is a **mesh** the compiler will apply the mesh asset material if present. The material determines the visual properties of the geom. The only exception is color: if the rgba attribute below is different from its internal default, it takes precedence while the remaining material properties are still applied. Note that if the same material is referenced from multiple geoms (as well as sites and tendons) and the user changes some of its properties at runtime, these changes will take effect immediately for all model elements referencing the material. This is because the compiler saves the material and its properties as a separate element in mjModel, and the elements using this material only keep a reference to it. Contact friction parameters for dynamically generated contact pairs. The first number is the sliding friction, acting along both axes of the tangent plane. The second number is the torsional friction, acting around the contact normal. The third number is the rolling friction, acting around both axes of the tangent plane. The friction parameters for the contact pair are combined depending on the solmix and priority attributes, as explained in Contact parameters. See the general Contact section for descriptions of the semantics of this attribute. If this attribute is specified, the density attribute below is ignored and the geom density is computed from the given mass, using the geom shape and the assumption of uniform density. The computed density is then used to obtain the geom inertia. Recall that the geom mass and inertia are only used during compilation, to infer the body mass and inertia if necessary. At runtime only the body inertial properties affect the simulation; the geom mass and inertia are not saved in mjModel. Material density used to compute the geom mass and inertia. The computation is based on the geom shape and the assumption of uniform density. The internal default of 1000 is the density of water in SI units. This attribute is used only when the mass attribute above is unspecified. If `shellinertia` is "false" (the default), density has semantics of mass/volume; if "true", it has semantics of mass/area. If true, the geom's inertia is computed assuming that all the mass is concentrated on the surface. In this case density is interpreted as surface rather than volumetric density. This attribute only applies to primitive geoms and is ignored for meshes. Surface inertia for meshes can be specified by setting the asset/mesh/inertia attribute to "shell". This attribute specifies the weight used for averaging of contact parameters, and interacts with the priority attribute. See CContact. Constraint solver parameters for contact simulation. See CSolver. Constraint solver parameters for contact simulation. See CSolver. Distance threshold below which contacts are detected and included in the global array mjData.contact. This however does not mean that contact force will be generated. A contact is considered active only if the distance between the two geom surfaces is below margin-gap. Recall that constraint impedance can be a function of distance, as explained in CSolver. The quantity this function is applied to is the distance between the two geoms minus the margin plus the gap. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. :width: 350px :align: right This attribute can only be used with capsule, box, cylinder and ellipsoid geoms. It provides an alternative specification of the geom length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the geom connects these two points, with the +Z axis of the geom's frame oriented from the first towards the second point, while in the perpendicular direction, the geom sizes are both equal to the first value of the size attribute. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the end points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. The image on the right demonstrates use of fromto with the four supported geoms, using identical Z values. The model is `here <_static/fromto.xml>`__. Note that the fromto semantics of *capsule* are unique: the two end points specify the segment around which the radius defines the capsule surface. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. This attribute must be specified if and only if the geom type is "hfield". It references the height field asset to be instantiated at the position and orientation of the geom frame. If the geom type is "mesh", this attribute is required. It references the mesh asset to be instantiated. This attribute can also be specified if the geom type corresponds to a geometric primitive, namely one of "sphere", "capsule", "cylinder", "ellipsoid", "box". In that case the primitive is automatically fitted to the mesh asset referenced here. The fitting procedure uses either the equivalent inertia box or the axis-aligned bounding box of the mesh, as determined by the attribute fitaabb of compiler. The resulting size of the fitted geom is usually what one would expect, but if not, it can be further adjusted with the fitscale attribute below. In the compiled mjModel the geom is represented as a regular geom of the specified primitive type, and there is no reference to the mesh used for fitting. This attribute is used only when a primitive geometric type is being fitted to a mesh asset. The scale specified here is relative to the output of the automated fitting procedure. The default value of 1 leaves the result unchanged, a value of 2 makes all sizes of the fitted geom two times larger. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. "ellipsoid" activates the geom-level fluid interaction model based on an ellipsoidal approximation of the geom shape. When active, the model based on body inertia sizes is disabled for the body in which the geom is defined. See section on ellipsoid-based fluid interaction model for details. Dimensionless coefficients of fluid interaction model, as follows. See section on ellipsoid-based fluid interaction model for details. See CUser. Type of geometric shape. This is used for rendering, and also determines the active sensor zone for touch sensors. Integer group to which the site belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of sites. Position of the site frame. Orientation of the site frame. See COrientation. Material used to specify the visual properties of the site. Sizes of the geometric shape representing the site. This attribute can only be used with capsule, cylinder, ellipsoid and box sites. It provides an alternative specification of the site length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the site connects these two points, with the +Z axis of the site's frame oriented from the first towards the second point. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the two points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Color and transparency. If this value is different from the internal default, it overrides the corresponding material properties. See CUser. Whether the camera uses a perspective (the default) or orthographic projection. Setting this attribute to "orthographic" changes the semantic of the fovy attribute, see below. Vertical field-of-view of the camera. If the camera uses a perspective projection, the field-of-view is expressed in degrees, regardless of the global compiler/angle setting. If the camera uses an orthographic projection, the field-of-view is expressed in units of length; note that in this case the default of 45 is too large for most scenes and should likely be reduced. In either case, the horizontal field of view is computed automatically given the window size and the vertical field of view. Inter-pupilary distance. This attribute only has an effect during stereoscopic rendering. It specifies the distance between the left and right viewpoints. Each viewpoint is shifted by +/- half of the distance specified here, along the X axis of the camera frame. Resolution of the camera in pixels [width height]. Note that these values are not used for rendering since those dimensions are determined by the size of the rendering context. This attribute serves as a convenient location to save the required resolution. Setting either value larger than 1 enables frustum visualization when the mjVIS_CAMERA visualization flag is active. Types of output images supported by the camera. - rgb: RGB image. - depth: Depth image (distance from camera plane). - distance: Distance image (distance from camera origin). - normal: Surface normal image. - segmentation: Segmentation image. This attribute is not used for rendering, but serves as a convenient location to save the output types supported by the camera. The output attribute can contain multiple types, e.g. "rgb normal". Position of the camera frame. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. This attribute specifies how the camera position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the camera sees). "fixed" means that the position and orientation specified below are fixed relative to the body where the camera is defined. "track" means that the camera position is at a constant offset from the body in world coordinates, while the camera orientation is constant in world coordinates. These constants are determined by applying forward kinematics in qpos0 and treating the camera as fixed. Tracking can be used for example to position a camera above a body, point it down so it sees the body, and have it always remain above the body no matter how the body translates and rotates. "trackcom" is similar to "track" but the constant spatial offset is defined relative to the center of mass of the kinematic subtree starting at the body in which the camera is defined. This can be used to keep an entire mechanism in view. Note that the subtree center of mass for the world body is the center of mass of the entire model. So if a camera is defined in the world body in mode "trackcom", it will track the entire model. "targetbody" means that the camera position is fixed in the body frame, while the camera orientation is adjusted so that it always points towards the targeted body (which is specified with the target attribute below). This can be used for example to model an eye that fixates a moving object; the object will be the target, and the camera/eye will be defined in the body corresponding to the head. "targetbodycom" is the same as "targetbody" but the camera is oriented towards the center of mass of the subtree starting at the target body. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Size of the camera sensor in length units. When specified, all intrinsic attributes become active and fovy is ignored. The field-of-view is then computed automatically from the focal length and sensor size. See CUser. Position of the light. This attribute only affects the rendering for spotlights, but it should also be defined for directional lights because we render the cameras as decorative elements. Direction of the light. The radius of the light source which can affect shadow softness depending on the renderer. This only applies to spotlights. The intensity of the light source, measured in candela, used for physically-based lighting models. This is unused by the default Phong lighting model. The effective range of the light. Objects further than this distance from the light position will not be illuminated by this light. This only applies to spotlights. This is a deprecated legacy attribute. Please use light type instead. If set to "true", and no type is specified, this will change the light type to be directional. Determines the type of light. Note that some light types may not be supported by some renderers (e.g. only spot and directional lights are supported by the default native renderer). If this attribute is "true" the light will cast shadows. More precisely, the geoms illuminated by the light will cast shadows, however this is a property of lights rather than geoms. Since each shadow-casting light causes one extra rendering pass through all geoms, this attribute should be used with caution. Higher quality of the shadows is achieved by increasing the value of the shadowsize attribute of quality, as well as positioning spotlights closer to the surface on which shadows appear, and limiting the volume in which shadows are cast. For spotlights this volume is a cone, whose angle is the cutoff attribute below multiplied by the shadowscale attribute of map. For directional lights this volume is a box, whose half-sizes in the directions orthogonal to the light are the model extent multiplied by the shadowclip attribute of map. The model extent is computed by the compiler but can also be overridden by specifying the extent attribute of statistic. Internally the shadow-mapping mechanism renders the scene from the light viewpoint (as if it were a camera) into a depth texture, and then renders again from the camera viewpoint, using the depth texture to create shadows. The internal rendering pass uses the same near and far clipping planes as regular rendering, i.e., these clipping planes bound the cone or box shadow volume in the light direction. As a result, some shadows (especially those very close to the light) may be clipped. The light is active if this attribute is "true". This can be used at runtime to turn lights on and off. These are the constant, linear and quadratic attenuation coefficients for Phong lighting. The default corresponds to no attenuation. Cutoff angle for spotlights, always in degrees regardless of the global angle setting. Exponent for spotlights. This setting controls the softness of the spotlight cutoff. The ambient color of the light, used by the default Phong lighting model. The color of the light. For the Phong (default) lighting model, this defines the diffuse color of the light. The specular color of the light, used by the default Phong lighting model. This is identical to the mode attribute of camera above. It specifies the how the light position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the light illuminates). The dimensionality of the contacts generated by this geom pair. The friction coefficients of the contacts generated by this geom pair. Making the first two coefficients different results in anisotropic tangential friction. Making the last two coefficients different results in anisotropic rolling friction. The length of this array is not enforced by the parser, and can be smaller than 5. This is because some of the coefficients may not be used, depending on the contact dimensionality. Unspecified coefficients remain equal to their defaults. Constraint solver parameters for contact simulation. See CSolver. Contact reference acceleration, in the friction dimensions. This attribute has the same semantics as other solref attributes (described in CSolver), with two important distictions: - The default "0 0" means "use the same values as solref". - This attribute only takes effect for elliptic friction cones, since pyramidal cones mix normal and frictional forces. Note that as with other solreffriction attributes, the constraint violation is identically 0. Therefore, when using positive semantics solreffriction[1] is ignored, while for negative semantics solreffriction[0] is ignored. See Friction for more details. Constraint solver parameters for contact simulation. See CSolver. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. Distance threshold below which contacts are detected and included in the global array mjData.contact. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". If true, the internal state (activation) associated with this actuator is automatically clamped to actrange at runtime. If false, activation clamping is disabled. If "auto" and autolimits is set in compiler, activation clamping will automatically be set to true if actrange is defined without explicitly setting this attribute to "true". See the Activation clamping section for more details. Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range for clamping the activation state. The first value must be no greater than the second value. See the Activation clamping section for more details. Setting this attribute without specifying actlimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Dimension of the activation state. The default value of -1 instructs the compiler to set the dimension according to the dyntype. Values larger than 1 are only allowed for user-defined activation dynamics, as native types require dimensions of only 0 or 1. For activation dimensions bigger than 1, the *last element* is used to generate force. Activation dynamics type for the actuator. The available dynamics types were already described in the Actuation model section. Repeating that description in somewhat different notation (corresponding to the mjModel and mjData fields involved) we have: =========== ====================================== Keyword Description =========== ====================================== none No internal state integrator act_dot = ctrl filter act_dot = (ctrl - act) / dynprm[0] filterexact Like filter but with exact integration muscle act_dot = mju_muscleDynamics(...) user act_dot = mjcb_act_dyn(...) =========== ====================================== The gain and bias together determine the output of the force generation mechanism, which is currently assumed to be affine. As already explained in Actuation model, the general formula is: scalar_force = gain_term \* (act or ctrl) + bias_term. The formula uses the activation state when present, and the control otherwise. The keywords have the following meaning: ======= =============================== Keyword Description ======= =============================== fixed gain_term = gainprm[0] affine gain_term = gain_prm[0] + gain_prm[1]*length + gain_prm[2]*velocity muscle gain_term = mju_muscleGain(...) user gain_term = mjcb_act_gain(...) ======= =============================== The keywords have the following meaning: ======= ================================================================ Keyword Description ======= ================================================================ none bias_term = 0 affine bias_term = biasprm[0] + biasprm[1]*length + biasprm[2]*velocity muscle bias_term = mju_muscleBias(...) user bias_term = mjcb_act_bias(...) ======= ================================================================ Activation dynamics parameters. The built-in activation types (except for muscle) use only the first parameter, but we provide additional parameters in case user callbacks implement a more elaborate model. The length of this array is not enforced by the parser, so the user can enter as many parameters as needed. These defaults are not compatible with muscle actuators; see muscle below. Gain parameters. The built-in gain types (except for muscle) use only the first parameter, but we provide additional parameters in case user callbacks implement a more elaborate model. The length of this array is not enforced by the parser, so the user can enter as many parameters as needed. These defaults are not compatible with muscle actuators; see muscle below. Bias parameters. The affine bias type uses three parameters. The length of this array is not enforced by the parser, so the user can enter as many parameters as needed. These defaults are not compatible with muscle actuators; see muscle below. If true, force computation will use the next value of the activation variable rather than the current one. Setting this flag reduces the delay between the control and accelerations by one time-step. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Automatically set the actuator's ctrlrange to match the transmission target's range. The default value means "disabled". A positive value X sets the ctrlrange around the midpoint of the target range, scaled by X. For example if the target joint has range of [0, 1], then a value of 1.0 will set ctrlrange to [0, 1]; values of 0.8 and 1.2 will set the ctrlrange to [0.1, 0.9] and [-0.1, 1.1], respectively. Values smaller than 1 are useful for not hitting the limits; values larger than 1 are useful for maintaining control authority at the limits (being able to push on them). This attribute is exclusive with ctrlrange and available only for joint and tendon transmissions which have range defined. Note that while inheritrange is available both as a position attribute and in the default class, saved XMLs always convert it to explicit ctrlrange at the actuator. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Position feedback gain. Damping applied by the actuator. When using this attribute, it is recommended to use the implicitfast or implicit integrators. Damping applied by the actuator, using damping ratio units. This attribute is exclusive with kv and has similar meaning, but instead of units of force/velocity, the units are 2 \sqrt{k_p \cdot m}, corresponding to a harmonic oscillator's `damping ratio <https://en.wikipedia.org/wiki/Damping#Damping_ratio_definition>`__. A value of 1 corresponds to a *critically damped* oscillator, which often produces desirable behavior. Values smaller or larger than 1 correspond to underdamped and overdamped oscillations, respectively. The mass m is computed at the reference configuration mjModel.qpos0, taking into account joint armature. However, passive damping or frictionloss in the affected joints are not taken into account; if they are non-negligible, dampratio values smaller than 1 might be required to achieve desirable motion. When using this attribute, it is recommended to use the implicitfast or implicit integrators. Time-constant of optional first-order filter. If larger than zero, the actuator uses the filterexact dynamics type, if zero (the default) no filter is used. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Velocity feedback gain. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range for clamping the activation state. The first value must be no greater than the second value. See the Activation clamping section for more details. Setting this attribute without specifying actlimited is an error if autolimits is "false" in compiler. Identical to position/inheritrange, but sets actrange (which has the same length semantics as the transmission target) rather than ctrlrange (which has velocity semantics). This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Position feedback gain. Damping applied by the actuator. When using this attribute, it is recommended to use the implicitfast or implicit integrators. See position/dampratio. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Velocity feedback gain. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Time constant of the activation dynamics. Area of the cylinder. This is used internally as actuator gain. Instead of area the user can specify diameter. If both are specified, diameter has precedence. Bias parameters, copied internally into biasprm. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Time constants for activation and de-activation dynamics. Operating length range of the muscle, in units of L0. Peak active force at rest. If this value is negative, the peak force is determined automatically using the scale attribute below. If the force attribute is negative, the peak active force for the muscle is set to this value divided by mjModel.actuator_acc0. The latter is the norm of the joint-space acceleration vector caused by unit force on the actuator's transmission in qpos0. In other words, scaling produces higher peak forces for muscles that pull more weight. Lower position range of the normalized FLV curve, in units of L0. Upper position range of the normalized FLV curve, in units of L0. Shortening velocity at which muscle force drops to zero, in units of L0 per second. Passive force generated at lmax, relative to the peak rest force. Active force generated at saturating lengthening velocity, relative to the peak rest force. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Gain of the adhesion actuator, in units of force. The total adhesion force applied by the actuator is the control value multiplied by the gain. This force is distributed equally between all the contacts involving geoms belonging to the target body. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. Motor constants, defined as motorconst = "Kt Ke" (N·m/A, equivalently V·s/rad). Kt is the torque constant and Ke the back-EMF constant; they can differ when magnetic saturation is present. If both are positive, the effective constant is K = \sqrt{K_t K_e} (geometric mean). If only one is positive, K equals that value. If a datasheet specifies the speed constant K_v in rad/(V·s), use K_e = 1/K_v. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1 and 2.1) Terminal resistance R in Ohm. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1 and 2.1) Nominal operating point, defined as nominal = "voltage stall_torque no_load_speed". The compiler derives K = voltage / no_load_speed and R = K · voltage / stall_torque. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1 and 2.1) Limits on the actuator, defined as saturation = "torque current current_rate". torque and current are alternative specifications of the maximum continuous torque: if current is given, torque = K \cdot current; if both are given, torque takes precedence. Sets forcerange to [-\tau_{\max},\, \tau_{\max}]. current_rate sets the maximum rate of change of current (di/dt)_{\max} (requires inductance). A value of 0 (the default) for any sub-value disables the respective limit. (see `tech note <_static/dcmotor.pdf>`__, Section 2) Electrical dynamics, defined as inductance = "L timeconst" (Henry, seconds). These are alternative specifications: L is the winding inductance and timeconst = L/R is the electrical time constant. Specify one; if both are given, L takes precedence. If both are 0 (the default), no electrical dynamics are modeled and the current is computed algebraically. Adds one activation variable for armature current. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1.1 and 2.2) Cogging torque, defined as cogging = "amplitude poles phase" (N·m, integer, rad). Adds a position-dependent torque = \textsf{amplitude} \cdot \sin(\textsf{poles} \cdot \theta + \textsf{phase}). Disabled when amplitude = 0 (the default). (see `tech note <_static/dcmotor.pdf>`__, Sections 1.2 and 2.1) PID controller parameters, defined as controller = "kp ki kd slewmax Imax Vmax". Depending on the input mode, the controller stabilizes either position or velocity. If the input mode is voltage, kp, ki, kd are ignored. Vmax sets the maximum drive voltage v_{\max} (Volt); in position/velocity modes it clamps the controller output, in voltage mode it clamps the control signal (if ctrlrange is also set, the tighter limit wins). A value of 0 (the default) disables the respective feature. When positive, slewmax limits the setpoint rate-of-change, Imax clamps the integrator state (anti-windup), and Vmax clamps the drive voltage. (see `tech note <_static/dcmotor.pdf>`__, Section 2.5) Specifies the input signal semantics. In "voltage" mode, the control directly sets applied motor voltage. In "position" or "velocity" modes, the PID controller uses the control as a reference setpoint relative to the joint trajectory. (see `tech note <_static/dcmotor.pdf>`__, Section 2.5) Thermal model, defined as thermal = "resistance capacitance timeconst tempcoef reftemp ambient" (K/W, J/K, s, 1/K, °C, °C). The first three sub-values specify the thermal time constant: timeconst = resistance \times capacitance. Specify either timeconst directly, or resistance and capacitance; if all three are given, timeconst takes precedence. If all are 0 (the default), thermal modeling is disabled. Adds one activation variable for winding temperature. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.3 and 2.3) LuGre friction, defined as lugre = "stiffness damping coulomb static stribeck" (N·m/rad, N·m·s/rad, N·m, N·m, rad/s). Disabled when stiffness = 0 (the default). Adds one activation variable for bristle deflection. Note that the viscous damping coefficient \sigma_2 is not part of the lugre attribute and should be added to the standard actuator damping attribute. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.4 and 2.4) The name of the defaults class. It must be unique among all defaults classes. This name is used to make the class active when creating an actual model element. Position of the inertial frame. This attribute is required even when the inertial properties can be inferred from geoms. This is because the presence of the inertial element itself disables the automatic inference mechanism. Orientation of the inertial frame. See COrientation. Mass of the body. Negative values are not allowed. MuJoCo requires the inertia matrix in generalized coordinates to be positive-definite, which can sometimes be achieved even if some bodies have zero mass. In general however there is no reason to use massless bodies. Such bodies are often used in other engines to bypass the limitation that joints cannot be combined, or to attach sensors and cameras. In MuJoCo primitive joint types can be combined, and we have sites which are a more efficient attachment mechanism. Diagonal inertia matrix, expressing the body inertia relative to the inertial frame. If this attribute is omitted, the next attribute becomes required. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Full inertia matrix M. Since M is 3-by-3 and symmetric, it is specified using only 6 numbers in the following order: M(1,1), M(2,2), M(3,3), M(1,2), M(1,3), M(2,3). The compiler computes the eigenvalue decomposition of M and sets the frame orientation and diagonal inertia accordingly. If non-positive eigenvalues are encountered (i.e., if M is not positive definite) a compile error is generated. Name of the joint. Defaults class for setting unspecified attributes. Type of the joint. The keywords have the following meaning: The **free** type creates a free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits. The **ball** type creates a ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed. The **slide** type creates a sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes. The **hinge** type creates a hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. Position of the joint, specified in the frame of the body where the joint is defined. For free joints this attribute is ignored. This attribute specifies the axis of rotation for hinge joints and the direction of translation for slide joints. It is ignored for free and ball joints. The vector specified here is automatically normalized to unit length as long as its length is greater than 10E-14; otherwise a compile error is generated. When both numbers are positive, the compiler will override any stiffness and damping values specified with the attributes below, and will instead set them automatically so that the resulting mass-spring-damper for this joint has the desired time constant (first value) and damping ratio (second value). This is done by taking into account the joint inertia in the model reference configuration. Note that the format is the same as the solref parameter of the constraint solver. This attribute specifies if the joint has limits. It interacts with the range attribute. If this attribute is "false", joint limits are disabled. If this attribute is "true", joint limits are enabled. If this attribute is "auto", and autolimits is set in compiler, joint limits will be enabled if range is defined. This attribute specifies whether actuator forces acting on the joint should be clamped. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. This attribute interacts with the actuatorfrcrange attribute. If this attribute is "false", actuator force clamping is disabled. If it is "true", actuator force clamping is enabled. If this attribute is "auto", and autolimits is set in compiler, actuator force clamping will be enabled if actuatorfrcrange is defined. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating dry friction. See also Friction. Constraint solver parameters for simulating dry friction. See also Friction. Joint stiffness coefficients a, b, c. A positive a produces the standard restorative linear spring force f = -a x, where x is the joint displacement from equilibrium given by springref. If the optional second and third components are set, they define a nonlinear polynomial spring force f(x) = -(a x + b x^2 + c x^3). See Polynomial forces for details. The joint limits. Limits can be imposed on all joint types except for free joints. For hinge and ball joints, the range is specified in degrees or radians depending on the angle attribute of compiler. For ball joints, the limit is imposed on the angle of rotation (relative to the reference configuration) regardless of the axis of rotation. Only the second range parameter is used for ball joints; the first range parameter should be set to 0. See the Limit section in the Computation chapter for more information. Setting this attribute without specifying limited is an error if autolimits is "false" in compiler. Range for clamping total actuator forces acting on this joint. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. The compiler expects the first value to be smaller than the second value. Setting this attribute without specifying actuatorfrclimited is an error if compiler-autolimits is "false". If this flag is enabled, gravity compensation applied to this joint is added to actuator forces (mjData.qfrc_actuator) rather than passive forces (mjData.qfrc_passive). Notionally, this means that gravity compensation is the result of a control system rather than natural buoyancy. In practice, enabling this flag is useful when joint-level actuator force clamping is used. In this case, the total actuation force applied on a joint, including gravity compensation, is guaranteed to not exceed the specified limits. See CForceRange and actuatorfrcrange for more details on this type of force limit. The distance threshold below which limits become active. Recall that the Constraint solver normally generates forces as soon as a constraint becomes active, even if the margin parameter makes that happen at a distance. This attribute together with solreflimit and solimplimit can be used to model a soft joint limit. The reference position or angle of the joint. This attribute is only used for slide and hinge joints. It defines the joint value corresponding to the initial model configuration. Note that the initial configuration itself is unmodified, only the value of the joint at this configuration. The amount of spatial transformation that the joint applies at runtime equals the current joint value stored in mjData.qpos minus this reference value stored in mjModel.qpos0. The meaning of these vectors is discussed in the Kinematic tree section in the Overview chapter. The joint position or angle in which the joint spring (if any) achieves equilibrium. Similar to the vector mjModel.qpos0 which stores all joint reference values specified with the ref attribute above, all spring reference values specified with this attribute are stored in the vector mjModel.qpos_spring. The model configuration corresponding to mjModel.qpos_spring is also used to compute the spring reference lengths of all tendons, stored in mjModel.tendon_lengthspring. This is because tendons can also have springs. Additional inertia associated with movement of the joint that is not due to body mass. This added inertia is usually due to a rotor (a.k.a `armature <https://en.wikipedia.org/wiki/Armature_(electrical)>`__) spinning faster than the joint itself due to a geared transmission. In the illustration, we compare (*left*) a 2-dof system with an armature body (purple box), coupled with a gear ratio of 3 to the pendulum using a joint equality constraint, and (*right*) a simple 1-dof pendulum with an equivalent armature. Because the gear ratio appears twice, multiplying both forces and lengths, the effect is known as "reflected inertia" and the equivalent value is the inertia of the spinning body multiplied by the *square of the gear ratio*, in this case 9=3^2. The value applies to all degrees of freedom created by this joint. Besides increasing the realism of joints with geared transmission, positive armature significantly improves simulation stability, even for small values, and is a recommended possible fix when encountering stability issues. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v, where v is the joint velocity. Despite its simplicity, larger damping values can make numerical integrators unstable, which is why our Euler integrator handles damping implicitly. See Integration in the Computation chapter. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Friction loss due to dry friction. This value is the same for all degrees of freedom created by this joint. Semantically friction loss does not make sense for free joints, but the compiler allows it. To enable friction loss, set this attribute to a positive value. See CUser. Name of the joint. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. When set to true, the body frame and free joint will automatically be aligned with inertial frame. When set to false, no alignment will occur. When set to auto, the compiler's alignfree global attribute will be respected. Inertial frame alignment is an optimization only applies to bodies with a free joint and no child bodies ("simple free bodies"). The alignment diagonalizes the 6x6 inertia matrix and minimizes bias forces, leading to faster and more stable simulation. While this behaviour is a strict improvement, it modifies the semantics of the free joint, making qpos and qvel values saved in older versions (for example, in keyframes) invalid. Note that the align attribute is never saved to XML. Instead, the pose of simple free bodies and their children will be modified such that the body frame and inertial frame are aligned. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. Name of the geom. Defaults class for setting unspecified attributes. Type of geometric shape. The keywords have the following meaning: The **plane** type defines a surface which is infinite for collision detection purposes. It can only be attached to the world body or static children of the world. The plane passes through a point specified via the pos attribute. It is normal to the Z axis of the geom's local frame. The +Z direction corresponds to empty space. Thus the position and orientation defaults of (0,0,0) and (1,0,0,0) would create a ground plane at Z=0 elevation, with +Z being the vertical direction in the world (which is MuJoCo's convention). Since the plane is infinite, it could have been defined using any other point in the plane. The specified position however has additional meaning with regard to rendering. If either of the first two size parameters are positive, the plane is rendered as a rectangle of finite size (in the positive dimensions). This rectangle is centered at the specified position. Three size parameters are required. The first two specify the half- size of the rectangle along the X and Y axes. The third size parameter is unusual: it specifies the spacing between the grid subdivisions of the plane for rendering purposes. The subdivisions are revealed in wireframe rendering mode, but in general they should not be used to paint a grid over the ground plane (textures should be used for that purpose). Instead their role is to improve lighting and shadows, similar to the subdivisions used to render boxes. When planes are viewed from the back, the are automatically made semi-transparent. Planes and the +Z faces of boxes are the only surfaces that can show reflections, if the material applied to the geom has positive reflection. To render an infinite plane, set the first two size parameters to zero. The **hfield** type defines a height field geom. The geom must reference the desired height field asset with the hfield attribute below. The position and orientation of the geom set the position and orientation of the height field. The size of the geom is ignored, and the size parameters of the height field asset are used instead. See the description of the hfield element. Similar to planes, height field geoms can only be attached to the world body or to static children of the world. The **sphere** type defines a sphere. This and the next four types correspond to built-in geometric primitives. These primitives are treated as analytic surfaces for collision detection purposes, in many cases relying on custom pair- wise collision routines. Models including only planes, spheres, capsules and boxes are the most efficient in terms of collision detection. Other geom types invoke the general-purpose convex collider. The sphere is centered at the geom's position. Only one size parameter is used, specifying the radius of the sphere. Rendering of geometric primitives is done with automatically generated meshes whose density can be adjusted via quality. The sphere mesh is triangulated along the lines of latitude and longitude, with the Z axis passing through the north and south pole. This can be useful in wireframe mode for visualizing frame orientation. The **capsule** type defines a capsule, which is a cylinder capped with two half-spheres. It is oriented along the Z axis of the geom's frame. When the geom frame is specified in the usual way, two size parameters are required: the radius of the capsule followed by the half-height of the cylinder part. However capsules as well as cylinders can also be thought of as connectors, allowing an alternative specification with the fromto attribute below. In that case only one size parameter is required, namely the radius of the capsule. The **ellipsoid** type defines a ellipsoid. This is a sphere scaled separately along the X, Y and Z axes of the local frame. It requires three size parameters, corresponding to the three radii. Note that even though ellipsoids are smooth, their collisions are handled via the general-purpose convex collider. The only exception are plane-ellipsoid collisions which are computed analytically. The **cylinder** type defines a cylinder. It requires two size parameters: the radius and half-height of the cylinder. The cylinder is oriented along the Z axis of the geom's frame. It can alternatively be specified with the fromto attribute below. The **box** type defines a box. Three size parameters are required, corresponding to the half-sizes of the box along the X, Y and Z axes of the geom's frame. Note that box-box collisions can generate up to 8 contact points. The **mesh** type defines a mesh. The geom must reference the desired mesh asset with the mesh attribute. Note that mesh assets can also be referenced from other geom types, causing primitive shapes to be fitted; see below. The size is determined by the mesh asset and the geom size parameters are ignored. Unlike all other geoms, the position and orientation of mesh geoms after compilation do not equal the settings of the corresponding attributes here. Instead they are offset by the translation and rotation that were needed to center and align the mesh asset in its own coordinate frame. Recall the discussion of centering and alignment in the mesh element. The **sdf** type defines a signed distance field (SDF, also referred to as signed distance function). In order to visualize the SDF, a custom mesh must be specified using the mesh/plugin attribute. See the `model/plugin/sdf/ <https://github.com/google-deepmind/mujoco/tree/main/model/plugin/sdf>`__ directory for example models with SDF geometries. For more details regarding SDF plugins, see the Extensions chapter. This attribute and the next specify 32-bit integer bitmasks used for contact filtering of dynamically generated contact pairs. See Collision in the Computation chapter. Two geoms can collide if the contype of one geom is compatible with the conaffinity of the other geom or vice versa. Compatible means that the two bitmasks have a common bit set to 1. Bitmask for contact filtering; see contype above. The dimensionality of the contact space for a dynamically generated contact pair is set to the maximum of the condim values of the two participating geoms. See coContact in the Computation chapter. The allowed values and their meaning are: +--------+----------------------------------------------------------------------------------------------------------+ | condim | Description | +========+==========================================================================================================+ | 1 | Frictionless contact. | +--------+----------------------------------------------------------------------------------------------------------+ | 3 | Regular frictional contact, opposing slip in the tangent plane. | +--------+----------------------------------------------------------------------------------------------------------+ | 4 | Frictional contact, opposing slip in the tangent plane and rotation around the contact normal. This is | | | useful for modeling soft contacts (independent of contact penetration). | +--------+----------------------------------------------------------------------------------------------------------+ | 6 | Frictional contact, opposing slip in the tangent plane, rotation around the contact normal and rotation | | | around the two axes of the tangent plane. The latter frictional effects are useful for preventing | | | objects from indefinite rolling. | +--------+----------------------------------------------------------------------------------------------------------+ This attribute specifies an integer group to which the geom belongs. The only effect on the physics is at compile time, when body masses and inertias are inferred from geoms selected based on their group; see inertiagrouprange attribute of compiler. At runtime this attribute is used by the visualizer to enable and disable the rendering of entire geom groups. By default, groups 0, 1 and 2 are visible, while all other groups are invisible. The group attribute can also be used as a tag for custom computations. The geom priority determines how the properties of two colliding geoms are combined to form the properties of the contact. This interacts with the solmix attribute. See CContact. Geom size parameters. The number of required parameters and their meaning depends on the geom type as documented under the type attribute. Here we only provide a summary. All required size parameters must be positive; the internal defaults correspond to invalid settings. Note that when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh. In that case the sizes are obtained from the mesh, and the geom size parameters are ignored. Thus the number and description of required size parameters in the table below only apply to geoms that do not reference meshes. +---------+--------+------------------------------------------------------------------------------------------------+ | Type | Number | Description | +=========+========+================================================================================================+ | plane | 3 | X half-size; Y half-size; spacing between square grid lines for rendering. If either the X or Y| | | | half-size is 0, the plane is rendered as infinite in the dimension(s) with 0 size. | +---------+--------+------------------------------------------------------------------------------------------------+ | hfield | 0 | The geom sizes are ignored and the height field sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ | sphere | 1 | Radius of the sphere. | +---------+--------+------------------------------------------------------------------------------------------------+ | capsule | 1 or 2 | Radius of the capsule; half-length of the cylinder part when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ 3 | X radius; Y radius; Z radius. | +---------+--------+------------------------------------------------------------------------------------------------+ |cylinder | 1 or 2 | Radius of the cylinder; half-length of the cylinder when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ | box | 3 | X half-size; Y half-size; Z half-size. | +---------+--------+------------------------------------------------------------------------------------------------+ | mesh | 0 | The geom sizes are ignored and the mesh sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ If specified, this attribute applies a material to the geom. Otherwise, if unspecified and the type of the geom is a **mesh** the compiler will apply the mesh asset material if present. The material determines the visual properties of the geom. The only exception is color: if the rgba attribute below is different from its internal default, it takes precedence while the remaining material properties are still applied. Note that if the same material is referenced from multiple geoms (as well as sites and tendons) and the user changes some of its properties at runtime, these changes will take effect immediately for all model elements referencing the material. This is because the compiler saves the material and its properties as a separate element in mjModel, and the elements using this material only keep a reference to it. Contact friction parameters for dynamically generated contact pairs. The first number is the sliding friction, acting along both axes of the tangent plane. The second number is the torsional friction, acting around the contact normal. The third number is the rolling friction, acting around both axes of the tangent plane. The friction parameters for the contact pair are combined depending on the solmix and priority attributes, as explained in Contact parameters. See the general Contact section for descriptions of the semantics of this attribute. If this attribute is specified, the density attribute below is ignored and the geom density is computed from the given mass, using the geom shape and the assumption of uniform density. The computed density is then used to obtain the geom inertia. Recall that the geom mass and inertia are only used during compilation, to infer the body mass and inertia if necessary. At runtime only the body inertial properties affect the simulation; the geom mass and inertia are not saved in mjModel. Material density used to compute the geom mass and inertia. The computation is based on the geom shape and the assumption of uniform density. The internal default of 1000 is the density of water in SI units. This attribute is used only when the mass attribute above is unspecified. If `shellinertia` is "false" (the default), density has semantics of mass/volume; if "true", it has semantics of mass/area. If true, the geom's inertia is computed assuming that all the mass is concentrated on the surface. In this case density is interpreted as surface rather than volumetric density. This attribute only applies to primitive geoms and is ignored for meshes. Surface inertia for meshes can be specified by setting the asset/mesh/inertia attribute to "shell". This attribute specifies the weight used for averaging of contact parameters, and interacts with the priority attribute. See CContact. Constraint solver parameters for contact simulation. See CSolver. Constraint solver parameters for contact simulation. See CSolver. Distance threshold below which contacts are detected and included in the global array mjData.contact. This however does not mean that contact force will be generated. A contact is considered active only if the distance between the two geom surfaces is below margin-gap. Recall that constraint impedance can be a function of distance, as explained in CSolver. The quantity this function is applied to is the distance between the two geoms minus the margin plus the gap. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. :width: 350px :align: right This attribute can only be used with capsule, box, cylinder and ellipsoid geoms. It provides an alternative specification of the geom length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the geom connects these two points, with the +Z axis of the geom's frame oriented from the first towards the second point, while in the perpendicular direction, the geom sizes are both equal to the first value of the size attribute. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the end points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. The image on the right demonstrates use of fromto with the four supported geoms, using identical Z values. The model is `here <_static/fromto.xml>`__. Note that the fromto semantics of *capsule* are unique: the two end points specify the segment around which the radius defines the capsule surface. Position of the geom, specified in the frame of the body where the geom is defined. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. This attribute must be specified if and only if the geom type is "hfield". It references the height field asset to be instantiated at the position and orientation of the geom frame. If the geom type is "mesh", this attribute is required. It references the mesh asset to be instantiated. This attribute can also be specified if the geom type corresponds to a geometric primitive, namely one of "sphere", "capsule", "cylinder", "ellipsoid", "box". In that case the primitive is automatically fitted to the mesh asset referenced here. The fitting procedure uses either the equivalent inertia box or the axis-aligned bounding box of the mesh, as determined by the attribute fitaabb of compiler. The resulting size of the fitted geom is usually what one would expect, but if not, it can be further adjusted with the fitscale attribute below. In the compiled mjModel the geom is represented as a regular geom of the specified primitive type, and there is no reference to the mesh used for fitting. This attribute is used only when a primitive geometric type is being fitted to a mesh asset. The scale specified here is relative to the output of the automated fitting procedure. The default value of 1 leaves the result unchanged, a value of 2 makes all sizes of the fitted geom two times larger. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. "ellipsoid" activates the geom-level fluid interaction model based on an ellipsoidal approximation of the geom shape. When active, the model based on body inertia sizes is disabled for the body in which the geom is defined. See section on ellipsoid-based fluid interaction model for details. Dimensionless coefficients of fluid interaction model, as follows. See section on ellipsoid-based fluid interaction model for details. See CUser. The sub-model from which to attach a subtree. Name of the body in the sub-model to attach here. The body and its subtree will be attached. If this attribute is not specified, the contents of the world body will be attached in a new frame. Prefix to prepend to names of elements in the sub-model. This attribute is required to prevent name collisions with the parent or when attaching the same sub-tree multiple times. Name of the site. Defaults class for setting unspecified attributes. Type of geometric shape. This is used for rendering, and also determines the active sensor zone for touch sensors. Integer group to which the site belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of sites. Position of the site frame. Orientation of the site frame. See COrientation. Material used to specify the visual properties of the site. Sizes of the geometric shape representing the site. This attribute can only be used with capsule, cylinder, ellipsoid and box sites. It provides an alternative specification of the site length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the site connects these two points, with the +Z axis of the site's frame oriented from the first towards the second point. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the two points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Color and transparency. If this value is different from the internal default, it overrides the corresponding material properties. See CUser. Name of the camera. Defaults class for setting unspecified attributes. Whether the camera uses a perspective (the default) or orthographic projection. Setting this attribute to "orthographic" changes the semantic of the fovy attribute, see below. Vertical field-of-view of the camera. If the camera uses a perspective projection, the field-of-view is expressed in degrees, regardless of the global compiler/angle setting. If the camera uses an orthographic projection, the field-of-view is expressed in units of length; note that in this case the default of 45 is too large for most scenes and should likely be reduced. In either case, the horizontal field of view is computed automatically given the window size and the vertical field of view. Inter-pupilary distance. This attribute only has an effect during stereoscopic rendering. It specifies the distance between the left and right viewpoints. Each viewpoint is shifted by +/- half of the distance specified here, along the X axis of the camera frame. Resolution of the camera in pixels [width height]. Note that these values are not used for rendering since those dimensions are determined by the size of the rendering context. This attribute serves as a convenient location to save the required resolution. Setting either value larger than 1 enables frustum visualization when the mjVIS_CAMERA visualization flag is active. Types of output images supported by the camera. - rgb: RGB image. - depth: Depth image (distance from camera plane). - distance: Distance image (distance from camera origin). - normal: Surface normal image. - segmentation: Segmentation image. This attribute is not used for rendering, but serves as a convenient location to save the output types supported by the camera. The output attribute can contain multiple types, e.g. "rgb normal". Position of the camera frame. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. This attribute specifies how the camera position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the camera sees). "fixed" means that the position and orientation specified below are fixed relative to the body where the camera is defined. "track" means that the camera position is at a constant offset from the body in world coordinates, while the camera orientation is constant in world coordinates. These constants are determined by applying forward kinematics in qpos0 and treating the camera as fixed. Tracking can be used for example to position a camera above a body, point it down so it sees the body, and have it always remain above the body no matter how the body translates and rotates. "trackcom" is similar to "track" but the constant spatial offset is defined relative to the center of mass of the kinematic subtree starting at the body in which the camera is defined. This can be used to keep an entire mechanism in view. Note that the subtree center of mass for the world body is the center of mass of the entire model. So if a camera is defined in the world body in mode "trackcom", it will track the entire model. "targetbody" means that the camera position is fixed in the body frame, while the camera orientation is adjusted so that it always points towards the targeted body (which is specified with the target attribute below). This can be used for example to model an eye that fixates a moving object; the object will be the target, and the camera/eye will be defined in the body corresponding to the head. "targetbodycom" is the same as "targetbody" but the camera is oriented towards the center of mass of the subtree starting at the target body. When the camera mode is "targetbody" or "targetbodycom", this attribute becomes required. It specifies which body should be targeted by the camera. In all other modes this attribute is ignored. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Size of the camera sensor in length units. When specified, all intrinsic attributes become active and fovy is ignored. The field-of-view is then computed automatically from the focal length and sensor size. See CUser. Name of the light. Defaults class for setting unspecified attributes. This is a deprecated legacy attribute. Please use light type instead. If set to "true", and no type is specified, this will change the light type to be directional. Determines the type of light. Note that some light types may not be supported by some renderers (e.g. only spot and directional lights are supported by the default native renderer). If this attribute is "true" the light will cast shadows. More precisely, the geoms illuminated by the light will cast shadows, however this is a property of lights rather than geoms. Since each shadow-casting light causes one extra rendering pass through all geoms, this attribute should be used with caution. Higher quality of the shadows is achieved by increasing the value of the shadowsize attribute of quality, as well as positioning spotlights closer to the surface on which shadows appear, and limiting the volume in which shadows are cast. For spotlights this volume is a cone, whose angle is the cutoff attribute below multiplied by the shadowscale attribute of map. For directional lights this volume is a box, whose half-sizes in the directions orthogonal to the light are the model extent multiplied by the shadowclip attribute of map. The model extent is computed by the compiler but can also be overridden by specifying the extent attribute of statistic. Internally the shadow-mapping mechanism renders the scene from the light viewpoint (as if it were a camera) into a depth texture, and then renders again from the camera viewpoint, using the depth texture to create shadows. The internal rendering pass uses the same near and far clipping planes as regular rendering, i.e., these clipping planes bound the cone or box shadow volume in the light direction. As a result, some shadows (especially those very close to the light) may be clipped. The light is active if this attribute is "true". This can be used at runtime to turn lights on and off. Position of the light. This attribute only affects the rendering for spotlights, but it should also be defined for directional lights because we render the cameras as decorative elements. Direction of the light. The radius of the light source which can affect shadow softness depending on the renderer. This only applies to spotlights. The intensity of the light source, measured in candela, used for physically-based lighting models. This is unused by the default Phong lighting model. The effective range of the light. Objects further than this distance from the light position will not be illuminated by this light. This only applies to spotlights. These are the constant, linear and quadratic attenuation coefficients for Phong lighting. The default corresponds to no attenuation. Cutoff angle for spotlights, always in degrees regardless of the global angle setting. Exponent for spotlights. This setting controls the softness of the spotlight cutoff. The ambient color of the light, used by the default Phong lighting model. The color of the light. For the Phong (default) lighting model, this defines the diffuse color of the light. The specular color of the light, used by the default Phong lighting model. This is identical to the mode attribute of camera above. It specifies the how the light position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the light illuminates). This is identical to the target attribute of camera above. It specifies which body should be targeted in "targetbody" and "targetbodycom" modes. The texture to use for image-based lighting. This is unused by the default Phong lighting model. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. The joint kind here is orthogonal to the joint type in the rest of MJCF. The joint kind refers to the function of the joint within the mechanism comprising the composite body, while the joint type (hinge or slide) is implied by the joint kind and composite body type. The **main** kind corresponds to the main joints forming each composite type. These joints are automatically included in the model even if the joint sub-element is missing. The main joints are 3D sliders for particle and grid; 1D sliders for box, cylinder and rope; universal joints for cloth, rope and loop. Even though the main joints are included automatically, this sub-element is still useful for adjusting their attributes. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. Joint stiffness coefficients a, b, c. A positive a produces the standard restorative linear spring force f = -a x, where x is the joint displacement from equilibrium given by springref. If the optional second and third components are set, they define a nonlinear polynomial spring force f(x) = -(a x + b x^2 + c x^3). See Polynomial forces for details. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v, where v is the joint velocity. Despite its simplicity, larger damping values can make numerical integrators unstable, which is why our Euler integrator handles damping implicitly. See Integration in the Computation chapter. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Additional inertia associated with movement of the joint that is not due to body mass. This added inertia is usually due to a rotor (a.k.a `armature <https://en.wikipedia.org/wiki/Armature_(electrical)>`__) spinning faster than the joint itself due to a geared transmission. In the illustration, we compare (*left*) a 2-dof system with an armature body (purple box), coupled with a gear ratio of 3 to the pendulum using a joint equality constraint, and (*right*) a simple 1-dof pendulum with an equivalent armature. Because the gear ratio appears twice, multiplying both forces and lengths, the effect is known as "reflected inertia" and the equivalent value is the inertia of the spinning body multiplied by the *square of the gear ratio*, in this case 9=3^2. The value applies to all degrees of freedom created by this joint. Besides increasing the realism of joints with geared transmission, positive armature significantly improves simulation stability, even for small values, and is a recommended possible fix when encountering stability issues. These are the solref and solimp attributes used to equality-constrain the joint. Whether or not a given joint is quality-constrained depends on the joint kind and composite object type as explained above. For joints that are not equality-constrained, this attribute has no effect. The defaults are adjusted depending on the composite type. Otherwise these attributes obey the same rules as all other solref and solimp attributes in MJCF. See Solver parameters. These are the solref and solimp attributes used to equality-constrain the joint. Whether or not a given joint is quality-constrained depends on the joint kind and composite object type as explained above. For joints that are not equality-constrained, this attribute has no effect. The defaults are adjusted depending on the composite type. Otherwise these attributes obey the same rules as all other solref and solimp attributes in MJCF. See Solver parameters. Type of the joint. The keywords have the following meaning: The **free** type creates a free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits. The **ball** type creates a ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed. The **slide** type creates a sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes. The **hinge** type creates a hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints. This attribute specifies the axis of rotation for hinge joints and the direction of translation for slide joints. It is ignored for free and ball joints. The vector specified here is automatically normalized to unit length as long as its length is greater than 10E-14; otherwise a compile error is generated. This attribute specifies if the joint has limits. It interacts with the range attribute. If this attribute is "false", joint limits are disabled. If this attribute is "true", joint limits are enabled. If this attribute is "auto", and autolimits is set in compiler, joint limits will be enabled if range is defined. The joint limits. Limits can be imposed on all joint types except for free joints. For hinge and ball joints, the range is specified in degrees or radians depending on the angle attribute of compiler. For ball joints, the limit is imposed on the angle of rotation (relative to the reference configuration) regardless of the axis of rotation. Only the second range parameter is used for ball joints; the first range parameter should be set to 0. See the Limit section in the Computation chapter for more information. Setting this attribute without specifying limited is an error if autolimits is "false" in compiler. The distance threshold below which limits become active. Recall that the Constraint solver normally generates forces as soon as a constraint becomes active, even if the margin parameter makes that happen at a distance. This attribute together with solreflimit and solimplimit can be used to model a soft joint limit. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating joint limits. See CSolver. Friction loss due to dry friction. This value is the same for all degrees of freedom created by this joint. Semantically friction loss does not make sense for free joints, but the compiler allows it. To enable friction loss, set this attribute to a positive value. Constraint solver parameters for simulating dry friction. See also Friction. Constraint solver parameters for simulating dry friction. See also Friction. If this is true, explicit texture coordinates will be generated, mapping the skin to the unit square in texture space. This is needed when the material specifies a texture. If texcoord is false and the skin has texture, the texture will appear fixed to the world instead of the skin. The reason for having this attribute in the first place is because skins with texture coordinates upload these coordinates to the GPU even if no texture is applied later. So this attribute should be set to false in cases where no texture will be applied via the material attribute. Same meaning as in geom. Same meaning as in geom. Same meaning as in geom. The default value of 0 means that the automatically-generated skin passes through the centers of the body elements comprising the composite object. Positive values offset each skin vertex by the specified amount, in the direction normal to the (non-inflated) skin at that vertex. This has two uses. First, in 2D objects, a small positive inflate factor is needed to avoid aliasing artifacts. Second, collisions are done with geoms that create some thickness, even for 2D objects. Inflating the skin with a value equal to the geom size will render the skin as a "mattress" that better represents the actual collision geometry. The value of this attribute is copied into the corresponding attribute of the skin asset being created. This is only applicable to cloth and 2D grid types, and has no effect for any other composite type. The default value of 0 means that the skin has as many vertices as the number of element bodies. A positive value causes subdivision, with the specified number of (additional) grid lines. In this case the model compiler generates a denser skin using bi-cubic interpolation. This increases the quality of the rendering (especially in the absence of textures) but also slows down the renderer, so use it with caution. Values above 3 are unlikely to be needed. Type of geometric shape. The keywords have the following meaning: The **plane** type defines a surface which is infinite for collision detection purposes. It can only be attached to the world body or static children of the world. The plane passes through a point specified via the pos attribute. It is normal to the Z axis of the geom's local frame. The +Z direction corresponds to empty space. Thus the position and orientation defaults of (0,0,0) and (1,0,0,0) would create a ground plane at Z=0 elevation, with +Z being the vertical direction in the world (which is MuJoCo's convention). Since the plane is infinite, it could have been defined using any other point in the plane. The specified position however has additional meaning with regard to rendering. If either of the first two size parameters are positive, the plane is rendered as a rectangle of finite size (in the positive dimensions). This rectangle is centered at the specified position. Three size parameters are required. The first two specify the half- size of the rectangle along the X and Y axes. The third size parameter is unusual: it specifies the spacing between the grid subdivisions of the plane for rendering purposes. The subdivisions are revealed in wireframe rendering mode, but in general they should not be used to paint a grid over the ground plane (textures should be used for that purpose). Instead their role is to improve lighting and shadows, similar to the subdivisions used to render boxes. When planes are viewed from the back, the are automatically made semi-transparent. Planes and the +Z faces of boxes are the only surfaces that can show reflections, if the material applied to the geom has positive reflection. To render an infinite plane, set the first two size parameters to zero. The **hfield** type defines a height field geom. The geom must reference the desired height field asset with the hfield attribute below. The position and orientation of the geom set the position and orientation of the height field. The size of the geom is ignored, and the size parameters of the height field asset are used instead. See the description of the hfield element. Similar to planes, height field geoms can only be attached to the world body or to static children of the world. The **sphere** type defines a sphere. This and the next four types correspond to built-in geometric primitives. These primitives are treated as analytic surfaces for collision detection purposes, in many cases relying on custom pair- wise collision routines. Models including only planes, spheres, capsules and boxes are the most efficient in terms of collision detection. Other geom types invoke the general-purpose convex collider. The sphere is centered at the geom's position. Only one size parameter is used, specifying the radius of the sphere. Rendering of geometric primitives is done with automatically generated meshes whose density can be adjusted via quality. The sphere mesh is triangulated along the lines of latitude and longitude, with the Z axis passing through the north and south pole. This can be useful in wireframe mode for visualizing frame orientation. The **capsule** type defines a capsule, which is a cylinder capped with two half-spheres. It is oriented along the Z axis of the geom's frame. When the geom frame is specified in the usual way, two size parameters are required: the radius of the capsule followed by the half-height of the cylinder part. However capsules as well as cylinders can also be thought of as connectors, allowing an alternative specification with the fromto attribute below. In that case only one size parameter is required, namely the radius of the capsule. The **ellipsoid** type defines a ellipsoid. This is a sphere scaled separately along the X, Y and Z axes of the local frame. It requires three size parameters, corresponding to the three radii. Note that even though ellipsoids are smooth, their collisions are handled via the general-purpose convex collider. The only exception are plane-ellipsoid collisions which are computed analytically. The **cylinder** type defines a cylinder. It requires two size parameters: the radius and half-height of the cylinder. The cylinder is oriented along the Z axis of the geom's frame. It can alternatively be specified with the fromto attribute below. The **box** type defines a box. Three size parameters are required, corresponding to the half-sizes of the box along the X, Y and Z axes of the geom's frame. Note that box-box collisions can generate up to 8 contact points. The **mesh** type defines a mesh. The geom must reference the desired mesh asset with the mesh attribute. Note that mesh assets can also be referenced from other geom types, causing primitive shapes to be fitted; see below. The size is determined by the mesh asset and the geom size parameters are ignored. Unlike all other geoms, the position and orientation of mesh geoms after compilation do not equal the settings of the corresponding attributes here. Instead they are offset by the translation and rotation that were needed to center and align the mesh asset in its own coordinate frame. Recall the discussion of centering and alignment in the mesh element. The **sdf** type defines a signed distance field (SDF, also referred to as signed distance function). In order to visualize the SDF, a custom mesh must be specified using the mesh/plugin attribute. See the `model/plugin/sdf/ <https://github.com/google-deepmind/mujoco/tree/main/model/plugin/sdf>`__ directory for example models with SDF geometries. For more details regarding SDF plugins, see the Extensions chapter. This attribute and the next specify 32-bit integer bitmasks used for contact filtering of dynamically generated contact pairs. See Collision in the Computation chapter. Two geoms can collide if the contype of one geom is compatible with the conaffinity of the other geom or vice versa. Compatible means that the two bitmasks have a common bit set to 1. Bitmask for contact filtering; see contype above. The dimensionality of the contact space for a dynamically generated contact pair is set to the maximum of the condim values of the two participating geoms. See coContact in the Computation chapter. The allowed values and their meaning are: +--------+----------------------------------------------------------------------------------------------------------+ | condim | Description | +========+==========================================================================================================+ | 1 | Frictionless contact. | +--------+----------------------------------------------------------------------------------------------------------+ | 3 | Regular frictional contact, opposing slip in the tangent plane. | +--------+----------------------------------------------------------------------------------------------------------+ | 4 | Frictional contact, opposing slip in the tangent plane and rotation around the contact normal. This is | | | useful for modeling soft contacts (independent of contact penetration). | +--------+----------------------------------------------------------------------------------------------------------+ | 6 | Frictional contact, opposing slip in the tangent plane, rotation around the contact normal and rotation | | | around the two axes of the tangent plane. The latter frictional effects are useful for preventing | | | objects from indefinite rolling. | +--------+----------------------------------------------------------------------------------------------------------+ This attribute specifies an integer group to which the geom belongs. The only effect on the physics is at compile time, when body masses and inertias are inferred from geoms selected based on their group; see inertiagrouprange attribute of compiler. At runtime this attribute is used by the visualizer to enable and disable the rendering of entire geom groups. By default, groups 0, 1 and 2 are visible, while all other groups are invisible. The group attribute can also be used as a tag for custom computations. The geom priority determines how the properties of two colliding geoms are combined to form the properties of the contact. This interacts with the solmix attribute. See CContact. Geom size parameters. The number of required parameters and their meaning depends on the geom type as documented under the type attribute. Here we only provide a summary. All required size parameters must be positive; the internal defaults correspond to invalid settings. Note that when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh. In that case the sizes are obtained from the mesh, and the geom size parameters are ignored. Thus the number and description of required size parameters in the table below only apply to geoms that do not reference meshes. +---------+--------+------------------------------------------------------------------------------------------------+ | Type | Number | Description | +=========+========+================================================================================================+ | plane | 3 | X half-size; Y half-size; spacing between square grid lines for rendering. If either the X or Y| | | | half-size is 0, the plane is rendered as infinite in the dimension(s) with 0 size. | +---------+--------+------------------------------------------------------------------------------------------------+ | hfield | 0 | The geom sizes are ignored and the height field sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ | sphere | 1 | Radius of the sphere. | +---------+--------+------------------------------------------------------------------------------------------------+ | capsule | 1 or 2 | Radius of the capsule; half-length of the cylinder part when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ 3 | X radius; Y radius; Z radius. | +---------+--------+------------------------------------------------------------------------------------------------+ |cylinder | 1 or 2 | Radius of the cylinder; half-length of the cylinder when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ | box | 3 | X half-size; Y half-size; Z half-size. | +---------+--------+------------------------------------------------------------------------------------------------+ | mesh | 0 | The geom sizes are ignored and the mesh sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ If specified, this attribute applies a material to the geom. Otherwise, if unspecified and the type of the geom is a **mesh** the compiler will apply the mesh asset material if present. The material determines the visual properties of the geom. The only exception is color: if the rgba attribute below is different from its internal default, it takes precedence while the remaining material properties are still applied. Note that if the same material is referenced from multiple geoms (as well as sites and tendons) and the user changes some of its properties at runtime, these changes will take effect immediately for all model elements referencing the material. This is because the compiler saves the material and its properties as a separate element in mjModel, and the elements using this material only keep a reference to it. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. Contact friction parameters for dynamically generated contact pairs. The first number is the sliding friction, acting along both axes of the tangent plane. The second number is the torsional friction, acting around the contact normal. The third number is the rolling friction, acting around both axes of the tangent plane. The friction parameters for the contact pair are combined depending on the solmix and priority attributes, as explained in Contact parameters. See the general Contact section for descriptions of the semantics of this attribute. If this attribute is specified, the density attribute below is ignored and the geom density is computed from the given mass, using the geom shape and the assumption of uniform density. The computed density is then used to obtain the geom inertia. Recall that the geom mass and inertia are only used during compilation, to infer the body mass and inertia if necessary. At runtime only the body inertial properties affect the simulation; the geom mass and inertia are not saved in mjModel. Material density used to compute the geom mass and inertia. The computation is based on the geom shape and the assumption of uniform density. The internal default of 1000 is the density of water in SI units. This attribute is used only when the mass attribute above is unspecified. If `shellinertia` is "false" (the default), density has semantics of mass/volume; if "true", it has semantics of mass/area. This attribute specifies the weight used for averaging of contact parameters, and interacts with the priority attribute. See CContact. Constraint solver parameters for contact simulation. See CSolver. Constraint solver parameters for contact simulation. See CSolver. Distance threshold below which contacts are detected and included in the global array mjData.contact. This however does not mean that contact force will be generated. A contact is considered active only if the distance between the two geom surfaces is below margin-gap. Recall that constraint impedance can be a function of distance, as explained in CSolver. The quantity this function is applied to is the distance between the two geoms minus the margin plus the gap. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. Integer group to which the site belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of sites. Sizes of the geometric shape representing the site. Material used to specify the visual properties of the site. Color and transparency. If this value is different from the internal default, it overrides the corresponding material properties. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. All automatically generated model elements have names indicating the element type and index. For example, the body at coordinates (2, 0) in a 2D grid is named "B2_0" by default. If prefix="C" is specified, the same body is named "CB2_0". The prefix is needed when multiple composite objects are used in the same model, to avoid name conflicts. This attribute determines the type of composite object. The only supported type is cable. The **cable** type creates a 1D chain of bodies connected with ball joints, each having a geom with user-defined type (cylinder, capsule or box). The geometry can either be defined with an array of 3D vertex coordinates vertex or with prescribed functions with the option curve. Only linear and trigonometric functions are supported. For example, an helix can be obtained with curve="cos(s) sin(s) s". The size is set with the option size, resulting in f(s)=\{\text{size}[1]\cdot\cos(2\pi\cdot\text{size}[2]),\; \text{size}[1]\cdot\sin(2\pi\cdot\text{size}[2]),\; \text{size}[0]\cdot s\}. The element count in each dimension of the grid. This can have 1, 2 or 3 numbers, specifying the element count along the X, Y and Z axis of the parent body frame within. Any missing numbers default to 1. If any of these numbers is 1, all subsequent numbers must also be 1, so that the leading dimensions of the grid are used. This means for example that a 1D grid will always extend along the X axis. To achieve a different orientation, rotate the frame of the parent body. Note that some types imply a grid of certain dimensionality, so the requirements for this attribute depend on the specified type. It specifies a 3D offset from the center of the parent body to the center of the first body of the cable. The offset is expressed in the local coordinate frame of the parent body. Vertex 3D positions in global coordinates. Behavior of the first point. Free: free joint. Ball: ball joint. None: no dof. Functions specifying the vertex positions. Available functions are `s`, `cos(s)`, and `sin(s)`, where `s` is the arc length parameter. Scaling of the curve functions. `size[0]` is the scaling of `s`, `size[1]` is the radius of `\cos(s)` and `\sin(s)`, and `size[2]` is the speed of the argument (i.e. `\cos(2*\pi*size[2]*s)`). It specifies a quaternion that rotates the first body frame. The quaternion is expressed in the parent body frame. The type of equality constraint applied to this edge. If false, no equality constraint is applied. If true, then edge constraints are enforced. If vert, an averaged constraint is used, see flexvert. if strain, then a constraint is added to enforce that the invariants of the strain tensor do not change; this is only equality constraint type supported for trilinear and quadratic dofs elements and here. The standard constraint parameters, passed through to the automatically generated equality constraint. The standard constraint parameters, passed through to the automatically generated equality constraint. Edge stiffness and damping, passed through to the automatically generated flex. Edge stiffness and damping, passed through to the automatically generated flex. Young's elastic modulus, a measure of tensile and compressive stiffness for continuum elastic materials. Units of \textrm{pressure}=\textrm{force}/\textrm{area}. Poisson's ratio, the ratio of transverse deformation to applied longitudinal strain. This unitless quantity is in the range [0, 0.5). Small or large values imply compressibility or incompressiblity, respectively. Rayleigh's damping coefficient, units of time. This quantity scales the stiffness defined by Young's modulus to produce the damping matrix. Shell thickness, units of length; only for used 2D flexes. Used to scale the stretching stiffness. This thickness can be set equal to 2 times the radius in order to match the geometry, but is exposed separately since the radius might be constrained by considerations related to collision detection. Elastic contribution to passive forces of 2D flexes. "none": none, "bend": bending only, "stretch": stretching only, "both": bending and stretching. Enables or disables internal collisions which prevent flex self-penetration and element inversion. Note that flex elements that have shared vertices cannot collide (or else there will be permanent contacts). In 1D and 2D, internal collision checks rely on predefined vertex-element pairs, where the vertex is treated as a sphere with the same radius as the flex. These spheres correspond to non-shared vertices of neighboring elements on the periphery of the flex. The pre-defined vertex-element pairs are generated by the model compiler automatically. In 3D, internal collision checks are performed within each tetraheron: each vertex is collided with the plane corresponding to the opposing triangle face (again using the flex radius). The resulting contacts are always created with condim 1, gap 0, margin 0. Note that internal contacts modify the behavior implied by the elasticity parameters and is recommended only for flexes where element inversion cannot be prevented. This determines the strategy for midphase collision pruning of element pairs belonging to the same flex. **none** means flex elements cannot collide with each other. **narrow** means narrow phase only (i.e. all pairs are checked). This is a diagnostic tool and is never a good idea in practice. **bvh** and **sap** refer to bounding volume hierarchies and sweep-and-prune (which are two different strategies for midphase collision pruning). **auto** selects **sap** in 1D and 2D, and **bvh** in 3D. Which strategy performs better depends on the specifics of the model. The automatic setting is just a simple rule which we have found to perform well in general. This only has an effect for 3D flexes. Each tetrahedron is labeled by the model compiler with an integer corresponding to (graph) distance to the outside surface of the flex. Thus outside-facing elements are in layer 0, their neighbors are in layer 1, etc. This attribute specifies how many layers will be allowed to participate in collisions. The default setting 1 means that only one layer (i.e. layer 0) can collide, with itself and with the rest of the world. This is usually sufficient, however if the outer layer is composed of small tetrahedra, another body can "pierce" it and get stuck. In that case the value should be increased. When enabled, the contact is not added to the contact solver but it is instead used to compute passive (spring-damper) contact forces. All contacts, regardless of the specified condim, are frictionless (condim 1). This is an experimental feature. 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. Ranges of points to pin. Each range is specified by two integers. Grid coordinates of points to pin. This can only be used with type grid. Ranges of grid coordinates of points to pin. Each range is specified by (dim) integers for the minimum of the range followed by (dim) integers for the maximum of the range. This can only be used with type grid. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. The name of the flex element being generated automatically. This name is used as a prefix for all bodies that are automatically generated here, and is also referenced by the corresponding flex equality constraint (if applicable). This attribute determines the type of flexcomp object. The remaining attributes and sub-elements are then interpreted according to the type. Default settings are also adjusted depending on the type. Different types correspond to different methods for specifying the flexcomp points and the stretchable elements that connect them. They fall in three categories: direct specification entered in the XML, direct specification loaded from file, and automated generation from higher-level specification. **grid** generates a rectangular grid of points in 1D, 2D or 3D as specified by dim. The number of points in each dimension is determined by count while the grid spacing in each dimension is determined by spacing. Make sure the spacing is sufficiently large relative to radius to avoid permanent contacts. In 2D and 3D the grid is automatically triangulated, and corresponding flex elements are created (triangles or tetrahedra). In 1D the elements are capsules connecting consecutive pairs of points. **box** generates a 3D box object, however flex bodies are only generated on the outer shell. Each flex body has a radial slider joint allowing it to move in and out from the center of the box. The parent body would normally be a floating body. The box surface is triangulated, and each flex element is a tetrahedron connecting the center of the box with one triangle face. count and spacing determine the count and spacing of the flex bodies, similar to the **grid** type in 3D. Note that the resulting flex has the same topology as the box generated by composite. **cylinder** is the same as **box**, except the points are projected on the surface of a cylinder. **ellipsoid** is the same as **box**, except the points are projected on the surface of an ellipsoid. **disc** is the same as **box**, except the points are projected on the surface of a disc. It is only compatible with dim=2. **circle** is the same as **grid**, except the points are sampled along a circle so that the first and last points are the same. The radius of the circle is computed such that each segment has the requested spacing. It is only compatible with dim=1. **mesh** loads the flexcomp points and elements (i.e. triangles) from a mesh file, in the same file formats as mesh assets, excluding the legacy .msh format. A mesh asset is not actually added to the model. Instead the vertex and face data from the mesh file are used to populate the point and element data of the flexcomp. dim is automatically set to 2. Recall that a mesh asset in MuJoCo can be used as a rigid geom attached to a single body. In contrast, the flex generated here corresponds to a soft mesh with the same initial shape, where each vertex is a separate moving body (unless pinned). .. _gmsh-file-docs: **gmsh** is similar to mesh, but it loads a GMSH file in `format 4.1 <https://gmsh.info//doc/texinfo/gmsh.html#MSH-file-format>`__ and `format 2.2 <https://gmsh.info//doc/texinfo/gmsh.html#MSH-file-format-version-2-_0028Legacy_0029>`__ (ascii or binary). The file extension can be anything; the parser recognizes the format by examining the file header. This is a very rich file format, allowing all kinds of elements with different dimensionality and topology. MuJoCo only supports GMSH element types 1, 2, 4 which happen to correspond to our 1D, 2D and 3D flexes and assumes that the nodes are specified in a single block. Only the Nodes and Elements sections of the GMHS file are processed, and used to populate the point and element data of the flexcomp. The parser will generate an error if the GMSH file contains meshes that are not supported by MuJoCo. dim is automatically set to the dimensionality specified in the GMSH file. Presently this is the only mechanism to load a large tetrahedral mesh in MuJoCo and generate a corresponding soft entity. If such a mesh is available in a different file format, use the freely available `GMSH software <https://gmsh.info/>`__ to convert it to GMSH in one of the supported versions. **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 specifying the corresponding flex directly. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. Dimensionality of the flex object. This value must be 1, 2 or 3. The flex elements are capsules in 1D, triangles with radius in 2D, and tetrahedra with radius in 3D. Certain flexcomp types imply a dimensionality, in which case the value specified here is ignored. The parametrization of the flex's degrees of freedom (dofs). See the video on the right illustrating the different parametrizations with deformable spheres. The three models in the video are respectively `sphere_full <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_full.xml>`__, `sphere_radial <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_radial.xml>`__ and `sphere_trilinear <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_trilinear.xml>`__. **full** Three translational dofs per vertex. This is the most expressive but also the most expensive option. **radial** A single radial translational dof per vertex. Note that unlike in the "full" case, the radial parametrization requires a free joint at the flex's parent in order for free body motion to be possible. This type of parametrization is appropriate for shapes that are relatively spherical. **trilinear** Three translational dofs at each corner of the bounding box of the flex, for a total of 24 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using trilinear interpolation over the bounding box. :align: right :width: 240px Trilinear and quadratic flexes are much faster than the previous two options, and are the preferred choice if the expected deformations can be captured by the reduced parametriation. For example, see the video on the right comparing `full <https://github.com/google-deepmind/mujoco/blob/main/model/flex/gripper.xml>`__ and `trilinear <https://github.com/google-deepmind/mujoco/blob/main/model/flex/gripper_trilinear.xml>`__ flexes for modeling deformable gripper pads. Note that the choice of dof parametrization affects the deformation modes of the flex but has no effect on the accuracy of the collision geometry, which always takes into account the high-resolution mesh of the flex. **quadratic** Three translational dofs per corner, edge, face, and volume of the bounding box of the flex, for a total of 81 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using quadratic interpolation over the bounding box. While this option requires more degrees of freedom than trilinear flexes, it enables curved deformation modes, while the only modes achievable for trilinear flexes are strech/compression and shear. To understand the difference between the two parametrizations, see `a trilinear cube <https://github.com/google-deepmind/mujoco/blob/main/model/flex/trilinear.xml>`__ and `a quadratic cube <https://github.com/google-deepmind/mujoco/blob/main/model/flex/quadratic.xml>`__. Note that a higher interpolation order generally requires a smaller time step for stability, although usually not as large as with the "full" option and a fine mesh. Specifies the number of automatically generated points in each dimension for types **grid**, **box**, **cylinder**, and **ellipsoid**. Specifies the number of cells in each dimension for the background interpolation grid when using **trilinear** or **quadratic** dofs. The spacing between the automatically generated points in each dimension. The spacing should be sufficiently large compared to the radius, to avoid permanent contacts. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. If this is true, all points correspond to vertices within the parent body, and no new bodies are created. This is equivalent to pinning all points. Note that if all points are indeed pinned, the model compiler will detect that the flex is rigid (which behaves is a non-convex mesh in collision detection). The mass of each automatically-generated body equals this value divided by the number of points. Note that pinning some points does not affect the mass of the other bodies. Even though the automatically-generated bodies have the physics of point masses, with slider joints, MuJoCo still requires each body to have rotational inertia. The inertias generated here are diagonal, and are computed such that the corresponding equivalent-inertia boxes have sides equal to this value. Scaling of all point coordinates, for types that specify coordinates explicitly. Scaling is applied after the pose transformation. The name of the file from which a **surface** (triangular) or **volumetric** (tetrahedral) mesh is loaded. For surface meshes, the file extension is used to determine the file format. Supported formats are GMSH and the formats specified in mesh assets, excluding the legacy .msh format. Volumetric meshes are supported only in GMSH format. See here for more information on GMSH files. The 3D coordinates of the points. This attribute is only used with type **direct**. All other flexcomp types generate their own points. The points are used to construct bodies and vertices as explained earlier. The zero-based point ids forming each flex elements. This attribute is only used with type **direct**. All other flexcomp types generate their own elements. This data is passed through to the automatically-generated flex. Texture coordinates of each point, passed through to the automatically-generated flex. Note that flexcomp does not generate texture coordinates automatically, except for 2D grids, box, cylinder and ellipsoid. For all other types, the user can specify explicit texture coordinates here, even if the points themselves were generated automatically. This requires understanding of the layout of the automatically-generated points and how they correspond to the texture referenced by the material. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. This 3D vector translates all points relative to the frame of the parent body. This is a quaternion rotation of all points around the pos vector specified above. Together these two vectors define a pose transformation, used to position and orient the points as needed. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. The origin of the flexcomp. Used for generating a volumetric mesh from an OBJ surface mesh. Each surface triangle is connected to the origin to create a tetrahedron, so the resulting volumetric mesh is guaranteed to be well-formed only for convex shapes. Name of the body. If this attribute is present, all descendant elements that admit a defaults class will use the class specified here, unless they specify their own class or another body or frame with a childclass attribute is encountered along the chain of nested bodies and frames. Recall CDefault. The 3D position of the body frame, in the parent coordinate frame. If undefined it defaults to (0,0,0). See COrientation. If this attribute is "true", the body is labeled as a mocap body. This is allowed only for bodies that are children of the world body and have no joints. Such bodies are fixed from the viewpoint of the dynamics, but nevertheless the forward kinematics set their position and orientation from the fields mjData.mocap_{pos,quat} at each time step. The size of these arrays is adjusted by the compiler so as to match the number of mocap bodies in the model. This mechanism can be used to stream motion capture data into the simulation. Mocap bodies can also be moved via mouse perturbations in the interactive visualizer, even in dynamic simulation mode. This can be useful for creating props with adjustable position and orientation. See COrientation. See COrientation. See COrientation. See COrientation. Gravity compensation force, specified as fraction of body weight. This attribute creates an upwards force applied to the body's center of mass, countering the force of gravity. As an example, a value of 1 creates an upward force equal to the body's weight and compensates for gravity exactly. Values greater than 1 will create a net upwards force or buoyancy effect. Sleep policy for the tree under this body. This attribute is only supported by moving bodies which are the root of a kinematic tree. For the default auto, the compiler will set the sleep policy as follows: - A tree which is affected by actuators is not allowed to sleep (overridable). - Trees which are connected by tendons which have non-zero stiffness and damping are not allowed to sleep (overridable). - Trees which are connected by tendons which connect more than two trees are not allowed to sleep (not overridable). - flexes are not allowed to sleep (not overridable). - All other trees are allowed to sleep (overridable). The policies never and allowed constitute user overrides of the automatic compiler policy. The init sleep policy can only be specified by the user and means "initialize this tree as asleep". This policy is implemented in mj_resetData and mj_makeData and only applies to the default configuration. If a keyframe changes the configuration of (or assigns nonzero velocity to) a sleeping tree, it will be woken up. This policy is useful for very large models where waiting for the automatic sleeping mechanism to kick in can be expensive. Trees initialized as sleeping can be placed in unstable configurations like deep penetration or in mid-air, but will only move when woken up. Also note that this policy can fail. For example if a tree marked as sleep="init" is in contact with a tree not marked as such (i.e., they are in the same island) then it is impossible to put the tree to sleep; such `models <https://github.com/google-deepmind/mujoco/blob/main/test/engine/testdata/sleep/init_island_fail.xml>`__ will lead to a compilation error. See implementation notes for more details. See CUser. Position of the inertial frame. This attribute is required even when the inertial properties can be inferred from geoms. This is because the presence of the inertial element itself disables the automatic inference mechanism. Orientation of the inertial frame. See COrientation. Mass of the body. Negative values are not allowed. MuJoCo requires the inertia matrix in generalized coordinates to be positive-definite, which can sometimes be achieved even if some bodies have zero mass. In general however there is no reason to use massless bodies. Such bodies are often used in other engines to bypass the limitation that joints cannot be combined, or to attach sensors and cameras. In MuJoCo primitive joint types can be combined, and we have sites which are a more efficient attachment mechanism. Diagonal inertia matrix, expressing the body inertia relative to the inertial frame. If this attribute is omitted, the next attribute becomes required. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Full inertia matrix M. Since M is 3-by-3 and symmetric, it is specified using only 6 numbers in the following order: M(1,1), M(2,2), M(3,3), M(1,2), M(1,3), M(2,3). The compiler computes the eigenvalue decomposition of M and sets the frame orientation and diagonal inertia accordingly. If non-positive eigenvalues are encountered (i.e., if M is not positive definite) a compile error is generated. Name of the joint. Defaults class for setting unspecified attributes. Type of the joint. The keywords have the following meaning: The **free** type creates a free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits. The **ball** type creates a ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed. The **slide** type creates a sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes. The **hinge** type creates a hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. Position of the joint, specified in the frame of the body where the joint is defined. For free joints this attribute is ignored. This attribute specifies the axis of rotation for hinge joints and the direction of translation for slide joints. It is ignored for free and ball joints. The vector specified here is automatically normalized to unit length as long as its length is greater than 10E-14; otherwise a compile error is generated. When both numbers are positive, the compiler will override any stiffness and damping values specified with the attributes below, and will instead set them automatically so that the resulting mass-spring-damper for this joint has the desired time constant (first value) and damping ratio (second value). This is done by taking into account the joint inertia in the model reference configuration. Note that the format is the same as the solref parameter of the constraint solver. This attribute specifies if the joint has limits. It interacts with the range attribute. If this attribute is "false", joint limits are disabled. If this attribute is "true", joint limits are enabled. If this attribute is "auto", and autolimits is set in compiler, joint limits will be enabled if range is defined. This attribute specifies whether actuator forces acting on the joint should be clamped. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. This attribute interacts with the actuatorfrcrange attribute. If this attribute is "false", actuator force clamping is disabled. If it is "true", actuator force clamping is enabled. If this attribute is "auto", and autolimits is set in compiler, actuator force clamping will be enabled if actuatorfrcrange is defined. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating dry friction. See also Friction. Constraint solver parameters for simulating dry friction. See also Friction. Joint stiffness coefficients a, b, c. A positive a produces the standard restorative linear spring force f = -a x, where x is the joint displacement from equilibrium given by springref. If the optional second and third components are set, they define a nonlinear polynomial spring force f(x) = -(a x + b x^2 + c x^3). See Polynomial forces for details. The joint limits. Limits can be imposed on all joint types except for free joints. For hinge and ball joints, the range is specified in degrees or radians depending on the angle attribute of compiler. For ball joints, the limit is imposed on the angle of rotation (relative to the reference configuration) regardless of the axis of rotation. Only the second range parameter is used for ball joints; the first range parameter should be set to 0. See the Limit section in the Computation chapter for more information. Setting this attribute without specifying limited is an error if autolimits is "false" in compiler. Range for clamping total actuator forces acting on this joint. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. The compiler expects the first value to be smaller than the second value. Setting this attribute without specifying actuatorfrclimited is an error if compiler-autolimits is "false". If this flag is enabled, gravity compensation applied to this joint is added to actuator forces (mjData.qfrc_actuator) rather than passive forces (mjData.qfrc_passive). Notionally, this means that gravity compensation is the result of a control system rather than natural buoyancy. In practice, enabling this flag is useful when joint-level actuator force clamping is used. In this case, the total actuation force applied on a joint, including gravity compensation, is guaranteed to not exceed the specified limits. See CForceRange and actuatorfrcrange for more details on this type of force limit. The distance threshold below which limits become active. Recall that the Constraint solver normally generates forces as soon as a constraint becomes active, even if the margin parameter makes that happen at a distance. This attribute together with solreflimit and solimplimit can be used to model a soft joint limit. The reference position or angle of the joint. This attribute is only used for slide and hinge joints. It defines the joint value corresponding to the initial model configuration. Note that the initial configuration itself is unmodified, only the value of the joint at this configuration. The amount of spatial transformation that the joint applies at runtime equals the current joint value stored in mjData.qpos minus this reference value stored in mjModel.qpos0. The meaning of these vectors is discussed in the Kinematic tree section in the Overview chapter. The joint position or angle in which the joint spring (if any) achieves equilibrium. Similar to the vector mjModel.qpos0 which stores all joint reference values specified with the ref attribute above, all spring reference values specified with this attribute are stored in the vector mjModel.qpos_spring. The model configuration corresponding to mjModel.qpos_spring is also used to compute the spring reference lengths of all tendons, stored in mjModel.tendon_lengthspring. This is because tendons can also have springs. Additional inertia associated with movement of the joint that is not due to body mass. This added inertia is usually due to a rotor (a.k.a `armature <https://en.wikipedia.org/wiki/Armature_(electrical)>`__) spinning faster than the joint itself due to a geared transmission. In the illustration, we compare (*left*) a 2-dof system with an armature body (purple box), coupled with a gear ratio of 3 to the pendulum using a joint equality constraint, and (*right*) a simple 1-dof pendulum with an equivalent armature. Because the gear ratio appears twice, multiplying both forces and lengths, the effect is known as "reflected inertia" and the equivalent value is the inertia of the spinning body multiplied by the *square of the gear ratio*, in this case 9=3^2. The value applies to all degrees of freedom created by this joint. Besides increasing the realism of joints with geared transmission, positive armature significantly improves simulation stability, even for small values, and is a recommended possible fix when encountering stability issues. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v, where v is the joint velocity. Despite its simplicity, larger damping values can make numerical integrators unstable, which is why our Euler integrator handles damping implicitly. See Integration in the Computation chapter. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Friction loss due to dry friction. This value is the same for all degrees of freedom created by this joint. Semantically friction loss does not make sense for free joints, but the compiler allows it. To enable friction loss, set this attribute to a positive value. See CUser. Name of the joint. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. When set to true, the body frame and free joint will automatically be aligned with inertial frame. When set to false, no alignment will occur. When set to auto, the compiler's alignfree global attribute will be respected. Inertial frame alignment is an optimization only applies to bodies with a free joint and no child bodies ("simple free bodies"). The alignment diagonalizes the 6x6 inertia matrix and minimizes bias forces, leading to faster and more stable simulation. While this behaviour is a strict improvement, it modifies the semantics of the free joint, making qpos and qvel values saved in older versions (for example, in keyframes) invalid. Note that the align attribute is never saved to XML. Instead, the pose of simple free bodies and their children will be modified such that the body frame and inertial frame are aligned. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. Name of the geom. Defaults class for setting unspecified attributes. Type of geometric shape. The keywords have the following meaning: The **plane** type defines a surface which is infinite for collision detection purposes. It can only be attached to the world body or static children of the world. The plane passes through a point specified via the pos attribute. It is normal to the Z axis of the geom's local frame. The +Z direction corresponds to empty space. Thus the position and orientation defaults of (0,0,0) and (1,0,0,0) would create a ground plane at Z=0 elevation, with +Z being the vertical direction in the world (which is MuJoCo's convention). Since the plane is infinite, it could have been defined using any other point in the plane. The specified position however has additional meaning with regard to rendering. If either of the first two size parameters are positive, the plane is rendered as a rectangle of finite size (in the positive dimensions). This rectangle is centered at the specified position. Three size parameters are required. The first two specify the half- size of the rectangle along the X and Y axes. The third size parameter is unusual: it specifies the spacing between the grid subdivisions of the plane for rendering purposes. The subdivisions are revealed in wireframe rendering mode, but in general they should not be used to paint a grid over the ground plane (textures should be used for that purpose). Instead their role is to improve lighting and shadows, similar to the subdivisions used to render boxes. When planes are viewed from the back, the are automatically made semi-transparent. Planes and the +Z faces of boxes are the only surfaces that can show reflections, if the material applied to the geom has positive reflection. To render an infinite plane, set the first two size parameters to zero. The **hfield** type defines a height field geom. The geom must reference the desired height field asset with the hfield attribute below. The position and orientation of the geom set the position and orientation of the height field. The size of the geom is ignored, and the size parameters of the height field asset are used instead. See the description of the hfield element. Similar to planes, height field geoms can only be attached to the world body or to static children of the world. The **sphere** type defines a sphere. This and the next four types correspond to built-in geometric primitives. These primitives are treated as analytic surfaces for collision detection purposes, in many cases relying on custom pair- wise collision routines. Models including only planes, spheres, capsules and boxes are the most efficient in terms of collision detection. Other geom types invoke the general-purpose convex collider. The sphere is centered at the geom's position. Only one size parameter is used, specifying the radius of the sphere. Rendering of geometric primitives is done with automatically generated meshes whose density can be adjusted via quality. The sphere mesh is triangulated along the lines of latitude and longitude, with the Z axis passing through the north and south pole. This can be useful in wireframe mode for visualizing frame orientation. The **capsule** type defines a capsule, which is a cylinder capped with two half-spheres. It is oriented along the Z axis of the geom's frame. When the geom frame is specified in the usual way, two size parameters are required: the radius of the capsule followed by the half-height of the cylinder part. However capsules as well as cylinders can also be thought of as connectors, allowing an alternative specification with the fromto attribute below. In that case only one size parameter is required, namely the radius of the capsule. The **ellipsoid** type defines a ellipsoid. This is a sphere scaled separately along the X, Y and Z axes of the local frame. It requires three size parameters, corresponding to the three radii. Note that even though ellipsoids are smooth, their collisions are handled via the general-purpose convex collider. The only exception are plane-ellipsoid collisions which are computed analytically. The **cylinder** type defines a cylinder. It requires two size parameters: the radius and half-height of the cylinder. The cylinder is oriented along the Z axis of the geom's frame. It can alternatively be specified with the fromto attribute below. The **box** type defines a box. Three size parameters are required, corresponding to the half-sizes of the box along the X, Y and Z axes of the geom's frame. Note that box-box collisions can generate up to 8 contact points. The **mesh** type defines a mesh. The geom must reference the desired mesh asset with the mesh attribute. Note that mesh assets can also be referenced from other geom types, causing primitive shapes to be fitted; see below. The size is determined by the mesh asset and the geom size parameters are ignored. Unlike all other geoms, the position and orientation of mesh geoms after compilation do not equal the settings of the corresponding attributes here. Instead they are offset by the translation and rotation that were needed to center and align the mesh asset in its own coordinate frame. Recall the discussion of centering and alignment in the mesh element. The **sdf** type defines a signed distance field (SDF, also referred to as signed distance function). In order to visualize the SDF, a custom mesh must be specified using the mesh/plugin attribute. See the `model/plugin/sdf/ <https://github.com/google-deepmind/mujoco/tree/main/model/plugin/sdf>`__ directory for example models with SDF geometries. For more details regarding SDF plugins, see the Extensions chapter. This attribute and the next specify 32-bit integer bitmasks used for contact filtering of dynamically generated contact pairs. See Collision in the Computation chapter. Two geoms can collide if the contype of one geom is compatible with the conaffinity of the other geom or vice versa. Compatible means that the two bitmasks have a common bit set to 1. Bitmask for contact filtering; see contype above. The dimensionality of the contact space for a dynamically generated contact pair is set to the maximum of the condim values of the two participating geoms. See coContact in the Computation chapter. The allowed values and their meaning are: +--------+----------------------------------------------------------------------------------------------------------+ | condim | Description | +========+==========================================================================================================+ | 1 | Frictionless contact. | +--------+----------------------------------------------------------------------------------------------------------+ | 3 | Regular frictional contact, opposing slip in the tangent plane. | +--------+----------------------------------------------------------------------------------------------------------+ | 4 | Frictional contact, opposing slip in the tangent plane and rotation around the contact normal. This is | | | useful for modeling soft contacts (independent of contact penetration). | +--------+----------------------------------------------------------------------------------------------------------+ | 6 | Frictional contact, opposing slip in the tangent plane, rotation around the contact normal and rotation | | | around the two axes of the tangent plane. The latter frictional effects are useful for preventing | | | objects from indefinite rolling. | +--------+----------------------------------------------------------------------------------------------------------+ This attribute specifies an integer group to which the geom belongs. The only effect on the physics is at compile time, when body masses and inertias are inferred from geoms selected based on their group; see inertiagrouprange attribute of compiler. At runtime this attribute is used by the visualizer to enable and disable the rendering of entire geom groups. By default, groups 0, 1 and 2 are visible, while all other groups are invisible. The group attribute can also be used as a tag for custom computations. The geom priority determines how the properties of two colliding geoms are combined to form the properties of the contact. This interacts with the solmix attribute. See CContact. Geom size parameters. The number of required parameters and their meaning depends on the geom type as documented under the type attribute. Here we only provide a summary. All required size parameters must be positive; the internal defaults correspond to invalid settings. Note that when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh. In that case the sizes are obtained from the mesh, and the geom size parameters are ignored. Thus the number and description of required size parameters in the table below only apply to geoms that do not reference meshes. +---------+--------+------------------------------------------------------------------------------------------------+ | Type | Number | Description | +=========+========+================================================================================================+ | plane | 3 | X half-size; Y half-size; spacing between square grid lines for rendering. If either the X or Y| | | | half-size is 0, the plane is rendered as infinite in the dimension(s) with 0 size. | +---------+--------+------------------------------------------------------------------------------------------------+ | hfield | 0 | The geom sizes are ignored and the height field sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ | sphere | 1 | Radius of the sphere. | +---------+--------+------------------------------------------------------------------------------------------------+ | capsule | 1 or 2 | Radius of the capsule; half-length of the cylinder part when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ 3 | X radius; Y radius; Z radius. | +---------+--------+------------------------------------------------------------------------------------------------+ |cylinder | 1 or 2 | Radius of the cylinder; half-length of the cylinder when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ | box | 3 | X half-size; Y half-size; Z half-size. | +---------+--------+------------------------------------------------------------------------------------------------+ | mesh | 0 | The geom sizes are ignored and the mesh sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ If specified, this attribute applies a material to the geom. Otherwise, if unspecified and the type of the geom is a **mesh** the compiler will apply the mesh asset material if present. The material determines the visual properties of the geom. The only exception is color: if the rgba attribute below is different from its internal default, it takes precedence while the remaining material properties are still applied. Note that if the same material is referenced from multiple geoms (as well as sites and tendons) and the user changes some of its properties at runtime, these changes will take effect immediately for all model elements referencing the material. This is because the compiler saves the material and its properties as a separate element in mjModel, and the elements using this material only keep a reference to it. Contact friction parameters for dynamically generated contact pairs. The first number is the sliding friction, acting along both axes of the tangent plane. The second number is the torsional friction, acting around the contact normal. The third number is the rolling friction, acting around both axes of the tangent plane. The friction parameters for the contact pair are combined depending on the solmix and priority attributes, as explained in Contact parameters. See the general Contact section for descriptions of the semantics of this attribute. If this attribute is specified, the density attribute below is ignored and the geom density is computed from the given mass, using the geom shape and the assumption of uniform density. The computed density is then used to obtain the geom inertia. Recall that the geom mass and inertia are only used during compilation, to infer the body mass and inertia if necessary. At runtime only the body inertial properties affect the simulation; the geom mass and inertia are not saved in mjModel. Material density used to compute the geom mass and inertia. The computation is based on the geom shape and the assumption of uniform density. The internal default of 1000 is the density of water in SI units. This attribute is used only when the mass attribute above is unspecified. If `shellinertia` is "false" (the default), density has semantics of mass/volume; if "true", it has semantics of mass/area. If true, the geom's inertia is computed assuming that all the mass is concentrated on the surface. In this case density is interpreted as surface rather than volumetric density. This attribute only applies to primitive geoms and is ignored for meshes. Surface inertia for meshes can be specified by setting the asset/mesh/inertia attribute to "shell". This attribute specifies the weight used for averaging of contact parameters, and interacts with the priority attribute. See CContact. Constraint solver parameters for contact simulation. See CSolver. Constraint solver parameters for contact simulation. See CSolver. Distance threshold below which contacts are detected and included in the global array mjData.contact. This however does not mean that contact force will be generated. A contact is considered active only if the distance between the two geom surfaces is below margin-gap. Recall that constraint impedance can be a function of distance, as explained in CSolver. The quantity this function is applied to is the distance between the two geoms minus the margin plus the gap. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. :width: 350px :align: right This attribute can only be used with capsule, box, cylinder and ellipsoid geoms. It provides an alternative specification of the geom length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the geom connects these two points, with the +Z axis of the geom's frame oriented from the first towards the second point, while in the perpendicular direction, the geom sizes are both equal to the first value of the size attribute. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the end points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. The image on the right demonstrates use of fromto with the four supported geoms, using identical Z values. The model is `here <_static/fromto.xml>`__. Note that the fromto semantics of *capsule* are unique: the two end points specify the segment around which the radius defines the capsule surface. Position of the geom, specified in the frame of the body where the geom is defined. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. This attribute must be specified if and only if the geom type is "hfield". It references the height field asset to be instantiated at the position and orientation of the geom frame. If the geom type is "mesh", this attribute is required. It references the mesh asset to be instantiated. This attribute can also be specified if the geom type corresponds to a geometric primitive, namely one of "sphere", "capsule", "cylinder", "ellipsoid", "box". In that case the primitive is automatically fitted to the mesh asset referenced here. The fitting procedure uses either the equivalent inertia box or the axis-aligned bounding box of the mesh, as determined by the attribute fitaabb of compiler. The resulting size of the fitted geom is usually what one would expect, but if not, it can be further adjusted with the fitscale attribute below. In the compiled mjModel the geom is represented as a regular geom of the specified primitive type, and there is no reference to the mesh used for fitting. This attribute is used only when a primitive geometric type is being fitted to a mesh asset. The scale specified here is relative to the output of the automated fitting procedure. The default value of 1 leaves the result unchanged, a value of 2 makes all sizes of the fitted geom two times larger. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. "ellipsoid" activates the geom-level fluid interaction model based on an ellipsoidal approximation of the geom shape. When active, the model based on body inertia sizes is disabled for the body in which the geom is defined. See section on ellipsoid-based fluid interaction model for details. Dimensionless coefficients of fluid interaction model, as follows. See section on ellipsoid-based fluid interaction model for details. See CUser. The sub-model from which to attach a subtree. Name of the body in the sub-model to attach here. The body and its subtree will be attached. If this attribute is not specified, the contents of the world body will be attached in a new frame. Prefix to prepend to names of elements in the sub-model. This attribute is required to prevent name collisions with the parent or when attaching the same sub-tree multiple times. Name of the site. Defaults class for setting unspecified attributes. Type of geometric shape. This is used for rendering, and also determines the active sensor zone for touch sensors. Integer group to which the site belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of sites. Position of the site frame. Orientation of the site frame. See COrientation. Material used to specify the visual properties of the site. Sizes of the geometric shape representing the site. This attribute can only be used with capsule, cylinder, ellipsoid and box sites. It provides an alternative specification of the site length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the site connects these two points, with the +Z axis of the site's frame oriented from the first towards the second point. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the two points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Color and transparency. If this value is different from the internal default, it overrides the corresponding material properties. See CUser. Name of the camera. Defaults class for setting unspecified attributes. Whether the camera uses a perspective (the default) or orthographic projection. Setting this attribute to "orthographic" changes the semantic of the fovy attribute, see below. Vertical field-of-view of the camera. If the camera uses a perspective projection, the field-of-view is expressed in degrees, regardless of the global compiler/angle setting. If the camera uses an orthographic projection, the field-of-view is expressed in units of length; note that in this case the default of 45 is too large for most scenes and should likely be reduced. In either case, the horizontal field of view is computed automatically given the window size and the vertical field of view. Inter-pupilary distance. This attribute only has an effect during stereoscopic rendering. It specifies the distance between the left and right viewpoints. Each viewpoint is shifted by +/- half of the distance specified here, along the X axis of the camera frame. Resolution of the camera in pixels [width height]. Note that these values are not used for rendering since those dimensions are determined by the size of the rendering context. This attribute serves as a convenient location to save the required resolution. Setting either value larger than 1 enables frustum visualization when the mjVIS_CAMERA visualization flag is active. Types of output images supported by the camera. - rgb: RGB image. - depth: Depth image (distance from camera plane). - distance: Distance image (distance from camera origin). - normal: Surface normal image. - segmentation: Segmentation image. This attribute is not used for rendering, but serves as a convenient location to save the output types supported by the camera. The output attribute can contain multiple types, e.g. "rgb normal". Position of the camera frame. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. This attribute specifies how the camera position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the camera sees). "fixed" means that the position and orientation specified below are fixed relative to the body where the camera is defined. "track" means that the camera position is at a constant offset from the body in world coordinates, while the camera orientation is constant in world coordinates. These constants are determined by applying forward kinematics in qpos0 and treating the camera as fixed. Tracking can be used for example to position a camera above a body, point it down so it sees the body, and have it always remain above the body no matter how the body translates and rotates. "trackcom" is similar to "track" but the constant spatial offset is defined relative to the center of mass of the kinematic subtree starting at the body in which the camera is defined. This can be used to keep an entire mechanism in view. Note that the subtree center of mass for the world body is the center of mass of the entire model. So if a camera is defined in the world body in mode "trackcom", it will track the entire model. "targetbody" means that the camera position is fixed in the body frame, while the camera orientation is adjusted so that it always points towards the targeted body (which is specified with the target attribute below). This can be used for example to model an eye that fixates a moving object; the object will be the target, and the camera/eye will be defined in the body corresponding to the head. "targetbodycom" is the same as "targetbody" but the camera is oriented towards the center of mass of the subtree starting at the target body. When the camera mode is "targetbody" or "targetbodycom", this attribute becomes required. It specifies which body should be targeted by the camera. In all other modes this attribute is ignored. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Size of the camera sensor in length units. When specified, all intrinsic attributes become active and fovy is ignored. The field-of-view is then computed automatically from the focal length and sensor size. See CUser. Name of the light. Defaults class for setting unspecified attributes. This is a deprecated legacy attribute. Please use light type instead. If set to "true", and no type is specified, this will change the light type to be directional. Determines the type of light. Note that some light types may not be supported by some renderers (e.g. only spot and directional lights are supported by the default native renderer). If this attribute is "true" the light will cast shadows. More precisely, the geoms illuminated by the light will cast shadows, however this is a property of lights rather than geoms. Since each shadow-casting light causes one extra rendering pass through all geoms, this attribute should be used with caution. Higher quality of the shadows is achieved by increasing the value of the shadowsize attribute of quality, as well as positioning spotlights closer to the surface on which shadows appear, and limiting the volume in which shadows are cast. For spotlights this volume is a cone, whose angle is the cutoff attribute below multiplied by the shadowscale attribute of map. For directional lights this volume is a box, whose half-sizes in the directions orthogonal to the light are the model extent multiplied by the shadowclip attribute of map. The model extent is computed by the compiler but can also be overridden by specifying the extent attribute of statistic. Internally the shadow-mapping mechanism renders the scene from the light viewpoint (as if it were a camera) into a depth texture, and then renders again from the camera viewpoint, using the depth texture to create shadows. The internal rendering pass uses the same near and far clipping planes as regular rendering, i.e., these clipping planes bound the cone or box shadow volume in the light direction. As a result, some shadows (especially those very close to the light) may be clipped. The light is active if this attribute is "true". This can be used at runtime to turn lights on and off. Position of the light. This attribute only affects the rendering for spotlights, but it should also be defined for directional lights because we render the cameras as decorative elements. Direction of the light. The radius of the light source which can affect shadow softness depending on the renderer. This only applies to spotlights. The intensity of the light source, measured in candela, used for physically-based lighting models. This is unused by the default Phong lighting model. The effective range of the light. Objects further than this distance from the light position will not be illuminated by this light. This only applies to spotlights. These are the constant, linear and quadratic attenuation coefficients for Phong lighting. The default corresponds to no attenuation. Cutoff angle for spotlights, always in degrees regardless of the global angle setting. Exponent for spotlights. This setting controls the softness of the spotlight cutoff. The ambient color of the light, used by the default Phong lighting model. The color of the light. For the Phong (default) lighting model, this defines the diffuse color of the light. The specular color of the light, used by the default Phong lighting model. This is identical to the mode attribute of camera above. It specifies the how the light position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the light illuminates). This is identical to the target attribute of camera above. It specifies which body should be targeted in "targetbody" and "targetbodycom" modes. The texture to use for image-based lighting. This is unused by the default Phong lighting model. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. The joint kind here is orthogonal to the joint type in the rest of MJCF. The joint kind refers to the function of the joint within the mechanism comprising the composite body, while the joint type (hinge or slide) is implied by the joint kind and composite body type. The **main** kind corresponds to the main joints forming each composite type. These joints are automatically included in the model even if the joint sub-element is missing. The main joints are 3D sliders for particle and grid; 1D sliders for box, cylinder and rope; universal joints for cloth, rope and loop. Even though the main joints are included automatically, this sub-element is still useful for adjusting their attributes. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. Joint stiffness coefficients a, b, c. A positive a produces the standard restorative linear spring force f = -a x, where x is the joint displacement from equilibrium given by springref. If the optional second and third components are set, they define a nonlinear polynomial spring force f(x) = -(a x + b x^2 + c x^3). See Polynomial forces for details. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v, where v is the joint velocity. Despite its simplicity, larger damping values can make numerical integrators unstable, which is why our Euler integrator handles damping implicitly. See Integration in the Computation chapter. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Additional inertia associated with movement of the joint that is not due to body mass. This added inertia is usually due to a rotor (a.k.a `armature <https://en.wikipedia.org/wiki/Armature_(electrical)>`__) spinning faster than the joint itself due to a geared transmission. In the illustration, we compare (*left*) a 2-dof system with an armature body (purple box), coupled with a gear ratio of 3 to the pendulum using a joint equality constraint, and (*right*) a simple 1-dof pendulum with an equivalent armature. Because the gear ratio appears twice, multiplying both forces and lengths, the effect is known as "reflected inertia" and the equivalent value is the inertia of the spinning body multiplied by the *square of the gear ratio*, in this case 9=3^2. The value applies to all degrees of freedom created by this joint. Besides increasing the realism of joints with geared transmission, positive armature significantly improves simulation stability, even for small values, and is a recommended possible fix when encountering stability issues. These are the solref and solimp attributes used to equality-constrain the joint. Whether or not a given joint is quality-constrained depends on the joint kind and composite object type as explained above. For joints that are not equality-constrained, this attribute has no effect. The defaults are adjusted depending on the composite type. Otherwise these attributes obey the same rules as all other solref and solimp attributes in MJCF. See Solver parameters. These are the solref and solimp attributes used to equality-constrain the joint. Whether or not a given joint is quality-constrained depends on the joint kind and composite object type as explained above. For joints that are not equality-constrained, this attribute has no effect. The defaults are adjusted depending on the composite type. Otherwise these attributes obey the same rules as all other solref and solimp attributes in MJCF. See Solver parameters. Type of the joint. The keywords have the following meaning: The **free** type creates a free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits. The **ball** type creates a ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed. The **slide** type creates a sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes. The **hinge** type creates a hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints. This attribute specifies the axis of rotation for hinge joints and the direction of translation for slide joints. It is ignored for free and ball joints. The vector specified here is automatically normalized to unit length as long as its length is greater than 10E-14; otherwise a compile error is generated. This attribute specifies if the joint has limits. It interacts with the range attribute. If this attribute is "false", joint limits are disabled. If this attribute is "true", joint limits are enabled. If this attribute is "auto", and autolimits is set in compiler, joint limits will be enabled if range is defined. The joint limits. Limits can be imposed on all joint types except for free joints. For hinge and ball joints, the range is specified in degrees or radians depending on the angle attribute of compiler. For ball joints, the limit is imposed on the angle of rotation (relative to the reference configuration) regardless of the axis of rotation. Only the second range parameter is used for ball joints; the first range parameter should be set to 0. See the Limit section in the Computation chapter for more information. Setting this attribute without specifying limited is an error if autolimits is "false" in compiler. The distance threshold below which limits become active. Recall that the Constraint solver normally generates forces as soon as a constraint becomes active, even if the margin parameter makes that happen at a distance. This attribute together with solreflimit and solimplimit can be used to model a soft joint limit. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating joint limits. See CSolver. Friction loss due to dry friction. This value is the same for all degrees of freedom created by this joint. Semantically friction loss does not make sense for free joints, but the compiler allows it. To enable friction loss, set this attribute to a positive value. Constraint solver parameters for simulating dry friction. See also Friction. Constraint solver parameters for simulating dry friction. See also Friction. If this is true, explicit texture coordinates will be generated, mapping the skin to the unit square in texture space. This is needed when the material specifies a texture. If texcoord is false and the skin has texture, the texture will appear fixed to the world instead of the skin. The reason for having this attribute in the first place is because skins with texture coordinates upload these coordinates to the GPU even if no texture is applied later. So this attribute should be set to false in cases where no texture will be applied via the material attribute. Same meaning as in geom. Same meaning as in geom. Same meaning as in geom. The default value of 0 means that the automatically-generated skin passes through the centers of the body elements comprising the composite object. Positive values offset each skin vertex by the specified amount, in the direction normal to the (non-inflated) skin at that vertex. This has two uses. First, in 2D objects, a small positive inflate factor is needed to avoid aliasing artifacts. Second, collisions are done with geoms that create some thickness, even for 2D objects. Inflating the skin with a value equal to the geom size will render the skin as a "mattress" that better represents the actual collision geometry. The value of this attribute is copied into the corresponding attribute of the skin asset being created. This is only applicable to cloth and 2D grid types, and has no effect for any other composite type. The default value of 0 means that the skin has as many vertices as the number of element bodies. A positive value causes subdivision, with the specified number of (additional) grid lines. In this case the model compiler generates a denser skin using bi-cubic interpolation. This increases the quality of the rendering (especially in the absence of textures) but also slows down the renderer, so use it with caution. Values above 3 are unlikely to be needed. Type of geometric shape. The keywords have the following meaning: The **plane** type defines a surface which is infinite for collision detection purposes. It can only be attached to the world body or static children of the world. The plane passes through a point specified via the pos attribute. It is normal to the Z axis of the geom's local frame. The +Z direction corresponds to empty space. Thus the position and orientation defaults of (0,0,0) and (1,0,0,0) would create a ground plane at Z=0 elevation, with +Z being the vertical direction in the world (which is MuJoCo's convention). Since the plane is infinite, it could have been defined using any other point in the plane. The specified position however has additional meaning with regard to rendering. If either of the first two size parameters are positive, the plane is rendered as a rectangle of finite size (in the positive dimensions). This rectangle is centered at the specified position. Three size parameters are required. The first two specify the half- size of the rectangle along the X and Y axes. The third size parameter is unusual: it specifies the spacing between the grid subdivisions of the plane for rendering purposes. The subdivisions are revealed in wireframe rendering mode, but in general they should not be used to paint a grid over the ground plane (textures should be used for that purpose). Instead their role is to improve lighting and shadows, similar to the subdivisions used to render boxes. When planes are viewed from the back, the are automatically made semi-transparent. Planes and the +Z faces of boxes are the only surfaces that can show reflections, if the material applied to the geom has positive reflection. To render an infinite plane, set the first two size parameters to zero. The **hfield** type defines a height field geom. The geom must reference the desired height field asset with the hfield attribute below. The position and orientation of the geom set the position and orientation of the height field. The size of the geom is ignored, and the size parameters of the height field asset are used instead. See the description of the hfield element. Similar to planes, height field geoms can only be attached to the world body or to static children of the world. The **sphere** type defines a sphere. This and the next four types correspond to built-in geometric primitives. These primitives are treated as analytic surfaces for collision detection purposes, in many cases relying on custom pair- wise collision routines. Models including only planes, spheres, capsules and boxes are the most efficient in terms of collision detection. Other geom types invoke the general-purpose convex collider. The sphere is centered at the geom's position. Only one size parameter is used, specifying the radius of the sphere. Rendering of geometric primitives is done with automatically generated meshes whose density can be adjusted via quality. The sphere mesh is triangulated along the lines of latitude and longitude, with the Z axis passing through the north and south pole. This can be useful in wireframe mode for visualizing frame orientation. The **capsule** type defines a capsule, which is a cylinder capped with two half-spheres. It is oriented along the Z axis of the geom's frame. When the geom frame is specified in the usual way, two size parameters are required: the radius of the capsule followed by the half-height of the cylinder part. However capsules as well as cylinders can also be thought of as connectors, allowing an alternative specification with the fromto attribute below. In that case only one size parameter is required, namely the radius of the capsule. The **ellipsoid** type defines a ellipsoid. This is a sphere scaled separately along the X, Y and Z axes of the local frame. It requires three size parameters, corresponding to the three radii. Note that even though ellipsoids are smooth, their collisions are handled via the general-purpose convex collider. The only exception are plane-ellipsoid collisions which are computed analytically. The **cylinder** type defines a cylinder. It requires two size parameters: the radius and half-height of the cylinder. The cylinder is oriented along the Z axis of the geom's frame. It can alternatively be specified with the fromto attribute below. The **box** type defines a box. Three size parameters are required, corresponding to the half-sizes of the box along the X, Y and Z axes of the geom's frame. Note that box-box collisions can generate up to 8 contact points. The **mesh** type defines a mesh. The geom must reference the desired mesh asset with the mesh attribute. Note that mesh assets can also be referenced from other geom types, causing primitive shapes to be fitted; see below. The size is determined by the mesh asset and the geom size parameters are ignored. Unlike all other geoms, the position and orientation of mesh geoms after compilation do not equal the settings of the corresponding attributes here. Instead they are offset by the translation and rotation that were needed to center and align the mesh asset in its own coordinate frame. Recall the discussion of centering and alignment in the mesh element. The **sdf** type defines a signed distance field (SDF, also referred to as signed distance function). In order to visualize the SDF, a custom mesh must be specified using the mesh/plugin attribute. See the `model/plugin/sdf/ <https://github.com/google-deepmind/mujoco/tree/main/model/plugin/sdf>`__ directory for example models with SDF geometries. For more details regarding SDF plugins, see the Extensions chapter. This attribute and the next specify 32-bit integer bitmasks used for contact filtering of dynamically generated contact pairs. See Collision in the Computation chapter. Two geoms can collide if the contype of one geom is compatible with the conaffinity of the other geom or vice versa. Compatible means that the two bitmasks have a common bit set to 1. Bitmask for contact filtering; see contype above. The dimensionality of the contact space for a dynamically generated contact pair is set to the maximum of the condim values of the two participating geoms. See coContact in the Computation chapter. The allowed values and their meaning are: +--------+----------------------------------------------------------------------------------------------------------+ | condim | Description | +========+==========================================================================================================+ | 1 | Frictionless contact. | +--------+----------------------------------------------------------------------------------------------------------+ | 3 | Regular frictional contact, opposing slip in the tangent plane. | +--------+----------------------------------------------------------------------------------------------------------+ | 4 | Frictional contact, opposing slip in the tangent plane and rotation around the contact normal. This is | | | useful for modeling soft contacts (independent of contact penetration). | +--------+----------------------------------------------------------------------------------------------------------+ | 6 | Frictional contact, opposing slip in the tangent plane, rotation around the contact normal and rotation | | | around the two axes of the tangent plane. The latter frictional effects are useful for preventing | | | objects from indefinite rolling. | +--------+----------------------------------------------------------------------------------------------------------+ This attribute specifies an integer group to which the geom belongs. The only effect on the physics is at compile time, when body masses and inertias are inferred from geoms selected based on their group; see inertiagrouprange attribute of compiler. At runtime this attribute is used by the visualizer to enable and disable the rendering of entire geom groups. By default, groups 0, 1 and 2 are visible, while all other groups are invisible. The group attribute can also be used as a tag for custom computations. The geom priority determines how the properties of two colliding geoms are combined to form the properties of the contact. This interacts with the solmix attribute. See CContact. Geom size parameters. The number of required parameters and their meaning depends on the geom type as documented under the type attribute. Here we only provide a summary. All required size parameters must be positive; the internal defaults correspond to invalid settings. Note that when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh. In that case the sizes are obtained from the mesh, and the geom size parameters are ignored. Thus the number and description of required size parameters in the table below only apply to geoms that do not reference meshes. +---------+--------+------------------------------------------------------------------------------------------------+ | Type | Number | Description | +=========+========+================================================================================================+ | plane | 3 | X half-size; Y half-size; spacing between square grid lines for rendering. If either the X or Y| | | | half-size is 0, the plane is rendered as infinite in the dimension(s) with 0 size. | +---------+--------+------------------------------------------------------------------------------------------------+ | hfield | 0 | The geom sizes are ignored and the height field sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ | sphere | 1 | Radius of the sphere. | +---------+--------+------------------------------------------------------------------------------------------------+ | capsule | 1 or 2 | Radius of the capsule; half-length of the cylinder part when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ 3 | X radius; Y radius; Z radius. | +---------+--------+------------------------------------------------------------------------------------------------+ |cylinder | 1 or 2 | Radius of the cylinder; half-length of the cylinder when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ | box | 3 | X half-size; Y half-size; Z half-size. | +---------+--------+------------------------------------------------------------------------------------------------+ | mesh | 0 | The geom sizes are ignored and the mesh sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ If specified, this attribute applies a material to the geom. Otherwise, if unspecified and the type of the geom is a **mesh** the compiler will apply the mesh asset material if present. The material determines the visual properties of the geom. The only exception is color: if the rgba attribute below is different from its internal default, it takes precedence while the remaining material properties are still applied. Note that if the same material is referenced from multiple geoms (as well as sites and tendons) and the user changes some of its properties at runtime, these changes will take effect immediately for all model elements referencing the material. This is because the compiler saves the material and its properties as a separate element in mjModel, and the elements using this material only keep a reference to it. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. Contact friction parameters for dynamically generated contact pairs. The first number is the sliding friction, acting along both axes of the tangent plane. The second number is the torsional friction, acting around the contact normal. The third number is the rolling friction, acting around both axes of the tangent plane. The friction parameters for the contact pair are combined depending on the solmix and priority attributes, as explained in Contact parameters. See the general Contact section for descriptions of the semantics of this attribute. If this attribute is specified, the density attribute below is ignored and the geom density is computed from the given mass, using the geom shape and the assumption of uniform density. The computed density is then used to obtain the geom inertia. Recall that the geom mass and inertia are only used during compilation, to infer the body mass and inertia if necessary. At runtime only the body inertial properties affect the simulation; the geom mass and inertia are not saved in mjModel. Material density used to compute the geom mass and inertia. The computation is based on the geom shape and the assumption of uniform density. The internal default of 1000 is the density of water in SI units. This attribute is used only when the mass attribute above is unspecified. If `shellinertia` is "false" (the default), density has semantics of mass/volume; if "true", it has semantics of mass/area. This attribute specifies the weight used for averaging of contact parameters, and interacts with the priority attribute. See CContact. Constraint solver parameters for contact simulation. See CSolver. Constraint solver parameters for contact simulation. See CSolver. Distance threshold below which contacts are detected and included in the global array mjData.contact. This however does not mean that contact force will be generated. A contact is considered active only if the distance between the two geom surfaces is below margin-gap. Recall that constraint impedance can be a function of distance, as explained in CSolver. The quantity this function is applied to is the distance between the two geoms minus the margin plus the gap. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. Integer group to which the site belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of sites. Sizes of the geometric shape representing the site. Material used to specify the visual properties of the site. Color and transparency. If this value is different from the internal default, it overrides the corresponding material properties. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. All automatically generated model elements have names indicating the element type and index. For example, the body at coordinates (2, 0) in a 2D grid is named "B2_0" by default. If prefix="C" is specified, the same body is named "CB2_0". The prefix is needed when multiple composite objects are used in the same model, to avoid name conflicts. This attribute determines the type of composite object. The only supported type is cable. The **cable** type creates a 1D chain of bodies connected with ball joints, each having a geom with user-defined type (cylinder, capsule or box). The geometry can either be defined with an array of 3D vertex coordinates vertex or with prescribed functions with the option curve. Only linear and trigonometric functions are supported. For example, an helix can be obtained with curve="cos(s) sin(s) s". The size is set with the option size, resulting in f(s)=\{\text{size}[1]\cdot\cos(2\pi\cdot\text{size}[2]),\; \text{size}[1]\cdot\sin(2\pi\cdot\text{size}[2]),\; \text{size}[0]\cdot s\}. The element count in each dimension of the grid. This can have 1, 2 or 3 numbers, specifying the element count along the X, Y and Z axis of the parent body frame within. Any missing numbers default to 1. If any of these numbers is 1, all subsequent numbers must also be 1, so that the leading dimensions of the grid are used. This means for example that a 1D grid will always extend along the X axis. To achieve a different orientation, rotate the frame of the parent body. Note that some types imply a grid of certain dimensionality, so the requirements for this attribute depend on the specified type. It specifies a 3D offset from the center of the parent body to the center of the first body of the cable. The offset is expressed in the local coordinate frame of the parent body. Vertex 3D positions in global coordinates. Behavior of the first point. Free: free joint. Ball: ball joint. None: no dof. Functions specifying the vertex positions. Available functions are `s`, `cos(s)`, and `sin(s)`, where `s` is the arc length parameter. Scaling of the curve functions. `size[0]` is the scaling of `s`, `size[1]` is the radius of `\cos(s)` and `\sin(s)`, and `size[2]` is the speed of the argument (i.e. `\cos(2*\pi*size[2]*s)`). It specifies a quaternion that rotates the first body frame. The quaternion is expressed in the parent body frame. The type of equality constraint applied to this edge. If false, no equality constraint is applied. If true, then edge constraints are enforced. If vert, an averaged constraint is used, see flexvert. if strain, then a constraint is added to enforce that the invariants of the strain tensor do not change; this is only equality constraint type supported for trilinear and quadratic dofs elements and here. The standard constraint parameters, passed through to the automatically generated equality constraint. The standard constraint parameters, passed through to the automatically generated equality constraint. Edge stiffness and damping, passed through to the automatically generated flex. Edge stiffness and damping, passed through to the automatically generated flex. Young's elastic modulus, a measure of tensile and compressive stiffness for continuum elastic materials. Units of \textrm{pressure}=\textrm{force}/\textrm{area}. Poisson's ratio, the ratio of transverse deformation to applied longitudinal strain. This unitless quantity is in the range [0, 0.5). Small or large values imply compressibility or incompressiblity, respectively. Rayleigh's damping coefficient, units of time. This quantity scales the stiffness defined by Young's modulus to produce the damping matrix. Shell thickness, units of length; only for used 2D flexes. Used to scale the stretching stiffness. This thickness can be set equal to 2 times the radius in order to match the geometry, but is exposed separately since the radius might be constrained by considerations related to collision detection. Elastic contribution to passive forces of 2D flexes. "none": none, "bend": bending only, "stretch": stretching only, "both": bending and stretching. Enables or disables internal collisions which prevent flex self-penetration and element inversion. Note that flex elements that have shared vertices cannot collide (or else there will be permanent contacts). In 1D and 2D, internal collision checks rely on predefined vertex-element pairs, where the vertex is treated as a sphere with the same radius as the flex. These spheres correspond to non-shared vertices of neighboring elements on the periphery of the flex. The pre-defined vertex-element pairs are generated by the model compiler automatically. In 3D, internal collision checks are performed within each tetraheron: each vertex is collided with the plane corresponding to the opposing triangle face (again using the flex radius). The resulting contacts are always created with condim 1, gap 0, margin 0. Note that internal contacts modify the behavior implied by the elasticity parameters and is recommended only for flexes where element inversion cannot be prevented. This determines the strategy for midphase collision pruning of element pairs belonging to the same flex. **none** means flex elements cannot collide with each other. **narrow** means narrow phase only (i.e. all pairs are checked). This is a diagnostic tool and is never a good idea in practice. **bvh** and **sap** refer to bounding volume hierarchies and sweep-and-prune (which are two different strategies for midphase collision pruning). **auto** selects **sap** in 1D and 2D, and **bvh** in 3D. Which strategy performs better depends on the specifics of the model. The automatic setting is just a simple rule which we have found to perform well in general. This only has an effect for 3D flexes. Each tetrahedron is labeled by the model compiler with an integer corresponding to (graph) distance to the outside surface of the flex. Thus outside-facing elements are in layer 0, their neighbors are in layer 1, etc. This attribute specifies how many layers will be allowed to participate in collisions. The default setting 1 means that only one layer (i.e. layer 0) can collide, with itself and with the rest of the world. This is usually sufficient, however if the outer layer is composed of small tetrahedra, another body can "pierce" it and get stuck. In that case the value should be increased. When enabled, the contact is not added to the contact solver but it is instead used to compute passive (spring-damper) contact forces. All contacts, regardless of the specified condim, are frictionless (condim 1). This is an experimental feature. 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. Ranges of points to pin. Each range is specified by two integers. Grid coordinates of points to pin. This can only be used with type grid. Ranges of grid coordinates of points to pin. Each range is specified by (dim) integers for the minimum of the range followed by (dim) integers for the maximum of the range. This can only be used with type grid. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. The name of the flex element being generated automatically. This name is used as a prefix for all bodies that are automatically generated here, and is also referenced by the corresponding flex equality constraint (if applicable). This attribute determines the type of flexcomp object. The remaining attributes and sub-elements are then interpreted according to the type. Default settings are also adjusted depending on the type. Different types correspond to different methods for specifying the flexcomp points and the stretchable elements that connect them. They fall in three categories: direct specification entered in the XML, direct specification loaded from file, and automated generation from higher-level specification. **grid** generates a rectangular grid of points in 1D, 2D or 3D as specified by dim. The number of points in each dimension is determined by count while the grid spacing in each dimension is determined by spacing. Make sure the spacing is sufficiently large relative to radius to avoid permanent contacts. In 2D and 3D the grid is automatically triangulated, and corresponding flex elements are created (triangles or tetrahedra). In 1D the elements are capsules connecting consecutive pairs of points. **box** generates a 3D box object, however flex bodies are only generated on the outer shell. Each flex body has a radial slider joint allowing it to move in and out from the center of the box. The parent body would normally be a floating body. The box surface is triangulated, and each flex element is a tetrahedron connecting the center of the box with one triangle face. count and spacing determine the count and spacing of the flex bodies, similar to the **grid** type in 3D. Note that the resulting flex has the same topology as the box generated by composite. **cylinder** is the same as **box**, except the points are projected on the surface of a cylinder. **ellipsoid** is the same as **box**, except the points are projected on the surface of an ellipsoid. **disc** is the same as **box**, except the points are projected on the surface of a disc. It is only compatible with dim=2. **circle** is the same as **grid**, except the points are sampled along a circle so that the first and last points are the same. The radius of the circle is computed such that each segment has the requested spacing. It is only compatible with dim=1. **mesh** loads the flexcomp points and elements (i.e. triangles) from a mesh file, in the same file formats as mesh assets, excluding the legacy .msh format. A mesh asset is not actually added to the model. Instead the vertex and face data from the mesh file are used to populate the point and element data of the flexcomp. dim is automatically set to 2. Recall that a mesh asset in MuJoCo can be used as a rigid geom attached to a single body. In contrast, the flex generated here corresponds to a soft mesh with the same initial shape, where each vertex is a separate moving body (unless pinned). .. _gmsh-file-docs: **gmsh** is similar to mesh, but it loads a GMSH file in `format 4.1 <https://gmsh.info//doc/texinfo/gmsh.html#MSH-file-format>`__ and `format 2.2 <https://gmsh.info//doc/texinfo/gmsh.html#MSH-file-format-version-2-_0028Legacy_0029>`__ (ascii or binary). The file extension can be anything; the parser recognizes the format by examining the file header. This is a very rich file format, allowing all kinds of elements with different dimensionality and topology. MuJoCo only supports GMSH element types 1, 2, 4 which happen to correspond to our 1D, 2D and 3D flexes and assumes that the nodes are specified in a single block. Only the Nodes and Elements sections of the GMHS file are processed, and used to populate the point and element data of the flexcomp. The parser will generate an error if the GMSH file contains meshes that are not supported by MuJoCo. dim is automatically set to the dimensionality specified in the GMSH file. Presently this is the only mechanism to load a large tetrahedral mesh in MuJoCo and generate a corresponding soft entity. If such a mesh is available in a different file format, use the freely available `GMSH software <https://gmsh.info/>`__ to convert it to GMSH in one of the supported versions. **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 specifying the corresponding flex directly. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. Dimensionality of the flex object. This value must be 1, 2 or 3. The flex elements are capsules in 1D, triangles with radius in 2D, and tetrahedra with radius in 3D. Certain flexcomp types imply a dimensionality, in which case the value specified here is ignored. The parametrization of the flex's degrees of freedom (dofs). See the video on the right illustrating the different parametrizations with deformable spheres. The three models in the video are respectively `sphere_full <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_full.xml>`__, `sphere_radial <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_radial.xml>`__ and `sphere_trilinear <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_trilinear.xml>`__. **full** Three translational dofs per vertex. This is the most expressive but also the most expensive option. **radial** A single radial translational dof per vertex. Note that unlike in the "full" case, the radial parametrization requires a free joint at the flex's parent in order for free body motion to be possible. This type of parametrization is appropriate for shapes that are relatively spherical. **trilinear** Three translational dofs at each corner of the bounding box of the flex, for a total of 24 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using trilinear interpolation over the bounding box. :align: right :width: 240px Trilinear and quadratic flexes are much faster than the previous two options, and are the preferred choice if the expected deformations can be captured by the reduced parametriation. For example, see the video on the right comparing `full <https://github.com/google-deepmind/mujoco/blob/main/model/flex/gripper.xml>`__ and `trilinear <https://github.com/google-deepmind/mujoco/blob/main/model/flex/gripper_trilinear.xml>`__ flexes for modeling deformable gripper pads. Note that the choice of dof parametrization affects the deformation modes of the flex but has no effect on the accuracy of the collision geometry, which always takes into account the high-resolution mesh of the flex. **quadratic** Three translational dofs per corner, edge, face, and volume of the bounding box of the flex, for a total of 81 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using quadratic interpolation over the bounding box. While this option requires more degrees of freedom than trilinear flexes, it enables curved deformation modes, while the only modes achievable for trilinear flexes are strech/compression and shear. To understand the difference between the two parametrizations, see `a trilinear cube <https://github.com/google-deepmind/mujoco/blob/main/model/flex/trilinear.xml>`__ and `a quadratic cube <https://github.com/google-deepmind/mujoco/blob/main/model/flex/quadratic.xml>`__. Note that a higher interpolation order generally requires a smaller time step for stability, although usually not as large as with the "full" option and a fine mesh. Specifies the number of automatically generated points in each dimension for types **grid**, **box**, **cylinder**, and **ellipsoid**. Specifies the number of cells in each dimension for the background interpolation grid when using **trilinear** or **quadratic** dofs. The spacing between the automatically generated points in each dimension. The spacing should be sufficiently large compared to the radius, to avoid permanent contacts. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. If this is true, all points correspond to vertices within the parent body, and no new bodies are created. This is equivalent to pinning all points. Note that if all points are indeed pinned, the model compiler will detect that the flex is rigid (which behaves is a non-convex mesh in collision detection). The mass of each automatically-generated body equals this value divided by the number of points. Note that pinning some points does not affect the mass of the other bodies. Even though the automatically-generated bodies have the physics of point masses, with slider joints, MuJoCo still requires each body to have rotational inertia. The inertias generated here are diagonal, and are computed such that the corresponding equivalent-inertia boxes have sides equal to this value. Scaling of all point coordinates, for types that specify coordinates explicitly. Scaling is applied after the pose transformation. The name of the file from which a **surface** (triangular) or **volumetric** (tetrahedral) mesh is loaded. For surface meshes, the file extension is used to determine the file format. Supported formats are GMSH and the formats specified in mesh assets, excluding the legacy .msh format. Volumetric meshes are supported only in GMSH format. See here for more information on GMSH files. The 3D coordinates of the points. This attribute is only used with type **direct**. All other flexcomp types generate their own points. The points are used to construct bodies and vertices as explained earlier. The zero-based point ids forming each flex elements. This attribute is only used with type **direct**. All other flexcomp types generate their own elements. This data is passed through to the automatically-generated flex. Texture coordinates of each point, passed through to the automatically-generated flex. Note that flexcomp does not generate texture coordinates automatically, except for 2D grids, box, cylinder and ellipsoid. For all other types, the user can specify explicit texture coordinates here, even if the points themselves were generated automatically. This requires understanding of the layout of the automatically-generated points and how they correspond to the texture referenced by the material. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. This 3D vector translates all points relative to the frame of the parent body. This is a quaternion rotation of all points around the pos vector specified above. Together these two vectors define a pose transformation, used to position and orient the points as needed. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. The origin of the flexcomp. Used for generating a volumetric mesh from an OBJ surface mesh. Each surface triangle is connected to the origin to create a tetrahedron, so the resulting volumetric mesh is guaranteed to be well-formed only for convex shapes. Name of the frame. If this attribute is present, all descendant elements that admit a defaults class will use the class specified here, unless they specify their own class or another frame or body with a childclass attribute is encountered along the chain of nested bodies and frames. Recall CDefault. The 3D position of the frame, in the parent coordinate system. See COrientation. See COrientation. See COrientation. See COrientation. See COrientation. Position of the inertial frame. This attribute is required even when the inertial properties can be inferred from geoms. This is because the presence of the inertial element itself disables the automatic inference mechanism. Orientation of the inertial frame. See COrientation. Mass of the body. Negative values are not allowed. MuJoCo requires the inertia matrix in generalized coordinates to be positive-definite, which can sometimes be achieved even if some bodies have zero mass. In general however there is no reason to use massless bodies. Such bodies are often used in other engines to bypass the limitation that joints cannot be combined, or to attach sensors and cameras. In MuJoCo primitive joint types can be combined, and we have sites which are a more efficient attachment mechanism. Diagonal inertia matrix, expressing the body inertia relative to the inertial frame. If this attribute is omitted, the next attribute becomes required. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Orientation of the inertial frame. See COrientation. Full inertia matrix M. Since M is 3-by-3 and symmetric, it is specified using only 6 numbers in the following order: M(1,1), M(2,2), M(3,3), M(1,2), M(1,3), M(2,3). The compiler computes the eigenvalue decomposition of M and sets the frame orientation and diagonal inertia accordingly. If non-positive eigenvalues are encountered (i.e., if M is not positive definite) a compile error is generated. Name of the joint. Defaults class for setting unspecified attributes. Type of the joint. The keywords have the following meaning: The **free** type creates a free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits. The **ball** type creates a ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed. The **slide** type creates a sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes. The **hinge** type creates a hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. Position of the joint, specified in the frame of the body where the joint is defined. For free joints this attribute is ignored. This attribute specifies the axis of rotation for hinge joints and the direction of translation for slide joints. It is ignored for free and ball joints. The vector specified here is automatically normalized to unit length as long as its length is greater than 10E-14; otherwise a compile error is generated. When both numbers are positive, the compiler will override any stiffness and damping values specified with the attributes below, and will instead set them automatically so that the resulting mass-spring-damper for this joint has the desired time constant (first value) and damping ratio (second value). This is done by taking into account the joint inertia in the model reference configuration. Note that the format is the same as the solref parameter of the constraint solver. This attribute specifies if the joint has limits. It interacts with the range attribute. If this attribute is "false", joint limits are disabled. If this attribute is "true", joint limits are enabled. If this attribute is "auto", and autolimits is set in compiler, joint limits will be enabled if range is defined. This attribute specifies whether actuator forces acting on the joint should be clamped. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. This attribute interacts with the actuatorfrcrange attribute. If this attribute is "false", actuator force clamping is disabled. If it is "true", actuator force clamping is enabled. If this attribute is "auto", and autolimits is set in compiler, actuator force clamping will be enabled if actuatorfrcrange is defined. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating dry friction. See also Friction. Constraint solver parameters for simulating dry friction. See also Friction. Joint stiffness coefficients a, b, c. A positive a produces the standard restorative linear spring force f = -a x, where x is the joint displacement from equilibrium given by springref. If the optional second and third components are set, they define a nonlinear polynomial spring force f(x) = -(a x + b x^2 + c x^3). See Polynomial forces for details. The joint limits. Limits can be imposed on all joint types except for free joints. For hinge and ball joints, the range is specified in degrees or radians depending on the angle attribute of compiler. For ball joints, the limit is imposed on the angle of rotation (relative to the reference configuration) regardless of the axis of rotation. Only the second range parameter is used for ball joints; the first range parameter should be set to 0. See the Limit section in the Computation chapter for more information. Setting this attribute without specifying limited is an error if autolimits is "false" in compiler. Range for clamping total actuator forces acting on this joint. See CForceRange for details. It is available only for scalar joints (hinge and slider) and ignored for ball and free joints. The compiler expects the first value to be smaller than the second value. Setting this attribute without specifying actuatorfrclimited is an error if compiler-autolimits is "false". If this flag is enabled, gravity compensation applied to this joint is added to actuator forces (mjData.qfrc_actuator) rather than passive forces (mjData.qfrc_passive). Notionally, this means that gravity compensation is the result of a control system rather than natural buoyancy. In practice, enabling this flag is useful when joint-level actuator force clamping is used. In this case, the total actuation force applied on a joint, including gravity compensation, is guaranteed to not exceed the specified limits. See CForceRange and actuatorfrcrange for more details on this type of force limit. The distance threshold below which limits become active. Recall that the Constraint solver normally generates forces as soon as a constraint becomes active, even if the margin parameter makes that happen at a distance. This attribute together with solreflimit and solimplimit can be used to model a soft joint limit. The reference position or angle of the joint. This attribute is only used for slide and hinge joints. It defines the joint value corresponding to the initial model configuration. Note that the initial configuration itself is unmodified, only the value of the joint at this configuration. The amount of spatial transformation that the joint applies at runtime equals the current joint value stored in mjData.qpos minus this reference value stored in mjModel.qpos0. The meaning of these vectors is discussed in the Kinematic tree section in the Overview chapter. The joint position or angle in which the joint spring (if any) achieves equilibrium. Similar to the vector mjModel.qpos0 which stores all joint reference values specified with the ref attribute above, all spring reference values specified with this attribute are stored in the vector mjModel.qpos_spring. The model configuration corresponding to mjModel.qpos_spring is also used to compute the spring reference lengths of all tendons, stored in mjModel.tendon_lengthspring. This is because tendons can also have springs. Additional inertia associated with movement of the joint that is not due to body mass. This added inertia is usually due to a rotor (a.k.a `armature <https://en.wikipedia.org/wiki/Armature_(electrical)>`__) spinning faster than the joint itself due to a geared transmission. In the illustration, we compare (*left*) a 2-dof system with an armature body (purple box), coupled with a gear ratio of 3 to the pendulum using a joint equality constraint, and (*right*) a simple 1-dof pendulum with an equivalent armature. Because the gear ratio appears twice, multiplying both forces and lengths, the effect is known as "reflected inertia" and the equivalent value is the inertia of the spinning body multiplied by the *square of the gear ratio*, in this case 9=3^2. The value applies to all degrees of freedom created by this joint. Besides increasing the realism of joints with geared transmission, positive armature significantly improves simulation stability, even for small values, and is a recommended possible fix when encountering stability issues. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v, where v is the joint velocity. Despite its simplicity, larger damping values can make numerical integrators unstable, which is why our Euler integrator handles damping implicitly. See Integration in the Computation chapter. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Friction loss due to dry friction. This value is the same for all degrees of freedom created by this joint. Semantically friction loss does not make sense for free joints, but the compiler allows it. To enable friction loss, set this attribute to a positive value. See CUser. Name of the joint. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. When set to true, the body frame and free joint will automatically be aligned with inertial frame. When set to false, no alignment will occur. When set to auto, the compiler's alignfree global attribute will be respected. Inertial frame alignment is an optimization only applies to bodies with a free joint and no child bodies ("simple free bodies"). The alignment diagonalizes the 6x6 inertia matrix and minimizes bias forces, leading to faster and more stable simulation. While this behaviour is a strict improvement, it modifies the semantics of the free joint, making qpos and qvel values saved in older versions (for example, in keyframes) invalid. Note that the align attribute is never saved to XML. Instead, the pose of simple free bodies and their children will be modified such that the body frame and inertial frame are aligned. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. Name of the geom. Defaults class for setting unspecified attributes. Type of geometric shape. The keywords have the following meaning: The **plane** type defines a surface which is infinite for collision detection purposes. It can only be attached to the world body or static children of the world. The plane passes through a point specified via the pos attribute. It is normal to the Z axis of the geom's local frame. The +Z direction corresponds to empty space. Thus the position and orientation defaults of (0,0,0) and (1,0,0,0) would create a ground plane at Z=0 elevation, with +Z being the vertical direction in the world (which is MuJoCo's convention). Since the plane is infinite, it could have been defined using any other point in the plane. The specified position however has additional meaning with regard to rendering. If either of the first two size parameters are positive, the plane is rendered as a rectangle of finite size (in the positive dimensions). This rectangle is centered at the specified position. Three size parameters are required. The first two specify the half- size of the rectangle along the X and Y axes. The third size parameter is unusual: it specifies the spacing between the grid subdivisions of the plane for rendering purposes. The subdivisions are revealed in wireframe rendering mode, but in general they should not be used to paint a grid over the ground plane (textures should be used for that purpose). Instead their role is to improve lighting and shadows, similar to the subdivisions used to render boxes. When planes are viewed from the back, the are automatically made semi-transparent. Planes and the +Z faces of boxes are the only surfaces that can show reflections, if the material applied to the geom has positive reflection. To render an infinite plane, set the first two size parameters to zero. The **hfield** type defines a height field geom. The geom must reference the desired height field asset with the hfield attribute below. The position and orientation of the geom set the position and orientation of the height field. The size of the geom is ignored, and the size parameters of the height field asset are used instead. See the description of the hfield element. Similar to planes, height field geoms can only be attached to the world body or to static children of the world. The **sphere** type defines a sphere. This and the next four types correspond to built-in geometric primitives. These primitives are treated as analytic surfaces for collision detection purposes, in many cases relying on custom pair- wise collision routines. Models including only planes, spheres, capsules and boxes are the most efficient in terms of collision detection. Other geom types invoke the general-purpose convex collider. The sphere is centered at the geom's position. Only one size parameter is used, specifying the radius of the sphere. Rendering of geometric primitives is done with automatically generated meshes whose density can be adjusted via quality. The sphere mesh is triangulated along the lines of latitude and longitude, with the Z axis passing through the north and south pole. This can be useful in wireframe mode for visualizing frame orientation. The **capsule** type defines a capsule, which is a cylinder capped with two half-spheres. It is oriented along the Z axis of the geom's frame. When the geom frame is specified in the usual way, two size parameters are required: the radius of the capsule followed by the half-height of the cylinder part. However capsules as well as cylinders can also be thought of as connectors, allowing an alternative specification with the fromto attribute below. In that case only one size parameter is required, namely the radius of the capsule. The **ellipsoid** type defines a ellipsoid. This is a sphere scaled separately along the X, Y and Z axes of the local frame. It requires three size parameters, corresponding to the three radii. Note that even though ellipsoids are smooth, their collisions are handled via the general-purpose convex collider. The only exception are plane-ellipsoid collisions which are computed analytically. The **cylinder** type defines a cylinder. It requires two size parameters: the radius and half-height of the cylinder. The cylinder is oriented along the Z axis of the geom's frame. It can alternatively be specified with the fromto attribute below. The **box** type defines a box. Three size parameters are required, corresponding to the half-sizes of the box along the X, Y and Z axes of the geom's frame. Note that box-box collisions can generate up to 8 contact points. The **mesh** type defines a mesh. The geom must reference the desired mesh asset with the mesh attribute. Note that mesh assets can also be referenced from other geom types, causing primitive shapes to be fitted; see below. The size is determined by the mesh asset and the geom size parameters are ignored. Unlike all other geoms, the position and orientation of mesh geoms after compilation do not equal the settings of the corresponding attributes here. Instead they are offset by the translation and rotation that were needed to center and align the mesh asset in its own coordinate frame. Recall the discussion of centering and alignment in the mesh element. The **sdf** type defines a signed distance field (SDF, also referred to as signed distance function). In order to visualize the SDF, a custom mesh must be specified using the mesh/plugin attribute. See the `model/plugin/sdf/ <https://github.com/google-deepmind/mujoco/tree/main/model/plugin/sdf>`__ directory for example models with SDF geometries. For more details regarding SDF plugins, see the Extensions chapter. This attribute and the next specify 32-bit integer bitmasks used for contact filtering of dynamically generated contact pairs. See Collision in the Computation chapter. Two geoms can collide if the contype of one geom is compatible with the conaffinity of the other geom or vice versa. Compatible means that the two bitmasks have a common bit set to 1. Bitmask for contact filtering; see contype above. The dimensionality of the contact space for a dynamically generated contact pair is set to the maximum of the condim values of the two participating geoms. See coContact in the Computation chapter. The allowed values and their meaning are: +--------+----------------------------------------------------------------------------------------------------------+ | condim | Description | +========+==========================================================================================================+ | 1 | Frictionless contact. | +--------+----------------------------------------------------------------------------------------------------------+ | 3 | Regular frictional contact, opposing slip in the tangent plane. | +--------+----------------------------------------------------------------------------------------------------------+ | 4 | Frictional contact, opposing slip in the tangent plane and rotation around the contact normal. This is | | | useful for modeling soft contacts (independent of contact penetration). | +--------+----------------------------------------------------------------------------------------------------------+ | 6 | Frictional contact, opposing slip in the tangent plane, rotation around the contact normal and rotation | | | around the two axes of the tangent plane. The latter frictional effects are useful for preventing | | | objects from indefinite rolling. | +--------+----------------------------------------------------------------------------------------------------------+ This attribute specifies an integer group to which the geom belongs. The only effect on the physics is at compile time, when body masses and inertias are inferred from geoms selected based on their group; see inertiagrouprange attribute of compiler. At runtime this attribute is used by the visualizer to enable and disable the rendering of entire geom groups. By default, groups 0, 1 and 2 are visible, while all other groups are invisible. The group attribute can also be used as a tag for custom computations. The geom priority determines how the properties of two colliding geoms are combined to form the properties of the contact. This interacts with the solmix attribute. See CContact. Geom size parameters. The number of required parameters and their meaning depends on the geom type as documented under the type attribute. Here we only provide a summary. All required size parameters must be positive; the internal defaults correspond to invalid settings. Note that when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh. In that case the sizes are obtained from the mesh, and the geom size parameters are ignored. Thus the number and description of required size parameters in the table below only apply to geoms that do not reference meshes. +---------+--------+------------------------------------------------------------------------------------------------+ | Type | Number | Description | +=========+========+================================================================================================+ | plane | 3 | X half-size; Y half-size; spacing between square grid lines for rendering. If either the X or Y| | | | half-size is 0, the plane is rendered as infinite in the dimension(s) with 0 size. | +---------+--------+------------------------------------------------------------------------------------------------+ | hfield | 0 | The geom sizes are ignored and the height field sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ | sphere | 1 | Radius of the sphere. | +---------+--------+------------------------------------------------------------------------------------------------+ | capsule | 1 or 2 | Radius of the capsule; half-length of the cylinder part when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ 3 | X radius; Y radius; Z radius. | +---------+--------+------------------------------------------------------------------------------------------------+ |cylinder | 1 or 2 | Radius of the cylinder; half-length of the cylinder when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ | box | 3 | X half-size; Y half-size; Z half-size. | +---------+--------+------------------------------------------------------------------------------------------------+ | mesh | 0 | The geom sizes are ignored and the mesh sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ If specified, this attribute applies a material to the geom. Otherwise, if unspecified and the type of the geom is a **mesh** the compiler will apply the mesh asset material if present. The material determines the visual properties of the geom. The only exception is color: if the rgba attribute below is different from its internal default, it takes precedence while the remaining material properties are still applied. Note that if the same material is referenced from multiple geoms (as well as sites and tendons) and the user changes some of its properties at runtime, these changes will take effect immediately for all model elements referencing the material. This is because the compiler saves the material and its properties as a separate element in mjModel, and the elements using this material only keep a reference to it. Contact friction parameters for dynamically generated contact pairs. The first number is the sliding friction, acting along both axes of the tangent plane. The second number is the torsional friction, acting around the contact normal. The third number is the rolling friction, acting around both axes of the tangent plane. The friction parameters for the contact pair are combined depending on the solmix and priority attributes, as explained in Contact parameters. See the general Contact section for descriptions of the semantics of this attribute. If this attribute is specified, the density attribute below is ignored and the geom density is computed from the given mass, using the geom shape and the assumption of uniform density. The computed density is then used to obtain the geom inertia. Recall that the geom mass and inertia are only used during compilation, to infer the body mass and inertia if necessary. At runtime only the body inertial properties affect the simulation; the geom mass and inertia are not saved in mjModel. Material density used to compute the geom mass and inertia. The computation is based on the geom shape and the assumption of uniform density. The internal default of 1000 is the density of water in SI units. This attribute is used only when the mass attribute above is unspecified. If `shellinertia` is "false" (the default), density has semantics of mass/volume; if "true", it has semantics of mass/area. If true, the geom's inertia is computed assuming that all the mass is concentrated on the surface. In this case density is interpreted as surface rather than volumetric density. This attribute only applies to primitive geoms and is ignored for meshes. Surface inertia for meshes can be specified by setting the asset/mesh/inertia attribute to "shell". This attribute specifies the weight used for averaging of contact parameters, and interacts with the priority attribute. See CContact. Constraint solver parameters for contact simulation. See CSolver. Constraint solver parameters for contact simulation. See CSolver. Distance threshold below which contacts are detected and included in the global array mjData.contact. This however does not mean that contact force will be generated. A contact is considered active only if the distance between the two geom surfaces is below margin-gap. Recall that constraint impedance can be a function of distance, as explained in CSolver. The quantity this function is applied to is the distance between the two geoms minus the margin plus the gap. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. :width: 350px :align: right This attribute can only be used with capsule, box, cylinder and ellipsoid geoms. It provides an alternative specification of the geom length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the geom connects these two points, with the +Z axis of the geom's frame oriented from the first towards the second point, while in the perpendicular direction, the geom sizes are both equal to the first value of the size attribute. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the end points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. The image on the right demonstrates use of fromto with the four supported geoms, using identical Z values. The model is `here <_static/fromto.xml>`__. Note that the fromto semantics of *capsule* are unique: the two end points specify the segment around which the radius defines the capsule surface. Position of the geom, specified in the frame of the body where the geom is defined. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. Orientation of the geom frame. See COrientation. This attribute must be specified if and only if the geom type is "hfield". It references the height field asset to be instantiated at the position and orientation of the geom frame. If the geom type is "mesh", this attribute is required. It references the mesh asset to be instantiated. This attribute can also be specified if the geom type corresponds to a geometric primitive, namely one of "sphere", "capsule", "cylinder", "ellipsoid", "box". In that case the primitive is automatically fitted to the mesh asset referenced here. The fitting procedure uses either the equivalent inertia box or the axis-aligned bounding box of the mesh, as determined by the attribute fitaabb of compiler. The resulting size of the fitted geom is usually what one would expect, but if not, it can be further adjusted with the fitscale attribute below. In the compiled mjModel the geom is represented as a regular geom of the specified primitive type, and there is no reference to the mesh used for fitting. This attribute is used only when a primitive geometric type is being fitted to a mesh asset. The scale specified here is relative to the output of the automated fitting procedure. The default value of 1 leaves the result unchanged, a value of 2 makes all sizes of the fitted geom two times larger. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. "ellipsoid" activates the geom-level fluid interaction model based on an ellipsoidal approximation of the geom shape. When active, the model based on body inertia sizes is disabled for the body in which the geom is defined. See section on ellipsoid-based fluid interaction model for details. Dimensionless coefficients of fluid interaction model, as follows. See section on ellipsoid-based fluid interaction model for details. See CUser. The sub-model from which to attach a subtree. Name of the body in the sub-model to attach here. The body and its subtree will be attached. If this attribute is not specified, the contents of the world body will be attached in a new frame. Prefix to prepend to names of elements in the sub-model. This attribute is required to prevent name collisions with the parent or when attaching the same sub-tree multiple times. Name of the site. Defaults class for setting unspecified attributes. Type of geometric shape. This is used for rendering, and also determines the active sensor zone for touch sensors. Integer group to which the site belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of sites. Position of the site frame. Orientation of the site frame. See COrientation. Material used to specify the visual properties of the site. Sizes of the geometric shape representing the site. This attribute can only be used with capsule, cylinder, ellipsoid and box sites. It provides an alternative specification of the site length as well as the frame position and orientation. The six numbers are the 3D coordinates of one point followed by the 3D coordinates of another point. The elongated part of the site connects these two points, with the +Z axis of the site's frame oriented from the first towards the second point. The frame orientation is obtained with the same procedure as the zaxis attribute described in Frame orientations. The frame position is in the middle between the two points. If this attribute is specified, the remaining position and orientation-related attributes are ignored. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Orientation of the site frame. See COrientation. Color and transparency. If this value is different from the internal default, it overrides the corresponding material properties. See CUser. Name of the camera. Defaults class for setting unspecified attributes. Whether the camera uses a perspective (the default) or orthographic projection. Setting this attribute to "orthographic" changes the semantic of the fovy attribute, see below. Vertical field-of-view of the camera. If the camera uses a perspective projection, the field-of-view is expressed in degrees, regardless of the global compiler/angle setting. If the camera uses an orthographic projection, the field-of-view is expressed in units of length; note that in this case the default of 45 is too large for most scenes and should likely be reduced. In either case, the horizontal field of view is computed automatically given the window size and the vertical field of view. Inter-pupilary distance. This attribute only has an effect during stereoscopic rendering. It specifies the distance between the left and right viewpoints. Each viewpoint is shifted by +/- half of the distance specified here, along the X axis of the camera frame. Resolution of the camera in pixels [width height]. Note that these values are not used for rendering since those dimensions are determined by the size of the rendering context. This attribute serves as a convenient location to save the required resolution. Setting either value larger than 1 enables frustum visualization when the mjVIS_CAMERA visualization flag is active. Types of output images supported by the camera. - rgb: RGB image. - depth: Depth image (distance from camera plane). - distance: Distance image (distance from camera origin). - normal: Surface normal image. - segmentation: Segmentation image. This attribute is not used for rendering, but serves as a convenient location to save the output types supported by the camera. The output attribute can contain multiple types, e.g. "rgb normal". Position of the camera frame. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. Orientation of the camera frame. See COrientation. Note that specifically for cameras, the xyaxes attribute is semantically convenient as the X and Y axes correspond to the directions "right" and "up" in pixel space, respectively. This attribute specifies how the camera position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the camera sees). "fixed" means that the position and orientation specified below are fixed relative to the body where the camera is defined. "track" means that the camera position is at a constant offset from the body in world coordinates, while the camera orientation is constant in world coordinates. These constants are determined by applying forward kinematics in qpos0 and treating the camera as fixed. Tracking can be used for example to position a camera above a body, point it down so it sees the body, and have it always remain above the body no matter how the body translates and rotates. "trackcom" is similar to "track" but the constant spatial offset is defined relative to the center of mass of the kinematic subtree starting at the body in which the camera is defined. This can be used to keep an entire mechanism in view. Note that the subtree center of mass for the world body is the center of mass of the entire model. So if a camera is defined in the world body in mode "trackcom", it will track the entire model. "targetbody" means that the camera position is fixed in the body frame, while the camera orientation is adjusted so that it always points towards the targeted body (which is specified with the target attribute below). This can be used for example to model an eye that fixates a moving object; the object will be the target, and the camera/eye will be defined in the body corresponding to the head. "targetbodycom" is the same as "targetbody" but the camera is oriented towards the center of mass of the subtree starting at the target body. When the camera mode is "targetbody" or "targetbodycom", this attribute becomes required. It specifies which body should be targeted by the camera. In all other modes this attribute is ignored. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Focal length in physical length units or in pixels, respectively. If both are specified, the pixel value is used and the length value is ignored. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Offset of the principal point (optical axis intersection with the image plane) from the image center. If both are specified, the pixel value is used. At zero offset, the rendered image is centered on the camera's negative Z axis, as in a standard pinhole camera model. Size of the camera sensor in length units. When specified, all intrinsic attributes become active and fovy is ignored. The field-of-view is then computed automatically from the focal length and sensor size. See CUser. Name of the light. Defaults class for setting unspecified attributes. This is a deprecated legacy attribute. Please use light type instead. If set to "true", and no type is specified, this will change the light type to be directional. Determines the type of light. Note that some light types may not be supported by some renderers (e.g. only spot and directional lights are supported by the default native renderer). If this attribute is "true" the light will cast shadows. More precisely, the geoms illuminated by the light will cast shadows, however this is a property of lights rather than geoms. Since each shadow-casting light causes one extra rendering pass through all geoms, this attribute should be used with caution. Higher quality of the shadows is achieved by increasing the value of the shadowsize attribute of quality, as well as positioning spotlights closer to the surface on which shadows appear, and limiting the volume in which shadows are cast. For spotlights this volume is a cone, whose angle is the cutoff attribute below multiplied by the shadowscale attribute of map. For directional lights this volume is a box, whose half-sizes in the directions orthogonal to the light are the model extent multiplied by the shadowclip attribute of map. The model extent is computed by the compiler but can also be overridden by specifying the extent attribute of statistic. Internally the shadow-mapping mechanism renders the scene from the light viewpoint (as if it were a camera) into a depth texture, and then renders again from the camera viewpoint, using the depth texture to create shadows. The internal rendering pass uses the same near and far clipping planes as regular rendering, i.e., these clipping planes bound the cone or box shadow volume in the light direction. As a result, some shadows (especially those very close to the light) may be clipped. The light is active if this attribute is "true". This can be used at runtime to turn lights on and off. Position of the light. This attribute only affects the rendering for spotlights, but it should also be defined for directional lights because we render the cameras as decorative elements. Direction of the light. The radius of the light source which can affect shadow softness depending on the renderer. This only applies to spotlights. The intensity of the light source, measured in candela, used for physically-based lighting models. This is unused by the default Phong lighting model. The effective range of the light. Objects further than this distance from the light position will not be illuminated by this light. This only applies to spotlights. These are the constant, linear and quadratic attenuation coefficients for Phong lighting. The default corresponds to no attenuation. Cutoff angle for spotlights, always in degrees regardless of the global angle setting. Exponent for spotlights. This setting controls the softness of the spotlight cutoff. The ambient color of the light, used by the default Phong lighting model. The color of the light. For the Phong (default) lighting model, this defines the diffuse color of the light. The specular color of the light, used by the default Phong lighting model. This is identical to the mode attribute of camera above. It specifies the how the light position and orientation in world coordinates are computed in forward kinematics (which in turn determine what the light illuminates). This is identical to the target attribute of camera above. It specifies which body should be targeted in "targetbody" and "targetbodycom" modes. The texture to use for image-based lighting. This is unused by the default Phong lighting model. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. The joint kind here is orthogonal to the joint type in the rest of MJCF. The joint kind refers to the function of the joint within the mechanism comprising the composite body, while the joint type (hinge or slide) is implied by the joint kind and composite body type. The **main** kind corresponds to the main joints forming each composite type. These joints are automatically included in the model even if the joint sub-element is missing. The main joints are 3D sliders for particle and grid; 1D sliders for box, cylinder and rope; universal joints for cloth, rope and loop. Even though the main joints are included automatically, this sub-element is still useful for adjusting their attributes. Integer group to which the joint belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of joints. Joint stiffness coefficients a, b, c. A positive a produces the standard restorative linear spring force f = -a x, where x is the joint displacement from equilibrium given by springref. If the optional second and third components are set, they define a nonlinear polynomial spring force f(x) = -(a x + b x^2 + c x^3). See Polynomial forces for details. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v, where v is the joint velocity. Despite its simplicity, larger damping values can make numerical integrators unstable, which is why our Euler integrator handles damping implicitly. See Integration in the Computation chapter. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Additional inertia associated with movement of the joint that is not due to body mass. This added inertia is usually due to a rotor (a.k.a `armature <https://en.wikipedia.org/wiki/Armature_(electrical)>`__) spinning faster than the joint itself due to a geared transmission. In the illustration, we compare (*left*) a 2-dof system with an armature body (purple box), coupled with a gear ratio of 3 to the pendulum using a joint equality constraint, and (*right*) a simple 1-dof pendulum with an equivalent armature. Because the gear ratio appears twice, multiplying both forces and lengths, the effect is known as "reflected inertia" and the equivalent value is the inertia of the spinning body multiplied by the *square of the gear ratio*, in this case 9=3^2. The value applies to all degrees of freedom created by this joint. Besides increasing the realism of joints with geared transmission, positive armature significantly improves simulation stability, even for small values, and is a recommended possible fix when encountering stability issues. These are the solref and solimp attributes used to equality-constrain the joint. Whether or not a given joint is quality-constrained depends on the joint kind and composite object type as explained above. For joints that are not equality-constrained, this attribute has no effect. The defaults are adjusted depending on the composite type. Otherwise these attributes obey the same rules as all other solref and solimp attributes in MJCF. See Solver parameters. These are the solref and solimp attributes used to equality-constrain the joint. Whether or not a given joint is quality-constrained depends on the joint kind and composite object type as explained above. For joints that are not equality-constrained, this attribute has no effect. The defaults are adjusted depending on the composite type. Otherwise these attributes obey the same rules as all other solref and solimp attributes in MJCF. See Solver parameters. Type of the joint. The keywords have the following meaning: The **free** type creates a free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits. The **ball** type creates a ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed. The **slide** type creates a sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes. The **hinge** type creates a hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints. This attribute specifies the axis of rotation for hinge joints and the direction of translation for slide joints. It is ignored for free and ball joints. The vector specified here is automatically normalized to unit length as long as its length is greater than 10E-14; otherwise a compile error is generated. This attribute specifies if the joint has limits. It interacts with the range attribute. If this attribute is "false", joint limits are disabled. If this attribute is "true", joint limits are enabled. If this attribute is "auto", and autolimits is set in compiler, joint limits will be enabled if range is defined. The joint limits. Limits can be imposed on all joint types except for free joints. For hinge and ball joints, the range is specified in degrees or radians depending on the angle attribute of compiler. For ball joints, the limit is imposed on the angle of rotation (relative to the reference configuration) regardless of the axis of rotation. Only the second range parameter is used for ball joints; the first range parameter should be set to 0. See the Limit section in the Computation chapter for more information. Setting this attribute without specifying limited is an error if autolimits is "false" in compiler. The distance threshold below which limits become active. Recall that the Constraint solver normally generates forces as soon as a constraint becomes active, even if the margin parameter makes that happen at a distance. This attribute together with solreflimit and solimplimit can be used to model a soft joint limit. Constraint solver parameters for simulating joint limits. See CSolver. Constraint solver parameters for simulating joint limits. See CSolver. Friction loss due to dry friction. This value is the same for all degrees of freedom created by this joint. Semantically friction loss does not make sense for free joints, but the compiler allows it. To enable friction loss, set this attribute to a positive value. Constraint solver parameters for simulating dry friction. See also Friction. Constraint solver parameters for simulating dry friction. See also Friction. If this is true, explicit texture coordinates will be generated, mapping the skin to the unit square in texture space. This is needed when the material specifies a texture. If texcoord is false and the skin has texture, the texture will appear fixed to the world instead of the skin. The reason for having this attribute in the first place is because skins with texture coordinates upload these coordinates to the GPU even if no texture is applied later. So this attribute should be set to false in cases where no texture will be applied via the material attribute. Same meaning as in geom. Same meaning as in geom. Same meaning as in geom. The default value of 0 means that the automatically-generated skin passes through the centers of the body elements comprising the composite object. Positive values offset each skin vertex by the specified amount, in the direction normal to the (non-inflated) skin at that vertex. This has two uses. First, in 2D objects, a small positive inflate factor is needed to avoid aliasing artifacts. Second, collisions are done with geoms that create some thickness, even for 2D objects. Inflating the skin with a value equal to the geom size will render the skin as a "mattress" that better represents the actual collision geometry. The value of this attribute is copied into the corresponding attribute of the skin asset being created. This is only applicable to cloth and 2D grid types, and has no effect for any other composite type. The default value of 0 means that the skin has as many vertices as the number of element bodies. A positive value causes subdivision, with the specified number of (additional) grid lines. In this case the model compiler generates a denser skin using bi-cubic interpolation. This increases the quality of the rendering (especially in the absence of textures) but also slows down the renderer, so use it with caution. Values above 3 are unlikely to be needed. Type of geometric shape. The keywords have the following meaning: The **plane** type defines a surface which is infinite for collision detection purposes. It can only be attached to the world body or static children of the world. The plane passes through a point specified via the pos attribute. It is normal to the Z axis of the geom's local frame. The +Z direction corresponds to empty space. Thus the position and orientation defaults of (0,0,0) and (1,0,0,0) would create a ground plane at Z=0 elevation, with +Z being the vertical direction in the world (which is MuJoCo's convention). Since the plane is infinite, it could have been defined using any other point in the plane. The specified position however has additional meaning with regard to rendering. If either of the first two size parameters are positive, the plane is rendered as a rectangle of finite size (in the positive dimensions). This rectangle is centered at the specified position. Three size parameters are required. The first two specify the half- size of the rectangle along the X and Y axes. The third size parameter is unusual: it specifies the spacing between the grid subdivisions of the plane for rendering purposes. The subdivisions are revealed in wireframe rendering mode, but in general they should not be used to paint a grid over the ground plane (textures should be used for that purpose). Instead their role is to improve lighting and shadows, similar to the subdivisions used to render boxes. When planes are viewed from the back, the are automatically made semi-transparent. Planes and the +Z faces of boxes are the only surfaces that can show reflections, if the material applied to the geom has positive reflection. To render an infinite plane, set the first two size parameters to zero. The **hfield** type defines a height field geom. The geom must reference the desired height field asset with the hfield attribute below. The position and orientation of the geom set the position and orientation of the height field. The size of the geom is ignored, and the size parameters of the height field asset are used instead. See the description of the hfield element. Similar to planes, height field geoms can only be attached to the world body or to static children of the world. The **sphere** type defines a sphere. This and the next four types correspond to built-in geometric primitives. These primitives are treated as analytic surfaces for collision detection purposes, in many cases relying on custom pair- wise collision routines. Models including only planes, spheres, capsules and boxes are the most efficient in terms of collision detection. Other geom types invoke the general-purpose convex collider. The sphere is centered at the geom's position. Only one size parameter is used, specifying the radius of the sphere. Rendering of geometric primitives is done with automatically generated meshes whose density can be adjusted via quality. The sphere mesh is triangulated along the lines of latitude and longitude, with the Z axis passing through the north and south pole. This can be useful in wireframe mode for visualizing frame orientation. The **capsule** type defines a capsule, which is a cylinder capped with two half-spheres. It is oriented along the Z axis of the geom's frame. When the geom frame is specified in the usual way, two size parameters are required: the radius of the capsule followed by the half-height of the cylinder part. However capsules as well as cylinders can also be thought of as connectors, allowing an alternative specification with the fromto attribute below. In that case only one size parameter is required, namely the radius of the capsule. The **ellipsoid** type defines a ellipsoid. This is a sphere scaled separately along the X, Y and Z axes of the local frame. It requires three size parameters, corresponding to the three radii. Note that even though ellipsoids are smooth, their collisions are handled via the general-purpose convex collider. The only exception are plane-ellipsoid collisions which are computed analytically. The **cylinder** type defines a cylinder. It requires two size parameters: the radius and half-height of the cylinder. The cylinder is oriented along the Z axis of the geom's frame. It can alternatively be specified with the fromto attribute below. The **box** type defines a box. Three size parameters are required, corresponding to the half-sizes of the box along the X, Y and Z axes of the geom's frame. Note that box-box collisions can generate up to 8 contact points. The **mesh** type defines a mesh. The geom must reference the desired mesh asset with the mesh attribute. Note that mesh assets can also be referenced from other geom types, causing primitive shapes to be fitted; see below. The size is determined by the mesh asset and the geom size parameters are ignored. Unlike all other geoms, the position and orientation of mesh geoms after compilation do not equal the settings of the corresponding attributes here. Instead they are offset by the translation and rotation that were needed to center and align the mesh asset in its own coordinate frame. Recall the discussion of centering and alignment in the mesh element. The **sdf** type defines a signed distance field (SDF, also referred to as signed distance function). In order to visualize the SDF, a custom mesh must be specified using the mesh/plugin attribute. See the `model/plugin/sdf/ <https://github.com/google-deepmind/mujoco/tree/main/model/plugin/sdf>`__ directory for example models with SDF geometries. For more details regarding SDF plugins, see the Extensions chapter. This attribute and the next specify 32-bit integer bitmasks used for contact filtering of dynamically generated contact pairs. See Collision in the Computation chapter. Two geoms can collide if the contype of one geom is compatible with the conaffinity of the other geom or vice versa. Compatible means that the two bitmasks have a common bit set to 1. Bitmask for contact filtering; see contype above. The dimensionality of the contact space for a dynamically generated contact pair is set to the maximum of the condim values of the two participating geoms. See coContact in the Computation chapter. The allowed values and their meaning are: +--------+----------------------------------------------------------------------------------------------------------+ | condim | Description | +========+==========================================================================================================+ | 1 | Frictionless contact. | +--------+----------------------------------------------------------------------------------------------------------+ | 3 | Regular frictional contact, opposing slip in the tangent plane. | +--------+----------------------------------------------------------------------------------------------------------+ | 4 | Frictional contact, opposing slip in the tangent plane and rotation around the contact normal. This is | | | useful for modeling soft contacts (independent of contact penetration). | +--------+----------------------------------------------------------------------------------------------------------+ | 6 | Frictional contact, opposing slip in the tangent plane, rotation around the contact normal and rotation | | | around the two axes of the tangent plane. The latter frictional effects are useful for preventing | | | objects from indefinite rolling. | +--------+----------------------------------------------------------------------------------------------------------+ This attribute specifies an integer group to which the geom belongs. The only effect on the physics is at compile time, when body masses and inertias are inferred from geoms selected based on their group; see inertiagrouprange attribute of compiler. At runtime this attribute is used by the visualizer to enable and disable the rendering of entire geom groups. By default, groups 0, 1 and 2 are visible, while all other groups are invisible. The group attribute can also be used as a tag for custom computations. The geom priority determines how the properties of two colliding geoms are combined to form the properties of the contact. This interacts with the solmix attribute. See CContact. Geom size parameters. The number of required parameters and their meaning depends on the geom type as documented under the type attribute. Here we only provide a summary. All required size parameters must be positive; the internal defaults correspond to invalid settings. Note that when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh. In that case the sizes are obtained from the mesh, and the geom size parameters are ignored. Thus the number and description of required size parameters in the table below only apply to geoms that do not reference meshes. +---------+--------+------------------------------------------------------------------------------------------------+ | Type | Number | Description | +=========+========+================================================================================================+ | plane | 3 | X half-size; Y half-size; spacing between square grid lines for rendering. If either the X or Y| | | | half-size is 0, the plane is rendered as infinite in the dimension(s) with 0 size. | +---------+--------+------------------------------------------------------------------------------------------------+ | hfield | 0 | The geom sizes are ignored and the height field sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ | sphere | 1 | Radius of the sphere. | +---------+--------+------------------------------------------------------------------------------------------------+ | capsule | 1 or 2 | Radius of the capsule; half-length of the cylinder part when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ 3 | X radius; Y radius; Z radius. | +---------+--------+------------------------------------------------------------------------------------------------+ |cylinder | 1 or 2 | Radius of the cylinder; half-length of the cylinder when not using the fromto | | | | specification. | +---------+--------+------------------------------------------------------------------------------------------------+ | box | 3 | X half-size; Y half-size; Z half-size. | +---------+--------+------------------------------------------------------------------------------------------------+ | mesh | 0 | The geom sizes are ignored and the mesh sizes are used instead. | +---------+--------+------------------------------------------------------------------------------------------------+ If specified, this attribute applies a material to the geom. Otherwise, if unspecified and the type of the geom is a **mesh** the compiler will apply the mesh asset material if present. The material determines the visual properties of the geom. The only exception is color: if the rgba attribute below is different from its internal default, it takes precedence while the remaining material properties are still applied. Note that if the same material is referenced from multiple geoms (as well as sites and tendons) and the user changes some of its properties at runtime, these changes will take effect immediately for all model elements referencing the material. This is because the compiler saves the material and its properties as a separate element in mjModel, and the elements using this material only keep a reference to it. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. Contact friction parameters for dynamically generated contact pairs. The first number is the sliding friction, acting along both axes of the tangent plane. The second number is the torsional friction, acting around the contact normal. The third number is the rolling friction, acting around both axes of the tangent plane. The friction parameters for the contact pair are combined depending on the solmix and priority attributes, as explained in Contact parameters. See the general Contact section for descriptions of the semantics of this attribute. If this attribute is specified, the density attribute below is ignored and the geom density is computed from the given mass, using the geom shape and the assumption of uniform density. The computed density is then used to obtain the geom inertia. Recall that the geom mass and inertia are only used during compilation, to infer the body mass and inertia if necessary. At runtime only the body inertial properties affect the simulation; the geom mass and inertia are not saved in mjModel. Material density used to compute the geom mass and inertia. The computation is based on the geom shape and the assumption of uniform density. The internal default of 1000 is the density of water in SI units. This attribute is used only when the mass attribute above is unspecified. If `shellinertia` is "false" (the default), density has semantics of mass/volume; if "true", it has semantics of mass/area. This attribute specifies the weight used for averaging of contact parameters, and interacts with the priority attribute. See CContact. Constraint solver parameters for contact simulation. See CSolver. Constraint solver parameters for contact simulation. See CSolver. Distance threshold below which contacts are detected and included in the global array mjData.contact. This however does not mean that contact force will be generated. A contact is considered active only if the distance between the two geom surfaces is below margin-gap. Recall that constraint impedance can be a function of distance, as explained in CSolver. The quantity this function is applied to is the distance between the two geoms minus the margin plus the gap. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. Integer group to which the site belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of sites. Sizes of the geometric shape representing the site. Material used to specify the visual properties of the site. Color and transparency. If this value is different from the internal default, it overrides the corresponding material properties. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. All automatically generated model elements have names indicating the element type and index. For example, the body at coordinates (2, 0) in a 2D grid is named "B2_0" by default. If prefix="C" is specified, the same body is named "CB2_0". The prefix is needed when multiple composite objects are used in the same model, to avoid name conflicts. This attribute determines the type of composite object. The only supported type is cable. The **cable** type creates a 1D chain of bodies connected with ball joints, each having a geom with user-defined type (cylinder, capsule or box). The geometry can either be defined with an array of 3D vertex coordinates vertex or with prescribed functions with the option curve. Only linear and trigonometric functions are supported. For example, an helix can be obtained with curve="cos(s) sin(s) s". The size is set with the option size, resulting in f(s)=\{\text{size}[1]\cdot\cos(2\pi\cdot\text{size}[2]),\; \text{size}[1]\cdot\sin(2\pi\cdot\text{size}[2]),\; \text{size}[0]\cdot s\}. The element count in each dimension of the grid. This can have 1, 2 or 3 numbers, specifying the element count along the X, Y and Z axis of the parent body frame within. Any missing numbers default to 1. If any of these numbers is 1, all subsequent numbers must also be 1, so that the leading dimensions of the grid are used. This means for example that a 1D grid will always extend along the X axis. To achieve a different orientation, rotate the frame of the parent body. Note that some types imply a grid of certain dimensionality, so the requirements for this attribute depend on the specified type. It specifies a 3D offset from the center of the parent body to the center of the first body of the cable. The offset is expressed in the local coordinate frame of the parent body. Vertex 3D positions in global coordinates. Behavior of the first point. Free: free joint. Ball: ball joint. None: no dof. Functions specifying the vertex positions. Available functions are `s`, `cos(s)`, and `sin(s)`, where `s` is the arc length parameter. Scaling of the curve functions. `size[0]` is the scaling of `s`, `size[1]` is the radius of `\cos(s)` and `\sin(s)`, and `size[2]` is the speed of the argument (i.e. `\cos(2*\pi*size[2]*s)`). It specifies a quaternion that rotates the first body frame. The quaternion is expressed in the parent body frame. The type of equality constraint applied to this edge. If false, no equality constraint is applied. If true, then edge constraints are enforced. If vert, an averaged constraint is used, see flexvert. if strain, then a constraint is added to enforce that the invariants of the strain tensor do not change; this is only equality constraint type supported for trilinear and quadratic dofs elements and here. The standard constraint parameters, passed through to the automatically generated equality constraint. The standard constraint parameters, passed through to the automatically generated equality constraint. Edge stiffness and damping, passed through to the automatically generated flex. Edge stiffness and damping, passed through to the automatically generated flex. Young's elastic modulus, a measure of tensile and compressive stiffness for continuum elastic materials. Units of \textrm{pressure}=\textrm{force}/\textrm{area}. Poisson's ratio, the ratio of transverse deformation to applied longitudinal strain. This unitless quantity is in the range [0, 0.5). Small or large values imply compressibility or incompressiblity, respectively. Rayleigh's damping coefficient, units of time. This quantity scales the stiffness defined by Young's modulus to produce the damping matrix. Shell thickness, units of length; only for used 2D flexes. Used to scale the stretching stiffness. This thickness can be set equal to 2 times the radius in order to match the geometry, but is exposed separately since the radius might be constrained by considerations related to collision detection. Elastic contribution to passive forces of 2D flexes. "none": none, "bend": bending only, "stretch": stretching only, "both": bending and stretching. Enables or disables internal collisions which prevent flex self-penetration and element inversion. Note that flex elements that have shared vertices cannot collide (or else there will be permanent contacts). In 1D and 2D, internal collision checks rely on predefined vertex-element pairs, where the vertex is treated as a sphere with the same radius as the flex. These spheres correspond to non-shared vertices of neighboring elements on the periphery of the flex. The pre-defined vertex-element pairs are generated by the model compiler automatically. In 3D, internal collision checks are performed within each tetraheron: each vertex is collided with the plane corresponding to the opposing triangle face (again using the flex radius). The resulting contacts are always created with condim 1, gap 0, margin 0. Note that internal contacts modify the behavior implied by the elasticity parameters and is recommended only for flexes where element inversion cannot be prevented. This determines the strategy for midphase collision pruning of element pairs belonging to the same flex. **none** means flex elements cannot collide with each other. **narrow** means narrow phase only (i.e. all pairs are checked). This is a diagnostic tool and is never a good idea in practice. **bvh** and **sap** refer to bounding volume hierarchies and sweep-and-prune (which are two different strategies for midphase collision pruning). **auto** selects **sap** in 1D and 2D, and **bvh** in 3D. Which strategy performs better depends on the specifics of the model. The automatic setting is just a simple rule which we have found to perform well in general. This only has an effect for 3D flexes. Each tetrahedron is labeled by the model compiler with an integer corresponding to (graph) distance to the outside surface of the flex. Thus outside-facing elements are in layer 0, their neighbors are in layer 1, etc. This attribute specifies how many layers will be allowed to participate in collisions. The default setting 1 means that only one layer (i.e. layer 0) can collide, with itself and with the rest of the world. This is usually sufficient, however if the outer layer is composed of small tetrahedra, another body can "pierce" it and get stuck. In that case the value should be increased. When enabled, the contact is not added to the contact solver but it is instead used to compute passive (spring-damper) contact forces. All contacts, regardless of the specified condim, are frictionless (condim 1). This is an experimental feature. 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. Ranges of points to pin. Each range is specified by two integers. Grid coordinates of points to pin. This can only be used with type grid. Ranges of grid coordinates of points to pin. Each range is specified by (dim) integers for the minimum of the range followed by (dim) integers for the maximum of the range. This can only be used with type grid. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. The name of the flex element being generated automatically. This name is used as a prefix for all bodies that are automatically generated here, and is also referenced by the corresponding flex equality constraint (if applicable). This attribute determines the type of flexcomp object. The remaining attributes and sub-elements are then interpreted according to the type. Default settings are also adjusted depending on the type. Different types correspond to different methods for specifying the flexcomp points and the stretchable elements that connect them. They fall in three categories: direct specification entered in the XML, direct specification loaded from file, and automated generation from higher-level specification. **grid** generates a rectangular grid of points in 1D, 2D or 3D as specified by dim. The number of points in each dimension is determined by count while the grid spacing in each dimension is determined by spacing. Make sure the spacing is sufficiently large relative to radius to avoid permanent contacts. In 2D and 3D the grid is automatically triangulated, and corresponding flex elements are created (triangles or tetrahedra). In 1D the elements are capsules connecting consecutive pairs of points. **box** generates a 3D box object, however flex bodies are only generated on the outer shell. Each flex body has a radial slider joint allowing it to move in and out from the center of the box. The parent body would normally be a floating body. The box surface is triangulated, and each flex element is a tetrahedron connecting the center of the box with one triangle face. count and spacing determine the count and spacing of the flex bodies, similar to the **grid** type in 3D. Note that the resulting flex has the same topology as the box generated by composite. **cylinder** is the same as **box**, except the points are projected on the surface of a cylinder. **ellipsoid** is the same as **box**, except the points are projected on the surface of an ellipsoid. **disc** is the same as **box**, except the points are projected on the surface of a disc. It is only compatible with dim=2. **circle** is the same as **grid**, except the points are sampled along a circle so that the first and last points are the same. The radius of the circle is computed such that each segment has the requested spacing. It is only compatible with dim=1. **mesh** loads the flexcomp points and elements (i.e. triangles) from a mesh file, in the same file formats as mesh assets, excluding the legacy .msh format. A mesh asset is not actually added to the model. Instead the vertex and face data from the mesh file are used to populate the point and element data of the flexcomp. dim is automatically set to 2. Recall that a mesh asset in MuJoCo can be used as a rigid geom attached to a single body. In contrast, the flex generated here corresponds to a soft mesh with the same initial shape, where each vertex is a separate moving body (unless pinned). .. _gmsh-file-docs: **gmsh** is similar to mesh, but it loads a GMSH file in `format 4.1 <https://gmsh.info//doc/texinfo/gmsh.html#MSH-file-format>`__ and `format 2.2 <https://gmsh.info//doc/texinfo/gmsh.html#MSH-file-format-version-2-_0028Legacy_0029>`__ (ascii or binary). The file extension can be anything; the parser recognizes the format by examining the file header. This is a very rich file format, allowing all kinds of elements with different dimensionality and topology. MuJoCo only supports GMSH element types 1, 2, 4 which happen to correspond to our 1D, 2D and 3D flexes and assumes that the nodes are specified in a single block. Only the Nodes and Elements sections of the GMHS file are processed, and used to populate the point and element data of the flexcomp. The parser will generate an error if the GMSH file contains meshes that are not supported by MuJoCo. dim is automatically set to the dimensionality specified in the GMSH file. Presently this is the only mechanism to load a large tetrahedral mesh in MuJoCo and generate a corresponding soft entity. If such a mesh is available in a different file format, use the freely available `GMSH software <https://gmsh.info/>`__ to convert it to GMSH in one of the supported versions. **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 specifying the corresponding flex directly. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. Dimensionality of the flex object. This value must be 1, 2 or 3. The flex elements are capsules in 1D, triangles with radius in 2D, and tetrahedra with radius in 3D. Certain flexcomp types imply a dimensionality, in which case the value specified here is ignored. The parametrization of the flex's degrees of freedom (dofs). See the video on the right illustrating the different parametrizations with deformable spheres. The three models in the video are respectively `sphere_full <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_full.xml>`__, `sphere_radial <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_radial.xml>`__ and `sphere_trilinear <https://github.com/google-deepmind/mujoco/blob/main/model/flex/sphere_trilinear.xml>`__. **full** Three translational dofs per vertex. This is the most expressive but also the most expensive option. **radial** A single radial translational dof per vertex. Note that unlike in the "full" case, the radial parametrization requires a free joint at the flex's parent in order for free body motion to be possible. This type of parametrization is appropriate for shapes that are relatively spherical. **trilinear** Three translational dofs at each corner of the bounding box of the flex, for a total of 24 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using trilinear interpolation over the bounding box. :align: right :width: 240px Trilinear and quadratic flexes are much faster than the previous two options, and are the preferred choice if the expected deformations can be captured by the reduced parametriation. For example, see the video on the right comparing `full <https://github.com/google-deepmind/mujoco/blob/main/model/flex/gripper.xml>`__ and `trilinear <https://github.com/google-deepmind/mujoco/blob/main/model/flex/gripper_trilinear.xml>`__ flexes for modeling deformable gripper pads. Note that the choice of dof parametrization affects the deformation modes of the flex but has no effect on the accuracy of the collision geometry, which always takes into account the high-resolution mesh of the flex. **quadratic** Three translational dofs per corner, edge, face, and volume of the bounding box of the flex, for a total of 81 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using quadratic interpolation over the bounding box. While this option requires more degrees of freedom than trilinear flexes, it enables curved deformation modes, while the only modes achievable for trilinear flexes are strech/compression and shear. To understand the difference between the two parametrizations, see `a trilinear cube <https://github.com/google-deepmind/mujoco/blob/main/model/flex/trilinear.xml>`__ and `a quadratic cube <https://github.com/google-deepmind/mujoco/blob/main/model/flex/quadratic.xml>`__. Note that a higher interpolation order generally requires a smaller time step for stability, although usually not as large as with the "full" option and a fine mesh. Specifies the number of automatically generated points in each dimension for types **grid**, **box**, **cylinder**, and **ellipsoid**. Specifies the number of cells in each dimension for the background interpolation grid when using **trilinear** or **quadratic** dofs. The spacing between the automatically generated points in each dimension. The spacing should be sufficiently large compared to the radius, to avoid permanent contacts. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. If this is true, all points correspond to vertices within the parent body, and no new bodies are created. This is equivalent to pinning all points. Note that if all points are indeed pinned, the model compiler will detect that the flex is rigid (which behaves is a non-convex mesh in collision detection). The mass of each automatically-generated body equals this value divided by the number of points. Note that pinning some points does not affect the mass of the other bodies. Even though the automatically-generated bodies have the physics of point masses, with slider joints, MuJoCo still requires each body to have rotational inertia. The inertias generated here are diagonal, and are computed such that the corresponding equivalent-inertia boxes have sides equal to this value. Scaling of all point coordinates, for types that specify coordinates explicitly. Scaling is applied after the pose transformation. The name of the file from which a **surface** (triangular) or **volumetric** (tetrahedral) mesh is loaded. For surface meshes, the file extension is used to determine the file format. Supported formats are GMSH and the formats specified in mesh assets, excluding the legacy .msh format. Volumetric meshes are supported only in GMSH format. See here for more information on GMSH files. The 3D coordinates of the points. This attribute is only used with type **direct**. All other flexcomp types generate their own points. The points are used to construct bodies and vertices as explained earlier. The zero-based point ids forming each flex elements. This attribute is only used with type **direct**. All other flexcomp types generate their own elements. This data is passed through to the automatically-generated flex. Texture coordinates of each point, passed through to the automatically-generated flex. Note that flexcomp does not generate texture coordinates automatically, except for 2D grids, box, cylinder and ellipsoid. For all other types, the user can specify explicit texture coordinates here, even if the points themselves were generated automatically. This requires understanding of the layout of the automatically-generated points and how they correspond to the texture referenced by the material. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. These attributes are directly passed through to the automatically-generated flex object and have the same meaning. This 3D vector translates all points relative to the frame of the parent body. This is a quaternion rotation of all points around the pos vector specified above. Together these two vectors define a pose transformation, used to position and orient the points as needed. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. Alternative specification of rotation, that can be used instead of quat. The origin of the flexcomp. Used for generating a volumetric mesh from an OBJ surface mesh. Each surface triangle is connected to the origin to create a tetrahedron, so the resulting volumetric mesh is guaranteed to be well-formed only for convex shapes. The number of replicas. Must be positive. Translational offset along the three coordinate axes. In general, the frame of the offset is with respect to the previous replica, except for the first one which is with respect to the replicate element's parent. If there is no rotation, these values are always in the frame of the replicate element's parent. Rotation angles around three coordinate axes between two subsequent replicas. The angular units and rotation sequence respect the global angle and eulerseq settings. Rotation is always with respect to the frame of the previous replica, so total rotation is cumulative. The namespace separator. This optional string is prepended to the namespace suffix string. Note that for nested replicate elements, the innermost namespace suffixes are appended first. Determines the type of actuators to which length range computation is applied. "none" disables this functionality. "all" applies it to all actuators. "muscle" applies it to actuators whose gaintype or biastype is set to "muscle". "muscleuser" applies it to actuators whose gaintype or biastype is set to either "muscle" or "user". The default is "muscle" because MuJoCo's muscle model requires actuator length ranges to be defined. If this attribute is "true" and the length range for a given actuator is already defined in the model, the existing value will be used and the automatic computation will be skipped. The range is considered defined if the first number is smaller than the second number. The only reason to set this attribute to "false" is to force re-computation of actuator length ranges - which is needed when the model geometry is modified. Note that the automatic computation relies on simulation and can be slow, so saving the model and using the existing values when possible is recommended. If this attribute is "true" and the actuator is attached to a joint or a tendon which has limits defined, these limits will be copied into the actuator length range and the automatic computation will be skipped. This may seem like a good idea but note that in complex models the feasible range of tendon actuators depends on the entire model, and may be smaller than the user-defined limits for that tendon. So the safer approach is to set this to "false", and let the automatic computation discover the feasible range. This attribute scales the forces applied to the simulation in order to push each actuator to its smallest and largest length. The force magnitude is computed so that the resulting joint-space acceleration vector has norm equal to this attribute. The force computed via the accel attribute above can be very large when the actuator has very small moments. Such a force will still produce reasonable acceleration (by construction) but large numbers could cause numerical issues. Although we have never observed such issues, the present attribute is provided as a safeguard. Setting it to a value larger than 0 limits the norm of the force being applied during simulation. The default setting of 0 disables this safeguard. The simulation is damped in a non-physical way so as to push the actuators to their limits without the risk of instabilities. This is done by simply scaling down the joint velocity at each time step. In the absence of new accelerations, such scaling will decrease the velocity exponentially. The timeconst attribute specifies the time constant of this exponential decrease, in seconds. The timestep used for the internal simulation. Setting this to 0 will cause the model timestep to be used. The latter is not the default because models that can go unstable usually have small timesteps, while the simulation here is artificially damped and very stable. To speed up the length range computation, users can attempt to increase this value. The total time interval (in seconds) for running the internal simulation, for each actuator and actuator direction. Each simulation is initialized at qpos0. It is expected to settle after inttotal time has passed. The time interval at the end of the simulation over which length data is collected and analyzed. The maximum (or respectively minimum) length achieved during this interval is recorded. The difference between the maximum and minimum is also recorded and is used as a measure of divergence. If the simulation settles, this difference will be small. If it is not small, this could be because the simulation has not yet settled - in which case the above attributes should be adjusted - or because the model does not have sufficient joint and tendon limits and so the actuator range is effectively unlimited. Both of these conditions cause the same compiler error. Recall that contacts are disabled in this simulation, so joint and tendon limits as well as overall geometry are the only things that can prevent actuators from having infinite length. This determines the threshold for detecting divergence and generating a compiler error. The range of actuator lengths observed during interval is divided by the overall range computed via simulation. If that value is larger than tolrange, a compiler error is generated. So one way to suppress compiler errors is to simply make this attribute larger, but in that case the results could be inaccurate. This attribute affects the behavior of attributes such as "limited" (on <body-joint> or <tendon>), "forcelimited", "ctrllimited", and "actlimited" (on <actuator>). If "true", these attributes are unnecessary and their value will be inferred from the presence of their corresponding "range" attribute. If "false", no such inference will happen: For a joint to be limited, both limited="true" and range="min max" must be specified. In this mode, it is an error to specify a range without a limit. This attribute imposes a lower bound on the mass of each body except for the world body. Setting this attribute to a value greater than 0 can be used as a quick fix for poorly designed models that contain massless moving bodies, such as the dummy bodies often used in URDF models to attach sensors. Note that in MuJoCo there is no need to create dummy bodies. This attribute imposes a lower bound on the diagonal inertia components of each body except for the world body. Its use is similar to boundmass above. If this value is positive, the compiler will scale the masses and inertias of all bodies in the model, so that the total mass equals the value specified here. The world body has mass 0 and does not participate in any mass-related computations. This scaling is performed last, after all other operations affecting the body mass and inertia. The same scaling operation can be applied at runtime to the compiled mjModel with the function mj_setTotalmass. A valid diagonal inertia matrix must satisfy A+B>=C for all permutations of the three diagonal elements. Some poorly designed models violate this constraint, which will normally result in a compile error. If this attribute is set to "true", the compiler will silently set all three diagonal elements to their average value whenever the above condition is violated. When this attribute is "true", the parser will remove any path information in file names specified in the model. This is useful for loading models created on a different system using a different directory structure. This attribute specifies whether frame positions and orientations are expressed in local coordinates. The "global" option is no longer supported and will cause an error. This attribute specifies whether the angles in the MJCF model are expressed in units of degrees or radians. The compiler converts degrees into radians, and mjModel always uses radians. For URDF models the parser sets this attribute to "radian" internally, regardless of the XML setting. The compiler is able to replace a mesh with a geometric primitive fitted to that mesh; see geom below. If this attribute is "true", the fitting procedure uses the axis-aligned bounding box (AABB) of the mesh, choosing the smallest primitive whose AABB contains the mesh AABB. Otherwise it uses the equivalent-inertia box of the mesh. The type of geometric primitive used for fitting is specified separately for each geom. The models used to generate the image on the right can be found `here <https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/fitmesh_inertiabox.xml>`__ (fit inertia box) and `here <https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/fitmesh_aabb.xml>`__ (fit aabb). This attribute specifies the sequence of Euler rotations for all euler attributes of elements that have spatial frames, as explained in COrientation. This must be a string with exactly 3 characters from the set {x, y, z, X, Y, Z}. The character at position n determines the axis around which the n-th rotation is performed. Lower case letters denote axes that rotate with the frame (intrinsic), while upper case letters denote axes that remain fixed in the parent frame (extrinsic). The "rpy" convention used in URDF corresponds to "XYZ" in MJCF. This attribute instructs the compiler where to look for mesh and height field files. The full path to a file is determined as follows. If the strippath attribute described above is "true", all path information from the file name is removed. The following checks are then applied in order: (1) if the file name contains an absolute path, it is used without further changes; (2) if this attribute is set and contains an absolute path, the full path is the string given here appended with the file name; (3) the full path is the path to the main MJCF model file, appended with the value of this attribute if specified, appended with the file name. This attribute is used to instruct the compiler where to look for texture files. It works in the same way as meshdir above. This attribute instructs the compiler to discard all model elements which are purely visual and have no effect on the physics (with one exception, see below). This often enables smaller mjModel structs and faster simulation. - All materials are discarded. - All textures are discarded. - All geoms with contype |-| = |-| conaffinity |-| =0 are discarded, if they are not referenced in another MJCF element. If a discarded geom was used for inferring body inertia, an explicit inertial element is added to the body. - All meshes which are not referenced by any geom (in particular those discarded above) are discarded. The resulting compiled model will have exactly the same dynamics as the original model. The only engine-level computation which might change is the output of raycasting computations, as used for example by rangefinder sensors, since raycasting reports distances to visual geoms. When visualizing models compiled with this flag, it is important to remember that collision geoms are often placed in a group which is invisible by default. If this attribute is "true", the model compiler will run in multi-threaded mode. Multi-threading is used for computing the length ranges of actuators and for parallel loading and processing of meshes. This attribute controls a compiler optimization feature where static bodies are fused with their parent, and any elements defined in those bodies are reassigned to the parent. Static bodies are fused with their parent unless - They are referenced by another element in the model. - They contain a site which is referenced by a force or torque sensor. This optimization is particularly useful when importing URDF models which often have many dummy bodies, but can also be used to optimize MJCF models. After optimization, the new model has identical kinematics and dynamics as the original but is faster to simulate. This attribute controls the automatic inference of body masses and inertias from geoms attached to the body. If this setting is "false", no automatic inference is performed. In that case each body must have explicitly defined mass and inertia with the inertial element, or else a compile error will be generated. If this setting is "true", the mass and inertia of each body will be inferred from the geoms attached to it, overriding any values specified with the inertial element. The default setting "auto" means that masses and inertias are inferred automatically only when the inertial element is missing in the body definition. One reason to set this attribute to "true" instead of "auto" is to override inertial data imported from a poorly designed model. In particular, a number of publicly available URDF models have seemingly arbitrary inertias which are too large compared to the mass. This results in equivalent inertia boxes which extend far beyond the geometric boundaries of the model. Note that the built-in OpenGL visualizer can render equivalent inertia boxes. This attribute specifies the range of geom groups that are used to infer body masses and inertias (when such inference is enabled). The group attribute of geom is an integer. If this integer falls in the range specified here, the geom will be used in the inertial computation, otherwise it will be ignored. This feature is useful in models that have redundant sets of geoms for collision and visualization. Note that the world body does not participate in the inertial computations, so any geoms attached to it are automatically ignored. Therefore it is not necessary to adjust this attribute and the geom-specific groups so as to exclude world geoms from the inertial computation. If set to "true", the compiler will save explicit inertial clauses for all bodies. This attribute sets the values of both meshdir and texturedir above. Values in the latter attributes take precedence over assetdir. This attribute toggles the default behaviour of an optimization that applies to bodies with a free joint and no child bodies. When true, the body frame and free joint will automatically be aligned with inertial frame, which leads to both faster and more stable simulation. See freejoint/align for details. This flag disables all standard computations related to the constraint solver. As a result, no constraint forces are applied. Note that the next four flags disable the computations related to a specific type of constraint. Both this flag and the type-specific flag must be set to "enable" for a given computation to be performed. This flag disables all standard computations related to equality constraints. This flag disables all standard computations related to friction loss constraints. This flag disables all standard computations related to joint and tendon limit constraints. This flag disables collision detection and all standard computations related to contact constraints. This flag disables passive joint and tendon springs. If passive damper forces are also disabled, **all** passive forces are disabled, including gravity compensation, fluid forces, forces computed by the mjcb_passive callback, and forces computed by plugins when passed the mjPLUGIN_PASSIVE capability flag. This flag disables passive joint and tendon dampers. If passive spring forces are also disabled, **all** passive forces are disabled, including gravity compensation, fluid forces, forces computed by the mjcb_passive callback, and forces computed by plugins when passed the mjPLUGIN_PASSIVE capability flag. This flag causes the gravitational acceleration vector in mjOption to be replaced with (0 0 0) at runtime, without changing the value in mjOption. Once the flag is re-enabled, the value in mjOption is used. This flag disables the clamping of control inputs to all actuators, even if the actuator-specific attributes are set to enable clamping. This flag disables warm-starting of the constraint solver. By default the solver uses the solution (i.e., the constraint force) from the previous time step to initialize the iterative optimization. This feature should be disabled when evaluating the dynamics at a collection of states that do not form a trajectory - in which case warm starts make no sense and are likely to slow down the solver. This flag disables the filtering of contact pairs where the two geoms belong to a parent and child body; recall contact selection in the Computation chapter. This flag disables all standard computations related to actuator forces, including the actuator dynamics. As a result, no actuator forces are applied to the simulation. This flag enables a safety mechanism that prevents instabilities due to solref[0] being too small compared to the simulation timestep. Recall that solref[0] is the stiffness of the virtual spring-damper used for constraint stabilization. If this setting is enabled, the solver uses max(solref[0], 2*timestep) in place of solref[0] separately for each active constraint. This flag disables all computations related to sensors. When disabled, sensor values will remain constant, either zeros if disabled at the start of simulation, or, if disabled at runtime, whatever value was last computed. This flag disables the mid-phase collision filtering using a static AABB bounding volume hierarchy (a BVH binary tree). If disabled, all geoms pairs that are allowed to collide are checked for collisions. This flag disables implicit integration with respect to joint damping in the Euler integrator. See the Numerical Integration section for more details. This flag disables the automatic resetting of the simulation state when numerical issues are detected. This flag enables the native convex collision detection pipeline instead of using the `libccd library <https://github.com/danfis/libccd>`__, see convex collisions for more details. This flag enables discovery and construction of constraint islands: disjoint sets of constraints and degrees-of-freedom that do not interact and can be solved independently. Islanding is not yet supported by the PGS solver. See soIsland for more details. The mjVIS_ISLAND enables `island visualization <https://youtu.be/Vc1tq0fFvQA>`__. This flag enables the Contact override mechanism. This flag enables the computation of potential and kinetic energy in mjData.energy[0, 1] respectively, and displayed in the simulate GUI info overlay. Potential energy includes the gravitational component summed over all bodies \sum_b m_b g h and energy stored in passive springs in joints, tendons and flexes \tfrac{1}{2} k x^2, where x is the displacement and k is the spring constant. Kinetic energy is given by \tfrac{1}{2} v^T M v, where v is the velocity and M is the mass matrix. Note that potential and kinetic energy in constraints is not accounted for. The extra computation (also triggered by potential and kinetic energy sensors) adds some CPU time but it is usually negligible. Monitoring energy for a system that is supposed to be energy-conserving is one of the best ways to assess the accuracy of a complex simulation. This flag enables the automatic comparison of forward and inverse dynamics. When enabled, the inverse dynamics is invoked after mj_forward (or internally within mj_step) and the difference in applied forces is recorded in mjData.solver_fwdinv[2]. The first value is the relative norm of the discrepancy in joint space, the next is in constraint space. This dual-purpose flag enables discrete-time inverse dynamics and disables midpoint integration. Enable discrete-time inverse dynamics This flag **enables** discrete-time inverse dynamics with mj_inverse for all integrators other than RK4. Recall from the numerical integration section that the one-step integrators (Euler, implicit and implicitfast), modify the mass matrix M \rightarrow M-hD. This implies that finite-differenced accelerations (v_{t+h} - v_t)/h will not correspond to the continuous-time acceleration mjData.qacc. When this flag is enabled, mj_inverse will interpret qacc as having been computed from the difference of two sequential velocities, and undo the above modification. Disable midpoint integration Additionally and relatedly, this flag **disables** midpoint integration for free bodies, which would otherwise break the linear relationship between finite-differenced velocities and forces assumed by discrete inverse dynamics. Note that disabling midpoint integration might be useful for debugging or for other reasons, regardless or whether inverse dynamics are used. This flag enables multiple-contact collision detection for geom pairs that use a general-purpose convex-convex collider e.g., mesh-mesh collisions. This can be useful when the contacting geoms have a flat surface and the single contact point generated by the convex-convex collider cannot accurately capture the surface contact, leading to instabilities that typically manifest as sliding or wobbling. The implementation of this feature depends on the selected convex collision pipeline, see convex collisions for more details. This flag enables sleeping. Disabling this flag when some trees are sleeping will wake them. :class: attention Unlike any other flag, the sleep flag has an effect during mjData **initialization** (mj_makeData or mj_resetData). First, it must be set at initialization time in order for the sleep-init policy to take effect. Second, it must be set in order for static quantities to be computed. See implementation notes for more details. Simulation time step in seconds. This is the single most important parameter affecting the speed-accuracy trade-off which is inherent in every physics simulation. Smaller values result in better accuracy and stability. To achieve real-time performance, the time step must be larger than the CPU time per step (or 4 times larger when using the RK4 integrator). The CPU time is measured with internal timers. It should be monitored when adjusting the time step. MuJoCo can simulate most robotic systems a lot faster than real-time, however models with many floating objects (resulting in many contacts) are more demanding computationally. Keep in mind that stability is determined not only by the time step but also by the CSolver; in particular softer constraints can be simulated with larger time steps. When fine-tuning a challenging model, it is recommended to experiment with both settings jointly. In optimization-related applications, real-time is no longer good enough and instead it is desirable to run the simulation as fast as possible. In that case the time step should be made as large as possible. This attribute determines the ratio of frictional-to-normal constraint impedance for elliptic friction cones. The setting of solimp determines a single impedance value for all contact dimensions, which is then modulated by this attribute. Settings larger than 1 cause friction forces to be "harder" than normal forces, having the general effect of preventing slip, without increasing the actual friction coefficient. For pyramidal friction cones the situation is more complex because the pyramidal approximation mixes normal and frictional dimensions within each basis vector; it is not recommended to use high impratio values with pyramidal cones. Tolerance threshold used for early termination of the iterative solver. For PGS, the threshold is applied to the cost improvement between two iterations. For CG and Newton, it is applied to the smaller of the cost improvement and the gradient norm. Set the tolerance to 0 to disable early termination. Tolerance threshold used for early termination of the linesearch algorithm. Tolerance threshold used for early termination of the Noslip solver. Tolerance threshold used for early termination of the convex collision algorithm. Velocity tolerance below which sleeping is allowed. Gravitational acceleration vector. In the default world orientation the Z-axis points up. The MuJoCo GUI is organized around this convention (both the camera and perturbation commands are based on it) so we do not recommend deviating from it. Velocity vector of the medium (i.e., wind). This vector is subtracted from the 3D translational velocity of each body, and the result is used to compute viscous, lift and drag forces acting on the body; recall Passive forces in the Computation chapter. The magnitude of these forces scales with the values of the next two attributes. Global magnetic flux. This vector is used by magnetometer sensors, which are defined as sites and return the magnetic flux at the site position expressed in the site frame. Density of the medium, not to be confused with the geom density used to infer masses and inertias. This parameter is used to simulate lift and drag forces, which scale quadratically with velocity. In SI units the density of air is around 1.2 while the density of water is around 1000 depending on temperature. Setting density to 0 disables lift and drag forces. Viscosity of the medium. This parameter is used to simulate viscous forces, which scale linearly with velocity. In SI units the viscosity of air is around 0.00002 while the viscosity of water is around 0.0009 depending on temperature. Setting viscosity to 0 disables viscous forces. Note that the default Euler integrator handles damping in the joints implicitly – which improves stability and accuracy. It does not presently do this with body viscosity. Therefore, if the goal is merely to create a damped simulation (as opposed to modeling the specific effects of viscosity), we recommend using joint damping rather than body viscosity, or switching to the implicit or implicitfast integrators. This attribute replaces the margin parameter of all active contact pairs when Contact override is enabled. Otherwise MuJoCo uses the element-specific margin attribute of geom or pair depending on how the contact pair was generated. See also Collision in the Computation chapter. The related gap parameter does not have a global override. These attributes replace the solref, solimp and friction parameters of all active contact pairs when contact override is enabled. See CSolver for details. These attributes replace the solref, solimp and friction parameters of all active contact pairs when contact override is enabled. See CSolver for details. These attributes replace the solref, solimp and friction parameters of all active contact pairs when contact override is enabled. See CSolver for details. This attribute selects the numerical integrator to be used. Currently the available integrators are the semi-implicit Euler method, the fixed-step 4-th order Runge Kutta method, the Implicit-in-velocity Euler method, and implicitfast, which drops the Coriolis and centrifugal terms. See Numerical Integration for more details. The type of contact friction cone. Elliptic cones are a better model of the physical reality, but pyramidal cones sometimes make the solver faster and more robust. The type of constraint Jacobian and matrices computed from it. Auto resolves to dense when the number of degrees of freedom is up to 60, and sparse over 60. This attribute selects one of the constraint solver algorithms described in the Computation chapter. Guidelines for solver selection and parameter tuning are available in the Algorithms section above. Maximum number of iterations of the constraint solver. When the warmstart attribute of flag is enabled (which is the default), accurate results are obtained with fewer iterations. Larger and more complex systems with many interacting constraints require more iterations. Note that mjData.solver contains statistics about solver convergence, also shown in the profiler. Maximum number of linesearch iterations performed by CG/Newton constraint solvers. Ensures that at most iterations times ls_iterations linesearch iterations are performed during each constraint solve. Maximum number of iterations of the Noslip solver. This is a post-processing step executed after the main solver. It uses a modified PGS method to suppress slip/drift in friction dimensions resulting from the soft-constraint model. The default setting 0 disables this post-processing step. Maximum number of iterations of the algorithm used for convex collisions. This rarely needs to be adjusted, except in situations where some geoms have very large aspect ratios. Number of iterations used for Signed Distance Field collisions (per initial point). Number of starting points used for finding contacts with Signed Distance Field collisions. List of actuator groups to disable. Actuators whose group is in this list will produce no force. If they are stateful, their activation states will not be integrated. Internally this list is implemented as an integer bitfield, so values must be in the range 0 <= group <= 30. If not set, all actuator groups are enabled. See `example model <https://github.com/google-deepmind/mujoco/blob/main/test/engine/testdata/actuation/actuator_group_disable.xml>`__ and associated screen-capture on the right. This attribute specifies the size of memory allocated for dynamic arrays in the mjData.arena memory space, in bytes. The default setting of -1 instructs the compiler to guess how much space to allocate. Appending the digits with one of the letters {K, M, G, T, P, E} sets the unit to be {kilo, mega, giga, tera, peta, exa}-byte, respectively. Thus "16M" means "allocate 16 megabytes of arena memory". See the Memory allocation section for details. This is a deprecated legacy attribute. It previously determined the maximum allowed number of constraints. Currently it means "allocate as much memory as would have previously been required for this number of constraints". Specifying both njmax and memory leads to an error. 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 previously affected memory allocation. It is kept for backwards compatibility and debugging purposes. This is a deprecated legacy attribute. It previously determined the maximum size of the stack. If nstack is specified, then the size of mjData.narena is nstack * sizeof(mjtNum) bytes, plus an additional space for the constraint solver. Specifying both nstack and memory leads to an error. The size of the field mjData.userdata of mjData. This field should be used to store custom dynamic variables. See also CUser. The number of key frames allocated in mjModel is the larger of this value and the number of key elements below. Note that the interactive simulator has the ability to take snapshots of the system state and save them as key frames. The number of custom user parameters added to the definition of each body. See also User parameters. The parameter values are set via the user attribute of the body element. These values are not accessed by MuJoCo. They can be used to define element properties needed in user callbacks and other custom code. The number of custom user parameters added to the definition of each joint. The number of custom user parameters added to the definition of each geom. The number of custom user parameters added to the definition of each site. The number of custom user parameters added to the definition of each camera. The number of custom user parameters added to the definition of each tendon. The number of custom user parameters added to the definition of each actuator. The number of custom user parameters added to the definition of each sensor. The id of the camera used when initially loading the model in the visualizer. The default value of -1 means the free camera. In order to specify a modeled camera, use the camera's id as given by mj_name2id. Whether the free camera uses a perspective projection (the default) or an orthographic projection. Setting this attribute changes the semantic of the global/fovy attribute, see below. This attribute specifies the vertical field of view of the free camera, i.e., the camera that is always available in the visualizer even if no cameras are explicitly defined in the model. If the camera uses a perspective projection, the field-of-view is expressed in degrees, regardless of the global compiler/angle setting. If the camera uses an orthographic projection, the field-of-view is expressed in units of length; note that in this case the default of 45 is too large for most scenes and should likely be reduced. In either case, the horizontal field of view is computed automatically given the window size and the vertical field of view. The same convention applies to the camera/fovy attribute. This attribute specifies the inter-pupilary distance of the free camera. It only affects the rendering in stereoscopic mode. The left and right viewpoints are offset by half of this value in the corresponding direction. This attribute specifies the initial azimuth of the free camera around the vertical z-axis, in degrees. A value of 0 corresponds to looking in the positive x direction, while the default value of 90 corresponds to looking in the positive y direction. The look-at point itself is specified by the statistic/center attribute, while the distance from the look-at point is controlled by the statistic/extent attribute. This attribute specifies the initial elevation of the free camera with respect to the lookat point. Note that since this is a rotation around a vector parallel to the camera's X-axis (right in pixel space), *negative* numbers correspond to moving the camera *up* from the horizontal plane, and vice-versa. The look-at point itself is specified by the statistic/center attribute, while the distance from the look-at point is controlled by the statistic/extent attribute. This attribute specifies the line-width in the sense of OpenGL. It affects the rendering in wire-frame mode. The value of this attribute is added to the emission coefficient of all geoms attached to the selected body. As a result, the selected body appears to glow. This and the next attribute specify the size in pixels of the off-screen OpenGL rendering buffer. This attribute specifies the width of the buffer. The size of this buffer can also be adjusted at runtime, but it is usually more convenient to set it in the XML. This attribute specifies the height in pixels of the OpenGL off-screen rendering buffer. This value sets the initial real-time factor of the model, when loaded in `simulate`. 1: real time. Less than 1: slower than real time. Must be greater than 0. This attribute specifies how the equivalent inertia is visualized. "false": use box, "true": use ellipsoid. This attribute specifies whether collision and raycasting code should mark elements of Bounding Volume Hierarchies as intersecting, for the purpose of visualization. Setting this attribute to "false" can speed up simulation for models with high-resolution meshes. This attribute specifies the size of the square texture used for shadow mapping. Higher values result in smoother shadows. The size of the area over which a light can cast shadows also affects smoothness, so these settings should be adjusted jointly. The default here is somewhat conservative. Most modern GPUs are able to handle significantly larger textures without slowing down. This attribute specifies the number of multi-samples for offscreen rendering. Larger values produce better anti-aliasing but can slow down the GPU. Set this to 0 to disable multi-sampling. Note that this attribute only affects offscreen rendering. For regular window rendering, multi-sampling is specified in an OS-dependent way when the OpenGL context for the window is first created, and cannot be changed from within MuJoCo. When rendering segmentation images, multi-sampling is automatically disabled so as not to average segmentation indices. However, some rendering backends ignore the automatic disabling. If your segmentation images contain bad indices, try manually setting this attribute to 0. This and the next three attributes specify the density of internally-generated meshes for geometric primitives. Such meshes are only used for rendering, while the collision detector works with the underlying analytic surfaces. This value is passed to the various visualizer functions as the "slices" parameter as used in GLU. It specifies the number of subdivisions around the Z-axis, similar to lines of longitude. This value of this attribute is passed to the various visualization functions as the "stacks" parameter as used in GLU. It specifies the number of subdivisions along the Z-axis, similar to lines of latitude. This attribute specifies the number of rectangles for rendering box faces, automatically-generated planes (as opposed to geom planes which have an element-specific attribute with the same function), and sides of height fields. Even though a geometrically correct rendering can be obtained by setting this value to 1, illumination works better for larger values because we use per-vertex illumination (as opposed to per-fragment). The ambient component of the headlight, in the sense of OpenGL. The alpha component here and in the next two attributes is set to 1 and cannot be adjusted. The diffuse component of the headlight, in the sense of OpenGL. The specular component of the headlight, in the sense of OpenGL. This attribute enables and disables the headlight. A value of 0 means disabled, any other value means enabled. This attribute controls the strength of mouse perturbations. The internal perturbation mechanism simulates a mass-spring-damper with critical damping, unit mass, and stiffness given here. Larger values mean that a larger force will be applied for the same displacement between the selected body and the mouse-controlled target. Same as above but applies to rotational perturbations rather than translational perturbations. Empirically, the rotational stiffness needs to be larger in order for rotational mouse perturbations to have an effect. This attributes controls the visualization of both contact forces and perturbation forces. The length of the rendered force vector equals the force magnitude multiplied by the value of this attribute and divided by the mean body mass for the model (see statistic element). Same as above, but controls the rendering of contact torque and perturbation torque rather than force (currently disabled). When transparency is turned on in the visualizer, the geoms attached to all moving bodies are made more transparent. This is done by multiplying the geom-specific alpha values by this value. The visualizer can simulate linear fog, in the sense of OpenGL. The start position of the fog is the model extent (see statistic element) multiplied by the value of this attribute. The end position of the fog is the model extent multiplied by the value of this attribute. This and the next attribute determine the clipping planes of the OpenGL projection. The near clipping plane is particularly important: setting it too close causes (often severe) loss of resolution in the depth buffer, while setting it too far causes objects of interest to be clipped, making it impossible to zoom in. The distance to the near clipping plane is the model extent multiplied by the value of this attribute. Must be strictly positive. The distance to the far clipping plane is the model extent multiplied by the value of this attribute. Proportion of the distance-to-horizon that is covered by haze (when haze rendering is enabled and a skybox is present). As mentioned above, shadow quality depends on the size of the shadow texture as well as the area where a given light can cast shadows. For directional lights, the area would be infinite unless we limited it somehow. This attribute specifies the limits, as +/- the model extent multiplied by the present value. These limits define a square in the plane orthogonal to the light direction. If a shadow crosses the boundary of this virtual square, it will disappear abruptly, revealing the edges of the square. This attribute plays a similar role as the previous one, but applies to spotlights rather than directional lights. Spotlights have a cutoff angle, limited internally to 80 deg. However this angle is often too large to obtain good quality shadows, and it is necessary to limit the shadow to a smaller cone. The angle of the cone in which shadows can be cast is the light cutoff multiplied by the present value. Ratio of actuator width to tendon width for rendering of actuators attached to tendons. The radius of the arrows used to render contact forces and perturbation forces. The radius of the cylinders used to render contact points. The normal direction of the cylinder is aligned with the contact normal. Making the cylinder short and wide results in a "pancake" representation of the tangent plane. The height of the cylinders used to render contact points. The radius of the capsules used to connect bodies and joints, resulting in an automatically generated skeleton. The radius of the spheres used to render the centers of mass of kinematic sub-trees. The size of the decorative object used to represent model cameras in the rendering. The size of the decorative object used to represent model lights in the rendering. The radius of the sphere used to render the selection point (i.e., the point where the user left-double-clicked to select a body). Note that the local and global coordinates of this point can be printed in the 3D view by activating the corresponding rendering flags. In this way, the coordinates of points of interest can be found. The length of the arrows used to render joint axes. The radius of the arrows used to render joint axes. The length of the arrows used to render actuators acting on scalar joints only. The radius of the arrows used to render actuators acting on scalar joints only. The length of the cylinders used to render coordinate frames. The world frame is automatically scaled relative to this setting. The radius of the cylinders used to render coordinate frames. The radius of the capsules used to render violations in spatial constraints. The radius of the capsules used to render slider-crank mechanisms. The second part of the mechanism is automatically scaled relative to this setting. The distance of the zfar plane from the camera pinhole for rendering the frustum. When fog is enabled, the color of all pixels fades towards the color specified here. The spatial extent of the fading is controlled by the fogstart and fogend attributes of the map element above. Haze color at the horizon, used to transition between an infinite plane and a skybox smoothly. The default creates white haze. To create a seamless transition, make sure the skybox colors near the horizon are similar to the plane color/texture, and set the haze color somewhere in that color gamut. Color of the arrows used to render perturbation forces. Color of the boxes used to render equivalent body inertias. This is the only rgba setting that has transparency by default, because it is usually desirable to see the geoms inside the inertia box. Color of the arrows used to render joint axes. If a joint is limited and the joint value exceeds the limit, the value of the constraint impedance d is used to mix this color and rgba/constraint. Actuator color for neutral value of the control. Actuator color for most negative value of the control. Actuator color for most positive value of the control. Color of the spheres used to render sub-tree centers of mass. Color of the decorative object used to represent model cameras in the rendering. Color of the decorative object used to represent model lights in the rendering. Color of the sphere used to render the selection point. Color of the capsules used to connect bodies and joints, resulting in an automatically generated skeleton. Color of the cylinders used to render contact points. Color of the arrows used to render contact forces. When splitting of contact forces into normal and tangential components is enabled, this color is used to render the normal components. Color of the arrows used to render contact tangential forces, only when splitting is enabled. Color of the arrows used to render contact torques (currently disabled). Color of contacts that fall in the contact gap (and are thereby excluded from contact force computations). Color of line geoms used to render rangefinder sensors. Color corresponding to spatial constraint violations -- equality constraints, joint limits, and tendon limits. Color of slider-crank mechanisms. Color used to render the crank of slide-crank mechanisms, in model configurations where the specified rod length cannot be maintained, i.e., it is "broken". Color used to render the camera frustum. Color used to render bounding volumes. Color used to render active bounding volumes, if the bvactive flag is "true". If this attribute is specified, it replaces the value of mjModel.stat.meaninertia computed by the compiler. The computed value is the average diagonal element of the joint-space inertia matrix when the model is in qpos0. At runtime this value scales the solver cost and gradient used for early termination. If this attribute is specified, it replaces the value of mjModel.stat.meanmass computed by the compiler. The computed value is the average body mass, not counting the massless world body. At runtime this value scales the perturbation force. If this attribute is specified, it replaces the value of mjModel.stat.meansize computed by the compiler. At runtime this value multiplies the attributes of the scale element above, and acts as their length unit. If specific lengths are desired, it can be convenient to set meansize to a round number like 1 or 0.01 so that scale values are in recognized length units. This is the only semantic of meansize and setting it has no other side-effect. The automatically computed value is heuristic, representing the average body radius. The heuristic is based on geom sizes when present, the distances between joints when present, and the sizes of the body equivalent inertia boxes. If this attribute is specified, it replaces the value of mjModel.stat.extent computed by the compiler. The computed value is half the side of the bounding box of the model in the initial configuration. At runtime this value is multiplied by some of the attributes of the map element above. When the model is first loaded, the free camera's initial distance from the center (see below) is 1.5 times the extent. Must be strictly positive. If this attribute is specified, it replaces the value of mjModel.stat.center computed by the compiler. The computed value is the center of the bounding box of the entire model in the initial configuration. This 3D vector is used to center the view of the free camera when the model is first loaded. Key used for plugin configuration. Value associated with key. Name of the plugin instance. Plugin identifier, used for implicit plugin instantiation. The name of the array. This attribute is required because the only way to find a custom element of interest at runtime is through its name. If specified this attribute sets the size of the data array, in doubles. If this attribute is not specified, the size will be inferred from the actual data array below. Numeric data to be copied into mjModel. If size is specified, the length of the array given here cannot exceed the specified size. If the length of the array is smaller, the missing components are set to 0. Note that custom arrays can be created for storing information at runtime - which is why data initialization is optional. It becomes required only when the array size is omitted. Name of the custom text field. Custom text to be copied into mjModel. Type of the object being added. Name of the object being added. The type and name must reference a named MuJoCo element defined somewhere in the model. Tuples can also be referenced (including self-references). Real-valued parameter associated with this element of the tuple. Its use is up to the user. Name of the custom tuple. Key used for plugin configuration. Value associated with key. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. Name of the mesh, used for referencing. If omitted, the mesh name equals the file name without the path and extension. Defaults class for setting unspecified attributes (only scale in this case). If the file attribute is specified, then this sets the `Media Type <https://www.iana.org/assignments/media-types/media-types.xhtml>`__ (formerly known as MIME type) of the file to be loaded. Any filename extensions will be overloaded. Currently model/vnd.mujoco.msh, model/obj, and model/stl are supported. The file from which the mesh will be loaded. The path is determined as described in the meshdir attribute of compiler. The file extension must be "stl", "msh", or "obj" (not case sensitive) specifying the file type. If the file name is omitted, the vertex attribute becomes required. Vertex 3D position data. You can specify position data in the XML using this attribute, or using a binary file, but not both. Vertex 3D normal data. If specified, the number of normals must equal the number of vertices. The model compiler normalizes the normals automatically. Vertex 2D texture coordinates, which are numbers between 0 and 1. If specified, the number of texture coordinate pairs must equal the number of vertices. Faces of the mesh. Each face is a sequence of 3 vertex indices, in counter-clockwise order. The indices must be integers between 0 and nvert-1. Reference position relative to which the 3D vertex coordinates are defined. This vector is subtracted from the positions. Reference orientation relative to which the 3D vertex coordinates and normals are defined. The conjugate of this quaternion is used to rotate the positions and normals. The model compiler normalizes the quaternion automatically. This attribute specifies the scaling that will be applied to the vertex data along each coordinate axis. Negative values are allowed, resulting in flipping the mesh along the corresponding axis. Controls the automatic generation of vertex normals when normals are not given explicitly. If true, smooth normals are generated by averaging the face normals at each vertex, with weight proportional to the face area. If false, faces at large angles relative to the average normal are excluded from the average. In this way, sharp edges (as in cube edges) are not smoothed. Maximum number of vertices in a mesh's convex hull. Currently this is implemented by asking qhull `to terminate <http://www.qhull.org/html/qh-optt.htm#TAn>`__ after maxhullvert vertices. The default value of -1 means "unlimited". Positive values must be larger than 3. This attribute controls how the mesh is used when mass and inertia are inferred from geometry. The default value is legacy for backward compatibility, but convex is recommended. convex: Use the mesh's convex hull to compute volume and inertia, assuming uniform density. exact: Compute volume and inertia exactly, even for non-convex meshes. This algorithm requires a well-oriented, watertight mesh and will error otherwise. legacy: Use the legacy algorithm, leads to volume overcounting for non-convex meshes. Though currently the default to avoid breakages, it is not recommended. shell: Assume mass is concentrated on the surface of the mesh. Use the mesh's surface to compute the inertia, assuming uniform surface density. The mesh is generated by the compiler from a set of parameters specified in params. When saved to XML, meshes produced this way are converted to explicit vertices. The Python bindings include convenience methods for generating these meshes. The available built-in types, their parameters and semantics are: :width: 23% :align: right :target: https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/makemesh.xml sphere (subdivision) Repeated subdivisions of a unit icosahedron ("icosphere"). For s subdivisions, this mesh has V = 2 + 10 \cdot 4^s vertices and F = 20 \cdot 4^s faces. **subdivision**: integer in [0-4]: The number of subdivisions to apply to icosahedron faces. :width: 23% :align: right :target: https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/makemesh.xml hemisphere (resolution) Quad-projected hemisphere. For resolution r, this mesh has 4r edges and vertices on the equator and a total of V = 2 + 2(r+1)(r+2) vertices and F = 4(r+1)(r+2) faces. **resolution**: integer in [0-10]: Equator discretization of one hemisphere quadrant. :width: 23% :align: right :target: https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/makemesh.xml cone (nvert, radius) The convex hull of a regular unit polygon at z = -1 and a unit polygon with the given radius at z = 1. If radius is 1, the mesh a prism. If radius is 0, only a single vertex is placed at (0, 0, 1) and the mesh is a discrete cone. If radius is positive, the mesh is a truncated discrete cone. **nvert**: integer >= 3: The number vertices in the polygon. **radius**: real in [0, 1]: The radius of the top face. :width: 23% :align: right :target: https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/makemesh.xml supersphere (resolution, e, n) A generalization of a sphere, also known as a superellipsoid (we use 'supersphere' since semiaxis rescaling is performed by the scale attribute). If the **n** and **e** parameters are both 1, the shape is a sphere. See `here <https://en.wikipedia.org/wiki/Superellipsoid>`__ for more details. **resolution** integer >= 3: Longitude and latitude discretization. **e**: real >= 0: The "east-west" exponent. **n**: real >= 0: The "north-south" exponent. :width: 23% :align: right :target: https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/makemesh.xml supertorus (resolution, radius, s, t) A generalization of a torus with major radius of 1 and given minor radius. If the **s** and **t** parameters are both 1, the shape is a torus. See `here <https://en.wikipedia.org/wiki/Supertoroid>`__ for more details. Note that this shape is inherently non-convex, and the standard caveats about mesh collisions apply. **resolution** integer >= 3: Discretization of both circumfrences. **radius**: real in (0, 1]: The minor radius of the torus. **s**: real > 0: The "squareness" of minor sections. **t**: real > 0: The "squareness" of major sections. :width: 23% :align: right :target: https://github.com/google-deepmind/mujoco/blob/main/test/user/testdata/makemesh.xml wedge (res_phi, res_theta, fov_phi, fov_theta, gamma) A slice of a unit spherical shell in spherical coordinates. This mesh is designed to be used by the tactile sensor, which reports data at the vertices. **res_phi**: integer >= 0: The vertical resolution of the slice. **res_theta**: integer >= 0: The horizontal resolution of the slice. **fov_phi**: real in (0, 180]: The horizontal field of view (degrees). **fov_phi**: real in (0, 90): The vertical field of view (degrees). **gamma**: real in [0, 1]: Foveal deformation of the discretization. plate (res_x, res_y) A rectangular plate with given resolution in each dimension. This mesh is designed to be used by the tactile sensor, which reports data at the vertices. **res_x**: integer > 0: The horizontal resolution of the plate. **res_y**: integer > 0: The vertical resolution of the plate. The parameters used to generate a builtin mesh. The number and type of parameters and their semantic depends on the mesh type. See mesh/builtin for details. Fallback material for mesh geoms that do not specify their own material. Name of the height field, used for referencing. If the name is omitted and a file name is specified, the height field name equals the file name without the path and extension. If the file attribute is specified, then this sets the `Media Type <https://www.iana.org/assignments/media-types/media-types.xhtml>`__ (formerly known as MIME types) of the file to be loaded. Any filename extensions will be overloaded. Currently image/png and image/vnd.mujoco.hfield are supported. If this attribute is specified, the elevation data is loaded from the given file. If the file extension is ".png", not case-sensitive, the file is treated as a PNG file. Otherwise it is treated as a binary file in the above custom format. The number of rows and columns in the data are determined from the file contents. Loading data from a file and setting nrow or ncol below to non-zero values results is compile error, even if these settings are consistent with the file contents. This attribute and the next are used to allocate a height field in mjModel. If the elevation attribute is not set, the elevation data is set to 0. This attribute specifies the number of rows in the elevation data matrix. The default value of 0 means that the data will be loaded from a file, which will be used to infer the size of the matrix. This attribute specifies the number of columns in the elevation data matrix. :width: 350px :align: right The four numbers here are (radius_x, radius_y, elevation_z, base_z). The height field is centered at the referencing geom's local frame. Elevation is in the +Z direction. The first two numbers specify the X and Y extent (or "radius") of the rectangle over which the height field is defined. This may seem unnatural for rectangles, but it is natural for spheres and other geom types, and we prefer to use the same convention throughout the model. The third number is the maximum elevation; it scales the elevation data which is normalized to [0-1]. Thus the minimum elevation point is at Z=0 and the maximum elevation point is at Z=elevation_z. The last number is the depth of a box in the -Z direction serving as a "base" for the height field. Without this automatically generated box, the height field would have zero thickness at places there the normalized elevation data is zero. Unlike planes which impose global unilateral constraints, height fields are treated as unions of regular geoms, so there is no notion of being "under" the height field. Instead a geom is either inside or outside the height field - which is why the inside part must have non-zero thickness. The example on the right is the MATLAB "peaks" surface saved in our custom height field format, and loaded as an asset with size = "1 1 1 0.1". The horizontal size of the box is 2, the difference between the maximum and minimum elevation is 1, and the depth of the base added below the minimum elevation point is 0.1. This attribute specifies the elevation data matrix. Values are automatically normalized to lie between 0 and 1 by first subtracting the minimum value and then dividing by the (maximum-minimum) difference, if not 0. If not provided, values are set to 0. Note that the row order of data in mjModel and mjsHField is flipped w.r.t. the order in XML i.e., it is bottom-to-top. Name of the body corresponding to this bone. Global body position corresponding to the bind pose. Global body orientation corresponding to the bind pose. Integer indices of the vertices influenced by this bone. The vertex index corresponds to the order of the vertex in the skin mesh. The number of vertex indices specified here (nvert) must equal the number of vertex weights specified with the next attribute. The same vertex may be influenced by multiple bones, and each vertex must be influenced by at least one bone. Weights for the vertices influenced by this bone, in the same order as the vertex indices. Negative weights are allowed (which is needed for cubic interpolation for example) however the sum of all bone weights for a given vertex must be positive. Name of the skin. The SKN file from which the skin will be loaded. The path is determined as described in the meshdir attribute of compiler. If the file is omitted, the skin specification must be provided in the XML using the attributes below. Same meaning as in geom. Same meaning as in geom. The default value of 0 means that the automatically-generated skin passes through the centers of the body elements comprising the composite object. Positive values offset each skin vertex by the specified amount, in the direction normal to the (non-inflated) skin at that vertex. This has two uses. First, in 2D objects, a small positive inflate factor is needed to avoid aliasing artifacts. Second, collisions are done with geoms that create some thickness, even for 2D objects. Inflating the skin with a value equal to the geom size will render the skin as a "mattress" that better represents the actual collision geometry. The value of this attribute is copied into the corresponding attribute of the skin asset being created. Vertex 3D positions, in the global bind pose where the skin is defined. If this is true, explicit texture coordinates will be generated, mapping the skin to the unit square in texture space. This is needed when the material specifies a texture. If texcoord is false and the skin has texture, the texture will appear fixed to the world instead of the skin. The reason for having this attribute in the first place is because skins with texture coordinates upload these coordinates to the GPU even if no texture is applied later. So this attribute should be set to false in cases where no texture will be applied via the material attribute. Triangular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1. Same meaning as in geom. As with all other assets, a texture must have a name in order to be referenced. However if the texture is loaded from a single file with the file attribute, the explicit name can be omitted and the file name (without the path and extension) becomes the texture name. If the name after parsing is empty and the texture type is not "skybox", the compiler will generate an error. This attribute determines how the texture is represented and mapped to objects. It also determines which of the remaining attributes are relevant. The keywords have the following meaning: The **cube** type has the effect of shrink-wrapping a texture cube over an object. Apart from the adjustment provided by the texuniform attribute of material, the process is automatic. Internally the GPU constructs a ray from the center of the object to each pixel (or rather fragment), finds the intersection of this ray with the cube surface (the cube and the object have the same center), and uses the corresponding texture color. The six square images defining the cube can be the same or different; if they are the same, only one copy is stored in mjModel. There are four mechanisms for specifying the texture data: #. Single file (PNG or custom) specified with the file attribute, containing a square image which is repeated on each side of the cube. This is the most common approach. If for example the goal is to create the appearance of wood, repeating the same image on all sides is sufficient. #. Single file containing a composite image from which the six squares are extracted by the compiler. The layout of the composite image is determined by the gridsize and gridlayout attributes. #. Six separate files specified with the attributes fileright, fileleft etc, each containing one square image. #. Procedural texture generated internally. The type of procedural texture is determined by the builtin attribute. The texture data also depends on a number of parameters documented below. The **skybox** type is very similar to cube mapping, and in fact the texture data is specified in exactly the same way. The only difference is that the visualizer uses the first such texture defined in the model to render a skybox. This is a large box centered at the camera and always moving with it, with size determined automatically from the far clipping plane. The idea is that images on the skybox appear stationary, as if they are infinitely far away. If such a texture is referenced from a material applied to a regular object, the effect is equivalent to a cube map. Note however that the images suitable for skyboxes are rarely suitable for texturing objects. The **2d** type maps a 2D image to a 3D object using texture coordinates (a.k.a UV coordinates). However, UV coordinates are only available for meshes. For primitive geoms, the texture is mapped to the object surface using the local XY coordinates of the geom, effectively projecting the texture along the Z axis. This sort of mapping is only suitable for planes and height fields, since their top surfaces always face the Z axis. 2d textures can be rectangular, unlike the sides of cube textures which must be square. The scaling can be controlled with the texrepeat attribute of material. The data can be loaded from a single file or created procedurally. This attribute determines the color space of the texture. The default value auto means that the color space will be determined from the image file itself. If no color space is defined in the file, then linear is assumed. If the file attribute is specified, then this sets the `Media Type <https://www.iana.org/assignments/media-types/media-types.xhtml>`_ (formerly known as MIME types) of the file to be loaded. Any filename extensions will be ignored. Currently image/png, image/ktx, and image/vnd.mujoco.texture are supported. If this attribute is specified, and the builtin attribute below is set to "none", the texture data is loaded from a single file. See the texturedir attribute of compiler regarding the file path. When a cube or skybox texture is loaded from a single file, this attribute and the next specify how the six square sides of the texture cube are obtained from the single image. The default setting "1 1" means that the same image is repeated on all sides of the cube. Otherwise the image is interpreted as a grid from which the six sides are extracted. The two integers here correspond to the number of rows and columns in the grid. Each integer must be positive and the product of the two cannot exceed 12. The number of rows and columns in the image must be integer multiples of the number of rows and columns in the grid, and these two multiples must be equal, so that the extracted images are square. :width: 250px :align: right When a cube or skybox texture is loaded from a single file, and the grid size is different from "1 1", this attribute specifies which grid cells are used and which side of the cube they correspond to. There are many skybox textures available online as composite images, but they do not use the same convention, which is why we have designed a flexible mechanism for decoding them. The string specified here must be composed of characters from the set {'.', 'R', 'L', 'U', 'D', 'F', 'B'}. The number of characters must equal the product of the two grid sizes. The grid is scanned in row-major order. The '.' character denotes an unused cell. The other characters are the first letters of Right, Left, Up, Down, Front, Back; see below for coordinate frame description. If the symbol for a given side appears more than once, the last definition is used. If a given side is omitted, it is filled with the color specified by the rgb1 attribute. For example, the desert landscape below can be loaded as a skybox or a cube map using gridsize = "3 4" and gridlayout = ".U..LFRB.D.." The full-resolution image file without the markings can be downloaded `here <_static/desert.png>`__. These attributes are used to load the six sides of a cube or skybox texture from separate files, but only if the file attribute is omitted and the builtin attribute is set to "none". If any one of these attributes are omitted, the corresponding side is filled with the color specified by the rgb1 attribute. The coordinate frame here is unusual. When a skybox is viewed with the default free camera in its initial configuration, the Right, Left, Up, Down sides appear where one would expect them. The Back side appears in front of the viewer, because the viewer is in the middle of the box and is facing its back. There is however a complication. In MuJoCo the +Z axis points up, while existing skybox textures (which are non-trivial to design) tend to assume that the +Y axis points up. Changing coordinates cannot be done by merely renaming files; instead one would have to transpose and/or mirror some of the images. To avoid this complication, we render the skybox rotated by 90 deg around the +X axis, in violation of our convention. However we cannot do the same for regular objects. Thus the mapping of skybox and cube textures on regular objects, expressed in the local frame of the object, is as follows: Right = +X, Left = -X, Up = +Y, Down = -Y, Front = +Z, Back = -Z. These attributes are used to load the six sides of a cube or skybox texture from separate files, but only if the file attribute is omitted and the builtin attribute is set to "none". If any one of these attributes are omitted, the corresponding side is filled with the color specified by the rgb1 attribute. The coordinate frame here is unusual. When a skybox is viewed with the default free camera in its initial configuration, the Right, Left, Up, Down sides appear where one would expect them. The Back side appears in front of the viewer, because the viewer is in the middle of the box and is facing its back. There is however a complication. In MuJoCo the +Z axis points up, while existing skybox textures (which are non-trivial to design) tend to assume that the +Y axis points up. Changing coordinates cannot be done by merely renaming files; instead one would have to transpose and/or mirror some of the images. To avoid this complication, we render the skybox rotated by 90 deg around the +X axis, in violation of our convention. However we cannot do the same for regular objects. Thus the mapping of skybox and cube textures on regular objects, expressed in the local frame of the object, is as follows: Right = +X, Left = -X, Up = +Y, Down = -Y, Front = +Z, Back = -Z. These attributes are used to load the six sides of a cube or skybox texture from separate files, but only if the file attribute is omitted and the builtin attribute is set to "none". If any one of these attributes are omitted, the corresponding side is filled with the color specified by the rgb1 attribute. The coordinate frame here is unusual. When a skybox is viewed with the default free camera in its initial configuration, the Right, Left, Up, Down sides appear where one would expect them. The Back side appears in front of the viewer, because the viewer is in the middle of the box and is facing its back. There is however a complication. In MuJoCo the +Z axis points up, while existing skybox textures (which are non-trivial to design) tend to assume that the +Y axis points up. Changing coordinates cannot be done by merely renaming files; instead one would have to transpose and/or mirror some of the images. To avoid this complication, we render the skybox rotated by 90 deg around the +X axis, in violation of our convention. However we cannot do the same for regular objects. Thus the mapping of skybox and cube textures on regular objects, expressed in the local frame of the object, is as follows: Right = +X, Left = -X, Up = +Y, Down = -Y, Front = +Z, Back = -Z. These attributes are used to load the six sides of a cube or skybox texture from separate files, but only if the file attribute is omitted and the builtin attribute is set to "none". If any one of these attributes are omitted, the corresponding side is filled with the color specified by the rgb1 attribute. The coordinate frame here is unusual. When a skybox is viewed with the default free camera in its initial configuration, the Right, Left, Up, Down sides appear where one would expect them. The Back side appears in front of the viewer, because the viewer is in the middle of the box and is facing its back. There is however a complication. In MuJoCo the +Z axis points up, while existing skybox textures (which are non-trivial to design) tend to assume that the +Y axis points up. Changing coordinates cannot be done by merely renaming files; instead one would have to transpose and/or mirror some of the images. To avoid this complication, we render the skybox rotated by 90 deg around the +X axis, in violation of our convention. However we cannot do the same for regular objects. Thus the mapping of skybox and cube textures on regular objects, expressed in the local frame of the object, is as follows: Right = +X, Left = -X, Up = +Y, Down = -Y, Front = +Z, Back = -Z. These attributes are used to load the six sides of a cube or skybox texture from separate files, but only if the file attribute is omitted and the builtin attribute is set to "none". If any one of these attributes are omitted, the corresponding side is filled with the color specified by the rgb1 attribute. The coordinate frame here is unusual. When a skybox is viewed with the default free camera in its initial configuration, the Right, Left, Up, Down sides appear where one would expect them. The Back side appears in front of the viewer, because the viewer is in the middle of the box and is facing its back. There is however a complication. In MuJoCo the +Z axis points up, while existing skybox textures (which are non-trivial to design) tend to assume that the +Y axis points up. Changing coordinates cannot be done by merely renaming files; instead one would have to transpose and/or mirror some of the images. To avoid this complication, we render the skybox rotated by 90 deg around the +X axis, in violation of our convention. However we cannot do the same for regular objects. Thus the mapping of skybox and cube textures on regular objects, expressed in the local frame of the object, is as follows: Right = +X, Left = -X, Up = +Y, Down = -Y, Front = +Z, Back = -Z. These attributes are used to load the six sides of a cube or skybox texture from separate files, but only if the file attribute is omitted and the builtin attribute is set to "none". If any one of these attributes are omitted, the corresponding side is filled with the color specified by the rgb1 attribute. The coordinate frame here is unusual. When a skybox is viewed with the default free camera in its initial configuration, the Right, Left, Up, Down sides appear where one would expect them. The Back side appears in front of the viewer, because the viewer is in the middle of the box and is facing its back. There is however a complication. In MuJoCo the +Z axis points up, while existing skybox textures (which are non-trivial to design) tend to assume that the +Y axis points up. Changing coordinates cannot be done by merely renaming files; instead one would have to transpose and/or mirror some of the images. To avoid this complication, we render the skybox rotated by 90 deg around the +X axis, in violation of our convention. However we cannot do the same for regular objects. Thus the mapping of skybox and cube textures on regular objects, expressed in the local frame of the object, is as follows: Right = +X, Left = -X, Up = +Y, Down = -Y, Front = +Z, Back = -Z. This and the remaining attributes control the generation of procedural textures. If the value of this attribute is different from "none", the texture is treated as procedural and any file names are ignored. The keywords have the following meaning: **gradient** Generates a color gradient from rgb1 to rgb2. The interpolation in color space is done through a sigmoid function. For cube and skybox textures the gradient is along the +Y axis, i.e., from top to bottom for skybox rendering. **checker** Generates a 2-by-2 checker pattern with alternating colors given by rgb1 and rgb2. This is suitable for rendering ground planes and also for marking objects with rotational symmetries. Note that 2d textures can be scaled so as to repeat the pattern as many times as necessary. For cube and skybox textures, the checker pattern is painted on each side of the cube. **flat** Fills the entire texture with rgb1, except for the bottom face of cube and skybox textures which is filled with rgb2. The first color used for procedural texture generation. This color is also used to fill missing sides of cube and skybox textures loaded from files. The components of this and all other RGB(A) vectors should be in the range [0 1]. The second color used for procedural texture generation. Procedural textures can be marked with the markrgb color, on top of the colors determined by the builtin type. "edge" means that the edges of all texture images are marked. "cross" means that a cross is marked in the middle of each image. "random" means that randomly chosen pixels are marked. All markings are one-pixel wide, thus the markings appear larger and more diffuse on smaller textures. The color used for procedural texture markings. When the mark attribute is set to "random", this attribute determines the probability of turning on each pixel. Note that larger textures have more pixels, and the probability here is applied independently to each pixel -- thus the texture size and probability need to be adjusted jointly. Together with a gradient skybox texture, this can create the appearance of a night sky with stars. The random number generator is initialized with a fixed seed. The width of a procedural texture, i.e., the number of columns in the image. Larger values usually result in higher quality images, although in some cases (e.g. checker patterns) small values are sufficient. For textures loaded from files, this attribute is ignored. The height of the procedural texture, i.e., the number of rows in the image. For cube and skybox textures, this attribute is ignored and the height is set to 6 times the width. For textures loaded from files, this attribute is ignored. If true, images loaded from file are flipped in the horizontal direction. Does not affect procedural textures. If true, images loaded from file are flipped in the vertical direction. Does not affect procedural textures. The number of channels in the texture image file. This allows loading 4-channel textures (RGBA) or single-channel textures (e.g., for Physics-Based Rendering properties such as roughness or metallic). Name of the texture, like the texture attribute. Role of the texture. The valid values, expected number of channels, and the role semantics are: :widths: 1 1 8 :header-rows: 1 * - value - channels - description * - rgb - 3 - base color / albedo [red, green, blue] * - normal - 3 - bump map (surface normals) * - occlusion - 1 - ambient occlusion * - roughness - 1 - roughness * - metallic - 1 - metallicity * - opacity - 1 - opacity (alpha channel) * - emissive - 4 - RGB light emission intensity, exposure weight in 4th channel * - orm - 3 - packed 3 channel [occlusion, roughness, metallic] * - rgba - 4 - packed 4 channel [red, green, blue, alpha] Name of the material, used for referencing. Defaults class for setting unspecified attributes. If this attribute is specified, the material has a texture associated with it. Referencing the material from a model element will cause the texture to be applied to that element. Note that the value of this attribute is the name of a texture asset, not a texture file name. Textures cannot be loaded in the material definition; instead they must be loaded explicitly via the texture element and then referenced here. The texture referenced here is used for specifying the RGB values. For advanced rendering (e.g., Physics-Based Rendering), more texture types need to be specified (e.g., roughness, metallic). In this case, this texture attribute should be omitted, and the texture types should be specified using layer child elements. Note however that the built-in renderer does not support PBR properties, so these advanced rendering features are only available when using an external renderer. This attribute applies to textures of type "2d". It specifies how many times the texture image is repeated, relative to either the object size or the spatial unit, as determined by the next attribute. For cube textures, this attribute controls how cube mapping is applied. The default value "false" means apply cube mapping directly, using the actual size of the object. The value "true" maps the texture to a unit object before scaling it to its actual size (geometric primitives are created by the renderer as unit objects and then scaled). In some cases this leads to more uniform texture appearance, but in general, which settings produces better results depends on the texture and the object. For 2d textures, this attribute interacts with texrepeat above. Let texrepeat be N. The default value "false" means that the 2d texture is repeated N times over the (z-facing side of the) object. The value "true" means that the 2d texture is repeated N times over one spatial unit, regardless of object size. Emission in OpenGL has the RGBA format, however we only provide a scalar setting. The RGB components of the OpenGL emission vector are the RGB components of the material color multiplied by the value specified here. The alpha component is 1. Specularity in OpenGL has the RGBA format, however we only provide a scalar setting. The RGB components of the OpenGL specularity vector are all equal to the value specified here. The alpha component is 1. This value should be in the range [0 1]. Shininess in OpenGL is a number between 0 and 128. The value given here is multiplied by 128 before passing it to OpenGL, so it should be in the range [0 1]. Larger values correspond to tighter specular highlight (thus reducing the overall amount of highlight but making it more salient visually). This interacts with the specularity setting; see OpenGL documentation for details. This attribute should be in the range [0 1]. If the value is greater than 0, and the material is applied to a plane or a box geom, the renderer will simulate reflectance. The larger the value, the stronger the reflectance. For boxes, only the face in the direction of the local +Z axis is reflective. Simulating reflectance properly requires ray-tracing. This renderer uses the stencil buffer and suitable projections instead to approximate it. Only the first reflective geom in the model is rendered as such. This adds one extra rendering pass through all geoms, in addition to the extra rendering pass added by each shadow-casting light. This attribute corresponds to uniform metallicity coefficient applied to the entire material. This attribute has no effect in MuJoCo's native renderer, but it can be useful when rendering scenes with a physically-based renderer. In this case, if a non-negative value is specified, this metallic value should be multiplied by the metallic texture sampled value to obtain the final metallicity of the material. This attribute corresponds to uniform roughness coefficient applied to the entire material. This attribute has no effect in MuJoCo's native renderer, but it can be useful when rendering scenes with a physically-based renderer. In this case, if a non-negative value is specified, this roughness value should be multiplied by the roughness texture sampled value to obtain the final roughness of the material. Color and transparency of the material. All components should be in the range [0 1]. Note that the texture color (if assigned) and the color specified here are multiplied component-wise. Thus the default value of "1 1 1 1" has the effect of leaving the texture unchanged. When the material is applied to a model element which defines its own local rgba attribute, the local definition has precedence. Note that this "local" definition could in fact come from a defaults class. The remaining material properties always apply. Name of the sub-model, used for referencing in attach. If unspecified, the model name is used. The file from which the sub-model will be loaded. Note that the sub-model must be a valid MJCF model. The file type to be loaded into a model. Currently only text/xml is supported. Enables or disables internal collisions which prevent flex self-penetration and element inversion. Note that flex elements that have shared vertices cannot collide (or else there will be permanent contacts). In 1D and 2D, internal collision checks rely on predefined vertex-element pairs, where the vertex is treated as a sphere with the same radius as the flex. These spheres correspond to non-shared vertices of neighboring elements on the periphery of the flex. The pre-defined vertex-element pairs are generated by the model compiler automatically. In 3D, internal collision checks are performed within each tetraheron: each vertex is collided with the plane corresponding to the opposing triangle face (again using the flex radius). The resulting contacts are always created with condim 1, gap 0, margin 0. Note that internal contacts modify the behavior implied by the elasticity parameters and is recommended only for flexes where element inversion cannot be prevented. This determines the strategy for midphase collision pruning of element pairs belonging to the same flex. **none** means flex elements cannot collide with each other. **narrow** means narrow phase only (i.e. all pairs are checked). This is a diagnostic tool and is never a good idea in practice. **bvh** and **sap** refer to bounding volume hierarchies and sweep-and-prune (which are two different strategies for midphase collision pruning). **auto** selects **sap** in 1D and 2D, and **bvh** in 3D. Which strategy performs better depends on the specifics of the model. The automatic setting is just a simple rule which we have found to perform well in general. This only has an effect for 3D flexes. Each tetrahedron is labeled by the model compiler with an integer corresponding to (graph) distance to the outside surface of the flex. Thus outside-facing elements are in layer 0, their neighbors are in layer 1, etc. This attribute specifies how many layers will be allowed to participate in collisions. The default setting 1 means that only one layer (i.e. layer 0) can collide, with itself and with the rest of the world. This is usually sufficient, however if the outer layer is composed of small tetrahedra, another body can "pierce" it and get stuck. In that case the value should be increased. When enabled, the contact is not added to the contact solver but it is instead used to compute passive (spring-damper) contact forces. All contacts, regardless of the specified condim, are frictionless (condim 1). This is an experimental feature. Edge stiffness and damping, passed through to the automatically generated flex. Edge stiffness and damping, passed through to the automatically generated flex. Young's elastic modulus, a measure of tensile and compressive stiffness for continuum elastic materials. Units of \textrm{pressure}=\textrm{force}/\textrm{area}. Poisson's ratio, the ratio of transverse deformation to applied longitudinal strain. This unitless quantity is in the range [0, 0.5). Small or large values imply compressibility or incompressiblity, respectively. Rayleigh's damping coefficient, units of time. This quantity scales the stiffness defined by Young's modulus to produce the damping matrix. Shell thickness, units of length; only for used 2D flexes. Used to scale the stretching stiffness. This thickness can be set equal to 2 times the radius in order to match the geometry, but is exposed separately since the radius might be constrained by considerations related to collision detection. Elastic contribution to passive forces of 2D flexes. "none": none, "bend": bending only, "stretch": stretching only, "both": bending and stretching. Name of the flex. Integer group to which the flex belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of flexes. Dimensionality of the flex. Allowed values are 1, 2 and 3. In 1D the elements are capsules, in 2D the elements are triangles with radius, in 3D the elements are tetrahedra with (optional) radius. Radius of all flex elements. It can be zero in 3D, but must be positive in 1D and 2D. The radius affects both collision detection and rendering. In 1D and 2D it is needed to make the elements volumetric. If specified, this attribute applies a material to the flex. Note that textures specified in the material will be applied only if the flex has explicit texture coordinates. Instead of creating material assets and referencing them, this attribute can be used to set color and transparency only. This is not as flexible as the material mechanism, but is more convenient and is often sufficient. If the value of this attribute is different from the internal default, it takes precedence over the material. This attribute determines whether 2D and 3D flexes that are rendered in flexskin mode will use smooth or flat shading. The default smooth shading is suitable in most cases, however if the object is intended to have visible sharp edges (such as a cube) then flat shading is more natural. An array of MuJoCo body names (separated by white space) to which each vertex belongs. The number of body names should either equal the number of vertices (nvert), or be a single body. If a single body is specified, all vertices are defined within that body - in which case the flex becomes a rigid body. The latter functionality effectively creates a general non-convex mesh (unlike mesh geoms which are convexified for collision detection purposes). The local coordinates of the vertices within the corresponding body frames. If this attribute is omitted, all coordinates are (0,0,0) or in other words, the vertices coincide with the centers of the body frames. For each element of the flex, this lists the zero-based indices of the vertices forming that flex element. We need two vertices to specify a capsule, three vertices to specify a triangle, and four vertices to specify a tetrahedron - which is why the number of indices equals (dim+1) times the number of elements. In 2D, the vertices should be listed in counter-clockwise order. In 1D and 3D the order is irrelevant; in 3D the model compiler will rearrange the vertices as needed. Repeated vertex indices within a flex element are not allowed. The topology of the flex is not enforced; it could correspond to a continuous soft body, or a collection of disconnected stretchable elements, or anything in-between. Texture coordinates. If omitted, texture mapping for this flex is disabled, even if a texture is specified in the material. Texture indices for each face. If omitted, texture are assumed to be vertex-based. The degrees-of-freedom of the flex. An array of MuJoCo body names (separated by white space) to which each node belongs. The number of body names should equal the number of nodes (nnode). See the flexcomp dof attribute for more details. When using **trilinear** or **quadratic** dofs, this specifies the number of cells in each dimension for the background interpolation grid. Interpolation order for the flex. Name of the body corresponding to this bone. Global body position corresponding to the bind pose. Global body orientation corresponding to the bind pose. Integer indices of the vertices influenced by this bone. The vertex index corresponds to the order of the vertex in the skin mesh. The number of vertex indices specified here (nvert) must equal the number of vertex weights specified with the next attribute. The same vertex may be influenced by multiple bones, and each vertex must be influenced by at least one bone. Weights for the vertices influenced by this bone, in the same order as the vertex indices. Negative weights are allowed (which is needed for cubic interpolation for example) however the sum of all bone weights for a given vertex must be positive. Name of the skin. The SKN file from which the skin will be loaded. The path is determined as described in the meshdir attribute of compiler. If the file is omitted, the skin specification must be provided in the XML using the attributes below. Same meaning as in geom. Same meaning as in geom. The default value of 0 means that the automatically-generated skin passes through the centers of the body elements comprising the composite object. Positive values offset each skin vertex by the specified amount, in the direction normal to the (non-inflated) skin at that vertex. This has two uses. First, in 2D objects, a small positive inflate factor is needed to avoid aliasing artifacts. Second, collisions are done with geoms that create some thickness, even for 2D objects. Inflating the skin with a value equal to the geom size will render the skin as a "mattress" that better represents the actual collision geometry. The value of this attribute is copied into the corresponding attribute of the skin asset being created. Vertex 3D positions, in the global bind pose where the skin is defined. If this is true, explicit texture coordinates will be generated, mapping the skin to the unit square in texture space. This is needed when the material specifies a texture. If texcoord is false and the skin has texture, the texture will appear fixed to the world instead of the skin. The reason for having this attribute in the first place is because skins with texture coordinates upload these coordinates to the GPU even if no texture is applied later. So this attribute should be set to false in cases where no texture will be applied via the material attribute. Triangular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1. Same meaning as in geom. Name of this contact pair. Defaults class for setting unspecified attributes. The name of the first geom in the pair. The name of the second geom in the pair. The contact force vector computed by the solver and stored in mjData.efc_force points from the first towards the second geom by convention. The forces applied to the system are of course equal and opposite, so the order of geoms does not affect the physics. The dimensionality of the contacts generated by this geom pair. The friction coefficients of the contacts generated by this geom pair. Making the first two coefficients different results in anisotropic tangential friction. Making the last two coefficients different results in anisotropic rolling friction. The length of this array is not enforced by the parser, and can be smaller than 5. This is because some of the coefficients may not be used, depending on the contact dimensionality. Unspecified coefficients remain equal to their defaults. Constraint solver parameters for contact simulation. See CSolver. Contact reference acceleration, in the friction dimensions. This attribute has the same semantics as other solref attributes (described in CSolver), with two important distictions: - The default "0 0" means "use the same values as solref". - This attribute only takes effect for elliptic friction cones, since pyramidal cones mix normal and frictional forces. Note that as with other solreffriction attributes, the constraint violation is identically 0. Therefore, when using positive semantics solreffriction[1] is ignored, while for negative semantics solreffriction[0] is ignored. See Friction for more details. Constraint solver parameters for contact simulation. See CSolver. This attribute is used to enable the generation of inactive contacts, i.e., contacts that are ignored by the constraint solver but are included in mjData.contact for the purpose of custom computations. When this value is positive, geom distances between margin and margin-gap correspond to such inactive contacts. Distance threshold below which contacts are detected and included in the global array mjData.contact. Name of this exclude pair. The name of the first body in the pair. The name of the second body in the pair. Name of the equality constraint. Defaults class for setting unspecified attributes. Name of the first body participating in the constraint. Either this attribute and anchor must be specified, or site1 and site2 must be specified. Name of the second body participating in the constraint. If this attribute is omitted, the second body is the world body. Coordinates of the 3D anchor point where the two bodies are connected, in the local coordinate frame of body1. The constraint is assumed to be satisfied in the configuration at which the model is defined (mjData.qpos0), which lets the compiler compute the associated anchor point for body2. Name of a site belonging to the first body participating in the constraint. When specified, site2 must also be specified. The (site1, site2) specification is a more flexible alternative to the body-based specification, and is different in two ways. First, the sites are not required to overlap at the default configuration; if they do not overlap then the sites will "snap together" at the beginning of the simulation. Second, changing the site positions in mjModel.site_pos at runtime will correctly change the position of the constraint (i.e. the content of mjModel.eq_data has no effect when this semantic is used). Name of a site belonging to the second body participating in the constraint. When specified, site1 must also be specified. See the site1 description for more details. If this attribute is set to "true", the constraint is active and the constraint solver will try to enforce it. The field mjModel.eq_active0 corresponds to this value, and is used to initialize mjData.eq_active, which is user-settable at runtime. Constraint solver parameters for equality constraint simulation. See CSolver. Constraint solver parameters for equality constraint simulation. See CSolver. Same as in connect element. Same as in connect element. Name of the first body participating in the constraint. Either this attribute and must be specified or site1 and site2 must be specified. Name of the second body. If this attribute is omitted, the second body is the world body. Welding a body to the world and changing the corresponding component of mjData.eq_active at runtime can be used to fix the body temporarily. This attribute specifies the relative pose (3D position followed by 4D quaternion orientation) of the anchor point relative to body1. The position part (first 3 components) gives the anchor coordinates in the local frame of body1, and the quaternion part (last 4 components) gives the relative orientation of body2 relative to body1. If the quaternion part (i.e., last 4 components of the vector) are all zeros, as in the default setting, this attribute is ignored and the relative pose is the one corresponding to the model reference pose in qpos0. The unusual default is because all equality constraint types share the same default for their numeric parameters. Coordinates of the weld point relative to body2. If relpose is not specified, the meaning of this parameter is the same as for connect constraints, except that is relative to body2. If relpose is specified, body1 will use the pose to compute its anchor point. Name of a site belonging to the first body participating in the constraint. When specified, site2 must also be specified. The (site1, site2) specification is a more flexible alternative to the body-based specification, and is different in two ways. First, the sites are not required to overlap at the default configuration; if they do not overlap then the sites will "snap together" at the beginning of the simulation. Second, changing the site position and orientation in mjModel.site_pos and mjModel.site_quat at runtime will correctly change the position and orientation of the constraint (i.e. the content of mjModel.eq_data has no effect when this semantic is used, with the exception of torquescale). Name of a site belonging to the second body participating in the constraint. When specified, site1 must also be specified. See the site1 description for more details. Same as in connect element. Same as in connect element. Same as in connect element. A constant that scales the angular residual (angular constraint violation). Notionally in units of \textrm{torque}/\textrm{force}=\textrm{length}. Intuitively this coefficient defines how much the weld "cares" about rotational displacements vs. translational displacements. Setting this value to 0 makes the weld behave like a connect constraint. Note that this value has units of length and can therefore be understood as follows. Imagining that the weld is implemented by a flat patch of glue sticking the two bodies together, torquescale can be interpreted as the diameter of this glue patch. Name of the joint. Defaults class for setting unspecified attributes. Name of the first joint. Name of the second joint. If this attribute is omitted, the first joint is fixed to a constant. Coefficients a_0 \ldots a_4 of the quartic polynomial. If the joint values of joint1 and joint2 are respectively y and x, and their reference positions (corresponding to the joint values in the initial model configuration) are y_0 and x_0, the constraint is: y-y_0 = a_0 + a_1(x-x_0) + a_2(x-x_0)^2 + a_3(x-x_0)^3 + a_4(x-x_0)^4 Omitting joint2 is equivalent to setting x = x_0, in which case the constraint is y = y_0 + a_0. Same as in connect element. Same as in connect element. Same as in connect element. Same as in connect element. Same as in connect element. Name of the first tendon. Name of the second tendon. If this attribute is omitted, the first tendon is fixed to a constant. Same as in the equality/joint element above, but applied to tendon lengths instead of joint positions. Same as in connect element. Same as in connect element. Same as in connect element. Name of the flex. Same as in connect element. Name of the flex whose edges are being constrained. Same as in connect element. Same as in connect element. Same as in connect element. Same as in connect element. Same as in connect element. Name of the flex whose vertices are being constrained. Same as in connect element. Same as in connect element. Same as in connect element. Same as in connect element. Same as in connect element. Name of the flex whose strain is being constrained. 3D grid index (i, j, k) identifying the cell in the flex object. The grid size is specified in the cellcount attribute. Same as in connect element. Same as in connect element. Same as in connect element. The name of the site that the tendon must pass through. The name of a geom that acts as an obstacle for the tendon path. Only sphere and cylinder geoms can be referenced here. To prevent the tendon path from snapping from one side of the geom to the other as the model configuration varies, the user can define a preferred "side" of the geom. At runtime, the wrap that is closer to the specified site is automatically selected. Specifying a side site is often needed in practice. If the side site is inside the geom, the tendon is constrained to pass through the interior of the geom. The length of the tendon branch started by the pulley element is divided by the value specified here. For a physical pulley that splits a single branch into two parallel branches, the common branch would have divisor value of 1 and the two branches following the pulley would have divisor values of 2. If one of them is further split by another pulley, each new branch would have divisor value of 4 and so on. Note that in MJCF each branch starts with a pulley, thus a single physical pulley is modeled with two MJCF pulleys. If no pulley elements are included in the tendon path, the first and only branch has divisor value of 1. Name of the tendon. Defaults class for setting unspecified attributes. Integer group to which the tendon belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of tendons. If this attribute is "true", the length limits defined by the range attribute below are imposed by the constraint solver. If this attribute is "auto", and autolimits is set in compiler, length limits will be enabled if range is defined. This attribute specifies whether actuator forces acting on the tendon should be clamped. See CForceRange for details. This attribute interacts with the actuatorfrcrange attribute. If this attribute is "false", actuator force clamping is disabled. If it is "true", actuator force clamping is enabled. If this attribute is "auto", and autolimits is set in compiler, actuator force clamping will be enabled if actuatorfrcrange is defined. Range of allowed tendon lengths. Setting this attribute without specifying limited is an error, unless autolimits is set in compiler. Range for clamping total actuator forces acting on this tendon. See CForceRange for details. The compiler expects the lower bound to be nonpositive and the upper bound to be nonnegative. Setting this attribute without specifying actuatorfrclimited is an error if compiler-autolimits is "false". Constraint solver parameters for simulating tendon limits. See CSolver. Constraint solver parameters for simulating tendon limits. See CSolver. Constraint solver parameters for simulating dry friction in the tendon. See also Friction. Constraint solver parameters for simulating dry friction in the tendon. See also Friction. Friction loss caused by dry friction. To enable friction loss, set this attribute to a positive value. Spring resting position, can take either one or two values. If one value is given, it corresponds to the length of the tendon at rest. If it is -1, the tendon resting length is determined from the model reference configuration in mjModel.qpos0. Note that the default value of -1, which invokes the automatic length computation, was designed with spatial tendons in mind, which can only have nonegative length. In order to set the springlength of a fixed tendon to -1, use a nearby value like -0.99999. If two non-decreasing values are given, they define a `dead-band <https://en.wikipedia.org/wiki/Deadband>`_ range. If the tendon length is between the two values, the force is 0. If it is outside this range, the force behaves like a regular spring, with the rest-point corresponding to the nearest springlength value. A deadband can be used to define tendons whose limits are enforced by springs rather than constraints. Radius of the cross-section area of the spatial tendon, used for rendering. Parts of the tendon that wrap around geom obstacles are rendered with reduced width. Material used to set the appearance of the tendon. The limit constraint becomes active when the absolute value of the difference between the tendon length and either limit of the specified range falls below this margin. Similar to contacts, the margin parameter is subtracted from the difference between the range limit and the tendon length. The resulting constraint distance is always negative when the constraint is active. This quantity is used to compute constraint impedance as a function of distance, as explained in CSolver. Damping coefficients a, b, c. A positive a produces the standard dissipative linear damping force f(v) = -a v. If the optional second and third components are set, they define a nonlinear polynomial damping force f(v) = -(a v + b v + c v^3). Note the anti-symmetrization of the quadratic term, ensuring that the force is an odd function of velocity. See Polynomial forces for details. Inertia associated with changes in tendon length. Setting this attribute to a positive value m adds a kinetic energy term \frac{1}{2}mv^2, where v is the tendon velocity. Tendon inertia is most valuable when modeling the armature inertia in a linear actuator which contains a spinning element or the inertial motion of a fluid in a linear hydraulic actuator. In the illustration, we compare (*left*) a 3-dof system with a "tendon" implemented with a rotational joint and a slider joint with armature, attached to the world with a connect constraint and (*right*) an equivalent 1-dof model with an armature-bearing tendon. Like joint armature, this added inertia is only associated with changes in tendon length, and would not affect the dynamics of a moving fixed-length tendon. Because the tendon Jacobian J is position-dependent, tendon armature leads to an additional bias-force term c = m J \dot{J}^T \dot{q}. Color and transparency of the tendon. When this value is different from the internal default, it overrides the corresponding material properties. If a material is unspecified and rgba has the default value, limited tendons whose length exceeds the limit are recolored using the value of the constraint impedance d to mix the default color and rgba/constraint. See CUser. Name of the joint to be added to the fixed tendon. Only scalar joints (slide and hinge) can be referenced here. Scalar coefficient multiplying the position or angle of the specified joint. Same as in connect element. Same as in connect element. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". If true, the internal state (activation) associated with this actuator is automatically clamped to actrange at runtime. If false, activation clamping is disabled. If "auto" and autolimits is set in compiler, activation clamping will automatically be set to true if actrange is defined without explicitly setting this attribute to "true". See the Activation clamping section for more details. Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range for clamping the activation state. The first value must be no greater than the second value. See the Activation clamping section for more details. Setting this attribute without specifying actlimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. This transmission can apply linear forces at contact points in the direction of the contact normal. The set of contacts is all those belonging to the specified body. This can be used to model natural active adhesion mechanisms like the feet of geckos and insects. The actuator length is again defined as zero. For more information, see the adhesion shortcut below. Dimension of the activation state. The default value of -1 instructs the compiler to set the dimension according to the dyntype. Values larger than 1 are only allowed for user-defined activation dynamics, as native types require dimensions of only 0 or 1. For activation dimensions bigger than 1, the *last element* is used to generate force. Activation dynamics type for the actuator. The available dynamics types were already described in the Actuation model section. Repeating that description in somewhat different notation (corresponding to the mjModel and mjData fields involved) we have: =========== ====================================== Keyword Description =========== ====================================== none No internal state integrator act_dot = ctrl filter act_dot = (ctrl - act) / dynprm[0] filterexact Like filter but with exact integration muscle act_dot = mju_muscleDynamics(...) user act_dot = mjcb_act_dyn(...) =========== ====================================== The gain and bias together determine the output of the force generation mechanism, which is currently assumed to be affine. As already explained in Actuation model, the general formula is: scalar_force = gain_term \* (act or ctrl) + bias_term. The formula uses the activation state when present, and the control otherwise. The keywords have the following meaning: ======= =============================== Keyword Description ======= =============================== fixed gain_term = gainprm[0] affine gain_term = gain_prm[0] + gain_prm[1]*length + gain_prm[2]*velocity muscle gain_term = mju_muscleGain(...) user gain_term = mjcb_act_gain(...) ======= =============================== The keywords have the following meaning: ======= ================================================================ Keyword Description ======= ================================================================ none bias_term = 0 affine bias_term = biasprm[0] + biasprm[1]*length + biasprm[2]*velocity muscle bias_term = mju_muscleBias(...) user bias_term = mjcb_act_bias(...) ======= ================================================================ Activation dynamics parameters. The built-in activation types (except for muscle) use only the first parameter, but we provide additional parameters in case user callbacks implement a more elaborate model. The length of this array is not enforced by the parser, so the user can enter as many parameters as needed. These defaults are not compatible with muscle actuators; see muscle below. Gain parameters. The built-in gain types (except for muscle) use only the first parameter, but we provide additional parameters in case user callbacks implement a more elaborate model. The length of this array is not enforced by the parser, so the user can enter as many parameters as needed. These defaults are not compatible with muscle actuators; see muscle below. Bias parameters. The affine bias type uses three parameters. The length of this array is not enforced by the parser, so the user can enter as many parameters as needed. These defaults are not compatible with muscle actuators; see muscle below. If true, force computation will use the next value of the activation variable rather than the current one. Setting this flag reduces the delay between the control and accelerations by one time-step. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Automatically set the actuator's ctrlrange to match the transmission target's range. The default value means "disabled". A positive value X sets the ctrlrange around the midpoint of the target range, scaled by X. For example if the target joint has range of [0, 1], then a value of 1.0 will set ctrlrange to [0, 1]; values of 0.8 and 1.2 will set the ctrlrange to [0.1, 0.9] and [-0.1, 1.1], respectively. Values smaller than 1 are useful for not hitting the limits; values larger than 1 are useful for maintaining control authority at the limits (being able to push on them). This attribute is exclusive with ctrlrange and available only for joint and tendon transmissions which have range defined. Note that while inheritrange is available both as a position attribute and in the default class, saved XMLs always convert it to explicit ctrlrange at the actuator. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. Position feedback gain. Damping applied by the actuator. When using this attribute, it is recommended to use the implicitfast or implicit integrators. Damping applied by the actuator, using damping ratio units. This attribute is exclusive with kv and has similar meaning, but instead of units of force/velocity, the units are 2 \sqrt{k_p \cdot m}, corresponding to a harmonic oscillator's `damping ratio <https://en.wikipedia.org/wiki/Damping#Damping_ratio_definition>`__. A value of 1 corresponds to a *critically damped* oscillator, which often produces desirable behavior. Values smaller or larger than 1 correspond to underdamped and overdamped oscillations, respectively. The mass m is computed at the reference configuration mjModel.qpos0, taking into account joint armature. However, passive damping or frictionloss in the affected joints are not taken into account; if they are non-negligible, dampratio values smaller than 1 might be required to achieve desirable motion. When using this attribute, it is recommended to use the implicitfast or implicit integrators. Time-constant of optional first-order filter. If larger than zero, the actuator uses the filterexact dynamics type, if zero (the default) no filter is used. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. Velocity feedback gain. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range for clamping the activation state. The first value must be no greater than the second value. See the Activation clamping section for more details. Setting this attribute without specifying actlimited is an error if autolimits is "false" in compiler. Identical to position/inheritrange, but sets actrange (which has the same length semantics as the transmission target) rather than ctrlrange (which has velocity semantics). Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. Position feedback gain. Damping applied by the actuator. When using this attribute, it is recommended to use the implicitfast or implicit integrators. See position/dampratio. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. Velocity feedback gain. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. Time constant of the activation dynamics. Area of the cylinder. This is used internally as actuator gain. Instead of area the user can specify diameter. If both are specified, diameter has precedence. Bias parameters, copied internally into biasprm. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. Time constants for activation and de-activation dynamics. Width of smooth transition between activation and deactivation time constants. Units of ctrl, must be nonnegative. Operating length range of the muscle, in units of L0. Peak active force at rest. If this value is negative, the peak force is determined automatically using the scale attribute below. If the force attribute is negative, the peak active force for the muscle is set to this value divided by mjModel.actuator_acc0. The latter is the norm of the joint-space acceleration vector caused by unit force on the actuator's transmission in qpos0. In other words, scaling produces higher peak forces for muscles that pull more weight. Lower position range of the normalized FLV curve, in units of L0. Upper position range of the normalized FLV curve, in units of L0. Shortening velocity at which muscle force drops to zero, in units of L0 per second. Passive force generated at lmax, relative to the peak rest force. Active force generated at saturating lengthening velocity, relative to the peak rest force. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. See CUser. The actuator acts on all contacts involving this body's geoms. Gain of the adhesion actuator, in units of force. The total adhesion force applied by the actuator is the control value multiplied by the gain. This force is distributed equally between all the contacts involving geoms belonging to the target body. Element name. See CName. Active defaults class. See CDefault. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. See CUser. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. When using a site transmission, measure the translation and rotation w.r.t the frame of the refsite. In this case the actuator *does* have length and position actuators can be used to directly control an end effector, see `refsite.xml <https://github.com/google-deepmind/mujoco/tree/main/test/engine/testdata/actuation/refsite.xml>`__ example model. As above, the length is the dot product of the gear vector and the frame difference. So gear="0 1 0 0 0 0" means "Y-offset of site in the refsite frame", while gear="0 0 0 0 0 1" means rotation "Z- rotation of site in the refsite frame". It is recommended to use a normalized gear vector with nonzeros in only the first 3 *or* the last 3 elements of gear, so the actuator length will be in either length units or radians, respectively. As with ball joints (see joint above), for rotations which exceed a total angle of \pi will wrap around, so tighter limits are recommended. Motor constants, defined as motorconst = "Kt Ke" (N·m/A, equivalently V·s/rad). Kt is the torque constant and Ke the back-EMF constant; they can differ when magnetic saturation is present. If both are positive, the effective constant is K = \sqrt{K_t K_e} (geometric mean). If only one is positive, K equals that value. If a datasheet specifies the speed constant K_v in rad/(V·s), use K_e = 1/K_v. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1 and 2.1) Terminal resistance R in Ohm. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1 and 2.1) Nominal operating point, defined as nominal = "voltage stall_torque no_load_speed". The compiler derives K = voltage / no_load_speed and R = K · voltage / stall_torque. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1 and 2.1) Limits on the actuator, defined as saturation = "torque current current_rate". torque and current are alternative specifications of the maximum continuous torque: if current is given, torque = K \cdot current; if both are given, torque takes precedence. Sets forcerange to [-\tau_{\max},\, \tau_{\max}]. current_rate sets the maximum rate of change of current (di/dt)_{\max} (requires inductance). A value of 0 (the default) for any sub-value disables the respective limit. (see `tech note <_static/dcmotor.pdf>`__, Section 2) Electrical dynamics, defined as inductance = "L timeconst" (Henry, seconds). These are alternative specifications: L is the winding inductance and timeconst = L/R is the electrical time constant. Specify one; if both are given, L takes precedence. If both are 0 (the default), no electrical dynamics are modeled and the current is computed algebraically. Adds one activation variable for armature current. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.1.1 and 2.2) Cogging torque, defined as cogging = "amplitude poles phase" (N·m, integer, rad). Adds a position-dependent torque = \textsf{amplitude} \cdot \sin(\textsf{poles} \cdot \theta + \textsf{phase}). Disabled when amplitude = 0 (the default). (see `tech note <_static/dcmotor.pdf>`__, Sections 1.2 and 2.1) PID controller parameters, defined as controller = "kp ki kd slewmax Imax Vmax". Depending on the input mode, the controller stabilizes either position or velocity. If the input mode is voltage, kp, ki, kd are ignored. Vmax sets the maximum drive voltage v_{\max} (Volt); in position/velocity modes it clamps the controller output, in voltage mode it clamps the control signal (if ctrlrange is also set, the tighter limit wins). A value of 0 (the default) disables the respective feature. When positive, slewmax limits the setpoint rate-of-change, Imax clamps the integrator state (anti-windup), and Vmax clamps the drive voltage. (see `tech note <_static/dcmotor.pdf>`__, Section 2.5) Thermal model, defined as thermal = "resistance capacitance timeconst tempcoef reftemp ambient" (K/W, J/K, s, 1/K, °C, °C). The first three sub-values specify the thermal time constant: timeconst = resistance \times capacitance. Specify either timeconst directly, or resistance and capacitance; if all three are given, timeconst takes precedence. If all are 0 (the default), thermal modeling is disabled. Adds one activation variable for winding temperature. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.3 and 2.3) LuGre friction, defined as lugre = "stiffness damping coulomb static stribeck" (N·m/rad, N·m·s/rad, N·m, N·m, rad/s). Disabled when stiffness = 0 (the default). Adds one activation variable for bristle deflection. Note that the viscous damping coefficient \sigma_2 is not part of the lugre attribute and should be added to the standard actuator damping attribute. (see `tech note <_static/dcmotor.pdf>`__, Sections 1.4 and 2.4) Specifies the input signal semantics. In "voltage" mode, the control directly sets applied motor voltage. In "position" or "velocity" modes, the PID controller uses the control as a reference setpoint relative to the joint trajectory. (see `tech note <_static/dcmotor.pdf>`__, Section 2.5) Key used for plugin configuration. Value associated with key. Element name. See CName. Active defaults class. See CDefault. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. Integer group to which the actuator belongs. This attribute can be used for custom tags. It is also used by the visualizer to enable and disable the rendering of entire groups of actuators. If greater than 0, this attribute creates a time-indexed ring buffer with nsample samples of this actuator's ctrl history. During state advancement, the current control input is appended to the buffer with timestamp time, and the oldest sample is removed. Values in the history buffer can be read via mj_readCtrl. A positive nsample is required for delay. See Delays for details. The interpolation method used when reading from the history buffer. Corresponds to the interp argument in mj_readCtrl. - zoh: Zero-order hold (piecewise constant). - linear: Piecewise linear interpolation. - cubic: Cubic spline interpolation (Catmull-Rom). The interp value is for advanced use-cases, see Delays for details. If greater than 0, then during the forward dynamics, instead of reading the control input to the actuator from mjData.ctrl, the control input is read from the history buffer using mj_readCtrl. Requires a history buffer (nsample > 0). In the most common case, delay = nsample * timestep. If true, the control input to this actuator is automatically clamped to ctrlrange at runtime. If false, control input clamping is disabled. If "auto" and autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true". Note that control input clamping can also be globally disabled with the clampctrl attribute of option/flag. If true, the force output of this actuator is automatically clamped to forcerange at runtime. If false, force clamping is disabled. If "auto" and autolimits is set in compiler, force clamping will automatically be set to true if forcerange is defined without explicitly setting this attribute to "true". If true, the internal state (activation) associated with this actuator is automatically clamped to actrange at runtime. If false, activation clamping is disabled. If "auto" and autolimits is set in compiler, activation clamping will automatically be set to true if actrange is defined without explicitly setting this attribute to "true". See the Activation clamping section for more details. Range for clamping the control input. The first value must be smaller than the second value. Setting this attribute without specifying ctrllimited is an error if autolimits is "false" in compiler. Range for clamping the force output. The first value must be no greater than the second value. Setting this attribute without specifying forcelimited is an error if autolimits is "false" in compiler. Range for clamping the activation state associated with this actuator's dyntype. The limit doesn't apply to activations computed by the plugin. The first value must be no greater than the second value. See the Activation clamping section for more details. Range of feasible lengths of the actuator's transmission. See Length Range. This attribute scales the length (and consequently moment arms, velocity and force) of the actuator, for all transmission types. It is different from the gain in the force generation mechanism, because the gain only scales the force output and does not affect the length, moment arms and velocity. For actuators with scalar transmission, only the first element of this vector is used. The remaining elements are needed for joint, jointinparent and site transmissions where this attribute is used to specify 3D force and torque axes. Viscous damping coefficients, contributed by the actuator to its transmission target (joint or tendon only). The damping value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to reflected damping (analogous to reflected inertia). Like joint damping, coefficients correspond to linear, quadratic and cubic velocity. See Polynomial forces for details. Several actuator shortcuts have a kv attribute which maps to -biasprm[2] and has similar semantics to damping: (e.g., position/kv). The differences between these attributes are: - damping is applied at the transmission target, and therefore includes the gear\ 2 factor. This factor is not required for kv as it is already applied in actuator space (so the units are identical). - Implicit integration works for damping when using the Euler integrator but not for kv. To get implicit integration for kv, implicit or implicitfast is required, see Integrators. - damping allows for polynomial damping, while kv is only linear. - Damping forces generated by kv are subject to forcerange clamping, but forces generated by damping are not. Finally, note that while it is permitted for nonzero damping and armature to be specified for multiple actuators acting on the same transmission target, it is more performant to specify them for only one actuator. Since these values are summed anyway, it is recommended to place all damping and armature for one transmission target in a single actuator definition. Armature inertia (or mass for slider joints) contributed by the actuator to its transmission target (joint or tendon only). This is the actual inertia of the spinning element inside the actuator (e.g., a rotor). The contributed value is scaled by gear squared, because the gear ratio scales both forces and velocities, leading to `reflected inertia <https://en.wikipedia.org/wiki/Reflective_inertia>`__. See joint and tendon armature for more details. See also the note in damping regarding multiple actuators acting on the same transmission target. Used only for the slider-crank transmission type. Specifies the length of the connecting rod. The compiler expects this value to be positive when a slider-crank transmission is present. This and the next four attributes determine the type of actuator transmission. All of them are optional, and exactly one of them must be specified. If this attribute is specified, the actuator acts on the given joint. For **hinge** and **slide** joints, the actuator length equals the joint position/angle times the first element of gear. For **ball** joints, the first three elements of gear define a 3d rotation axis in the child frame around which the actuator produces torque. The actuator length is defined as the dot-product between this gear axis and the angle-axis representation of the joint quaternion, and is in units of radian if gear is normalized (generally scaled by by the norm of gear). Note that after total rotation of more than \pi, the length will wrap to - \pi, and vice-versa. Therefore position servos for ball joints should generally use tighter limits which prevent this wrapping. For **free** joints, gear defines a 3d translation axis in the world frame followed by a 3d rotation axis in the child frame. The actuator generates force and torque relative to the specified axes. The actuator length for free joints is defined as zero (so it should not be used with position servos). Identical to joint, except that for ball and free joints, the 3d rotation axis given by gear is defined in the parent frame (which is the world frame for free joints) rather than the child frame. This transmission can apply force and torque at a site. The gear vector defines a 3d translation axis followed by a 3d rotation axis. Both are defined in the site's frame. This can be used to model jets and propellers. The effect is similar to actuating a free joint, and the actuator length is defined as zero unless a refsite is defined (see below). One difference from the joint and jointinparent transmissions above is that here the actuator operates on a site rather than a joint, but this difference disappears when the site is defined at the frame origin of the free-floating body. The other difference is that for site transmissions both the translation and rotation axes are defined in local coordinates. In contrast, translation is global and rotation is local for joint, and both translation and rotation are global for jointinparent. Dimension of the activation state. The default value of -1 instructs the compiler to set the dimension according to the dyntype. Values larger than 1 are only allowed for user-defined activation dynamics, as native types require dimensions of only 0 or 1. For activation dimensions bigger than 1, the *last element* is used to generate force. Activation dynamics type for the actuator. The available dynamics types were already described in the Actuation model section. If dyntype is not "none", an activation variable will be added to the actuator. This variable will be added after any activation state computed by the plugin (see actuator plugin activations). Activation dynamics parameters. The built-in activation types (except for muscle) use only the first parameter, but we provide additional parameters in case user callbacks implement a more elaborate model. The length of this array is not enforced by the parser, so the user can enter as many parameters as needed. These defaults are not compatible with muscle actuators; see muscle below. If specified, the actuator acts on the given tendon. The actuator length equals the tendon length times the gear ratio. Both spatial and fixed tendons can be used. If specified, the actuator acts on a slider-crank mechanism which is implicitly determined by the actuator (i.e., it is not a separate model element). The specified site corresponds to the pin joining the crank and the connecting rod. The actuator length equals the position of the slider-crank mechanism times the gear ratio. Used only for the slider-crank transmission type. The specified site is the pin joining the slider and the connecting rod. The slider moves along the z-axis of the slidersite frame. Therefore the site should be oriented as needed when it is defined in the kinematic tree; its orientation cannot be changed in the actuator definition. See CUser. If true, force computation will use the next value of the activation variable rather than the current one. Setting this flag reduces the delay between the control and accelerations by one time-step. See CSensor. Site defining the active sensor zone. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Site where the sensor is mounted. The accelerometer is centered and aligned with the site local frame. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Site where the sensor is mounted. The velocimeter is centered and aligned with the site local frame. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Site where the sensor is mounted. The gyroscope is centered and aligned with the site local frame. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Site where the sensor is mounted. The measured interaction force is between the body where the site is defined and its parent body, and points from the child towards the parent. The physical sensor being modeled could of course be attached to the parent body, in which case the sensor data would have the opposite sign. Note that each body has a unique parent but can have multiple children, which is why we define this sensor through the child rather than the parent body in the pair. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Site where the sensor is mounted. The measured interaction torque is between the body where the site is defined and its parent body. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The site where the sensor is attached. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The site which is projected on to the camera image. The camera used for the projection, its resolution attribute must be positive. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The site where the sensor is attached. The camera where the sensor is attached. By default, the rangefinder outputs a distance measurement, as described above. However, it is also possible to specify a set of output data fields. The data attribute can contain **multiple sequential data types**, as long as the relative order---as listed above---is maintained. For example, data = "dist point normal" will return 7 numbers per ray, while data = "point origin" is an error because origin must come before point. - dist **real(1)**: The distance from the ray origin to the nearest geom surface, -1 if no surface was hit. If this data type is included, rays will be visualized as lines. - dir **real(3)**: Normalized direction of the ray, or (0, 0, 0) if no surface was hit. - origin **real(3)**: The point from which the ray emanates (global frame). For sites and perspective cameras, this is the site/camera xpos. However for orthographic cameras, ray origins are spatially distributed along the image plane. - point **real(3)**: The point where the ray intersects the nearest geom surface in the global frame, or (0, 0, 0) if no surface was hit. If this data type is included, intersection points will be visualized as spheres. - normal: **real(3)**: The geom surface normal at the point where the ray intersects it, in the global frame, or (0, 0, 0) if no surface was hit. Note that normals always point towards the outside of the geom surface, regardless of the ray origin. If this data type is included along with either dist or point, normals will be visualized as arrows at the intersection points. - depth: **real(1)**: The distance of the hit point from the camera plane, -1 if no surface was hit. Note that this depth semantic corresponds to depth images in the computer graphics sense. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The joint whose position or angle will be sensed. Only scalar joints can be referenced here. The sensor output is copied from mjData.qpos. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The joint whose velocity will be sensed. Only scalar joints can be referenced here. The sensor output is copied from mjData.qvel. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The tendon whose length will be sensed. The sensor output is copied from mjData.ten_length. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The tendon whose velocity will be sensed. The sensor output is copied from mjData.ten_velocity. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The actuator whose transmission's length will be sensed. The sensor output is copied from mjData.actuator_length. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The actuator whose transmission's velocity will be sensed. The sensor output is copied from mjData.actuator_velocity. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The actuator whose scalar force output will be sensed. The sensor output is copied from mjData.actuator_force. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The joint where actuator forces will be sensed. The sensor output is copied from mjData.qfrc_actuator. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The tendon where actuator forces will be sensed. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The ball joint whose quaternion is sensed. The sensor output is copied from mjData.qpos. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The ball joint whose angular velocity is sensed. The sensor output is copied from mjData.qvel. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The joint whose limit is sensed. The sensor output equals mjData.efc_pos - mjData.efc_margin for the corresponding limit constraint. Note that the result is negative if the limit is violated, regardless of which side of the limit is violated. If both sides of the limit are violated simultaneously, only the first component is returned. If there is no violation, the result is 0. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The joint whose limit is sensed. The sensor output is copied from mjData.efc_vel. If the joint limit is not violated, the result is 0. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The joint whose limit is sensed. The sensor output is copied from mjData.efc_force. If the joint limit is not violated, the result is 0. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The tendon whose limit is sensed. The sensor output equals mjData.efc_pos - mjData.efc_margin for the corresponding limit constraint. If the tendon limit is not violated, the result is 0. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The tendon whose limit is sensed. The sensor output is copied from mjData.efc_vel. If the tendon limit is not violated, the result is 0. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The tendon whose limit is sensed. The sensor output is copied from mjData.efc_force. If the tendon limit is not violated, the result is 0. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The type of object to which the sensor is attached. This must be an object type that has a spatial frame. "body" refers to the inertial frame of the body, while "xbody" refers to the regular frame of the body (usually centered at the joint with the parent body). The name of the object to which the sensor is attached. The type of object to which the frame-of-reference is attached. The semantics are identical to the objtype attribute. If reftype and refname are given, the sensor values will be measured with respect to this frame. If they are not given, sensor values will be measured with respect to the global frame. The name of the object to which the frame-of-reference is attached. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See framepos sensor. See framepos sensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Name of the body where the kinematic subtree is rooted. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Name of the body where the kinematic subtree is rooted. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Name of the body where the kinematic subtree is rooted. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. The site defining the volume used for the inside check. The type of the object whose position will be queried. See framepos. The name of the object whose position will be queried. See framepos. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Name of the first geom. Exactly one of (geom1, body1) must be specified. Name of the second geom. Exactly one of (geom2, body2) must be specified. Name of the first body. Exactly one of (geom1, body1) must be specified. Name of the second body. Exactly one of (geom2, body2) must be specified. See CSensor. See CSensor. See CSensor. See 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 cutoff value, so in this case cutoff acts as a maximum clipping value, in addition to the special semantics. See CSensor. See CSensor. See CSensor. Name of the first geom. Exactly one of (geom1, body1) must be specified. Name of the second geom. Exactly one of (geom2, body2) must be specified. Name of the first body. Exactly one of (geom1, body1) must be specified. Name of the second body. Exactly one of (geom2, body2) must be specified. See CSensor. See CSensor. See CSensor. See collision-sensors for the semantics of this attribute, which is different than for other sensor categories. If no collision is detected, the normal sensor returns (0, 0, 0), otherwise it returns a normalized direction vector. For this sensor, cutoff does not lead to any clamping. See CSensor. See CSensor. See CSensor. Name of the first geom. Exactly one of (geom1, body1) must be specified. Name of the second geom. Exactly one of (geom2, body2) must be specified. Name of the first body. Exactly one of (geom1, body1) must be specified. Name of the second body. Exactly one of (geom2, body2) must be specified. See CSensor. See CSensor. See CSensor. See collision-sensors for the semantics of this attribute, which is different than for other sensor categories. If no collision is detected, the fromto sensor returns 6 zeros. For this sensor, cutoff does not lead to any clamping. See CSensor. See CSensor. See CSensor. Name of a geom participating in a contact. See **matching** above. Name of a geom participating in a contact. See **matching** above. Name of a body participating in a contact. See **matching** above. Name of a body participating in a contact. See **matching** above. Name of a body whose subtree is participating in a contact. See **matching** above. Name of a body whose subtree is participating in a contact. See **matching** above. Name of a site within whose volume the contact position must be found in order to match. See **matching** above. Number of contacts to report. The sensor will always report num sequential data arrays ("slots") per contact. The order in which contacts are reported depends on the reduce attribute. Specification of which data field(s) to report from the selected contacts. - found **real(1)**: This field serves two purposes. First, it indicates whether a contact was found in this slot, 0 means not found while a positive number means found. Second, the positive value equals the number of *matching* contacts. So if num = 3 contacts were requested but only 2 were matched, the found fields will equal (2, 2, 0); if 6 were matched they will equal (6, 6, 6). - force **real(3)**: The contact force, in the contact frame. - torque **real(3)**: The contact torque, in the contact frame. - dist **real(1)**: The penetration distance. - pos: **real(3)**: The contact position, in the global frame. - normal: **real(3)**: The contact normal direction, in the global frame. - tangent: **real(3)**: The first tangent direction, in the global frame. In order to complete the full 3x3 contact frame, use tangent2 = cross(normal, tangent). Importantly, the data attribute can contain **multiple sequential data types**, as long as the relative order---as listed above---is maintained. For example, data = "found force dist" will return 5 numbers per contact (the concatenated values of [found, force, dist]), while data = "force found dist" is an error because found must come before force. Missing contacts If less than num contacts satisfy the matching criterion, the entire data slot is set to be identically zero. Because most data types can take 0 as a valid value, only the zero-ness of the normal and tangent unit vectors can be used to unambiguously detect an empty slot. For this reason, the found data type is in place to allow for simple detection of missing contacts. Size of sensordata block Unlike other sensors, the size of the corresponding sensordata block depends on the values of its attributes num and data. The total size of the output of a contact sensor is the product num x size(selected data fields). For example, requesting num = 6 contacts with data = "force dist normal" (3+1+3=7), will result in a sensordata block of 42 numbers (6 consecutive slots x 7 numbers per slot). Direction convention Because contacts create two equal-and-opposite forces between contacting bodies, there is freedom in the choice of which body impinges on which. The sensor's convention is for "geom1/body1/subtree1" and "geom2/body2/subtree2" to determine the direction of the normal. The normal always points from the first to the second. In the case that a direction cannot be determined, as when only a site is used as the matching criterion, or when both subtrees are the same, the normal direction is the same as it is in mjData.contact, where the normal points from the first to the second geom, and the two geoms are sorted according to their order in mjtGeom. Reduction criterion to use. Also see **reduction** above. - **none**: Returns the first num contacts that satisfy the matching criterion, in the order that they appear in mjData.contact. Note that while this is the fastest option, it is also potentially non-deterministic: future changes to collision detection code may cause the identity and order of matching contacts to change. - **mindist**: Returns num contacts with the smallest penetration depth, ascending order. - **maxforce**: Returns num contacts with the largest force norm, descending order. - **netforce**: This reduction criterion returns one new "synthetic" contact, located at the force-weighted centroid of all matched contacts. The frame of the contact is the global frame, so normal and tangent directions lose their natural semantic. The force and torque are computed such that a wrench applied at the computed position will have the same net effect as all the matching contacts combined. Note that this reduction criterion always returns exactly one contact. See CSensor. See CSensor. See CSensor. This attribute is ignored. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Name of the geom to associate the tactile sensor with. Name of the mesh to associate the tactile sensor with. See CSensor. See CSensor. See CSensor. See CSensor. See CSensor. Type of the MuJoCo object to which the sensor is attached. This together with the objname attribute determines the actual object. If unspecified, will be mjOBJ_UNKNOWN. Name of the MuJoCo object to which the sensor is attached. The type of output generated by this sensor. "axis" means a unit-length 3D vector. "quat" means a unit quaternion. These need to be declared because when MuJoCo adds noise, it must respect the vector normalization. "real" means a generic array (or scalar) of real values to which noise can be added independently. The MuJoCo computation stage that must be completed before the user callback mjcb_sensor() is able to evaluate the output of this sensor. Number of scalar outputs of this sensor. See CSensor. See CSensor. See CSensor. Key used for plugin configuration. Value associated with key. Element name. See CName. Plugin identifier, used for implicit plugin instantiation. Instance name, used for explicit plugin instantiation. See CUser. Name of this keyframe. Simulation time, copied into mjData.time when the simulation state is set to this keyframe. Vector of joint positions, copied into mjData.qpos when the simulation state is set to this keyframe. Vector of joint velocities, copied into mjData.qvel when the simulation state is set to this keyframe. Vector of actuator activations, copied into mjData.act when the simulation state is set to this keyframe. Vector of mocap body positions, copied into mjData.mocap_pos when the simulation state is set to this keyframe. Vector of mocap body quaternions, copied into mjData.mocap_quat when the simulation state is set to this keyframe. Vector of controls, copied into mjData.ctrl when the simulation state is set to this keyframe. The name of the model. This name is shown in the title bar of simulate.cc.