总览：不是新模型，是一张"该怎么搭"的配方地图

这也是这篇笔记采用的视角——OpenHLM 把"全身人形 loco-manipulation 该怎么搭"这件事，拆成了三个阶段、逐个变量做消融，每个决策都有真机数据背书。对任何做全身 VLA 的工作来说，它相当于一份别人已经替你踩过坑的 checklist。三个阶段（对应图 1 的三块）：

Fig 1 · p.2 Overview of OpenHLM. A roadmap of controlled experiments in three phases: (I) compare teleop interfaces and adopt a joint-based whole-body controller; (II) adapt a manipulation VLA to the humanoid's full action space along several design axes; (III) extend the policy to new objects/instructions via co-training with stationary teleop or HuMI. OpenHLM 总览：三阶段受控实验路线图——(I) 选 joint-based 全身控制器；(II) 把操作 VLA 沿多个设计轴适配到人形全动作空间；(III) 用便宜数据协同训练扩展到新物体/新指令。

"13 个实验"到底是哪 13 个

这 13 个实验就是论文 §3–§4 的逐变量消融，一次只翻转一个设计选择，看真机 task progress 掉多少。下面这张表把它们对号入座，也是这篇笔记后面章节的骨架：

HLM-12 基准：四类"逼你用全身"的能力

Fig 2 · p.3 The HLM-12 Benchmark. Tasks fall into four capability families targeting different aspects of whole-body behavior, with one representative per family shown. HLM-12 基准：12 个任务分成四类能力，图中每类展示一个代表任务。完整 12 任务规范见附录 A。

评测协议怎么切分：大部分 §3.1 / §3.2 的消融跑在覆盖四类的 4 任务子集（Cola Placement / Shelf Cup Transfer / Bottle Disposal / Jar Opening）上；VLA 定型后在 8 个训练任务上确认能泛化；§3.3 协同训练额外引入 4 个 held-out 任务（全身遥操作从没覆盖过），凑齐 12 个；最后 §4 用一个跨越机器人大垂直工作空间的长时序任务做系统级对标。记住这套"4 → 8 → 12 → 长时序"的切分，后面看数字才不会串台。

遥操作接口对比：为什么 Joint-based 是最优解 ★核心借鉴

三种接口共享同一套本体感受状态：一个 32 维 body state（root roll、root pitch、yaw 角速度 + Unitree G1 的 29 个关节）加每只手一个夹爪标量。区别只在操作者能下达什么指令、以及录下来的 action 是什么：

实验 #1 · 三接口真机对比（Table 1）

三个任务、每任务 40 条演示、每种接口各训一个 VLA，真机各跑 5 次。紫色 ✗ = 该接口天生做不了这个任务：

读表要点：Joint-based 是唯一三个任务全通的接口（80–87% 进度）。更关键的是动作质量——它每次 rollout 只走 10–12 步，而解耦控制在 Cola 上要走 42.3 步（3.5× 膨胀），碎步、生硬、还会 ground-stomping；VR 三点则在可乐罐前犹豫不决，时长翻到 67.8s、进度只有 40%。解耦在 Shelf 上分数（93.3）甚至比 joint 高，但它整类"用身体部位操作"（Bottle）直接出局。覆盖面 + 自然度，joint-based 赢两头。

实验 #2 · 关节重定向 vs 原生 SMPL（Fig 3）

既然要全身，那动作表示是用"人体 SMPL 参数"还是"机器人关节角"？SMPL 看似能省掉 retarget 误差，但结果反过来：关节表示 88% 平均进度 vs SMPL 75%。原因是 81 维 SMPL 里大量坐标对机器人是冗余的，维度一高、VLA 反而学不动。最惨的是 Bottle Disposal——SMPL 训的策略脚跟抬不够、够不到踏板（100 vs 53）。结论：采集时就在线把全身演示 retarget 到机器人 32 维关节空间，别留 SMPL。

实验 #3 · 未来帧预览延迟 = 0.2s（Fig 4）

低层运动追踪控制器有个可调的预览延迟 Δt：控制器提前看多远的参考动作再去跟踪。预览越长动作越平滑，但操作者的指令到落地的延迟也越大。扫 Δt ∈ {0, 0.2, 0.4, 0.6}s：0.2s 命中最佳平衡（67% 进度、演示时长基本等于零预览的 35s）。Δt=0 时操作者最跟手但机器人走路抖、跺脚；Δt=0.6s 时延迟压垮操作者，进度暴跌到 13%。后续所有阶段都用 0.2s。

VLA 设计：输入/动作格式、预训练、动作生成

Fig 5 · p.7 VLA design ablations on the 4-task subset. Amber: interface ablations (Q1) — drops are minor, no single choice is the bottleneck. Rose: pretraining ablations (Q2) — robot pretraining (π₀.₅) dominates, PaliGemma & from-scratch collapse. Sage: one-step action generation (Q3) — both underperform the 10-step baseline by ~20 pts despite lower validation MSE. 紫=默认配置(Ours)。琥珀组=Q1 接口消融（掉分都很小）；玫红组=Q2 预训练（π₀.₅ 91% ≫ PaliGemma 60% ≫ 从头 42%）；鼠尾草绿组=Q3 单步动作（虽然验证 MSE 更低，真机反而掉 ~20 分）。

Q1 · 输入 & 动作格式的四个选择（图 5 琥珀组）

π₀.₅ 预训练的动作向量是 双臂 32 维，而人形要 34 维（§3.1 的 32 维 + 两个平行夹爪维）。围绕"输出动作 + 输入本体感受"这两根线，作者消融了四个选择：

结论有点反直觉：四个"坏选择"每个单独翻转，4 任务平均进度只掉一点点，没有单一瓶颈——小幅波动更像是鲁棒性下降或 5 次 rollout 的噪声。但作者补了一句关键提醒：坏选择不能叠加——同时"去掉本体感受 + 改用相对动作"会灾难性失败，因为策略一旦漂到分布外就靠视觉也拉不回来（没有本体感受这个锚）。

Q2 · 预训练来源：机器人预训练即使跨 embodiment 也决定性有用（图 5 玫红组）

这是全节最强的信号。三种初始化对比：π₀.₅（在静态/轮式双臂机器人数据上预训练，不含任何人形数据）91% ≫ PaliGemma（同架构但只有视觉语言预训练）60% ≫ 完全从头 42%。差距巨大。

藏在差距背后的惊人细节：PaliGemma 初始化和 π₀.₅ 初始化的模型，在 held-out 验证集上的动作 MSE 几乎一模一样；可一放到真机上就天差地别——PaliGemma 版抓取一直更弱、抓空了很少能重试，而 π₀.₅ 版会流畅地"看到错→纠正→重试"。这说明两件事：① π₀.₅ 预训练数据里那种闭环纠错行为先验（"see error, correct, retry"）能跨 embodiment 迁移，双臂→人形的 gap 是真实的，但远小于"有机器人预训练 vs 完全没有"的 gap；② 动作 MSE 是个糟糕的代理指标，别拿它选模型。

Q3 · 单步动作生成会掉分（图 5 鼠尾草绿组）

π₀.₅ 的 flow-matching 动作头推理时要在多步（默认 10 步）上积分向量场，每次 ~90ms。想提速就试单步：① 单步 flow matching（推理时积分步数设 1）；② drifting model（一种天生支持单步的生成模型）。结果：两者验证 MSE 都更低（~0.007 vs 10 步的 ~0.009），但真机进度都掉了约 20 分。作者推测单步产生的动作虽然 ℓ₂ 上接近目标，却更抖、时间上不够平滑。保留多步 flow matching。（又一次印证：MSE 骗人。）

实验 #10 · 每任务 40 条演示够用（Fig 6）

扫每任务演示预算：5→52%、10→60%、20→85%、40→91%，最大的跃升在 10→20 条之间，40 条后基本饱和。40 条演示对中等难度任务约花熟练操作者 1.5 小时，是个"数据高效"的默认预算。带到 8 个训练任务（每任务 40 条）上，系统拿到 89% 平均进度——4 任务子集上的所有选择都能泛化到更广的训练分布。

异构协同训练：用便宜数据补全新任务

Fig 7 · p.8 Heterogeneous co-training results on the 4 held-out tasks (9–12) and aggregate averages. 8-task baseline (米黄) vs Stationary co-training (浅紫) vs HuMI co-training (深紫) vs 12-task oracle (金). 在 4 个 held-out 任务上的协同训练结果。注意 Pouring（任务12，需要新动作"倒"）：Stationary 补到 80%，而 HuMI 只有 15%——HuMI 补不了新动作。两种协同都不回退原 8 个训练任务（Tasks 1–8 avg 都 ~87%）。

Stationary 站立遥操作：新语义 + 新动作都能补。它把 held-out 4 任务的平均进度从 33% 拉到 87%，逼近 12-task oracle 的 94%，而且不回退原 8 个训练任务。任务 9–11 只是复用已有动作、换了新物体/新指令——站立数据提供了新语义（新物体识别、新指令 grounding）；任务 12 Pouring 需要 8 个训练任务里根本没有的"倒"这个新动作，站立数据也补上了（80%）。

HuMI 机器人无关数据：只补新语义、补不了新动作。在复用动作的任务 9–11 上，HuMI 和站立数据打平（grounding 新物体/指令没问题）；但在需要新动作的 Pouring 上，HuMI 只有 15%、失败。作者归因于人-机之间的 gap：即使离线 IK 重定向过，纯人手演示的轨迹和真机遥操作出来的还是不一样（相机是 RealSense vs 矫正后的 GoPro 鱼眼，夹爪是自适应平行爪 vs 刚性手持爪），当前数据规模下 HuMI 主要在监督语义、而非动作。代价是它只花站立遥操作约一半的人力时间。

硬件、鱼眼主视角、开源数据 & 系统级对标

Fig 9 / 10 · p.23 Left: Humanoid robot hardware — Unitree G1 with a head-mounted Unitree SV1-25 stereo fisheye camera and two wrist RealSense D405. Right: HuMI hardware — handheld UMI grippers with GoPro cameras + HTC VIVE trackers. 左：人形机器人硬件——Unitree G1 + 头部 SV1-25 立体鱼眼 + 双腕 RealSense D405。右：HuMI 采集硬件——手持 UMI 夹爪(GoPro) + VIVE tracker。

开源了什么（可直接复用的数据）

论文摘要明确："Our code, training data, and model checkpoints are available."——代码 + 训练数据 + 模型 checkpoint 全开（openhlm-project.github.io）。这批全关节、含全身 loco-manipulation 的真机数据（已开放 500 GB+），格式就是 §3.1 那套 32 维关节 + 双腕/头视角，可直接拿来做 co-training 数据或预训练素材。训练成本参考：4×A800、约 24 小时、30k 步、batch 128、action horizon 50、224×224；推理时生成 50 步 action chunk @ 30Hz，每次执行 25 步再重推（约 5/6 秒一次）。

实验 #13 · 系统级对标长时序任务（Table 2）

压轴：一个跨越机器人大垂直工作空间的长时序语言任务（走到矮咖啡桌右手拿水果1、走到中桌左手拿水果2、走到高架分别放进容器；水果从 5 选 2，共 20 种有序组合）。对标两个 SOTA 人形 VLA：

OpenHLM 用不到一半的演示时长（1.14h vs 2.70h）反超两个 SOTA 30+ 分，且逼近自己的 teleop 上界（97.5%）10 分以内。两个 baseline 都抓取弱、执行刻板臂轨迹、不跟随语言指定的目标水果——而它们预训练里都混了 G1 人形数据。再次印证 §4 那句话：混人形数据进预训练不够，配方细节才是关键。

工程借鉴清单