地平线 HoloMotion 深度拆解:4 亿参数“机器人小脑“大模型,如何让机器人学会跳舞、爬行与踢腿?

一九九一晚春

178人浏览 · 2026-09-09 10:14:18

一九九一晚春 · 2026-09-09 10:14:18 发布

从 MoE-Transformer 架构、参考条件路由、KV-Cache 实时推理,到 2000+ 小时异构运动数据、HoloSMPL / HoloRetarget 数据流水线、PPO 训练与真机部署——一篇博客把地平线开源的人形机器人全身运控基础模型讲透。

一、介绍:这是给机器人装"小脑"的开源基座

如果你关注具身智能圈,2025 年 12 月地平线首届技术生态大会(Horizon Together 2025)上有一个很醒目的发布:地平线把"机器人大脑"和"机器人小脑"两个开源模型一起端了出来。大脑是负责感知、理解、规划与灵巧操作的 HoloBrain VLA 基座模型;小脑就是本文主角 —— HoloMotion,一个面向**人形机器人全身运动控制(Whole-Body Control)**的开源基础模型。

为什么要区分"大脑"和"小脑"?这是地平线官方叙事里一个非常清晰的类比:

大脑:理解指令(“我渴了”)、规划任务序列、感知空间——对应视觉语言导航、灵巧操作。
小脑:把"意图"翻译成几十个关节上每毫秒都在变化的力矩/位置指令,维持平衡、跟踪动作、抵抗扰动——对应运动控制。

人形机器人要完成一个高动态的全身动作(比如跳舞、爬行、高踢腿),难点根本不在"动起来",而在:

几十个关节之间的协同——Unitree G1 有 29 个自由度,手脚躯干必须同步;
理解并跟随复杂的人体运动参考——尤其是从互联网视频里"看来的"动作;
在连续时序中保持稳定、自然、一致——不能抖、不能倒、不能像木偶。

传统做法是训练百万级、千万级参数的任务特化小模型,每个动作集一个策略,能跑但泛化差。HoloMotion 赌的是一条更大的路:把控制策略规模推到 4 亿(0.4B)参数级别,同时用 MoE 稀疏激活 + KV-Cache 把端侧推理压到约 300 FPS——既能装下更丰富的动作分布,又能满足真实机器人 50 Hz 以上的高频控制。

仓库与版本演进

仓库地址:github.com/HorizonRobotics/HoloMotion,Apache 2.0 协议,主分支 75+ commits,活跃度极高(截至 2026-08 仍在发版)。

版本	时间	核心变化
v1.2	2026.04	开放预训练 motion tracking / velocity tracking 模型,可直接部署
v1.3	2026.05	参数从 60M → 0.4B,数据从 80h → 2000+h,推理从 ~100 → ~300 FPS
v1.4	2026.07	引入 HoloRetarget(4090 上 3000+ FPS 生成训练数据、机器人端 300+ FPS 遥操作)与 HoloSMPL(支持 10+ 数据集/设备)
v1.4.1	2026.08	通用模块化 G1 支持:2 种头部 × 5 种 29-DoF 机身 × 7 种手,共 66 种组合,一个策略通吃,免去每种硬件单独训练

"4-Any"路线图:现在只是第一阶段

HoloMotion 的名字背后是一张野心不小的路线图,官方叫 Scales Toward 4-Any Humanoid Control:

阶段	目标	状态	含义
v1	Any Pose	✅ 完成	对多样化全身人体运动的鲁棒跟踪与模仿(imitation),即通用 motion tracking
v2	Any Command	🚀 下一步	语言/任务条件下的运动生成,目标导向与交互行为
v3	Any Embodiment	🧭 规划中	跨不同形态、运动学的人形机器人泛化
v4	Any Terrain	🧭 规划中	楼梯、坡道、复杂室内外地形适应

v1 完成意味着:给定一段"参考运动"(无论是离线 .npz 运动片段还是实时遥操作流),机器人要能以零样本迁移的方式,在真机上稳定跟出来。“Imitation Any Pose” 是整条路线的地基,也是本次开源全链路覆盖的能力。

二、原理:参考条件 MoE-Transformer,是怎么"看懂"动作并控制身体的?

2.1 系统级视角:一条从数据到真机的闭环

先把仓库的模块地图摆出来,后面所有源码拆解都挂在这张图上:

┌──────────────────────────────────────────────────────────────────────┐
│                      HoloMotion 端到端模块架构                          │
├──────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  DATA            ENVIRONMENT         TRAINING        EVALUATION        │
│  ┌──────────┐   ┌───────────────┐  ┌────────────┐  ┌───────────────┐  │
│  │ HoloSMPL │──▶│ Isaac Lab     │  │ PPO (seq)  │  │ IsaacLab      │  │
│  │ 多源数据  │   │ MuJoCo        │  │ 分布式训练  │  │ MuJoCo sim2sim│  │
│  │ 标准化    │   │ 仿真环境       │  │ MoE-TF策略  │  │ 指标+视频渲染  │  │
│  └──────────┘   └───────────────┘  └────────────┘  └───────────────┘  │
│        │                                                               │
│        ▼                                                               │
│  ┌──────────┐   HoloRetarget(GMR/GPU-IK)                                │
│  │ 人类运动  │──────────────────────────────▶  机器人 HDF5/NPZ          │
│  │ SMPL数据  │                                                          │
│  └──────────┘                                                          │
│                                                                        │
│  DEPLOYMENT                                                            │
│  ┌────────────────────────────────────────────────────────────┐        │
│  │ Unitree G1 29DoF + Jetson Orin,ROS2,Docker,ONNX Runtime    │        │
│  │ 双策略:Velocity Tracking(移动/安全)+ Motion Tracking(执行) │        │
│  └────────────────────────────────────────────────────────────┘        │
└──────────────────────────────────────────────────────────────────────┘

一句话串起来:HoloSMPL 把 VR/惯性/光学/视觉捕捉的异构数据统一成 SMPL 表示 → HoloRetarget 把"人体运动"重定向成"机器人参考轨迹" → 在 Isaac Lab 仿真里用序列级 PPO 训出一个 MoE-Transformer 策略 → 导出 ONNX → 跑在机器人机载 Orin 上实现离线动作回放与在线遥操作。

2.2 策略网络:decoder-only Transformer + 参考条件路由 MoE

核心策略在 holomotion/src/modules/network_modules.py,骨干类继承链是:

GroupedMoETransformerPolicy                       # 通用 MoE Transformer 解码器
└── ReferenceRoutedGroupedMoETransformerPolicy   # V1:扁平观测里抽 ref 特征喂 router
    └── ReferenceRoutedGroupedMoETransformerPolicyV2  # V2:显式拆分 state/ref_cur/ref_fut

架构上它是 decoder-only Transformer,带一堆现代大模型标配:RMSNorm、GQA(分组查询注意力)、QK-Norm、门控注意力(gated attention)、SwiGLU、Real-RoPE、SDPA Flash Attention、梯度 checkpointing。每个时间步的观测(含当前机器人状态 + 参考动作的当前帧)作为一个 token,通过因果注意力建模时序。

MoE 设计(0.4B 的秘密),配置在 holomotion/config/modules/motion_tracking/motion_tracking_tf-moe.yaml:

modules:
  actor:
    type: ReferenceRoutedGroupedMoETransformerPolicy
    num_fine_experts: 1024      # 1024 个细粒度专家
    num_shared_experts: 1       # 1 个共享专家(always-on)
    top_k: 2                    # 每个 token 只激活 2 个专家
    d_model: 512
    n_heads: 8
    n_kv_heads: 4
    n_layers: 1
    dense_layer_at_first: false
    ff_mult: 0.5
    max_ctx_len: 32             # KV-Cache 环形缓冲长度(部署时)

总参数约 4 亿,但每步实际激活仅约 7M。为什么能这样?因为 1024 个专家中每个 token 只挑 Top-2(外加 1 个共享专家),FFN 的计算量 = 激活专家的算量,而不是全部 1024 个。这就是"大容量模型 + 稀疏激活"的老配方(Mixtral 同款思路)在机器人控制上的应用:容量决定"会多少动作",激活量决定"跑多快"。

2.3 参考条件路由:为什么路由输入必须"只看参考,不看机器人状态"?

这是整篇技术报告里最有意思的一个设计决策。一般 MoE 的路由器会拿全部观测(包括机器人 proprioception)来做专家选择。但 HoloMotion 刻意把路由通路和状态通路分开:

直接把本体感受观测与参考运动混合用于路由,会导致严重的 sim-to-real 性能退化。路由决策会显著影响策略行为;当路由器对底层动态变化(如关节速度抖动)敏感时,仿真与现实的不可避免差异会被放大成"路由振荡",最终破坏真机执行的稳定性。

所以路由器的输入被限制为纯参考运动项。代码里体现在两个层面:

V1 实现(扁平观测 + 特征下标抽取):

self.router_feature_indices = tuple(int(idx) for idx in router_feature_indices)
self.router_obs_embed = nn.Sequential(
    nn.Linear(self.router_input_dim, self.router_embed_mlp_hidden),
    nn.SiLU(),
    nn.Linear(self.router_embed_mlp_hidden, self.d_model),
)

def _compute_router_hidden(self, x):
    router_idx = self._router_feature_indices
    router_obs = torch.index_select(x, dim=x.ndim - 1, index=router_idx)
    return self.router_obs_embed(router_obs)   # 只吃 ref 项 → 路由 hidden

V1 通过 infer_router_feature_indices 自动把观测里所有 actor_ref_* 前缀的特征挑出来作为路由依据。actor_ref_ 就是路由与状态的"楚河汉界"。

**V2 实现(显式三维拆分)**做得更彻底,把观测切为三块并各自校验维度守恒:

self.state_obs_input_dim = state_obs_input_dim     # 纯机器人状态(actor 输入)
self.ref_cur_token_dim   = ref_cur_token_dim       # 当前帧参考(router + 状态)
self.ref_fut_token_dim   = ref_fut_token_dim       # 未来参考(每步维度)
self.ref_fut_seq_len     = ref_fut_seq_len         # 未来参考帧数
# 全维度守恒: full_input_dim = state_obs + ref_cur_token + fut_seq_len*fut_token
if (end - start) != self.ref_fut_seq_len * dim:
    raise ValueError("Future ref slice span must equal ref_fut_seq_len * dim, ...")

路由隐藏状态随后作为 router_x 传入每一个 MoE 层:

h = layer(h, cos, sin, mask, memory, memory_mask, router_x=layer_router_h)

配置里 router_obs_terms 清单也印证了这个哲学——只允许参考/指令类项进入路由器:

router_obs_terms:
  - unified/actor_ref_gravity_projection_cur
  - unified/actor_ref_dof_pos_cur
  - unified/actor_ref_dof_pos_fut
  - unified/actor_ref_root_height_fut
  # ... 全部是 ref_* 项

路由器"只看参考"带来的好处是双重的:(1) 专家分配对 sim-to-real 的状态差异不敏感;(2) 同一段参考运动在仿真与真机上会触发完全相同的路由决策,天然对齐。

2.4 参考运动的两种注入方式:当前帧路由 + 未来帧条件

策略输入观测(obs_schema 里 flattened_obs)按帧组织,包含:

机器人本体感知:投影重力、本体线/角速度、关节位置/速度、上一时刻动作(last action)、与参考的偏航误差等;
当前帧参考:actor_ref_gravity_projection_cur、actor_ref_dof_pos_cur、actor_ref_root_height_cur 等 —— 同时被 router 消费;

未来参考帧则走 flattened_obs_fut(seq_len = obs.n_fut_frames,如 32 帧),由专门编码器处理——PPOCondTFActor 用 future_obs_embed + future_pos_embed 把未来 token 序列投影后,以交叉注意力(cross-attention)或拼接方式注入,让策略"预知"接下来一小段动作趋势(就像你跳舞时知道下一个八拍要迈哪只脚)。V2 里还有一个 ReferenceMotionConvRouterEncoder,用 Conv1d(kernel=3)+ SiLU + AdaptiveAvgPool 对参考序列做时序卷积编码,作为未来参考的压缩表征:

x = seq.transpose(1, 2)          # [B, D, T]
x = self.temporal_trunk(x)       # Conv1d + SiLU × conv_layers
x = self.pool(x).squeeze(-1)     # AdaptiveAvgPool1d(1)
return self.out_proj(x)

2.5 KV-Cache 环形缓冲:把 O(C²) 降到 O© 的关键

真实机器人控制是单步高频推理:每 3.3ms 左右就要出一个动作,不可能每步都把 32 帧历史重新算一遍注意力。所以策略在训练和部署里都维护每环境(per-environment)的 KV-Cache:

# True per-layer KV cache for single-step inference.
# K/V shapes: [B, n_layers, max_ctx_len, n_kv_heads, head_dim]
self._k_cache: torch.Tensor | None = None
self._v_cache: torch.Tensor | None = None
self._kv_cache_len: torch.Tensor | None = None      # [B] 每环境已缓存长度
self._kv_cache_write_idx: torch.Tensor | None = None  # [B] 环形写指针
self._kv_cache_abs_pos: torch.Tensor | None = None    # [B] 绝对位置(RoPE 用)

单步推理时只算新 token,通过 forward_single_token 写入缓存并 attend 已缓存上下文,复杂度从 O(C²) 降到 O©。环形缓冲的核心逻辑:

max_len = int(self.max_ctx_len)               # 默认 64(部署配置为 32)
new_len = torch.clamp(cache_len + 1, max=max_len)
self._kv_cache_len = new_len
self._kv_cache_write_idx = (insert_pos + 1) % max_len   # ← 环形写指针回绕

# RoPE 位置用"每环境绝对位置",环形覆盖不导致位置回退
pos = self._kv_cache_abs_pos
self._kv_cache_abs_pos = pos + 1
pos_ids = pos.unsqueeze(1)
cos, sin = self.get_cos_sin(h, pos_ids)

两个细节很见功力:

RoPE 位置不回绕:虽然 KV 缓冲区是环形的(旧 token 被覆盖),但绝对位置持续累加,保证注意力里的相对位置编码始终正确;
按环境清缓存:回合终止时 clear_env_cache(env_ids) 清掉对应环境的 KV/长度/写指针/绝对位置,下一回合从空上下文开始——避免上一回合的"记忆"污染新回合。

技术报告称,KV-Cache 在嵌入式部署配置下让策略评估延迟降低约 4×;配合稀疏 MoE,最终实现机器人端 200–300 Hz 的推理频率,远超 50 Hz 控制环需求。

2.6 训练:序列级 PPO(Sequence-Level Policy Optimization)

策略用 PPO 强化学习训练,reward 是密集的跟踪奖励(关键体位置/朝向/速度、根速度、五点局部位置 + 动作频率、关节加速度、关节限位、非期望接触惩罚)。真正值得一提的是训练效率优化:holomotion/src/algo/ppo_tf.py 里的 PPOTF 类把标准 PPO 从"逐帧"改造成"轨迹级序列"。

标准 PPO 会把 rollout 展平、随机打乱单步样本。但 Transformer 策略的一个 step 的 logp 依赖整个观测前缀,逐帧重算导致每步 O© 的冗余计算。PPOTF 的做法:

数据保持 [envs, T, …] 序列组织,不展平;
mini-batch 只打乱环境维,时间维严格保留;
调用 actor 的 sequence_logp 模式,一次 batched forward 算完整段轨迹所有时间步的 logp:

actor_out = self.actor(
    obs_b, actions=actions_b,
    mode="sequence_logp",          # ← 序列级前向,一次算整段
    attn_mask=attn_mask_b,         # [B, T, T]
    update_obs_norm=False,
)

注意力掩码必须同时满足"因果"与"同 episode"两个约束:

def _build_episode_causal_mask(dones_seq):
    dones = dones_seq.squeeze(-1).to(torch.long)
    seg = torch.cumsum(dones, dim=1) - dones   # episode 段编号
    same = seg[:, :, None] == seg[:, None, :]  # 只能看到同一 episode
    causal = torch.tril(torch.ones(t, t, dtype=torch.bool, device=device))
    return same & causal

也就是说,如果某个环境在 rollout 中途"摔倒重置"了,段边界之后的 token 不允许 attend 段边界之前的 token——这正是 Transformer 处理 RL 重置的标准姿势,也是很多移植 Transformer 做 RL 的人最容易踩的坑。这个序列级优化把训练吞吐提升了约 22×(技术报告数字),让 2000 小时数据的训练在 64×RTX 5090 上约 6 天(9200 GPU 小时)完成。

除了 PPO 主损失,actor 还挂了几个辅助自监督头(技术报告给出权重):速度预测(NLL, λ=10⁻²)、关键体接触状态(BCE, λ=10⁻²)、参考关键体位置(MSE, λ=10⁻¹)、机器人关键体位置(MSE, λ=10⁻¹)、死专家边际正则化(λ=10⁻¹)。代码里对应 aux_state_pred(从 pre-MoE hidden 预测)、aux_router_command_recon/aux_router_future_recon(用路由分布反推指令/未来)。有意思的是路由分布竟然能用来重建指令——说明路由器学到了有语义的参考动作表征,而不只是算力调度器。

2.7 观测噪声与价值网络:不对称的 actor/critic

标准 PPO 里的"sim-to-real 最后一公里"处理:actor 观测加噪声(domain randomization、观测噪声),critic 则吃干净观测 + 特权信息(锚点姿态差异、精确连杆状态),用来估计更准确的价值。代码层面 actor/critic 是两个独立网络——actor 是 MoE-Transformer,obs_embed_mlp_hidden: 2048;critic 是 4 层 2048 宽 MLP + RMSNorm,观测 schema 完全独立(critic_ref_*、critic_global_anchor_diff 等特权项)。

三、数据流水线源码拆解:HoloSMPL 与 HoloRetarget

3.1 HoloSMPL:十几种数据源,统一成一种"人形语言"

数据是这次开源的另一半灵魂。HoloMotion-1 的训练语料超过 2000 小时,构成如下:

数据组件	来源	角色
视频重建运动	MotionMillion(互联网视频恢复)	规模与多样性主力
精选 MoCap	AMASS(40+ h)、LAFAN1(4.6 h)	干净高保真监督
内部遥操作	PICO 4 Ultra VR/MR	低成本部署导向覆盖
内部遥操作	Noitom PN Link 惯性动捕	接触/操作类动作

问题是这些源的天生"格式"完全不同:光学动捕给的是标记点轨迹、VR 给的是头显+手柄 6DoF、惯性给的是 IMU 积分姿态、视频重建给的是 SMPL 参数。holosmpl/ 模块干的活就是把它们全部规整成 project-standard 的 SMPL 表示(canonical → formal 两级):

raw dataset / device export
        │  python -m holosmpl convert --source pico4_ultra_enterprise ...
        ▼
canonical/   # SMPL/SMPL-like: root_orient[T,3] pose_body[T,63/69] trans[T,3] betas[B]
formal_npz/  # 训练侧稳定接口:
             #   human_pose_aa[T,72] human_root_trans[T,3] human_shape_beta[B]
             #   human_root_height[T,1] human_gravity_projection[T,3] metadata
formal_h5/   # 打包后的分片
reports/     # 校验报告

仓库把可支持的数据集/设备做成注册表 + README 的插件结构(supported_datasets/、supported_devices/、sources.py 分发、converters/ 放解析逻辑),加一个新数据源只需:写 README → 写 converter → 在 registry 注册 SOURCE_CONFIGS["xxx"] → python -m holosmpl list-sources 验证。设计上对社区扩展非常友好。

3.2 HoloRetarget:GPU IK 求解器,为什么能到 3000+ FPS?

数据统一成 SMPL 之后,还得把"人的动作"变成"G1 机器人能执行的 29 关节角度"。这一步传统做法是离线逐帧优化(慢),HoloMotion 把它做成了基于 Newton/Warp 的 GPU 实时 IK 求解器 holoretarget/,输出固定为 reference_qpos[36] = root_pos[3] + root_quat_wxyz[4] + dof_pos[29]。

核心类 HoloNewtonG1Retargeter 用了整整一整套 GPU 工程优化组合拳:

Newton GPU IK + 解析雅可比:ik.IKSolver(model, n_problems=1, objectives=..., jacobian_mode=ANALYTIC),IK 目标由"位置目标 + 朝向目标 + 软关节限位"组成(IKObjectivePosition / IKObjectiveRotation / IKObjectiveJointLimit),每条目标带 link 与权重;
CUDA Graph 录制:把稳态求解循环录成 CUDA Graph,运行时 wp.capture_launch 一次发射,消除 Python/驱动开销;
批量 H2D 拷贝:wp_memcpy_batch 一次 C 调用推送所有 IK 目标,而不是逐目标 Python 循环;
pinned host memory:qpos 输出走 pinned=True 缓冲 + wp.copy + wp.synchronize;
fused 直接路径:输入直接吃 XRoboToolkit/Pico 的 body_poses(24,7)(24 个身体节点,前 3 位置 + Unity 坐标 xyzw 四元数),跳过中转数组;Unity→机器人坐标系旋转用四元数预乘就地完成;
连续化后处理:把 IK 输出投影到关节等效限位分支(q + 2πk),并限制单帧最大关节步长(max_joint_step=0.1 rad),防止相邻帧跳变;root 四元数做符号对齐(避免 q 与 -q 的跳变)。

值得留意的是遥操作路径不需要 SMPL 模型——HoloRetargeter 直接消费 PICO 的 24 关节全局姿态;SMPL 模型只在把 SMPL 家族训练数据转成 24 关节表示时才需要(放在 gitignore 的 thirdparties/smpl_models/,避免把许可模型提交进仓库,这个合规细节很到位)。

也正是这套优化,让 HoloRetarget 在 RTX 4090 上以 3000+ FPS 生成训练数据、在机器人机载 Orin 上以 300+ FPS 做遥操作重定向,彻底把"重定向"从数据准备期的离线负担变成了可实时运行的部署组件。

3.3 训练数据的最终形态:机器人 HDF5

离线重定向后打包成 HDF5 v2 数据库(供训练与评估),每个 clip 只存非派生参考:

ref_root_pos [T,3]
ref_root_rot [T,4]   # xyzw 顺序
ref_dof_pos  [T,29]

关节速度、根速度、投影重力、局部坐标系速度等派生量在训练/部署时由共享的 motion-tracking observation 模块现算——一份存储、多处消费,避免数据冗余与不一致。

四、环境搭建步骤流程(保姆级)

官方明确:训练侧用 Conda,部署侧只用 Docker。下面按官方文档整理。

4.1 训练环境(训练自己的策略时)

Step 1:装 Conda(国内用户建议先配 TUNA 清华镜像)。

Step 2:下载 SMPL/SMPLX 许可模型并解压

# 官网注册后下载 SMPL_python_v.1.1.0.zip 和 models_smplx_v1_1.zip
mkdir thirdparties/smpl_models
unzip thirdparties/SMPL_python_v.1.1.0.zip -d thirdparties/smpl_models/
unzip thirdparties/models_smplx_v1_1.zip -d thirdparties/smpl_models/

Step 3:初始化子模块(提供共享机器人网格与模块化 G1 组件包)

git lfs install
git submodule update --init --recursive
git -C thirdparties/HoloMotion_assets lfs pull   # 若 LFS 未随子模块拉取

Step 4:创建 Conda 环境

# CUDA 11.8 用户
conda env create -f environments/environment_train_isaaclab_cu118.yaml

# RTX 5090 等新卡用户:cu128 环境 + 项目验证过的 Torch 覆盖(必须分两步!)
conda env create -f environments/environment_train_isaaclab_cu128.yaml
conda run -n holomotion_train \
  python -m pip install -r environments/requirements_torch_cu128.txt

⚠️ 踩坑:cu128 栈用 Torch 2.9.1,而 Isaac Sim 5.0 硬性依赖 Torch 2.7.0,pip check 会报 3 个已知版本冲突——这是官方预期行为,不要画蛇添足去"修"它。

Step 5:以可编辑模式安装 smplx 并配置环境变量

cd thirdparties && conda activate holomotion_train && pip install -e ./smplx
source train.env     # 提供 shell 脚本定位训练环境的变量

⚠️ 项目不支持直接从 pyproject.toml 装运行时依赖;editable 安装只负责注册源码路径。

4.2 从零训练 motion tracking 策略

数据准备(HoloSMPL → HoloRetarget → HDF5)完成后:

# 1. 改配置:holomotion/config/training/motion_tracking/motion_tracking_v1_4_0.yaml
#    把 train_hdf5_roots 指向你自己的 HDF5,可配多数据集与采样比例
train_hdf5_roots:
  - { root: data/h5v2_datasets/AMASS_test, ratio: 1.0 }

# 2. 开始分布式训练(默认 CONFIG_NAME=motion_tracking_v1_4_0)
bash holomotion/scripts/training/train_motion_tracking.sh
# 自定义环境数与配置:
NUM_ENVS=2048 CONFIG_NAME=motion_tracking_v1_4_0 \
  bash holomotion/scripts/training/train_motion_tracking.sh

常用技巧(文档明示):

显存不够:调小 NUM_ENVS(会降低稳定性);
多开训练:显式加 --main_process_port=端口(不能是 0)避免 accelerate 端口冲突;
指定 GPU:改脚本里 export CUDA_VISIBLE_DEVICES="X";
调保存/日志频率:algo.config.save_interval=X、algo.config.log_interval=Y;
断点续训:Hydra override checkpoint=logs/<project>/<run>/model_X.pt;
checkpoint 默认落在 logs/<project_name>/<timestamp>-<experiment_name>/。

微调 v1.4.1 模块化 G1(生成 66 种确定性变体再统一微调):

python assets/robots/unitree/G1/modular/g1_urdf_composer.py generate-all \
  --output-dir assets/robots/unitree/G1/modular/generated/urdf

python holomotion/scripts/training/download_v1_4_checkpoint.py \
  HorizonRobotics/HoloMotion_models

CONFIG_NAME=motion_tracking_v1_4_1_universal_finetune \
  bash holomotion/scripts/training/finetune_motion_tracking_v1_4_0.sh

⚠️ 视频重建数据处理需要 GVHMR(独立环境);IsaacLab 场景创建卡住,多半是连不上 Nvidia 云资产——开代理重试。

4.3 评估

# 离线评估(IsaacLab + HDF5)
CKPT_PATH="logs/<project>/<run>/model_1000.pt" \
EVAL_H5_DATASET_PATH="['data/h5v2_datasets/lafan1']" \
  bash ./holomotion/scripts/evaluation/eval_motion_tracking.sh

# 量化指标 JSON
bash ./holomotion/scripts/evaluation/calc_offline_eval_metrics.sh

# MuJoCo 视频渲染(记着 +key_prefix="robot_")
bash ./holomotion/scripts/motion_retargeting/run_motion_viz_mujoco.sh

评估脚本会自动导出 ONNX 到 checkpoint 目录:

logs/<project_name>/<run_name>/
├── config.yaml
├── exported/model_10000.onnx
└── model_10000.pt

4.4 真机部署(零训练,直接跑)

硬件需求:Unitree G1 29-DoF(带 Jetson Orin)、JetPack 5.1 兼容的 NVIDIA 容器运行时;PICO 4 Ultra + XRoboToolkit 仅遥操作需要。开跑前拆掉灵巧手(29-DoF 配置 = 12 腿 + 3 腰 + 14 臂)。

首次配置 Docker NVIDIA runtime(/etc/docker/daemon.json 加 nvidia runtime,sudo systemctl restart docker;权限不够就 sudo usermod -aG docker $USER);
拉镜像并进容器:

docker pull horizonrobotics/holomotion:v1.4.1-orin-jp5.1-arm64
docker run --rm -it --runtime nvidia --gpus all --privileged \
  --network host --name holomotion_g1 --entrypoint bash \
  horizonrobotics/holomotion:v1.4.1-orin-jp5.1-arm64

按顺序验证:holomotion check(无动作校验,必须 PASS)→ holomotion offline(回放内置 qinghaiyao.npz 舞蹈)→ holomotion teleop(PICO 遥操作);

遥控器序列:A 进入策略/回默认位 → B 切换 motion tracking(离线片段或遥操作)→ Y 回到速度模式 → Select 急停。

跑自己的动作片段只需挂载目录并指定文件(要求六个 ref_* 数组、29-DoF/30-body 布局):

holomotion offline /data/your_motion.npz

遥操作链路(全程在机器人端,低延迟路径不经过工作站):

PICO/XRoboToolkit → Orin 上 HoloRetarget → observation → policy → robot

强烈建议的安全习惯:机器人悬吊/固定架测试、遥控器不离手、check 通过前绝不 offline/teleop、先离线后遥操作、异常立即停止。

五、效果对比:HoloMotion-1 到底强在哪?

5.1 数值对比(技术报告 vs 三个 SOTA 基线)

技术报告在多个未见过的运动基准上对比了 GMT、Any2Track、Sonic 三个系统(指标越小越好;SR 成功率越高越好):

方法	训练语料	时长	激活参数	总参数	E_mpkpe↓(mm)	E_mpjpe↓(rad)	E_vel↓(mm/帧)	SR↑
GMT	LAFAN1 & AMASS	30 h	2M	2M	484.05	0.1097	8.0	92.54%
Any2Track	LAFAN1	10 h	33M	33M	1200.96	0.1342	13.8	25.10%
Sonic	In-house	700 h	42M	42M	227.95	0.1069	5.4	95.58%
HoloMotion-1	视频重建+AMASS/LAFAN1+In-house	2000+ h	7M	400M	124.57	0.0979	3.9	97.55%

要点解读:

相对最强基线 Sonic,MPKPE(躯干+四肢位置误差)降低约 45%(227.95 → 124.57 mm),成功率 95.58% → 97.55%;
相对用公开数据训练的 GMT/Any2Track 优势更大(误差降低 3–10 倍);
关键洞察:**Any2Track 虽然也是"大模型+多样数据",但因数据仅 10 h 且含噪声视频重建,成功率只有 25.1%——说明规模必须和数据质量/时长配合,才不是负资产;
"4 亿参数"并没有带来推理负担:激活参数仅 7M,是全场最小的激活模型之一(仅大于 2M 的 GMT)。

5.2 推理性能

优化	效果
KV-Cache 增量推理	嵌入式部署策略评估延迟降约 4×
MoE 稀疏激活	400M 总参 → 7M 激活参
序列级 PPO	训练吞吐较滑动窗口基线提升约 22×

综合结果:机载推理 200–300 Hz / 单步约 3.32 ms,而机器人控制环只需 50 Hz——留出了约 4–6 倍的算力余量,这也正是"大模型能进控制闭环"的底气。

5.3 真机零样本迁移(定性效果)

在 Unitree G1 上无任何真机微调,直接迁移了多种"域外"参考动作,覆盖了全身控制的典型难点:

动作	数据来源	难点
高动态舞蹈	TikTok/互联网视频恢复	大幅度肢体运动、高速姿态变化
爬行、坐下	高精度光学动捕	接触丰富、低姿态、动态平衡
高踢腿	光学动捕	单腿支撑平衡、敏捷爆发
健身动作	低成本 VR 遥操作	部署导向覆盖
搬箱子	惯性动捕(MoCap TeleOp)	人机交互、负重扰动

遥操作场景里,操作员穿惯性动捕服或用 PICO VR 全身跟踪,机器人能稳定、低延迟地跟随——说明从"数据侧重定向"到"真机侧重定向"的表示一致性经受住了考验。

5.4 与其他生态的"效果"对比视角

再放一个宏观参照系(帮助读者定位):

英伟达 GR00T 家族的 Sonic(Whole-Body Control)是 42M 小脑路线,主打端侧轻量;
OmniH2O / HumanPlus / ExBody2 等学术工作大多面向"特定动作集 + MoCap 数据",难以覆盖互联网视频级别的动作多样性;
HoloMotion-1 的差异化:把"控制策略的大模型化"做到了量产级工程(2000+h 异构数据、7M 激活参数、~300 FPS 端侧推理、66 种 G1 形态一个策略),并用 OMG、HoloAgent-0 等项目证明了作为"运动控制底座"的可复用性。

六、优缺点与踩坑点总结

✅ 优点

架构取舍聪明:MoE(1024 专家/Top-2/1 共享)让"4 亿参数"与"~300 FPS 端侧推理"同时成立,并成为目前人形运控基座模型里规模与实时性平衡最激进的开源样例;
路由设计有 insight:参考条件路由(只吃 ref、不吃状态)直击 sim-to-real 路由振荡问题,是值得所有"Transformer 做 RL 控制器"的工作抄作业的设计;
数据基建完整开源:HoloSMPL(多源统一)+ HoloRetarget(GPU IK、3000+ FPS)+ HDF5 流水线,把"数据"这一最难复现的资产也开放了;
训练效率工程化:序列级 PPO 22× 吞吐提升、episode 感知因果掩码、异步专家路由统计,都是可直接复用的 RL+Transformer 工程经验;
工程链路闭环:从 Conda 训练环境、分布式 PPO、IsaacLab/MuJoCo 双评估、ONNX/TensorRT 导出、Docker 真机镜像到 ROS2/Orin 部署、66 种模块化 G1 一个策略,几乎"开箱即用";
法律与合规细节到位:许可 SMPL 模型不进仓库、NOTICE 归因、Apache 2.0、致谢 ASAP/PHC/GMR/MotionMillion 等上游项目。

❌ 缺点与边界

硬件门槛高:2000+h 数据 + 64×RTX 5090 × 6 天(约 9200 GPU 小时)的训练成本不是普通开发者能复现的——开源了"方法",没开源"钱";
数据资产不可完整分发:视频重建/动捕数据受许可限制,官方主要给转换工具链与子集,完整语料需自行收集(与 Sonic 等闭源数据形成对照);
本体覆盖仍窄:真机验证集中在 Unitree G1 29-DoF(及其模块化变体),“Any Embodiment”(v3)尚在路线图上;
场景局限:地面为平面/粗糙地形,不具备爬楼梯、斜坡大角度、动态地形能力(那是 v4 Any Terrain 的事);静态参考跟踪为主,尚不支持语言指令(Any Command, v2);
安全定位:官方明说"真实机器人演示与评估用,非生产级控制系统",真机实验需严格悬吊+急停流程;
依赖链较重:Isaac Sim/IsaacLab + Newton/Warp + MuJoCo + ROS2 多套仿真与运行时,环境配置踩坑面大(cu128 与 Isaac Sim 的 Torch 版本冲突即是官方已知项)。

🕳️ 高频踩坑清单(文档与源码交叉验证)

坑	现象	对策
pip check 报 Torch 冲突	cu128 栈 vs Isaac Sim 5.0	官方预期行为,别乱修
从 pyproject.toml 直接装依赖	报错/环境残缺	环境必须走 `environments/*.yaml`
IsaacLab 卡在场景创建	拉不到 Nvidia 云资产	开代理重试
`holomotion check` 失败仍跑 offline/teleop	动作指令可能异常	check PASS 前禁止任何会发指令的命令
自定义 .npz 加载失败	字段或布局不符	校验 6 个 `ref_*` 数组 + 29-DoF/30-body 布局
遥操作按 B 无反应	VR 队列未就绪	先等 PICO/XRoboToolkit 数据流,再按 B
训练小显存崩溃	GPU OOM	降 `NUM_ENVS`,接受稳定性下降
多开训练端口冲突	accelerate 报错	显式 `--main_process_port`(≠0)
Newton 找不到 G1 toe	兼容映射	源码已内置 `left_toe→ankle_roll` 映射与 link offset

七、结语:机器人的"小脑"正在被大模型重写

HoloMotion 最值得记录的一点,是它把两件过去被认为矛盾的事情做到了同一个仓库里:模型容量大到 4 亿参数,推理却又快到 300 FPS。它用 MoE 稀疏激活化解容量与延迟的矛盾,用"参考条件路由"化解大规模数据训练与 sim-to-real 的矛盾,用序列级 PPO 化解"长时序 Transformer + RL 训练效率"的矛盾,再用 HoloRetarget 的 GPU IK 把"数据生产"也变成实时组件。

从"Any Pose"到"Any Command / Any Embodiment / Any Terrain",HoloMotion 的 v1 只是地平线"机器人大脑 + 小脑 + 端侧算力(RDK S100)+ RoboOrchard 全栈开源生态"拼图里的一块。但对研究者和开发者来说,它已经是目前观察"人形机器人控制大模型"这场范式迁移的最佳开源切片:你能看到数据怎么来、模型怎么长、怎么训得快、怎么跑上真机——整条链路没有黑盒。

下一步如果你想动手:没有 G1?先跑 MuJoCo sim2sim 评估与可视化;有 GPU 没机器人?用官方 Docker 镜像 + 预训练 checkpoint 复现离线评估;真想训自己的策略?从收集一段自定义动作数据 + HoloSMPL/HoloRetarget 转成 HDF5 开始,再把 motion_tracking_v1_4_0.yaml 的 train_hdf5_roots 指向它——祝你早日让机器人学会你的舞步。