cuRobo

Use this skill when a task names cuRobo/cuRoboV2, NVIDIA robot motion planning, GPU kinematics, collision-free IK, B-spline trajectory optimization, MPC, TSDF/ESDF mapping, or whole-body motion retargeting. This is a v2 skill; the v1 API is a separate compatibility target and should be pinned to the repository's documented v0.7.8 release rather than mixed into these routes.

Operating contract

• Treat CUDA as a core prerequisite. cuRobo's kinematics, collision, solver, planning, and mapper kernels are not honestly validated by a CPU import.
• Use float32 tensors unless a cited API requires otherwise. Keep tensors and DeviceCfg on the same CUDA device, and select a free device explicitly on shared hosts.
• Prefer the public modules (curobo.kinematics, curobo.types, curobo.inverse_kinematics, curobo.motion_planner, curobo.trajectory_optimizer, curobo.model_predictive_control, curobo.scene, curobo.collision_checking, curobo.perception, and curobo.motion_retargeter). Use _src only when a documented public wrapper does not expose a required configuration or diagnostic.
• Keep CUDA graphs enabled for normal runtime. Disable them only for bounded tests/debugging when eager execution is needed to expose a failure.
• Resolve bundled robot/task YAML through cuRobo's content-path mechanisms; do not invent paths relative to a vanished checkout.

Install and inspect

For a supported Linux + NVIDIA driver, create Python 3.10–3.13 (3.11 is the most conservative choice) and install one matching CUDA extra:

uv venv --python 3.11
uv pip install .[cu13-torch]  # fresh install for a CUDA 13 driver/runtime
# or .[cu12-torch] for a CUDA 12 installation
python -c "import curobo, torch; print(curobo.__version__, torch.cuda.is_available())"

Use . [cu13]/.[cu12] only when PyTorch is already installed. The package requires Warp, PyYAML, SciPy, trimesh, yourdfpy, and other base dependencies; pybind, usd, doc, and benchmark are optional and not needed for core solver use. Follow references/installation-and-runtime.md for compatibility, device, CUDA graph, and optional-dependency decisions.

Route by task

User intent	Read next
Load URDF/YAML, build a robot, FK/Jacobians, joint/pose tensors	robot-models
Solve pose IK, batched/reachability IK, collision-aware IK, update obstacles	ik
Plan collision-free pose/c-space/grasp paths or use graph planning	motion-planning
Configure trajectory optimization, MPC, custom costs, rollout, or reactive control	mpc-optimization
Model obstacles, self-collision, sphere approximations, collision queries	collision-scenes
Integrate depth/LiDAR, TSDF/ESDF, feature grids, pose estimation	perception
Retarget frame/pose sequences or humanoid motion	retargeting

Cross-cutting API signatures and configuration relationships are in references/api-map.md. Read references/troubleshooting.md before changing an install, device, YAML, or solver lifecycle. The source snapshot and refresh baseline are in references/repo-provenance.md.

Minimal decision sequence

1. Identify robot model, tool frame(s), device, dtype, scene, solver family, batch/horizon requirements, and whether the request is online or offline.
2. Validate torch.cuda.is_available() and allocate a tiny tensor on the selected device before constructing a solver. Treat out-of-memory as a device-selection/resource problem, not as an API failure.
3. Choose the narrowest public config factory and bundled YAMLs. Keep robot, optimizer, transition, metrics, and scene configs mutually compatible.
4. Start with a tiny deterministic target and inspect success, position and orientation errors, trajectory validity, collision distances, and device shapes. Scale seeds/batches/horizons only after the small case is sound.
5. For a failure, preserve the config and result diagnostics, then consult the owning sub-skill's troubleshooting reference; do not mask it by disabling collision checks or CUDA graphs without recording the reason.