Deployment guide · commands verbatim

Install and deploy SONIC: TensorRT first, then build

Deploying the SONIC whole-body controller on the Unitree G1 is a C++ + TensorRT build with one non-negotiable rule: install the exact TensorRT version before anything else. Everything below is transcribed from the official Installation (Deployment) and C++ Deployment Program Flow docs.

Prerequisites

Ubuntu 20.04/22.04/24.04 or other Debian-based Linux distributions
CUDA Toolkit (for GPU acceleration)
TensorRT (for inference optimization) — install this first!
JetPack 6 (for onboard deployment)
Python 3.8+
Git with LFS support

Download TensorRT from NVIDIA Developer. This is the deployment-side install; training has its own path — see Training Data and Training for the Isaac Lab setup.

TensorRT versions (verbatim)

Platform	TensorRT Version
x86_64 (Desktop)	10.13 (required)
Jetson / G1 onboard Orin	10.7 (required; requires JetPack 6 — flashing guide)

Download the TAR package (not the DEB one) so you can extract TensorRT to any location. The archive is ~10 GB; consider using pv to monitor progress:

sudo apt-get install -y pv
pv TensorRT-*.tar.gz | tar -xz -f -

Move the unzipped TensorRT to ~/TensorRT (or similar) and add to your ~/.bashrc:

export TensorRT_ROOT=$HOME/TensorRT

Read this before installing

Danger: you must use the exact TensorRT versions listed above. Using a different version is known to produce incorrect inference results — the planner will output wrong motion, which can cause dangerous robot behavior.

This warning is copied from the official docs. A wrong TensorRT build does not fail loudly — it silently degrades planner output, and on a real robot that is a safety problem, not a performance problem.

Clone the repository

git clone https://github.com/NVlabs/GR00T-WholeBodyControl.git
cd GR00T-WholeBodyControl
git lfs pull          # make sure all large files are fetched

The repo contains large binary assets (meshes, ONNX models); git lfs pull fetches the real bytes instead of pointer files. Full LFS guidance, including the MotionBricks checkpoint caveat, is on the setup page.

Native development (recommended)

Advantages: direct system installation, faster builds, production-ready. Prerequisites: basic development tools (cmake, git, etc.) and, optionally, ROS2 if you plan ROS2-based input/output.

For G1 onboard deployment, the onboard Orin must be upgraded to JetPack 6 to support TensorRT. Follow the flashing guide for upgrading.

1 · Install system dependencies

cd gear_sonic_deploy
chmod +x scripts/install_deps.sh
./scripts/install_deps.sh

2 · Set up environment

source scripts/setup_env.sh

The setup script automatically configures the TensorRT environment and sets up all necessary paths. For convenience, add it to your shell profile:

echo "source $(pwd)/scripts/setup_env.sh" >> ~/.bashrc

3 · Build the project

just build

Other just commands: just clean (clean build artifacts) and just --list (show all available commands).

Docker (ROS2 development environment)

A unified Docker environment with ROS2 Humble, supporting x86_64 and Jetson platforms.

Prerequisites: Docker installed and user added to docker group; TensorRT_ROOT environment variable set on host; for Jetson: JetPack 6.1+ (CUDA 12.6).

# 1. Add user to docker group (one-time setup)
sudo usermod -aG docker $USER
newgrp docker

# 2. Set TensorRT path (add to ~/.bashrc for persistence)
export TensorRT_ROOT=/path/to/TensorRT

# 3. Launch container
cd gear_sonic_deploy
./docker/run-ros2-dev.sh

Options:

./docker/run-ros2-dev.sh               # Standard build (fast)
./docker/run-ros2-dev.sh --rebuild     # Force rebuild
./docker/run-ros2-dev.sh --with-opengl # Include OpenGL for visualization (RViz, Gazebo)

Architecture support: x86_64 — CUDA 12.4.1 (requires NVIDIA driver 550+); Jetson — CUDA 12.4.1 container on CUDA 12.6 host (forward compatible). Inside the container:

source scripts/setup_env.sh # set up dependency
just build                  # Build
just --list                 # Show all commands

Troubleshooting: if you get "permission denied", ensure you're in the docker group; TensorRT must be set on the host before starting the container; for Jetson, run source scripts/setup_env.sh on the host first (sets jetson_clocks).

Run the deployment stack

The C++ deployment binary is gear_sonic_deploy, launched via deploy.sh. Input interfaces: keyboard | gamepad | gamepad_manager | zmq | zmq_manager | ros2 | manager; output publishing via --output-type zmq|ros2|all.

cd gear_sonic_deploy
./deploy.sh --input-type zmq_manager real

In simulation (MuJoCo), use the sim argument instead — the deploy binary connects to the sim loop instead of real hardware:

./deploy.sh --input-type zmq_manager sim
# Wait until you see "Init done"

The default deployment uses the default SONIC checkpoint. For the low-latency or SONIC v1.1 checkpoints, point deploy.sh at the matching model prefix and observation config (per the model card comparison page):

./deploy.sh \
--cp policy/low_latency/model \
--obs-config policy/low_latency/observation_config.yaml \
--input-type zmq_manager \
real

Data collection and VLA execution build on this stack — see Data collection and the VLA workflow.

Planner ONNX file

The kinematic planner runs alongside the policy when planner mode is enabled. It is an ONNX model passed with --planner-file (required for ROS2, gamepad_manager, and zmq_manager planner mode). Official example path:

--planner-file planner/target_vel/V2/planner_sonic.onnx

In the deployment flow the planner generates target animations (when enabled), the motion reader provides reference motions for non-planner mode, policy inference runs encoder → decoder on TensorRT, and results are published over ZMQ or ROS2. Sanity-check an ONNX model's input/output info with just run freq_test policy/example/model_step_000000.onnx — the reported frequency is not TensorRT inference speed. For VR teleoperation and the ZMQ manager modes, see the teleoperation guide.

Install & deploy FAQ

Why does the installation page insist on exact TensorRT versions?

The official docs carry a danger warning: you must use the exact TensorRT versions listed (10.13 on x86_64, 10.7 on Jetson with JetPack 6). Using a different version is known to produce incorrect inference results — the planner will output wrong motion, which can cause dangerous robot behavior.

Do I need to flash my G1's onboard Orin to JetPack 6 before deploying?

For G1 onboard deployment, the official docs require the onboard Orin to be upgraded to JetPack 6 to support TensorRT. The flashing guide (docs/source/references/jetpack6.md) covers the upgrade; the Jetson TensorRT 10.7 TAR package requires it.

Native install or Docker — which should I pick?

Native development is recommended by the official docs: direct system installation, faster builds, production-ready. The Docker image is a ROS2 development environment (ROS2 Humble, x86_64 and Jetson) — use it if you plan ROS2-based input/output. Both paths run the same inside-container/terminal commands: source scripts/setup_env.sh, then just build.

What exactly does deploy.sh run on the real robot?

From gear_sonic_deploy/, ./deploy.sh --input-type zmq_manager real starts the C++ deployment stack: TensorRT policy inference (encoder → decoder) plus the kinematic planner, with ZMQ manager input/output. In simulation, the same command uses the sim argument instead of real and pairs with run_sim_loop.py.