训练好的策略在跟踪训练分布内的动作样本时表现尚可，但进入流水线下一阶段——为 VLA 微调做 PICO VR 遥操作——就不行了。遥操作过程中机器人不稳定、频繁摔倒，尽管离线动作跟踪看起来可以接受。
背景：训练配置：288 小时 BONES-SEED 数据集、约 142k 条 retargeted 动作、7000+ 次迭代、1 张 RTX PRO 6000 Blackwell、env 8192。作者怀疑默认的 SONIC 奖励配置与 domain randomization 是为 Unitree G1 调的，无法迁移到形态、动力学、执行器与关节限位都不同的机器人上。
我们的解读：离线动作跟踪通过不等于遥操作鲁棒。把 SONIC 移植到新机器人时，要为奖励与 domain randomization 的重新调参预留时间——针对 G1 调优的默认值只是起点，不能直接拿来用。
从哪开始：见我们的新 embodiment 指南（KP/KD 调参、body 名称兼容、PKL 数据格式）——#252 的症状正是出在那里的配置文件上。
gear_sonic/envs/manager_env/robots/h2.py 里有三个执行器相关数值与随附发布的 H2 模型文件不一致。h2.py 中每个执行器组的数值都是 g1.py 的恰好 3 倍。而 h2.urdf 与 mjcf/h2.xml 在所有 31 个关节上互相一致，也和 Unitree 公布的规格一致。
背景：issue 里的具体例子：ankle_roll 在 h2.urdf/h2.xml 中是 19.00，在 h2.py 里却是 150.0（约 7.9 倍）；waist_yaw 120.00 对 264.0（2.2 倍）。daf3899 随附的移植示例能端到端跑通，但执行器数值看起来像是从 G1 等比例缩放来的占位值。
我们的解读：移植到 H2（或任何机器人）时，URDF/MJCF 的关节限位比机器人 .py 里的执行器数值更可信——并核实 effort limit 是否与真实电机规格一致（Unitree 公布 H2 腿部 360 N·m、手臂 120 N·m）。
从哪开始：这正是配置与模型一致性检查能抓到的错误类型。官方仓库里的 scripts/check_actuator_params.py 就是为自动标记这类不一致而写的。
SONIC 遥操作过程中，G1 会偶尔报 “robot data late”。机器人动作有时还会越来越延迟。触发 episode 录制时，按下控制器按键到收到确认，响应有时能到大约 6 秒。
背景：拓扑：G1 有线 → 路由器 → 笔记本（RTX 5090），Pico 4 Ultra 无线。停掉 camera service 与 data exporter 后复测——警告和延迟仍然出现。
我们的解读：“robot data late” 说明控制回路没有及时收到机器人状态——是网络/系统问题，不是模型问题。机器人有线直连 PC 是可靠基线；无线 VR 多一跳，可能饿死控制回路。
从哪开始：遥操作页面覆盖 ZMQ 端口与部署拓扑；数据采集里的 data-exporter 与 camera-server 卸载建议，正是给控制回路腾带宽的做法。