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 the 2026-06-20 update, 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.
If a post does not appear in the blog listing
With a static/Next.js blog, a post can open by direct URL but still fail to appear correctly in the listing or series section. Quick checks:
| Check | Why it matters |
|---|---|
Both content/posts/<slug>.mdx and content/posts/en/<slug>.mdx exist |
VI files are the source of truth; EN has its own fallback |
date is not in the future |
Future-dated posts are hard to see in sorting/filtering and SEO |
series and seriesPart are set |
The series section groups only posts with frontmatter.series |
category/type/level are valid |
Filters and category counts stay correct |
npm run build passes |
Catches YAML/MDX errors before deploy |
| Cloudflare cache is purged | The listing may otherwise show old content |
For this cuRobo series, the initial visibility bug was missing series/seriesPart metadata in the 20 MDX files. The correct fix is frontmatter, rebuild, redeploy, and cache purge; no route change is needed.
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.
Discord/auto-blog operations checklist
If the series is managed through the Discord bot, add these checks:
!series-update <slug> --improve --add Nupdates old parts and appends new ones.!codex-statuschecks Codex login status on the server.!codex-logincreates a login URL/device code directly in Discord.- If the Codex token expires, auto-blog falls back to Claude, but long jobs may run slower or produce a different writing style.
- After Codex login, run
!codex-statusagain before launching a long!series-updatejob.
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.
