MuJoCo 入门教程（一）（上）+https://developer.aliyun.com/article/1585311
2.3.2 关节 Joint
关节是在主体（Body）内部定义的。它们在主体（Body）和其父主体（Body）之间创建运动自由度（DOF）。在没有关节的情况下，主体（Body）与其父主体（Body）是焊接在一起的。这与使用过度完整的笛卡尔坐标的游戏引擎相反，在游戏引擎中，关节会移除而不是增加自由度。有四种类型的关节：球形关节（ball）、滑动关节（slide）、铰链关节（hinge）和 "自由关节"（free joint），"自由关节 "可创建浮动体。一个主体（Body）可以有多个关节。这样就可以自动创建复合关节，而无需定义假体（dummy bodies）。球关节和自由关节的方向分量用单位四元数表示，MuJoCo 中的所有计算都遵循四元数的属性。
2.3.3 关节参考 Joint reference
参考姿态是存储在 mjModel.qpos0 中的关节位置向量。它与模型初始配置时的关节数值相对应。在我们前面的例子中，肘部是以 90° 角弯曲配置创建的。但 MuJoCo 并不知道什么是肘部，因此默认情况下会将此关节配置视为数值为 0。我们可以覆盖默认行为，使用关节的 ref 属性指定初始配置对应于 90°。所有关节的参考值都会汇总到向量 mjModel.qpos0 中。每当仿真重置时，关节配置 mjData.qpos 都会设置为 mjModel.qpos0。运行时，关节位置矢量相对于参考姿势进行解释。具体来说，关节应用的空间变换量为 mjData.qpos - mjModel.qpos0。这种变换是对存储在 mjModel 主体元素中的父子平移和旋转偏移的补充。ref 属性只适用于标量关节（滑动和铰链）。对于球形关节，mjModel.qpos0 中保存的四元数始终为 (1,0,0,0)，对应于空旋转。对于自由关节，浮动体的全局 3D 位置和四元数都保存在 mjModel.qpos0 中。
2.3.4 弹簧参考 Spring reference
这是所有关节和肌腱弹簧达到静止长度的姿势。当关节配置偏离弹簧参考姿势时会产生弹簧力，弹簧力与偏离量呈线性关系。弹簧参考姿势保存在 mjModel.qpos_spring 中。对于滑动和铰链关节，弹簧参考由属性 springref 指定。对于球关节和自由关节，弹簧基准与初始模型配置相对应。
2.3.5 自由度 DOF
自由度与关节密切相关，但并非一一对应，因为球关节和自由度关节具有多个 DOF。将关节视为指定位置信息，将自由度视为指定速度和力信息。更正式地说，关节位置是系统配置流形上的坐标，而关节速度则是当前位置处流形切线空间上的坐标。自由度具有与速度相关的特性，如摩擦损耗、阻尼、电枢惯性。作用在系统上的所有广义力都用 DOF 空间表示。相反，关节具有与位置相关的特性，如极限和弹簧刚度。用户不能直接指定自由度。相反，它们是由编译器根据关节创建的。
2.3.6 几何体 Geom
Geoms 是刚性连接到主体（Body）的三维形状。可以将多个 Geom 附加到同一个主体（Body）上。鉴于 MuJoCo 只支持凸形几何体之间的碰撞，而创建非凸形物体的唯一方法就是将它们表示为凸形几何体的结合体，因此这一点特别有用。除了碰撞检测和随后的接触力计算外，几何体还用于渲染，以及在省略体质量和惯性时自动推断体质量和惯性。MuJoCo 支持几种原始几何形状：平面、球面、囊面、椭圆面、圆柱体、盒体。一个几何体也可以是一个网格或一个高度场；这可以通过引用相应的资产来实现。几何体具有许多影响仿真和可视化的材料属性。
2.3.7 站点 Site
站点本质上是轻型几何体。它们代表了主体（Body）坐标系中感兴趣的位置。站点不参与碰撞检测或惯性属性的自动计算，但可用于指定传感器、肌腱路由和滑块-曲柄端点等其他对象的空间属性。
2.3.8 摄像机 Camera
一个模型中可以定义多个摄像机。默认情况下总是有一个摄像机，用户可以在交互式可视化界面中用鼠标自由移动。不过，定义额外的摄像机也很方便，这些摄像机可以固定在世界中，也可以附着在某个物体上并随其移动。除了摄像机的位置和方向外，用户还可以调整垂直视场和瞳孔间距以进行立体渲染，以及创建立体虚拟环境所需的斜投影。在使用不完善的光学系统对真实摄像机进行建模时，可以为水平和垂直方向指定不同的焦距，并指定一个非居中的主点。
2.3.9 灯光 Light
灯光可以固定在世界体上，也可以连接到运动体上。可视化器可访问 OpenGL（固定函数）中的完整照明模型，包括环境、漫反射和镜面反射组件、衰减和截止、位置和方向照明以及雾。灯光，或者说被灯光照亮的物体，还可以投射阴影。不过，与材质反射类似，每个投射阴影的灯光都会增加一次渲染，因此应谨慎使用这一功能。详细记录照明模型超出了本章的范围；请参阅 OpenGL 文档。请注意，除了用户在运动树中定义的灯光外，还有一个默认的头灯会随着摄像机移动。其属性可通过 mjVisual 选项进行调整。
2.4 独立
这里我们描述的是不属于单个主体（Body）的模型元素，因此是在运动学树之外描述的。
2.4.1 肌腱 Tendon
筋是标量长度元素，可用于驱动、施加限制和相等约束，或产生弹簧阻尼和摩擦损耗。有两种类型的筋腱：固定筋腱和空间筋腱。固定筋是（标量）关节位置的线性组合。它们可用于模拟机械耦合。空间筋的定义是通过一系列指定位置（或通过点）或环绕指定几何体的最短路径。仅支持球体和圆柱体作为包裹几何体，圆柱体在包裹时被视为无限长。为避免肌腱从包裹几何体的一侧突然跳到另一侧，用户还可以指定首选的一侧。如果肌腱路径中存在多个缠绕几何体，则必须用站点将它们分开，以避免使用迭代求解器。空间筋也可以使用滑轮分割成多个分支。
2.4.2 执行器 Actuator
MuJoCo 提供了一个灵活的执行器模型，它有三个可独立指定的组件。它们共同决定了执行器的工作方式。通过以协调的方式指定这些组件，可以获得常见的致动器类型。这三个组件分别是传动、激活动力学和力的产生。传动装置规定了执行器与系统其他部分的连接方式；可用的类型包括关节、腱和滑块-曲柄。激活动力学可用于模拟气动或液压缸以及生物肌肉的内部激活状态；使用此类致动器可使整个系统的动力学达到三阶。力的产生机制决定了作为致动器输入的标量控制信号如何映射为标量力，而标量力又如何通过从传动装置推断出的力矩臂映射为广义力。
2.4.3 传感器 Sensor
MuJoCo 可以生成仿真传感器数据，并将其保存在全局数组 mjData.sensordata 中。这些数据不会用于任何内部计算，而是提供给用户用于自定义计算或数据分析。可用的传感器类型包括触摸传感器、惯性测量单元（IMU）、力矩传感器、关节和肌腱位置及速度传感器、致动器位置、速度和力传感器、运动捕捉标记位置和四元数以及磁力计。其中有些需要额外的计算，有些则是从 mjData 的相应字段复制而来。还有一个用户传感器，允许用户代码在传感器数据数组中插入任何其他感兴趣的数量。MuJoCo 还具有离屏渲染功能，可以直接仿真彩色和深度摄像头传感器。这并不包括在标准传感器模型中，而是必须通过编程完成，如代码示例 simulate.cc 中所示。
2.4.4 等效约束 Equality
在运动树结构和其中定义的关节/DOFs 已施加的约束之外，等效约束还可以施加额外的约束。它们可用于创建环形关节或一般的机械耦合模型。执行这些约束的内力与所有其他约束力一起计算。可用的相等约束类型包括：在一个点上连接两个物体（在运动树外创建一个球形关节）；将两个物体焊接在一起；固定一个关节或肌腱的位置；通过三次多项式将两个关节或两条肌腱的位置耦合在一起；将挠性体（即可变形网格）的边缘约束为初始长度。
2.4.5 挠性 Flex
柔性网格是在 MuJoCo 3.0 中添加的。它们表示可变形网格，可以是一维、二维或三维网格（因此其元素可以是胶囊、三角形或四面体）。与固定连接在单个物体上的静态形状的几何体不同，柔性元素是可变形的：它们是通过连接多个物体构建的，因此物体的位置和方向决定了运行时柔性元素的形状。这些可变形元素支持碰撞和接触力，还能产生被动力和约束力，从而保持可变形实体的形状。可自动从文件中加载网格，构建与网格顶点相对应的体，构建与网格面（或线或四面体，取决于维度）相对应的柔性元素，并获得相应的可变形网格。
2.4.6 接触对 Contact pair
MuJoCo 中的接触生成是一个复杂的过程。检查是否有接触的几何体对（Geom pairs）有两个来源：自动邻近性测试（automated proximity tests）和其他统称为 "动态（dynamic） "的过滤器，以及模型中提供的明确几何体对（Geom pairs）列表。后者是一种单独的模型元素。由于接触涉及两个几何体的组合，明确的规范允许用户以动态机制无法实现的方式定义接触参数。这对于微调接触模型也很有用，特别是添加被激进过滤方案删除的接触对。现在，接触机制已扩展到柔性元素，可以在两个以上的物体之间创建接触互动。不过，这种碰撞是自动发生的，无法使用接触对进行微调。
2.4.7 接触排除
这与接触配对相反：它指定了应从候选接触配对生成中排除的体对（而不是几何体（geoms））。它适用于禁用几何体之间的接触，因为这些几何体会导致不理想的永久接触。请注意，MuJoCo 有其他机制来处理这种情况（特别是如果几何体属于同一个体或属于父体和子体，它们就不会发生碰撞），但有时这些自动机制并不足够，明确的排除就变得很有必要。
2.4.8 自定义数值
在 MuJoCo 仿真中输入自定义数字有三种方法。首先，可在 XML 中定义全局数字字段。它们有一个名称和一个实数值数组。其次，可以通过特定元素的自定义数组来扩展某些模型元素的定义。具体方法是在 XML 元素大小中设置 nuser_XXX 属性。第三，数组 mjData.userdata 不用于任何 MuJoCo 计算。用户可以在这里存储自定义计算的结果；请记住，所有随时间变化的内容都应存储在 mjData 中，而不是 mjModel 中。
2.4.9 自定义文本
自定义文本字段可以保存在模型中。它们可用于自定义计算 —— 指定关键字命令或提供其他文本信息。但不要将它们用于注释；在编译后的模型中保存注释没有任何好处。XML 有自己的注释机制（被 MuJoCo 的解析器和编译器忽略），这更合适。
2.4.10 自定义元组
自定义元组是 MuJoCo 模型元素的列表，可能包括其他元组。它们不被仿真器使用，但可用于指定用户代码所需的元素组。例如，可以使用图元来定义用于自定义触点处理的体对。
2.4.11 关键帧
关键帧是仿真状态变量的快照。它包含关节位置矢量、关节速度矢量、执行器激活（如有）矢量和仿真时间矢量。模型可以包含一个关键帧库。这些关键帧可用于将系统状态重置为某个感兴趣的点。需要注意的是，关键帧并非用于在模型中存储轨迹数据，而应使用外部文件。
三、说明
读者很可能有使用其他物理仿真器和相关约定的经验，以及与 MuJoCo 不一致的一般编程实践。这有可能造成混淆。本节的目的是预先澄清最有可能引起混淆的方面；它介于常见问题解答和选定话题的教程之间。我们需要参考后面文档中涉及的材料，但下面的文字尽可能是自成一体的介绍性文字。
3.1 发散
当状态元素迅速趋向无穷大时，仿真就会出现发散。在 MuJoCo 中，这通常表现为 mjWARN_BADQACC 警告。发散是所有物理仿真的通病，并不一定表明模型有问题或仿真器有错误，而是提示我们，对于给定的积分器选择来说，时间步长太大了。在物理仿真中，速度（大时间步长）和稳定性（小时间步长）之间总是存在矛盾。一个对速度进行了良好调整的模型，其最大可能的时间步长是不发散的，这通常意味着它可以在极端条件下发散。从这个意义上说，罕见的发散情况实际上可以说明模型调试良好。在任何情况下，都可以通过减少时间步长和/或改用更稳定的积分器来防止发散。如果这种方法失败，罪魁祸首就不同了。例如，在物体初始化为穿透的模型中，巨大的排斥力可能会将它们推开并导致发散。
3.2 未指定单位
MuJoCo 没有指定基本物理单位。用户可以根据自己的选择来解释单位系统，只要它们是一致的即可。为了理解这一点，请看一个例子：重量为 1 千克、使用 1 牛顿推进器的 1 米宇宙飞船的动力与重量为 1 克、使用 1 达因推进器的 1 厘米宇宙飞船的动力是相同的。这是因为 MKS 和 CGS 都是一致的单位系统。这一特性允许用户随意缩放模型，这在仿真非常小或非常大的东西时非常有用，可以提高仿真的数值特性。
尽管如此，我们还是鼓励用户使用 MKS，因为 MuJoCo 在两个地方使用了类似 MKS 的默认值：
- 重力的默认值是（0, 0, -9.81），相当于 MKS 中的地球表面重力。请注意，这并没有真正指定 MKS 单位系统，因为我们可能会在恩克拉多斯使用 CGS。
- 几何体密度（用于推断物体质量和惯性）的默认值是 1000，相当于 MKS 中水的密度。
一旦选择了一致的基本单位（长度、质量、时间）系统，所有衍生单位都将与这一系统相对应，就像在维度分析中一样。例如，如果我们的模型被解释为 MKS，那么力和扭矩就分别以牛顿和牛顿-米为单位。
角度： 虽然在 MJCF 中可以使用度来指定角度（事实上度也是默认值），但 mjModel 和 mjData 中的所有角度量都以弧度表示。因此，举例来说，如果我们使用的是 MKS，陀螺仪报告的角速度将以弧度/秒为单位，而铰链接头的刚度将以牛米/弧度为单位。
3.3 意外碰撞
默认情况下，MuJoCo 会排除属于直接父子关系的体对的几何体之间的碰撞。例如，请看上面 "示例 "部分中的手臂模型：由于前臂是上臂的直接子体，因此即使胶囊 geoms 相互穿透，"肘部 "也不会发生碰撞。
但是，如果父体是一个静态体，即世界体，或者是一个相对于世界体没有任何自由度的体，那么这种排除就不适用。碰撞检测部分记录的这一行为可以防止物体从地板上掉落或穿过墙壁。然而，这种行为往往会导致以下情况：
用户注释掉浮动基体模型的根关节，也许是为了防止它坠落；现在基体被视为静态，出现了之前没有的新碰撞，用户感到困惑。有两种简单的方法可以避免这个问题：
- 不要移除根关节。也许只需禁用重力，并在可能的情况下添加一些流体粘度，就能防止模型过度移动。
- 通过设置相关的 contype 和 conaffinity 属性，或者使用接触排除指令，使用碰撞过滤明确禁用不需要的碰撞。
3.4 不面向对象
面向对象编程是一个非常有用的抽象概念，它建立在更基本（更接近硬件）的数据结构与对其进行操作的函数概念之上。对象是数据结构和函数的集合，这些数据结构和函数与一个语义实体相对应，因此它们之间的依赖性比与应用程序其他部分的依赖性更强。我们之所以不在这里使用，是因为从依赖结构来看，自然实体就是整个物理仿真器。与对象不同，我们有少量数据结构和大量对其进行操作的函数。
我们仍然使用一种分组方式，但与面向对象的方法不同。我们将模型（mjModel）与数据（mjData）分开。它们都是数据结构。模型包含描述建模物理系统恒定属性所需的一切，而数据则包含时变状态和内部计算的可重用中间结果。所有顶级函数的参数都是指向 mjModel 和 mjData 的指针。通过这种方式，我们避免了全局变量对工作区的污染和对多线程的干扰，但我们这样做的方式与面向对象编程实现相同效果的方式不同。
3.5 柔性和滑动
正如我们将在 "计算 "一章中详细解释的那样，MuJoCo 基于接触物理学和其他约束条件的数学模型。这个模型本质上是柔性的，即对约束条件施加更大的推力总会导致更大的加速度，因此可以唯一定义反向动力学。这是可取的，因为它能产生一个凸优化问题，并能进行依赖于逆动力学的分析，此外，我们在实践中需要模拟的大多数接触都具有一定的软性。然而，一旦我们允许软约束，我们实际上就创造了一种新的动力学类型，即变形动力学，现在我们必须明确这些动力学的行为方式。这就需要对接触和其他约束条件进行详细的参数化，其中涉及可根据约束条件设置的属性 solref 和 solimp，稍后将对其进行描述。
这种软模型经常令人困惑的一点是，无法避免逐渐的接触滑移。同样，摩擦接头也会在重力作用下逐渐屈服。这并不是因为求解器无法防止滑移（达到摩擦锥或摩擦损失极限），而是因为它一开始就没有试图防止滑移。回想一下，在给定约束条件下，较大的力必然导致较大的加速度。如果要完全抑制滑移，就必须违反这一关键特性。因此，如果你在仿真中看到逐渐滑移，直观的解释可能是摩擦力不足，但在 MuJoCo 中很少出现这种情况。相反，需要调整 solref 和 solimp 参数向量，以减少这种影响。增加约束阻抗（solimp 的前两个元素）以及全局 mjModel.opt.impratio 设置尤其有效。这种调整通常需要更小的时间步长来保持仿真稳定，因为它们会使非线性动力学更难进行数值积分。牛顿求解器也可以减少滑动，因为牛顿求解器一般更为精确。
在需要完全抑制滑动的情况下，可在主求解器之后运行第二个无滑动求解器。它通过忽略约束软度来更新摩擦维度的接触力。然而，当使用该选项时，MuJoCo 不再求解其设计用于求解的凸优化问题，仿真的鲁棒性可能会降低。因此，建议使用牛顿求解器、椭圆摩擦锥和较大的摩擦系数值来减少滑移。
3.6 类型、名称和 ID
如前所述，MuJoCo 支持大量模型元素。每种元素类型在 mjModel 中都有相应的部分列出其各种属性。例如，关节限制数据在数组
mjtNum* jnt_range; // joint limits (njnt x 2)
mjModel 中还给出了每个数组（本例中为 njnt）的大小。第一个关节点的限制首先包括在内，然后是第二个关节点的限制等。这种排序反映了 MuJoCo 中的所有矩阵都是行主格式。
可用的元素类型在 mjmodel.h 的枚举类型 mjtObj 中定义。这些枚举大多在内部使用。一个例外是 MuJoCo API 中的函数 mj_name2id 和 mj_id2name，它们将元素名称映射为整数 id，反之亦然。这些函数将元素类型作为输入。
在 XML 中命名模型元素是可选的。同一类型的两个元素（如两个关节）不能有相同的名称。只有在模型中其他地方需要引用给定元素时，才需要命名；XML 中的引用只能通过名称来完成。模型编译完成后，为方便用户使用，名称仍会存储在 mjModel 中，但不会对仿真产生进一步影响。名称对于查找相应的整数 id 以及渲染都很有用：例如，如果启用关节标签，每个关节旁边都会显示一个字符串（名称未定义的元素会被标记为 "关节 N"，其中 N 是 id）。
元素的整数 id 对 MuJoCo 数据数组的索引至关重要。按照 C 语言的习惯，id 以 0 为基础。要打印名为 "肘 "的关节的范围，请执行以下操作
int jntid = mj_name2id(m, mjOBJ_JOINT, "elbow"); if( jntid>=0 ) printf("(%f, %f)\n", m->jnt_range[2*jntid], m->jnt_range[2*jntid+1]);
如果未找到名称，函数将返回-1，这就是为什么要始终检查 id>=0 的原因。
3.7 主体、几何体、站点
Bodies、geoms 和 sites 是 MuJoCo 的元素，与物理世界中的刚体大致对应。那么为什么要把它们分开呢？这里解释了语义和计算方面的原因。
首先是相似性。Bodies、geoms 和 sites 都有空间坐标系（尽管物体也有第二个坐标系，它以物体的质量中心为中心，并与惯性主轴对齐）。这些坐标系的位置和方向是在每个时间步长通过前向运动学从 mjData.qpos 计算得出的。正向运动学的结果可以在 mjData 中以 xpos、xquat 和 xmat 的形式表示体，以 geom_xpos 和 geom_xmat 的形式表示geom，以 site_xpos 和 site_xmat 的形式表示站点。
现在是不同之处。主体（Body）用于构建运动树，是其他元素（包括 geoms 和 sites）的容器。主体（Body）具有空间坐标系和惯性属性，但没有与外观或碰撞几何相关的属性。这是因为这些属性并不影响物理特性（当然接触除外，但这些属性会单独处理）。如果你在机器人学教科书中看到过运动树的图解，那么这些物体通常被画成无定形的形状--以表明它们的实际形状与物理无关。
Geoms（几何基元的简称）用于指定外观和碰撞几何形状。每个几何体都属于一个物体，并与该物体刚性连接。同一个物体可以连接多个几何体。考虑到 MuJoCo 的碰撞检测器假定所有几何体都是凸面（如果网格不是凸面，它就会在内部用凸面体替换网格），这一点尤其有用。因此，如果要对一个非凸形状进行建模，就必须将其分解为多个凸几何体，并将所有几何体连接到同一个体上。在 XML 模型中，几何体也可以有质量和惯性（或者说用于计算质量和惯性的材料密度），但在模型编译器中，这只用于计算主体（Body）的质量和惯性。在实际仿真的 mjModel 中，geoms 没有惯性属性。
场地是轻型场地。它们具有相同的外观属性，但不能参与碰撞，也不能用于推断物体质量。另一方面，站点可以做一些几何体做不到的事情：它们可以指定触摸传感器的体积、IMU 传感器的附件、空间筋腱的路线、滑块-曲柄执行器的端点。这些都是空间量，但它们并不对应于具有质量或与其他实体发生碰撞的实体，这就是创建站点元素的原因。站点还可以用来指定用户感兴趣的点（或者说坐标系）。
下面的示例说明了可以将多个站点和地理坐标连接到同一个体上：在本例中，两个站点和两个几何体坐标连接到一个主体（Body）上。
<mujoco> <worldbody> <body pos="0 0 0"> <geom type="sphere" size=".1" rgba=".9 .9 .1 1"/> <geom type="capsule" pos="0 0 .1" size=".05 .1" rgba=".9 .9 .1 1"/> <site type="box" pos="0 -.1 .3" size=".02 .02 .02" rgba=".9 .1 .9 1"/> <site type="ellipsoid" pos="0 .1 .3" size=".02 .03 .04" rgba=".9 .1 .9 1"/> </body> </worldbody> </mujoco>
该模型由 OpenGL 可视化器渲染为
请注意红色方框。这是身体惯性属性的等效惯性盒渲染，由 MuJoCo 内部生成。方框位于几何体（geoms）上方，但不在站点（sites）上方。这是因为只有几何体被用来（自动）推断物体的惯性属性。如果我们碰巧知道后者，当然可以直接指定。但通常更方便的做法是，让模型编译器使用均匀密度假设（可在 XML 中指定几何体密度；默认值为水的密度），从附着在几何体上的几何体推断出这些体的属性。
3.8 关节坐标
MuJoCo 与游戏引擎（如 ODE、Bullet、Havoc、PhysX）的主要区别之一是，MuJoCo 采用广义或关节坐标，而游戏引擎采用笛卡尔坐标，尽管 Bullet 现在支持广义坐标。这两种方法的区别可归纳如下：
关节坐标：
- 最适合机器人等精细运动结构；
- 关节增加了默认情况下焊接在一起的体之间的自由度；
- 关节约束隐含在表示中，不会被违反；
- 仿真体的位置和方向是通过正向运动学从广义坐标中获得的，不能直接操作（根体除外）。
笛卡尔坐标：
- 最适合许多相互弹跳的体，如分子动力学和箱体堆叠；
- 关节消除了默认情况下自由浮动体之间的自由度；
- 关节约束以数值方式执行，可以违反；
- 仿真体的位置和方向是显式表示的，可以直接操作，但这样会进一步违反关节约束。
如果模型中的自由浮动体也包含运动学树，那么在处理这些自由浮动体时，关节坐标可能会特别 容易混淆。下文将对此进行说明。
3.9 浮动物体
在使用关节坐标时，不能简单地将任意体的位置和方向设置为您想要的任何位置和方向。要达到这种效果，必须实现某种形式的逆运动学，计算出一组关节坐标（不一定是唯一的），正向运动学会根据这组关节坐标将物体放置到你想要的位置。
浮动体的情况则不同，即通过自由关节与世界相连的物体。这类物体的位置和方向以及线速度和角速度都在 mjData.qpos 和 mjData.qvel 中明确表示，因此可以直接操作。一般的方法是在 qpos 和 qvel 中找到体数据所在的地址。当然，qpos 和 qvel 代表的是关节而不是身体，因此需要相应的关节地址。假设在 XML 中，主体被命名为 "myfloatingbody"。必要的地址可以通过以下方式获得
int bodyid = mj_name2id(m, mjOBJ_BODY, "myfloatingbody"); int qposadr = -1, qveladr = -1; // make sure we have a floating body: it has a single free joint if( bodyid>=0 && m->body_jntnum[bodyid]==1 && m->jnt_type[m->body_jntadr[bodyid]]==mjJNT_FREE ) { // extract the addresses from the joint specification qposadr = m->jnt_qposadr[m->body_jntadr[bodyid]]; qveladr = m->jnt_dofadr[m->body_jntadr[bodyid]]; }
如果一切顺利（即 "myfloatingbody "确实是一个浮动体），那么 qposadr 和 qveladr 就是浮动体/关节数据所在的 qpos 和 qvel 地址。位置数据是 7 个数字（三维位置和单位四元数），速度数据是 6 个数字（三维线速度和三维角速度）。现在可以将这些数字设置为所需的身体姿态和速度。
自由关节的语义如下。自由关节的线性姿态和线性速度都在全局坐标系中。自由关节的方向（四元数）也在全局坐标系中。然而，自由关节的旋转速度是在局部车身坐标系中。这与其说是一个设计决定，不如说是对四元数拓扑结构的正确使用。角速度存在于四元数切线空间中，而四元数切线空间是为某个方向局部定义的，因此坐标系局部角速度是一种自然的参数化。加速度与相应的速度定义在同一空间。
