cuRoboV2-Fast: Fast Torque-Limited Collision-Free Motion Planning

TL;DR

cuRoboV2-Fast is NVIDIA LPR’s next-generation GPU-accelerated motion planner for collision-free, torque-limited, payload-aware robot arm motion, companion to an arXiv preprint (2611.06913). It replaces cuRoboV1’s waypoint-at-fixed-timestep trajectory optimization with a B-spline parameterization refined by L-BFGS, a separately-optimized TimeOpt stage for traversal-speed-along-the-fixed-path exploiting the spline’s local support to produce banded Newton systems, and accelerated GPU kernels for kinematics / inverse dynamics / collision checking. At 3 kg payload the planner reports 4.4 ms mean planning time on an RTX 5090 (14.7× over cuRoboV2) and 26.0 ms on Jetson AGX Orin (23.2× over cuRoboV2); on a real YAM arm it cuts mean pick-and-drop cycles 34.6% to 5.93 s. A parallel GPU RRT provides route initialization only when needed; differentiable inverse dynamics accommodates runtime payload inertia updates without recompilation.

Key claims

B-spline trajectory optimization refines manipulation geometry with fewer L-BFGS iterations than per-waypoint fixed-timestep representations; after 25 iterations 93% of queries succeed vs cuRoboV1 requiring 5× as many iterations [§Fewer Iterations].
At 5 kg payload the full stack (B-spline refinement + TimeOpt + differentiable inverse dynamics) succeeds on 93% of queries vs cuRoboV1’s 78%, with torque limits becoming the dominant feasibility constraint at this payload [§TimeOpt torque chart].
TimeOpt parameterizes squared path speed as a B-spline, enforces sampled velocity/acceleration/jerk/torque constraints, and exploits the spline’s local support to solve banded Newton systems efficiently on GPU — the time parameterization step inherits the same O(1)-per-control-point gradient structure as the geometry step [§TimeOpt].
Parallel GPU RRT finds seeds in 0.3 ms — reported as the fastest GPU RRT — and is invoked only when B-spline refinement fails to find a feasible solution directly [§For hard problems].
Kernel-level attribution identifies kinematics, inverse dynamics, collision checking, and cost reductions as the four dominant per-iteration costs; each is attacked with a specific GPU restructuring (spline-aware gather+reduction, parallel chain traversal, link + swept bounds skipping, fused cost reduction + gradient accumulation) [§Kernel profiling].
Differentiable inverse dynamics maps torque-loss gradients directly to joint-state gradients and accepts runtime updates to payload mass / center of mass / inertia without kernel recompilation — load-bearing for picking tasks where carried-object dynamics change mid-execution [§Inverse dynamics].
Full planning pipeline (IK + linear seed + conditional RRT + B-spline opt + TimeOpt + validation) at 3 kg: 4.43 ms mean on RTX 5090, 25.99 ms on Jetson AGX Orin — 14.7× and 23.2× faster than cuRoboV2 on the same hardware [§Full-planning times].
cuRoboV2-Fast on Jetson AGX Orin plans faster than cuRoboV1 + TOPPRA on RTX 5090, inverting the desktop-vs-edge planning-latency gap [§Fewer Iterations].
In simulation, two-cube pick-and-place completes in 7.7 s vs 11.0 s (cuRoboV1) and 13.8 s (cuRoboV2) — motion-planner choice alone changes task cycle time by nearly 2× [§Simulation side-by-side].
On a real YAM arm driven end-to-end by SceneFields (depth + detection + robot masks) + GraspGenX (grasp proposals) + cuRoboV2-Fast, each planning call takes 23 ms and planning accounts for 1% of total cycle time; arm motions are 45% shorter and cycles 35% shorter than cuRoboV2 — the 500-episode statistics include dynamic replan against moved obstacles and against failed-grasp retries [§Real-robot deployment].

Method

The planner is a full-stack GPU replacement for the cuRoboV2 pipeline, structured around two separate optimization stages. Geometry refinement: a B-spline over joint configurations is optimized with L-BFGS on the GPU, with each iteration evaluating the spline, running kinematics and inverse dynamics on parallel GPU streams, evaluating costs, and gathering gradients back to the spline control points via a single warp reduction per control (no atomics). Kinematics computes local link poses in parallel; its backward pass gathers a wrench per link and maps it to joint gradients in one chain traversal rather than one per sphere (the collision primitive). Inverse dynamics runs the per-link chains in parallel and maps torque-loss gradients directly to joint-state gradients. Collision checking uses link bounds to skip separated links and swept bounds to skip distant obstacles; adjacent half-sweeps share a distance evaluation and combine gradients before rotating them to world frame. A fused cost reduction + gradient accumulation kernel removes separate pointwise and gradient-add launches.

Time parameterization (TimeOpt): once geometry is fixed, TimeOpt separately optimizes traversal speed along the fixed path, representing squared path speed as a B-spline and enforcing sampled velocity, acceleration, jerk, and torque constraints. Because the spline has local support, the Newton system is banded and admits efficient GPU solution — a different exploitation of B-spline structure than the geometry stage’s spline-aware gradient gather.

RRT fallback: a parallel GPU RRT provides a route initialization only when B-spline refinement fails. At 3 kg the direct linear seed succeeds on most queries; RRT seeds are invoked on hard problems where obstacles block direct interpolation.

Payload handling: differentiable inverse dynamics accepts runtime updates to payload mass, center of mass, and inertia — the planner can re-plan for a 5 kg load mid-execution without recompiling kernels, which is what makes the system robust for pick-and-drop cycles where carried-object dynamics change at each grasp.

Real-robot deployment on YAM pairs cuRoboV2-Fast with SceneFields (depth + object detections + robot masks) and GraspGenX (grasp pose proposals): SceneFields constructs the scene representation, GraspGenX samples grasp candidates, and cuRoboV2-Fast plans each candidate’s approach + lift + transfer in 23 ms, with plans re-issued when grasps fail or when obstacles move.

Results

Planning latency (3 kg payload): 4.43 ms mean on RTX 5090, 25.99 ms on Jetson AGX Orin — 14.7× faster than cuRoboV2 on RTX 5090, 23.2× on Jetson Orin.
Cross-hardware inversion: Jetson AGX Orin running cuRoboV2-Fast beats RTX 5090 running cuRoboV1 + TOPPRA on wall-clock planning time.
Payload-constrained success: at 5 kg, 93% success vs cuRoboV1’s 78%, with the gap opening on torque-feasibility edges.
RRT seed latency: 0.3 ms on RTX 5090, reported as the fastest GPU RRT.
Simulated two-cube pick-and-place: 7.7 s end-to-end cycle vs 11.0 s (cuRoboV1) and 13.8 s (cuRoboV2) — nearly 2× cycle-time reduction attributable to the planner alone with identical scene and grasp specification.
Real YAM mean pick-and-drop cycle: 5.93 s — 34.6% shorter than cuRoboV2 — on an RTX 6000 Ada GPU driving the full SceneFields + GraspGenX + cuRoboV2-Fast loop.
Real-robot planning-share-of-cycle: 1%, i.e. planning is no longer the dominant per-cycle cost.
Arm motion length: 45% shorter on real hardware than cuRoboV2 across the deployed pick-and-drop run.
Qualitative deployment behavior: reports transferring 7 objects in 1 min 22 s continuously, bin-picking with per-grasp replanning around bin walls and neighboring objects, automatic replan on grasp failure, replan under moving-obstacle scene updates, and mapping + grasping + transferring a newly-placed box in under 7 seconds.

Why it’s interesting

cuRoboV2-Fast sits one layer below the VLA / LLM-as-controller debate on VLA Models: the LLM-as-controller row consistently exposes planning as a tool (AGP calls EE-pose targets against a motion-planner tool harness Agent as Policy for Robotic Manipulation; GPT-6 Astra drives real arms via IK + a motion-planning tool harness Wenli Xiao — GPT-6 Astra does physical in-context learning from a single human video via a motion-planning tool harness; SkipVLA routes free-space transit to a classical motion planner so a frozen VLA is called only for contact-rich primitives SkipVLA: Skipping VLA Steps with Classical Planning for Fast Robot Manipulation), and cuRoboV1 / TOPPRA was the dominant free tool in that slot — cuRoboV2-Fast plus a 14.7× latency reduction and torque-limit awareness changes the economics for every entry on that row, especially the Jetson-class variant where 26 ms planning makes closed-loop LLM-as-controller stacks feasible on edge hardware for the first time.

The design also operationalizes the IO-Aware Kernel Design template outside the attention/LM-head family it has been developed in: TimeOpt’s exploitation of B-spline local support to produce banded Newton systems is the same algebraic-structure-of-the-intermediate lever Gram Newton-Schulz uses for symmetric GEMMs (Gram Newton-Schulz: A Fast, Hardware-Aware Newton-Schulz Algorithm for Muon), and the fused cost-reduction + gradient-accumulation kernel removing separate pointwise and gradient-add launches is the same produce/reduce-pair fusion pattern FlashAttention and Flash-KMeans apply (FlashAttention-4: Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling, Flash-KMeans: Fast and Memory-Efficient Exact K-Means) — now transplanted onto classical robot trajectory optimization rather than attention or k-means. Complements the VLA serving-runtime line (APXinf-robo — Edge Inference Engine for VLA/WAM Models on Jetson Thor / Orin APXinf-robo, InstinctFlash — High-Performance Serving Runtime for Robotics Models InstinctFlash, Embodied.cpp: A Portable Inference Runtime of Embodied AI Models on Heterogeneous Robots Embodied.cpp) on the deployment side: those stacks speed up the VLA call; cuRoboV2-Fast speeds up the planning call that often sits in series with it or substitutes for it on free-space segments.

Finally, the 1%-of-cycle result reframes where latency budget now goes in a classical-planner + grasp-proposer + perception stack: with planning at 1% and SceneFields/GraspGenX dominating, the next optimization target shifts from the planner to the perception front-end — concrete empirical answer to “when you have fast enough motion planning, what is the new bottleneck.”