Curobo
Skill and tool bundles for gap (graph as policy) — Anthropic Agent Skills format, discovered by path
npx -y skills add graph-robots/open-robot-skills --skill curoboAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
NVIDIA cuRobo motion planning — collision-free trajectories to grasp goalsets, transport with an attached object, constrained linear moves, single-pose planning, geometric IK, batch grasp feasibility, and joint-trajectory collision validation. Use when a workflow needs GPU-accelerated, collision-aware arm motion plans.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.8 KB, as published. Nobody here has run it
curobo
Collision-aware cuRobo motion planning as in-process tools. Trajectories
in/out are gap Trajectory dicts (waypoints: [{positions: float64[dof]}]); worlds are gap WorldConfig dicts (build one with
geometry.build_world_config).
When to use
- Tabletop pick:
geometry.top_down_grasp_candidates→curobo.plan_to_grasp_poses(pass the whole fan as the goalset; checkgoalset_indexfor which one was reached). - Transport after grasping:
curobo.plan_with_grasped_objectwith the object's mesh name frombuild_world_config. - Drawers/doors:
curobo.plan_grasp_motion(approach → grasp → lift/pull with gripper commands interleaved), orcurobo.plan_directed_linearfor a pull along one axis with orientation locked.
Install
cuRobo JIT-compiles CUDA extensions at install time — build isolation must
be off and CUDA_HOME must point at a toolkit matching your torch build:
export CUDA_HOME=/usr/local/cuda # toolkit matching torch's CUDA version
uv sync --extra curobo # (pip: pip install -e ".[curobo]" --no-build-isolation)
If the import fails at tool-call time the tools raise a ToolError with
this recipe. First planner call per process pays JIT/warmup latency; the
MotionGen/planner instances are cached and reused (HyRL pattern — recreating
them per call corrupts CUDA graph state).
Gotchas (carried over from the service + curobo_api)
- Frames: grasp/target poses are in the robot-base frame (cuRobo treats
the robot base as world origin). With
grasp_pose_is_fingertip=True(default) grasp positions are fingertip-pad centers and converted to thepanda_handframe solver-side (offset 0.1029 m along hand Z). - Ignore the grasp target: pass its mesh name in
ignore_obstacle_namesforplan_to_grasp_poses/batch_grasp_feasibility— closing on the target is not a collision. robot_collision_sphere_bufferdefault −0.01 shrinks robot collision spheres 1 cm; reduces IK_FAIL against dense perception meshes. Negative is intentional.- GPU access is serialised by a module lock (cuRobo is not thread-safe);
CUDA/"graph capture" errors invalidate the cached planners automatically
before raising
PlanningFailed. use_cuda_graphmust stay False for the validators (check_start_staterequirement) and for varying world/start setups.- curobo version split:
plan_to_grasp_poses,plan_grasp_motion,plan_directed_linear,plan_linear,plan_to_pose,plan_with_grasped_objecttarget curobo v0.8 (MotionPlanner API);solve_ikandbatch_grasp_feasibilityare built on the v0.7 IKSolver API that v0.8 removed — on a v0.8-only install they raisePlanningFailed("not supported on cuRobo v0.8"); plan via the goalset tools instead. The validators use the v0.7 MotionGen path too. validate_joint_trajectory_graspedalways invalidates the planner cache afterward so the attachment cannot leak; expect the next planning call to re-create the planner.- Planning failures return
success=False(withfailure_reasonwhere the RPC had one); infrastructure errors raisePlanningFailed/ToolError. - Set
debug_out_diron the grasp/transport planners to dump world + robot sphere OBJ/PLY debug artifacts on failure (default./curobo_debug*).