Thousands of Points. Thousands of Orientations.
The Same Grip Calculation, 700x Faster on the GPU.

Before a robot can grip an item, it has to know which way the item is lying.

The robot’s perception system first identifies each item and reconstructs it as a 3D point cloud (see our Warehouse Perception case study). From there, the next challenge is determining how the robot should pick it up.

To find the optimal grip orientation, the software rotates the item’s point cloud through thousands of candidate poses across three axes, evaluating each one to identify the orientation where the object lies flat and can be reliably lifted by the vacuum gripper.

The computational cost adds up quickly. Each point cloud contains thousands of points, and every candidate orientation requires transforming every point before it can be evaluated. Multiply that by thousands of orientations for every item moving through the system, and orientation computation becomes one of the perception pipeline’s most demanding workloads.

Getting the right orientation was never the question. Getting it fast enough, for every item, was.

The original C++ implementation was computationally intensive but highly parallel by nature. Each candidate orientation applied a rigid-body transformation to every point in the cloud, then evaluated the resulting pose geometrically. Those operations are independent across both points and orientations, so the workload maps cleanly onto a massively parallel architecture. Running on the CPU left most of that parallelism untapped.

The same computation, moved onto hardware built to run it in parallel.

CUDA Implementation of the Orientation Algorithm

Geisel reimplemented the client’s C++ orientation algorithm as a set of CUDA kernels, preserving the original mathematical operations and decision logic. The objective was strict functional equivalence: for the same input point cloud, the GPU implementation had to produce the same grip orientation as the CPU baseline. This was not a new algorithm or an approximation. It was the same computation executing on a massively parallel architecture.

GPU-Resident Data Pipeline

Performance depended on more than kernel execution. Transferring large point clouds between host and device memory introduces significant PCIe overhead, particularly in high-throughput perception pipelines.

To minimize those costs, Geisel structured the processing pipeline so the point cloud remained resident in GPU memory across multiple stages of the orientation search. Intermediate results stayed on the device, eliminating repeated host-to-device transfers and allowing the computation to proceed entirely on the GPU.

Parallel Orientation Search

With the data resident on the GPU, the orientation search could finally exploit that parallelism. Thousands of candidate orientations were evaluated concurrently rather than one after another, each kernel working across the point cloud independently.

The same grip decisions. Only the execution time changed.

The result was a best-case acceleration of 700x over the original C++ implementation while maintaining numerically identical output. Every grip decision matched the CPU baseline; only the execution time changed.

Rather than changing how the robot selected a grip orientation, the project removed a computational bottleneck from the perception pipeline, enabling the existing algorithm to operate at production throughput.