MuJoCo 如何统一计算多关节动力学与接触

机械臂的夹爪已经闭合，目标物体却从指间穿过；换过摩擦参数、改过夹持力，抓取仍然不稳。穿模和抓取失败未必源于求解器，更可能涉及模型、接触配置和数值参数三层问题。MuJoCo 的核心做法是用广义坐标描述多关节运动，再把关节驱动与接触力纳入同一次约束求解。

这也是 GitHub 趋势项目 google-deepmind/mujoco 的定位：“Multi-Joint dynamics with Contact. A general purpose physics simulator.” 它关注的并非单独提高某个碰撞算法的速度，而是让关节结构、驱动和接触共享一套动力学计算。

关节树映射出广义坐标

MuJoCo 的机器人模型以 worldbody 为根，body 按父子关系组成树。joint 在父子 body 之间建立自由度，每个 body 则承载局部坐标系、质量与惯量、geom 以及传感器等组件。

关节自由度最终映射到两组核心状态：qpos 保存广义坐标下的构型，qvel 保存对应的广义速度。在只有一个铰链关节的最小模型中，两者各有一个元素；增加关节后，数值会按照 XML 中的 body 树序组织，而不是为每个 body 单独保存一组世界坐标系位姿。

这种表示方式让机械臂的连杆结构直接进入动力学方程。控制程序面对的是关节位置、速度和驱动力，而不是先计算每个刚体的笛卡尔位姿，再额外修补关节之间的连接。

驱动和接触进入同一次求解

如果把 MuJoCo 只当成一个碰撞检测库，就会低估它的设计。MuJoCo 将整个系统的运动方程写成带约束的优化问题：关节驱动与接触力都可以作为约束参与求解，求解器在每个仿真步中联合确定系统加速度和接触力。

因此，机械臂运动与物体接触不是两条彼此独立的计算链。前者产生的约束不会在接触计算结束后再单独覆盖，后者也不需要作为外力补丁附加到已经完成的机器人运动上。抓取失败时，应同时检查驱动是否合理、接触是否成立，以及两者能否在同一组约束下得到一致解。

接触也是优化问题的一部分

早期机器人与生物力学引擎通常在广义坐标中采用递归算法，但要么省略接触，要么依赖弹簧—阻尼式接触，需要很小的时间步长。游戏引擎往往使用优化方法计算接触力，却常采用自由度过多的笛卡尔表示，再通过数值方法施加关节约束，复杂运动学结构由此可能出现精度或稳定性问题。

MuJoCo 采用“广义坐标仿真加优化接触动力学”的组合路线。对抓取任务，这意味着关节运动和接触约束处在同一动力学系统中；对足式机器人而言，多个持续接触点也不会脱离主体动力学单独存在。 这种设计减少了动力学与接触分开求解造成的结构不一致，但不能自动消除错误几何、过大的时间步长或不合理参数造成的穿模。

模型错误和求解参数要分开查

下面的最小 XML 包含一个带铰链和球形 geom 的 body，并加入执行器与关节位置传感器，用于演示模型加载、控制和状态读取。

<mujoco model="simple_body">
  <worldbody>
    <body name="child" pos="0 1 0">
      <joint name="hinge" type="hinge" axis="0 0 1"/>
      <geom name="ball" type="sphere" size="0.1"/>
    </body>
  </worldbody>

  <actuator>
    <motor joint="hinge"/>
  </actuator>

  <sensor>
    <jointpos joint="hinge"/>
  </sensor>
</mujoco>

从安装后的首个 demo 到控制闭环，基本流程是：加载模型，向 data.ctrl 写入驱动，调用 mj_step 推进仿真，再读取 data.qpos、data.qvel、data.sensordata，并通过 data.ncon、data.contact 获取状态与接触结果。

import mujoco

def rollout(control_sequence):
    model = mujoco.MjModel.from_xml_path("simple_body.xml")
    data = mujoco.MjData(model)
    mujoco.mj_resetData(model, data)

    for control in control_sequence:
        data.ctrl[0] = control
        mujoco.mj_step(model, data)

    return data

导入已有机器人模型时，先核对 joint 轴、body 质量以及 geom 映射，不要先靠调整求解器掩盖模型问题。 穿模、关节漂移和夹持不稳可以按下面的顺序排查：

1. 隔离接触问题：暂时排除异常接触对，观察驱动后的 qpos、qvel 是否符合预期。没有接触时仍然漂移，优先检查树结构、关节轴、质量与驱动。
2. 核对接触配置：检查相关 geom 的形状、尺寸、位置和碰撞过滤，再查看接触是否实际生成、摩擦属性是否合理。
3. 检查时间步长：模型正确后，再减小 timestep，观察穿模深度、接触数量和夹持稳定性是否随之变化。较小的时间步长不能修复错误的几何关系。
4. 最后调整求解器：比较 solver 的迭代预算与收敛容差。求解参数可能改善约束满足程度，但无法修正错误的关节轴、质量分布或接触映射。

项目场景决定是否采用 MuJoCo

强化学习、机械臂操作和足式机器人适合优先用 MuJoCo 验证，因为这些任务同时依赖关节动力学与高频接触；生物力学和图形动画也是它明确面向的研究领域。

与 PyBullet 等方案相比，选择不应只看单次 benchmark。PyBullet 已有 GPU 加速、URDF 支持和传感器接口，如果现有流程依赖这些能力，迁移成本和开发生态同样重要；相反，当问题核心是多关节结构与接触的统一建模时，MuJoCo 的路线更直接。 如果任务更接近通用刚体场景，或项目已有游戏引擎工作流，则应把动力学路线、接触需求和既有工具链放在一起比较，而不必默认更换引擎。

是否采用或更换引擎，不能只凭单次截图决定：先固定初态并用同一控制序列重复仿真，再决定是继续沿“模型—接触—timestep—solver”的顺序调参，还是因既有 URDF、传感器、GPU 或工具链要求转向 PyBullet 等方案。