cuRobo: GPU motion generation, and the v2 API break you have to plan around

What cuRobo does, and what it is built on

cuRobo is a CUDA-accelerated library for robot motion generation, built on PyTorch, CUDA and Warp. The README lists GPU-parallel algorithms for forward and inverse kinematics, collision checking, trajectory optimization, geometric planning, GPU-native perception and whole-body motion generation, and puts the range as scaling from single-arm manipulators to high-DoF humanoids.

The Warp dependency is the interesting one for reading the code. pyproject.toml pins warp-lang at 0.10.0 or newer, alongside numpy, scipy, trimesh, yourdfpy for robot description files, networkx, numpy-quaternion and viser, which is the visualisation server. That combination says the numeric work is expressed as kernels rather than as loops, with PyTorch holding tensors on the device and Warp providing the kernel layer.

Two other details in the packaging tell you how this is consumed. The distribution name on PyPI is nvidia-curobo, not curobo, and the version is dynamic through setuptools_scm. The package still ships CUDA C++ under the hood, with a .clang-format file and a .clangd configuration at the top level, so this is a compiled project that happens to have a Python front end.

The stated goal is collision-free motion generation that combines IK, geometric planning and trajectory optimization, in that order, so that a request for a reachable pose becomes a planned path and then a dynamically sensible one.

The v2 break, and the tag that is the escape hatch

The first note in the README is a migration warning. cuRoboV2 is described as a significant rewrite whose public API has changed from cuRobo v1, and anyone depending on the v1 API is told to pin to the v0.7.8 tag.

That instruction is concrete and worth taking literally. Pinning a tag is cheap, but a pin is also a freeze: you get the API you know at the cost of whatever came after, including fixes.

The version list gives the shape of the decision. The newest entry is v0.8.0, titled cuRoboV2 research and Open Source, dated 2026-04-18. Before it sits v0.7.7 from 2025-04-25 with bug fixes and Isaac Sim 4.5 support, and v0.7.6 from 2024-11-22 carrying a claim of a 10x improvement in pose reaching accuracy.

So v0.7.8 is the last of the v1 line, sitting between a 2025 bug-fix build and the 2026 rewrite. An existing v1 user choosing to stay has a specific commit to hold, and a user starting fresh has no reason to.

The v2 pitch, stated in the note and the capability list, is dynamics-aware optimisation with depth-fused distance fields for high-DoF robots, which the citation gives a title and an arXiv identifier for.

Four capability blocks and what each one costs you

The key capabilities are grouped, and the grouping maps onto the pipeline of a motion request.

The first is trajectory optimization with a B-spline representation enforcing smoothness and torque limits. B-splines rather than per-waypoint control is the choice that makes smooth, dynamically feasible output possible, and the torque limit constraint is what stops the optimiser from producing a path that no motor can execute.

The second is GPU-native perception generating dense signed distance fields from depth images. An ESDF turns depth into a signed distance function, which turns collision checking into a lookup rather than a geometry query, and that is exactly the kind of workload that wants to be on a GPU.

The third is whole-body computation, described as topology-aware kinematics, differentiable inverse dynamics and map-reduce self-collision for high-DoF robots. Each term is doing real work: topology-aware kinematics handles robots whose joint graph is not a simple chain, differentiable inverse dynamics lets you reason about forces without a separate dynamics engine, and map-reduce self-collision is how you check every link against every other without a quadratic blow-up on a humanoid.

The fourth is the composition of IK, geometric planning and trajectory optimization into collision-free motion generation, which is the product-level claim and the one you should test against your own scenes first.

The ESDF claim, stated as the vendor states it

The README says the GPU-native ESDF perception generates dense signed distance fields from depth images, up to 10x faster than state of the art. That number is a claim by NVIDIA about a comparison the README does not describe, and the phrasing carries its own caveat: up to, and faster than a category rather than a named baseline.

It is worth sitting with what the claim does and does not tell you. It does not say the field is 10x more accurate, or that collision checking downstream is 10x faster overall, only that generating the field is faster than the comparison point. Distance field generation is a per-pixel operation over depth images, which is the kind of work where GPU arithmetic and dense memory access genuinely beat a CPU loop, so the direction of the claim is not surprising even if the factor is context-dependent.

What matters for an integrator is that ESDF representation changes downstream code. Once collision is a distance lookup, your obstacle representation is the field rather than a mesh, and anything that used to query geometry directly needs to change with it. The v0.7.6 entry mentioning a 10x improvement in pose reaching accuracy is a related signal: in IK, better distance queries translate into finding more reachable poses.

Treat both numbers as marketing-adjacent and evaluate them on your own sensor, resolution and scene density.

Installing: the CUDA extra matrix and a deprecated compile path

The packaging splits by CUDA major version and by whether you want torch pulled in, with four optional dependency groups: cu12 and cu13 for the runtime stack, and cu12-torch and cu13-torch for the versions that also require torch 2.5 or newer.

Each group pulls cuda-core for the matching CUDA version and an NVIDIA runtime package, and the CCCL packages are present but commented out with a note that they are needed only for the cooperative groups headers. That is a helpful detail, because a commented dependency with a stated reason is a much better sign than a silent one.

setup.py handles something that has been deprecated. The file states that it handles optional CUDA extension compilation via pybind11, that package metadata now lives in pyproject.toml following PEP 621, and that using pybind-compiled extensions is deprecated with the default being false in favour of cuda.core runtime compilation. The opt-in is an environment variable read at install time, and the comment shows the exact command:

CUROBO_USE_PYBIND=1 pip install -e . --no-build-isolation

If you do enable it, the nvcc flags are tuned for speed: --threads=8, -O3, --ftz=true for flush-to-zero, --fmad=true for fused multiply-add, --prec-div=false and --prec-sqrt=false, plus --generate-line-info. On Windows the setup appends --allow-unsupported-compiler.

One implementation detail in that file is a good warning about the kernel layout: headers live in nested subdirectories such as optimization/lbfgs/ and are included by bare filename, so every subdirectory has to be on the include path, and the code builds that list by walking the kernels root.

Benchmarks, citations and repository hygiene signals

A few things in the tree tell you how seriously this is maintained, and they matter for a library you will build a robot on.

There is a benchmark/ directory at the top level, which is the right instinct for a project whose headline capability is GPU acceleration: you should be able to reproduce the numbers. There are also files for contribution guidance, an AGENTS.md and an .agent/ directory, so the project carries instructions for both humans and automated assistants, plus a MANIFEST.in for packaging.

The citation block is unusually complete for a README. It names the work, gives three authors, the year, the arXiv identifier, the archive prefix and the primary class, formatted as a BibTeX misc entry. If you use this in a publication, the citation refers to cuRoboV2 with the title Dynamics-Aware Motion Generation with Depth-Fused Distance Fields for High-DoF Robots, which is the phrasing that tells you where v2 puts its weight.

The contrast between the two ways this project reports itself is informative. The capability list uses performance language, with the 10x claim, while the process sections are plain and procedural: issues for bugs, Discussions for usage questions, CONTRIBUTING.md for pull requests, and a DCO sign-off on every commit. Nothing here is trying to sell you a roadmap.

Where cuRobo is the wrong choice

The first boundary is the API break, which is already covered and is the reason to read the note before anything else.

The second is hardware. Everything here is CUDA, and while the classifiers say Operating System OS Independent, that describes the packaging rather than the capability. There is no CPU fallback for the GPU-parallel paths in the feature list, and the whole design assumes you have an NVIDIA GPU and a driver matching your chosen CUDA extra.

The third is scope. This is a motion generation library, not a robot stack. It does not provide hardware drivers, a simulator, a perception front end beyond generating an ESDF from depth, or a policy that decides what motion to request. If your problem is that you do not have a trajectory, you can get one; if your problem is that you do not know what trajectory you want, this does not answer it.

The fourth is the asset and dependency situation. The bundled example robot assets are provided under their own terms with details in a separate file, and installation can pull additional third-party open source projects whose terms you are expected to review before use. Both statements are unusually explicit, and both are reasons to read before you ship something that depends on this.

The fifth is process. Contributions require a DCO sign-off with git commit -s, bugs go to issues, usage questions go to Discussions, and pull requests are expected to follow CONTRIBUTING.md. That is a well-run process rather than a barrier, but it is the project telling you what working with it involves.

Editorial conclusion

Adopt cuRobo if you are doing robot motion generation on NVIDIA hardware and want kinematics, planning and optimisation in one GPU-resident stack, especially for high-DoF robots where the whole-body path with topology-aware kinematics, differentiable inverse dynamics and map-reduce self-collision is the reason to use this rather than a single-arm library. Do not adopt it if your code already depends on the v1 API and you have no room to migrate, because cuRoboV2 is a significant rewrite with a changed public API. Verify four things first. Decide the version, since the README tells v1 users to pin to the v0.7.8 tag while the newest listed version is v0.8.0, and that intermediate tag is the migration cliff. Pick your CUDA extra, because the packaging offers cu12 and cu13 variants plus torch-flavoured ones, and a mismatch between your driver and that extra is the most common install failure. Read the terms before you ship, because the code is Apache 2.0 while bundled robot assets carry their own and installation can pull additional third-party projects whose licences you are expected to review. And confirm your GPU expectations, since the classifiers say OS Independent while the whole implementation is CUDA. Start by installing nvidia-curobo with the extra matching your CUDA version and running one IK problem on a single arm.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. NVlabs/curobo on GitHub
3. Project website
4. README
5. Releases