PointPillars on a power budget: pruning for a battery, not a benchmark
Latency, watts, and accuracy form a triangle. Picking the corner that ships.
Most published LiDAR detection results optimize for one corner of a triangle — accuracy — while latency and power float free. On a battery-powered platform you do not get that luxury. This is a note on pruning a PointPillars-style detector for a power budget rather than a leaderboard.
The triangle
Accuracy, latency, and watts trade against each other. Fix any two and the third is determined. The mistake is optimizing accuracy in isolation and discovering the watts only at integration.
Pruning with the right objective
We pruned with energy-per-inference as the explicit constraint, on public autonomous-driving point clouds:
- Profile first. The pillar feature encoder and the 2D backbone dominated energy — so that is where pruning had to bite.
- Structured over unstructured. Channel pruning gave real speedups on the target; unstructured sparsity looked great on paper and did little in practice.
- Sensitivity sweep. Some layers tolerated aggressive pruning; a few were load-bearing for small-object recall and were left alone.
What shipped
The pruned detector hit the per-frame energy target with a modest, well-understood accuracy give-back — concentrated in the easy classes, not the safety-relevant small objects.
Takeaway
Decide which corner of the triangle ships before you train, and make the deployment constraint — here, watts — the pruning objective. A detector that wins a benchmark and drains the battery never leaves the bench.
Clean-room write-up — public / synthetic data only.