芯耀
与非AI
385
转载自公众号：敢敢AUTOHUB
0. 简介
Hydra-0 面向机器人操作中的视频预测、策略评估与跨平台控制，处理的核心矛盾是：关节角、末端位姿等动作坐标依赖具体机器人，来自人手、单臂、双臂和手持夹爪的视频很难放进同一个世界模型。论文把可执行动作通过机器人几何、相机标定和物理仿真投影为图像平面上的 action flow，再沿轨迹传播首帧视觉特征，让 Cosmos 2.5 或 Wan2.2 预测动作后果。公开结果显示，最佳配置的机器人运动误差比动作条件基线低 90.4%，物体运动误差低 60.2%，RoboLab 回放成功率与参考成功率的 Pearson 相关系数为 0.96。下面从表示、训练、推理和逆控制四条线，解释这套系统为什么能把异构机器人数据接到同一条视觉接口上。
1. 研究问题与方法缺口
在传统动作条件视频模型里，动作通常写成关节位置、关节增量或末端执行器的六维位姿。这样的表示对控制器很方便，却没有直接告诉视频模型“画面里的哪一片像素将怎样移动”。同样的末端位姿变化，放到不同连杆长度、关节限制和相机位置的机器人上，会对应完全不同的可见轨迹；人手演示更没有关节控制量可供对齐。核心问题在于，模型被迫同时学习机器人运动学、相机成像和物体动力学，数据一换平台就容易失效。
Hydra-0 的选择是把动作转换成相机平面轨迹。训练时，视频跟踪器从真实片段恢复机器人或人手的可见点流；部署时，Isaac Lab 执行候选动作，利用机器人表面点、连杆变换和相机内外参生成同样格式的流。这样，模型接收的不是“Franka 的第 4 个关节转多少度”，而是“图像中这一组可见点从这里移动到那里”。动作流是跨具身共享的视觉中间层，它把平台差异留在流的生成器和最终 action head 中。
直觉理解：把不同车辆的油门、方向盘角度，统一翻译成道路画面中车身边缘的移动轨迹。车辆仍然不同，但预测“画面会怎样变化”时，视觉坐标比机械坐标更容易共享。
2. Hydra-0 的整体框架
2.1 输入、潜变量与输出
设初始 RGB 观测为 ，机器人执行动作序列为 。编码器把第一帧变成空间 latent ，动作序列经过运动学和投影得到 action flow ，动力学模型在 latent 空间预测未来状态，最后由视频解码器输出未来帧。关键不对称在于，模型主体只负责视觉动力学，具体机器人负责把动作变成可见流，action head 负责把逆向 latent 再翻译回目标机器人动作。
其中 是预测 horizon， 同时包含点轨迹和可见性。模型学习的是动作带来的视觉后果，而不是某个机器人本体的控制语法；这也是它能够吸收人手和多种机械臂数据的前提。进一步看，编码器与解码器仍沿用视频基础模型的视觉空间，新增的 action flow 只改变条件通路，因此模型不必为每种机器人重建一套完整生成架构。
2.2 前向和逆向两种工作模式
前向模式输入 embodiment flow，回答“这串可执行动作会让场景怎样变化”，适合生成 rollout 和 open-loop 策略评估。逆向模式输入 desired object flow，回答“要让物体沿这条轨迹运动，机器人可能怎样运动”，再由 target-embodiment action head 输出执行指令。两者共用同一视觉动力学空间，区别只在流的语义来源和输出端是否接动作读出模块。
难点提示（共享接口）：同一张地图既能用于导航，也能反过来规划路线。前向模式像沿已知路线开车观察结果，逆向模式像给出终点附近的脚印再推测车辆应该怎么走；共享地图不等于共享车辆控制器。
2.3 训练语料的覆盖范围
论文把 DROID、ABC-130k、MolmoAct2、EgoDex、Deform360、XVLA-Soft-Fold 和 H1-Fold-Clothes 组合成七源语料，过滤后约有 178,187 个 episode、1,565,634 个窗口和 2,201.7 小时视频。窗口统一为 480p、16 fps、81 帧，主要保留布料、绳索、线缆、包袋和纸张等可变形物体交互。这样的数据构成让模型看到同一物理现象的多种执行方式，也让“动作流”不再只对应一种机械结构。
3. action flow 的几何构建
3.1 几何感知路径
在有 URDF、机器人状态和相机标定的场景中，系统先在初始观测可见的机器人表面采样三维点。第 个点属于连杆 ，其局部坐标为 ；控制器和 Isaac Lab 物理仿真产生每个时刻的构型 ，连杆变换将点传播到世界坐标，再由相机外参 和内参 投影到像素坐标。只有深度为正、落在画面边界内且通过深度缓冲检查的点才保留为可见轨迹。
这里 表示透视除法， 是可见性。深度缓冲不是装饰步骤，而是把自遮挡和相机背后的点从条件中剔除；否则模型会被要求预测画面中根本看不见的“幽灵轨迹”。这里的关键是让二维条件与最终 RGB 观测严格对齐，三维点在运动学上有效，并不代表它在当前相机中一定构成可监督的视觉证据。
3.2 依据公式实现投影
下面的教学代码把批量三维点投影到图像平面，并返回有效掩码。它省略了真实仿真器接口，但保留了部署时最关键的张量关系：点先经过连杆和相机变换，再做透视投影，最后检查深度和边界。换句话说，这段实现不是视频光流估计器，而是把控制器可执行的三维运动确定性地翻译为二维观测条件。
# geometry/action_flow_projection.py (教学性复现代码)
import torch
def project_surface_points(points_link, link_T_world, cam_T_world, K, h, w):
"""points_link: [N,4], link_T_world: [N,4,4]"""
p_world = torch.bmm(link_T_world, points_link[..., None]).squeeze(-1)
p_cam = cam_T_world @ p_world.T
z = p_cam[2].clamp_min(1e-6)
uvw = K @ p_cam[:3]
uv = (uvw[:2] / z).T
visible = (p_cam[2] > 0)
visible &= (uv[:, 0] >= 0) & (uv[:, 0] < w)
visible &= (uv[:, 1] >= 0) & (uv[:, 1] < h)
return uv, visible代码中的 visible 只是第一层筛选，实际系统还要和渲染深度缓冲比较，论文附录给出的邻域容差为约 1.2 cm。工程上，标定误差会扰动二维条件但不改变目标视频；当误差大到让轨迹落在错误物体上，模型就会把错误对应关系当成动力学输入，因此相机标定质量直接影响部署上限。
3.3 仅视频路径
大规模互联网式交互视频往往没有 URDF、关节状态或相机内参。Hydra-0 使用 AllTracker 在窗口内查询密集点轨迹，再用机器人或人手掩码、物体掩码把轨迹分组。DROID 等数据缺少可靠的物体掩码时，系统仍然可以只利用 embodiment 轨迹学习前向动力学。这里要厘清的是，视频跟踪只负责训练条件恢复；部署时，候选机器人动作对应的流必须因果地产生，不能偷看未来真实视频。
4. 从稀疏轨迹到视频条件
4.1 轨迹在 latent 网格中的聚合
视频模型的 latent 帧数通常比原始视频帧数少，比如 81 帧视频在 latent 里可能只有十几帧。如果一条轨迹想从第一帧一路走到最后，就必须先想清楚：它对应 latent 里的哪一帧？Hydra-0 的做法是时间池化——一个 latent 时间片覆盖多帧轨迹，只要这个窗口里有任何一帧能看见该轨迹，就认定它在窗口内可见，目标位置取所有可见位置的平均值。代价是丢掉一点时间上的精细度，换来的是每个像素轨迹不必全部送进昂贵的 Transformer，这对机器人预测的延迟是实打实的收益。
4.2 高斯传播与存在门
有了轨迹位置，下一步是把"轨迹上该有什么内容"喂给模型。每条轨迹从首帧 latent 特征图上按双线性采样取出自己的源特征 ，再沿着未来位置铺开，铺开的权重按到目标位置的高斯距离衰减。每个目标网格只收权重最大的两条轨迹，传播特征不做 softmax 归一化，而是直接把权重和裁剪到 ，形成一个 presence gate——它告诉主干网络：哪些位置明确有运动条件约束，哪些位置只是模型自己脑补出来的。
这里的关键是，特征和门控各管一件事：特征负责说"这片内容是从哪条轨迹带来的"，门控负责说"这里到底有没有轨迹证据"。两者分开以后，模型不需要把"没有轨迹"理解成"特征值恰好是零"——那是两种完全不同的情况，混在一起会让训练信号变得很脏。
直觉理解：像把几支荧光笔沿着路线拖过地图。颜色表示“这片内容从哪里被带来”，透明度表示“路线证据有多强”；没有轨迹覆盖的区域仍由视频模型自己的物理先验补全。
4.3 运动条件如何注入 DiT
得到 之后，问题变成怎么塞进不同的视频主干。Cosmos 2.5 把 16 个传播特征通道加上 1 个门控通道，经过独立的 patch embedding 加到噪声视频 token 上；Wan2.2 I2V 把传播特征和 4 个 mask 通道接进它原生就有的视觉条件；TI2V-5B 则是拼接 49 通道的侧输入，再把 DiT 的输入投影加宽。三个模型共享同一套轨迹采样和聚合逻辑，只有最外层的适配器不同——这说明 action flow 是一个可移植的 conditioning 接口，不是某个主干的专用层。换主干不用重写条件通路，这层抽象正是跨平台训练能成立的原因。
4.4 教学性特征传播代码
下面的代码展示 Top-K 高斯传播的核心计算。它没有实现分布式训练、VAE 编码和 DiT patch embedding，但可以用小尺寸张量验证“轨迹位置、源特征、存在门”三者怎样合成运动条件。这里值得观察 topk 的维度：竞争发生在轨迹轴，而不是时间或通道轴，因此每个时空网格只接收局部最相关的轨迹贡献。
# models/propagate_flow.py (教学性复现代码)
def propagate_features(src_feat, xy0, xyt, vis0, vist, beta=220.0, topk=2):
# src_feat: [N,C], xyt: [N,T,2], grid: [T,H,W,2] in normalized coordinates
T, H, W = xyt.shape[1], 32, 52
yy, xx = torch.meshgrid(torch.linspace(-1, 1, H),
torch.linspace(-1, 1, W), indexing="ij")
grid = torch.stack((xx, yy), dim=-1).to(xyt.device)
delta = grid[None, None] - xyt.permute(0, 1, 2).reshape(-1, T, 1, 1, 2)
weight = torch.exp(-beta * (delta.square().sum(-1)))
weight = weight * vis0[:, None, None, None] * vist[:, :, None, None]
value, idx = weight.topk(topk, dim=0)
feat = (value[..., None] * src_feat[idx]).sum(dim=0)
gate = value.sum(dim=0).clamp(0, 1)
return feat, gate5. 训练目标与条件采样
5.1 Flow Matching 目标
视频主干使用预训练的图像和文本上下文 ，对目标视频 latent 加噪后预测 flow-matching 速度。训练样本中的 可以来自机器人元数据，也可以来自跟踪和掩码；模型本身不需要知道这些轨迹究竟由哪种 embodiment 产生。这里要厘清的是，式中的 flow matching 指扩散模型在噪声路径上的速度学习目标，与作为动作条件的二维 action flow 名称相近，但承担的数学角色并不相同。
冻结主干权重，只训练 patch embedding 和 rank-64 LoRA，既减少显存和训练成本，也保留 Cosmos 或 Wan 原有的视频外观先验。LoRA 在这里的作用不是把机器人知识全部塞进一个小模块，而是让预训练视频动力学学会读取新的视觉动作通道。进一步看，论文仍开放 DiT patch embedding，是因为输入通道结构已经变化；若只训练注意力 LoRA 而不适配入口投影，新加入的运动条件很难与原有 token 落到一致表征空间。
5.2 None、Embodiment、Object、All
论文采用四种条件模式，默认概率为 None 0.05、Embodiment 0.40、Object 0.40、All 0.15。Embodiment 主要选择机器人、夹爪或人手轨迹；Object 选择被操纵物体的未来流；All 从多类轨迹并集中抽样；None 则是条件 dropout。缺少某类标注时，系统移除该模式并重新归一化概率，避免数据质量差异变成训练崩溃的来源。
5.3 采样逻辑代码
这段代码把“轨迹池不可用时重归一化”的论文细节写成可读形式。真实训练还需要按数据源覆盖相机视角和窗口长度，但这个逻辑解释了为什么同一个模型可以同时接收稀疏 embodiment flow 与 object flow。进一步看，采样模式只决定哪些轨迹填入公共运动张量，并没有额外引入表示模式的可学习 token，这迫使主干从轨迹本身理解条件语义。
# training/sample_condition.py (教学性复现代码)
def sample_mode(pools, probs=(0.05, 0.40, 0.40, 0.15), rng=None):
names = ["none", "embodiment", "object", "all"]
valid = [name for name in names if name == "none" or len(pools.get(name, [])) > 0]
weights = torch.tensor([probs[names.index(n)] for n in valid], dtype=torch.float32)
weights = weights / weights.sum()
mode = valid[torch.multinomial(weights, 1, generator=rng).item()]
if mode == "none":
return mode, []
count = 128 if mode != "all" else 1024
tracks = pools[mode]
idx = torch.randperm(len(tracks), generator=rng)[:min(len(tracks), count)]
return mode, [tracks[i] for i in idx]工程价值：这像一间有四个入口的实验室，某个入口今天没有合格样本，就把名额分给其他入口，而不是让整批实验停摆。条件 dropout 还让模型保留无流预测能力，方便处理不完整标注。
6. 因果 rollout 与推理加速
6.1 从双向窗口到时间块
一次性双向去噪需要提前知道完整 horizon，机器人在线决策却只能看到当前及过去。Hydra-0 借鉴 LongLive-2.0，把 latent 序列切成时间块 ，先生成第一块，再把干净生成结果作为后续块的历史上下文。动作流在完整窗口坐标中只计算一次，之后按绝对偏移切片，避免每个块重新把轨迹锚到左上角。
6.2 KV cache 和少步蒸馏
KV cache 保存已经生成块的注意力键值，后续块无需重复计算整段历史。随后用 DMD2 训练四步学生模型，把教师模型每块 50 步左右的去噪压缩到 4 步。论文在单张 80GB H100、生成 81 帧的条件下报告：双向教师 3.87 FPS，自回归教师 6.49 FPS，少步学生 61.98 FPS，生成阶段约 16 倍加速。
难点提示（因果缓存）：像写长篇小说时把已经定稿的章节放进书架，写下一章只查书架索引，不重新誊写整本书。缓存减少的是重复注意力计算，不会自动修复错误动作流或错误标定。
6.3 rollout 伪实现
下面代码强调块边界和缓存的关系。实际模型还需实现 causal mask、噪声调度和 DMD2 训练，但这段结构足以说明推理时为什么不能把每一块的轨迹重新归一化。核心问题在于，同一条物理轨迹跨越多个块时仍应共享绝对时间坐标；若每块重新定原点，连续运动会在边界产生不真实的跳变。
# inference/causal_rollout.py (教学性复现代码)
def rollout(model, init_latent, motion_cond, chunks, denoise_steps=4):
history, cache, outputs = init_latent, None, []
for start, end in chunks:
cond = motion_cond[:, start:end] # absolute offset slice
noisy = model.sample_noise_like(cond)
for _ in range(denoise_steps):
noisy, cache = model.denoise_block(
noisy, history=history, cond=cond, kv_cache=cache
)
outputs.append(noisy)
history = torch.cat([history, noisy], dim=1)
return torch.cat(outputs, dim=1)7. 正向模式：把世界模型用于策略评估
7.1 Achieved-trajectory replay
open-loop 评估的做法很直接：从每条真实 rollout 的第一帧出发，把录好的 gripper trajectory 转成 action flow，固定住不再改，一次性生成未来整段视频。策略在整个过程中不会再去读生成帧，所以这里测的是世界模型能不能保留"动作之后发生了什么"，而不是策略和模型在闭环里互相纠正。正因为复现的是"实际发生的事"，成功和失败的轨迹都能拿来当训练样本——模型不需要把每个动作都改写成成功版本，如实重现就行。
7.2 RoboLab 结果如何解读
RoboLab 上评估了 5 个预训练策略、6 项任务，每个策略-任务配对跑 10 次 rollout，一共 300 个片段。结果上，生成成功率和参考成功率的 Pearson ，Spearman ，平均绝对误差 5.7 个百分点，5 个策略的相对排序也复现出来了。这说明 Hydra-0 更像一个用于相对比较的神经模拟器，而不是已经证明能替代真实机器人测试的完美仿真器——它能帮你判断"策略 A 大概率比策略 B 好"，但还不敢说"跑在模型里的成功率就是真机成功率"。
RoboLab 开环策略评估
7.3 评估代码的核心接口
为了让读者把论文实验和工程系统对应起来，下面给出一个最小评估接口。它把真实轨迹转换成流，调用 world model 生成视频，再交给独立的成功判别器；成功判别器可以是人工标注、视觉语言模型或任务专用检测器。这意味着 world model 与成功判定必须分开审计，否则生成质量误差和判别误差会混在同一个成功率数字里——数字好看，却不知道是哪一环在起作用。
# evaluation/open_loop.py (教学性复现代码)
def evaluate_rollout(world_model, first_frame, achieved_actions, camera, detector):
flow = camera.command_to_action_flow(achieved_actions)
generated = world_model.predict(first_frame, flow)
score = detector.success_probability(generated)
return {"flow": flow, "video": generated, "success": float(score)}8. 逆向模式：世界动作模型
8.1 desired object flow 作为任务意图
逆向实验有一个关键改动：不给模型 gripper flow，而是从留出的人类演示里提取物体本身的运动，作为 desired object flow。模型在"只看物体想怎么动"的条件下生成兼容的机器人运动 latent，action head 再从干净的 DiT token 特征里读出目标机器人的 action 和 state。训练数据来自成对的真实 rollout，样本里带失败也没关系，只要把实际机器人动作和产生它的观测对齐就行——模型学的不是"理想操作"，而是"观测和动作之间的对应关系"。
8.2 Action head 的读出方式
读出端的设计值得细看：每个 latent 帧的空间 token 先做均值池化，再做单查询注意力池化，拼起来过 LayerNorm 和两层 GELU MLP（隐藏宽度 1024），同时预测 action 和 state。动作、状态目标都做归一化并用 masked Huber 损失，动作的一阶差分再加一项 masked L1 平滑。action head 并没有从视频像素直接猜电机命令，而是读取已经编码了物体动力学的内部 token——换句话说，它翻译的是"场景里的物体打算怎么走"，而不是"画面里哪个像素对应哪个关节"。
8.3 从人类演示到机器人执行
论文用一个柔性管道弯曲的例子把整条链路串起来：人类视频提供物体流，Hydra-0 生成兼容的机器人运动，action head 输出目标平台的指令，真实机器人完成弯曲任务。需要说清楚的是，这目前只是概念验证——作者报告的是厘米级抓取误差，并推测深度和接触状态歧义是主要原因。"任务意图迁移成功"和"高精度通用控制已经解决"是两个层次，这篇文章证明的是前者，后者仍然留白。
物体流条件下的真实机器人执行
9. 总结
Hydra-0 的核心贡献就是把异构机器人的可执行动作投影为共享的像素运动，让一个视频世界模型既能预测动作后果、评估策略，又能从人类示范的物体运动反推出兼容的机器人动作。 它没有消除机器人控制中的几何、接触和安全问题，却提供了一条清晰的工程分工：机器人和仿真负责产生可信 action flow，视频模型负责学习跨具身的视觉动力学，action head 负责恢复目标平台的执行接口。
