资讯动态

BEV感知十年演进:从IPM到Transformer再到端到端量产落地

发布时间:2026/10/21 9:27:15 来源:尧图企业网站定制
BEV感知在自动驾驶圈子里已经成为一个绕不开的底层层。不管你是做视觉、做激光雷达融合还是做规划控制只要涉及环境感知BEV这个词就一定会出现在你的算法脑图里。这篇内容想帮大家把从2015年前后到2025年这几年间BEV感知是怎么一步步从实验室概念变成量产车标配的完整脉络捋一遍重点说说每一阶段的思路转折、工程约束和落地经验。我会尽量用做工程的眼光去讲而不是讲论文式的抽象概念。因为BEV真正走到量产靠的不是哪篇论文一时惊艳而是整个系统在算力、标定、数据闭环这些维度上找到了可落地的平衡点。这篇文章适合刚入行想建立知识框架的同学也适合已经在做感知开发、想回头复盘技术路线的工程师。1. 为什么2015年之前没人提“BEV感知”1.1 二维矩形框和“各自为政”的感知时代在2015年前后主流车载感知系统的输出还是2D检测框加目标的类别标签。摄像头负责在图像平面找到车辆、行人、自行车的位置毫米波雷达负责给出目标的距离和速度激光雷达则输出三维点云供后融合模块使用。这套架构的本质问题是坐标系不统一。图像检测结果表达的是像素坐标雷达目标表达的是笛卡尔坐标激光雷达点云表达的是传感器自身坐标系后融合模块拿到这些结果之后需要做大量坐标变换和匹配工作才能拼出一个大致可信的车辆周围环境模型。这个模型通常是离散的、目标级别的车道线、路沿、交通标志这些几何元素极其容易被忽略或者被切割成零散片段。我见过不少2017年之前的工程代码融合节点的逻辑比检测算法本身还复杂各种卡尔曼滤波器、匈牙利匹配器、坐标投影纠偏码堆在一起一旦车辆经过大的颠簸或者坡道外参发生微小变化融合结果就立刻出现目标跳变。这本质上不是算法能力不够而是架构顶层设计就让每个传感器各说各话没有一个共同的“底板”。BEV感知的核心价值就在于它把这个“底板”统一到了自车坐标系下的俯视图网格上。1.2 从图像视角到俯视视角的思维转折2016年左右业界开始逐渐意识到下游的规划控制模块根本不在乎图像长什么样最关心的东西是“自车周围哪些区域被占据、哪些区域可通行、障碍物以什么速度和方向移动”。这种需求天然适合用俯视图来表达也就是把车辆周围环境拍扁到地面平面形成一张以自车为中心的栅格图。栅格图里每一个格子代表实际空间的一块区域可能是道路、可能是车辆、可能是树干、可能是空隙。要生成这种俯视图最简单的办法是逆透视映射IPMInverse Perspective Mapping。这个阶段很多团队开始把摄像头图像投影到地平面上用图像数据和IPM变换拼出局部俯视拼接图。IPM的优点是计算简单依赖标定好的相机内外参即可完成像素和地面坐标之间的映射。缺点是它假设地面是一个平面遇到坡道、起伏路面、道路边缘翘起时投影结果会产生严重的拉伸失真。今天看来IPM更多像是一个前BEV时代的过渡产物但它让人们意识到了一个问题——如果所有感知信息都能在同一个俯视图网格里对齐下游的融合和规划会变得非常干净。2. 特征级BEV从后融合走向前融合的关键一步2.1 为什么把特征图投到地面比把目标投到地面更优2018年前后视觉检测的深度估计能力有所提升单目图像的深度预测不再是纯粹的盲猜而是可以通过训练数据学到一定的尺度感。于是行业里出现了另一条思路不再在后融合阶段把“目标框”投影到地面而是在特征层面把图像特征图映射到BEV网格。这就是特征级BEV的雏形。这种做法的思路逻辑很清晰目标级投影会丢信息比如一辆遮挡了大半的车检测器只能给出一个框框内丰富的纹理、边缘、阴影细节在投影阶段全部被丢弃后融合只能靠框和速度信息去猜而特征级投影则把整个特征图的所有通道都搬到BEV空间后续所有任务可以共享这份高信息密度特征车道线分割、可行驶区域分割、障碍物检测、目标速度回归都可以从同一份BEV特征里取数。这种共享特征的思想基本奠定了后续所有BEV算法的工作范式也让“前融合”这个概念真正落地了。2.2 工程视角下的坐标变换与插值细节特征级BEV在工程实现上最麻烦的不是网络结构而是每一步坐标变换的精度控制。图像特征图上的每一点都有对应的像素坐标(u, v)结合相机内参和外参可以反投影到车体坐标系下的三维射线。这条射线与地面平面相交就得到该点在地面上的位置再映射到BEV网格的行列索引就完成了一个特征像素到BEV网格的映射关系。但实际做起来会有三个坑。第一个坑是反投影和地面交会计算必须考虑相机安装高度和俯仰角车辆加减速时车身俯仰角变化幅度在±3度左右一个3度的俯仰误差在20米处会造成接近1米的横向位移偏差这已经足够让感知结果错乱。第二个坑是图像特征图分辨率与BEV网格分辨率之间的比例关系远不是整数倍需要做双线性插值或者最近邻采样每层特征的分辨率不同映射表必须逐层单独计算不能共享一份采样网格。第三个坑是多相机重叠区域的拼接缝特征级拼接如果不做过渡处理重叠区域的响应会突然加倍导致这个区域检测置信度虚高相邻区域却响应空洞实际处理时通常会对权重做高斯衰减或者距离加权融合。2.3 多传感器的时间同步与空间对齐特征级BEV时代的另一个典型问题就是时间戳同步。摄像头是30帧率对外发布激光雷达是10赫兹扫描毫米波雷达是20赫兹更新。如果拿三个不同时刻的数据直接做特征拼接车辆在高速转弯时会产生明显的“鬼影”比如前一刻车辆在左车道后一刻已经摆在右车道边缘融合出来的BEV特征里两个位置都有响应。工程上让各传感器发布到统一时间基准里做运动补偿插值再把点云运动补偿后的特征放入同一个BEV网格。这一步听起来基础但几乎所有量产问题最后排查下来都跟时间戳没有严格对齐有关。3. Transformer时代BEV从“手工变换”到“可学习查询”3.1 基于可学习查询的BEV构建逻辑2020年到2022年间Transformer结构在视觉领域全面开花之后BEV感知也迎来了它的重大转折。核心变化是把“图像特征怎么放到地面上去”这种需要明确坐标变换规则的问题变成了“让网络用一组可学习的网格查询自己去图像特征里寻找需要的信息”。具体来说BEV网格里的每一个格子都会被初始化一个特征向量这个特征向量在Transformer解码器里充当查询query图像特征图充当键和值key-value。网络通过自注意力机制学习到当某个格子处在自车正前方20米时应该主要从图像特征的中上部区域取信息当格子处于侧方时又应该从图像特征的边缘区域取信息。整张BEV特征图不再依赖显式的IPM或者几何投影公式来生成而是由注意力机制自适应地从多相机图像特征里聚合而来。这一个改变解决了许多此前IPM时代遗留的老问题坡道环境下BEV网格不再违反平面假设多相机重叠区域的融合权重由网络自动学习无需手工调距离衰减参数侧向和后方相机因畸变导致的投影误差也不再依赖标定的绝对精度来兜底。Transformer的自注意力本质上让模型自己学会了“在哪里找什么”只要训练数据覆盖足够的场景多样性BEV特征图的表达质量就会比手工变换方案稳定得多。3.2 计算量与量产约束之间的妥协纯粹的可学习查询方案有一个显著缺点——计算量巨大。以典型方案为例一个BEV网格通常取128×128到200×200之间的分辨率每个网格查询需要在全部图像特征图上做注意力计算这个复杂度在车端芯片上基本跑不起来。量产落地时通常会做几种妥协第一种是稀疏化查询只在有先验障碍物或者地形起伏的网格位置计算注意力空白区域用全局池化特征直接填充第二种是局部注意力替代全局注意力每个BEV查询只看图像特征中与自己几何位置邻近的局部窗口而不是看整张图特征第三种是把查询数量从密集网格降到稀疏锚点把网格做粗之后再用上采样恢复细节。我实际观察到的量产项目多数选用了局部注意力加稀疏化因为这两种改变能保住BEV特征的语义丰富度同时把计算量压到车端可推理范围。BEV网格分辨率的选择也很有讲究做到0.5米/格已能满足几十米范围内的决策需求但如果要做到类似停车位检测这种精细任务网格分辨率得拉到0.2米/格这个尺度下整张BEV特征的内存占用会成倍增长必须挂靠更高算力的域控制器才能跑得动。3.3 时序信息融合让BEV成为“活地图”很多团队在21年前后开始把时序融合引入BEV网络。说白了就是在BEV特征图基础上增加了一个递归结构当前帧的BEV特征会和历史BEV特征做基于自车运动的对齐和叠加。这样一来被遮挡的物体可以利用历史帧信息推断当前大致位置被短暂丢失的目标可以依靠历史轨迹维持一段时间的存在概率。更重要的是通过时序融合BEV特征里开始蕴含速度与运动趋势的隐性表达下游模块再做决策时不用每次从头看一遍场景。跑时序融合时需要注意一个坑自车位姿变换处理不好历史特征会被错误地“平移”到新的BEV网格里造成历史车辆变成拖影。工程上通常在网格坐标变换之间用车辆IMU测得的位移和转角做一次大致的刚体变换之后的残差让网络自己通过学习修正。4. 端到端与大模型2023到2025年的BEV质变4.1 BEV与占用网络、端到端驾驶的交织2023年之后BEV感知的边界明显被推向更远的地方。一方面占用网络Occupancy Network直接把BEV空间扩展成了三维占据场自车周围的每个体素被标记为占据或空闲甚至细分出语义类别比如车辆、行人、骑行者、障碍物。这套方案把BEV“一张俯视图”的思路升级成“三维语义占用图”对于解决异形障碍物、罕见卡车装载物这类corner case特别有效因为占用描述的是“这里有没有东西”而不是“这是什么东西”。另一个大变化是端到端驾驶方案越来越受到关注。在这些方案里BEV不再是一个显式的中间产物而是变成神经网络内部的特征表达之一。系统输入的是多模态传感器数据输出的是规划轨迹或者控制指令感知、预测、规划之间的模块边界被打破。BEV特征在这个过程中更像是“语义世界模型”的中间表示它不再需要具备人类容易理解的栅格化可视化形态而是一组隐含空间语义的高维向量。4.2 高精地图解耦与无图化趋势这几年BEV感知还有一个特别明显的应用方向演化就是与高精地图解耦。早期系统极度依赖高精地图提供先验车道拓扑信息BEV感知在其中主要承担“车道线补充和动态目标检测”的角色。但高精地图的鲜度问题催生了无图化路线BEV感知直接承担实时重建局部路网结构、车道拓扑、路口连接关系的任务。现在多数量产方案的做法是由BEV感知输出结构化车道中心线、车道边界和元素级拓扑关系再叠加轻量导航地图信息做全局路径引导车辆不需要依赖厘米级高精地图也能可靠运行。从工程实际看这条路线的效果高度依赖众包数据闭环质量如果车端发现局部路网拓扑与导航地图冲突上报后云端能在几天内完成修复和模型迭代这套系统就能在城市场景里保持很好的鲜度。相反如果数据闭环周期长模型就会在改道、修路频繁的区域反复出错甚至不如退回到纯地图依赖模式。4.3 视频BEV与大语言模型的融合探索2024年至2025年的趋势之一是把视频BEV跟大语言模型结合BEV特征作为视觉Token输入到语言模型中语言模型理解场景语义后输出结构化描述比如“前方施工护栏占用最左侧车道但在直行方向可通行”。这个方向目前更多是探索性质但它真正解决了传统规则逻辑难以表达复杂空间语义的问题。不过我对这类方案的实际量产前景持谨慎态度。大语言模型的推理时延不确定性、token长度限制导致的长距离感知瓶颈以及车端算力对百亿级参数的压缩挑战都决定了短期内它更适合做离线场景解析或者作为远程辅助模块直接进入车端闭环控制链路的可能性不大。5. 实操心得从论文到车端的BEV感知落地建议5.1 标定是BEV感知的生死线这些年我接手过的BEV项目凡是出现“远处目标横向漂移”“车道线地面投影扭曲”“重叠区检测置信度跳变”这类问题的排查到最后基本都落在标定环节。BEV感知的统一前提是“所有输入传感器都在同一坐标系下对齐”这个前提一天不满足Transformer算得再漂亮也没有意义。建议量产团队至少维护三套标定参数工厂下线标定、场端定期标定、在线联合标定同时建立外参健康度监控指标比如通过道路直线在BEV网格里的曲率变化来反推俯仰角是否漂移。外参漂移发生在剧烈颠簸或者小碰撞之后这方面我可以举一个实测例子某开发团队在针对极端颠簸路况进行数据采集时估计车辆在几十次剧烈冲击后相机俯仰角变化了约1.2度这个漂移量在近距离几乎没有感知但在30米外会造成约0.6米的横向偏移属于足以影响边缘通行决策的误差量级最终他们依靠这条路段的特征回归监控发现了问题。5.2 数据闭环决定模型上限算法只是一个环节真正决定BEV感知性能的是数据从哪里来、覆盖多少corner case、多久能回流到训练集。我强烈建议团队搭建单独针对BEV的挖掘系统监测点依次为多相机拼接后特征一致性分数、网格级不确定度、时序前后向对齐误差。任何一路超过阈值自动截取前后若干秒的原始数据包上传云端这些片段不需要标注也能用来做自监督和半监督训练让模型在持续运营过程中自动变稳。5.3 甄别BEV可视化陷阱做BEV感知项目时最容易产生错觉的地方是可视化。栅格图渲染到屏幕上线条整洁、目标清晰看起来很可靠但画面上一个被识别良好的人形轮廓在目标级接口输出的可能只是一个低置信度的矩形框。不要只看可视化效果评估模型要深入到特征层面去分析哪些区域响应高、哪些区域响应稀疏。工程上我习惯同时打开BEV特征热度图和目标级输出框交叉验证模型是否真的学到了空间语义而不是仅仅对部分纹理做了过拟合。5.4 算力约束下的网络结构选择如果是在量产域控制器上做BEV感知计算量预算一般只有几十到一百多TOPS这个约束下做超大分辨率和密集注意力基本不现实。我建议优先选择局部注意力加稀疏查询的路线先把网格分辨率定在0.4米格距左右后续需要精细感知再引入一个局部的高清分支出线。需要时刻记住BEV网络只是整个自动驾驶系统的一环它还面临规划和控制模块的资源抢占预留给系统的余量是一种取舍智慧。6. 回望十年BEV感知的演进逻辑与避坑宝典6.1 一份关于BEV感知的避坑速查表这里我把在不同项目里踩过的坑整理成一份简表供做量产BEV的朋友参考。场景方面坡道起步对IPM方案极为致命因为车辆俯仰角变化会导致网格投影偏差迅速扩大处理建议是放弃纯IPM方案改用可学习变换或者至少对俯仰角做在线估计补偿。多相机重叠区域如果采用简单平均会容易造成反应虚高建议过渡时使用距离加权插值分配权重。时序融合的参考帧若不做运动补偿会出现严重拖影建议始终用IMU或位姿估计结果做刚体变换后再输入到网络中。低纹理环境容易让深度估计崩溃从而退化到2D投影带来深度歧义建议结合雷达信息做深度先验监督或者引入历史帧时序信息进行约束。长期外参漂移无法通过感知侧解决建议建立在线标定模块并持续监控地面水平度和直线曲率来触发重标定请求。6.2 十年技术演变留下的三点个人感受先说第一点也是最重要的一点。BEV感知之所以能在这十年里经历从IPM到Transformer再到端到端的演变核心驱动力从来不是某个单一算法的突破而是算力、传感器成本、数据规模、芯片架构这几项基础设施的同步成熟。视觉BEV大规模普及的一个重要原因是激光雷达成本逐步下降但低成本视觉方案在过渡阶段的性能兜底能力也需要被正视这决定了一款车的中配和顶配到底要不要上激光雷达也决定了感知算法的冗余设计目标。第二个体会是模块化设计没有过时。哪怕端到端方案越来越多我在做量产项目时仍然倾向于让BEV网络输出一套显式的、可供勾稽校验的中间结果比如车道中心线、车道边界、目标运动轨迹。这些显式结果既可以用作安全兜底的规则层输入也可以在出问题时作为可解释性的抓手。全黑盒的端到端模型在量产合规和事故回溯上还有很长的路要走。第三个体会是感知的最终评价标准要看下游怎么用。一个BEV模型就算在感知排行榜上精度不是最高但只要它输出的车道拓扑能让规划模块稳定走完狭窄的园区道路并且不频繁触发接管那这就是一个成功落地的模型。反过来就算感知榜单上指标漂亮但规划模块发现输出的车道边界抖动频繁或者目标航向角跳变严重这类模型是做不了量产交付的。做感知不能只盯着自己的指标更要理解下游需要什么样的接口保真度。这十年看下来BEV感知从无到有、从粗糙到成熟的过程其实是整个自动驾驶行业在“如何表达道路世界”这个问题上不断反思和迭代的缩影。未来哪怕新范式出现BEV这套“自车为中心、统一坐标、多源融合”的底层层思路也一定会在很长一段时间里继续支撑自动驾驶系统往前走。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑