飞凡智驾BEV：已实现对遛狗行人、倒地通用障碍等感知

讲述 | 金杰盂

编辑 | 张祥威

“有了Occupancy后，是否还需要激光雷达？” 

“BEV+4D毫米波雷达方案，能否支持实现城市NOA？” 

“BEV落地中，芯片的哪些算子还不能很好的支持？” 

以上这些，是BEV落地中很多人关注的问题，也是上汽旗下飞凡汽车在量产落地BEV的过程已经有了答案的地方。 

相比特斯拉、蔚小理落地BEV方案的节奏，飞凡并不慢。 

2020年10月，特斯拉开始在美国进行基于BEV算法的FSD Beta测试。几个月后，2021年4月，飞凡汽车开始为PP-CEM智驾系统布局BEV算法。去年9月， BEV感知算法在飞凡R7车型上进行量产。 

PP-CEM&飞凡智能驾驶首席科学家金杰盂认为，BEV有以下几大优势： 

• 可以提供更好的异构多传感器的表征，进行多元数据的融合和预测处理；

• 更便利地进行时序融合，和更多的连续帧的特征处理；

• 把更多的任务模块集成到神经网络中。

金杰盂在上汽飞凡PP-CEM团队负责智能驾驶相关的开发和工程生产，带领团队完整量产了飞凡的R7和F7的Orin平台行泊一体智能驾驶系统和生产售后相关的全套开发落地。 

据他介绍，飞凡在研发BEV方案过程中，更注重对数据挖掘，以及多样性、有效性的获取，设置了非常多的触发事件，可以每周进行 250 万个clips的处理。 

另外，针对原生算子不支持的情况，会进行一定的操作组合，以及比如针对坐标处理层的定制化开发和算子优化，以实现性能的数倍提升。 

飞凡的量产车采用了不同传感器配置的方案，并且支持多种传感器下的Occupancy占用网络，这将为接下来的城市NOA落地打下基础。 

2023年下半年，是头部几家车企较量智驾水平的重要节点，飞凡在BEV方案上的投入，将是其跻身智驾第一梯队的基础。 

本文是HiEV出品的系列直播 「硬核拆解BEV」第四期，金杰盂分享的《车企如何布局BEV通往高阶智驾》内容梳理。 

一、注重数据挖掘，每周可以处理250万个clips

整体看，一套BEV方案有三个核心： 

• 芯片SoC；

• 像素Pixel；

• 点云Point Cloud。

今年，飞凡上线了泊车功能，即将在城市推送领航功能，一些如遥控泊车的功能也将释放。我们还在做 PP-CEM2.0的开发，接下来会推出更复杂场景下的功能。 

飞凡的智驾方案有不同的配置： 

• Pro版，包括5-6个毫米波雷达、12个摄像头、1个激光雷达，2颗Orin X ；

• Standard版，包括3-5个毫米波雷达、11个摄像头、1颗Orin X；

• Lite版，包括3到5个毫米波雷达、7个摄像头、1颗 Orin N。

在设计BEV方案时，摄像头、4D毫米波雷达、激光雷达会经过encoder的层级，然后进入Cross Attention层，生成多模态的3D特征。针对多模态的3D特征再进行时间序列的处理， 实现4D特征融合。 

整体上，有几类任务的Head网络： 

• 周围的静态交通环境要素，比如车道线、路沿、停止线、道路标识、人行道等；

• 交通参与者的任务输出，比如运动的障碍物、交通锥，红绿灯、车尾灯等；

• 泊车任务要素输出，比如泊车位、多语义分割通行空间与地面要素等；

• 语义占据栅格要素输出等。

如何实现高效的数据闭环？ 

飞凡现在做得非常多的是 主动挖掘，clips挖掘是决定迭代效率的关键环节。飞凡每周大概可以进行 250万个clips的处理。 

那么，怎么实现数据clips的多样性和有效性？ 

我们在车端设置了非常多的Triggered event（触发事件），触发这些条件后，可以进行多样性的数据回传。在三个月里，我们获得了 将近1200万个clips数据回传。 

对于异常数据，比如摄像头数据以及clips数据中的异常数据，我们开发了大量的识别和处理的神经网络小模型，并且会对神经网络小模型做一些标签和处理。 

数据处理方面，基本上全部做到了自动化的处理。比如，对语义数据的处理，包括前向、后向、左右和周视等的语义处理。 

我们可以对不同型号的激光雷达（R7上的Luminar和F7激光雷达版的速腾聚创）采集的数据进行 检测神经网络、分割神经网络的适配和自动化数据处理。 

在降低对高精度地图依赖方面，会生成非常多的离线道路基础要素真值，然后进行车端和云端的综合处理，以实现对“地图空洞”（Map Hole）的增强和地图鲜度的完善。 

进行自动化生成时，有些标签可能不准确，但也一定会有部分标签是准确的，我们会针对不同任务的数据进行重采样。将标签不完整的部分，和完整的数据标签进行联合训练，以提升网络的感知性能。 

BEV算法向芯片端移植时，有非常多的层级是芯片端无法很好支持的。 

举个例子，传感器数据送到芯片端时，有一个 Grid_Sampler（坐标处理）的层级，芯片中并没有原生算子的支持，需要我们进行定制化开发。 

另外，一些原生算子的性能不好，达不到最佳计算效率。 

在Transformer 架构里，飞凡开发了一个 替换梅林结构的算子，性能得到了数倍的提升。

向芯片端移植的时候，还会有非常多的量化，会有一定的精度损失。 

在整个训练过程中，我们通过一系列的算子开发和优化，实现了在耗时大幅度降低的情况下， 精度损失维持在1% 左右，一个很低的水平。随着算法、数据模型的不断迭代，以及云端大模型处理能力的提升，我们也在思考后续如何来实现更丰富的智驾功能。 

最后，分享一些飞凡最新的算法进展。 

无论是否搭载激光雷达，我们均实现了实时推理的Occupancy占用网络，它主要针对一些不容易直接表征的环境信息，进行灵活地探测。 

比如，针对遛狗时行人和动物的高度、位置、速度进行探测，针对Protruding类（也是欧洲高关注的场景）的交通参与者的运动位置、语义、运动趋势进行精准的刻画，以及对高速道路上的道路施工场景、异型车辆，以及倒地的自行车和锥桶进行精准车辆周围的数字刻画。 

我们还在做全局动静属性相互关联的算法开发，相信可以针对城区的博弈空间，提供更好的端到端数据闭环。 

整体上，BEV就是通过SoC芯片，以及摄像头、 4D毫米波雷达、激光雷达等传感器，构建整个周围环境的数字 Voxel World Model（体素世界模型），然后在World Model 里为规划和决策提供更灵活的描述。 

二、时序对算法资源占用高，BEV需要激光雷达

在线上圆桌互动环节，HiEV邀请到探维科技联合创始人、COO沈罗丰、驭视科技定位感知部门总监张丹与金杰盂和智驾产品市场专家周琳一起，围绕BEV方案进行了探讨。 

周琳：飞凡提供了不同的智驾方案配置，原因是什么，优劣性如何？ 

金杰盂：主要还是基于软硬一体化方案的思考。我们有不同的车型，比如R7是SUV ，车顶上的空间对于激光雷达的安装比较灵活。F7是轿车，空间相对受限。BEV方案的出发点，是Soc的芯片+视觉要素的处理。在整个方案的梯队化上，我们考虑得比较完备，希望这套方案可以更好地进行一些序列化、梯队化的拓展。 

沈罗丰：时序的使用，是否会对算法资源占用有更高的要求，如何平衡算力资源和识别效率之间的平衡？ 

金杰盂：选择时序，主要因为它对于感知、预测、规划，以及位置、测速、精度提升都有非常好的受益。 

为了平衡耗时和精度，我们会对历史帧的Feature做低分辨率的处理，在训练时做一些稀疏化的处理，来实现计算效率的综合平衡。 

沈罗丰：你们使用了不同厂家、不同类型的激光雷达，对于已经做好的模型来说，哪些工作是重复的？ 

金杰盂：我们对不同的激光雷达做了相应的处理，通过在Encoder时做一些特征的提取，消除一些Domain（域）的误差。再通过数据对齐的处理，使特征层的表征尽可能一致。然后做一些语义空间的对齐， 消除激光雷达在不同距离、不同角度分辨率下的点云密度差异。 

沈罗丰：随着BEV的应用，感知系统对于激光雷达的需求是加强还是减弱了？整个系统对激光雷达的需求，是不是会由于应用场景的不同而存在差异？ 

金杰盂：在不同的场景下确实会有不同的收益。 

视觉可以提供更稳健、更丰富的特征，但是在一些复杂的场景下，点云会发挥互补作用。举个例子，对于一些非规则的物体，通过点云的确可以实现探测的补充。 

总之，随着BEV的出现，感知性能在进步，这个趋势非常明确。 

另外，我也想向沈总请教一个问题。在使用激光雷达的过程中，我们希望挖掘除了点云位置等以外的其它特征。激光雷达在这方面有哪些趋势？ 

沈罗丰：激光雷达本身输出的是脉冲，是信号的强度。我们直接测到的就是脉冲的飞行时间和脉宽。 

对于不同反射率的目标物，强度的对比度是非常明显的，所以如果只是需要用对比度做一些车道线等的判断，强度信息是足够的。 

金杰盂：不同的激光雷达，在不同的位置，以及雨、雪、雾、逆光等情况下，会产生不同的激光。在应对这些场景适应性上，有哪些策略？ 

沈罗丰：激光雷达远近目标进行判断时，遵循近大远小的规律。 

如果要实现更远距离的探测，可以考虑通过动态的自适应方式。比如在某一些角度下，增加采样的速率来实现。 

当然，这会牺牲掉其它位置上的测距能力或分辨率。 

对于近处的目标物，分辨率如果过高的话，点云对于后端来说是过剩的。为了减小数据的带宽，以及减少数据的预处理压力，我们在雷达层面嵌入了预处理的算法，可以将近处的点云进行稀疏化处理，降频输出后再给到后端。 

对于雨、雪、雾等场景目标物，它们会被探测到，探测到之后，我们统计它们的距离、脉宽分布，进行特征的识别。在激光雷达内部，我们可以做算法的嵌入，提前识别这些目标物，之后把回波去掉，然后给到后端。 

金杰盂：一些激光雷达可以支持动态探测的点云配置，成本和性能上有哪些趋势？ 

沈罗丰：一般来说，激光雷达的采样点频、测距能力、测距精度三者是互相耦合、互相平衡的关系。 

成本主要体现在算法上。我们需要在雷达系统控制层面之外，开发一部分算法。硬件成本是不变的，需要做软件层面的自适应。 

三、Occupancy对网格要求高， 需要云端大模型处理数据 

张丹：Occupancy这项技术会把纯视觉感知的上限提升到什么程度，是否还有其它优化方向？ 

金杰盂：采用传统的语义分割时，语义上不够精细。我们做了一个云端大模型，参数大概是Billion这种级别，专门对语义做处理。 

Occupancy对像素的网格要求比较高，如果很粗糙，下游环节很难用。如果网格很精细，语义很混乱，下游也很难用。并且需要平衡自动化真值准确程度带来的过拟合和泛化鲁棒性的问题。 

所以，需要在云端做高准确程度大模型的处理，通过大模型做蒸馏和自动化标注，才能得到一个比较精准的结果，实现对几何分布或组合分布比较复杂的障碍物检测，具备更好的通用性、可扩展性。 

张丹：搭载4D毫米波雷达、激光雷达后，对视觉BEV 的感知效果有多大的加成作用？ 

金杰盂：在整个融合框架里，我们使用了全融合的方式，每一类的传感器会进行独立的BEV的感知。 

带激光雷达的车型，对小的障碍物或者不规则的障碍物上探测更加准确，它与视觉进行组合后，可以获取更加准确的特征，实现更好地探测。搭载4D毫米波雷达的车型，在对道路拓扑结构、雨天中的稳定性、静态非电波穿透类物体的探测上与视觉可以互相补充。 

周琳：基于BEV和4D毫米波雷达，是否可以实现城市NOA？ 

金杰盂：绝大多数的城市场景是可以支持的。像特斯拉的Hardware 4.0 ，有很多场景跑得很好，无非是算法鲁棒性和感知准确性。 

周琳：不带激光雷达能够做到什么程度？ 

金杰盂：有一些场景，我认为有激光雷达会更好。比如，对于送外卖的电动车，通过激光雷达可以更好地探测。 

张丹：4D毫米波雷达等的硬件成熟需要经历一段时间，实际量产过程中，你们碰到了哪些具有挑战的问题？哪些可以通过数据驱动优化，哪些需要硬件供应商来解决？ 

金杰盂：有两类问题相对有挑战性，花了比较多的时间最终才解决掉了。 

第一类，性能问题。传感器的固件存在性能差异，需要团队对传感器深入理解，以及与传感器供应商支持团队的高效沟通，进行及时地响应和处理。 

第二类，生产问题。传感器要导入到工厂，与车辆一起按照像流水线批量下线，整个过程中会存在诊断等问题。 

张丹：飞凡的包括车端算法、数据闭环在内的平台，是全自研，还是有一部分会采用第三方的工具？ 

金杰盂：全自研。逻辑很简单，大家都在谈数据闭环，其实所有的数据处理处理和算法密不可分。 

算法处理数据，可能只能把它挖掘成比较有效的clips，然后对这些clips 进行一些标签化，促进算法的迭代。但是，如果数据和算法无法适配，很多时候组合效率会很低。 

我也想请教张总一个问题。驭势科技在园区等场景做了许多工作，对于轻地图，想听听你们的一些思考和一些方法。 

张丹：在一些封闭场景，轻地图肯定可以做。对于轻地图，我们内部会再做一些探讨和基于BEV的预研。现在谈到的轻地图，我认为更多的还是在开放场景下应用，因为地图的鲜度、成本等方面存在很多问题。 

四、4D毫米波有惊喜，从来没把激光雷达当做冗余件

直播期间，金杰盂还解答了一些线上观众的问题。 

Q：BEV上车之后，会带来哪些功能和体验上的提升？ 

A：第一点，无论是LCC还是领航的功能，连续性会更好。加入时序处理后，对很多场景比如cut in的处理，性能会有大幅度的提升。 

第二点，我们在设计产品时，一直认为交互特别重要。无论是否开启智驾系统，所有的感知要素都会实时地显示，让用户实时地感受到车辆的系统探测能力，了解系统的边界，更好地去使用系统。 

Q：BEV对数据的需求量是巨大的，怎么估算成本，需要多大的数据量？ 

A：有了量产车以后，数据获取会相对容易很多，更大的成本来自于数据挖掘和清洗。 

具体的数据量，不太容易准确地定义。核心是基于SoC芯片，软件、模型算法是否进行了有效利用。 

Q：激光雷达本身提供了3D点云信息，对于飞凡带有激光雷达的高配车型，是否还需要Occupancy ？ 

A：需要。在一些小的障碍物上，带有激光雷达的Occupancy方案能够在探测范围、距离、精准性上表现更好一些。 

当然，我们的4D毫米波雷达也能够提供比较连贯、流畅的体验，特别是对于一些结构化道路而言。 

尤其是，今年我们更新了一个4D毫米波雷达的固件后，发现它对一些低矮障碍物，比如15厘米左右的障碍物的探测能力非常好，稳定性也很好。对一些道路结构上的处理、环境适应性，也有它独特的地方。 

Q：主机厂是否会在算法比较成熟后，考虑去掉激光雷达的这个硬件冗余？ 

A：我认为，激光雷达本身就不是一个redundancy（冗余），我们在最初考虑激光雷达的用途时，就没有把它当做冗余来用。 

如果车企刚刚开始做，又想很快地搞定一些场景，有激光雷达的话难度会低一些，当然需要付出更多的成本。如果车企已经有了很强的积累，不带激光雷达也会做得很好。 

要不断地压榨传感器的性能，比如R7不带激光雷达的车，在很多的场景下确实也可以运行得很好。视觉算法发展一定程度之后，确实在面对很多场景时问题不大。 

Q：要带动激光雷达，芯片算力是否有最低的要求？ 

A：会有一些要求，但不是绝对的。 

在激光雷达点云数据上实现很多的网络处理，特别是做一些语义分割等，还是比较耗费计算资源的。我们认为，还是要看对芯片是否足够了解。最终取决于是否可以对芯片里面的绝大多数的计算资源，能清晰懂得如何利用。 

目前来看，飞凡已经围绕BEV建立了一套成体系的数据标注和处理体系，并且在算子优化、云端大模型建立、Occupancy开发等方面分别取得了进展。 

通常，传统车企给大家的印象是，智能驾驶研发进展缓慢，自研比例不高。但是，飞凡通过BEV方案展现了新的一面，至于真实的道路表现，应该会在下半年逐渐看到。