自动驾驶合集10

#通过数据一步步构建高效的自动驾驶算法

下一代自动驾驶技术期望依赖于智能感知、预测、规划和低级别控制之间的专门集成和交互。自动驾驶算法性能的上限一直存在巨大的瓶颈，学术界和业界一致认为，克服瓶颈的关键在于以数据为中心的自动驾驶技术。AD仿真、闭环模型训练和AD大数据引擎近期已经获得了一些宝贵的经验。然而，对于如何构建高效的以数据为中心的AD技术来实现AD算法的自进化和更好的AD大数据积累，缺乏系统的知识和深刻的理解。为了填补这一研究空白，这里将密切关注最新的数据驱动自动驾驶技术，重点是自动驾驶数据集的全面分类，主要包括里程碑、关键特征、数据采集设置等。此外我们从产业前沿对现有的基准闭环AD大数据pipeline进行了系统的回顾，包括闭环框架的过程、关键技术和实证研究。最后讨论了未来的发展方向、潜在应用、局限性和关注点，以引起学术界和工业界的共同努力，推动自动驾驶的进一步发展。

总结来说，主要贡献如下：

• 介绍了第一个按里程碑代、模块化任务、传感器套件和关键功能分类的自动驾驶数据集综合分类法；

• 基于深度学习和生成人工智能模型，对最先进的闭环数据驱动自动驾驶pipeline和相关关键技术进行系统回顾；

• 给出了闭环大数据驱动pipeline在自动驾驶工业应用中如何工作的实证研究；

• 讨论了当前pipeline和解决方案的优缺点，以及以数据为中心的自动驾驶未来的研究方向。

SOTA自动驾驶数据集：分类和发展

自动驾驶数据集的演变反映了该领域的技术进步和日益增长的雄心。20世纪末的早期进展院的AVT研究和加州大学伯克利分校的PATH计划，为基本的传感器数据奠定了基础，但受到时代技术水平的限制。在过去的二十年里，在传感器技术、计算能力和复杂的机器学习算法的进步的推动下，出现了重大的飞跃。2014年，美国汽车工程师学会（SAE）向公众公布了一个系统化的六级（L0-L5）自动驾驶系统，该系统得到了自动驾驶研发进展的广泛认可。在深度学习的推动下，基于计算机视觉的方法已经主导了智能感知。深度强化学习及其变体为智能规划和决策提供了至关重要的改进。最近，大型语言模型（LLM）和视觉语言模型（VLM）展示了它们强大的场景理解、驾驶行为推理和预测以及智能决策能力，为自动驾驶的未来发展开辟了新的可能性。

自动驾驶数据集的里程碑式发展

图2按照时间顺序展示了开源自动驾驶数据集的里程碑式开发。显著的进步导致主流数据集被分为三代，其特点是数据集的复杂性、数量、场景多样性和标注粒度都有了显著的飞跃，将该领域推向了技术成熟的新前沿。具体而言，横轴表示开发时间轴。每行的侧头包括数据集名称、传感器模态、合适的任务、数据收集地点和相关挑战。为了进一步比较不同世代的数据集，我们使用不同颜色的条形图来可视化感知和预测/规划数据集规模。早期阶段，即2012年开始的第一代，由KITTI和Cityscapes牵头，为感知任务提供了高分辨率图像，是视觉算法基准进度的基础。推进到第二代，NuScenes、Waymo、Argoverse 1等数据集引入了一种多传感器方法，将车载摄像头、高精地图（HD Map）、激光雷达、雷达、GPS、IMU、轨迹、周围物体的数据集成在一起，这对于全面的驾驶环境建模和决策过程至关重要。最近，NuPlan、Argoverse 2和Lyft L5显著提高了影响标准，提供了前所未有的数据规模，并培育了一个有利于尖端研究的生态系统。这些数据集以其庞大的规模和多模态传感器集成为特点，在开发感知、预测和规划任务的算法方面发挥了重要作用，为先进的End2End或混合自动驾驶模型铺平了道路。2024年，我们迎来了第三代自动驾驶数据集。在VLM、LLM和其他第三代人工智能技术的支持下，第三代数据集强调了行业致力于应对自动驾驶日益复杂的挑战，如数据长尾分布问题、分布外检测、角点案例分析等。

数据集采集、设置和关键功能

表1总结了具有高度影响力的感知数据集的数据采集和标注设置，包括驾驶场景、传感器套件和标注，我们报告了数据集场景下天气/时间/驾驶条件类别的总数，其中天气通常包括晴天/多云/雾天/下雨/雪/其他（极端条件）；一天中的时间通常包括上午、下午和晚上；驾驶条件通常包括城市街道、主干道、小街、农村地区、高速公路、隧道、停车场等。场景越多样化，数据集就越强大。我们还报告了数据集收集的区域，表示为as（亚洲）、EU（欧洲）、NA（北美）、SA（南美）、AU（澳大利亚）、AF（非洲）。值得注意的是，Mapillary是通过AS/EU/NA/SA/AF/AF收集的，DAWN是从谷歌和必应图像搜索引擎收集的。对于传感器套件，我们研究了相机、激光雷达、GPS和IMU等。表1中的FV和SV分别是前视图相机和街景相机的缩写。360°全景摄像头设置，通常由多个前视图摄像头、罕见视图摄像头和侧视图摄像头组成。我们可以观察到，随着AD技术的发展，数据集中包含的传感器类型和数量正在增加，数据模式也越来越多样化。关于数据集标注，早期的数据集通常采用手动标注方法，而最近的NuPlan、Argoverse 2和DriveLM对AD大数据采用了自动标注技术。我们认为，从传统的手动标注到自动标注的转变是未来以数据为中心的自动驾驶的一大趋势。

对于预测和规划任务，我们在表2中总结了主流数据集的输入/输出分量、传感器套件、场景长度和预测长度。对于运动预测/预测任务，输入组件通常包括自车历史轨迹、周围代理历史轨迹、高精地图和交通状态信息（即交通信号状态、道路ID、停车标志等）。目标输出是自车和/或周围主体在短时间内的几个最可能的轨迹（例如前5或前10轨迹）。运动预测任务通常采用滑动时间窗口设置，将整个场景划分为几个较短的时间窗口。例如，NuScenes采用过去2秒的GT据和高精地图来预测下一个6秒的轨迹，而Argoverse 2采用历史5秒的地面真相和高精地图预测未来6秒的轨道。NuPlan、CARLA和ApoloScape是最受欢迎的规划任务数据集。输入组件包括自我/周围车辆历史轨迹、自我车辆运动状态和驾驶场景表示。虽然NuPlan和ApoloScape是在现实世界中获得的，但CARLA是一个模拟数据集。CARLA包含在不同城镇的模拟驾驶过程中拍摄的道路图像。每个道路图像都带有一个转向角，它表示保持车辆正常行驶所需的调整。规划的预测长度可以根据不同算法的要求而变化。

闭环数据驱动的自动驾驶系统

我们现在正从以前的软件和算法定义的自动驾驶时代转向新的鼓舞人心的大数据驱动和智能模型协同自动驾驶时代。闭环数据驱动系统旨在弥合AD算法训练与其现实世界应用/部署之间的差距。与传统的开环方法不同，在传统开环方法中，模型是在从人类客户驾驶或道路测试中收集的数据集上被动训练的，闭环系统与真实环境动态交互。这种方法解决了分布变化的挑战——从静态数据集学习的行为可能无法转化为真实世界驾驶场景的动态性质。闭环系统允许AV从互动中学习并适应新的情况，通过行动和反馈的迭代循环进行改进。

然而，由于几个关键问题，构建现实世界中以数据为中心的闭环AD系统仍然具有挑战性：第一个问题与AD数据收集有关。在现实世界的数据采集中，大多数数据样本是常见/正常驾驶场景，而弯道和异常驾驶场景的数据几乎无法采集。其次，需要进一步努力探索准确高效的AD数据自动标注方法。第三，为了缓解AD模型在城市环境中某些场景中表现不佳的问题，应该强调场景数据挖掘和场景理解。

SOTA闭环自动驾驶pipeline

自动驾驶行业正在积极构建集成的大数据平台，以应对大量AD数据积累带来的挑战。这可以被恰当地称为数据驱动自动驾驶时代的新基础设施。在我们对顶级AD公司/研究机构开发的数据驱动闭环系统的调查中，我们发现了几个共性：

• 这些pipeline通常遵循一个工作流循环，包括：（I）数据采集，（II）数据存储，（III）数据选择和预处理，（IV）数据标注，（V）AD模型训练，（VI）模拟/测试验证，以及（VII）真实世界部署。

• 系统内闭环的设计，现有的解决方案要么选择单独设置的“数据闭环”和“模型闭环”，要么分别设置不同阶段的周期：“研发阶段闭环”、“部署阶段闭环”。

• 之外，该行业还强调了真实世界AD数据集的长期分布问题以及处理角落案例时的挑战。特斯拉和英伟达是这一领域的行业先驱，其数据系统架构为该领域的发展提供了重要参考。

NVIDIA MagLev AV平台图3（左））遵循“收集→ 选择→ 标签→ 驯龙”作为程序，它是一个可复制的工作流程，可以实现SDC的主动学习，并在循环中进行智能标注。MagLev主要包括两条闭环pipeline。第一个循环是以自动驾驶数据为中心，从数据摄入和智能选择开始，通过标注和标注，然后是模型搜索和训练。然后对经过训练的模型进行评估、调试，并最终部署到现实世界中。第二个闭环是平台的基础设施支持系统，包括数据中心骨干和硬件基础设施。此循环包括安全的数据处理、可扩展的DNN和系统KPI、用于跟踪和调试的仪表板。它支持AV开发的全周期，确保在开发过程中不断改进和整合真实世界的数据和模拟反馈。

特斯拉自动驾驶数据平台（图3（右））是另一个具有代表性的AD平台，它强调使用大数据驱动的闭环pipeline来显著提高自动驾驶模型的性能。pipeline从源数据收集开始，通常来自特斯拉的车队学习、事件触发车端数据收集和阴影模式。收集到的数据将由数据平台算法或人类专家进行存储、管理和检查。无论何时发现角落案例/不准确性，数据引擎都将从现有数据库中检索并匹配与角落案例/不准确事件高度相似的数据样本。同时，将开发单元测试，以复制场景并严格测试系统的响应。之后，检索到的数据样本将由自动标注算法或人类专家进行标注。然后，标注良好的数据将反馈给AD数据库，数据库将被更新以生成用于AD感知/预测/规划/控制模型的新版本的训练数据集。经过模型训练、验证、仿真和真实世界测试，具有更高性能的新AD模型将发布并部署。

基于Generative AI的高保真AD数据生成与仿真

从真实世界采集的大多数AD数据样本都是常见/正常驾驶场景，其中我们在数据库中已经有大量类似的样本。然而，要从真实世界的采集中收集某种类型的AD数据样本，我们需要驾驶指数级的长时间，这在工业应用中是不可行的。因此，高保真自动驾驶数据生成和仿真方法引起了学术界的极大关注。CARLA是一款用于自动驾驶研究的开源模拟器，能够在用户指定的各种设置下生成自动驾驶数据。CARLA的优势在于其灵活性，允许用户创建不同的道路条件、交通场景和天气动态，这有助于全面的模型训练和测试。然而，作为模拟器，其主要缺点在于领域差距。CARLA生成的AD数据无法完全模拟真实世界的物理和视觉效果；真实驾驶环境的动态和复杂特征也没有被表现出来。

最近，世界模型以其更先进的内在概念和更有前景的性能，已被用于高保真度AD数据生成。世界模型可以被定义为一个人工智能系统，它构建其感知的环境的内部表示，并使用学习到的表示来模拟环境中的数据或事件。一般世界模型的目标是表示和模拟各种情况和互动，就像成熟的人类在现实世界中遇到的一样。在自动驾驶领域，GAIA-1和DriveDreamer是基于世界模型的数据生成的代表作。GAIA-1是一个生成型人工智能模型，通过将原始图像/视频以及文本和动作提示作为输入，实现图像/视频到图像/视频的生成。GAIA-1的输入模态被编码成统一的令牌序列。这些标注由世界模型内的自回归变换器处理，以预测后续的图像标注。然后，视频解码器将这些标注重建为具有增强的时间分辨率的连贯视频输出，从而实现动态和上下文丰富的视觉内容生成。DriveDreamer在其架构中创新地采用了扩散模型，专注于捕捉现实世界驾驶环境的复杂性。它的两阶段训练pipeline首先使模型能够学习结构化的交通约束，然后预测未来的状态，确保为自动驾驶应用程序量身定制的强大的环境理解。

自动驾驶数据集的自动标注方法

高质量的数据标注成功和可靠性是必不可少的。到目前为止，数据标注pipeline可以分为三种类型，从传统的手工标注到半自动标注，再到最先进的全自动标注方法，如图4所示AD数据标注通常被视为特定于任务/模型。工作流程从仔细准备标注任务和原始数据集的需求开始。然后，下一步是使用人工专家、自动标注算法或End2End大型模型生成初始标注结果。之后，标注质量将由人工专家或自动质量检查算法根据预定义的要求进行检查。如果本轮标注结果未能通过质量检查，它们将再次发送回标注循环并重复此标注作业，直到它们满足预定义的要求。最后，我们可以获得现成的标注AD数据集。

自动标注方法是闭环自动驾驶大数据平台缓解人工标注劳动密集、提高AD数据闭环循环效率、降低相关成本的关键。经典的自动标记任务包括场景分类和理解。最近，随着BEV方法的普及，AD数据标注的行业标准也在不断提高，自动标注任务也变得更加复杂。在当今工业前沿的场景中，3D动态目标自动标注和3D静态场景自动标注是两种常用的高级自动标注任务。

场景分类和理解是自动驾驶大数据平台的基础，系统将视频帧分类为预定义的场景，如驾驶场所（街道、高速公路、城市立交桥、主干道等）和场景天气（晴天、雨天、雪天、雾天、雷雨天等）。基于CNN的方法通常用于场景分类，包括预训练+微调CNN模型、多视图和多层CNN模型，以及用于改进场景表示的各种基于CNN的模型。场景理解超越了单纯的分类。它涉及解释场景中的动态元素，如周围的车辆代理、行人和红绿灯。除了基于图像的场景理解外，基于激光雷达的数据源，如SemanticKITTI，也因其提供的细粒度几何信息而被广泛采用。

三维动态物体自动标注和三维静态场景自动标注的出现是为了满足广泛采用的纯电动汽车感知技术的要求。Waymo提出了一种基于激光雷达点云序列数据的3D自动标记流水线，该流水线使用3D检测器逐帧定位目标。然后，通过多目标跟踪器链接跨帧的已识别目标的边界框。为每个目标提取目标轨迹数据（每个帧处的对应点云+3D边界框），并使用分治架构进行以目标为中心的自动标记，以生成最终细化的3D边界框作为标签。优步提出的Auto4D pipeline首次探索了时空尺度下的AD感知标记。在自动驾驶领域中，空间尺度内的3D目标边界框标记以及时间尺度内的1D对应时间戳标记被称为4D标记。Auto4D pipeline从连续的激光雷达点云开始，以建立初始物体轨迹。该轨迹由目标大小分支进行细化，该分支使用目标观测值对目标大小进行编码和解码。同时，运动路径分支对路径观测和运动进行编码，允许路径解码器以恒定的目标大小细化轨迹。

3D静态场景自动标记可被视为HDMap生成，其中车道、道路边界、人行横道、红绿灯和驾驶场景中的其他相关元素应进行标注。在这一主题下，有几项有吸引力的研究工作：基于视觉的方法，如MVMap，NeMO；基于激光雷达的方法，如VMA；预训练3D场景重建方法，如OccBEV，OccNet/ADPT，ALO。VMA是最近提出的一项用于3D静态场景自动标记的工作。VMA框架利用众包、多行程聚合的激光雷达点云来重建静态场景，并将其分割成单元进行处理。基于MapTR的单元标注器通过查询和解码将原始输入编码为特征图，生成语义类型的点序列。VMA的输出是矢量化地图，将通过闭环标注和人工验证对其进行细化，从而为自动驾驶提供满意的高精地图。

实证研究

我们提供了一个实证研究，以更好地说明本文中提到的先进的闭环AD数据平台。整个过程图如图5所示。在这种情况下，研究人员的目标是开发一个基于Generative AI和各种基于深度学习的算法的AD大数据闭环pipeline，从而在自动驾驶算法研发阶段和OTA升级阶段（在现实世界部署后）实现数据闭环。具体而言，生成人工智能模型用于（1）基于工程师提供的文本提示生成特定场景的高保真度AD数据。（2） AD大数据自动标注，有效准备地面实况标签。

图中显示了两个闭环。其中较大的一个阶段是自动驾驶算法研发阶段，该阶段从生成人工智能模型的合成自动驾驶数据和从真实世界驾驶中获取的数据样本的数据收集开始。这两种数据源被集成为一个自动驾驶数据集，在云端进行挖掘，以获得有价值的见解。之后，数据集进入了双重标记路径：基于深度学习的自动标记或手动手工标记，确保了标注的速度和精度。然后，标记的数据被用于在高容量自动驾驶超级计算平台上训练模型。这些模型经过模拟和真实世界的道路测试，以评估其功效，从而发布自动驾驶模型并进行后续部署。较小的一个是针对真实世界部署后的OTA升级阶段，该阶段涉及大规模云端模拟和真实世界测试，以收集AD算法的不准确/角落情况。所识别的不准确性/角点情况用于通知模型测试和更新的下一次迭代。例如，假设我们发现我们的AD算法在隧道驾驶场景中表现不佳。已识别的隧道驾驶弯道情况将立即向环路公布，并在下一次迭代中更新。生成型人工智能模型将以隧道驾驶场景相关描述作为文本提示，生成大规模的隧道驾驶数据样本。生成的数据和原始数据集将被输入模拟、测试和模型更新。这些过程的迭代性质对于优化模型以适应具有挑战性的环境和新数据，保持自动驾驶功能的高精度和可靠性至关重要。

讨论

第三代及以后的新型自动驾驶数据集。尽管LLM/VLM等基础模型在语言理解和计算机视觉方面取得了成功，但将其直接应用于自动驾驶仍然具有挑战性。原因有两个方面：一方面，这些LLM/VLM必须具有全面集成和理解多源AD大数据（如FOV图像/视频、激光雷达云点、高清地图、GPS/IMU数据等）的能力，这比理解我们在日常生活中看到的图像更难。另一方面，自动驾驶领域现有的数据规模和质量与其他领域（如金融和医疗）不可比，难以支持更大容量LLM/VLM的训练和优化。由于法规、隐私问题和成本的原因，目前自动驾驶大数据的规模和质量有限。我们相信，在各方的共同努力下，下一代AD大数据在规模和质量上都会有显著提升。

自动驾驶算法的硬件支持。当前的硬件平台已经取得了重大进展，特别是随着GPU和TPU等专门处理器的出现，这些处理器提供了对深度学习任务至关重要的大量并行计算能力。车载和云基础设施中的高性能计算资源对于实时处理车辆传感器生成的大量数据流至关重要。尽管取得了这些进步，但在处理自动驾驶算法日益复杂的问题时，在可扩展性、能效和处理速度方面仍然存在局限性。VLM/LLM引导的用户-车辆交互是一个非常有前景的应用案例。基于该应用程序可以收集用户特定的行为大数据。然而，VLM/LLM在车端的设备将要求高标准的硬件计算资源，并且交互式应用程序预计具有低延迟。因此，未来可能会有一些重量轻的大型自动驾驶车型，或者LLM/VLM的压缩技术将得到进一步研究。

基于用户行为数据的个性化自动驾驶推荐。智能汽车，已经从简单的交通工具发展到智能终端场景的最新应用扩展。因此，人们对配备先进自动驾驶功能的车辆的期望是，它们能够从历史驾驶数据记录中学习驾驶员的行为偏好，如驾驶风格和行驶路线偏好。这将使智能汽车在未来帮助驾驶员进行车辆控制、驾驶决策和路线规划时能够更好地与用户喜爱的车辆保持一致。我们将上述概念称为个性化自动驾驶推荐算法。推荐系统已广泛应用于电子商务、在线购物、送餐、社交媒体和直播平台。然而，在自动驾驶领域，个性化推荐仍处于起步阶段。我们相信，在不久的将来，将设计一个更合适的数据系统和数据采集机制，在用户允许并遵守相关规定的情况下，收集用户驾驶行为偏好的大数据，从而为用户实现定制的自动驾驶推荐系统。

数据安全和值得信赖的自动驾驶。海量的自动驾驶大数据对数据安全和用户隐私保护提出了重大挑战。随着互联自动驾驶汽车（CAV）和车联网（IoV）技术的发展，车辆的连接越来越紧密，从驾驶习惯到频繁路线的详细用户数据的收集引发了人们对个人信息潜在滥用的担忧。我们建议在收集的数据类型、保留策略和第三方共享方面具有透明度的必要性。它强调了用户同意和控制的重要性，包括尊重“不跟踪”请求和提供删除个人数据的选项。对于自动驾驶行业来说，在促进创新的同时保护这些数据需要严格遵守这些准则，确保用户信任并遵守不断发展的隐私立法。

除了数据安全和隐私，另一个问题是如何实现值得信赖的自动驾驶。随着AD技术的巨大发展，智能算法和生成人工智能模型（如LLM、VLM）将在执行越来越复杂的驾驶决策和任务时“充当驱动因素”。在这个领域下，一个自然的问题出现了：人类能信任自动驾驶模型吗？在我们看来，值得信赖的关键在于自动驾驶模型的可解释性。他们应该能够向人类驾驶员解释做出决定的原因，而不仅仅是执行驾驶动作。LLM/VLM有望通过实时提供高级推理和可理解的解释来增强可信赖的自动驾驶。

结论

这项调查首次系统回顾了自动驾驶中以数据为中心的进化，包括大数据系统、数据挖掘和闭环技术。在这项调查中，我们首先制定了按里程碑代分类的数据集分类法，回顾了AD数据集在整个历史时间线上的发展，介绍了数据集的获取、设置和关键功能。此外，我们从学术和工业两个角度阐述了闭环数据驱动的自动驾驶系统。详细讨论了以数据为中心的闭环系统中的工作流pipeline、流程和关键技术。通过实证研究，展示了以数据为中心的闭环AD平台在算法研发和OTA升级方面的利用率和优势。最后，对现有数据驱动自动驾驶技术的优缺点以及未来的研究方向进行了全面的讨论。重点是第三代之后的新数据集、硬件支持、个性化AD推荐、可解释的自动驾驶。我们还表达了对Generative AI模型、数据安全和自动驾驶未来发展中值得信赖的担忧。

参考

[1] Data-Centric Evolution in Autonomous Driving: A Comprehensive Survey of Big Data System, Data Mining, and Closed-Loop Technologies.

开源链接：https://github.com/LincanLi98/Awesome-Data-Centric-Autonomous-Driving                                     

#远距离LiDAR感知

本文所提到的内容都在图森ai day视频[0]和公开发表的论文中，不涉及具体的工程细节等技术秘密。

众所周知，图森是做卡车自动驾驶的，而卡车不论是刹车距离还是变道时间都远比轿车要长，所以如果说图森有什么与其他自动驾驶公司不同的独门技术，远距离感知必然是其中之一。我在图森负责LiDAR感知这一块，就专门聊一聊使用LiDAR进行远距离感知的相关内容。

刚加入公司时，主流的LiDAR感知一般是BEV方案。不过此BEV不是大家熟悉的那个BEV，特斯拉的那个BEV感知我个人认为应该叫作“多视角相机在BEV空间下的融合技术”，而这里的LiDAR BEV是指将LiDAR点云投影到BEV空间下，然后接2D卷积+2D检测头进行目标检测的方案。我能查到最早关于BEV方案的记录是在百度发表在CVPR17的论文MV3D[1]，后续的大部分工作，包括我所了解的大部分公司实际使用的方案，最后都要投影到BEV空间进行检测，大致也都可以归在BEV方案之中。

MV3D[1]使用的BEV视角特征

BEV方案的一大好处是可以直接套用成熟的2D检测器，但也有一个很致命的缺点：它限制住了感知范围。从上图可以看到，因为要套2D检测器，它必须形成一个2D的feature map，此时就必须给它设置一个距离阈值，而在上图范围之外其实也还是有LiDAR点的，只是被这个截断操作给丢弃了。那可不可以把这个距离阈值拉大，直到包住所有点呢？硬要这么做也不是不行，只是LiDAR在扫描模式、反射强度（随距离呈4次方衰减）、遮挡等问题作用下，远处的点云是非常少的，这么做很不划算。

BEV方案的这个问题在学术界并没有引起关注，这主要是数据集的问题，主流数据集的标注范围通常只有不到80m（nuScenes 50m、KITTI 70m，Waymo 80m），在这个距离下BEV feature map并不需要很大。但工业界使用的中距离LiDAR普遍已经可以做到200m的扫描范围，而近几年也有几款远距离LiDAR问世，它们可以做到500m的扫描范围。注意到feature map的面积和计算量是随距离呈二次方增长的，在BEV方案下，200m的计算量几乎都无法承受，更不用说500m了。

公开数据集中激光雷达的扫描范围。KITTI(红点, 70m) vs. Argoverse 2 (蓝点, 200m)

在认识到BEV方案的局限之后，我们进行了多年的研究，最终才找到了可行的替代方案。研究过程并非一帆风顺，经历了很多次挫折，论文和报告中一般都只会讲成功而不会说失败，但失败的经验也是弥足珍贵的，所以博客反而成了更好的媒介，下面就按时间线依次讲述一下。

二、Point-based方案

CVPR19上，港中文发表了一篇Point-based检测器PointRCNN[2]，它是直接在点云上进行计算的，点云扫到哪它算到哪，没有拍BEV的过程，所以这类point-based方案理论上是可以做到远距离感知的。

但我们试下来发现了一个问题，KITTI一帧的点云数量可以降采样到1.6万个点来检测而不怎么掉点，但我们的LiDAR组合一帧有10多万个点，如果降采样10倍显然检测精度会大幅度受影响。而如果不降采样的话，在PointRCNN的backbone中甚至有O(n^2)的操作，导致它虽然不拍bev，但计算量仍然无法承受。这些比较耗时的op主要是因为点云本身的无序性，导致不论是降采样还是检索邻域，都必须遍历所有的点。由于涉及到的op较多且都是没有经过优化的标准op，短期内感觉也没有能优化到实时的希望，所以这条路线就放弃了。

不过这段研究也并没有浪费，虽然backbone计算量过大，但它的二阶段因为只在前景上进行，所以计算量还是比较小的。把PointRCNN的二阶段直接套用在BEV方案的一阶段检测器之后，检测框的准确度会有一个比较大的提升。

三、Range-View方案

在Point-based方案尝试失败之后，我们将目光转向了Range View，当年的LiDAR都是机械旋转式的，比如64线激光雷达就会扫描出64行具有不同俯仰角的点云，比如每行都扫描到2048个点的话，就可以形成一张64*2048的range image。

RV、BEV、PV的对比

在Range View下，点云不再是稀疏的形式而是致密地排列在一起，远距离的目标在range image上只是比较小，但并不会被丢掉，所以理论上也是能检测到的。

可能是因为与图像更相似，对于RV的研究其实比BEV还早，我能找到的最早记录也是来自于百度的论文[4]，百度真的是自动驾驶的黄埔军校啊，不论是RV还是BEV的最早应用都来自于百度。

于是当时我就随手试了一把，结果跟BEV方法相比，RV的AP狂掉30-40个点...我发现其实在2d的range image上检测得还可以，但输出出来的3d框效果就非常差了。当时分析RV的特性，感觉它具备图像的所有劣势：物体尺度不统一、前背景特征混杂、远距离目标特征不明显，但又不具备图像语义特征丰富的优势，所以当时对这个方案比较悲观。

因为正式员工毕竟还是要做落地的工作，对于这种探索性问题还是交给实习生比较好。后来招了两名实习生一起来研究这个问题，在公开数据集上一试，果然也是掉了30个点...还好两位实习生比较给力，通过一系列的努力，还有参考其他论文修正了一些细节之后，将点数刷到了跟主流BEV方法差不多的水平，最终论文发表在了ICCV21上[5]。

虽然点数刷上来了，但问题并没有被彻底解决，当时lidar需要多帧融合来提高信噪比的做法已经成为共识，远距离目标因为点数少，更加需要叠帧来增加信息量。在BEV方案里，多帧融合非常简单，直接在输入点云上加上一个时间戳然后多帧叠加起来，整个网路都不用改动就可以涨点，但在RV下变换了很多花样都没有得到类似的效果。

并且在这个时候，LiDAR从硬件的技术方案上也从机械旋转式走向了固态/半固态的方式，大部分固态/半固态的LiDAR不再能够形成range image，强行构造range image会损失信息，所以这条路径最终也是被放弃了。

四、Sparse Voxel方案

之前说过Point-based方案的问题在于点云不规整的排列使得降采样和邻域检索等问题需要遍历所有点云导致计算量过高，而BEV方案下数据规整了但又有太多空白区域导致计算量过高。这两者结合一下，在有点的地方进行voxelization使其变得规整，而没点的地方不进行表达来防止无效计算似乎也是一条可行的路径，这也就是sparse voxel方案。

因为SECOND[6]的作者闫岩加入了图森，所以我们在早期就曾经尝试过sparse conv的backbone，但因为spconv并不是一个标准的op，自己实现出来的spconv仍然过慢，不足以实时进行检测，有时甚至慢于dense conv，所以就暂时搁置了。

后来第一款能扫描500m的LiDAR：Livox Tele15到货，远距离LiDAR感知算法迫在眉睫，尝试了一下BEV的方案实在是代价太高，就又把spconv的方案拿出来试了一下，因为Tele15的fov比较窄，而且在远处的点云也非常稀疏，所以spconv勉强是可以做到实时的。

但不拍bev的话，检测头这块就不能用2D检测中比较成熟的anchor或者center assign了，这主要是因为lidar扫描的是物体的表面，中心位置并不一定有点（如下图所示），没有点自然也无法assign上前景目标。其实我们在内部尝试了很多种assign方式，这里就不细讲公司实际使用的方式了，实习生在之后也尝试了一种assign方案发表在了NIPS2022上[7]，可以看看他写的解读：

明月不谙离苦：全稀疏的3D物体检测器

但如果要把这个算法应用在向前500m，向后和左右各150m的LiDAR组合下，还是力有不逮。恰好实习生之前追热度曾经也借鉴Swin Transformer的思想做过一篇Sparse Transformer的文章[8]，也是费了好大的功夫从掉20多个点一点点刷起来（感谢实习生带飞，tql），当时觉得Transformer的方法还是很适合不规整的点云数据的，所以在公司数据集上也试了一下。

可惜的是，这个方法在公司数据集上一直刷不过BEV类方法，差了接近5个点的样子，现在回想起来可能还是有一些trick或者训练技巧没有掌握，按理说Transformer的表达能力是不弱于conv的，但后来也并没有再继续尝试。不过这个时候已经对assign方式进行了优化降低了很多计算量，所以就想再尝试一把spconv，结果令人惊喜的是，直接把Transformer替换为spconv就可以做到近距离与BEV类方法的精度相当，同时还能检测远距离目标的效果了。 whaosoft aiot http://143ai.com

也是在这个时候，闫岩同学做出了第二版spconv[9]，速度有了大幅度提升，所以计算延迟不再是瓶颈，终于远距离的LiDAR感知扫清了所有障碍，能够在车上实时地跑起来了。

后来我们更新了LiDAR排列方式，将扫描范围提升到了向前500m，向后300m，向左向右各150m，这套算法也运行良好，相信随着未来算力的不断提升，计算延迟会越来越不成问题。

下面展示一下最终的远距离检测效果，大家也可以看看图森ai day的视频的01:08:30左右的位置看一下动态的检测效果：

虽然是最终的融合结果，但因为这天起雾图像能见度很低，所以结果基本上都来自于LiDAR感知。

五、后记

从point-based方法，到range image方法，再到基于sparse voxel的Transformer和sparse conv方法，对于远距离感知的探索不能说是一帆风顺，简直就是满路荆棘。最后其实也是随着算力的不断提升加上很多同事的不断努力才做到了今天这一步。在此感谢图森首席科学家王乃岩和图森的各位同事、实习生们，这里面大部分的idea和工程实现都不是我做出来的，很惭愧，更多地是起到了承上启下的作用。

很长时间不写这么长的文章了，写得跟个流水账似的而没有形成一个动听的故事。近年来，坚持做L4的同行越来越少，L2的同行们也逐渐转向纯视觉的研究，LiDAR感知肉眼可见地逐步被边缘化，虽然我仍然坚信多一种直接测距的传感器是更好的选择，但业内人士似乎越来越不这么认为。看着新鲜血液们的简历上越来越多的BEV、Occupancy，不知道LiDAR感知还能再坚持多久

#关于BEV(障碍物)落地

1: 21年的大争论

现在回看21年底组内决定做BEV障碍物的时候，应该来说是一个幸运，或者说有一点运气在里面。最开始面临的当时是大家每个人都熟悉的拍板的事情，到底是按照业界成熟的2D检测方案，或者说单目3D的的检测方案来做。还是说按照21 在自动驾驶届最火的那个Tesla Ai Day 的方案来做。争论，和彷徨应该持续了有一个月左右的时间。很幸运的是，最终我们老大直接拍板了，决定做BEV 障碍物。现在回看为什么说幸运：一个是在21年后学术届有很多优秀的BEV论文出来，一个是行车感知这块一直没有作为一个正式项目立项，给了我们足够的时间去试错，(最开始只有2-3个人来做这件事情)。如果缺少这一些因素，也许最后是做不出来的。这样可能往往一件成功的事情都伴随着一些幸运在里面吧。

2：BEV 如何做方案

在21年10份的时候，能够找到的BEV 障碍物检测的资料还是比较少的，看的最多的就是21 年Tesla AI day 上面的BEV pipeline。我记得很清楚组内对21年的Tesla AI day 的pipeline 方案(感知部分)进行了拆解分析，最后的难点卡在了2D image Feature 到 BEV Feature 的转换上面。其实那个时候还真不知道如何和Tranformer 结合来做这个。在这里不得不感慨CV 领域的开源文化，有一天看到了Patrick Langechuan Liu(https://www.linkedin.com/in/patrick-llgc/). (在这里很感谢刘兰个川博士持续关于自动驾驶经典论文的输出Paper notes(https://patrick-llgc.github.io/Learning-Deep-Learning/)，不过近期看到刘兰个川博士从自动驾驶行业跳去做机器人和大模型去了。)写的一篇文章,里面有一个图，感觉对2Dto BEV 的转换清楚了很多。如图1

图1 来自https://towardsdatascience.com/monocular-bev-perception-with-transformers-in-autonomous-driving-c41e4a893944

然后我们就开始按图索骥，开始设计我们的网络，后面Detr3D—DETR3D: 3D Object Detection from Multi-view Images via 3D-to-2D Queri(https://arxiv.org/abs/2110.06922) 开源，结合Detr3D 我们的BEV 障碍物网络在nuscenes 数据集上开始收敛还不错。在验证集上跑出一个视频效果，大家都比较兴奋。那个时候我们只有2张40G的A100， 现在回想哈哈，我们真是无知者无畏。

3: 痛苦开始的22年

到22年的时候，我们面临的两个问题一个是自己车型的BEV训练数据如何构建，一个是如何把BEV 网络部署到车上。先说数据，这面临两个问题，一个是采集，一个是标注，还有一个是标定。采集我们搞了一台真值采集车，但是因为没有搞硬同步，导致7v(前视2V，后视1V，周视4V) 摄像头 和lidar 时间同步有问题，然后我们就搞了一套所谓的软同步的方案，只能说凑合着够用。然后说到标注，其实在22年标注行业里面，或者说我们选到标注供应商他们是没有标注过BEV 障碍物的, 然后我们就从零开始写标注文档(这个过程是真痛苦)， 第一版的标注文档，加上供应商提供的标注工具，最后标注出来的数据，一个字是真贵呀, 每标一帧都在滴血。经过1-2个月双方痛苦的磨合和优化过程，最终价格在一个合理的范围内了，不过现在回看，我们在22年标注的数据量还是有点多了。标定，最开始标定我们是求助外力来搞的，但是效果是真不行。最终只能自己动手风衣足食，磕磕绊绊搞了一个lidar 和7v 的联合标注。经过这一系列的操作，在这里感谢商汤开源的标定工具，https://github.com/pjlab-adg/sensorscalibration。我们终于搞到了质量还算可以的数据(现在回看，我们应该提早为时序模型的数据进行布局)。然后就是部署了，我记得很清楚上海刚好有疫情，然后我们居家了3个月左右。我们差不多痛苦了1个多月，在部署的时候，有一些算子不支持(也主要是2D-to-3D 的算子)，后面是转出来模型性能差，然后优化。然后是Pytroch 的模型和转出来在工程上部署的模型掉点很严重，我们曾一度想搞一个Fcos3D(https://arxiv.org/abs/2104.10956） 的网络先搞到板子上。组内的同学很给力的，我们差不多就3-4个人力左右的情况下，最后我们的模型能跑到10hz, 然后在大家的努力下我们差不多在22年7，8月份的时候，我们的视觉 BEV 障碍物就能跑上车了。看到BEV 障碍物在车上实时跑起来的时候，还是感觉到很兴奋的。（跨相机的case 是真稳，整个后处理pipeline 是真的很简洁的)。 整个22年对我们来说收获还很大的，BEV 障碍物跑的不错。但22年我们也面临了来自项目的压力我们曾面临着人力资源紧缺，只有一个人力在投入在BEV 上面，还好大家坚持了下。

4：收获的23年

在前面差不多1年多的积累下，也随着组内的资源越来越多，23年我们做出来BEV 车道线，还有前融合的BEV多任务模型，端到端的红绿灯(一介书生：城市自动驾驶红绿灯方案何去何从？(https://zhuanlan.zhihu.com/p/656119050))目前都已经落地，在项目中开始测试，交付中。目前我们在探索时序的BEV，以及大模型相关的(一介书生：2024年自动驾驶标注行业是否会被世界模型所颠覆？(https://zhuanlan.zhihu.com/p/678882421)) 现在来看在21年投入去积累BEV技术，是一个很恰当的时机，当然抛开技术本身，我们老大也顶下来很大的压力和质疑，因为有人的地方就有江湖的。