LaserPerception v0.1.0 — PointPillars + TensorRT + ROS 2 with honest deployment benchmarks

LaserPerception v0.1.0 — PointPillars + TensorRT + ROS 2 with honest deployment benchmarks

I’ve released LaserPerception v0.1.0, an open-source LiDAR deployment project focused on reproducible PointPillars/TensorRT/ROS 2 inference rather than model training.

GitHub: GitHub - muhammadmahadazher/laserperception: Reproducible 3D LiDAR detection with TensorRT FP16, exact deterministic voxelization, and ROS 2. · GitHub
Release: Release LaserPerception v0.1.0 · muhammadmahadazher/laserperception · GitHub

Pipeline:

multi-sweep PointCloud2 → exact deterministic voxelization → TensorRT FP16 PointPillars → Detection3DArray → RViz/Foxglove

Representative W1 workload: current keyframe + 10 historical sweeps, 354,182 points, RTX 4060 Laptop GPU under WSL2.

  • 10 Hz: sustained cleanly, ~9.95 Hz output, zero measured drops
  • 15 Hz: not sustained, ~13.34 Hz useful output
  • 20 Hz: not sustained, ~10.83 Hz useful output

So the release deliberately does not claim a 20 Hz ROS pipeline.

A second result came from deterministic hard voxelization. I first tried the faster deterministic=False path, but it changed retained point subsets and produced observable detector differences, so I rejected it.

The replacement exact_fast path matched the official deterministic implementation:

  • 81/81 nuScenes mini_val samples bit-exact
  • 20/20 frozen detector samples with exact raw TensorRT outputs
  • no custom CUDA/C++
  • no TensorRT plugin

Representative hard-voxel layer measurements:

  • 238.9 ms → 1.76 ms
  • 261.9 ms → 1.92 ms

That’s roughly 136× at the hard-voxel layer only, not end-to-end.

I also posted the result to the original MMDetection3D voxelization discussion:

One thing I deliberately kept in the repo is the failed/corrected benchmark history: lighter scene-start workloads, rejected execution-boundary comparisons, the nondeterministic shortcut, and the failed 20 Hz target.

I’d be interested in how other ROS 2 perception teams report performance:

model runtime, callback latency, sensor-to-output loopback, or all three?