BEV感知技术路线详解：从坐标系统一到量产落地

智驾行业这两年的变化用一个词形容就是卷卷完传感器卷算力卷完算力开始卷算法架构。如果你关注过智驾相关的技术分享大概率逃不开一个词BEV。从特斯拉当年的AI Day开始Birds Eye View这个鸟瞰视角概念就火遍了大江南北到现在国内智驾公司无论大小宣讲自己技术路线时不提BEV似乎都没法开口。不过火归火很多想入门或者在行业边缘观望的朋友对BEV的认知还停留在把摄像头画面拼成俯视图这个模糊层面。真正的BEV感知远不止拼接这么简单它是一套把多传感器数据统一到三维鸟瞰坐标系下、直接输出结构化感知结果的深度学习范式。这套范式重新定义了智驾感知的上限也直接决定了后续规划、控制模块能否做出正确决策。这篇文章我想从一个实际做智驾感知的工程师视角把BEV感知这条技术路线从入门到核心的关键节点全部梳理一遍。适合三类人看一是刚入行想做感知算法的工程师二是想搞清楚技术方向的在校学生三是虽然不写代码但需要跟技术团队对齐认知的产品、项目管理人员。我不会只讲概念会把技术选型背后的逻辑、工程化落地时踩过的坑、以及未来演进方向一起聊透。1. 感知系统的坐标系之战为什么偏偏是BEV1.1 摄像头视角的近视眼困境在BEV火起来之前主流智驾感知方案大多在做什么摄像头图像空间里做2D目标检测然后在后处理里依靠逆透视变换IPM或者地面平面假设进行坐标映射。听起来似乎也能用但实际上问题非常多。最典型的场景是高速公路上前车急刹。纯视觉方案在图像空间里检测到前车但如果要判断前车距离我到底有多远图像上只能看到车变大了具体距离需要通过目标在图像中的位置、大小以及相机内外参推算。这个推算过程极度依赖地面平坦假设遇到坡道、颠簸或者车辆俯仰变化距离误差可以轻松超过一米这在安全冗余里是完全不可接受的。另一个致命问题是多相机之间的割裂。车上装了六到八个摄像头每个摄像头看到的都是局部视角帧与帧之间、相机与相机之间没有统一坐标系。要跟踪一个跨越相邻相机视野的目标传统方案只能靠后处理逻辑去拼凑经常出现目标ID跳变、位置跳变的情况。这就是感知系统的坐标系之战——到底把感知结果放在哪个坐标系下表达才能最稳定、最简洁、最有利于后续决策。BEV的核心思路就是不要各自为战把全部输入统一投到自车为中心的鸟瞰坐标系里在这个坐标系下做检测、分割、预测一步到位。1.2 特斯拉炒火的概念国内企业如何跟进BEV感知这个概念被广泛认知特斯拉功不可没。从2020年前后特斯拉AI Day上展示的BEV网络结构开始整个行业都看到了这套范式在纯视觉方案下的潜力。国内企业跟进的速度非常快蔚小理、华为、大疆车载、Momenta、地平线基本都在近两年内完成了BEV感知架构的落地。为什么国内跟进这么积极一个原因是纯视觉或轻地图路线的兴起。过去智驾依赖高精地图提供先验信息但高精地图的采集和维护成本高得吓人且无法实时反映道路变化。BEV感知配合实时构建的局部语义地图可以在一定程度上替代高精地图的实时性短板。另一个原因是多传感器融合的需求。现在主流方案基本都是摄像头激光雷达毫米波雷达的组合传统融合方案大多在物体层面做融合也就是每个传感器独立感知完再凑到一起这种方式在传感器视野重叠区域容易出现目标不一致的问题。BEV天然为多传感器融合提供了统一的坐标空间可以在特征层面做到真融合而不是后处理层面的假拼凑。这里有一个很关键的区别特征级融合 vs 目标级融合。BEV空间下的融合发生在特征层面各传感器提取的特征被投到同一个BEV网格上网络自动学习哪些区域该信任哪个传感器这在雨雾天气、激光雷达故障等场景下有质的提升。目标级融合则是在后端把各自检测结果合并本质上是规则系统无法应对复杂的置信度冲突。1.3 BEV是最终答案吗必须先给新人打一个预防针BEV不是智驾感知的终点但它是现阶段最成熟、最能打的范式。它最大的贡献是把感知问题从图像域推到了空间域让算法天然具备了几何一致性。但也正因为它的流行业界也在反思它的问题比如BEV网格的分辨率受限于算力网格太密计算量爆炸网格太粗小目标检测困难。后续才有了Occupancy Network这类更细粒度的三维表达但它仍然建立在BEV框架的思路之上。所以学BEV不是学一个过时的东西而是学一套空间统一表达的思维方法论这套方法论未来很长时间内都不过时。2. 主干网络之争从LSS到Transformer的路线选择2.1 LSS视觉特征如何发射到鸟瞰图聊BEV感知绕不开的一篇奠基之作是LSS全称是Lift, Splat, Shoot。这篇论文提出的思想几乎奠定了基于视觉的BEV感知的基本操作框架。这三个词分别代表三个阶段先把2D图像特征逐像素提升到3D空间Lift再把3D空间中的特征撒到BEV网格上Splat最后在BEV网格上做感知任务Shoot。我常用一个类比帮助理解LSS的流程把每个图像像素想成向三维空间发射一束光线光线沿途会碰到很多可能的位置网络需要为光线上每个离散深度点预测一个概率表示这个像素对应的物体到底出现在这个深度点的可能性有多大。有了深度概率之后把图像特征按照概率加权放到三维空间里这就是所谓的提升。然后把三维空间沿着高度方向压扁投到二维的BEV网格平面上完成撒的过程。这套操作对算力的消耗是巨大的因为每个像素都要做多深度维度的外积计算。早期LSS在嵌入式平台上跑实时非常吃力所以后来的很多工作都在优化这一环节的效率比如减少深度采样数量、使用稀疏化策略等。2.2 Transformer让BEV Query自动长出感知结果LSS虽然经典但它存在一个绕不开的问题深度分布预测得准不准直接决定了整个BEV特征的准不准而深度预测本身是一个很有挑战的问题。Transformer路线换了一种思路不再去显式做2D到3D的几何提升而是把BEV平面划分成一个个网格位置编码称为BEV Query让注意力机制自动去图像特征里查询每个BEV位置应该放什么特征。这里面最典型的代表是BEVFormer。BEVFormer通过可变形注意力机制让每个BEV Query只在图像特征的相关区域做注意力采样避免了全局需要关注所有图像像素大幅压缩了计算量。同时它引入了时序模块把上一帧的BEV特征通过自车运动补偿后叠加到当前帧这让网络天然具备了一定的时序建模和遮挡推理能力。2.3 实际工程中怎么选从学术论文的角度两条路线都有大量变体但从实际工程落地的角度我的经验是LSS系更适合传感器配置固定、算力相对紧张、纯视觉方案的中低阶智驾场景Transformer系更适合传感器冗余度高、算力充裕、需要更强泛化能力的高阶智驾场景。为什么会这样原因在于两者的先验假设不同。LSS假设深度概率是可学习的几何关系它需要大量的数据来拟合相机的内外参数特征因此传感器一旦换了位置或者型号网络需要重新适配Transformer路线虽然没有显式几何建模但它通过注意力机制在数据中隐式学习图像特征到BEV位置的对应关系对相机参数变化的鲁棒性相对更好代价是训练时间更长、对数据质量要求更高。对比维度LSS路线Transformer路线核心操作像素深度估计外积投影BEV Query可变形注意力显式几何建模有无隐式学习计算开销中等需深度维度乘法较高注意力矩阵计算量大传感器变动鲁棒性较差需重新适配相对更好典型代表Lift-Splat-Shoot, BEVDetBEVFormer, PETR适用场景轻地图、算力有限的纯视觉方案高阶智驾、多传感器融合方案训练这类网络时有一条很实用的心得先固定相机参数训练一段时间让网络优先学到图像特征的语义信息再解锁相机参数进行微调。直接从头到尾端到端训练浅层特征可能一直学不稳定导致深度预测振荡收敛速度会慢不少。这在LSS系网络里尤其明显。3. 两张全景图早期融合怎么演进到BEV空间3.1 前BEV时代目标级融合的创可贴打法在BEV概念普及之前各传感器数据如何协同工作一直是个老大难问题。最常见的方案是相机做识别、雷达做测距的并联结构相机输出的目标列表和毫米波雷达输出的目标列表通过匈牙利匹配、卡尔曼滤波来做目标关联然后在决策层做加权融合。这套方案从功能上车上看是能跑通的但问题在于它是创可贴式的每个传感器的缺陷都需要用后处理去弥补算法工程师70%的精力可能都在调标定值和关联阈值换个传感器配置又得从头来过。到了深度学习普及之后出现了图像域特征和点云特征在二维平面上拼接的网络结构比如把激光雷达点云投影到图像平面在图像特征层面做融合这类方案叫特征级融合。它的融合层次虽然比目标级更深但融合空间仍然位于图像坐标系说白了还是以图像为中心的视角。3.2 BEV空间把一切放到一个上帝视角里BEV范式的革命性在于把融合空间从图像域彻底搬到了三维BEV域。在这个空间里每个传感器都被看作一个采集器它们的特征被统一投射到以自车为中心的网格平面上网络在同一个坐标系下学习特征交互。打个比方目标级融合的画像是几个人各自描述了同一样东西最后靠人脑去判断这些描述是否一致特征级融合画像是几个人的描述先转写成文字再让模型去理解文字BEV融合画像是把所有人的描述全部翻译成同一张地图上的信息模型直接在地图上工作。这个地图视角天然解决了传感器视野冲突的问题也天然方便后续的路径规划模块使用。3.3 从传感器套件到传感器无关架构的转变从工程架构来看BEV带来的更深层变化是传感器无关架构成为可能。过去传感器配置一变整个软件链路都要跟着调整而在BEV框架下只要传感器外参标定准确不管你是用6个摄像头还是8个摄像头不管激光雷达是上半部还是下半部所有数据都先投到BEV空间后续的感知逻辑完全不需要改动。这意味着车型适配成本大幅下降一个软件栈可以快速部署到多款车型上。这个架构优势在量产前的矩阵化开发阶段尤其明显。我经历过的一个项目从A车型迁移到B车型感知代码一行没改只更新了标定参数和传感器配置文件一周内就跑通了原本需要两个多月的移植工作。放在过去的目标级融合方案里这种迁移基本等于重新开发。3.4 部署推理中的隐形墙BEV也要尊重硬件很多人一谈BEV就只看网络结构但在实际工程中能否高效部署决定了这套架构能不能量产。BEV感知对算力的需求远超传统的2D感知因为它引入了空间的维度扩展特征图从图像分辨率变成了BEV网格分辨率乘通道数。举个例子一个120米见方、分辨率0.4米的BEV网格平面就是300乘300的网格每个网格如果产生64维特征那么单帧BEV特征就有将近580万个数值参与后续计算。这个量级放在底层算力有限的域控制器上是实实在在的压力。所以在选BEV架构的时候不能只看精度指标还要看模型在目标芯片上的算子支持情况。比如有些车载芯片对稀疏卷积Sparse Convolution支持得并不好而很多点云BEV网络恰恰依赖稀疏卷积来降低计算量这就导致论文里速度很快到了自家芯片上反而跑不动。我的建议是做BEV架构选型之前先拉一张目标平台的算子支持清单再对照候选模型的算子构成提前把不可行的路线筛掉能省下后面一大半的部署痛苦。4. 感知任务全景图检测、占用网络、轨迹预测的三级火箭4.1 目标检测BEV下一切变得直接了传统图像目标检测输出的是2D框而BEV感知输出的是3D框包括中心点坐标、长宽高、航向角、速度等信息。这个转变太关键了因为下游的规划控制器直接需要的是3D空间的信息BEV空间下的检测结果天然就是这些量。BEV下的3D目标检测在实际工程中最明显的体验是跟踪的稳定性大幅提升。为什么因为目标和自车都在同一个鸟瞰坐标系下运动目标的运动模型在表达式上天然平滑不需要像在图像坐标系里那样做复杂的透视补偿。以前在图像域里目标从左前摄像头切换到正前摄像头ID经常跳变在BEV框架下这个跨界问题基本消失了。4.2 占用网络从看得见到看得全2023年之后占用网络逐渐成为智驾感知的另一个热词。它的核心思路是不再把世界物体抽象成一个个框而是对空间进行体素化预测每个体素是被占据还是空闲以及如果被占据它属于什么语义类别。这种表示方法对不规则障碍物比如掉落的轮胎、侧翻的卡车、施工路障的感知能力远超3D框检测。占用网络和BEV是什么关系占用网络输出的三维体素空间通常在BEV平面上建立柱状结构再沿着高度方向展开。也就是说BEV仍然是它的空间推理骨架只不过高度方向的信息没有被压扁而是被保留了下来。从工程角度讲占用网络给下游规控提供了连续的空间占用概率这在开放道路的决策中特别有用。我做过的项目里占用网络上线后一个很直观的变化是对异形障碍物的误检率下降了三分之一。过去依赖3D框检测遇到形状不规则目标很容易出现置信度低、漏检或者误检出很多小碎片框的问题换成占用网络后空间占据的表达天然排除掉了这一类形状怪异的框问题。4.3 轨迹预测从我在哪到你去哪感知系统做到第三步是要回答周围的车接下来会怎么走。轨迹预测模块通常在BEV特征的基础上结合目标历史轨迹、道路结构信息预测未来三到八秒内目标可能的多条轨迹及其概率。这里的核心难点是多模态。所谓多模态就是前方路口左转车可能直行、可能变道、可能掉头这些可能性同时成立。BEV在这个环节的优势在于预测模块可以直接在BEV空间内进行交互建模。两个相距不远的目标在BEV空间里靠得很近网络可以通过图神经网络或注意力机制建模目标之间的交互关系这在过去图像域的表达上很难实现。4.4 三个任务怎么串成一条流水线实际工程中检测和占用网络通常是并行运行的它们产出不同的感知结果但共享同一个BEV特征骨干网。这样可以大幅减少重复计算。轨迹预测则依赖前两者的输出在时序维度上运行。因此整体架构可以看作三级火箭第一级多传感器输入在BEV空间融合产出一份统一的BEV特征。第二级这份BEV特征并行驱动3D目标检测和占用网络输出当前时刻的静态、动态目标信息。第三级基于目标的检测结果和时空BEV特征做轨迹预测输出未来时刻的运动预测。在工程架构上要特别小心共享骨干网带来的训练耦合问题。检测和占用网络对特征的关注点不同检测更关注目标边界和中心点占用更关注稠密的占据语义如果直接多任务学习可能出现一个任务收敛快、另一个任务始终不涨点的情况。比较稳妥的做法是分级训练先单独训练特征骨干网再插入各个任务头最后放开联合微调。这个顺序能明显减少任务之间的干扰。4.5 感知只是起点别搞混感知和决策的边界很多新人容易把BEV感知理解成智驾的全部其实感知只是智驾大系统里的一个环节。BEV感知输出的结构化结果会送入预测、规划、控制模块最终转化为方向盘角度和油门刹车信号。在工程团队里感知组和规控组的协同方式通常是把BEV感知结果发布成中间件消息规控模块订阅这些消息做后续处理。这也意味着BEV感知的接口设计很关键——输出的坐标定义、航向角定义、速度定义必须和规控对齐好。我见过一个项目因为航向角定义差了90度导致规划模块在低速泊车场景反复转向排查了半天才发现是接口约定不一致。做感知模块的时候一定要在接口文档里把坐标系、单位、离散化方式写得清清楚楚这种跨团队的小事往往是最容易出大事的地方。5. 工程落地避坑指南从模型到量产的真问题5.1 传感器标定BEV的地基塌了一切白搭BEV感知对传感器标定的依赖程度是传统方案完全无法比拟的。因为BEV的核心假设是所有传感器都能精确映射到统一坐标系一旦标定误差超过一定阈值网络学到的几何关系就会被污染感知精度断崖式下跌。这里特别提醒的是相机内参的温度漂移和振动漂移问题。批量量产的车辆在夏天暴晒和冬天严寒环境下相机支架的物理形变会导致内参偏移如果这个偏移没有定期校正BEV网络输出会出现系统性偏差。现在的量产方案普遍会做在线标定或者定期整车的标定自检目的就是补偿这类缓慢漂移。落地时最好在BEV特征网络的输入端加上一个数据质量监控模块关注每个相机的图像清晰度、曝光情况以及标定残差。当标定残差突然增大时自动降级到非BEV的紧急兜底感知模式避免感知结果看起来正常但实际错得离谱。5.2 真值方案怎么选从人工标注到自动标注训练BEV感知网络需要大量的3D真值而人工标注3D框的成本和周期比2D标注高一个数量级这是很多团队低估了的点。纯视觉BEV方案通常采用激光雷达自动标注路线也就是利用激光雷达的几何信息自动生成目标的3D位置和朝向再用相机图像做人工校验。而激光雷达方案本身则可以利用多帧时序融合来做自动标注。这里的关键在于真值质量和覆盖率的平衡。追求极致精度会导致自动标注流水线长期阻塞追求覆盖率又会把噪声带进训练数据里。我比较推荐的做法是先做一批高精度人工精修的真值作为验证集再用自动标注产出的数据做训练集。这样能保证评价指标的纯净同时训练数据的规模可以快速扩张。5.3 数据闭环corner case从哪来、怎么补BEV感知落地过程中最磨人的不是模型结构而是数据闭环。网络在常规场景能达到99%以上的精度但那些1%的corner case比如夜间逆光下的异形车辆、被落叶遮挡的路肩、极端暴雨下的交通参与者才是量产真正要跨越的坎。我的经验是建立一套数据回传策略十分关键。车端只回传触发特定规则的数据片段比如感知置信度低、规划模块强烈刹车、天气传感器检测到雨雪等。云端对回传数据进行聚类和筛选挑出有价值的新场景回灌到训练集里。这看起来好像是数据平台团队的事情但实际上感知算法工程师必须深度参与——哪些数据值得回传、聚类阈值设多少都依赖于对感知模型失败的深刻理解。5.4 未来趋势BEV演进路上的三个方向最后聊一下BEV感知这条路线接下来可能走向哪里。第一个方向是端到端化从感知直接输出控制命令不再人为地划分为感知、预测、规划模块。特斯拉FSD V12就是这一方向的代表但端到端对算力和数据量的要求极高离全面量产还有距离。第二个方向是更高效的三维表达从BEV平面到占用网络再到显式的三维高斯表达空间信息和语义信息的融合会更加紧密。第三个方向是轻量化把BEV网络在算力更低的平台比如单颗Orin N上跑通城市辅助驾驶上运行这要求架构设计上做极致的算子融合和量化优化。现在回过头看我自己从传统2D感知转向BEV感知的过程最核心的认知转变是干智驾感知不能只看感知模块内部一定要把感知放到整个智驾系统里去理解。坐标系的选择、特征投到哪里、输出怎么定义每一层都牵动着上下游模块。框架决定上限细节决定下限这句话在BEV感知这条路上体现得淋漓尽致。希望这篇文章能帮你节省一些自己摸索的时间快速建立起一张有主干、有枝叶的认知地图。