A Fully Interpretable Statistical Approach for Roadside LiDAR Background Subtraction

AI summary

Overview

• Research area: Computer vision and infrastructure-based perception for automated driving, specifically background subtraction (filtering static scene points) in roadside LiDAR point clouds.
• Technical level: Intermediate. The method is mathematically transparent (Gaussian statistics over a 2D grid plus a rule-based filter), but assumes familiarity with LiDAR point clouds, voxelization, and evaluation metrics such as IoU, TPR, and recall.
• Scope in one sentence: The paper proposes a fully interpretable, sensor-agnostic statistical pipeline called a Gaussian Distribution Grid (GDG) for roadside LiDAR background subtraction, and evaluates it on the public RCooper dataset against a state-of-the-art baseline.

What This Paper Is About

Roadside LiDAR collects enormous point clouds, but most points come from static structures such as buildings, trees, ground, and road furniture rather than from vehicles and pedestrians. Removing that background early makes downstream clustering, detection, and tracking faster and more accurate. Existing background subtraction methods tend to be tied to a specific sensor type (for example, azimuth-based filtering assumes a rotating LiDAR) or are deep learning models that need large annotated datasets and offer little transparency. The goal of this paper is a method that is both interpretable by construction and flexible enough to run on rotating, MEMS, and Risley Prism LiDARs, in single- or multi-sensor setups.

Key Contributions

1. A fully interpretable approach to roadside LiDAR background subtraction, where the outputs follow directly from the model's structure and operation rather than from post hoc explanation (the authors cite the definition of interpretable design proposed by Naranjo et al.).
2. A two-phase pipeline consisting of a Gaussian Distribution Grid (GDG) built from background-only scans and a filtering algorithm that classifies each incoming point as foreground or background.
3. Demonstrated flexibility across LiDAR configurations, including different LiDAR models, multiline 360-degree and MEMS sensors, and both single-sensor and multi-sensor setups.
4. An evaluation on a public dataset (RCooper), with reported comparisons to a state-of-the-art reference method, promoting reproducibility and enabling direct comparison with future work.

Main Findings

• Method beats the reference baseline: On a single multiline 360-degree LiDAR setup, the proposed method reached an IoU of 0.3812 in the corridor scene and 0.6972 in the intersection scene, versus 0.3320 in both cases for the reference method [10]. The reference method is tailored to a single rotating LiDAR and was given 400 background scans (the maximum available in the training split) with its original hyperparameters.

• Small background sets are enough: The method requires no training, only a few background scans. In the intersection scene the best point-level results came with just 10 background scans, producing IoUs of 0.6972 for individual 360-degree sensors, 0.8154 for individual MEMS sensors, 0.6784 for combined 360-degree sensors, 0.8073 for combined MEMS sensors, and 0.7045 when all sensors were used.

• More background scans are not always better: In the corridor setting, IoU peaked at 25 background scans (0.3812 individual, 0.3878 combined) and declined with 50 and 100 scans. In the intersection setting, performance was consistently best at 10 scans, indicating that excessive background scans can add noise or variability. By contrast, the reference method's performance improved as its number of background scans increased.

• Intersection scenes are easier than corridor scenes: The intersection scenes outperformed the corridor in all metrics, which the authors attribute to richer spatial information and more diverse perspectives, versus more constrained viewpoints or reduced scene variability in the corridor.

• MEMS sensors perform best: In the intersection scene, individual MEMS sensors produced the highest point-level scores, with precision 0.9102, recall 0.8867, F1 0.8983, and IoU 0.8154 at 10 background scans. The authors credit MEMS sensors' denser, more detailed point clouds.

• Single sensors slightly beat combinations: Using sensors individually gave slightly better results than combining them in both scenarios, suggesting that sensor fusion may introduce inconsistencies.

• Corridor precision-recall imbalance: In the corridor scene at 25 background scans, recall reached 0.6724 (individual) and 0.6219 (combined), while precision was much lower at 0.4681 and 0.5074 respectively, implying the method over-segments the foreground there.

• Object-level results are more stable than point-level: Using a 0.5 threshold for considering an object detected, the best corridor results were at 10 background scans, with TPR 0.7973 and Completeness 0.6967 for individual sensors, and TPR 0.8368 and Completeness 0.7343 for combined sensors. In the intersection scene at 10 scans, individual 360-degree sensors reached TPR 0.7659 and Completeness 0.7011, individual MEMS reached TPR 0.8471 and Completeness 0.7876, combined 360-degree reached TPR 0.7359 and Completeness 0.6571, combined MEMS reached TPR 0.8178 and Completeness 0.7499, and the all-sensor setup reached TPR 0.7284 and Completeness 0.6466.

• Per-class performance varies by object type: Most categories, including car, truck, bus, construction, and huge vehicle, showed strong results, often exceeding 0.8 and sometimes approaching 1. Pedestrian, bicycle, motorcycle, and tricycle scored lower, which the authors link to these objects being smaller, thinner, or more dynamic. The paper reports only Recall, TPR, and Completeness per class, because the method does not perform semantic classification and false positives cannot be computed at class level. The corridor per-class evaluation used 10 background files and the intersection evaluation used 25.

• Runs on low-cost hardware: On a Jetson Nano 2GB Developer Kit, average total execution times per frame were 575.4525 ms for an individual 360-degree LiDAR (mean N = 88703.54, M = 52139.53, K = 1238.98), 298.2228 ms for an individual MEMS LiDAR (mean N = 40804.59, M = 35725.63, K = 562.43), 1197.3615 ms for combined 360-degree LiDARs (mean N = 177407.08, M = 104170.34, K = 2466.53), 620.6476 ms for combined MEMS LiDARs (mean N = 81609.19, M = 71331.88, K = 1040.06), and 2582.2519 ms for all sensors together (mean N = 259016.26, M = 175031.24).

• Compute complexity is dominated by outlier removal: The declared per-stage complexity is O(N) for voxelization, O(M) for point counting, O(N) for the background filter, and O(K²) for Radius Outlier Removal, giving a total of O(N²).

Methodology in Plain English

The method has two phases and requires no training.

Phase one builds the background model, called the Gaussian Distribution Grid. The authors take several LiDAR scans that contain only background (objects were removed using the dataset labels). They combine these scans into a single dense accumulated point cloud, which captures a fuller picture of the static scene, including things like moving tree branches, and helps cushion sensor vibration and noise. They also make a low-resolution copy of that cloud by voxelizing it, which makes the representation more uniform.

Both clouds are then projected onto a 2D grid based on x and y coordinates. The voxelized cloud is used to count how many points fall into each grid cell, giving a stable density descriptor. The richer accumulated cloud is used to fit a Gaussian distribution to the height (z) values of the points within each cell. Two hyperparameters control this phase: voxel size and cell size, where cell size must be larger than voxel size.

Phase two classifies a new scan. First the scan is voxelized with the same voxel size to make a low-resolution version, and points per grid cell are counted. Then each point goes through a decision chain:

• If the background model has zero points in that cell, the point is foreground.
• If the current scan's cell point count does not exceed the model's count plus a threshold (th_points), the point is background.
• If the count exceeds that threshold, the point's height is scored against the cell's Gaussian distribution. If the density falls below th_density times the cell's maximum density, it is foreground.
• Finally, a Radius Outlier Removal step deletes isolated foreground points that have fewer than a set number of neighbors within a given radius, keeping only spatially consistent clusters likely to be real objects.

The six hyperparameters used in the evaluation were voxel size 0.1 along all axes, cell size 0.2 in x and y, a points threshold of 2, a density threshold of 0.3, and 4 neighbors with a radius of 0.8 for outlier removal.

The evaluation used the public RCooper dataset with the original train/validation split. Two scenes were tested: corridor (two multiline 360-degree LiDARs) and intersection (two multiline 360-degree and two MEMS LiDARs). The authors built separate validation samples for individual sensors and combinations of sensors. Ten labels were available: car, pedestrian, truck, bus, bicycle, motorcycle, tricycle, construction, huge vehicle, and signal; the signal class was excluded as background, and the corridor validation set contains no huge vehicle samples. Background scan counts tested were 10 (1 second), 25 (2.5 seconds), 50 (5 seconds), and 100 (10 seconds) randomly selected from the training sample.

Why This Matters

The paper argues that interpretability is not optional in safety-critical automated driving: engineers, regulators, and users need to understand how and why decisions are made, and transparent algorithms make flaws or biases easier to find and fix. The method also avoids a practical bottleneck in the literature — the authors state that none of the previously reviewed background subtraction methods had been evaluated on publicly available roadside LiDAR datasets, which they say hinders comparison and reproducibility.

Real-world applications:

• Adaptive traffic signals and roadside signalling systems, which is the domain of the industry co-authors at CAFSignalling and motivates roadside perception.
• Infrastructure-to-vehicle support, where roadside sensors corroborate a connected vehicle's own perception, which the paper notes is especially valuable when vehicle sensors are obstructed or malfunctioning.
• Edge deployment in smart intersections, since the method ran on a Jetson Nano 2GB Developer Kit, a low-cost and not particularly powerful device chosen specifically to demonstrate performance on resource-constrained hardware.
• Traffic monitoring and counting of vehicles and pedestrians, benefiting from the reduced computational load that background removal brings to clustering, object identification, and tracking.

Industry relevance: the work is a collaboration between Fundación Vicomtech (BRTA), the University of the Basque Country, and the industrial partner CAFSignalling, and it explicitly targets scalable real-world deployment. Because the method works across sensor types without device-specific calibration, it addresses a practical barrier for infrastructure operators who deploy a mix of rotating and non-rotating LiDARs.

Future Directions

The paper's content as provided ends during the time performance section, so no explicit future work section is reported. The results nonetheless point to several logical next steps:

• Investigating why combining multiple LiDARs slightly degrades results compared to using them individually, since the authors attribute this to inconsistencies introduced by sensor fusion but do not resolve it.
• Improving performance in corridor-like scenes, where precision and recall are imbalanced and the method tends to over-segment the foreground.
• Raising accuracy on small or thin object classes, specifically pedestrian, bicycle, motorcycle, and tricycle, which scored lowest across Recall, TPR, and Completeness.
• Reducing the computational cost of the Radius Outlier Removal stage, which dominates runtime through its O(K²) complexity and accounts for the largest share of execution time in the combined and all-sensor configurations.
• Understanding why increasing the number of background scans beyond 10 in the intersection scene, or beyond 25 in the corridor scene, degrades performance, since the paper observes the effect but does not explain its cause.

Target Audience

This paper suits researchers and engineers working on infrastructure-based perception, roadside LiDAR processing, and automated driving systems. It is also relevant to practitioners deploying perception models on edge or low-power hardware, to teams needing sensor-agnostic pipelines rather than device-specific calibration, and to readers interested in interpretable-by-design machine learning for safety-critical applications. Reviewers and regulators concerned with the transparency of perception algorithms are another natural audience, as are students looking for a clear example of a non-deep-learning statistical baseline with a full public-dataset evaluation.

Authors’ abstract

We present a fully interpretable and flexible statistical method for background subtraction in roadside LiDAR data, aimed at enhancing infrastructure-based perception in automated driving. Our approach introduces both a Gaussian distribution grid (GDG), which models the spatial statistics of the background using background-only scans, and a filtering algorithm that uses this representation to classify LiDAR points as foreground or background. The method supports diverse LiDAR types, including multiline 360 degree and micro-electro-mechanical systems (MEMS) sensors, and adapts to various configurations. Evaluated on the publicly available RCooper dataset, it outperforms state-of-the-art techniques in accuracy and flexibility, even with minimal background data. Its efficient implementation ensures reliable performance on low-resource hardware, enabling scalable real-world deployment.