The repository is built around Unitree G1 and SONIC
GR00T Whole-Body Control collects several layers of NVIDIA's humanoid control work in one 548.2 MB checkout. SONIC supplies a motion-tracking policy, gear_sonic_deploy provides the C++ path to a robot, and the Python side covers training, data processing, simulation, and VLA orchestration. MotionBricks adds an interactive latent-motion system. This breadth is useful when the target is already a Unitree G1 and the team wants one upstream source for policy assets and deployment code.
The scope is narrower than the name first suggests. Three released SONIC checkpoints target G1, and the documented Isaac Teleop route is supported only on a G1 carrying a Thor backpack. The controller runs at 50 Hz and consumes different reference forms, including SMPL poses and teleoperation input. Teams adapting another humanoid should expect robot-model work, configuration changes, training, and safety validation rather than a model-name swap. Open issue 252, about poor training on a new robot, is a useful warning from the current queue.
A 64-GPU example puts training beyond a small lab
The repository includes a real training path, not only inference files. NVIDIA publishes the SONIC checkpoint, conversion scripts for Bones-SEED motion data, evaluation instructions, and ONNX export guidance. The README describes a dataset with more than 142,000 motions and about 288 hours of G1-retargeted movement. That gives researchers a defined starting corpus, while custom motion libraries still need conversion and filtering before training.
Compute is the limiting detail. The quick-start fine-tuning command recommends 64 or more GPUs, launches 8 processes, and requests 4,096 environments. Isaac Lab must be installed separately inside its own Python environment. Smaller experiments may be possible, but the README does not give us evidence for a cheap training configuration. A team interested mainly in deployment should start with the released checkpoints instead of budgeting from the short Python installation we measured.
What happened when we ran it
Our sandbox cloned commit a0732b6 and installed 33 Python packages in 18 seconds. They occupied 36 MB, and the build completed successfully in 6 seconds. Pip-audit reported 0 known vulnerabilities. The checkout contained 3,376 files and about 350,652 lines of source, so the quick dependency step should not be mistaken for proof that the whole robotics stack is ready.
The test command failed after 8 seconds with exit code 1. Pytest reported 0 passed, 0 failed, and 9 collection or setup errors out of 9 modules. Each listed traceback ended with ModuleNotFoundError: No module named 'yaml', covering controller loops, policy interpolation, robot models, teleoperation, visualization, data export, and simulation. The log establishes the missing import and nothing more, so we cannot say whether adding one package would uncover later failures.
Our scan found 1 CI workflow file, no Dockerfile, and no top-level tests directory. Tests do exist under decoupled_wbc/tests, as the failure paths show. These findings describe an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and the supplied Python 3.12 image. They do not measure controller quality, training speed, simulation accuracy, or physical-robot safety.
Exact TensorRT versions are a safety requirement
The production path asks for much more than Python. Git LFS is mandatory because meshes and ONNX models are stored as large assets; cloning without it leaves pointer files that can fail later. Training downloads checkpoints and SMPL data from Hugging Face. Separate installer scripts create environments for MuJoCo, PICO teleoperation, and data collection, while real hardware uses a C++ build. That separation is sensible, though it means there is no single setup that proves every path.
Deployment documentation requires CUDA and TensorRT before building. It names TensorRT 10.13 for x86_64 and 10.7 for Jetson or onboard G1 Orin, plus JetPack 6 for that onboard route. NVIDIA warns that another TensorRT version can yield incorrect inference and dangerous robot motion. The Docker development environment still expects TensorRT on the host, an NVIDIA driver, and architecture-specific CUDA handling. This is the point where an experienced robotics operator becomes mandatory.
Three checkpoints trade responsiveness against reference context
The default SONIC and v1.1 checkpoints use 10 future reference frames at 20 ms spacing, roughly 200 ms of lookahead. The low-latency teleoperation checkpoint uses 4 frames, roughly 80 ms. NVIDIA carefully says these horizons are not total teleoperation latency because sensing, networking, preprocessing, and inference add their own delays. That distinction matters when specifying a remote-control system: none of the README figures is an end-to-end response benchmark.
Each checkpoint has matching encoder, decoder, observation configuration, and sometimes model configuration files. Mixing those assets would be an avoidable deployment error. The v1.1 checkpoint adds heading-normalized target orientation and wrist-pose augmentation, while the low-latency option favors a shorter reference window. Testing all candidates against the intended task in simulation is more useful than choosing the one whose label sounds fastest.
August activity is healthy, while releases are not tagged
GitHub showed 3,428 stars, 66 combined issues and pull requests, and a last push dated August 21, 2026. Issue and pull request activity continued through August 26, including work on teleoperation, training performance, camera support, and network setup. The latest-release endpoint returned no published GitHub release, but the README records checkpoint updates through July 23. A missing release object is therefore a packaging fact, not evidence that the project is abandoned.
The source code uses Apache-2.0, while model weights carry the NVIDIA Open Model License and its attribution and Trustworthy AI conditions. That split deserves a legal check before a commercial rollout. For a G1 team already using NVIDIA's simulation and inference stack, GR00T Whole-Body Control is a serious reference implementation. The 9 collection errors mean its checked-out test state still needs to be made reproducible before anyone lets the result command hardware.