Polka: A unified node for all pointcloud pre-processing/merging

ROS ROS General
, , , ,
1

Hello folks,

Point cloud pre-processing including deskewing, merging, and filtering traditionally requires a chain of nodes working in tandem, many of which are no longer actively maintained. Setting up these individual filtering stages often consumes excessive CPU cycles and precious DDS bandwidth.

What if you had a single, low-latency node that could voxellize, deskew, downsample, and merge scans in one go? By passing only mission-critical features to your odometry nodes and downstream, you significantly reduce lag and bandwidth usage across your entire navigation or SLAM stack. A single node to accomplish this.

I developed Polka to solve this. It’s a drop-in replacement for multiple pre-processing nodes and if you need to save CPU, you can run the entire pipeline on your GPU.

Latency across both being ~40ms.

Current features:

  • Merge Pointclouds and laser scans

  • Input/output frame filtering.

  • Defined footprint, height, and angular box filters.

  • Voxel downsampling.

  • GPU acceleration support.

  • Deskewing Pointclouds (WIP)

I’d love your feedback, and if you find the project useful, please consider leaving a star on GitHub!

GitHub - Pana1v/polka

1 Like
2

Thanks, what’s the speedup achievable with GPU? Do you have some measurements or estimates?

Regarding CPU pipeline, if you need to save bandwidth and unnecessary copies, that’s what the filters package is here for.

To get a simple filter chain allowing to process PointCloud2 messages in filters, there is (our) sensor_filters package . @solonovamax helps us to get the ROS 2 port working and it’s around the corner! (ros2 port by solonovamax · Pull Request #7 · ctu-vras/sensor_filters · GitHub) .

Does Polka do something that would not be representable as a filter? (Except GPU support which is currently out of scope)

3

Is there any reason why the link in your post leads to google and not directly to github?