PaperlayerView exact revision on arXiv

Source-linked AI summary

cuRobo: Parallelized Collision-Free Minimum-Jerk Robot Motion Generation

Balakumar Sundaralingam, Siva Kumar Sastry Hari, Adam Fishman, Caelan Garrett, Karl Van Wyk, Valts Blukis, Alexander Millane, Helen Oleynikova, Ankur Handa, Fabio Ramos, Nathan Ratliff, Dieter Fox

arXiv:2310.17274v2cs.ROcs.ARcs.DC

TL;DR

Collision-free manipulator motion generation requires trajectories that satisfy robot constraints while reaching a goal pose. cuRobo formulates this as global motion optimization and uses parallel GPU computation across its motion-generation pipeline. The paper reports a 60× speedup over state-of-the-art motion-generation methods on a modern PC, while validating trajectory tracking on two robots.

  • Problem

    Manipulator motion generation must find trajectories that reach a goal pose while satisfying joint limits and avoiding self-collision and environmental collision.

    Source: §2 · p. 6

  • Method

    cuRobo formulates global motion generation as optimization and combines GPU-parallel kernels, collision checking, geometric planning, and parallel trajectory optimization.

    Source: §1 · pp. 5–6, §2 · p. 6

  • Results

    60× speedup over SOTA motion-generation methods on a modern PC; UR5e and UR10 tracking errors were below the joint-encoder accuracy margin.

    Source: §6.5 · p. 28, §8 · p. 32

  • Takeaways & Limitations

    cuRobo packages GPU-accelerated robotics algorithms in a library released for integration into robotic pipelines.

    Source: §1 · p. 6, §8 · p. 32

    The current approach plans full motions from a static state, and reactive motion generation requires a fixed solve rate despite longer solve times on hard problems.

    Source: §8.1 · p. 32

Abstract

from arXiv · show

This paper explores the problem of collision-free motion generation for manipulators by formulating it as a global motion optimization problem. We develop a parallel optimization technique to solve this problem and demonstrate its effectiveness on massively parallel GPUs. We show that combining simple optimization techniques with many parallel seeds leads to solving difficult motion generation problems within 50ms on average, 60x faster than state-of-the-art (SOTA) trajectory optimization methods. We achieve SOTA performance by combining L-BFGS step direction estimation with a novel parallel noisy line search scheme and a particle-based optimization solver. To further aid trajectory optimization, we develop a parallel geometric planner that plans within 20ms and also introduce a collision-free IK solver that can solve over 7000 queries/s. We package our contributions into a state of the art GPU accelerated motion generation library, cuRobo and release it to enrich the robotics community. Additional details are available at https://curobo.org

NVIDIA

Figure 1 shows a Franka Panda moving a grasped object around obstacles to a target location using parallel motion generation within 30 ms.

NVIDIA

  • The Franka Panda moves a grasped object around obstacles to place it at a target location.The figure shows several instances of the approach.Source: Figure 1 · p. 1
  • The approach generates collision-free manipulator motions from a start configuration to a desired gripper pose.Source: Figure 1 · p. 1
  • 30 ms is the stated motion-generation time using parallel computing.Source: Figure 1 · p. 1

1 Introduction

The introduction frames robot navigation as a global motion-optimization problem, while noting that existing motion-generation systems are often sequential and slow. It presents GPU parallelism and a suite of algorithms as a way to run many optimization instances for these problems.

1 Introduction

  • High-dimensional robot motion generation must satisfy complex constraints while minimizing costs in a large configuration space.Manipulators may have many articulations, complex link geometries, goal regions, task constraints, and kinematic and torque limits.Source: §1 · p. 5
  • The paper frames robot navigation as a large global motion-optimization problem rather than only a path-planning and smoothing pipeline.Source: §1 · p. 5
  • Existing systems often use slow, sequential CPU planning and optimization, with pipelines betting on a single seed and limiting their ability to find better local optima.State-of-the-art motion-generation solutions take 0.5s to 10s on modern CPUs, depending on task complexity.Source: §1 · p. 5
  • The approach uses GPUs to parallelize the motion-generation pipeline, with the authors noting applicability to other parallel architectures.The paper describes GPUs as energy-efficient, high-throughput platforms that offer programmability and flexibility for motion-optimization computations.Source: §1 · p. 5
  • cuRobo combines parallelized kinematics and signed-distance kernels, continuous collision checking, optimization, and geometric planning in a GPU-accelerated robotics library.The collision-checking formulation uses a point signed-distance function and closest point for gradients, supporting world representations including primitives, meshes, and occupancy maps.Source: §1 · pp. 5–6

2 Motion Generation as Optimization

The paper formulates collision-free motion generation as trajectory optimization subject to joint, smoothness, and collision requirements. Its pipeline solves collision-free IK, creates trajectory seeds, then optimizes them in parallel and adjusts the timestep.

2 Motion Generation as Optimization

  • The target is a joint-space trajectory that reaches a goal Cartesian pose while respecting position, velocity, acceleration, and jerk limits and avoiding self-collision and environmental collision.Source: §2 · p. 6
  • The optimization is time-discretized, with joint-limit constraints and zero terminal velocity, acceleration, and jerk; the smoothness cost encourages smooth robot behavior.Source: §2 · p. 6
  • The pipeline first solves collision-free IK, then seeds trajectory optimization using interpolation from the start to the IK solution or other paths, including a retract configuration or geometric planner.Source: §2 · p. 6, Figure 2 · p. 7
  • Trajectory optimization runs on many seeds in parallel; particle-based optimization moves a seed to a good region before L-BFGS converges toward a minimum.Source: Figure 2 · p. 7, §2 · p. 7
  • The method scales the trajectory timestep to robot velocity, acceleration, or jerk limits, then reruns optimization with the estimated timestep.Source: §2 · p. 7

3 Kinematics & Collision Avoidance

cuRobo represents robot geometry with spheres and formulates collision avoidance through distance-based costs, including continuous checks along trajectories. Its collision queries support several world representations, while the continuous-checking implementation assumes linear motion between waypoints.

3 Kinematics & Collision Avoidance

  • Sphere proxies reduce collision checks to distances from sphere centers to the world or between sphere pairs, rather than mesh-to-mesh distances.The paper says this supports large batches and low-power edge devices.Source: §3 · p. 7

3.1 Robot Kinematics

  • Parallel-threaded homogeneous-matrix operations map joint configurations to link and sphere positions and return the end-effector pose.The implementation also projects gradients from Cartesian to joint space using 16 threads.Source: §3.1 · p. 7

3.2 Self-Collision Avoidance

  • Self-collision costs use the largest penetration among selected sphere pairs; empirically, only 50% of pairs were included in those sets across studied manipulators.The selected set omits pairs permitted to contact safely or unable to collide under kinematic limits.Source: §3.2 · p. 8

3.3 World Collision Avoidance

  • A buffer distance η makes the collision cost quadratic near the obstacle surface, while velocity scaling discourages fast passage through obstacles and slows motion near obstacles.The near-obstacle speed penalty is motivated by robustness to path deviations during real-robot execution.Source: §3.3 · pp. 8–9

3.4 Continuous Collision Checking

  • Continuous collision checking requires only point signed-distance queries and sweeps backward and forward from trajectory waypoints, enabling parallel gradient computation across sphere locations.The method avoids swept-volume distance queries, which the paper notes are limited to primitive or mesh world representations.Source: §3.4 · p. 9
  • The continuous-checking implementation assumes linear sphere motion between waypoints, although revolute-joint links do not move linearly; exact paths are left for future work.The authors report finding paths in tight spaces despite this assumption.Source: §3.4 · p. 9

3.5 World Representation

  • World collision costs use closest-point and inside/outside queries, with implementations for cuboids, watertight meshes, and depth-camera-derived ESDF voxels.The depth-camera representation assumes an accurate camera pose relative to the robot base; the cost can combine representations.Source: §3.5 · pp. 9–10

4 Parallel Optimization Solver

The solver combines L-BFGS with parallel line search and particle-based initialization to optimize difficult motion-generation problems. It evaluates discrete step magnitudes in parallel and uses noisy updates when line search conditions are not met.

4 Parallel Optimization Solver

  • The solver treats constraints as large-weight cost terms and uses L-BFGS, selected for its performance, simplicity, and suitability for parallelization.The paper leaves a full exploration of Gauss-Newton methods to future work.Source: §4 · pp. 10–11

4.1 Parallel L-BFGS Optimization

  • Parallel line search evaluates a discrete set of step magnitudes against Armijo and Wolfe conditions; when none qualifies, a 0.01 noisy update is used.The paper reports that this noisy perturbation greatly increased convergence versus stopping after a failed search.Source: §4.1 · p. 11

4.2 Particle-Based Optimization

  • Particle-based optimization first samples trajectories around an initialization and updates its mean and covariance; the authors report better L-BFGS convergence with this initialization.A parallel geometric planner is proposed to tackle very hard problems and reduce the seeds needed for convergence.Source: §4.2 · pp. 11–12

5 Parallel Geometric Planner

The geometric planner builds collision-free paths by parallelizing key graph-construction operations on the GPU. It samples collision-free configurations, finds nearby graph nodes, and steers between them.

5 Parallel Geometric Planner

  • The GPU planner parallelizes collision-free node sampling, nearest-neighbor search, and steering between sampled nodes and their neighbors.It represents the path as waypoints traversed linearly by the robot.Source: §5 · p. 12

23 end

The planner repeats sampling and graph expansion until it finds a path, then returns that path. Its parallel steering routine handles multiple candidate connections, and shortcutting seeks shorter routes.

23 end

  • The planner returns a path after its search finds one, with the algorithm specifying a minimum-length condition of more than three.Source: §23 · p. 12
  • Parallel steering processes multiple existing vertices and sampled configurations to expand the graph.Source: §23 · p. 13
  • A shortcut routine tries connecting each waypoint to every other waypoint and supports batched start-goal queries or one start with a goal set.Source: §23 · p. 13

6 Results

The results evaluate cuRobo against Tesseract-based methods on Panda planning problems and assess its planning modules, trajectory tracking, and deployments across multiple robot platforms. They also report high-quality solutions and faster computation than existing methods.

6.1 Motion Generation Quality

  • cuRobo succeeded on 99.8% of 2,600 problems (5 failures), versus Tesseract’s 98.53% (38 failures).The five cuRobo failures were attributed to invalid problems under its cuboid collision representation: three goals were in collision, one start configuration was in collision, and one goal had no collision-free IK solution.Source: §6.1 · pp. 14–15, Figure 6 · p. 15
  • Across the dataset, cuRobo produced shorter C-Space paths than any other method, succeeded on all feasible problems, and had mean motion times 1.23× lower than existing trajectory-optimization techniques.Against Tesseract, cuRobo’s mean motion time was 1.59 seconds versus 1.96 seconds, and its paths were 26% shorter at the 98th percentile. Its jerk was 4× lower than Tesseract’s and 12× lower than Tesseract-TG’s.Source: §6.1 · pp. 15, 17, 18

6.2.1 Motion Generation

  • cuRobo planned in 50ms on average versus Tesseract’s 2.95 seconds, a 60× speedup; at the 98th percentile, the speedup was 83×.On Jetson ORIN, cuRobo was 28× faster at MAXN and 21× faster at 15W; at 15W it was faster than Tesseract on a desktop PC. Python-side setup and result collection accounted for 8ms on average.Source: §6.2.1 · pp. 18–20, Figure 12 · p. 18, Figure 13 · p. 19

6.2.2 Geometric Planning

  • cuRobo-GP took 0.02 seconds on average versus Tesseract-GP’s 1.5 seconds, a 101× geometric-planning speedup.At the 98th percentile, cuRobo-GP took 0.04 seconds versus Tesseract-GP’s 20 seconds, a 581× speedup.Source: §6.2.2 · p. 20, Figure 15 · p. 20

6.2.3 Trajectory Optimization

  • cuRobo’s GPU-accelerated trajectory optimization was 87× faster than TrajOpt on average and 145× faster at the 75th percentile; it took 10 ms, versus TrajOpt’s 1.79 seconds, at that percentile.Source: §6.2.3 · p. 20

6.2.4 Inverse Kinematics

  • At batch size 1, cuRobo IK took 2.7ms versus TracIK’s 0.9ms; at batch size 1,000, cuRobo produced 37,134 solutions/s versus TracIK’s 1,590.For collision-free IK, cuRobo produced 7,611 solutions/s versus rejection-sampled TracIK’s 95, an 80× speedup; the rejection-sampling approach failed on 20% of tested problems.Source: §6.2.4 · p. 21, Figure 17 · p. 22

6.2.5 Kinematics and Distance Queries

  • At batch size 100,000, cuRobo’s kinematics and collision checking took 1 nanosecond and 10 nanoseconds, respectively.At batch size 1,000, IK took 27 μs and collision-free IK 130 μs; the module summary reports 10ms trajectory optimization, 16ms geometric planning, and 30ms median full motion generation. cuRobo’s signed-distance queries were faster than PyBullet starting at batch size 1.Source: §6.2.6 · p. 23, §6.2.5 · p. 23, Figure 20 · p. 24

6.3 Real Robot Tracking Performance

  • The real-robot tracking evaluation sent cuRobo motions from a Jetson ORIN AGX to UR5e and UR10 robots across 35 reaching trials.Each robot reached seven randomly selected poses in sequence five times; the authors assumed joint-position measurement accuracy of 0.0017 radians.Source: §6.3 · p. 24, Figure 21 · p. 24
  • Minimum-jerk avoids the initial position-error spike seen with minimum-acceleration by gradually increasing acceleration, reducing tracking error from delayed robot acceleration.The authors note that feed-forward torque could help accelerate more quickly, but torque commands are unavailable on the UR10 and UR5e.Source: §6.3 · p. 25, Figure 23 · p. 26
  • cuRobo planned within 100 ms on average, while planning consumed 6.02%, 6.62%, and 9.12% of min-jerk pipeline time on UR5e and 6.67%, 7.93%, and 9.13% on UR10.The percentages correspond to the reported mean, 75th-percentile, and 98th-percentile results. The robot was in motion for 90%, 92%, and 94% of time on UR5e and 89%, 90%, and 92% on UR10; planning the next motion after execution allows reaction to intervening world or task changes.Source: §6.3 · pp. 25, 27, Figure 24 · p. 26

6.4 Deployment on different Robot Platforms

  • Deployments demonstrated cuRobo avoiding obstacles on a UR10e using an nvblox ESDF map, generating Kinova Jaco motions, and finding collision-free paths for dual UR10e arms in Isaac Sim.The Jaco used a velocity-space PD controller; the dual-arm results were described as preliminary and promising.Source: §6.4 · p. 27, Figure 25 · p. 27

6.3 Real Robot Tracking Performance

  • Minimum-jerk mean position errors were 0.00085 radians on UR5e and 0.00133 radians on UR10, below the 0.0017-radian encoder accuracy margin.Minimum-acceleration errors were 0.00117 radians on UR5e and 0.00250 radians on UR10; the paper reports lower position and velocity tracking errors for minimum-jerk on both robots.Source: §6.3 · p. 25, §6.5 · p. 28

6.5 Summary

  • The paper’s summary reports better motion solutions, faster generation across computing platforms including a 15W Jetson, double-digit subcomponent speedups, and validation on UR5e and UR10.It states that both robots tracked high-speed minimum-jerk trajectories with position errors below the joint-encoder accuracy margin, and that cuRobo also worked on different robot platforms.Source: §6.5 · p. 28

7 Component Analysis

The component analysis measures how collision-cost design, parallel seeds, line search, and optimizer choices affect success, motion time, and computation. Its results show that combining collision-handling refinements with particle initialization and parallel seeds substantially improves success, while seed count and optimizer settings involve trade-offs.

7.1 Collision Cost Formulation

  • Activation distance raised success by 27%, swept checking added 4%, and the speed metric added 2%.Activation distance smooths the collision cost and helps account for collisions that can arise after trajectory interpolation; continuous checking improved success by 7% with tuned seeds and zero activation distance, but by 3% with activation distance.Source: §7.1 · p. 28
  • Success rose from 38% to 85% across collision-cost refinements, particle initialization, and many parallel trajectory-optimization seeds.The analysis attributes the overall gain to existing techniques combined with continuous collision checking and multiple seeds.Source: Figure 26 · p. 28, §7.1 · p. 29

7.2 Effect of Parallel Seeds

  • More trajectory seeds increased success and, from 48 seeds, reduced motion time; geometric-planner seeding reached 96% success but doubled planning time and raised motion time.Using 4 versus 48 seeds changed compute time by 8 ms on an RTX 4090, 158 ms on an Orin at MAXN, and 417 ms on an Orin at 15W.Source: Figure 28 · p. 29, §7.2 · p. 30

7.3 Line Search

  • Noisy line search achieved 75.69% success and 2.86 mm final position error, versus 4 mm with no line search; Wolfe variants performed worse.The Wolfe variants could apply a zero step magnitude when none of their sampled values met the conditions.Source: §7.3 · p. 30, Figure 30 · p. 31

7.4 Gradient Descent and Effect of history length in L-BFGS

  • Gradient descent succeeded on 46% of problems, or 61% with particle initialization, and had 4.94 cm 98th-percentile position error versus L-BFGS at 2.72 cm.L-BFGS converged on the illustrated problem within 100–200 iterations, while gradient descent had not converged after 500.Source: §7.4 · p. 31, Figure 32 · p. 32
  • Increasing L-BFGS history improved convergence, but planning-time impact began at history 12; the evaluations used history 4 because further gains were not significant.History lengths 15 and 25 converged within 100 iterations in the illustrated problem, while history 2 required 200.Source: §7.4 · pp. 31–32, Figure 32 · p. 32

7.5 Effect of Particle Optimization

  • Two particle-optimization iterations added 2 ms on average and improved success by 5 percentage points with one seed and 3 points with multiple seeds.Success increased from 71% to 76% with one seed and from 82% to 85% with multiple seeds.Source: §7.5 · p. 32

8 Concluding Remarks

cuRobo formulates global motion generation as optimization and uses parallel computation to solve it efficiently. The paper also identifies limits in reactive, constrained, contact-rich, dynamics-based, partial-world, and task-sequencing settings.

8 Concluding Remarks

  • cuRobo empirically achieved 60× speedup over SOTA motion-generation methods on a modern PC and 28× on a Jetson AGX ORIN at 60W.The authors release the CUDA-accelerated library with PyTorch and Python wrappers.Source: §8 · p. 32

8.1 Limitations & Open Research Problems

  • Reactive motion generation is not addressed: the method plans full motions from static states and can have longer 98th-percentile solve times on hard problems.Pose-constrained motion showed preliminary promise but was not rigorously evaluated, and constrained graph planning was not implemented.Source: §8.1 · p. 32
  • The paper does not study optimal task sequencing or route planning, though it identifies point-to-point motion generation as a critical component for those tasks.The authors also suggest it could support faster feasibility checks and improved motion sequences in task-and-motion planning.Source: §8.1 · p. 33
  • Current cost terms target kinematic trajectories with position-derivative limits; contact-rich motion and optimization over robot dynamics remain open extensions.The paper points to contact-implicit formulations and GPU-accelerated dynamics as possible directions.Source: §8.1 · p. 33
  • The approach assumes a complete world representation and does not address collision avoidance under partial perception.Learned world representations are proposed as a possible extension for unknown environments.Source: §8.1 · p. 33

A Trajectory Optimization: Cost Terms & Solvers; A.1 Pose Reaching Cost

  • The trajectory optimization uses joint configurations as variables and represents constraints as large-penalty cost terms because its L-BFGS implementation handles only box constraints.The end-effector pose cost uses position and quaternion distances scaled to provide accuracy near the goal and stable gradients farther away.Source: A Trajectory Optimization: Cost Terms… · p. 34, §A.1 · p. 34

A.2 Path-Length Minimization & Smoothness Costs

The appendix describes trajectory costs, time discretization, derivative estimation, and solver choices used to produce smooth, bounded trajectories. It also reports how the authors tuned weights and selected among valid solutions.

A.2 Path-Length Minimization & Smoothness Costs

  • Squared joint-acceleration and jerk costs encourage low-acceleration motion and penalize abrupt acceleration changes that can impair tracking.The authors encourage smooth starts and stops by making the first and last three states equal, avoiding sensitivity to explicit endpoint-velocity constraint weights.Source: §A.2 · p. 34

A.3 Enforcing Joint Limits

  • The joint-limit cost transitions smoothly from quadratic to linear growth near a limit, avoiding a sudden linear jump at the boundary.Similar costs apply to velocity, acceleration, and jerk limits, with an activation distance of η² = 0.1.Source: Figure 33 · p. 35, §A.3 · p. 35

A.4 Time-step Descretization and Temporal Weight Scaling

  • With a fixed timestep count, cuRobo varies the time discretization, rescales derivative-related costs, optimizes again, and retimes the final trajectory.The initial timestep is 0.25 seconds; jerk is not penalized during the first optimization because the authors found this improved convergence.Source: §A.4 · p. 35

A.5 Finite Difference for State Derivatives

  • The five-point stencil reduced optimization iterations by 50% and produced trajectories that ran successfully on the real robot.It computes velocity, acceleration, and jerk from five adjacent joint positions; residual acceleration aliasing was smoothed with a sliding-window filter.Source: §A.5 · p. 36

A.6 Trajectory Profiles

  • cuRobo’s cost terms can produce different trajectory profiles, including a smoother minimum-jerk profile than minimum-acceleration optimization alone.Minimum-acceleration optimization can still yield instantaneous jerks, while the Kunz and Stilman post-processing approach can have high jerks from instantaneous accelerations.Source: §A.6 · p. 36, Figure 34 · p. 37

A.7 Numerical Optimization Solvers

  • A batch-queryable rollout evaluates costs across particle samples and line-search magnitudes in parallel for the particle-based and gradient-based solvers.Step-direction clamping was considered to prevent numerical blow-up from large soft-constraint violations but was not used because it did not significantly improve tested problems.Source: §A.7 · p. 37, Figure 35 · p. 38

A.8 Tuning Weights & Parameters

  • The authors tune pose and collision costs for IK, then pose and smoothness costs for trajectory optimization, before tuning trajectory collision costs.After finding suitable weights, they reduce the seed count until the weights stop working; tuned weights transferred across environments and robot platforms.Source: §A.8 · p. 39

A.9 Evaluating Optimized Trajectories

  • For multiple valid trajectory seeds, cuRobo selects using a blended sum of pose error, maximum jerk, and motion time.For IK, it chooses the solution with the lowest weighted sum of pose error and distance from the current joint configuration.Source: §A.9 · p. 39

B.1 Dataset & Evaluator

The evaluation uses benchmark datasets with adjustments to match robot gripper limits and compares cuRobo with Tesseract and PyBullet-wrapped OMPL planners. The appendix also documents baseline configurations and cuRobo parameters.

B.1 Dataset & Evaluator

  • The benchmark combines 800 MotionBenchMaker problems and 1,600 MPinets problems, with gripper settings adjusted to match the robot configurations.For MotionBenchMaker, the cylinder radius was reduced by 4 cm to fit the Franka Panda’s real gripper limits; MPinets used a 2.5 cm gripper width.Source: §B.1 · p. 39

B.2 Tesseract Baseline

  • Tesseract’s tested configuration used zero endpoint velocities and smooth acceleration; enabling smooth jerk caused failures on many problems and acceleration aliasing.The comparison also used a −1.5 cm collision-margin offset for Tesseract and a −2 cm offset for its OMPL phase.Source: §B.2 · p. 40

B.3 cuRobo Parameters

  • cuRobo used 100 fixed followed by 300 variable trajectory-optimization iterations, with two particle-optimization iterations before L-BFGS.The evaluation included a two-second warm-up for tensor initialization and CUDA Graph creation.Source: §B.3 · p. 40

C.1 Comparison to pyBullet and RRTStar

  • On MotionBenchMaker, PyBullet-wrapped RRTConnect and AIT-Star were significantly slower than trajectory-optimization methods, while cuRobo produced shorter C-space paths than PyBullet-AITStar.The figure compares planning time and C-space path length across methods.Source: §C.1 · p. 41, Figure 36 · p. 41

C.2 Compute Time Coverage Plot

The compute-time comparison reports cuRobo faster than Tesseract and Tesseract-GP, while cuRobo-GP is faster than cuRobo across tested compute platforms. Real-robot observations identify safety settings and derivative estimation as execution considerations.

C.2 Compute Time Coverage Plot

  • cuRobo was faster than Tesseract and Tesseract-GP across compute devices, and cuRobo-GP was faster than cuRobo across tested platforms.Figure 37 presents compute-time distributions for these methods.Source: §C.2 · p. 41, Figure 37 · p. 42

C.3 Real Robot Quirks

  • UR safety settings clipped peak velocities and limited power; selecting the least conservative configuration raised the maximum power limit from 300W to 1000W.Higher-accuracy central or five-point finite differences fixed high-speed oscillations caused by backward-difference velocities.Source: §C.3 · p. 41, Figure 38 · p. 42

D cuRobo Library

cuRobo is a PyTorch-fronted robotics framework that combines GPU-based geometry and kinematics with optimization solvers and a high-level motion-generation API. Its compute kernels parallelize key kinematics, collision-checking, and L-BFGS operations.

D cuRobo Library

  • 10× faster compute time came from capturing 25 solver iterations in one CUDA graph and replaying it, compared with calling the kernels natively.The library also uses PyTorch profiling, CUDA compilation, and tensor operations to support its GPU pipeline.Source: D cuRobo Library · p. 43
  • cuRobo combines PyTorch-based differentiable operations with rollout, optimization, geometry, planning, and wrapper modules for motion-generation tasks.Its mesh-sphere approximation combines surface samples with voxel-derived internal spheres; the automatic technique is used for objects attached to a gripper, not robot geometry.Source: D cuRobo Library · pp. 43–44, Figure 39 · p. 43, Figure 41 · p. 45

E.1 Kinematics

  • Homogeneous 4×4 transformation matrices enable parallel kinematics computations, using four threads per batch for forward kinematics and 16 for backward kinematics.For backward kinematics, the implementation can reuse stored matrices or recompute them, since reuse may be slower for large batches on low-memory-bandwidth systems.Source: §E.1 · p. 46

E.2 Self-Collision

  • Self-collision checking computes pairwise distances between robot spheres and reduces them to the minimum, using one thread block per batch to avoid atomic accesses.The evaluated implementation assigns sphere-pair computations to threads and stores spheres in shared memory to reduce fetch overhead.Source: §E.2 · p. 46

E.3 Signed Distance

  • World collision checking transforms query spheres into obstacle coordinates and computes gradients for potential collisions, including between adjacent horizons for continuous trajectory checks.Inverse kinematics and graph planning instead check collisions at discrete times.Source: §E.3 · p. 46, Figure 42 · p. 47

E.4 L-BFGS

  • L-BFGS computes step directions through parallel dot-product reductions when history is under 16, and uses warp shuffles to shift buffers of size 32 or less.Larger buffers can also use this shifting approach if elements at warp boundaries are handled.Source: §E.4 · pp. 46, 48

E.5 Kernel Timing Benchmark

The section describes cuRobo implementation changes and kernel timing benchmarks, including trajectory-optimization and CUDA updates and the effects of collision representation and execution settings on solve time.

E.5 Kernel Timing Benchmark

  • The kernel profile covered one trajectory-optimization problem, timing all kernels per L-BFGS iteration and measuring one-seed execution separately.The run used 100 iterations with 12 parallel seeds, selected a time-step discretization, then optimized one seed for up to 300 seeds; timings were reported for 12 seeds and 1 seed at 32 timesteps.Source: §E.5 · p. 48, Table 3 · p. 49, Table 4 · p. 49
  • OBB collision cost is 8× faster than mesh collision cost, while meshes use 207 registers versus 77 for OBBs.The mesh slowdown was even more pronounced on Jetson; nvblox was faster than OBB on an RTX 4090, but its comparison is limited because it checks only sphere waypoints and omits continuous collision checking.Source: §E.5 · p. 48, Table 5 · p. 49

E.6 Profiling CUDA Flags

  • Capturing and replaying 25 solver iterations in a CUDAGraph gave a 10× speedup over native kernel calls.The paper notes that this sequence of repeated optimization kernels is well suited to graph capture and replay.Source: §E.6 · p. 48
  • Without tf32, solve time was 15% slower; without fast-math, it was 18% slower.The allocator comparison found no significant solve-time difference between cudaMallocAsync and PyTorch’s default allocator on 2600 problems.Source: §E.6 · p. 48

32 end

  • The collision-checking code transforms spheres into obstacle frames, checks sphere–AABB collisions, computes gradients, and projects them into the global frame.It also uses distance-based jump steps during forward and backward sweeps.Source: §32 · p. 56

F Changes since ICRA 2023

  • State-representation changes reduced iterations to convergence by 50%, while jerk minimization, five-point stencil derivatives, and final-state constraints addressed safety stops, tracking, and overshoot.The authors report that these changes enabled robot velocity and acceleration to reach their limits.Source: F Changes since ICRA 2023 · p. 57
  • Weight tuning and time-step re-optimization addressed motion-length sensitivity; retuning reduced collision-free IK from 100 seeds to 30 and improved position and rotation accuracy.Adding final-timestep velocity constraints to Tesseract produced cuRobo-like trajectory profiles, with planning times of 5.8 seconds on an i7-7800x and 2.9 seconds on an AMD Ryzen 9 7950x; the newer CPU reduced geometric planning time to 20ms.Source: F Changes since ICRA 2023 · p. 57
  • CUDA kernels reduced memory latency by packing three-float vectors into padded float4 values for vectorized loads.The passage attributes the improvement to higher-performing kernel implementations.Source: F Changes since ICRA 2023 · p. 57

Related papers

Loading 2310.17274v2…