当谈论端到端自动驾驶的时候,我们到底在谈论些什么

端到端自动驾驶目前尚不成熟,但作为今年的各家厂商必争的领域,写一些自己的理解

请注意,本文编写于 270 天前,最后修改于 222 天前,其中某些信息可能已经过时。

前言:端到端自动驾驶目前尚不成熟,作为做感知算法的同学,我的视角和理解也不一定很全面。我这里放一些个人理解的端到端自动驾驶的文字,希望和大家多多讨论。后续这篇文章会持续更新我对端到端的理解

原文首发于知乎:当谈论端到端自动驾驶的时候,我们到底在谈论些什么

端到端自动驾驶的现状

1. 端到端自动驾驶是什么

  • 端到端感知:输入是图像和传感器的数据,直接输出速度、tracking 结果,避免 Rule-based 的测速测距
  • 感知到 Planning 的端到端:输入是图像和传感器的数据,直接输出方向盘、油门刹车的控制信号

而端到端算法又分为显式端到端和隐式端到端,显式端到端指的是类似 UniAD 那种有中间的感知结果输出的,可以用于 HMI 以及排查 corner case,隐式端到端指的是不输出中间结果,直接出控制信号,会更加的黑盒。以下讨论的感知到 Planning 的端到端,包括显式端到端和隐式端到端

2. 关于 UniAD

UniAD 的算法 Pipeline
UniAD 的算法 Pipeline

而在 2023 年,UniAD 获得了 CVPR 2023 Best Paper,虽说不算是众望所归,但也给自动驾驶行业的人注入了一剂强心剂,但国内对 UniAD 的褒贬不一。这种褒贬不一不仅仅体现在感知预测规控各个人群独立的视角上。还体现在自动驾驶领域学术界和工业界的 gap,工业界的迭代远大于学术界,corner case 也远多于学术界。论文里面的各个模块其实是自驾团队都会去做的事情,所以将这些串起来做端到端的创新性看起来确实没有那么革命性,故事确实讲的蛮好。并且自驾团队都很看重落地性,因为预研的技术是要落到实车上才能最终体现价值。但论文里面没有提供实车数据(不包含 nuScenes)的数据和 demo,所以令人遗憾吧。还有 Planning 出身的同学经常诟病的一点是:端到端模型可解释性差,而 UniAD 又只放了开环评测的结果,所以实际效果难以令人信服

3. 关于 Tesla 的端到端

Tesla 端到端
Tesla 端到端

国内自动驾驶总体还是 follower,从业者都非常关注每年的 Tesla AI Day 或者 Tesla 相关的技术报告。在感知范式、预测、规划、基建上都会有新启发。个人是做感知方向的,所以见识了 BEV、Occupancy 的技术路线一经发布,在学术界卷起的新浪潮。所以在自动驾驶领域,我个人感受到的还是工业界在推着学术界往前进,而目前来看 Tesla 在这方面应该是毫无疑问的 leader。而在 2023 年,Tesla 的新话题包含 World model 和 E2E,注定会成为未来几年的热门话题。就算是敢于放出实车 Demo 的 Tesla,视频里的 MTBF(Mean-Time-Between-Failures) 也不过一小时左右,而 MPI(Mileage Per Intervention)也不会特别高。但一众媒体宣扬的 2024 年是大家比拼端到端的一年,我感觉今年的智驾节奏顶多是放端到端的 demo 出来,端到端模型的真正量产实车还很远。

端到端自动驾驶的优势和问题

优势1:减少 rule-based 的过多后处理,系统简洁,减少人为偏见

传统的自动驾驶系统通常是分为例如感知、预测、规控等子系统,每块之间常常会有部分 Rule-based 的后处理流程,端到端自动驾驶可以做到全流程可微,系统变得相当简洁。减少了很多后处理模块例如传感器后融合的的维护成本,并且还能避免编写大量规则引入的人为偏见,

优势2:数据驱动(Software2.0)的范式去迭代模型

Software 2.0
Software 2.0

"Software 2.0" 这个术语是由 Andrej Karpathy 提出的,简单来讲,就是以数据驱动的方式来解决问题,迭代模型。例如遇到了 Badcase,之前的模型需要先定位是规控还是感知的问题,并且有些问题只能基于规则去解。而端到端的优势是全流程可微,理想情况下,我们就可以去采集类似的数据加入训练集来解决泛化问题。

端到端自动驾驶的挑战

挑战1:可解释性差

深度学习黑盒模型的可解释性差
深度学习黑盒模型的可解释性差

以端到端模型目前的实现方式,就是一个大黑盒,可解释性实在太差。而可解释性差导致的就是端到端模型的下限不可控,我们无法预知大风吹来的塑料袋以及纸箱子会诱导模型做出怎样的决策。无法知道模型能力边界的情况下,或许还是需要手工规则去保证整个系统的下限。

可能的解决路径:

  • 利用大语言模型来获得模型的决策动机,之前 naiyan 所写文章 中测试的 GPT-4V 其实是有这种能力的,对于提升可解释性或许有些帮助,但是否实用依然要进行仔细评估

挑战2:评测手段不成熟,闭环训练不充分

端到端自动驾驶的评测分为云端评测和路测,路测需要大量时间去验证,云端评测可以复用之前积累下来的感知及规控的 Badcase,会更加全面和实用。但云端评测如何做到闭环是一个难题,下面介绍一下开环评测和闭环评测:

  • 开环评测: 系统被置于一个不受外部反馈控制的环境中,系统的输入被改变以模拟不同的情况,但系统本身的输出不会影响评测环境。例如模型输出的 planning 指令做出了加减速动作,由于路测的感知视频是录制的,这个动作无法反映到图像上去,这导致开环评测只能在每一帧都会重置到数据集中录制那一刻的评测环境,并且是安全的轨迹,不存在误差累积。学术界最常见的就是在 nuscenes 数据集上进行开环评测。
  • 闭环评测:模型的输出会影响评测环境,同时评测环境的反馈会影响系统的输入,形成一个反馈循环。闭环评测模拟了真实世界中系统与环境的相互作用,例如自车发生变道行为,反应到图像上就是视角切换,前车切换等等,最常用的就是 Carla 模拟器。

开环评测的问题最近被讨论很多了,感兴趣的可以去看 文章 1文章 2,简单来讲就是不靠谱,存在数据泄露,数据分布不足,错误恢复能力差,碰撞率指标本身有问题等等

Carla 模拟器
Carla 模拟器

而闭环测试的问题是什么呢,借用 文章 3 中的言论,WorldSim(用虚拟数据做仿真)像在玩游戏,而 LogSim(用真实道路数据做仿真)则更像是电影,无法解决交互的问题。基于虚拟仿真场景的闭环评测(如 Carla),对规控会更加合适,因为仿真数据的感知图像和真实道路上存在 domain gap,这会导致无法真正获得带感知的端到端模型性能。

所以最大的难点是如何解决真实数据的云端闭环评测。具体来讲,对于每次模型做出指令后,评测环境要能够执行相应的指令,并且给出当前的各种参数,包括新视角下的感知图像,自车状态等,涉及到两方面的技术,仿真及交互。

仿真的一种技术路径是三维重建 + 场景编辑,能够获得简单的场景视角转换能力。但是依然是有限的,只有 planning 结果不超过所录制场景太多才有一定可用性。例如超车场景,这个指令完成后,多视角的图像里需要渲染出之前前车的侧面及车头,假设录制时自车就是一直跟车,是压根没见过前车的侧面及车头的,应该如何提升渲染的真实性呢。可能需要用到图形学中的渲染才能让目标更加真实,但场景偏离太多时,静态环境也会发生崩坏,是比较难解决的。另外,多视角图像渲染下,多视角及时序的一致性在复杂场景下难以保证,这也是 world model 做的不太好的地方

交互的问题是如何构建合理的他车运动模型,博弈论里面假设大家都是理性人,但真实场景中的交通参与者或保守或激进,个性十足。如果他车运动模型过于单一,最终的评测性能不太可靠。

可能的解决路径:

  • 对于仿真来讲:尝试图形学仿真和深度学习的仿真相结合,加入物理先验;利用 Sora 等生成模型,做可控的视频片段生成;
  • 对于交互来讲:或许利用训好的 planner 作为他车的控车程序是可行的路径,多智能体情况下场景就会变得更复杂了。并且要注意 planner 是否有偏,他车的策略是偏保守还是偏激进,这都会对最终的评测性能有影响。

另外还想谈谈闭环训练,上述闭环评测中的问题闭环训练都有。而模型若仅在开环条件下训练,无法适应环境中的变化和未知情况,泛化性会强受限于数据场景,模型的鲁棒性会是个问题。

其实关于闭环评测和闭环训练,可以关注 Openpilot 这个开源项目(https://github.com/commaai/openpilot),给出了参考路径以及真实的路测视频,并且用一部旧手机就可以在简单的真实场景下跑 work,还是令人惊喜的。但是对于复杂的道路场景下的量产,闭环训练和评测是我们需要重点关注的问题

挑战3:Learning-based 方法对数据多样性的要求很高,并且如何引入先验

端到端模型的优势是全流程可微,基于学习的系统该有的问题他都有,简单列举两个。第一是数据多样性要求高,例如假设数采数据中自车是理性人场景,没有包含车辆发生碰撞等紧急场景,那模型对于这类场景学习不足,就学不到应对事故的修正能力。第二个是应该如何引入人为先验,例如不应该闯红灯,虚实车道线等交规信息就是规控的强先验,这类先验应当以何种形式加入到模型中去,以实现加速收敛和约束输出的目的。

针对这些 Learning-based 方法的固有问题,解决路径就需要非常深的业务理解了,数据仿真合成可以有效解决场景丰富度缺失的问题,如何引入先验就因人因场景而异了。

问题4:端到端解 corner case 的路径是否清晰

虽然我们希望端到端解 corner case 可以通过加数据来解决,这种方式有效但不可控程度较高。在模型容量有限的情况下,是否存在遗忘现象,之前能解掉的 case 有可能会发生回退,并且可能还找不清楚回退的原因,而 rule-based 的方法能够保证 case 绝大多数场景下是不会发生回退的。所以端到端模型想要摒弃掉中间环节,那么解决 corner case 的技术路径,当前并不太明晰,或许还是需要 rule-based 来兜底。

端到端未来到底应该怎么去做?

这边不讨论具体的模型设计,只谈端到端在落地侧怎么去发挥作用。正向来看,作为一种新的范式,好像没有什么是非得用端到端去解决的,而端到端本身也解决不了什么新出现的问题。但是从大局的角度去考虑,做出端到端 demo 背后所证明的事情却很多,例如数据和基建已经为类似的 learning-based 方案准备好了,闭环训练测试和解 Badcase 的技术路径都尝试过了,这种经验以及在落地过程中所搭建好的平台是更为宝贵的东西。所以端到端模型可能最大的作用是促进各个厂商内部基建完善的一个契机,促进对数据驱动的理解,闭环评测,规控的 Badcase 如何流转到感知等等,这都是智驾深水区,每一块做好了都需要花功夫,这是我个人觉得大家去做端到端最有价值的地方。

非常感谢和一个学长讨论得到的观点:“L2 的产品里感知端到端效率上会更优,L4 产品需要安全冗余因此还需要考虑不同算法的失效模式,仅使用现有的端到端方法可能还不够”,推荐了 mobieye 的一篇文章,从产品定义角度进一步完善了我的视角。所以最终我感受到的是,端到端一种最可能的落地方向是作为冗余模型存在,产出的规控结果作为 proposal,与现有的感知-预测-规控的链路并行,或者为了节省算力和方便收敛从现有链路中提取 feature 或者中间结果用于端到端模型。最后需要一个决策模块从并行的两个链路中选择最终用哪个 planning 的结果。

另外还要提醒大家的是,还是不要对端到端的预期过高,从几个小黑盒变成一个大黑盒,没有规则的兜底,量产实车很难有特别亮眼的表现,甚至其下限都不可控。去年校招培训中我印象非常深的一个画面是,饭桌上,项目经理向我展示了各家企业路测中暴露出的 case 视频,有的对行人造成了甚至很严重的伤害。交通事故中没有受益者,这对我触动很大,在这之后有实车的机会我都会去争取,去实际地感受所开发的算法真实的性能,从产品的角度感受算法稳定性和可靠性的必要,这远比在工位上看路测视频要来的真实。

我相信,我们开发的算法不会主动作恶,但我们需要意识到,我们所开发的智能驾驶系统在和具体的交通参与者在交互,那是一个个具体的鲜活的人。我们还是应该要有技术情怀和责任心,避免为了技术噱头不顾实际的人文关怀,实实在在的提高交通参与者的安全。

参考资料

评论列表