总览 / RoboDojo · D56

RoboDojo：按能力维度剖分的统一评测

42 canonical + 12 random + 18 真机：记忆、精度、长时程剖面全文。

接近原文长文版仅排版加工 · 未删减压缩RoboDojo · D56

What this is

RoboDojo 是一个面向通用机器人操作策略的统一仿真—真实机器人评测基准。当前开源仓库主要负责：Isaac Sim/IsaacLab 仿真环境、任务与场景、机器人和相机配置、评估客户端、结果汇总以及多 GPU/Docker 评测；策略模型、checkpoint 和策略服务主要由独立的 XPolicyLab 管理。

Stack

Language(s)： Python 3.11、Bash、YAML
Framework / runtime： NVIDIA Isaac Sim 5.1 + IsaacLab 2.3
Notable libraries： CuRobo、OmegaConf、PyTorch、WebSocket/XPolicyLab client
策略通信： 默认通过 WebSocket 与外部 policy server 通信
评测形态： eval-only；不负责策略训练

1. 任务集：42 个基础任务 + 12 个随机泛化变体

RoboDojo 的核心不是单一的抓取或堆叠任务，而是按照机器人能力划分为五个维度：

能力维度	主要考察内容	任务数量
Generalization	对物体、位置、布局变化的泛化能力	12 个基础任务，另有 12 个 `_random` 变体
Memory	多步骤过程中的记忆、顺序和状态保持	6
Precision	插入、对齐、精细放置等高精度操作	8
Long-Horizon	长序列、多阶段任务执行能力	8
Open	语言、视觉或开放式条件下的任务理解与执行	8

因此，正式统计时是：

42 个 canonical simulation tasks
54 个 runnable task configurations
42 个基础任务
12 个 Generalization 维度的 _random 变体
README 还声明了 18 个真实机器人任务，覆盖 Piper X、Piper 和 ARX X5 三种本体。

任务定义方式

每个任务通常由两个文件组成：

task/RoboDojo/
  tasks/<task_name>.py       # 任务逻辑、reset、reward/success
  config/<task_name>.yml      # 物体、布局、随机化、标签配置
  task_registry.py            # 动态加载任务

任务通过 task_registry.load_task_class(task_name) 动态导入，并要求：

Python 文件名、YAML 文件名和任务类名保持一致；
任务类继承 TaskEnv；
任务实现 run_reward()；
成功判断必须真正调用 RewardManager，不能简单恒为成功。

例如 stack_bowls 的 YAML 定义了 3 个 bowl、采样范围和标签：

Rigid:
  -
    common:
      xlim: [-0.45, 0.45]
      ylim: [-0.25, 0.07]
      rotate_rand: False
      relative_plane: "Table"

    category:
      -
        name: "bowl"
        index: [1, 2, 3, 5, 7, 8, 9, 10]

    select_mode:
      nums: 3
      mode: "same"
      label: ["bowl0", "bowl1", "bowl2"]

任务逻辑则通过一系列可解释的物理条件来判断，例如：

bowl 是否保持竖直；
bowl 是否按正确顺序堆叠；
机器人是否回到初始位置；
是否完成所有阶段。

这意味着 RoboDojo 的任务评价不是简单的分类标签，而是对物体关系、姿态、位置、顺序和机器人状态的组合验证。

2. 引擎 & 本体：Isaac Sim/IsaacLab + 配置化多机器人、多物体场景

仿真引擎

仓库基于：

Isaac Sim 5.1
IsaacLab 2.3
CuRobo
PhysX GPU 仿真
Isaac Sim tiled camera / RTX 渲染

TaskEnv 是任务环境的基础骨架，负责组合：

TaskEnv
├── RobotManager
├── SceneManager
├── CameraManager
├── TiledCaptureManager
└── Task-specific RewardManager

TaskEnv 初始化时，会根据配置创建：

机器人；
场景和物体；
相机；
tiled capture；
并行环境数量与环境间距。

场景和物体类型

SceneManager 支持多种物体类型：

rigid object
dynamic object
articulation
garment / deformable object
geometry
fluid
primitive shape
room、table、ground、light、background 等环境组件

场景主要由 YAML 配置描述，支持：

USD 资产；
primitive；
物体类别和索引；
物体标签；
初始位置、姿态、缩放；
随机布局；
多环境 seed；
不同场景模板，例如 default 和 conveyor。

这让任务代码和具体资产、布局配置相互解耦：任务代码描述“要做什么”，YAML 描述“用哪些物体、放在哪里”。

机器人本体

代码中直接注册的机器人包括：

ARX X5 / X5
Franka

典型配置是双臂 X5：

robots:
  - robot_name: x5
    robot_type: arm
    type: target

  - robot_name: x5
    robot_type: arm
    type: target

部分复杂任务使用：

dual_x5_and_franka_competition.yml

其中：

两个 X5 是 target arms；
Franka 作为 support arm；
support arm 可参与辅助操作，但不一定作为策略的主要控制对象。

RobotManager 统一处理：

单臂与双臂命名；
joint action；
end-effector pose action；
gripper 映射和 mimic joints；
IK；
CuRobo planner；
机器人初始状态；
相机挂载；
target arm 与 support arm。

策略动作可以是：

joint position；
end-effector pose；
delta end-effector pose；
gripper/hand action。

观测

ObsManager 将观测统一成：

vision
state
action
instruction
additional_info

视觉侧可以包含：

RGB；
approximate depth；
depth；
相机内参；
相机外参；
图像尺寸。

机器人状态侧可包含：

joint state；
world-frame end-effector pose；
上一步控制动作。

默认 arx_x5.yml 中，观测频率为 25 Hz，并开启 joint state 和 world EE state。

3. 评估指标和分数基线

3.1 成功率

每个 episode 最终会得到：

{
  "success_rate": 0.0,
  "eval_time": 0,
  "score": 0.0,
  "details": {}
}

其中：

success rate：成功 episode 数 / 有效评测 episode 数；
score：任务内部定义的过程分数或最终分数；
eval time：实际计入评测的 episode 数；
details：每个 layout/seed 的 success 和 score。

任务成功通常由 RewardManager.get_reward() 得出。episode 会在以下情况下结束：

所有 success 条件满足；
达到 step_lim；
任务状态被判定失败。

3.2 分阶段分数

RoboDojo 不只记录二值成功，还支持过程分数：

reward_manager.score(
    check_list,
    score_list,
    score_mode="transition",
)

目前支持三种主要 score mode：

`paired`

每组检查条件对应一个分数，所有完成的检查分数可以累加。

`by_count`

按照完成的阶段数，返回当前达到的分数等级。

`transition`

把任务建模成状态转移：

state 0 → state 1 → state 2 → ... → final state

例如 stack_bowls 使用：

[15, 100]

含义可以理解为：

完成部分堆叠阶段：15 分；
完成最终任务：100 分。

这种设计可以区分：

完全失败；
完成了一部分操作；
已经完成关键中间步骤但最终失败；
完整成功。

3.3 Generalization 的特殊统计方式

Generalization 任务采用标准布局和随机布局配对：

stack_bowls
stack_bowls_random

每个子任务通常各运行 25 个 episode，最终合并为 50 个 episode：

25 standard + 25 random = 50

评估汇总脚本明确规定：

_random 任务不会单独作为主任务报告；
它会与对应 base task 合并；
同时额外输出 standard vs random 的对比；
可以直接观察随机布局带来的性能下降。

这比简单把随机布局当作另一个独立任务更适合衡量真正的泛化能力。

3.4 多 seed 和汇总方式

标准评测使用：

seed 0
seed 1
seed 2

汇总脚本：

每个 task/seed 读取最新 timestamp 结果；
单独任务通常需要 50 个 episode；
Generalization 需要 standard/random 各 25 个 episode；
按 task、能力维度和整体分别统计；
对多个 seed 计算均值和标准差；
未完成的 cell 保留为空；
42 个任务 × 3 个 seed = 126 个完整评测 cell。

3.5 分数基线

从当前仓库来看，代码仓库本身没有提交固定的 baseline 分数表。它提供的是：

指标定义；
结果 JSON 格式；
评测任务；
_summary.md 生成脚本；
leaderboard 的线上入口。

因此，项目内可复现的“基线”更准确地分成两类：

评测基线

统一 42 任务；
5 个能力维度；
3 个 seeds；
Generalization 使用 25 + 25；
success rate 和 score 统一聚合。

策略基线

由 XPolicyLab 中接入的策略模型产生；
具体策略分数依赖 checkpoint、policy、embodiment、seed 和当前评测版本；
需要以官方 leaderboard 或对应的评测结果目录为准。

换句话说，RoboDojo 的 repo 更像是一个标准化评测协议和 harness，而不是把某个策略模型的固定分数硬编码进仓库。

4. Harness 做了什么优化？

这里的 harness 可以理解为从：

启动策略 → 启动仿真 → 连接 policy server → 执行动作
→ 检查 reward → 保存视频和 JSON → 汇总 leaderboard

这一整套自动化评测基础设施。

RoboDojo 的主要优化集中在以下几个方面。

4.1 统一 policy server 和 simulator client

策略不直接嵌入仿真进程，而是由 XPolicyLab 提供 policy server，RoboDojo 作为 simulator client：

XPolicyLab policy server
          ↑ WebSocket
RoboDojo Isaac Sim client

优点是：

不同策略只需要实现统一 deploy adapter；
策略依赖和仿真依赖隔离；
策略服务器可以在另一台机器运行；
Docker 中只放仿真客户端，不需要把每个策略及其依赖都打进镜像。

支持三种典型模式：

robodojo.sh eval       # server + client，本机一键评测
robodojo.sh server     # 只启动策略服务器
robodojo.sh client     # 只启动仿真客户端

4.2 一键 CLI 和自动校验

统一入口是：

bash scripts/robodojo.sh <command>

主要命令包括：

doctor       检查资产、环境、配置
eval         单任务评测
server       只启动 policy server
client       连接外部 policy server
smoke        少量 episode 快速检查
benchmark    完整 benchmark sweep
dimensions   查看能力维度
summarize    汇总评测结果
tasks        检查任务 inventory

这避免了每个策略、每个任务都需要手工拼接启动参数。

4.3 动态任务 inventory

task_inventory.py 不启动 Isaac Sim，就能通过 AST 检查：

task Python 文件是否存在；
同名任务类是否导出；
对应 YAML config 是否存在；
任务是否属于某个能力维度；
任务是否 runnable。

因此可以在真正启动 GPU 仿真之前发现常见错误：

文件名和类名不一致；
缺少 YAML；
任务未归入 capability dimension；
配置和代码不配套。

4.4 多 GPU 任务调度

smoke 和 benchmark 支持：

--gpu-ids 0,2,5,7

harness 会基于 runtime table 对任务进行平衡分组，而不是依赖固定的任务分组。

这带来的优化是：

不同任务可以跨多个 Isaac Sim 进程并行；
根据历史运行时间进行更均衡的 GPU 分配；
可以只选择某个 capability dimension；
可以使用 --only 或 --tasks-file 做子集评测；
支持 batch client。

这对 42 个任务的批量评测非常关键，因为不同任务的仿真时长、物体复杂度和渲染成本差异很大。

4.5 Batch evaluation 和异构并行环境

评测环境支持多个并行 env：

num_envs

同一个 Isaac Sim 进程中，可以并行运行多个 layout/seed。EvalEnv 会：

按 env 维护 success、fail、step count；
批量获取 observation；
批量处理 action；
对不同 env 分别记录 layout_id；
对不稳定环境单独剔除。

同时，某些 policy 的 deploy.yml 可以声明 eval_batch，harness 会据此决定使用单 episode 还是 batch evaluation。

4.6 seed-controlled layout replay

每个环境使用独立 seed：

task → seed → saved layout → reproducible episode

评测时会：

通过 seed 生成或恢复 layout；
将布局保存下来；
在 reset 时恢复同一布局；
使用 layout_id 记录结果；
避免简单的随机 reset 导致结果不可复现。

这对 benchmark 尤其重要，因为同一个策略的结果可以在多个 seed 上稳定比较。

4.7 对 PhysX/仿真崩溃的恢复

这是当前 harness 中比较有工程价值的一部分。

main.py 和 eval_env.py 对 PhysX 问题做了多层处理：

对包含 articulation 的任务选择性启用 PhysX warning monitor；
监测 PhysX broken environment；
检查 end-effector pose 是否出现 NaN/Inf；
发现坏 env 后放弃对应 seed；
从 seed queue 补充新的 seed；
保留已有评测进度；
必要时重新启动当前进程；
进程内重启次数有限制；
超过限制后交给 shell 层重试。

评测进度通过：

_resume_<run_id>.json

原子写入保存，包括：

已完成成功数；
已完成失败数；
已完成 layout；
被放弃的 layout；
当前累计 score；
评测详情；
restart count。

因此，单个 PhysX/CUDA 错误不会直接让整轮 50 或 150 个 episode 全部作废。

4.8 视频流式写盘，降低内存压力

旧式做法通常是把完整 episode 的图像帧积存在内存，episode 结束时再写视频。当前实现使用：

VideoStreamWriter

按 frame 到达顺序写入临时 MP4：

_stream/env{env_idx}_{camera}.tmp.mp4

episode 结束后：

成功 episode 重命名为 success 视频；
失败 episode 重命名为 fail 视频；
不稳定或异常 episode 删除临时视频；
进程异常退出后，启动时自动清理残留 .tmp.mp4。

这样可以明显减少长 episode、多环境、多相机评测时的 RAM 占用。

4.9 观测帧和物理状态同步

ObsManager.render_for_capture() 不再简单调用一次 render()，而是等待 camera buffer 追上最新的 physics state。

此外，entrypoint 会设置 zero-delay Kit 参数，减少：

observation 使用上一帧图像；
RGB 与机器人状态错位；
camera pipeline 异步延迟；
不同机器上的 frame discrepancy。

这是对视觉策略评测很重要的稳定性改进。

4.10 action 校验和动作插值

EvalEnv.validate_action_dict() 会检查：

action key 是否正确；
单臂是否错误使用 left_/right_ 前缀；
action 是否为一维数组；
joint 维度是否匹配；
EE pose 是否是 7 维；
单臂/双臂 action schema 是否一致。

收到一个高层动作后，harness 还会：

将 EE pose 转换成 IK joint target；
对 joint action 做插值；
前 80% interpolation steps 逐渐逼近 target；
最后 20% hold target；
对 gripper 做范围裁剪和 mimic joint 映射。

这让不同策略输出的离散动作可以更平滑地驱动仿真机器人，减少动作跳变和物理不稳定。

4.11 Docker 化和 host-side policy server

Docker 镜像只包含：

Isaac Sim；
IsaacLab；
CuRobo；
RoboDojo 仿真代码；
XPolicyLab client。

策略 server 在容器外运行，通过 WebSocket 连接。这样可以：

让同一个仿真镜像评估不同策略；
避免重新制作包含策略依赖的巨大镜像；
支持 host、bridge 和跨机器网络；
复用 Warp、Isaac Sim extension、shader cache；
通过 smoke test 验证完整评测链路。

How it's organized

env/                   Isaac Sim 环境骨架、机器人/场景/相机/reward managers
env_cfg/               仿真、场景、机器人、相机配置
task/RoboDojo/         42 个任务、12 个 random 变体和任务 YAML
src/eval_client/       policy server 对接、观测/动作/评测循环、恢复机制
scripts/               robodojo.sh、安装、资产、benchmark、summarize
docker/                Docker 镜像与端到端 smoke test
utils/                 资产路径、布局、保存/加载、随机化和 pipeline 工具
XPolicyLab/             外部策略服务与策略适配器，git submodule
third_party/           IsaacLab 和 CuRobo，git submodule

整体运行链路：

scripts/robodojo.sh 解析命令和任务；
根据 env_cfg、task YAML 和 scene config 创建 Isaac Sim 环境；
TaskEnv 组合机器人、场景和相机；
src/eval_client/eval_env.py 通过 WebSocket 获取策略动作；
RobotManager 执行 joint/EE action；
RewardManager 检查成功条件并计算阶段分数；
EvalEnv 保存 _result.json 和 episode videos；
summarize_result.py 汇总成按任务、能力维度、seed 和策略的 Markdown leaderboard。

How to run it

单任务 dry-run：

bash scripts/robodojo.sh eval \
  --policy-dir XPolicyLab/policy/<POLICY> \
  --task stack_bowls \
  --ckpt <CKPT> \
  --policy-env <ENV> \
  --dry-run

快速 smoke test：

bash scripts/robodojo.sh smoke \
  --policy-dir XPolicyLab/policy/<POLICY> \
  --ckpt <CKPT> \
  --policy-env <ENV> \
  --only stack_bowls,push_T \
  --dry-run

按能力维度运行：

bash scripts/robodojo.sh benchmark \
  --dimension memory,long-horizon \
  --policy-dir XPolicyLab/policy/<POLICY> \
  --ckpt <CHECKPOINT> \
  --policy-env <ENV> \
  --eval-num native

多 GPU benchmark：

bash scripts/robodojo.sh benchmark \
  --policy-dir XPolicyLab/policy/ACT \
  --ckpt test_ckpt \
  --policy-env RoboDojo \
  --eval-num 1 \
  --gpu-ids 0,2,5,7 \
  --dry-run

结果汇总：

bash scripts/robodojo.sh summarize

Docker 端到端测试：

bash docker/smoke_docker.sh run

需要注意：

需要 NVIDIA GPU；
默认依赖 Isaac Sim 5.1、IsaacLab 2.3；
需要下载 Assets/；
运行策略评测时需要 XPolicyLab policy server；
Docker 镜像本身不包含策略和 checkpoint；
评测许可证是非商业研究用途许可证。

Try asking

RoboDojo 的五个 capability dimension 和 42 个任务分别是什么？
RoboDojo 的 RewardManager 如何区分 success rate、process score 和 transition score？
smoke_all_tasks.sh 如何根据 GPU runtime table 对任务进行多 GPU 分组？

关于“分数基线”的补充

仓库代码能够确认的是指标和统计规则，但不能仅凭仓库内容确认某个具体策略的最新 leaderboard 分数。官方 README 将 leaderboard 放在：

如果要做严谨的 baseline 对比，建议固定以下条件后重新跑：

policy/checkpoint
embodiment
task set
seed = 0, 1, 2
Generalization = standard 25 + random 25

否则不同 policy、checkpoint、评测版本或本体配置之间的分数不应直接横向比较。

← 上一章 · RoboTwin 2.0 · D55RoboTwin 2.0：双臂数字孪生的数据工厂下一章 · VLA-Harness · D58 →vla-eval：模型、环境、协议三解耦的评估矩阵