1. BEV感知概述：从2D视觉到BEV的演进、BEV感知的核心优势、主流BEV方案对比（LSS、Transformer、IPM）
大家好，欢迎来到《BEV与Occupancy联合训练实战》的第一章。
说实话，每次带新人入门自动驾驶感知，我都要花不少时间解释一个问题：为什么我们非得搞BEV（鸟瞰图）？ 2D图像上检测得好好的，干嘛要费劲转成俯视图？
嗯，今天我们就来彻底聊透这个话题。我会结合自己踩过的坑，带你看看从2D到BEV的演进逻辑，以及目前主流的三种方案——LSS、Transformer、IPM——到底该怎么选。
1.1 从2D视觉到BEV的演进：为什么非转不可？
先说说传统2D感知的痛点。你想想看，一辆车在图像里可能只有几十个像素，但它在真实世界中的位置、朝向、速度，这些信息在2D空间里是严重扭曲的。我早期做项目时，遇到过最头疼的问题就是：前向摄像头检测到一辆车，但它在图像左侧，实际是在我左前方还是正前方？ 单目相机缺乏深度信息，这种歧义很难消除。
后来大家开始用IPM（逆透视映射）做简单转换，但那是基于地面平坦假设的，遇到坡道、颠簸路面，结果就崩了。我记得有一次测试，车过了一个小坡，IPM直接把路边的行人映射到了马路中间——这要是真上路，后果不堪设想。
所以，行业逐渐达成共识：感知必须在统一的BEV空间里做。 所有传感器（相机、激光雷达、毫米波）都投影到同一个俯视坐标系，这样物体的位置、速度、朝向就一目了然了。
核心结论： BEV感知的本质，是把多个视角的2D信息，融合到一个3D空间（俯视图）中，消除视角畸变和深度歧义。
1.2 BEV感知的核心优势
说白了，BEV带来的好处是实实在在的，我总结为三点：
- 空间统一性：所有传感器数据都在同一个坐标系下，融合变得简单。你不需要再纠结“这个雷达点云对应图像里的哪个像素”。
- 时序一致性：在BEV空间里做时序融合（比如跟踪、预测），天然就是物理世界的位置变化，比在图像空间做光流、匹配要稳定得多。
- 端到端可学习：从图像到BEV的转换，现在可以用神经网络（LSS、Transformer）来学习，不再依赖手工设计的几何变换，鲁棒性大幅提升。
我的经验： 在项目中，BEV最大的收益其实是简化了后处理。以前2D检测后还要做3D投影、去重、跟踪关联，代码量巨大。换成BEV后，很多逻辑直接在一个俯视图上完成，代码量减少了一半以上。
1.3 主流BEV方案对比：LSS、Transformer、IPM
目前主流的BEV方案，我按技术路线分成三类。先看一个对比表格，再逐个细说。
| 方案 | 核心思想 | 优点 | 缺点 | 代表工作 |
|---|---|---|---|---|
| IPM | 逆透视映射，基于几何 | 简单、速度快、无需训练 | 依赖地面平坦假设，远距离精度差 | 传统方法 |
| LSS | Lift-Splat-Shoot，深度估计+体素池化 | 显式建模深度，可解释性强 | 深度估计不准时误差大，计算量大 | BEVDet, BEVDepth |
| Transformer | Cross-Attention，隐式学习映射 | 无需深度监督，端到端效果好 | 训练收敛慢，对数据量要求高 | BEVFormer, PETR |
1.3.1 IPM：老派但仍有价值
IPM是最早的方案，说白了就是利用相机内参和外参，把图像像素映射到地面平面。我刚开始做感知时，用的就是IPM。它的优点是快，CPU上都能跑实时。但缺点也很明显：地面必须平坦。一旦有坡度，映射就全歪了。
我曾经在一个园区项目里用IPM做车道线检测，结果遇到一个10度的上坡，车道线直接飞到了天上。嗯，从那以后，我再也不敢在复杂场景里单独用IPM了。
避坑指南： 如果你只在结构化道路（高速、城市快速路）上做感知，IPM勉强可用。但遇到非铺装路面、坡道、颠簸路段，请直接放弃IPM。
1.3.2 LSS：显式深度估计的经典
LSS（Lift-Splat-Shoot）是NVIDIA在2020年提出的，核心思路是：先估计每个像素的深度分布，然后把图像特征“提升”到3D空间，再“拍平”到BEV网格上。
我个人很喜欢LSS的设计，因为它很直观。你想想看，每个像素都知道自己大概在哪个深度范围，然后所有像素一起投票，最终形成BEV特征图。我在做BEVDet复现时，发现LSS对深度估计的质量非常敏感。如果深度网络没训好，BEV特征图就会很模糊，像蒙了一层雾。
代码实现上，LSS的核心是体素池化（Voxel Pooling）。这里给一个简化的伪代码示意：
# 伪代码：LSS的核心步骤
def lift_splat(features, depth_probs, camera_params):
# 1. Lift: 每个像素生成深度分布，得到3D点云特征
points_3d = lift(features, depth_probs, camera_params)
# 2. Splat: 将3D点云投影到BEV网格，做体素池化
bev_feature = voxel_pooling(points_3d, grid_size)
return bev_feature
我的建议： 如果你有激光雷达做深度真值监督，LSS方案会非常稳。但纯视觉深度估计本身是个病态问题，所以LSS在远距离（>50米）的精度会下降。
1.3.3 Transformer：隐式学习的王者
Transformer方案（以BEVFormer为代表）彻底抛弃了显式深度估计。它用Cross-Attention机制，让BEV空间中的每个网格，自己去图像特征中“查询”对应的信息。说白了，就是让网络自己学会怎么从图像到BEV的映射。
我记得第一次跑BEVFormer时，被它的效果惊艳到了。在nuScenes数据集上，它的检测精度比LSS高了近10个点。但代价也很明显：训练太慢了。一个BEVFormer模型，8张A100要训好几天。而且对数据量要求极高，小数据集上容易过拟合。
不过，Transformer方案是目前的主流趋势。因为它不需要深度监督，可以端到端地学习，而且天然支持多模态融合（图像+雷达+地图）。
核心对比： LSS是“显式建模+几何先验”，Transformer是“隐式学习+数据驱动”。前者可解释性强，后者上限更高。
1.4 如何选择？我的实战建议
说了这么多，到底该选哪个？我根据项目经验，给一个简单的决策树：
- 场景简单、算力有限（比如园区低速车）：用IPM，够用且快。
- 有激光雷达、需要高精度（比如L4级Robotaxi）：用LSS，深度估计有真值，效果稳定。
- 纯视觉、追求极致性能（比如量产车）：用Transformer，虽然训练成本高，但效果上限最高。
当然，现在也有混合方案，比如LSS+Transformer的变体，但那是后话了。我们这门课后续会重点讲LSS和Transformer的联合训练，以及如何与Occupancy网络结合。
好了，第一章就到这里。下一章我们会深入LSS的数学原理和代码实现，到时候我会手把手带你写一个简单的BEV感知管线。我们下次见。