Bird's-eye-view (BEV) representation

Overview

A bird's-eye-view (BEV) representation is a 2D map seen from above, in the ego vehicle's frame. A detection head reads it to place objects on the road 2205.13790 §3. Seven cards use it for 3D object detection on driving data, and BEVFormer also feeds a map head 2203.17270 §3.1. The survey card places these methods in a taxonomy and adds no variant of its own. A second survey lists BEV as one grid-based LiDAR representation among several 2206.09474 §3.1. LaserNet is the contrast: it detects on the LiDAR range image and builds no BEV grid 1903.08701 §3.1. One card uses the BEV map for lane topology rather than boxes [arxiv:2511.12590 §3.2]. Two world-model cards keep a BEV state, forecast its change, and read occupancy and a plan from it 2408.14197 §3.2 2510.16729 §3.2. One reinforcement-learning card feeds a two-channel BEV raster to its world model as the observation, and the BEV is not built inside the method 2512.02417 §5.1.1. Two more cards use BEV in other roles. A LiDAR occupancy network fuses a semantic and a geometric BEV branch 2408.10618 § Method. A cooperative driving model builds a BEV on each side of a vehicle-roadside link, but sends only sparse queries and one occupancy map over the link, not the BEV itself [arxiv:2404.00717 § Data generation].

The cards differ in what they put on the map:

• Single camera, depth distribution. One front camera predicts a depth distribution per pixel, lifts its features into a voxel grid and collapses it to BEV. No LiDAR is needed at run time. CaDDN does this from a monocular image 2103.01100 §3.1 2103.01100 §1.
• Shared grid. Every stream writes into one common grid in ego coordinates, and one head reads the result. BEVFusion does this with a camera stream and a LiDAR stream 2205.13790 §3.
• Camera-only polar grid. Six cameras write a grid of distance and angle, not a square grid. PolarFormer learns the distance by attention, without predicting depth 2206.15398 §1 2206.15398 §3.1.
• Camera-only learned grid with history. Learnable queries on a square grid read the six cameras through deformable attention, and the previous grid is carried forward after an ego-motion shift. BEVFormer does this 2203.17270 §3.1 2203.17270 §3.3 2203.17270 §3.4.
• Lane masks on a camera BEV grid. Learnable lane queries each predict a BEV mask. The masks weight a grid encoding that is added back into the queries, so each lane is tied to a region of the map. The output is lane topology, not boxes 2511.12590 §3.2 2511.12590 §3.3.
• Forecast of the BEV state. The BEV state is an input to a predictor that rolls it forward in time, and occupancy and a plan are read from the state. Drive-OccWorld conditions its memory on ego motion, and IR-WM adds a predicted change to the previous state 2408.14197 §3.2 2510.16729 §3.2.
• Per-proposal crops of a LiDAR map and an image. AVOD keeps the LiDAR BEV map and the image as two feature maps. It crops both at each anchor or proposal and averages the crops, so no camera data is written onto the BEV map 1712.02294 §3.3 1712.02294 §3.4.
• Separate maps with interaction. The LiDAR BEV map and the image features stay as two representations. They exchange information through the known calibration between points and pixels, and the decoder reads them in turn 2208.11112 §3.1 2208.11112 §3.2.
• One BEV map among several LiDAR inputs. BADet keeps a LiDAR BEV map as one of three feature sources for each proposal, next to voxel and raw-point features, and refines proposals with a graph 2104.10330 §3.2 2104.10330 §3.3.

Among the cards, only the shared-grid design needs every stream to produce a feature map of the same height and width in the same ego coordinates 2205.13790 §3. The polar, learned-grid and interaction designs do not need it, BADet samples one BEV map at each proposal's footprint, and AVOD crops its two maps to one size per anchor 1712.02294 §3.3.

A survey places these methods in a wider taxonomy. It groups voxel-based LiDAR detectors, which often collapse points into a BEV map, and camera methods that lift image features into 3D 2106.10823 §3.1 [arxiv:2106.10823 §3.2]. It is a taxonomy, not a method, so it adds no variant below.

Variants

Camera lift into a shared LiDAR-sized grid

What it is: an independent camera stream that builds a BEV map by predicting depth per pixel, then fuses with a LiDAR BEV map at the feature level 2205.13790 §3. At inference it needs the images and the camera-to-LiDAR matrices only. The LiDAR points enter through the LiDAR stream and the fusion module 2205.13790 §3. Key results, measured against the LiDAR-only row of each setting 2205.13790 tab. 1:

• Fused with TransFusion-L on nuScenes validation: 67.9 mAP against 64.9 for LiDAR alone, and 71.0 NDS against 69.9 2205.13790 tab. 1.
• With the field of view cut to plus or minus 60 degrees, the fused TransFusion-L reaches 41.5 mAP against 19.0 for LiDAR alone 2205.13790 tab. 3.

Card: BEVFusion: A Simple and Robust LiDAR-Camera Fusion Framework.

Monocular lift with a depth distribution (CaDDN)

What it is: a single camera and no LiDAR at inference. A ResNet-101 backbone gives image features at 1/4 of the input resolution 2103.01100 §3.1. A depth head predicts a softmax over depth bins for each pixel, and each pixel's reduced features are multiplied by these probabilities to form a frustum volume 2103.01100 §3.1 2103.01100 eq. 1. The frustum is sampled into a voxel grid with the camera projection, height is folded into channels, and a PointPillars-style backbone and head read the resulting BEV map 2103.01100 §3.1 2103.01100 §3.2. Bin spacing is linear in the increasing discretisation (LID) 2103.01100 §3.3 [arxiv:2103.01100 eq. 2]. LiDAR points, projected into the image, supervise the depth bins during training only 2103.01100 §3.4. Key results, author-reported on KITTI test, Car, one frame, AP|R40 2103.01100 tab. 1:

• Car moderate 13.41 AP, against 11.72 for D4LCN. Among the single-frame rows, that is the highest other than this one 2103.01100 tab. 1.
• Ablation on KITTI val, Car moderate: depth distribution without depth supervision gives 6.43 AP. Adding supervision gives 14.03, and LID discretisation gives 16.31 2103.01100 tab. 3 [arxiv:2103.01100 tab. 6].
• Waymo validation, Vehicle, front camera only: 17.54 mAP at IoU 0.5 for Level 1, against 3.79 for M3D-RPN. The M3D-RPN baseline is the authors' own extension 2103.01100 tab. 2 2103.01100 §4.

The results give no runtime or memory figure, so measure before choosing it. The frustum holds 64 channels over every depth bin at each feature pixel 2103.01100 §3.1.

Card: Categorical Depth Distribution Network for Monocular 3D Object Detection.

LiDAR-only BEV heads (baseline in the same paper)

The LiDAR stream alone, with PointPillars, CenterPoint or TransFusion-L, is the reference point for every gain above 2205.13790 tab. 1. It has no camera stream, so it has no depth prediction or lift. Latency and memory are lower: on a V100 at batch size 1, TransFusion-L with LiDAR only takes 263.61 ms and 12536 MB 2205.13790 tab. 13.

LiDAR BEV map as one feature source for a graph refiner

What it is: a LiDAR-only two-stage detector. A 2D network runs on the BEV map, and its proposals are refined in a second stage 2104.10330 §3.1.2. Each proposal's node state joins three sources: BEV features sampled on a small grid over the proposal's footprint, voxel features interpolated from the 3D backbone, and point features from a PointNet++-style branch [arxiv:2104.10330 §3.2]. A radius graph links nearby proposals, and message passing lets each box take the boundary cues of its neighbours 2104.10330 §3.3. The camera is not used. Key results, author-reported:

• KITTI test, Car moderate: 81.61 AP3D and 91.32 APBEV, against 81.62 AP3D and 88.83 APBEV for Voxel R-CNN. The 3D score is on par, and the BEV score is higher 2104.10330 tab. 1. The authors say the BEV score was first on the leaderboard at submission 2104.10330 §4.2.2.
• KITTI validation, Car moderate, ablation: BEV features alone give 79.93 AP3D, and all three sources give 85.77 2104.10330 tab. 6. The refiner itself gives most of the gain: 79.94 to 85.77 with the refiner added to the same backbone 2104.10330 tab. 5.
• nuScenes validation: 47.65 mAP and 58.84 NDS 2104.10330 tab. 4.

Card: BADet: Boundary-Aware 3D Object Detection from Point Clouds.

Two-view proposal crops (AVOD)

What it is: a two-stage detector for cars, pedestrians and cyclists. Its LiDAR input is a six-channel BEV map at 0.1 m per cell, with five height slices and a density channel 1712.02294 §3.1. An image branch runs alongside it 1712.02294 §3.2. Each anchor on a 0.5 m BEV grid is cropped from both maps to 3 x 3 and averaged before the region proposal network 1712.02294 §3.3. The second stage crops each proposal from both maps to 7 x 7 and averages again. The box is coded with four BEV corners and two heights, and an angle vector gives the heading 1712.02294 §3.4. The camera enters only through these crops. Key results, author-reported on KITTI:

• Test, car 3D AP at easy, moderate and hard: 81.94, 71.88 and 66.38 for the feature-pyramid model, at about 0.1 s per frame 1712.02294 tab. 2 1712.02294 §4.
• Proposal recall for pedestrians and cyclists at 1024 proposals is higher with the image fused into the proposal network than with BEV features alone: by 10.1% and 8.6% in the authors' figure, without the feature pyramid 1712.02294 §4 1712.02294 fig. 5.

Card: Joint 3D Proposal Generation and Object Detection from View Aggregation.

Object-point dropping as a training choice

This is a training-time augmentation for the LiDAR stream, not a separate representation. It removes all points inside ground-truth boxes with a probability, to mimic an object that returns no laser light [arxiv:2205.13790 §4.4.1]. Its effect depends on the model: it lifts the fused models, but it lowers the vanilla TransFusion LiDAR-camera baseline from 38.1 to 37.2 mAP 2205.13790 tab. 4. The paper suggests missing foreground points give wrong supervision for that model 2205.13790 §4.4.1.

Camera-only polar grid without depth prediction

What it is: six surround cameras feed a polar BEV grid indexed by radius and azimuth. Each image column is turned into polar rays by cross-plane attention, at three scales. A deformable-attention encoder mixes the cells, and a decoder with learned queries predicts boxes. Heading and velocity are measured relative to the object's azimuth 2206.15398 §3 [arxiv:2206.15398 §3.4]. The radius is not computed from an estimated depth; the model learns it through attention 2206.15398 §3.1. Key results, author-reported on nuScenes validation:

• Prototype setting, ResNet-101 initialised from FCOS3D: 39.6 mAP and 45.8 NDS, against 37.5 and 44.8 for BEVFormer-S 2206.15398 tab. 3.
• Improved setting, VoVNet-V2-99 with DD3D pretraining and extra data: 50.0 mAP and 56.2 NDS, against 47.8 and 53.4 for Ego3RT 2206.15398 tab. 3 2206.15398 §4.
• The authors' own ablation: polar features with a Cartesian head give 38.5 mAP, against 38.1 for Cartesian features 2206.15398 tab. 2a. Three polar scales add 0.5 mAP over one scale, from 39.1 to 39.6 [arxiv:2206.15398 tab. 2c].

Card: PolarFormer: Multi-camera 3D Object Detection with Polar Transformer.

Camera-only learned grid with temporal history

What it is: six surround cameras and no LiDAR. A 200 x 200 grid of learnable queries, each cell 0.512 m, is updated by six encoder layers [arxiv:2203.17270 §3.1] 2203.17270 §4.2. Each layer runs temporal self-attention over the current queries and the previous grid, then spatial cross-attention into the camera features, then a feed-forward block 2203.17270 §3.1. Spatial cross-attention projects a column of fixed reference heights above each cell into the cameras, and samples features only in the views where a point lands 2203.17270 §3.3. The previous grid is shifted by ego motion before use 2203.17270 §3.4. Key results, author-reported on nuScenes:

• Test, ResNet-101 backbone: 53.5 NDS, against 46.2 for the BEVFormer-S variant 2203.17270 tab. 1. Test, with a VoVNet-99 backbone pre-trained on depth estimation with extra data: 56.9 NDS 2203.17270 tab. 1. The like-for-like comparison is the ResNet-101 row.
• Velocity error on test: mAVE 0.435 for the full model, against 0.925 for BEVFormer-S, both ResNet-101 2203.17270 tab. 1.
• Validation, ResNet-101: 51.7 NDS and 41.6 mAP 2203.17270 tab. 2.
• Frames in training: NDS 0.448 with one frame and 0.517 with four 2203.17270 tab. 7.

Card: BEVFormer: Learning Bird's-Eye-View Representation from Multi-Camera Images via Spatiotemporal Transformers.

Separate maps with cross-modal interaction

What it is: the LiDAR BEV map and the image features are kept as two representations for the whole network 2208.11112 §3. The encoder has two layers. In each, a LiDAR cell attends to the camera pixels its pillar projects to, and the BEV map is warped into each camera with a depth map completed from LiDAR points 2208.11112 §3.1. Each modality also attends to its own neighbourhood 2208.11112 §3.1. The decoder refines 200 object queries, and alternate layers pool a 7 x 7 region from the camera image and from the LiDAR BEV map 2208.11112 §3.2 [arxiv:2208.11112 §4.2]. Key results, author-reported:

• Validation, base model with ResNet-50: 69.9 mAP and 72.6 NDS against 65.1 and 70.1 for TransFusion-L, and 67.9 and 71.0 for BEVFusion (Liang et al.) 2208.11112 tab. 1.
• Test, base model: 70.8 mAP and 73.4 NDS. The paper lists BEVFusion (Liang et al.) at 69.2 and 71.8 with Swin-Tiny 2208.11112 tab. 1. The backbones differ, so this comparison mixes two factors.
• Decoder alternating image and LiDAR layers gives 69.9 mAP on validation, against 69.2 when every layer reads only the LiDAR map [arxiv:2208.11112 tab. 3].
• Encoder with two layers gives 69.9 mAP, against 66.4 with no encoder 2208.11112 tab. 4.

Card: DeepInteraction: 3D Object Detection via Modality Interaction.

BEV lane masks for lane topology (TopoFG)

What it is: a camera-only model for which lanes connect, not a detector. Six or seven cameras feed a BEVFormer-style encoder that produces the BEV features 2511.12590 §3.1. Each lane query predicts one BEV lane mask, and a mask-weighted sine-cosine grid encoding is added to the query as a spatial prior 2511.12590 §3.2 2511.12590 eq. 2. The decoder's deformable attention takes its reference points from that mask 2511.12590 §3.3. The released config uses a 100 x 200 BEV grid, which the paper does not state topofg_r50_8x1_24e_olv2_subset_A.py. Key results, author-reported on OpenLane-V2 subset_A with ResNet-50 2511.12590 tab. 1:

• OLS 48.0, against 44.1 for TopoLogic. Adding the three modules in turn gives 45.4, 45.8 and 48.0 2511.12590 tab. 3.
• The mask-based global spatial prior alone gives OLS 45.2, against 44.1 for the baseline, and the full prior module gives 45.4 2511.12590 tab. 4.
• The paper reports no seeds or variance, so a gap of a few tenths of a point is not reliable 2511.12590 tab. 4.

Card: Fine-Grained Representation for Lane Topology Reasoning.

Autoregressive BEV forecast with ego-motion memory (Drive-OccWorld)

What it is: a camera-only world model that forecasts 4D occupancy and flow. A BEVFormer-style encoder turns the multi-view images into BEV embeddings 2408.14197 §3.2. Each embedding in the memory is layer-normalised without learned affine terms, then rescaled and shifted by parameters derived from a condition 2408.14197 eq. 5 2408.14197 §3.2. The paper names three conditions: semantic labels, ego motion and agent motion. The released configs turn on ego motion only [code: projects/configs/inflated/action_condition_GMO.py#L164-L175]. A decoder with learnable BEV queries reads the memory, and a 200 x 200 grid with 16 height bins is decoded into occupancy 2408.14197 app. C.3. The action enters through cross-attention. The paper lists velocity, steering, trajectory and command as action types 2408.14197 §3.3. Key results, author-reported on nuScenes 2408.14197 tab. 1:

• Inflated occupancy, mIoU at 2 s: 36.3 for Drive-OccWorld, against 26.8 for Cam4DOcc.
• Open-loop planning, NoAvg protocol, average L2: 0.85 m, against 1.03 m for UniAD 2408.14197 tab. 5. The planning rows are not reproducible from the released configs (see Contradictions).

Card: Driving in the Occupancy World: Vision-Centric 4D Occupancy Forecasting and Planning via World Models for Autonomous Driving.

Residual BEV forecast with feature alignment (IR-WM)

What it is: a camera-only world model with the same encoder family. A BEVFormer-based encoder builds the BEV state from the past and current frames 2510.16729 §3.2.1. The future predictor does not output the next state. It outputs a change, which is added to the previous state [arxiv:2510.16729 eq. 6] 2510.16729 §3.2.2. Before the state goes back into memory, an alignment module rescales its features with parameters from a predicted semantic occupancy map and from the ego transform 2510.16729 §3.2.2. The authors say this slightly reduces error build-up over time [arxiv:2510.16729 §4.4] 2510.16729 tab. 8. The planner reads the un-aligned state 2510.16729 §3.2.3. The default coupling uses only the generated BEV features for planning, and occupancy is an auxiliary output [arxiv:2510.16729 §3.2.4]. Key results, author-reported on nuScenes:

• Inflated occupancy, IoU at 2 s: 37.2 against 36.3 for Drive-OccWorld 2510.16729 tab. 1.
• Fine-grained occupancy on nuScenes-Occupancy, IoU at 2 s: 14.5 against 12.0 2510.16729 tab. 1.
• Open-loop planning, average L2: 0.53 m against 0.85 m for Drive-OccWorld 2510.16729 tab. 4.
• Feature alignment, per-class IoU on four classes: gains of 0.2 to 0.4 2510.16729 tab. 8.

Card: Vision-Centric 4D Occupancy Forecasting and Planning via Implicit Residual World Models.

BEV raster as observation for a model-based RL agent (VDD)

What it is: a reinforcement-learning agent, not a detector. Its observation is two channels of 128 x 128 cells, one for road geometry and navigation, one for surrounding vehicles 2512.02417 §5.1.1. The encoder turns each frame into a discrete latent, and a recurrent state is updated from the previous latent and the previous ego state 2512.02417 §4.1.1. The paper assumes the BEV raster is available from perception and does not model how it is produced 2512.02417 §5.1.1. The ego vehicle's dynamics are a separate model, and the policy outputs a goal that a fixed controller turns into an action 2512.02417 §4.2.1. Key results, author-reported in MetaDrive with traffic density 0.35 2512.02417 tab. 1:

• Roundabout, success rate: 0.70 against 0.53 for DreamerV3. The roundabout reward is 163.82 against 150.64 2512.02417 tab. 1.
• Intersection, success rate: 0.88 against 0.91 for DreamerV3, so this variant is slightly lower there 2512.02417 tab. 1.
• Changed mass and maximum steering: the robustness study is figure-only, and the text says VDD is stable across mass changes 2512.02417 fig. 9 2512.02417 §5.2.4.

Card: Vehicle Dynamics Embedded World Models for Autonomous Driving.

Roadside BEV summary sent over a link (UniV2X)

What it is: a cooperative camera-only planner. The roadside unit runs a BEVFormer-style encoder, then sends four items: agent queries with ids and reference points, lane queries after low-score removal, and one occupancy map with a flow that gives its future values 2404.00717 § Data generation. The vehicle does not receive the BEV feature. It matches roadside agent queries to its own with the Hungarian method on reference-point distance, keeps unmatched roadside queries, and takes the maximum of the two occupancy maps 2404.00717 § Cross-view query matching [arxiv:2404.00717 § Cross-view occupancy fusion]. The paper's latency compensation uses a predicted query flow, which the released code does not contain 2404.00717 § Paper vs code. Key results, author-reported on DAIR-V2X, averaged over 2.5, 3.5 and 4.5 s 2404.00717 tab. 2:

• Collision rate 0.34%, against 0.89% with no fusion.
• Planning L2 3.48 m, against 3.44 m with no fusion and 3.30 m for BEV feature fusion. The paper does not claim an L2 win.
• Transmission 8.09e5 BPS, against 8.19e7 for BEV feature fusion. The paper does not define the unit in the table.

Card: End-to-End Autonomous Driving through V2X Cooperation.

Two-branch BEV fusion for LiDAR occupancy (OccMamba)

What it is: a LiDAR-only network that predicts voxel semantics on a 256 x 256 x 32 grid, with 0.2 m voxels 2408.10618 §5.1. A semantic branch runs sparse 3D convolutions and projects its voxels to BEV after each stage, with a Mamba block on the BEV map 2408.10618 §3.1. A geometric branch runs dense 3D convolutions with a Mamba block after each stage, then flattens height into channels to form BEV features. A BEV U-Net fuses the three scales of both branches and outputs the voxel classes 2408.10618 §3.1. The code uses sparse convolutions for the semantic branch [code: networks/semantic_segmentation.py#L119-L126]. Key results, author-reported on SemanticKITTI:

• Hidden test: IoU 59.9 and mIoU 25.0, against 56.6 and 24.4 for Co-Occ, and 59.7 IoU and 24.2 mIoU for SSC-RS 2408.10618 tab. 2. The throughput is 22.1 FPS, and the paper does not name the hardware 2408.10618 tab. 2.
• Validation: IoU 58.6 and mIoU 25.2, with 23.8 M parameters and 3.5 GB of memory 2408.10618 tab. 3.
• Ablation on validation mIoU: 24.1 without the semantic Mamba block, 24.7 without the geometric one, and 25.2 for the full model 2408.10618 tab. 4.

Card: OMEGA: Efficient Occlusion-Aware Navigation for Air-Ground Robot in Dynamic Environments via State Space Model.

Range-image detector with no BEV grid (LaserNet)

What it is: a LiDAR-only, single-stage detector that runs on the sensor's own range image, with one row per laser and one column per azimuth bin 1903.08701 §3.1. Each cell carries range, height, azimuth, intensity and a valid flag 1903.08701 §3.1. A fully convolutional backbone keeps the vertical resolution and downsamples only horizontally [arxiv:1903.08701 §3.2]. Each point predicts class probabilities and a mixture of box distributions, each with a spread 1903.08701 §3.3. Mean-shift clustering on a 0.5 m bin grid merges the boxes per class and per component 1903.08701 §3.4, and an NMS threshold set by the predicted spread prunes duplicates 1903.08701 §3.6. Key results, author-reported:

• ATG4D validation, vehicle AP0.7 over 0 to 70 m: 85.34, against 85.17 for ContFuse with LiDAR and RGB, and 83.13 for ContFuse with LiDAR alone 1903.08701 tab. 1. The paper does not say how to obtain ATG4D 1903.08701 §4.1.
• Ablation on ATG4D: a mixture of boxes gives 81.80 against 80.92 for a single box, with the same fixed threshold and hard NMS. The adaptive threshold with soft NMS gives 85.34 1903.08701 tab. 2.
• KITTI runtime on a 1080 Ti: 30 ms total and 12 ms forward, against 62 ms total for PIXOR 1903.08701 tab. 3. The total includes pre- and post-processing, and the source of the baseline timings is not stated 1903.08701 §4.3.
• KITTI validation, BEV vehicle AP0.7 at moderate difficulty: 73.77, against 83.70 for PIXOR++ 1903.08701 tab. 4. The authors say it trails BEV detectors there 1903.08701 §4.4.

Card: LaserNet: An Efficient Probabilistic 3D Object Detector for Autonomous Driving.

When to use which

The latency figures are not comparable across cards. BEVFusion's are batch size 1 on one V100 with a CPU, including the projection step, and DeepInteraction's are throughput on several GPUs. Drive-OccWorld's are on one A6000 2408.14197 tab. 9, and IR-WM's device is not stated 2510.16729 tab. 5. Measure on your own hardware before deciding.

Implementation sketch

Language-agnostic outline of the camera-lift core, with its fusion step. It follows the shared-grid design, the one with a camera stream that differs from a LiDAR-only pipeline. Polar and interaction designs replace the splat step, as the notes below say.

# Camera lift into a BEV grid  [arxiv:2205.13790 §3.1]
def camera_bev(images, lidar2img):
    # Per-pixel depth distribution over bins, plus context features
    depth_probs = softmax(depth_head(feats), dim=depth_bins)
    context = context_head(feats)
    # Frustum: depth-weighted features, one slice per depth bin
    frustum = depth_probs[:, None] * context[:, :, None]
    # Project each frustum cell to ego coordinates, sum into the grid
    grid = splat_sum(frustum, lidar2img)  # (C, Z, H_bev, W_bev)
    # Fold height into channels; keeps full horizontal resolution
    bev = reshape(grid, (C * Z, H_bev, W_bev))
    return bev_encoder(bev)

# Fusion on the shared grid  [arxiv:2205.13790 §3.3] [arxiv:2205.13790 eq. 2]
def fuse(cam_bev, lidar_bev):
    x = conv3x3(concat([cam_bev, lidar_bev], dim=channels))
    gate = sigmoid(linear(global_avg_pool(x)))
    return gate * x

Notes on where the common core varies:

• The camera and LiDAR BEV grids must agree in size. In BEVFusion the camera grid uses 0.6 m cells and the LiDAR voxels are 0.075 m, but the two BEV maps end up the same size, so re-tuning one stream without the other changes the BEV size 2205.13790 tab. 3 2205.13790 §4.1.
• The depth range (4 to 44 m in 1 m bins) and the grid extent are code defaults, not paper values. The paper does not say what happens beyond the depth range 2205.13790 app. B.1.
• The camera frustum is built on the original 900 x 1600 frame while the network input is 448 x 800. The lidar2img matrices are not rescaled with the resize, so changing the input scale without also changing the downsampling breaks the match 2205.13790 §4.1.
• PolarFormer replaces the frustum splat with cross-plane attention. Each polar ray queries the features of one image column, and three polar scales are kept 2206.15398 §3.1 2206.15398 §4.
• DeepInteraction does not build a camera BEV map. It keeps image features in image space and reads them with projected 7 x 7 regions, and it warps the LiDAR BEV map into the cameras using completed depth [arxiv:2208.11112 §3.1] 2208.11112 §3.2. Calibration errors propagate into both directions 2208.11112 app. A.3.
• BEVFormer writes no splat. Its grid is learned queries, and camera features are read by deformable attention at fixed reference heights above each cell 2203.17270 §3.3. The previous grid is rotated by the change in yaw and shifted by ego translation before use [code: projects/mmdet3d_plugin/bevformer/modules/transformer.py#L143-L156]. Inference is stateful: frames must run in time order [code: projects/mmdet3d_plugin/bevformer/detectors/bevformer.py#L243-L251].
• AVOD keeps the LiDAR map at 0.1 m per cell. Each anchor and proposal is cropped from both views and averaged, so the image never reaches the grid 1712.02294 §3.1 1712.02294 §3.3. Its height bands differ between paper and code, so check them before reusing the input pyramid_cars_example.config.
• CaDDN's depth head outputs D+1 values. The extra out-of-range bin is supervised but dropped before the frustum, so the in-range weights do not sum to 1 for each pixel. The paper's appendix describes it this way 2103.01100 app. B depth_ffe.py.
• The paper describes depth labels from LiDAR projection followed by depth completion 2103.01100 §3.4. The released code loads precomputed depth maps and does not contain the completion step [code: pcdet/datasets/kitti/kitti_dataset.py#L98-L113]. Label generation is therefore not reproducible from that repository alone.
• TopoFG's spatial prior is a mask-weighted grid encoding, and the paper leaves its normalisation undefined. The released code divides by the largest absolute value across the whole batch, so one sample's prior depends on the others in the batch 2511.12590 eq. 2 [code: projects/topofg/models/dense_heads/topofg_head.py#L287]. Reproduce the batch-level scaling only if you need the paper's numbers.
• BADet has no camera lift. Its BEV map comes from the LiDAR stream alone 2104.10330 §3.1.2, and it samples that map at each proposal's footprint 2104.10330 §3.2.2. The radius of the graph and the cap on neighbours are not in the paper; the code uses 0.1 m and 256 neighbours gnn.py. Treat them as code defaults, not paper values.
• Drive-OccWorld's memory is normalised by ego motion, and its released configs take the action from the CAN bus, not from the predicted trajectory the paper describes 2408.14197 §3.2 [code: projects/mmdet3d_plugin/bevformer/dense_heads/world_head_base.py#L309-L317]. The predicted-trajectory action therefore has no released path.
• IR-WM's state update is the previous state plus a predicted change, and the planner reads the state before alignment 2510.16729 §3.2.2 [arxiv:2510.16729 §3.2.3]. The code's planning loss takes a Euclidean distance, not a squared one planning_loss.py.
• VDD has no camera lift and no splat. The BEV raster is a fixed two-channel input to an encoder, so the camera-lift core above does not apply 2512.02417 §5.1.1. Its CARLA run replaces the BEV input with a route map and a front camera, and the decoder then reconstructs a BEV image of the surrounding vehicles 2512.02417 §5.1.1.

Contradictions

Papers disagree on a few numbers and design choices. Each side is cited, and none is resolved here.

• LiDAR baseline on validation. BEVFusion reports TransFusion-L at 64.9 mAP and 69.9 NDS 2205.13790 tab. 1. DeepInteraction reports the same model at 65.1 mAP and 70.1 NDS in its main table 2208.11112 tab. 1, and 70.2 NDS in its per-class table 2208.11112 tab. 6. The gain from fusion therefore depends on which paper's baseline you use.
• Depth from images. BEVFusion predicts a depth distribution for each pixel and uses it to lift features into the grid 2205.13790 §3.1. PolarFormer argues that dense depth estimation is costly and error-prone, and learns the radius through attention instead 2206.15398 §1 2206.15398 §3.1. DeepInteraction predicts no depth from images. Its depth comes from LiDAR points 2208.11112 §3.1. BEVFormer samples camera features at fixed reference heights rather than at predicted depths 2203.17270 §3.3. CaDDN predicts a depth distribution from the image and trains it jointly with the detector, using LiDAR-derived labels. On KITTI val, Car moderate, a separately trained CaDDN depth network gives 12.26 AP and joint training gives 13.71 2103.01100 tab. 4. The same table gives 10.18 and 11.04 for separately trained BTS and DORN depth [arxiv:2103.01100 tab. 4]. These are the paper's own runs in one pipeline, and they do not test a design without depth. These are design positions, and no single experiment in the cards settles them.
• Within CaDDN. The paper gives a focal alpha of 3.25 for foreground and 0.25 for background 2103.01100 §3.5. The code uses a single alpha of 0.25 and multiplies the loss by 13 for foreground and 1 for background CaDDN.yaml. The paper does not say which form produced its reported numbers.
• Polar grid versus Cartesian. PolarFormer argues a polar grid matches the imaging geometry better 2206.15398 §1. The gain it reports over a Cartesian baseline is small: 0.4 mAP for polar features with a Cartesian head 2206.15398 tab. 2a, and 1.1 mAP for the full model against CenterPoint on a Cartesian grid 2206.15398 tab. 2a. These are the paper's own ablations on one backbone, so they do not show how much of the gain the polar grid alone accounts for.
• Within BEVFusion. The main text says the fusion stage runs 9 epochs, while the appendix gives 6 epochs for TransFusion-L and CenterPoint 2205.13790 §4.1 2205.13790 app. B.1. The paper describes a per-object draw for object-point dropping, while the code makes one draw per frame and drops all points in every ground-truth box [arxiv:2205.13790 §4.4.1] transforms_3d.py. The code also adds a depth loss from projected LiDAR points, which the paper does not describe bevf_transfusion.py. The card records these in full under "Paper vs code".
• Within DeepInteraction. The paper says its two-stage training freezes only the image branch in the second stage, while the code also freezes most LiDAR modules 2208.11112 §4.2 Fusion_0075_refactor.py. The reproduced numbers depend on which freezing rule is used. The paper's decoder depth also differs from the released configuration 2208.11112 §4.2.
• Fusion against LiDAR alone. The survey's summary, drawn from KITTI results, says multimodal fusion still trails point cloud methods 2106.10823 §3.3 2106.10823 tab. 6. BEVFusion reports that fusion beats its LiDAR-only baseline on nuScenes validation [arxiv:2205.13790 tab. 1]. The survey is from 2021 and BEVFusion from 2022, and the two use different benchmarks, so the statements may not be about the same setting. No single experiment in the cards settles it.
• Within TopoFG. The text says the global spatial prior improves all metrics 2511.12590 §4.4. Table 4 shows lower lane-topology scores for the full prior than for the local prior alone: 26.1 against 26.7 on TOP_ll and 26.6 against 27.3 on TOP_lt 2511.12590 tab. 4. The overall score still rises, so the text overstates the table on these two metrics.
• Drive-OccWorld's planning baseline. Both world-model cards report Drive-OccWorld at 0.85 m average planning L2 under the NoAvg protocol 2408.14197 tab. 5 2510.16729 tab. 4. The Drive-OccWorld card finds that the released configs cannot reproduce that row [code: projects/configs/inflated/action_condition_GMO.py#L43]. IR-WM does not say whether it re-ran the baseline or copied it 2510.16729 tab. 4.
• Real-time claim in Drive-OccWorld. The card records that the paper calls its lowest configuration real-time. The same paper's Table 9 gives 140 ms of encoder time and 190 ms of decoder time for that configuration on an A6000 2408.14197 tab. 9. In that row the decoder takes longer than the encoder.
• Horizon in IR-WM. The text says four future timestamps. The fine-grained tables label the horizon 2 s, and the end-to-end tables label it 2.5 s 2510.16729 §4.1.1 2510.16729 tab. 2 2510.16729 tab. 3. Compare numbers only within one table.

Papers

• BEVFusion: A Simple and Robust LiDAR-Camera Fusion Framework: a camera stream lifted into a BEV grid with predicted depth, fused with a LiDAR BEV map, and robust to LiDAR loss in author-reported tests.
• PolarFormer: Multi-camera 3D Object Detection with Polar Transformer: camera-only detection on a polar BEV grid, with cross-plane attention and no dense depth estimation.
• DeepInteraction: 3D Object Detection via Modality Interaction: separate LiDAR BEV and image representations that interact in an encoder and a decoder.
• Joint 3D Proposal Generation and Object Detection from View Aggregation: AVOD, a LiDAR BEV map and an image cropped and averaged at each anchor and proposal, for cars, pedestrians and cyclists.
• BEVFormer: Learning Bird's-Eye-View Representation from Multi-Camera Images via Spatiotemporal Transformers: camera-only learned BEV queries, with deformable spatial attention and a temporal grid carried over from earlier frames.
• Categorical Depth Distribution Network for Monocular 3D Object Detection: a single camera lifted into a voxel grid with a predicted depth distribution, collapsed to BEV, with LiDAR-derived depth labels used only in training.
• BADet: Boundary-Aware 3D Object Detection from Point Clouds: a LiDAR BEV map as one of three node sources in a graph refiner for two-stage detection.
• Fine-Grained Representation for Lane Topology Reasoning: a BEV lane mask prior with one query per lane point, and a connectivity head on the first and last point of each lane.
• 3D Object Detection for Autonomous Driving: A Survey: a taxonomy of camera, LiDAR and fusion detectors, with the BEV collapse and the camera lift placed among them.
• Driving in the Occupancy World: Vision-Centric 4D Occupancy Forecasting and Planning via World Models for Autonomous Driving: a camera-only world model whose BEV memory is normalised by ego motion, with occupancy forecasting and a planner that scores sampled trajectories.
• Vision-Centric 4D Occupancy Forecasting and Planning via Implicit Residual World Models: a camera-only world model that predicts a residual BEV change per step, with feature alignment and a planner on the generated BEV features.
• Vehicle Dynamics Embedded World Models for Autonomous Driving: a two-channel BEV raster as the observation of a Dreamer-style agent, with the ego dynamics modelled apart from the environment.
• End-to-End Autonomous Driving through V2X Cooperation: a roadside BEV encoder whose output is sent as sparse queries and one occupancy map with flow, fused into the vehicle's planner.
• OMEGA: Efficient Occlusion-Aware Navigation for Air-Ground Robot in Dynamic Environments via State Space Model: a LiDAR occupancy network with semantic and geometric BEV branches fused by a U-Net, using Mamba blocks in both branches.
• LaserNet: An Efficient Probabilistic 3D Object Detector for Autonomous Driving: a LiDAR detector on the range image, with a mixture of box distributions per point, mean-shift merging and an adaptive NMS. It builds no BEV grid.
• 3D Object Detection for Autonomous Driving: A Comprehensive Survey: a 2022 survey that sorts LiDAR, camera and fusion detectors and compiles author-reported scores on KITTI, nuScenes and Waymo, with mixed splits.