Why cuRobo needs its own deployment series
cuRobo is NVIDIA's CUDA-accelerated robot motion generation library, built on PyTorch, CUDA, and Warp. The current cuRoboV2 release is more than a classic arm planner: it includes GPU kinematics, collision checking, trajectory optimization, geometric planning, depth-fused mapping, grasp planning, and whole-body motion generation. The important operational detail is that cuRoboV2 is a major rewrite. If your stack still depends on the v0.7 API, pin v0.7.8 instead of mixing old examples with the new API.
This series targets a concrete deployment path: run cuRobo on a Jetson AGX Orin 64GB for a robot arm, then extend the same mental model to Unitree G1 arm-only and whole-body workflows. The emphasis is deployability: model building, solver checks, ROS 2 integration, safety gates, issue review, and rollback.
2026-06-20 update: read this series as cuRoboV2
The current cuRobo documentation describes V2/v0.8.x as a major rewrite: B-spline trajectory optimization, GPU-native TSDF/ESDF mapping, topology-aware whole-body kinematics, and a humanoid MotionRetargeter API. Treat this series as a deployment guide for cuRoboV2, not as a copy-paste archive of the older v0.7 API.
On Jetson AGX Orin 64GB, the question is not only whether cuRobo imports. The runtime may hold PyTorch tensors, CUDA graph warmup, collision kernels, depth mapping, and ROS 2 nodes at the same time. If the environment is not pinned, failures appear late: planning works on a workstation but fails on Jetson; IK is correct but collision differs because spheres changed; or G1 retargeting looks smooth offline but jumps when streamed.
Use three gates while reading:
| Gate | Question before moving on |
|---|---|
| Model | Are URDF, meshes, joint order, TCP, and collision spheres correct? |
| Solver | Do FK/IK/planning/retargeting pass regression poses and p95/p99 latency checks? |
| Runtime | Are ROS 2 bridge, watchdogs, scene snapshots, rollback image, and E-stop ready? |
If you only read one article before touching hardware, read part 10 for upstream issues and deployment checks. If you start from zero, follow parts 2-6 for a robot arm, then parts 8-9 for Unitree G1.
Runtime architecture
Depth / RGB-D / world model
|
v
Scene representation: cuboids, meshes, ESDF/TSDF
|
v
cuRobo: FK, IK, self-collision, world collision, trajectory optimization
|
+--> Robot arm joint targets / trajectory
|
+--> Unitree G1 arm targets / whole-body retargeting targets
|
v
Safety gate: joint limits, velocity, torque, E-stop, watchdog
|
v
ros2_control / vendor SDK / low-level controller
For a fixed arm, cuRobo normally acts as the planner: it receives a start joint state, a goal pose, and world obstacles, then returns a joint trajectory. For Unitree G1, split the problem into two modes. Arm-only mode keeps the legs and waist governed by a separate stabilizing controller. Whole-body mode uses a floating base, tool frames for pelvis, feet, elbows, and wrists, then solves multi-target IK/MPC or motion retargeting.
Is Jetson AGX Orin 64GB enough?
Yes, for scoped online workloads: single-arm planning, reactive IK, collision checking over moderate scenes, and G1 upper-body planning at lower planner rates. The 64GB memory budget is useful because PyTorch, CUDA kernels, perception nodes, and ROS 2 processes can coexist. The risk is not raw memory; it is version compatibility, thermals, and reproducibility.
Use a workstation for heavy tuning, sphere fitting, broad seed sweeps, and benchmark exploration. Use Jetson as the target runtime with a pinned container image, pinned CUDA/PyTorch/cuRobo versions, and a known JetPack base.
The 10 guides
- Architecture and version boundaries: where cuRobo belongs in the robot stack.
- Installing cuRoboV2 on Jetson AGX Orin 64GB: pin JetPack/CUDA/PyTorch/uv.
- Building a robot model from URDF: meshes, spheres, and self-collision.
- FK, IK, and frame convention checks: catch quaternion, TCP, and joint-order bugs.
- Motion planning with obstacles and grasping: tune seeds, grasp segments, and fallbacks.
- ROS 2 bridge from planner to controller: action interface, retiming, watchdogs.
- Scene mapping from depth cameras: cuboids first, TSDF/ESDF later.
- Unitree G1 arm-only planning: lock legs/waist and gate commands.
- Unitree G1 whole-body retargeting and MPC: floating base, tool frames, SOMA/BVH.
- Deployment checklist, current issues, rollback, and operations: pre-flight, canary, rollback.
Baseline hardware
| Area | Recommendation |
|---|---|
| Compute | Jetson AGX Orin 64GB, NVMe SSD, active cooling |
| OS | JetPack/Ubuntu matching CUDA 12.x |
| Robot arm | Clean URDF, per-link meshes, correct joint limits |
| Humanoid | Unitree G1 29-DOF URDF/config and separate low-level control |
| Sensor | RGB-D or depth camera with stable timestamps |
| Safety | Hardware E-stop, software watchdog, velocity clamps |
Primary references
- cuRobo docs: https://nvlabs.github.io/curobo/latest/index.html
- cuRobo GitHub: https://github.com/NVlabs/curobo
- Installation: https://nvlabs.github.io/curobo/latest/getting-started/installation.html
- Build Robot Model: https://nvlabs.github.io/curobo/latest/getting-started/build_robot_model.html
- Humanoid Retargeting: https://nvlabs.github.io/curobo/latest/getting-started/humanoid_retargeting.html
Conclusion
For arm planning, cuRobo can replace parts of a MoveIt-style stack when low latency and many parallel GPU seeds matter. For Unitree G1 whole-body work, treat cuRobo as a solver and retargeting component inside a larger stack, not as the only balance controller. The next article locks down the Jetson installation.
