SlimComm: Sparse 3D Perception in CAVs
- SlimComm is a communication-efficient framework for cooperative 3-D perception that uses radar Doppler and sparse BEV queries to reduce bandwidth while preserving detection accuracy.
- It employs a two-stage query mechanism combining heuristic and exploratory reference points along with gated deformable attention for precise feature fusion.
- Evaluations on CARLA-based datasets demonstrate superior performance and up to 90% bandwidth reduction compared to baselines like Where2Comm and AttFusion.
SlimComm is a communication-efficient framework for cooperative 3-D perception in connected autonomous vehicles (CAVs) that integrates 4-D radar Doppler with a query-driven sparse communication scheme. Its central objective is to avoid transmitting dense Bird’s-Eye-View (BEV) feature maps, which can overwhelm inter-vehicle bandwidth, while preserving detection accuracy under occlusion and limited sensor range. The framework constructs a motion-centric dynamic map, generates two classes of sparse BEV queries, exchanges only query-specific features, and fuses collaborator responses through multi-scale gated deformable attention. The same work also introduces the CARLA-based OPV2V-R and Adver-City-R datasets with per-point Doppler radar for evaluation (Yazgan et al., 18 Aug 2025).
1. System formulation and architectural organization
Each CAV collects a time-synchronized LiDAR point cloud and six 4-D radar point clouds , where each radar point carries plus Doppler velocity. LiDAR and radar points are pillarized into two BEV tensors, and , concatenated, and passed through a ResNet-style BEV backbone. For each scale , the encoder produces a multi-scale feature map , together with three semantic priors on the highest-resolution grid : a Dynamic Map , a Confidence Map 0, and a Foreground Density Map 1 (Yazgan et al., 18 Aug 2025).
The overall processing chain is explicitly modular. An Ego Query Generator uses 2, 3, and 4 to emit sparse BEV queries at each scale. The communicator then broadcasts the sparse query locations 5 and the ego pose. Each neighboring vehicle 6 first warps its foreground-density prior into the ego frame and decides whether to participate; if any ego query falls on a cell satisfying 7, the neighbor warps its multi-scale features into ego coordinates, extracts a 8 halo around each queried location, and transmits only those halo-enriched features 9. Gated Multi-Scale Deformable Fusion merges ego features and collaborator responses into fused features 0, which are up-sampled and aggregated into a unified BEV tensor 1 for a lightweight 3D detection head. This organization makes sparse communication a first-class design principle rather than a post hoc compression stage.
2. Doppler-guided motion-centric dynamic map
A defining component of SlimComm is its use of radar Doppler to separate moving from static content before query generation. Let 2 denote ego velocity in ego coordinates. For radar 3 with extrinsic rotation 4, the ego velocity in radar-5 coordinates is
6
Each radar returns an absolute Doppler measurement 7 along the line of sight 8. After compensating for own-vehicle motion, the radial velocity of point 9 is
0
The fused LiDAR-radar point cloud is then discretized into a BEV grid of size 1. A grid cell 2 is marked dynamic if there exists a radar point projected into that cell whose compensated radial speed exceeds the threshold 3:
4
The resulting binary map is
5
This motion-centric construction gives the communication module a physically grounded prior for prioritizing moving objects. Because the six radars provide full 6 coverage and each radar point includes per-point Doppler, the method is designed to support moving/static separation across all directions (Yazgan et al., 18 Aug 2025).
3. Query taxonomy and two-stage offset mechanism
SlimComm generates two query types at each BEV scale 7, each containing 8 reference points. The first type is Heuristic Reference Points (HRP). Here, 9 and 0 are down-sampled to 1 and 2. Pool 1 contains all cells with 3; Pool 2 contains the highest-confidence cells not already in Pool 1 until 4. The selected coordinates are stored in 5, and the associated embeddings are obtained by bilinear sampling:
6
The second type is Exploratory Reference Points (ERP), intended to probe occluded regions. Occluder peaks are first found in 7 by
8
followed by thresholding with the per-scene percentile 9. For each peak, a stochastic shadow offset 0 is sampled, yielding 1. Each ERP is embedded as
2
and then mapped by a two-layer MLP to 3 (Yazgan et al., 18 Aug 2025).
The two query branches are combined through anchor formation and offset prediction. The anchor set is
4
A coarse MLP predicts a 2-D offset 5, producing nudged centers
6
To prevent HRP and ERP from collapsing to similar locations, SlimComm introduces an auxiliary margin loss:
7
where 8 is the mean occluder-to-shadow distance at scale 9. A deformable-attention head then predicts 9 local offsets 0 for each nudged anchor, producing final query locations
1
A common misconception in sparse cooperative perception is that sparsification is synonymous with selecting only already-visible or already-confident locations. SlimComm explicitly departs from that assumption by coupling dynamic/high-confidence HRP with occlusion-oriented ERP. This suggests that its sparsity pattern is designed not only for compression but also for targeted exploration of hidden structure.
4. Sparse communication protocol and gated deformable fusion
The communication stage is query-centric. The ego vehicle broadcasts 2. Each neighbor 3 warps its foreground density map into the ego frame, forming 4, and opts in only if any query at the highest-resolution scale lands on a location with 5. For participating neighbors, the warped multi-scale features 6 are used to extract halo-enriched responses 7 by taking a 8 neighborhood around each ego query. Only these query-conditioned local features are transmitted (Yazgan et al., 18 Aug 2025).
Fusion proceeds in three steps. First, collaborator features are averaged:
9
where 0. Second, deformable cross-attention is applied using the ego query embeddings 1, the final query locations 2, and the aggregated collaborator halos:
3
All unqueried grid cells are set to zero. Third, the collaborator-informed features are blended with the ego features by gated residual fusion:
4
with gate
5
The fused feature pyramid 6 is then up-sampled and aggregated into 7 for detection. The end-to-end pseudocode supplied with the method makes clear that query generation, neighbor selection, halo extraction, deformable attention, and gated residual blending are integrated in a single loop over time steps and scales.
5. Datasets and evaluation setting
SlimComm is evaluated on two CARLA-based cooperative perception datasets, OPV2V-R and Adver-City-R, both built on CARLA and OpenCDA, recorded at 10 Hz, and annotated with 3-D bounding boxes. Each CAV uses the same sensor suite: one 64-channel LiDAR with 8 M points/s and 9 m range, six 4-D radars with 0 M points/s each and 1 m range, four RGB cameras providing 2 FOV, and GPS/IMU. The radar returns 3, and the six-radar layout provides full 4 coverage (Yazgan et al., 18 Aug 2025).
| Dataset | Scene characterization | Traffic statistics |
|---|---|---|
| OPV2V-R | “General urban” | Avg. neighbors per frame: 2 (up to 5); avg. vehicles in range 5 |
| Adver-City-R | “Crash-relevant scenarios” | Avg. neighbors per frame: 2; avg. vehicles 6; five road types; scenario lengths 23–39 s; densities 10–33 vehicles |
The two datasets serve distinct roles. OPV2V-R represents general urban operation, whereas Adver-City-R emphasizes crash-relevant scenarios and explicitly stratifies results by General, Sparse, and Dense traffic settings. Because both datasets include per-point Doppler radar, they support direct evaluation of the motion-centric dynamic map rather than requiring radar to be treated only as an auxiliary geometric sensor.
6. Quantitative performance and research significance
Bandwidth is computed in float32 as
7
Relative to full-map sharing of a dense BEV tensor, SlimComm uses only 8–9 MB/frame, corresponding to up to 0 lower bandwidth. On Adver-City-R, SlimComm reports [email protected] of 1 and [email protected] of 2 for General/Sparse/Dense, with BD 3 MB/frame. In the same setting, Where2Comm reports 4 and 5 with BD 6 MB, and AttFusion reports 7 and 8 with BD 9 MB. On OPV2V-R, SlimComm reports [email protected] 00, [email protected] 01, and BD 02 MB/frame, compared with Where2Comm at 03 and BD 04 MB, and AttFusion at 05 and BD 06 MB (Yazgan et al., 18 Aug 2025).
These results are summarized below.
| Setting | SlimComm | Baselines |
|---|---|---|
| Adver-City-R | [email protected] 07; [email protected] 08; BD 09 MB/frame | Where2Comm: BD 10 MB; AttFusion: BD 11 MB |
| OPV2V-R | [email protected] 12; [email protected] 13; BD 14 MB/frame | Where2Comm: BD 15 MB; AttFusion: BD 16 MB |
Within the reported experiments, SlimComm matches or exceeds the best baselines under all densities while using only 17 of their bandwidth. A plausible implication is that the combination of Doppler-guided motion priors, exploratory occlusion probing, and query-conditioned halo transmission changes the usual trade-off between communication volume and cooperative detection accuracy. Rather than treating bandwidth reduction as a purely compression-oriented objective, SlimComm frames it as a structured feature-selection problem over dynamic and occluded BEV regions.