RoboGPU: Accelerating GPU Collision Detection for Robotics

Abstract: Autonomous robots are increasingly prevalent in our society, emerging in medical care, transportation vehicles, and home assistance. These robots rely on motion planning and collision detection to identify a sequence of movements allowing them to navigate to an end goal without colliding with the surrounding environment. While many specialized accelerators have been proposed to meet the real-time requirements of robotics planning tasks, they often lack the flexibility to adapt to the rapidly changing landscape of robotics and support future advancements. However, GPUs are well-positioned for robotics and we find that they can also tackle collision detection algorithms with enhancements to existing ray tracing accelerator (RTA) units. Unlike intersection tests in ray tracing, collision queries in robotics require control flow mechanisms to avoid unnecessary computations in each query. In this work, we explore and compare different architectural modifications to address the gaps of existing GPU RTAs. Our proposed RoboGPU architecture introduces a RoboCore that computes collision queries 3.1$\times$ faster than RTA implementations and 14.8$\times$ faster than a CUDA baseline. RoboCore is also useful for other robotics tasks, achieving 3.6$\times$ speedup on a state-of-the-art neural motion planner and 1.1$\times$ speedup on Monte Carlo Localization compared to a baseline GPU. RoboGPU matches the performance of dedicated hardware accelerators while being able to adapt to evolving motion planning algorithms and support classical algorithms.

• The paper introduces RoboCore, a modified ray tracing accelerator with conditional returns and specialized collision units that reduce wasted traversal and computation.
• RoboCore achieves 14.8× faster collision detection than a CUDA baseline, 3.1× over a ray-tracing approach, and 87% lower energy use in simulation.
• The architecture also accelerates point-cloud processing and neural motion planning, but results are simulation-based and depend on estimated full-pipeline latencies.

RoboGPU addresses a specific gap in GPU architecture: while modern GPUs include specialized units for tensor operations and ray tracing, no existing unit is well-suited to explicit collision detection, which is among the most computationally demanding components of real-time robot motion planning. The paper proposes RoboCore, a modified ray tracing accelerator (RTA) integrated into a GPU (RoboGPU), and demonstrates that modest architectural changes to a programmable tree traversal unit yield substantial speedups on collision detection, point cloud processing, and classical robotics algorithms.

Motivation and problem characterization

The authors motivate their work by profiling collision detection on an NVIDIA RTX 2080 Ti across four environments from M$\pi$Net (Zhang et al., 2022). Collision queries exhibit low SIMT efficiency due to divergent control flow, and explicit collision checking can consume up to 95% of total planning time when included (2603.01517). Notably, state-of-the-art neural motion planners such as M$\pi$Net often omit explicit collision checks from their reported success rates; M$\pi$Net reports up to an 11% collision rate, which the authors argue is unacceptable for deployment and motivates always performing explicit detection before execution.

The paper also characterizes why repurposing RTAs is suboptimal. Mapping collision detection onto RTAs via Mochi-style ray tracing formulations requires 12× more queries than necessary because RTAs are designed to report all intersections rather than terminate at the first collision. Conversely, TTA+ [ha2024tta], a generalized tree traversal unit built from modular operation units connected by an interconnect, achieves better SIMT efficiency but lacks control flow: roughly 60% of collision queries could terminate early after fewer than half of their tests, yet TTA+ executes all 47 $\mu$ops of the full 15-axis separating axis collision test (SACT) — far more than the 12–19 $\mu$ops typical of its original workloads.

RoboCore architecture

RoboCore builds on TTA+ with two categories of modifications. First, early exit support addresses the absence of conditional control flow. Two designs are explored: predication, where each $\mu$op carries a predicate bit set by comparison units so OP units skip execution but all $\mu$ops still traverse the interconnect; and conditional returns, where an extended operation destination table allows CMP units to redirect the program counter based on compare results, and a dedicated RETURN OP unit terminates the intersection program entirely. The authors note that conditional returns add one cycle of intersection latency and that the branching mechanism is general, supporting arbitrary conditional programs beyond returns.

Second, SACT hardware specialization reduces interconnect latency caused by long $\mu$op sequences. Two alternatives are evaluated: pipelined clusters grouping the Box-Normal and Edge×Edge axis test sequences (eliminating intra-cluster interconnect hops), or two new specialized collision OP units that replicate cluster functionality with less buffering and configuration overhead. Area analysis shows these units cost 0.099 mm² and 0.076 mm² respectively at 45 nm, and can be accommodated by removing graphics-only units such as RCP (26% area reduction), leaving RoboCore smaller than a baseline RTA when ray tracing support is not required.

Evaluation methodology

Evaluation uses Vulkan-Sim, a cycle-level GPU simulator with RTA and TTA+ models, configured to match TTA+'s published setup (8 SMs, one RoboCore per SM, four intersection unit sets). Energy is modeled with AccelWattch. Workloads comprise four M$\pi$Net environments (Cubby, Dresser, Merged Cubby, Tabletop) with up to 32,384 OBBs per environment, ten smaller MPAccel scenarios, M$\pi$Net inference, and DeliBot's Monte Carlo Localization kernel from RoWild. Baselines include a CUDA octree-based implementation, Mochi adapted via Vulkan ray tracing, and TTA+.

Results

Collision detection: The full RoboCore configuration (conditional returns plus collision units) achieves 14.8× speedup over the CUDA baseline and 3.1× over Mochi. Ablations show that replacing conditional returns with predication or removing collision units each costs about 25% performance; predication alone yields performance nearly identical to unmodified TTA+, since all 47 $\pi$0ops still traverse the interconnect — a clear demonstration that skipping computation without skipping data movement is insufficient. Unit utilization traces confirm high interconnect utilization in predication configurations. A latency sweep shows performance is relatively insensitive to collision unit latency (0.5×–2×), suggesting area- and energy-oriented designs are viable. Against MPAccel's smaller scenarios, RoboCore does not match MPAccel's reported 23–34× speedups over the same CUDA baseline, though it avoids standalone-accelerator I/O overheads. Interestingly, MPAccel's bounding/inscribing sphere culling optimization provides no benefit on RoboCore — the sphere-OBB test itself nearly doubles query latency in the worst case — a result that contradicts its value on dedicated accelerators. Energy consumption falls 87% versus CUDA and 42% versus Mochi, with RoboCore contributing under 5% of total energy.

Point cloud processing: Profiling M$\pi$1Net shows sampling and grouping consume 38.6% and 37.6% of inference time. The authors find random point sampling sufficient (88.7% success rate versus 94.8% for furthest point sampling, saving 29% latency), shifting the bottleneck to ball query. On RoboCore, the P-Sphere formulation (sampled points as rays, other points as spheres in a BVH) outperforms P-Ray by 1.9× over RTNN on average, despite using only 47.4% occupancy — because BVH organization reduces node traversals dramatically (349K versus 6.9M nodes). Early exit support avoids the wasted shader invocations RTNN incurs after reaching maximum group size, reducing traversed nodes by 6× on average. In the full pipeline, point cloud processing speeds up 2.2×, and the complete M$\pi$2Net pipeline including explicit collision detection runs 3.6× faster than the baseline without collision detection, completing in under 10 ms. This end-to-end estimate relies on extrapolation: since RoboCore cannot be measured on real silicon, collision check time is estimated by scaling the CUDA baseline by 7.0×, and overall latency depends on octree build speed, which is outside the paper's scope.

Classical algorithms: For RoWild's DeliBot Monte Carlo Localization, RoboCore yields 10–20% speedups over CUDA and TTA+. Because workload characteristics shift during execution (long traversals early, short ones as particles converge), the authors implement dynamic switching between RoboCore and CUDA cores based on average traversal distance, illustrating the flexibility advantage over fixed-function accelerators.

Limitations and open questions

Several limitations are acknowledged directly. All results are simulation-based on Vulkan-Sim rather than measured on fabricated hardware, and the full-pipeline results depend on estimated kernel latencies. RoboCore cannot match MPAccel on small-scale scenarios, indicating the approach favors complex, dense environments. The sphere-culling optimization from prior work is ineffective on this architecture, suggesting collision acceleration strategies do not transfer uniformly across platforms. Octree construction remains a potential pipeline bottleneck left to orthogonal work. Finally, scheduling of concurrent robotics kernels on the heterogeneous execution model is explicitly out of scope, and whether the conditional-return mechanism generalizes to substantially more complex intersection programs remains untested.

Conclusion

RoboGPU demonstrates that targeted extensions to a programmable RTA — conditional returns and SACT-specialized operation units — close much of the gap between general-purpose GPUs and dedicated robotics accelerators, delivering 3.1× faster collision detection than RTA-based approaches, 3.6× faster neural motion planning pipelines, and meaningful gains on classical localization, all within a negligible area budget relative to a baseline RTA. The central claim supported by the evaluation is that flexibility and specialization need not be traded off when specialization is implemented as configurable control flow and reusable dataflow units within the GPU's existing accelerator framework.