【SONIC源码阅读系列1】总体路线
Repo：https://github.com/NVlabs/GR00T-WholeBodyControl
Page：https://nvlabs.github.io/GEAR-SONIC/
其他：从运控基座到VLA梳理
博主作为一个初学者，后面将试图呈现一条端到端数据流，仅作为自己快速了解 Repo架构的记录，大部分内容由ChatGPT生成，不具备参考价值。按下面 6 个阶段来读SONIC的项目。每一阶段都回答四个问题：
- 输入是什么，tensor 长什么样？
- 经过哪个代码模块？
- 为什么 NVIDIA 要这么设计？
- 它和 SONIC report 中的哪个概念/公式对应？
截至 2026/9/13，代码已经比早期版本完整很多：gear_sonic 已经公开了训练代码、universal-token 模块、配置体系、ONNX export；gear_sonic_deploy 则对应 C++/TensorRT 部署。尤其值得注意的是，当前 training guide 明确把 architecture 描述为 G1 / Teleop / SMPL 多 encoder → FSQ shared latent token → 单一 G1 dynamic decoder，而不是简单的“一个 encoder + 一个 policy”。(GitHub)
总体路线
┌──────────────────────┐
│ VLA / Motion Source │
│ │
│ VLA / Teleop / SMPL │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Motion Representation│
│ │
│ reference trajectory │
│ future lookahead │
└──────────┬───────────┘
│
▼
╔════════════════════════════════════╗
║ SONIC CORE ║
║ ║
║ G1 Encoder ─┐ ║
║ Teleop Enc ─┼→ FSQ → Token ║
║ SMPL Encoder┘ │ ║
║ ▼ ║
║ G1 Dynamic ║
║ Decoder ║
╚══════════════════╤═════════════════╝
│
▼
Joint Actions
│
▼
┌──────────────────────┐
│ TensorRT / C++ WBC │
│ │
│ observation / policy │
│ safety / PD / ZMQ │
└──────────┬───────────┘
│
▼
G1
│
└──── feedback ───►
而训练是从下面这条支路进入的：
Bones-SEED / Motion Dataset
│
▼
Retarget / Filter
│
▼
Motion Library
│
▼
Isaac Lab
│
▼
SONIC + G1 Simulation
│
▼
PPO + Aux Loss
│
▼
SONIC Checkpoint
│
▼
ONNX / TensorRT
当前官方训练配置确实是 Hydra 分层组合的：base → observations → actor_critic/universal_token → aux_losses → trainer → experiment，而 train_agent_trl.py 是训练入口。(GitHub)
Phase 0：先建立“地图”——VLA / Motion Generation 到 SONIC
目的：只花很少篇幅把 SONIC 放到整个机器人系统里。
我们会回答：
VLA 到底输出什么？
↓
为什么不能直接控制 G1？
↓
为什么需要 SONIC？
↓
SONIC 和 GR00T VLA 的边界在哪里？
不会深入 VLA 本身。重点只追：
VLA
↓
motion / target
↓
SONIC
↓
whole-body execution
尤其会结合仓库现在提供的：
launch_inference.py
↓
Python VLA inference
↓
C++ SONIC controller
官方目前已经明确提供 VLA → SONIC → G1 的 end-to-end workflow。(GitHub)
这一阶段最终得到
一张非常清晰的：
“GR00T / VLA 是大脑，SONIC 是运动系统”的接口图
Phase 1：Motion Reference → Observation
这是真正读 SONIC 代码的起点。我们会从：
SMPL / G1 / Teleop
↓
motion reference
↓
observation construction
↓
policy input
一路追源码。重点看：
- motion library
- motion cursor
- reference sampling
- future frames
- robot proprioception
- observation history
- normalization
- heading / coordinate frame
- 不同 modality 的 observation
尤其会把：
Default SONIC
10 future frames × 20 ms
≈ 200 ms
Low latency
4 future frames × 20 ms
≈ 80 ms
这种论文/README 里的描述真正落实到代码中的 tensor。当前 model card 已明确给出这两个 reference horizon。(GitHub)
这一阶段最重要的问题
SONIC 究竟“看到了什么”？
这个问题非常重要。因为看 SONIC Report 时容易直接跳到：
“它有一个 universal token。”
但实际上：token 是 representation；真正决定 controller 行为的第一步，是 observation 如何构造。
Phase 2：Universal Token——整个项目最核心的一章
这一章代码主线会追：
gear_sonic/
↓
actor_critic/
↓
universal_token/
↓
UniversalTokenModule
当前官方 training-code reference 已经明确给出了结构：
G1 observation
│
▼
G1 Encoder ───────────┐
│
Teleop observation │
│ │
▼ │
Teleop Encoder ───────┼──→ FSQ → shared token
│
SMPL observation │
│ │
▼ │
SMPL Encoder ─────────┘
│
▼
G1 Dynamic Decoder
│
▼
Joint Actions
(GitHub)
这里拆解和回答一个重点问题：
64-D universal token 到底是什么？
我们不会满足于说：
“它是 latent representation。”
而是会继续往下拆：
raw motion
↓
encoder
↓
continuous representation?
↓
FSQ
↓
discrete / quantized latent
↓
64-D token
然后研究：
① 为什么需要 FSQ？
② 64-D 是怎么形成的？
③ token 是 continuous 还是 quantized？
④ 不同 modality 为什么能够进入同一个 token space？
⑤ decoder 为什么只需要一个？
⑥ “universal”到底是 representation universal，还是 control universal？
这几个问题，我认为是整个 SONIC 最值得研究的部分。
Phase 3：Token → Policy → Action
这一阶段开始回答：
有了 universal token 之后，SONIC 到底怎么产生运动？
我们会拆成：
motion token
+
robot proprioception
+
history
↓
policy / actor
↓
action
然后追：
Actor/Critic/PPO/Auxiliary Loss
这里会把代码和 RL formulation 对起来。特别是当前 repo 已明确：
SONIC 训练不是纯 PPO，而是 PPO + auxiliary losses。(GitHub)
所以这一阶段会专门研究：
┌── tracking loss
│
PPO objective ──────┼── RL reward
│
├── auxiliary loss
│
└── token-related objective?
从源码确认每一项到底是什么，而不是根据 report 猜。
Phase 4：Simulation → PPO → Generalization
这一阶段完整追训练闭环：
Motion Dataset
↓
Motion Library
↓
Isaac Lab
↓
Reference Motion
↓
SONIC
↓
G1
↓
Physics
↓
Reward
↓
PPO
↓
Policy Update
重点研究三个东西。
A. Motion Tracking Reward
也就是：
SONIC 究竟用什么方式定义“跟得好”？
B. Sim-to-real
这里会看：
domain randomization
system identification
motor dynamics
noise
latency
terrain/contact
以及为什么一个 tracking policy 最后可以跑到真实 G1。
C. Motion Generalization
这里的研究方向：
training motions
↓
SONIC
↓
unseen motions？
提出一个问题：
它究竟是在“记 motion”，还是学到了一个 motion-conditioned controller？
这会直接连接到 SONIC report 的 foundation-model 叙事。
Phase 5：Training Checkpoint → ONNX → TensorRT → G1
然后从 Python 世界进入 deployment 世界。
PyTorch checkpoint
↓
ONNX export
↓
encoder.onnx
decoder.onnx
↓
TensorRT
↓
C++
↓
ZMQ
↓
G1
这里会重点看：为什么训练代码和部署代码差这么多？
以及：
Python
↓
PyTorch
↓
ONNX
↓
TensorRT
↓
C++
究竟在哪些地方发生了：
- observation transformation
- normalization
- model split
- latency optimization
- action scaling
- motor control
官方当前 deployment 把 encoder / decoder 和 observation config 单独作为部署组件，并通过 C++ stack 运行。(GitHub)
这一阶段的最终目标是：
把一条真实机器人控制周期从输入到电机彻底走通。
Phase 6：最后做一次“研究者视角”的重构
这一章，从后续研究价值的角度来审视，不再按代码讲，而是重新问：
SONIC 真正的核心贡献是什么？
将其拆成几个 hypothesis（Noted as H）：
H1 — Motion Tracking as a Scalable Control Objective
大量 human motion
↓
统一 tracking task
↓
RL
↓
generalist WBC
H2 — Universal Token
G1 ──────┐
Teleop ──┼→ shared latent → one decoder
SMPL ────┘
这是 representation-level 的统一。
H3 — Generalist Controller
walk
run
crawl
kneel
jump
manipulate
...
↓
SONIC
不是一个 behavior 一个 policy。
H4 — Control Foundation Model
最终形成：
VLA
│
▼
motion intent
│
▼
SONIC
│
┌──────────┼──────────┐
▼ ▼ ▼
walk crawl manipulate
这里会讨论：
SONIC 和传统 WBC、motion imitation、RL locomotion policy、diffusion motion policy、VLA controller 的本质区别到底是什么？
最后还有一条“横向主线”
整个阅读过程中始终维护一个 Tensor/Data Flow Table。最终我们会得到类似：
| Stage | Tensor | Shape | Semantic |
|---|---|---|---|
| Motion | SMPL ref | T × J × 3 | human motion |
| Reference | future motion | H × ... | lookahead |
| Observation | encoder input | ... | modality-specific |
| Encoder | latent | ... | motion representation |
| FSQ | token | 64 | universal representation |
| Policy | actor input | ... | control context |
| Action | joint command | 29 | G1 command |
| Motor | PD target | 29 | low-level control |
**这一张表会是整个系列最重要的产物之一。**因为最终真正要掌握的不是：
“这个文件调用了那个文件。”
而是：
一个 motion 从进入系统开始，到最后变成 G1 的 29 个关节控制量，中间到底经过了什么数学变换。
节奏
第 1
│
├─ Phase 0：VLA / Motion → SONIC
└─ Phase 1：Motion Reference → Observation
↓
建立完整输入侧
第 2
│
└─ Phase 2：Universal Token
↓
Encoder → FSQ → 64D Token → Decoder
↓
重点深挖
第 3
│
└─ Phase 3：Token → Policy → Action
↓
PPO + Auxiliary Loss
第 4
│
└─ Phase 4：Isaac Lab → PPO → Sim2Real
↓
为什么它能 generalize
第 5
│
└─ Phase 5：ONNX → TensorRT → C++ → G1
↓
真正的 deployment loop
第 6
│
└─ Phase 6：研究者视角
↓
SONIC 的核心设计
与已有 WBC / imitation / diffusion / VLA 比较
↓
提炼潜在研究方向
而且每一期都会直接引用当前仓库的具体文件、class/function 和配置路径，而不是只讲概念。当前 repo 的训练入口、Hydra 配置树、UniversalTokenModule 和 deployment 路径已经可以直接串起来。(GitHub)
三个“研究问题”
后面六阶段都围绕这三个问题反复验证：
① Universal Token 为什么有效？
② SONIC 学到的到底是 motion representation，还是一个真正 generalizable 的 control policy？
③ 为什么“human motion tracking + universal representation + RL”能够成为 VLA 和 humanoid hardware 之间的一个通用 control interface？
如果最后这三个问题能够从代码 + tensor + loss + experiment + deployment全部回答清楚，对 SONIC 的理解就不再是“读过一个 report”，而会接近能够自己设计下一代 whole-body controller的程度。
另外，仓库当前仍在快速演进——例如 2026-07 已加入 SONIC v1.1，2026-08 又加入了逐电机 Kp/Kd scaling，所以我们阅读时会明确区分论文/原始 SONIC、当前 release、以及 v1.1 后来的工程修改，避免把后来的 engineering fix 误认为论文原始设计。(GitHub)
DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐
2
0- 0
已为社区贡献8条内容
所有评论(0)