cuRoboV2-Fast: 4.4 ms Motion Planning With a 3 kg Payload

Ask anyone who has integrated a robot arm and they will tell you where the time goes. Not in the grasp planner, not in the perception stack: in the motion layer that has to turn a desired pose into a collision-free, dynamically feasible trajectory, over and over, while the rest of the system waits. A planner that takes a hundred milliseconds is fine for a demo and fatal for a 3-second cycle.

cuRoboV2-Fast, from NVIDIA’s robotics group, is a direct attack on that budget. The headline numbers are 4.4 ms mean planning time with a 3 kg payload on an RTX 5090, a 14.7x speedup over cuRoboV2, and a real pick-and-drop deployment on a YAM arm whose mean cycle time drops to 5.93 s, 34.6% shorter than the previous version.

Core innovation

B-spline trajectory optimisation to cut iterations. Representing the trajectory in a spline basis with local support means a change to one control point does not ripple through the whole horizon. Fewer iterations to convergence is the most reliable kind of speedup, because it does not depend on a particular GPU.

Differentiable inverse dynamics for payload awareness. This is the part that distinguishes the work from generic GPU planning. A 3 kg payload changes the torque required at every joint, and the planner refines trajectories against a differentiable inverse dynamics model, so the cost of carrying the object is inside the optimisation rather than checked afterwards. Payload-aware planning matters in exactly the settings where planning speed pays: bin picking with varying masses, machine tending, anything where the gripper’s contents change between cycles.

TimeOpt on the GPU. Once the geometric path is fixed, a separate stage optimises traversal speed along it under sampled velocity, acceleration, jerk and torque constraints. Because the spline’s support is local, the resulting Newton systems are banded, and banded systems solve efficiently in parallel. That is the structural reason this stage is fast on a GPU rather than merely ported to one.

Results

The 4.4 ms figure is a mean, with a 3 kg payload, on a desktop-class RTX 5090. Means hide tails, and in industrial deployment the tail is what breaks cycle-time guarantees; the abstract does not report a worst-case or 99th-percentile planning time. Readers should treat 4.4 ms as evidence of a large margin rather than a latency guarantee.

The more interesting comparison is the embedded one: on a Jetson AGX Orin, cuRoboV2-Fast plans faster than cuRoboV1 with TOPPRA does on an RTX 5090. Cross-version and cross-hardware comparisons are not controlled experiments, but the direction of the claim is what matters commercially — the new planner puts real-time torque-limited planning on the robot’s own compute, without a datacenter GPU in the loop.

The deployment evidence is a stereo-camera setup on a YAM arm completing pick-and-drop cycles in 5.93 s on average, 34.6% shorter than cuRoboV2. Cycle time is the metric a line integrator actually buys, and it is measured end to end, including perception and execution, not just the planner’s internal clock.

Limitations

Three caveats. First, single-platform deployment: one arm, one task family, one camera configuration. Pick-and-drop is the easiest case for a planner, because the hard part is the grasp and the free-space motion is generous.

Second, the torque-limit modelling is only as good as the identified dynamics. Payload mass is modelled; where the centre of mass sits inside the payload, joint friction, and compliance in the mounting are the usual sources of mismatch, and none of them appear in the abstract.

Third, the speedups are reported against the authors’ own previous version, which is a fair regression test but not a comparison against other planners. Whether cuRoboV2-Fast beats a well-tuned sampling planner on a specific cell is a question each integrator will have to answer on their own hardware.

Industry implications

For integrators, the practical shift is that torque-limited, payload-aware planning becomes cheap enough to run every cycle instead of on a slow supervisory path. That enables replanning when a grasped object turns out heavier than expected, or when a human enters the workspace and the path has to change without stopping the arm.

The embedded result is the strategically important one. Robot cells have historically offloaded heavy planning to an industrial PC; a planner that runs on Jetson-class hardware collapses that architecture, cutting cost, cabling and latency. It also makes mobile manipulators more plausible, since the planner can live on the robot rather than on a nearby server.

The open-source licence lowers the barrier further. Apache 2.0 code from a major vendor means the barrier to trying this on a real cell is an afternoon, not a procurement cycle — and that, more than any single benchmark number, is how a planner becomes infrastructure.