Kiến trúc SONIC cho WBC humanoid

Vì sao nên đọc SONIC qua repo, không chỉ qua paper?

SONIC, viết tắt của Supersizing Motion Tracking for Natural Humanoid Whole-Body Control, là một hướng rất đáng chú ý trong điều khiển toàn thân humanoid. Thay vì viết riêng một controller cho đi bộ, một controller khác cho bò, một controller khác cho teleoperation và thêm một controller nữa cho VLA loco-manipulation, SONIC đẩy bài toán về một việc có thể scale: motion tracking. Policy học bám chuyển động người ở quy mô lớn, sau đó dùng cùng một không gian token để nhận nhiều kiểu lệnh khác nhau.

Nhưng nếu chỉ đọc paper, người mới rất dễ bị lẫn giữa ba lớp: ý tưởng học representation, code train trong Isaac Lab, và stack deploy C++ cho robot thật. Repo NVlabs/GR00T-WholeBodyControl giúp ta tách rõ ba lớp đó. README chính thức nói repo hiện chứa Decoupled WBC, GEAR-SONIC Series và MotionBricks. Riêng bài này tập trung vào ba stack cụ thể cần hiểu trước khi đi sâu: decoupled_wbc, gear_sonic, và gear_sonic_deploy.

Nếu bạn đã đọc các bài trước của vnrobo về deploy GR00T N1 trên Unitree G1, whole-body data pipeline, hoặc ASAP cho Unitree G1, hãy xem bài này như bản đồ kiến trúc. Mục tiêu không phải là chạy ngay robot thật. Mục tiêu là biết file nào đại diện cho khái niệm nào, để khi đọc tiếp các bài 2-6 trong series, bạn không bị lạc giữa checkpoint, planner, token, ZMQ, teleop và VLA.

Roadmap series

Series GR00T SONIC: Điều khiển toàn thân humanoid gồm 6 bài. Bạn đang đọc bài 1.

1. Kiến trúc SONIC cho WBC humanoid: bản đồ repo, ba stack chính và cách nối paper với entry point code.
2. Sim eval SONIC trong Isaac Lab và MuJoCo: cách kiểm tra checkpoint, chạy render, đọc success rate, MPJPE và lỗi tracking.
3. Dữ liệu và training SONIC: Bones-SEED, motion_lib PKL, SMPL, SOMA, PPO và multi-GPU training.
4. Deploy SONIC qua ZMQ: C++ inference, ONNX encoder/decoder, protocol v4, latency và safety loop.
5. Teleop và VLA với SONIC: PICO VR, LeRobot dataset, Isaac-GR00T N1.7 và latent action interface.
6. MotionBricks trong hệ sinh thái SONIC: latent generative motion, interactive control và vai trò bổ sung cho tracking policy.

Ba stack trong GR00T-WholeBodyControl

Hãy bắt đầu bằng cách nhìn repo như một hệ thống nhiều tầng, không phải một package Python đơn. README của repo nói rõ mục tiêu: lưu checkpoint, script train, đánh giá và deploy whole-body controller cho humanoid. Ba stack liên quan trực tiếp đến SONIC có vai trò khác nhau.

decoupled_wbc là stack cũ hơn, dùng cho các mô hình NVIDIA GR00T N1.5 và N1.6. Tài liệu Decoupled WBC mô tả nó như phần mềm cho thí nghiệm loco-manipulation trên nhiều humanoid, chủ yếu Unitree G1. Triết lý của stack này là tách lower body và upper body: phần chân dùng RL policy để giữ cân bằng và di chuyển, phần thân trên dùng IK hoặc teleop policy để đưa tay, cổ tay, gripper theo mục tiêu. Cách tách này thực dụng. Khi bạn muốn robot vừa đi vừa với tay, lower body phải xử lý contact và balance nhanh, còn upper body thường cần tracking target từ người điều khiển hoặc task planner.

gear_sonic là stack training và evaluation. Đây là nơi bạn gặp các file như gear_sonic/train_agent_trl.py, gear_sonic/eval_agent_trl.py, gear_sonic/data_process/convert_soma_csv_to_motion_lib.py, config Hydra trong gear_sonic/config, và các module môi trường trong gear_sonic/envs. Nếu bạn muốn hiểu policy học như thế nào, observation được cấu hình ra sao, motion library được đưa vào Isaac Lab như thế nào, hoặc một checkpoint đạt success_rate và mpjpe_l ra sao, bạn đang ở lớp gear_sonic.

gear_sonic_deploy là stack C++ inference và deployment. README gọi nó là C++ inference stack để deploy SONIC policy lên phần cứng thật. Đây là nơi xuất hiện ONNX model, TensorRT, loop thời gian thực, folder policy/release, phần G1, script deploy, reference motion và các thành phần cần cho MuJoCo sim2sim hoặc robot. Khi paper nói một policy có thể chạy real-time, phần người vận hành cần đọc không chỉ là architecture neural network, mà còn là gear_sonic_deploy: model encoder, model decoder, planner ONNX, observation config, build CMake và đường đi từ lệnh điều khiển đến joint command.

Một cách tóm tắt cho beginner:

Sự khác biệt quan trọng là gear_sonic không phải "bản Python của deploy", và gear_sonic_deploy không phải "nơi train nhanh hơn". Chúng là hai mặt của cùng policy: một mặt tối ưu trong simulation, một mặt đóng gói để chạy ổn định trong loop điều khiển.

Universal token policy là gì?

Trong paper SONIC bản v3, nhóm tác giả nói họ scale motion tracking theo ba trục: kích thước mạng từ 1.2M lên 42M parameters, dữ liệu hơn 100M frames từ 700 giờ mocap, và compute khoảng 21k GPU hours. Nhưng phần làm SONIC khác một motion tracker truyền thống không chỉ nằm ở số to. Điểm kiến trúc cốt lõi là universal token space.

Tài liệu training của repo mô tả SONIC dùng kiến trúc universal-token để điều khiển Unitree G1 29 DoF bằng cách bắt chước dữ liệu mocap người. Nhiều encoder song song nhận các định dạng lệnh khác nhau:

• G1: trajectory ở không gian robot joint.
• Teleop: tracking target từ VR, điển hình là head và hai wrist.
• SMPL: vị trí joint từ parametric human body model.
• SOMA: skeleton joint từ BVH, dùng trong cấu hình mở rộng.

Các encoder này không xuất trực tiếp joint angle. Chúng chiếu input vào một latent token space chung thông qua FSQ, tức Finite Scalar Quantization. Một decoder duy nhất nhận token và sinh action cho robot. Vì vậy, cùng một decoder có thể phục vụ nhiều nguồn lệnh: dữ liệu robot retargeted, teleop, video-to-motion, text-to-motion qua generator, hoặc VLA.

Bạn có thể hình dung pipeline như sau:

motion input
  |-- G1 robot trajectory
  |-- VR teleop targets
  |-- SMPL human joints
  |-- SOMA/BVH skeleton
        |
        v
specialized encoder
        |
        v
shared quantized token space
        |
        v
SONIC decoder
        |
        v
full-body robot actions at control rate

Trong workflow VLA của docs GR00T-WBC, ý tưởng này trở nên rất thực tế: VLA không cần dự đoán raw joint angle. Nó dự đoán SONIC latent motion tokens. Docs ghi rõ biểu diễn này là 64 chiều, còn action đầy đủ mỗi bước inference gồm 78 chiều: 64 chiều motion token cộng 7 joint tay trái và 7 joint tay phải. SONIC sau đó giải mã latent thành command toàn thân ở 50 Hz. Nói ngắn gọn: VLA quyết định "làm gì", SONIC chịu trách nhiệm "làm thế nào để cơ thể đi, giữ thăng bằng, đưa tay và phối hợp chân tay".

Điểm này cũng giải thích vì sao series có bài riêng về teleop/VLA. Nếu bạn nhìn VLA robot như mô hình end-to-end ảnh sang joint, bạn sẽ bỏ lỡ lớp trung gian quan trọng nhất: token motion bền hơn, compact hơn và gần với prior vận động người hơn.

Map paper vào entry point trong repo

Khi đọc paper, bạn sẽ thấy các khái niệm như scaling law, universal tracking, kinematic planner, sim-to-real, zero-shot unseen motion, VLA-driven loco-manipulation. Khi mở repo, bạn lại thấy script, config và folder. Bảng dưới đây là cầu nối:

download_from_hf.py tải từ Hugging Face repo nvidia/GEAR-SONIC. Ở mode mặc định, script tải ONNX cho deploy: model_encoder.onnx, model_decoder.onnx, observation_config.yaml, và planner planner_sonic.onnx nếu không bỏ qua. Với --training, nó tải checkpoint PyTorch sonic_release/last.pt, config.yaml, và dữ liệu SMPL lớn. Với --sample, nó tải sample data nhỏ để chạy thử. Nếu bạn là beginner, đây là file nên đọc sớm vì nó nói rất rõ repo kỳ vọng artifact nằm ở đâu.

check_environment.py là pre-flight check. Nó kiểm tra Python, Git LFS, CUDA, PyTorch, disk space, Isaac Lab, package gear_sonic, training dependencies như Hydra, TRL, Transformers, Accelerate, W&B, và deployment dependency như TensorRT. Chi tiết Git LFS rất quan trọng: repo có mesh, ONNX và asset lớn. Nếu bạn clone mà chưa pull LFS, nhiều file chỉ là pointer vài trăm byte. Lỗi kiểu này làm simulation hoặc deployment hỏng rất khó đoán.

gear_sonic/eval_agent_trl.py là entry point hợp lý sau khi có checkpoint. Script yêu cầu Isaac Lab, load config từ checkpoint nếu có, rewrite một số path module cũ sang path release gear_sonic.*, merge override Hydra, rồi chạy evaluation trong IsaacSim/Isaac Lab. Training guide của repo đưa hai mode chính: metrics và render. Metrics dùng eval_callbacks=im_eval, num_envs=128, termination tracking/eval và giới hạn số motion. Render bật manager_env.config.render_results=True để xuất video. Đây là bài 2 trong series.

Vì sao scale lại quan trọng?

Trong humanoid WBC, policy nhỏ thường được train cho một nhóm skill cụ thể: đi bộ, đứng dậy, đá, bò, hoặc tracking một tập motion. SONIC đặt cược vào luận điểm khác: nếu motion tracking có dense supervision từ mocap, ta có thể scale nó giống foundation model hơn. Paper bản v3 nêu rõ ba trục:

Paper cũng mô tả training lớn nhất dùng 128 GPU trong 7 ngày, tương ứng khoảng 21k GPU hours. Dataset test được tách thành test-content cho motion content chưa thấy trong training, test-repetition cho lần diễn lại của motion type đã thấy, và PHUMA từ pipeline retargeting khác. Metric chính gồm success rate, MPJPE-L, velocity distance và acceleration distance. Với người mới, đừng chỉ nhìn "42M parameters" như một con số marketing. Điều cần nhớ là scale được kiểm tra trên generalization: motion mới, repetition mới, dataset khác, simulation và real-world.

Điều này khác với cách làm reward-engineering theo từng task. Nếu bạn muốn robot học "bò bằng khuỷu tay", bạn có thể viết reward cho body height, elbow contact, forward velocity, energy, smoothness. Nhưng nếu ngày mai muốn "đi kiểu bị thương" hoặc "vừa quỳ vừa đưa tay", bạn lại phải chỉnh reward. SONIC dùng mocap để cung cấp mục tiêu dense hơn: body nên ở đâu, joint nên chuyển động thế nào, vận tốc và gia tốc có hợp lý không. Khi dữ liệu đủ lớn, policy học một prior vận động toàn thân thay vì học từng trò rời rạc.

Luồng chạy tối thiểu cho người mới

Nếu bạn mới tiếp cận, đừng bắt đầu bằng robot thật. Hãy đi theo thứ tự an toàn:

1. Đọc README và docs chính thức.
2. Clone repo có Git LFS và pull asset đầy đủ.
3. Chạy python check_environment.py để biết máy thiếu gì.
4. Chạy python download_from_hf.py --sample để lấy sample data nhỏ.
5. Cài môi trường đúng use case: training dùng Isaac Lab Python env, MuJoCo simulation dùng .venv_sim, deploy thật dùng C++ build.
6. Chạy evaluation hoặc render với gear_sonic/eval_agent_trl.py.
7. Chỉ sau khi hiểu observation, action scale, PD gain, safety và networking mới nghĩ đến gear_sonic_deploy trên phần cứng.

Một skeleton lệnh đọc được từ README và training guide:

# Kiểm tra môi trường tổng quát
python check_environment.py

# Tải ONNX model cho deployment vào gear_sonic_deploy/
python download_from_hf.py

# Tải checkpoint training và SMPL data lớn
python download_from_hf.py --training

# Tải sample data nhỏ để thử nhanh
python download_from_hf.py --sample

# Eval checkpoint bằng metrics
python gear_sonic/eval_agent_trl.py \
  +checkpoint=<path_to_checkpoint.pt> \
  +headless=True \
  ++eval_callbacks=im_eval \
  ++run_eval_loop=False \
  ++num_envs=128

Các lệnh này chưa đủ để chạy trên mọi máy, vì Isaac Lab, CUDA, TensorRT và Git LFS phụ thuộc môi trường. Nhưng chúng đủ để bạn biết "đường ray" của repo: download artifact, check env, chạy training/eval Python, rồi chuyển sang deploy C++.

Đọc decoupled_wbc như baseline, không như phần lỗi thời

Một sai lầm dễ gặp là xem decoupled_wbc như phần cũ nên bỏ qua. Thực tế, nó là baseline kiến trúc rất hữu ích. Decoupled WBC thể hiện một cách thiết kế phổ biến trong humanoid loco-manipulation: lower body policy chịu trách nhiệm stability và navigation, upper body bám target tay, và teleop hoặc planner gửi command.

Tài liệu của decoupled_wbc có script chạy control loop G1 trong simulation và real robot, cùng phím keyboard cho activate/deactivate policy, release/hold robot, tiến/lùi, strafe, yaw và zero navigation command. Nó cũng có teleoperation loop dùng PICO controller, LeapMotion hoặc HTC Vive với Joy-Con. Những chi tiết này giúp bạn hiểu vì sao SONIC cần universal control interface. Nếu mỗi interface teleop, planner, VLA đều đẩy thẳng vào controller riêng, hệ thống sẽ nở ra rất nhanh. Universal token space là cách gom nhiều interface vào một policy chung.

Nói cách khác, decoupled_wbc trả lời câu hỏi: "Trước SONIC, ta ghép locomotion và manipulation thực dụng như thế nào?" Còn gear_sonic trả lời: "Nếu muốn một policy generalist học từ motion data lớn, train nó ra sao?" Và gear_sonic_deploy trả lời: "Nếu policy đó đã học xong, đóng gói nó để chạy realtime thế nào?"

Những chỗ cần cẩn thận khi đọc repo

Thứ nhất, đừng nhầm training và deployment artifact. download_from_hf.py mặc định tải ONNX deploy model vào gear_sonic_deploy. Khi thêm --training, nó tải checkpoint PyTorch và SMPL data về repo root. Hai mode này phục vụ hai workflow khác nhau.

Thứ hai, đừng bỏ qua observation_config.yaml. Với WBC, observation không phải chi tiết phụ. Nếu order joint, normalization, history, frame convention hoặc sensor field lệch giữa train và deploy, policy có thể sinh action trông hợp lệ nhưng sai hoàn toàn về ý nghĩa vật lý.

Thứ ba, hãy xem Git LFS như dependency bắt buộc. Nhiều asset robot và ONNX model được track qua LFS. check_environment.py có logic kiểm tra file quá nhỏ để phát hiện pointer. Đây là lỗi rất thực tế trong robotics repo lớn.

Thứ tư, hãy nhớ rằng policy SONIC nhắm đến Unitree G1 29 DoF trong tài liệu training. Nếu robot, firmware, hand, waist hoặc joint order khác, bạn cần mapping lại. Một model foundation cho motion không làm mất đi các ràng buộc cơ khí, actuator, PD gain và network safety.

Nguồn kỹ thuật chính

Các chi tiết trong bài này dựa trên README và docs của NVlabs/GR00T-WholeBodyControl, project page GEAR-SONIC, paper SONIC trên arXiv, tài liệu Training Guide, VLA Workflow, và Decoupled WBC reference.

Bài viết liên quan

• Sim eval SONIC trong Isaac Lab và MuJoCo
• Dữ liệu và training SONIC
• Teleop và VLA với SONIC