企业官网建设流程全解析

Repo：https://github.com/NVlabs/GR00T-WholeBodyControl
Page：https://nvlabs.github.io/GEAR-SONIC/
其他：从运控基座到VLA梳理

博主作为一个初学者，后面将试图呈现一条端到端数据流，仅作为自己快速了解 Repo架构的记录，大部分内容由ChatGPT生成，不具备参考价值。按下面6 个阶段来读SONIC的项目。每一阶段都回答四个问题：

1. 输入是什么，tensor 长什么样？
2. 经过哪个代码模块？
3. 为什么 NVIDIA 要这么设计？
4. 它和 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。最终我们会得到类似：

**这一张表会是整个系列最重要的产物之一。**因为最终真正要掌握的不是：

“这个文件调用了那个文件。”

而是：

一个 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)