端到端时代下的自动驾驶感知

智能车情报局 · 公众号 · · 2025-02-18 21:23

正文

👀

导读

作者：PeidongL，西安交通大学。

原文来自知乎，地址：

https://zhuanlan.zhihu.com/p/14173403896

本文只做学术/技术分享，如有侵权，联系删文。

不得不感叹的是，自动驾驶行业的技术的发展日新月异，技术热点已经从 BEV 迅速地转移到了端到端上。不管如何看待端到端，最近一年端到端的火热已经切实影响到了这个行业的每一个人。相比于在紧锣密鼓恶补各种模型知识的传统规划的工程师而言，大家似乎往往默认感知算法工程师在端到端时代是有优势的。然而实际上，和很多朋友交流下来，我发现很多人还是做着和以前类似的工作，专注于某个感知task来提升端到端性能，忽略了端到端时代下真正的感知红利。最近看到 @Patrick Liu 大佬(https://www.zhihu.com/people/patrick-llgc)分享了感知工程师如何恶补规划知识的文章，很受启发，因此想在这里结合我们ICLR 2025的工作SSR，分享一些从感知角度出发的思考。

arxiv: [2409.18341] Does End-to-End Autonomous Driving Really Need Perception Tasks?（ https://arxiv.org/abs/2409.18341 ）

github: https://github.com/PeidongLi/SSR

端到端的复兴

端到端并不是一项新的技术，甚至在自动驾驶技术方兴未艾时，很多人都寄希望于能用神经网络输入前视相机图像直接输出轨迹或是控制量。然而，当时的方案不管是用CNN或是强化学习，都很难达到稳定安全的实车效果。最终通过不断的实车测试迭代，主流的方案才逐渐收敛到定位-感知-规划-控制这套系统架构下。这套系统架构很好地分解了自动驾驶任务——感知模块将障碍物，车道线，红绿灯等等元素通过固定的接口传输到规划模块，再由规划模块根据上游信息输出轨迹给控制模块。

而随着BEV感知的快速发展和 Transformer架构的不断成熟，端到端终于又带着全新的架构卷土重来，尤其以 UniAD 为代表，把这项经典技术又重新带回了大众视野内。各家纷纷掏出自己的一段式、两段式方案，只要是能把规划模块NN化，就可以说自己已经端了（端到端风评被害:D）。

端到端的感知红利

在传统的感知-规划框架里，感知的目的是全量化尽可能多的获取精确的场景感知信息，让规划模块能有完备的输入以得出好的规划结果。这是由于传统框架模块化的设计使得感知无法获得规划的需求，所以只能尽可能多的提取有效信息给下游模块使用。目前主流的端到端方案也大都延续了这一思路，无非是把BBox，Map这些信息换成query来表征，把原来的各种感知任务当成auxiliary loss加进来做监督。当然还有那种把感知网络decode出来的感知信息，再重新encode又输入到规划网络的两段式方案。但一个一直被忽略的问题是，端到端时代下依然还需要这么多人为定义的感知任务吗?或者说，真的还需要全量的感知信息吗?

对于感知而言，端到端最大的意义在于"Planning-Oriented"，也就是从全知全量的感知到可以学习的的按需感知。 我们以传统的检测任务打个比方，感知任务就相当于特征提取，轨迹生成则相当于特征处理。目前定义的各类感知任务就类似于SIFT这种手工特征，是人为定义的而非学习的。而端到端架构打通了从轨迹生成任务到感知模块之间的反向传播通路，为一种可学习而非人为设计的感知模块提供了可能。这正是端到端时代下感知最大的红利，也是目前主流端到端方法因循守旧所忽略掉的。扪心自问，这些人为定义的感知任务不恰恰就是感知模块自己的手工特征算子吗？

在端到端时代，不仅规划模块要革自己的命，感知模块也要有勇气革自己的命。也许端到端模型对于场景的理解方式和我们人类并不相同，基于人类先验知识定义的感知任务反而约束了端到端模型的上限。很多最新的用大模型来做自动驾驶场景理解的工作，同样也能不依赖于这些感知任务来实现很好的场景理解。更何况，感知任务同样层出不穷，从2D检测3D检测再到Occ，我们也无法定义和穷举所有的有效任务。相反地，如果我们通过learning的方式在端到端模型中去除了这些人为定义的感知任务，得到的好处也是显而易见的。一方面，这将极大减少模型对于标注资源和训练资源的需求，提高端到端模型的Scalability；另一方面，按需感知的高效推理速度能使得端到端模型更快地走向大规模量产部署，真正让端到端模型在数据闭环下乘上Scaling Law的东风。

Navigation-Guided Perception

在主流的端到端方案中，感知任务的结果不仅仅显式地作为上下游的中继，更为整体的模型性能起着重要作用。若要不依赖于这些感知任务，仍然能隐式地实现对于场景的有效理解，便成了一个非常有挑战的任务。在和 @翠翠Darr en(https://www.zhihu.com/people/cuidixiao) 的一次讨论中，我们聊到为什么感知一定要做全量感知而非根据下游的需求来做局部感知。沿着这一思路，受人类驾驶员的注意力机制启发，我们提出了一种Navigation-Guided Perception的方案，也就是根据导航信息来引导感知注意力——人类驾驶员在开车的时候也不会做全量的感知，而是根据不同的驾驶意图去关注场景中的不同部分。但是如果模型直接用behavior来引导感知，就会陷入先有鸡还是先有蛋的怪圈。而导航信息无论是以引导线或者command来表示，都可以看成是一种简化的behavior。在传统方案中，导航信息往往只被用作在规划模块中辅助最终轨迹的生成，但我们认为它同样可以引导感知信息的提取，类似于人类驾驶员会根据导航指引关注场景中的不同信息。

为了实现这一构想，我们设计了一个基于BEV特征的 Scene TokenLearner (STL)模块，来实现对于场景特征的高效提取。我一直是一个BEV特征的支持者，这一点从我们之前的工作（DualBEV）可以看出，这是由于BEV特征集成了语义信息和几何信息以包含完备的场景信息。虽然task-specific query直接和图像交互可以在各个感知task上实现很好的效果，但是BEV特征仍然是我认为的感知乃至端到端的基石模块。既然BEV特征包含着所有的场景信息，那么理论上我们就可以直接根据BEV特征来输出规划轨迹。然而，这种类似于BEV-Planner的做法无论在效率还是性能上都不能够满足我们的要求。因此我们继续沿用了我们在做DualBEV时候的思路，希望在BEV层面引入注意力机制，但与直接预测占据概率不同的是，我们的STL模块首先使用一个SE模块将导航信息引入到BEV特征中，再通过TokenLearner预测BEV注意力来将场景表征压缩为16个scene query。而Planning Decoder只需要和这16个scene query做交互就可得到最后的规划轨迹。也就是说，我们发现 在Navigation-Guided Perception模式下，仅仅只使用16个query就可以有效表征当前规划任务所需要的感知信息 ，这在原来的全量感知方案下是难以想象的——哪怕是号称Sparse的各种端到端方案，实际上也需要上百个query来表征感知到的场景信息。通过这种对感知模块的极致压缩和高效利用，我们的端到端方案SSR不仅在训练效率和推理速度上都成倍地提高了，在性能上同样也大幅超越了各种SOTA的方案。

世界模型——隐式特征监督的新方向

为了使模型进一步摆脱对于人为定义的感知任务的依赖，我们诉诸自监督的方式，通过时序上的信息来增强对场景的理解能力。具体来说，我们引入了一个基于BEV特征的世界模型，在训练过程中通过预测未来帧的BEV特征和实际的未来帧特征做自监督，来增强scene query对于场景的理解能力。这种方法在之前BEV检测的HoP，端到端任务的LAW中都是有出现的。但由于我们Navigation-Guided Perception的方案在每一帧上关注的区域是在不断变化的，就无法按照这些策略mask掉某一帧然后进行一一对应的scene query监督。在经历了很多种失败的尝试后，我们最终提出了一种在sparse query上做轨迹规划，而在dense BEV上做世界模型的方案。由于世界模型只在训练时作为一种增强方式来提升性能，这种设计既能保证轨迹规划任务在推理时的高效，同样也能使得世界模型在自监督时具备一致性来实现模型的收敛。我们目前的设计还仍然比较简单，并不像广泛定义下的世界模型那样直接囊括掉原始数据如图片、点云等的生成。但随着世界模型的研究越来越成熟，我们认为它终将会完全替代掉目前人定任务在感知模块的作用，成为隐式场景表征最可靠的监督方式。

端到端感知的AlexNet时刻

端到端时代下的自动驾驶感知

正文

请到「今天看啥」查看全文