1. BEV感知概述：从“看路”到“看懂路”
各位同学，欢迎来到《BEV感知模型端侧移植》的第一章。
咱们开门见山。BEV感知，全称是Bird‘s Eye View Perception，翻译过来就是“鸟瞰视角感知”。说白了，就是让车学会像鸟一样，从天上往下看。
你想想看，人开车的时候，眼睛是平视前方的。看到前面有车，知道它在我前面；看到右边有行人，知道他在我右边。但问题是，这个“前面”和“右边”是相对车头朝向的。如果车在转弯，或者路是弯的，这个相对关系就变得很绕。
BEV的做法，是把所有传感器看到的东西——摄像头拍的、激光雷达扫的、毫米波雷达测的——全部投影到一个统一的、从上往下看的俯视图上。在这个图里，每个物体都有绝对的位置坐标，车在哪、人在哪、路沿在哪，一目了然。
核心一句话：BEV感知就是把多传感器数据统一到“上帝视角”的坐标系下，让自动驾驶系统真正理解周围环境的拓扑关系。
1.1 为什么自动驾驶离不开BEV？
我刚开始做自动驾驶感知的时候，用的还是传统的“前视单目”方案。摄像头拍一张图，检测出车和人，然后估算距离。听起来挺合理对吧？但实际跑起来，问题一堆。
举个例子。前视摄像头检测到一辆车，但它在画面里只露了半个屁股——被前面的公交车挡住了。这时候，系统就不知道它到底在哪。更麻烦的是，如果这辆车从左边车道变到右边车道，在图像里它只是从画面左边移到右边，但实际位置变化，你得靠复杂的跟踪算法去猜。
BEV方案直接解决了这个问题。它把所有检测结果放到一个统一的俯视图网格里。每个网格单元都对应真实世界的物理尺寸，比如20厘米×20厘米。物体在网格里的移动，直接对应真实世界的位移。
我总结了一下，BEV在自动驾驶里扮演了三个关键角色：
- 传感器融合的“粘合剂”：摄像头、激光雷达、毫米波雷达，各自有各自的坐标系。BEV提供了一个公共的“翻译平台”，让它们能对上话。
- 时序信息的“对齐器”：上一帧检测到的车，和这一帧检测到的车，在BEV空间里可以直接做位置关联，不需要复杂的特征匹配。
- 下游任务的“通用底座”：规划、控制、预测模块，都只需要看BEV空间里的障碍物和道路结构，不用关心原始传感器数据长什么样。
我的经验：在项目里，我见过团队花大量时间调前视方案的跟踪逻辑，结果换到BEV方案后，跟踪模块的代码量直接砍掉了一半。因为位置关系天然对齐了。
1.2 主流BEV方案对比：LSS、Transformer、IPM
目前业界主流的BEV构建方案，主要有三条技术路线。我分别说说它们的核心思路和适用场景。
| 方案 | 核心思路 | 优点 | 缺点 | 典型代表 |
|---|---|---|---|---|
| IPM（逆透视映射） | 利用相机内外参，将图像像素直接投影到地面平面 | 计算量极小，部署简单 | 依赖地面平坦假设，远处畸变严重 | 早期ADAS方案 |
| LSS（Lift-Splat-Shoot） | 先预测每个像素的深度分布，再“升维”到3D空间，最后“拍平”到BEV网格 | 深度信息可学习，适应复杂场景 | 计算量大，深度预测精度有限 | NVIDIA、特斯拉早期 |
| Transformer | 利用注意力机制，让图像特征直接“查询”BEV空间中的位置 | 端到端可训练，全局建模能力强 | 计算量最大，对硬件要求高 | BEVFormer、PETR |
1.2.1 IPM：最朴素的方案
IPM是最早被采用的BEV方案。它的原理很简单：假设地面是平的，利用相机标定好的内外参数，建立一个从图像像素坐标到地面物理坐标的映射关系。
嗯，这里要注意。这个“地面是平的”假设，在真实道路上几乎不成立。稍微有个坡，或者车身颠簸一下，投影出来的位置就歪了。我在早期一个泊车项目里用过IPM，车位上有个减速带，结果车位线投影出来直接扭曲了。
适用场景：低速、结构化停车场、固定路线。
1.2.2 LSS：可学习的深度升维
LSS方案是NVIDIA在2018年提出的。它的核心创新在于：不假设地面是平的，而是让网络自己去学习每个像素的深度。
具体流程分三步：
- Lift（升维）：对每个像素，预测它在不同深度上的概率分布。相当于给每个像素“拉”出一条深度射线。
- Splat（拍平）：把这些带深度信息的特征点，投影到BEV网格里，做累积和池化。
- Shoot（射击）：在BEV空间里做后续的检测、分割任务。
我个人的习惯是，把LSS理解成“用神经网络做三维重建”。它不依赖物理假设，但代价是计算量上去了。尤其是深度预测那一步，每个像素都要算几十个深度级别的概率，对端侧芯片来说是个不小的挑战。
避坑指南：我曾经在Jetson Orin上移植LSS模型，发现深度预测分支的卷积层特别多，导致推理速度上不去。后来把深度离散化从64级降到32级，精度只掉了1.2%，速度却快了近一倍。所以，深度离散化级别是个很好的调优切入点。
1.2.3 Transformer：注意力机制的降维打击
Transformer方案是这两年最火的。它的思路和LSS完全不同。LSS是“从图像出发，把特征推到3D空间”；Transformer是“从BEV空间出发，去图像里找对应的特征”。
具体来说，BEV空间里每个网格位置，会生成一组查询向量（Query）。这些查询向量通过注意力机制，去多张图像的特征图上“找”自己对应的特征。找到之后，把特征拉回到BEV网格里。
这样做的好处是：
- 天然支持多相机：一个查询可以同时关注6个相机的图像。
- 时序信息好融合：上一帧的BEV特征可以作为这一帧的输入，实现时序对齐。
但缺点也很明显——计算量巨大。一个BEV网格如果是200×200，那就是4万个查询向量，每个查询都要和图像特征做注意力计算。在端侧芯片上，这个计算量目前还很难跑实时。
1.3 三种方案的选型建议
我根据实际项目经验，给各位一个选型参考：
- 如果算力有限（比如TDA4、地平线J3）：优先考虑IPM或者轻量化的LSS变体。别碰Transformer，跑不动的。
- 如果算力中等（比如Jetson Orin NX）：LSS是性价比最高的选择。精度够用，部署工具链也成熟。
- 如果算力充足（比如Orin AGX、Thor）：直接上Transformer。端到端训练，效果上限高。
我的建议：别盲目追新。我在一个客户项目里，对方非要上Transformer，结果模型在Orin NX上只能跑8帧，而客户要求15帧。最后换回LSS，12帧达标，精度也够用。选方案，先看硬件预算。
1.4 BEV感知的整体流程
为了让大家有个全局印象，我画了一张流程图。它展示了从传感器输入到BEV输出的完整链路。
从这张图里可以看到，BEV特征图是整个系统的中枢。传感器数据进来，先经过特征提取网络，然后通过某种转换机制（LSS、Transformer或IPM）映射到BEV空间。之后，所有下游任务——检测、分割、预测——都共享这一份BEV特征。
嗯，这里要特别强调一下。在端侧移植时，最需要优化的就是“BEV空间转换”这个模块。它往往是整个模型的计算瓶颈。后面的章节，我会带大家一步步拆解这个模块，教你怎么在芯片上把它跑快。
1.5 本章小结
这一章，我们聊了三个核心问题：
- BEV是什么：一个统一的俯视图坐标系，让车真正“看懂”周围环境。
- BEV为什么重要：它解决了多传感器融合、时序对齐、下游任务统一的问题。
- 三种主流方案怎么选：IPM简单但受限，LSS均衡，Transformer上限高但吃算力。
我个人觉得，理解BEV的关键不在于记住那些花哨的网络结构，而在于想清楚一个问题：你打算怎么把不同传感器、不同时刻的信息，放到同一个空间里去做决策？想通了这一点，后面的技术细节就都是工具了。