---
title: "Isaac Sim、Isaac Lab 与 MuJoCo：机器人仿真和强化学习完整使用教程"
lang: zh-CN
---

[课程首页](https://github.com/zengxiong111/Foundation_of_Embodied_AI/blob/main/README.zh-CN.md) · [English](Isaac_MuJoCo_RL_Complete_Guide_EN.md) · [运动控制 RL 教程](Embodied_Motion_Control_RL_Tutorial_ZH.md)

| 项目 | 说明 |
|---|---|
| 定位 | 工程工具与训练基础设施（How to Use）；不重复 PPO、SAC 或运动控制原理 |
| 版本边界 | Isaac Lab 2.3.2 / Isaac Sim 5.1; Isaac Lab 3.0 Early Access / Isaac Sim 6.1; MuJoCo/MJX/MJWarp 按具体任务选版本 |
| 核验日期 | 2026-10-19 |
| 许可 | CC BY 4.0 · Xiong Zeng and contributors |


> **课程分工：** 本讲义回答“如何构建可靠、高效、可复现的仿真训练平台”；运动控制 RL 讲义回答“如何学习运动、跟踪和恢复等控制能力”。


**章节知识地图：** 机器人模型 → 仿真场景 → 环境接口 → 并行训练 → 部署核验。

## 1. 平台角色与研究任务选择

### 1.1 角色分工

- **Isaac Sim：** 基于 NVIDIA 仿真技术的机器人应用平台，擅长场景编辑、USD 资产、PhysX 动力学、RTX 渲染、相机及 ROS 2 集成。它解决的是“场景和机器人怎样在仿真中运行与感知”的问题。
- **Isaac Lab：** 建立在仿真后端之上的机器人学习框架，提供任务接口、并行环境、观测、动作、奖励、终止、重置、域随机化以及与 RL 框架的连接。它解决的是“怎样系统地训练和评估策略”的问题。
- **MuJoCo：** 动力学与接触仿真引擎，适合研究刚体动力学、约束、执行器、控制与模型诊断。经典 MuJoCo 通常在 CPU 上运行；MJX、MuJoCo Warp（MJWarp）则面向批量和 GPU 仿真。

**重要更新：** Isaac Lab 3.0 Early Access 已引入多物理后端，包含基于 Newton／MuJoCo Warp 的运行路线。因此，不应再把“Isaac Lab = 只能用 PhysX”或“MuJoCo = 只能在 CPU 上使用”当成绝对结论。新架构与旧版 API 的兼容性仍需逐项确认。[1–4]

| 维度 | Isaac Sim | Isaac Lab | MuJoCo 及其 GPU 生态 |
|---|---|---|---|
| 核心定位 | 场景、传感器、数字孪生 | 机器人学习与批量环境 | 动力学、接触、控制及批量仿真 |
| 常见资产 | USD、可导入 URDF | 使用后端可接受的资产 | MJCF，可导入 URDF |
| 可视化 | RTX 渲染能力强 | 沿用所选渲染后端 | 轻量查看器；GPU 批量渲染能力依实现而异 |
| RL 集成 | 需要任务／训练层 | RSL-RL、RL-Games、skrl 等 | MuJoCo Playground、Gymnasium 或自定义训练栈 |
| 最适合入门 | 场景和传感器 | 并行 RL | 动力学和控制 |
| 易踩的坑 | 驱动、显存、光线追踪要求 | 版本/API、奖励与重置 | 执行器、接触参数、CPU/GPU 差异 |

### 1.2 研究任务怎么选？

| 研究目标 | 优先选择 | 选择理由 |
|---|---|---|
| 单机器人动力学、PD/MPC、逆动力学 | MuJoCo | 状态和力学机制易于检查，单步调试方便 |
| 使用 replay buffer 的 SAC | 支持 SAC 的 MuJoCo RL 栈或对应 Isaac Lab 集成 | 必须确认训练库确实实现 SAC 与向量环境适配 |
| 头部＋腕部 RGB-D、遮挡、光照变化 | Isaac Sim / Isaac Lab | 真实感渲染和相机系统较完整 |
| 高速状态策略、接触任务的批量仿真 | Isaac Lab 的适合后端，或 MJX/MJWarp | 取决于任务、GPU、接触复杂度和数据搬运 |
| 真机上线前复核 | 两个引擎交叉验证 | 减少对单一接触模型和执行器假设的依赖 |

**核心原则：** 首先根据任务选择物理模型与观测类型，其次才根据峰值仿真帧率决定工具。视觉、接触和真机一致性可能比原始 FPS 更重要。


## 2. 版本、硬件与工具入门

### 2.1 两条版本路线

**稳定复现路线：Isaac Lab 2.3.2 + Isaac Sim 5.1。** 适合复现基于 2.x 开发的现有论文、RSL-RL 和 PhysX 操作任务；旧项目最好锁定 Git 标签、Python、PyTorch、扩展及驱动版本。

**新框架路线：Isaac Lab 3.0 Early Access + Isaac Sim 6.1（需要完整 Isaac Sim 功能时）。** 3.0 引入无 Kit 的部分后端工作流和多后端抽象，但存在破坏性变化；截至本文日期，属于 Early Access，不能认为所有旧任务与插件直接兼容。尤其注意四元数约定由 2.x 常见的 **wxyz** 转向 3.0 的 **xyzw**，并且部分数据接口已变化。[1][2]

**安装决策步骤：** ① 确定复现目标与所需功能；② 根据官方兼容表选择版本；③ 将 Isaac 与 MuJoCo 放在独立环境；④ 先运行官方最小场景；⑤ 验证物理步进、资产导入和 GPU 使用；⑥ 再安装训练框架。不要先混装一堆深度学习依赖再查错。

### 2.2 计算资源如何分配

- **RTX 4090（24 GB）：** 适合 Isaac Lab 物理训练和受限分辨率的视觉任务；复杂场景仍需控制显存、环境数和相机像素。
- **RTX 3090（24 GB）：** 可用于兼容的部分实验和 MuJoCo GPU 训练，但 Isaac Sim 5.1 官方最低性能档列为 RTX 4080；在 3090 上的工作流应视为需要自行验证的配置。
- **A100／A800：** 适合神经网络训练与部分不需要 RTX 渲染的计算；**A100 不属于完整 Isaac Sim 5.1 官方支持的 RTX GPU**，不要把高算力误判为 Isaac Sim 渲染兼容。
- **CPU：** 经典 MuJoCo 的小批量调试、MPC 或动力学检查往往很合适；当任务大量并行时再评估 MJX/MJWarp。

官方的 Isaac Sim 5.1 系统要求给出了 Ubuntu、内存、存储、RTX GPU 和驱动的具体兼容条件；依赖和驱动不应根据“最新”二字盲目升级。[5]

### 2.3 环境验收，而不只是“能够启动”

| 验收项目 | 通过标准 |
|---|---|
| 基础场景 | 地面、重力、机器人正常出现，不发生非预期穿透 |
| 关节运动 | 逐关节测试方向、限位、零位与速度 |
| 机器人状态 | 位姿、速度、力矩与真实模型定义一致 |
| 渲染／相机 | 图像方向、深度类型、时间戳和分辨率正确 |
| 物理稳定性 | 静止机器人无持续震荡，物体自由落体合理 |
| 训练接入 | 重置、观测、动作、奖励与终止流程能够闭环 |
| 复现记录 | 记录软件版本、模型文件哈希、GPU/驱动与随机种子 |

### 2.4 MuJoCo 的入门顺序

1. **理解模型层：** 将机器人视为由 body、joint、geom、actuator、sensor 及约束组成。MJCF 的“外观”与“物理碰撞”可以分开定义。
2. **查看模型：** 在查看器中逐一检查关节转轴、零位、碰撞几何、惯性参数和末端参考点。
3. **进行自由运动实验：** 让单关节摆杆或机械臂受重力运动，比较物理直觉与仿真行为。
4. **进行伺服实验：** 分别观察位置、速度和转矩驱动的差异，明确输入是目标值、力矩还是执行器内部信号。
5. **加入接触：** 放入桌面和小物体，比较自由落体、平面滑动、夹持和释放行为。
6. **进行 RL 准备：** 明确环境状态、动作、重置与随机化接口后再连接训练器。

**适合的首个完整机器人：** Franka Panda。模型公开、自由度适中，兼具末端控制和抓取任务，可使用 MuJoCo Menagerie 的维护版本作为起点。[6]

### 2.5 Isaac Sim / Isaac Lab 的入门顺序

1. **Isaac Sim 场景编辑：** 熟悉 Stage、Prim、USD、视口、时间轴、物理材质及刚体属性。
2. **导入机器人：** 查看 URDF 导入后的 articulation 根节点、驱动、质量、关节限位和碰撞体。
3. **构建基本场景：** 地面、桌面、固定机械臂、抓取物体及灯光。
4. **验证传感器：** 放置头部与腕部相机，检查内参、外参、深度含义、遮挡和同步。
5. **学习 Isaac Lab 任务：** 了解场景、机器人资产、观测、动作、奖励、终止和 Event／Domain Randomization。
6. **运行官方基准任务：** 从 Cartpole、Franka Reach、Franka Lift。
7. **进入 RL：** 先跑无视觉、低随机化的状态策略，再增加视觉与接触复杂度。

**Manager-based 与 Direct 的取舍：** Manager-based 适合快速复用标准观测、奖励、重置和随机化模块；Direct 适合高度定制的接触过程或算法研究。两种模式都能实现强化学习环境，区别在工程组织，而不是理论上的 RL 能力。[7]

### 2.6 推荐统一练习：Panda + 方块 + 桌面

不要一开始就把不同平台中的两个机器人拿来比较。建议固定机器人、物体、桌高、末端点、初始位姿与动作接口，完成四次递进实验：**单关节响应 → 末端轨迹 → 方块抓取 → 加扰动的重新抓取**。


## 3. 机器人资产：URDF、MJCF、USD

### 3.1 不存在无损“一键转换”

| 内容 | URDF | MJCF | USD / Isaac |
|---|---|---|---|
| Link、Joint、惯性 | 标准描述能力 | 可表达 | 可表达 |
| 视觉和碰撞模型 | 支持 | 支持且可细化接触 | 支持且适合渲染 |
| 电机／执行器 | 标准本身描述有限 | 多种 actuator 和 tendon | 关节驱动与物理属性 |
| 复杂接触设置 | 通常依赖扩展 | 接触求解器参数丰富 | PhysX 接触及材质 |
| 机器人场景组织 | 比较基础 | 适合物理模型 | 支持大规模场景组合 |

建议维护一份**物理参数主表**：关节名称、轴方向、关节零位、限位、link 质量、质心、惯量、TCP、碰撞体、驱动模式及传感器外参。它比仅维护一份 URDF 更能保证跨平台一致。

### 3.2 导入后必须做的十项测试

1. 机器人基座坐标系与世界系是否一致；2. 关节名称与顺序是否匹配；3. 关节正方向是否正确；4. 角度与长度单位是否一致；5. 末端 TCP 定义是否一致；6. 质量与质心是否正确；7. 惯量是否物理可行；8. 碰撞体是否合理简化；9. 自碰撞过滤是否符合真实机构；10. actuator 的限幅、刚度、阻尼及控制频率是否一致。


## 4. 动力学、控制、接触与传感器

### 4.1 共同的动力学语言

对于刚体机器人，可用概念关系表达为：

**惯性效应 + 科氏／离心与重力等偏置项 = 执行器广义力 + 接触／约束广义力。**

在 MuJoCo 和 PhysX 中，数值求解实现不完全相同；比较两者时，应先确认模型、执行器和接触条件一致，再比较轨迹或物体位姿。

### 4.2 五种常见控制方式

| 控制方式 | 策略输出 | 要警惕的问题 |
|---|---|---|
| 关节位置目标 | 各关节的期望角度 | 背后 PD 增益、力矩限幅、速度限幅 |
| 关节位置增量 | 相对当前／历史目标的增量 | 累积漂移、增量缩放、动作连续性 |
| 关节速度 | 期望速度 | 停止与接触时的稳定性、积分误差 |
| 关节转矩 | 执行器力矩 | 重力补偿、摩擦、饱和与真机安全 |
| 末端位姿或阻抗 | TCP 位姿／力学参数 | IK 可解性、奇异位形、末端坐标系 |

**关键提醒：** “策略输出关节位置”与“仿真中把关节直接设置到该位置”完全不同。前者应经由真实可比的控制器和执行器动力学实现，后者可能绕过物理约束，形成严重的 Sim-to-Real 偏差。

### 4.3 三个时间尺度必须分开

- **物理步长：** 用于积分碰撞、动力学和接触；越小通常越稳定，但成本更高。
- **控制频率：** 位置伺服、阻抗环或 IK 更新速率。
- **策略／相机频率：** RL 推理和视觉观测速率，可能互不整除。

示例：物理 500 Hz、策略 50 Hz，则每个策略动作维持 **10 个物理步**；若相机为 30 Hz，就必须明确图像缓存、时间戳和延迟，而不能假设策略每步都会得到新帧。真实机器人部署时还要考虑通信、估计、执行器响应和动作滤波的总延迟。

### 4.4 跨平台控制一致性

比较前固定四件事：**相同任务空间或关节空间动作定义、相同动作缩放、相同低层控制器语义、相同有效采样周期。** 不满足这些条件的性能差异不能简单归因于物理引擎。

## 5. RL 训练环境的工程接口

这份讲义只介绍**仿真环境接口的工程契约**，不再展开如何理论性地设计任务奖励；数学设计和运动技能的选择见配套《运动控制强化学习》教程。

| 模块 | Isaac Lab 工程入口 | MuJoCo 工程入口 | 需要确认的契约 |
|---|---|---|---|
| 场景与批量实例 | Scene / Articulation / Manager 或 Direct 工作流 | `MjModel`/`MjData`、批量模型/数据 | 实例间无状态串扰、资产参数可追溯 |
| 观测 | Observation Manager 或自定义缓冲区 | 传感器/状态抽取、观测封装 | shape、单位、坐标系、时间戳、可部署性 |
| 动作 | Action Manager 或自定义控制路径 | `ctrl`/actuator 与策略接口 | 数值限幅、物理含义、更新频率 |
| 奖励/完成 | Reward/Termination Manager 或 Direct 逻辑 | 任务回调 | 成功判定与 timeout 分离、日志可追溯 |
| 重置/随机化 | Event/Reset Manager 或 Direct 回调 | 批量 reset 与参数更新 | 无跨回合状态泄漏，随机种子可固定 |
| 训练连接 | RSL-RL、RL-Games、skrl 等所支持的适配 | Playground/Brax/其他适配 | rollout、batch、device、checkpoint、normalizer 一致 |

### 5.1 环境接口最小验收

- **Reset 的确定性**：同一模型、初态、种子与后端下，重置后关键状态应可重复；CUDA 并行和异步管线可能仍有非确定性，需说明边界。
- **步进关系**：记录每一次策略动作对应的物理步数、执行器更新次数和传感器采样时刻。不能把物理 FPS、环境 FPS 和策略 steps/s 混为一谈。
- **数值边界**：动作归一化、关节限位、奖励截断、NaN/Inf、终止与时间上限必须显式检查。
- **信息隔离**：只有用于训练 critic 的 privileged state 才可作为特权输入；部署 actor 不得意外读取真实物体位姿、未来参考或地形真值。
- **依赖固定**：保存资产哈希、模型尺寸、传感器配置、后端选项、训练器配置、归一化统计和策略 checkpoint。

### 5.2 PPO/SAC 的最低限度工具选择

PPO 常用于大规模同步 rollout；SAC 需要 replay buffer、off-policy 更新和妥善处理并行采样的训练栈。这里的选择标准是**训练器是否实际支持所需算法、能否稳定适配当前环境和设备**，而不是再次推导 actor–critic。算法原理和实际控制策略设计放到独立课程。


## 6. Isaac Lab 的并行训练工作流

### 6.1 从已知任务到自定义任务

**第 1 步：选任务。** 从 Cartpole 了解训练闭环，从 Franka Reach 验证动作与观测，从 Lift 进入接触。

**第 2 步：确认物理后端与版本。** 2.x 既有 PhysX 任务与 3.0 多后端任务不能默认混用；先用官方支持的参考配置完成基准。

**第 3 步：定义场景。** 机器人、桌面、物体、关节驱动、物理材质、初始位置、相机均应记录参数。

**第 4 步：定义 RL 五大接口。** 观测、动作、奖励、终止、重置；确认每次 reset 后环境状态和缓存同步。

**第 5 步：用单环境“过拟合”验证。** 固定物体、固定目标、无随机化，确保策略确实能够成功。失败时先查环境，不急于扩大网络。

**第 6 步：增加并行环境。** 从显存可承受的少量环境开始，逐步观察每秒环境步数、GPU 利用率、显存和接触稳定性；并行数越大并不保证整体训练越快。

**第 7 步：训练 PPO 基线。** 固定种子、学习率、rollout 长度、网络结构、奖励尺度和控制周期。每次只改一类因素。

**第 8 步：进行独立评估。** 关闭训练探索噪声或按固定评估协议采样，保存成功率、轨迹、碰撞和失败录像。

**第 9 步：加入真实感变化。** 动力学随机化、执行器延迟、观测噪声、视觉遮挡，逐项验证边际效果。

**第 10 步：保存完整可复现包。** 模型资产、任务配置、奖励权重、归一化统计、训练器版本、checkpoint、评估脚本版本和关键日志均需要保留。

### 6.2 Isaac Lab 框架选择

| 训练框架 | 推荐用途 | 注意事项 |
|---|---|---|
| RSL-RL | GPU 大并行 PPO、状态控制、蒸馏 | 检查 actor／critic 观测配置与网络兼容 |
| RL-Games | 已有 RL-Games 实验，或需要其支持的算法 | 不同版本的算法与任务配置存在差别 |
| skrl | 需要更广的算法支持或 PyTorch/JAX 选项 | 额外适配与可复现性验证 |
| Stable-Baselines3 | 小规模基线、熟悉的分析工作流 | 大规模 GPU 向量环境未必最合适 |

### 6.3 Isaac Lab 常见陷阱

**显存：** 相机数量 × 分辨率 × 环境数会显著提高显存占用，加入视觉之后应重新进行吞吐基准。**Headless：** 不打开交互式窗口不等于自动关闭全部离屏渲染；也不等于视觉训练无需配置相机输出。**Reset：** 并行环境各自独立结束，必须正确处理环境索引及历史观测清空。**奖励：** 物理频率或策略 decimation 改变后，要检查按时间积累的奖励是否被无意缩放。


## 7. MuJoCo、MJX 与 MJWarp 的训练工作流

### 7.1 经典 MuJoCo：验证逻辑优先

经典 MuJoCo 适合单机控制实验、动力学分析、小规模 Gymnasium 环境和 CPU 并行 rollout。优点是调试直接、单步延迟较低；但大规模训练若每步都需 CPU→GPU 搬运观测，可能出现通信瓶颈。[3]

建议路线：先在经典 MuJoCo 中完成模型、奖励、重置、接触和控制正确性验证，再评估是否需要 GPU 批量实现。

### 7.2 MJX / MJWarp：高吞吐量训练

**MJX-JAX** 利用 JAX/XLA 做批量计算；**MJWarp** 针对 NVIDIA GPU 并行场景优化，尤其适合许多独立机器人环境的高吞吐量仿真。不要把“总吞吐量更高”误解成“单个仿真步的延迟更低”：MJWarp 侧重吞吐，经典 MuJoCo 常更适合单环境低延迟控制。当前 MJX-Warp 路线不以自动微分作为能力目标。[3][4]

**MuJoCo Playground** 已提供运动控制与部分视觉环境，以及基于 MJX/MJWarp 的 RL 基线；适合对照 Isaac Lab 的状态策略训练。[10]

### 7.3 MuJoCo RL 的十步流程

1. 从 Menagerie 或可靠 MJCF 模型出发；2. 确认关节／执行器与真机一致；3. 构建最小操作场景；4. 验证接触与自由运动；5. 定义观测动作与归一化；6. 设计奖励、终止、重置；7. 用小样本和固定初态测试；8. 选择 CPU、MJX-JAX 或 MJWarp；9. 使用 PPO 或受支持的其他训练器；10. 在不同初态、物理参数和仿真器中独立评估。

**并行后端注意事项：** GPU 版本的求解能力与模型特性并非完全等价；迁移时重点检查 tendon、复杂约束、接触数量限制、传感器，以及批量重置行为。并非所有 CPU MuJoCo 模型都能无修改地获得同样物理结果。


## 8. 训练效率、显存与调试

### 8.1 至少测量五个数字

**环境步／秒、完整物理步／秒、策略更新耗时、峰值显存、达到既定成功率所需的墙钟时间。** 视觉任务还应统计渲染时间、编码器前向时间与数据搬运时间。

不同文献的 FPS／SPS 可能统计口径不同：单环境物理帧、所有环境总步数或策略步数不相等。报告训练速度必须同时给出环境数、物理／控制频率、GPU 型号和相机设置。

### 8.2 并行环境并非越多越好

环境数较小时 GPU 未饱和；环境数过大时显存、接触求解、相机渲染、数据搬运和策略更新可能成为瓶颈。应从小规模开始逐倍增加，用真实的成功率／小时和 GPU 使用数据确定工作点，而非凭经验固定为几千环境。

### 8.3 视觉 RL 的两条路线

- **端到端视觉 RL：** 直接从图像训练，简单直观但计算成本高，对遮挡、视觉域差异更敏感。
- **状态 teacher → 视觉 student：** 先学习可达的控制策略，再把视觉表征或估计状态用于学生训练；更适合用来排除“物理任务不会做”和“视觉看不懂”的混杂因素。

如果视觉 teacher/student 的控制频率不同，蒸馏损失必须对齐动作时间戳与输出语义，不能只对齐向量维度。

### 8.4 训练调试的优先级

观察到学习失败时，先排除数据管线问题：观测维度/归一化、动作缩放与 clip、奖励统计与终止理由、环境数改变后的 batch 定义、每回合时间步的物理含义，然后才调整优化器。将 PPO 的 KL、clip fraction、value loss 或 SAC 的 Q 值、温度、replay 年龄记录为**排错信号**，而不是把它们当成平台教程的算法主题。

若使用视觉，需同时记录图像尺寸、相机个数、渲染 FPS、编码器用时、GPU 显存，以及渲染到策略推理的排队延迟。只有总 wall-clock 训练时间缩短、性能在相同评测协议下不下降，才能称为真正的提速。


## 9. 域随机化实现、评估与复现

| 随机化类别 | 建议变量 | 验证目的 |
|---|---|---|
| 几何 | 物体初始位姿、台面高度、小尺度偏差 | 空间泛化 |
| 动力学 | 质量、惯量、摩擦、关节阻尼 | 物理模型偏差 |
| 执行器 | 延迟、死区、刚度、限幅、低通滤波 | 实际伺服差异 |
| 观测 | 关节噪声、位姿估计偏差、丢帧 | 感知与同步鲁棒性 |
| 视觉 | 光照、材质、背景、遮挡、相机外参 | 图像域变化 |
| 扰动 | 外力、滑移、掉落、目标移动 | 恢复和纠错能力 |

**推荐次序：** 无随机化学会任务 → 扩展初始状态 → 动力学与执行器 → 状态估计噪声 → 视觉域随机化 → 外力和掉落恢复。随机化幅度以真实机器人的可观测误差或合理系统辨识区间为基础，避免生成大量真机永远不会遇到的极端状态。

**训练集与评测集应当分离。** 评测时需要固定未参与训练的物体姿态、质量、摩擦、照明和相机偏差组合，才能判断真正泛化，而不是只在训练随机化内插成功。

### 9.1 核心指标

| 指标 | 说明 |
|---|---|
| Success rate | 符合客观判定条件的回合比例 |
| Time-to-success | 达到成功的步数或真实时间 |
| Drop / slip rate | 掉落／滑移比例 |
| Recovery success | 出现可恢复扰动后的重新成功比例 |
| Pose / tracking error | 物体或末端位姿误差 |
| Unsafe event rate | 越界、过载、碰撞等事件比例 |
| Environment steps / wall time | 样本效率与训练总效率 |
| Real-time latency | 部署时策略、感知与控制链时延 |

建议至少使用多个随机种子，并报告均值及不确定性区间；不能仅选择最好的一个训练 checkpoint。跨方法比较时固定模型、环境、动作接口、训练预算和评估分布。

### 9.2 如何避免不可信结论

- **跨引擎比较不等于严格动力学等价。** 不同求解器的摩擦和接触实现不同，必须报告这种差异。
- **相同成功率不等于相同鲁棒性。** 应分阶段统计接触、旋转、释放、恢复的失败模式。
- **训练帧数不等于交互样本数。** 物理步、策略步和并行总步数必须分别定义。
- **不要只保存最终权重。** 还要保存观测归一化统计、动作缩放和依赖版本。


## 10. 部署接口、标定与跨仿真器验证

### 10.1 部署前的六个校准层

1. **几何：** 关节零位、TCP、机器人底座与桌面关系。
2. **动力学：** 手部负载质量、质心、惯量、摩擦和重力补偿。
3. **执行器：** 控制模式、位置／速度／力矩限制、响应延迟。
4. **视觉：** 头部与腕部相机的内外参、图像时间戳与深度单位。
5. **软件：** ROS 2 或控制 SDK 的频率、缓存、丢包和异常恢复。
6. **安全：** 急停、工作空间、碰撞阈值、物体脱落处理。

### 10.2 真机验证的阶梯

**空载关节运动 → 无接触轨迹 → 慢速接近 → 低力抓取 → 物体抬升 → 物体旋转 → 人为小扰动 → 可控掉落与重抓。** 每一级先设置限幅、保护和人工监护，再进行下一项。

**真机性能低于仿真时的诊断顺序：** 先查坐标系与观测同步，再查动作语义与伺服频率，然后查接触和动力学参数，最后才考虑扩大 RL 网络或调算法超参数。


## 12. 故障诊断与交付检查

| 现象 | 优先检查 | 不建议立刻采取的做法 |
|---|---|---|
| 机器人启动后抽搐 | 关节零位、刚度、碰撞、物理步长 | 直接提高控制增益 |
| 方块穿模 | 碰撞几何、接触设置和步长 | 只提高摩擦 |
| PPO 奖励上涨但任务失败 | 奖励分项、成功判定、观察录像 | 继续盲目增加训练步数 |
| SAC Q 值不稳定 | replay 分布、critic、目标网络、奖励尺度 | 只增大网络 |
| GPU 利用率低 | CPU-GPU 拷贝、渲染、环境数、同步点 | 立即堆到最多环境数 |
| 视觉训练极慢 | 相机数、分辨率、渲染成本、编码器 | 先上全分辨率图像 |
| 物体掉落后无法恢复 | 终止逻辑、RSI、视觉覆盖、目标定义 | 仅增加成功奖励 |
| 机械臂追踪误差大 | IK、TCP、延迟、动作缩放、限速 | 直接改 PPO 超参数 |
| Isaac 版本升级后行为变化 | 依赖锁定、四元数顺序、传感器／后端 | 直接沿用旧 checkpoint 作结论 |

**排查总顺序：** 模型正确性 → 坐标与单位 → 执行器控制 → 物理和接触 → 观测与延迟 → 奖励与 reset → 优化算法。

**模型与物理：** 关节顺序、轴向、限位、质量、惯量、TCP、碰撞体、执行器、物理步长、摩擦均已核查。  
**RL 任务：** 成功判据明确；观测无泄漏；动作限幅正确；奖励分项可解释；终止与 timeout 区分；RSI 覆盖关键事件。  
**训练：** 已跑通固定初态；记录种子、网络、训练器与环境版本；报告训练样本、吞吐、墙钟时间与峰值显存。  
**评估：** 多种子、独立初态、OOD 扰动、跨引擎、失败模式、drop recovery 均有记录。  
**真机：** 坐标与相机校准、速率和延迟匹配、力／速／位限幅、监护与急停机制准备完毕。

> **一句话总结：** MuJoCo 负责把物理模型和控制接口“解释清楚”；Isaac Sim 负责把机器人、场景和视觉“搭建可信”；Isaac Lab 或 MuJoCo Playground 负责把 RL “训练系统化”；最后用跨引擎、OOD 与真机结果验证策略，而不是只看训练奖励。


## 参考资料与扩展阅读（官方优先）

1. Isaac Lab Releases（含 3.0 Early Access 与迁移说明）：https://github.com/isaac-sim/IsaacLab/releases
2. Isaac Lab 3.0 Early Access 安装与架构：https://isaac-sim.github.io/IsaacLab/v3.0.0-EA/source/setup/installation/index.html
3. MuJoCo Warp 官方文档：https://mujoco.readthedocs.io/en/latest/mjwarp/
4. MuJoCo XLA / MJX 官方文档：https://mujoco.readthedocs.io/en/stable/mjx.html
5. Isaac Sim 5.1 系统要求：https://docs.isaacsim.omniverse.nvidia.com/5.1.0/installation/requirements.html
6. MuJoCo Menagerie 机器人模型：https://github.com/google-deepmind/mujoco_menagerie
7. Isaac Lab 2.3.2 Direct RL Environment：https://isaac-sim.github.io/IsaacLab/v2.3.2/source/tutorials/03_envs/create_direct_rl_env.html
8. Isaac Lab 2.3.2 传感器文档：https://isaac-sim.github.io/IsaacLab/v2.3.2/source/api/lab/isaaclab.sensors.html
9. Isaac Lab RL 框架对比：https://isaac-sim.github.io/IsaacLab/main/source/overview/reinforcement-learning/rl_frameworks.html
10. MuJoCo Playground：https://github.com/google-deepmind/mujoco_playground
11. MuJoCo 官方基础文档：https://mujoco.readthedocs.io/en/stable/
12. Isaac Sim 官方文档：https://docs.isaacsim.omniverse.nvidia.com/

**资料使用提醒：** 官方项目的版本、名称和 API 可能继续变化。本文刻意不提供命令行安装细节，以免把只适用于某个版本的命令误用到其他版本。

13. [MuJoCo MJX 官方实现与可微性说明](https://mujoco.readthedocs.io/en/stable/mjx.html)
14. [Isaac Lab 3.0 Early Access Release Notes](https://github.com/isaac-sim/IsaacLab/releases)

**跨课程说明：** 算法目标、动作跟踪、Residual RL、Teacher–Student 和失败恢复详见《具身智能中的运动控制强化学习》。