The released controller path is built for Unitree G1
The 3 models released for SONIC target Unitree G1. GR00T Whole-Body Control collects the pieces needed to move that humanoid, rather than stopping at a research checkpoint. SONIC tracks reference motion, gear_sonic_deploy runs the controller through C++ and TensorRT, and the Python side covers training, MuJoCo simulation, teleoperation, and data collection. The repository also includes MotionBricks, a separate interactive motion model. That explains the 3,380 files and 548.3 MB checkout we measured.
The Isaac Teleop route is documented only for a G1 with a Thor backpack. The controller runs at 50 Hz and accepts SMPL poses, G1 motion references, or teleoperation input. Adapting another humanoid means more than changing a model name. You need robot assets, actuator assumptions, training, deployment work, and a fresh safety case.
Training SONIC from scratch is a 64-plus-GPU project
The README's full training command recommends 64+ GPUs and 4,096 environments. NVIDIA provides a PyTorch checkpoint, training recipes, motion conversion scripts, Isaac Lab evaluation, and ONNX export guidance. The README also points to Bones-SEED data for G1 and explains how to filter motions the robot cannot perform. Issue 136 shows that researchers are already comparing their trained policies with the released model.
Isaac Lab 2.3 or newer must be installed separately, while the deployment route has its own native or container setup. A lab interested mainly in running a released policy should begin with simulation and the supplied checkpoints. The 22-second Python install from our sandbox says nothing about the cost of training SONIC.
What happened when we ran it
Our measurement setup was an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. We cloned commit b042411 and installed it in 22 seconds, adding 35 packages and 37 MB. The build finished successfully in another 8 seconds. Pip-audit reported 0 known vulnerabilities. Those checks do not measure controller quality, tracking accuracy, latency, or robot safety.
Pytest failed with exit code 1 after 6 seconds. It reported 0 passed, 0 failed, and 9 collection/setup errors out of 9 modules. The affected paths cover control loops, interpolation policy, robot models, teleoperation, visualization, data export, and simulation. The provided log tail names each file and gives the summary, but it does not show the underlying exceptions. Assigning the failure to one missing package or one code defect would be guesswork.
The checkout held about 351,339 source lines across 3,380 files. Our inventory found one CI workflow, no Dockerfile, and no top-level tests directory, although pytest discovered modules under decoupled_wbc/tests. The result is clear enough for a release gate: commit b042411 installed and built in our container, but its supplied test command never executed a test. A team adopting it should reproduce the intended environment and make that suite collect cleanly first.
Exact TensorRT versions are part of robot safety
The deployment guide requires TensorRT 10.13 on x86_64 and 10.7 on Jetson or onboard G1 Orin. It warns that a different version can produce wrong planner output and dangerous behavior. Git LFS is mandatory for meshes and ONNX files, and Jetson deployment requires JetPack 6. Even the Docker development route expects TensorRT on the host. This is a hardware stack with pinned assumptions, not a portable Python demo.
The quick start puts Isaac Lab evaluation and MuJoCo sim-to-sim work before deploy.sh real. It also calls for a clear safety zone and an operator ready to trigger an emergency stop. Those instructions deserve to be treated as acceptance criteria. Each checkpoint has matching encoder, decoder, and observation files, so versioning those assets together matters as much as pinning the source commit.
Open overheating reports make physical validation non-negotiable
Open issue 174 reports ankle-motor high-temperature warnings within roughly 5 to 10 minutes under SONIC. A project collaborator said the team had also seen overheating in some awkward postures and advised checking reference motion, calibration, and robot version. Later reports in the same thread describe continuing symptoms on physical G1 units. These are user reports, not findings from our 8 GB sandbox, but they concern the part of the system that can damage hardware.
The issue thread also shows how specific the support boundary is. A collaborator wrote that the released policy was mainly built for the newer G1 and suggested fine-tuning actuator parameters for the older version. That turns robot revision, joint calibration, reference stance, motor temperature, and emergency-stop behavior into deployment checks. A passing simulator run cannot certify a physical machine, though a failed simulator run should stop the rollout.
September activity is healthy, but releases are not tagged on GitHub
GitHub showed 3,682 stars, 35 open issues, and 36 open pull requests on September 29, 2026. The main repository was pushed on September 23, and issue and pull request activity continued afterward. The latest-release endpoint returned no GitHub release, while the README records dated checkpoint updates and points to Hugging Face for model files. Maintenance is active, even if the packaging does not follow GitHub Releases.
Code and weights also have different terms. Source code is under Apache 2.0, while trained checkpoints use the NVIDIA Open Model License. For a G1 team already committed to Isaac Lab, TensorRT, and supervised hardware trials, this repository can save months of integration work. For everyone else, Isaac Lab or a narrower motion-tracking project gives you fewer assumptions to inherit.