Goal
Deploying cuRobo is not just docker run. You need to know which versions are running, which upstream issues affect your runtime design, how to roll back, and when the planner is allowed to send commands to real hardware. This final guide covers both robot arms on Jetson AGX Orin 64GB and Unitree G1 arm/whole-body workflows.
Current upstream issues to watch
As of 2026-06-19, the NVlabs/curobo GitHub issues page shows 2 open issues:
| Issue | Type | Deployment impact |
|---|---|---|
#668 Per-call lock_joints override on a shared multi-arm MotionPlanner |
enhancement | Matters for G1 and multi-arm systems when legs, waist, or arms need different locks per request. Workaround: create explicit planner configs per mode instead of mutating one shared planner. |
#663 plan_grasp fails because the goalset plan_pose ... needs to run twice |
bug | Matters for grasp pipelines. Workaround: log each segment and fall back to separate approach/grasp/lift plan_pose calls. |
These issues do not block every deployment, but they influence runtime design. In particular, do not force every G1 mode into one shared planner when joint locking must vary by request.
Lock the deployment matrix
deploy_matrix:
jetpack: "R36.x"
cuda: "12.x"
python: "3.11"
pytorch: "pinned aarch64 wheel"
curobo_commit: "git sha"
robot_config: "my_arm.yml sha256"
container_image: "registry/org/curobo-jetson:date-sha"
Without this matrix, you cannot debug why planning worked yesterday and fails today.
Robot arm pre-flight checklist
- FK/IK regression poses pass.
- Collision spheres are visualized and do not false-collide with the table.
- Planner warmup finishes before goals are accepted.
- Joint state age is below threshold.
- Scene age is below threshold.
- Trajectory is clamped for velocity and acceleration.
- Controller action cancel works.
- Hardware E-stop has been tested.
- A
plan_onlymode exists.
Unitree G1 pre-flight checklist
- Arm-only mode has explicit leg/waist locks.
- The bridge reads base IMU/state before sending arm targets.
- The first arm workspace is limited to a box in front of the chest.
- Whole-body output is not sent directly to motors without a stabilizing controller.
- Offline retargeting has been replayed in simulation.
- The 6-DOF virtual base is treated as an optimization variable, not a hardware command.
Canary rollout
plan_onlyinside the production container.- Execute in simulation with the same URDF/config.
- Hardware powered with motors disabled or gravity compensation.
- Low-speed single-joint motion.
- Small Cartesian box.
- Static scene obstacle.
- Dynamic depth scene.
- Light grasp or small G1 arm-only task.
Every step needs p50/p95/p99 latency and failure-status logs. Do not expand scope while p99 is unstable.
Rollback
Rollback should be an image tag change, not SSH edits on Jetson:
docker pull registry/org/curobo-jetson:previous-good
docker stop curobo_planner
docker run --rm --name curobo_planner registry/org/curobo-jetson:previous-good
Keep at least one previous-good image tested with the same robot config. Rolling back the image without rolling back the YAML config may still fail.
Conclusion
cuRoboV2 is a strong GPU motion generation stack, but safe deployment requires a version matrix, a ROS 2 bridge with watchdogs, explicit scene snapshots, and awareness of upstream issues. For robot arms, the main risks are collision and trajectory limits. For Unitree G1, the main risks are balance and the boundary between arm-only and whole-body modes.
