自动驾驶合集3_machine learning for autonomous vehicle's trajecto

#这是自动驾驶の从入门到放弃

UniAD[1]获得CVPR Best Paper Award后毫无疑问给自动驾驶领域带来了又一个热点： 端到端自动驾驶。同时马老师也在极力的宣传自己的端到端FSD。不过本篇文章只把讨论限定在一个很小的学术方向，基于nuScenes的开环端到端自动驾驶，会给出一些细节的东西，不讨论其它假大空的东西。（叠个甲，本文章仅是学术讨论，不包含任何对于文章中引用的paper，相关作者的任何负面态度）

因为不能闭环所以被迫选择了开环

以能否得到反馈为标准，端到端自动驾驶的学术研究主要分为两类，一类是在模拟器比如CARLA中进行，规划的下一步指令可以被真实的执行。第二类主要是在已经采集的现实数据上进行端到端研究，主要是模仿学习，参考UniAD。开环的缺点就是无法闭环（好像是废话），不能真正看到自己的预测指令执行后的效果。由于不能得到反馈，开环自动驾驶的测评极其受限制，现在文献中常用的两种指标分别是

• L2 距离：通过计算预测轨迹和真实轨迹之间的L2距离来判断预测轨迹的质量

• Collision Rate: 通过计算预测轨迹和其他物体发生碰撞的概率，来评价预测轨迹的安全性

事实上我们发现这两个指标完全不足以评判预测的轨迹的质量，一些技术看似提高了模型在这些指标上的表现，实则带来了其他没有被发现的问题，后续会介绍到。

nuScenes不是为planning设计的

关于开环端到端自动驾驶的测评问题最早在这篇文章[2] 中提到。在这篇文章中他们仅使用Ego Status就能够获得和现有Sota相比较的结果。但是第一次文章放出来的时候他们的数据好像用错了[3] 。同时他们错误的认为VAD也用了history trajectory, 但其实VAD[4]并没有使用历史轨迹。在AD-MLP中历史轨迹是一个默认使用的选项，当时本人理所应当的认为AD-MLP可能是受益于历史轨迹的使用，并没有特别在意这篇文章的结论。

表1: AD-MLP的实验结果

不过后来实验受挫之后，心态发生了：”从相信端到端到怀疑端到端“的转变后，开始觉得AD-MLP的结论应该是对的。通过可视化很多nuScenes的整体场景，会发现相当比例的场景都是直行，而且速度变化不大，交互很少，如图1所示。考虑到我们对于AD-MLP使用历史轨迹的顾虑，我们复现了一版仅使用当前速度，加速度，转向角和转向指令的MLP网络。如图2所示，为了区分，将我们复现的这个网络记为Ego-MLP。Ego-MLP不使用任何传感器感知信息，监督loss仅为一个L2 Loss。同时我们还有一个更基础的驾驶策略Go Stright: 保持当前速度继续前进。

图1: nuScenes的场景相对简单，直行占比过大

表2 实验结果由我们使用统一的Eval代码和策略获得，与之前文献中会有不一样的地方. ID-1,3,4为我们根据开源代码简单修改复现的结果, UniAD和VAD使用BEVFormer生成BEV特征，BEVFormer默认在BEV初始阶段引入can_bus (可以理解为ego status)信息

如表2所示，我们会有如下发现

• 简单的直行策略（ID-7）在2s内的指标都挺高的。

• Ego-MLP 不使用感知也能取得和现有sota差不多的结果。

第二条其实还可以换个角度这样理解，现有方法比如VAD, UniAD只有在Planner上引入Ego Status才能取得和Ego-MLP相似的效果。所以自然而然有了下面的问题：

Ego Status 引入会降低对感知的依赖

为了探究Perception 和Ego Status的效果，我们向这两个输入分别加扰动。如表3所示，在Planner中已经使用了Ego Status的情况下，就算把所有相机输入全部去掉，感知模块全部崩溃（结果变成0），模型的planning效果依然会在一个非常好的水平。我们相信这并不是一个正常的现象。与之对比的是模型会过渡依赖Ego Status的信息，假如我们改变输入模型的速度，会发现模型预测的轨迹基本会按照我们输入的假的速度去走，哪怕输入图像中事实上隐式地包含了ego的真实速度。如果输入速度全部设置成0的话，模型预测的轨迹基本处于原地不动的状态。

表3

结合上面我们所讨论的仅使用Ego-Status的MLP网络就能获得sota效果，说明对于nuScenes来说，Ego Status就是预测轨迹的一条shortcut, 当模型引入Ego status的时候，自然会降低对于感知信息的利用。这样的表现很难让人相信端到端模型在复杂场景下的表现。

设计一个高效的Baseline 来验证Ego Status的效果

首先，我们实在负担不起在VAD或者UniAD上来做验证实验，举例来说UniAD的第二阶段训练在我们的8* V100上就需要10天。同时，ST-P3[5]，一个经常被拿来比较的方法使用了部分不正确的训练和测试数据，产生的结果数值上是不准确的。

因此我们认为我们需要设计一个相对简洁高效的baseline方法能够快速验证我们的想法，并且能够跟现有方法进行有效对比。不同于UniAD的模块化设计，我们使用了一个非常非常简单的设计，如下图所示，我们提出的baseline网络直接使用生成的BEV特征与一个Ego query发生交互，然后通过MLP预测最终的轨迹。与UniAD等方法不同，我们的baseline方法不使用其他任何中间监督，包括但不限于Depth, Detection, Map, Motion 等。最终模型仅使用一个L2 loss来进行轨迹的监督。Ego Status可以在BEV阶段或者最终的MLP阶段选择性加入。我们的模型训练12ep需要大概6个小。

图3

最终的结果如下表，在BEV和Planner中都使用Ego staus时，我们的方法(ID-12)和VAD-Base（ID-6）基本一致，这能说明我们的方法简单却有效吗？显然不能，这也正是Ego status主导planning性能所带来的影响，使用Ego status后，根本无需复杂设计就能取得和现有sota差不多的结果。在Ego status占据主导地位后，不同方法之间的差异根本体现不出来。事实上我们已经看到了类似的论文把使用ego status所带来的性能提升包装进自己方法里，用来展现自己方法的有效性。这是极其误导人的行为。

表4

看似我们的方法在使用Ego Status时取得了不错的结果，但是从下图中可以看到，在Planner中使用Ego status的方法（Baseline++）似乎只用3k个iter就能收敛了，这显然是模型学到了Ego status到planning的short cut而非从视觉信息中获得有效线索。可视化BEV特征也发现，模型几乎没有从视觉分支中学习到什么有意义的表征。

图4

我们暂时先不讨论为什么我们的方法在不使用ego status的情况下（ID-10）效果也不错的这个现象。

不用Ego Status不就完事了？

既然引入Ego Status会主导planning的学习，假如我们不想让这样的现象发生，那我们不用Ego Status不就完事了吗？第一时间这么想肯定没问题，但是

真的没有使用Ego Status吗？

为什么会有这个问题呢？因为我们发现很多方法会无意识的引入Ego Status。例如，BEVFormer默认使用了can_bus信息，这里面包含了跟自车速度，加速度，转向角相关的信息。这个东西对BEVFormer做感知其实是没啥用的，但是VAD和UniAD拿过来直接做planning话，can_bus就会发挥作用了。类似的Ego信息在感知方法中也经常被使用用来做时序对齐之类的事情。我们重新训练了去掉了can_bus的UniAD 和VAD模型，会发现明显的性能下降。考虑到ego status信息在最新的BEV方法中都被广泛使用，去掉这些信息的使用或者保证不同方法之间的公平比较都是非常困难的事情。一点点Ego status的泄漏都会对最终的planning性能产生巨大的影响。

图5： BEVFormer默认使用的can_bus_info包含ego status

去掉Ego Stutus仍存在的问题

讨论到现在，可能只是简单的认为责任全在ego status，很可惜并不是这样。当我们观察上面的表4，会看到我们的方法Baseline（ID-10）在不使用任何ego status的信息的情况下，可以取得和UniAD(ID-2), VAD(ID-5)这些在BEV上用了ego status的，使用了额外感知，预测任务的模型差不多的效果。 我们再回顾一下我们的Baseline (ID-4)的设置，输入图像256x704, 仅使用GT轨迹，不使用其他中间标注，仅使用L2 loss训练12ep。 为什么这样一个朴素到极致的方法会取得这样的效果？在这里我只给出我的一个猜想，不一定正确。 既然我们能够用ego status几个数值就拟合nuScenes大多数简单场景，说明学习nuScenes 大多数简单场景的planning本身就不是一件具有挑战性的事情，学习这些简单场景下的planning根本就不需要perception map等信息。其他方法使用了更多其他模块，带来更复杂的多任务学习，事实上反而影响了planning 本身的学习，我们也做了一个简单的实验来验证我们的猜想。

表5

如上表所示，Baseline 是原来的(ID-10)的结果，我们在Baseline上添加了一个MapFormer，具体实现做法和UniAD/VAD差不多，这个Baseline+Map模型的初始化是经过Map预训练的。我们可以看到Baseline+Map的结果远远逊色于Baseline。 原因是啥呢？为了消除Map预训练的影响，我们也使用Map预训练的权重作为(ID-10)这个setting的初始化得到了Baseline（init*）这个结果，通过对比Baseline不同初始化，我们可以发现，预训练的Map权重不会导致性能下降，反而会提升性能。问题只会出现在引入Map任务本身了。

我们对比了Baseline和Baseline+Map 在直行命令下的 L2 指标：L2-ST 和左右转指令下的L2指标： L2-LR。 同样还有在直行命令下的碰撞率指标Collision-ST, 在转弯场景下的碰撞率指标Collision-LR。 我们会发现在转弯场景下引入Map只是轻微增加L2距离，并且能够大幅度降低转弯场景下的碰撞率。与之对应的是直行场景下的L2和Collision被double了。考虑到转弯场景通常是更复杂，更需要操作的，而直行场景相对简单，我们猜测是因为引入Map 带来多任务学习的干扰反而影响了这些简单场景的学习。在nuScenes验证集上，直行命令占比87%，因此主导了最终的平均指标。我们可以看到Map引入在转弯场景下实际是没什么负面效果的，但是被平均之后Map的积极效果根本彰显不出来。

如果我们的猜想成立，这说明nuScenes做planning不单单是一个ego status的问题，而是本身全方面的不靠谱。

开环Planning指标

碰撞率指标的多个问题

我们暂时先不讨论L2 distance的问题， 因为好像更多的文章倾向于认可collision rate这个指标。实际上这个指标非常不靠谱，原因有：

• 计算碰撞的时候，其他车的未来轨迹都是回放，没有任何reaction，单从这一点上讲，这个指标就很不靠谱。

• 实际实现的问题，由于预测的轨迹只是一堆xy坐标，没有考虑ego 的yaw angle在未来的变化，计算碰撞的时候也是假设ego car的yaw angle永远保持不变，会造成很多错误的碰撞计算。我们这次也是通过轨迹估算yaw, 统一解决了这个问题。

图7 UniAD引入后处理模块来优化轨迹，降低碰撞率

• Collision Rate可以被后处理进行攻击, UniAD中最有效的模块是一个后处理模块，在端到端模型给出一个初始的预测结果后，使用一个optimizer 来使得轨迹在满足一定约束条件下尽可能的远离其他物体，从而避免碰撞。从指标上讲，这个trick可以显著降低collision rate。然而看似合理的模块其实只是对于collision rate的一个hack, 原因在于约束条件不够多，例如没有考虑到地图信息。可以简单理解为：为了躲其他车，这个模块会选择打方向盘，冲到马路牙子上。但是根据现有指标，撞马路牙子是没有啥大问题的。 whaosoft aiot http://143ai.com 

引入新指标

上面我们讨论了，汽车撞到马路牙子时，现在的指标是不会有什么显著惩罚的，造成一些方法可以通过用撞马路牙子的手段来降低与其他车发生碰撞的概率。所以我们使用了一个新的指标用来统计ego和road boundary(马路牙子)发生交集的概率。具体实现方法和collision rate的方法一致。经过统计，使用UniAD的后处理，降低0.1 %的碰撞概率的代价是增加5%以上与道路边界（马路牙子）发生交互的概率。这一后处理显然是不合理的，我们汇报UniAD的结果时，也都是默认不使用后处理的。

图8 UniAD的后处理显著增加了与马路边间发生交互的概率

开环的DEMO真的可靠吗

图9 左：根据当前速度直行，中：Ego-MLP 右: GT 我们可以看到左边这列使用最简单的按照当前速度直行的策略，也会减速让行，避让车辆。这其实这都是human driver 的操作。 对于开环方法，每一时刻都会刷新回human driver驾驶的安全轨迹，沿用human driver的驾驶策略。因此开环端到端方法每时每刻都是在一个安全的轨迹之上做未来的预测，不受到累计误差的影响。再难的路, 0.5s后 human driver总会给你正确答案。

你的开环端到端模型能学会转弯吗？

图10， 似乎所有的开环模型都不会转弯

我们发现似乎所有的开环模型都没有学会怎么转弯，转弯的时候预测的轨迹和真实轨迹差别很大，而且前后预测的轨迹不smooth，也就是前后不一致。

总结

基于nuScenes的开环端到端自动驾驶，所面临的问题太多了，心累了。

参考

1. https://arxiv.org/pdf/2212.10156.pdf

2. RethinkingtheOpen-LoopEvaluationofEnd-to-EndAutonomousDrivingin nuScenes https://arxiv.org/pdf/2305.10430.pdf

3. AD-MLP Issue https://github.com/E2E-AD/AD-MLP/issues/4

4. https://github.com/hustvl/VAD

5. https://github.com/OpenDriveLab/ST-P3

# 自动驾驶轨迹/行为/运动/交通预测~论文总结

１.轨迹预测

TP-AD-Survey

题目：A Survey on Trajectory-Prediction Methods for Autonomous Driving

名称：自动驾驶轨迹预测方法综述

论文：https://ieeexplore.ieee.org/document/9756903

TP-Vision-Survey

题目：Trajectory-Prediction with Vision: A Survey

名称：视觉轨迹预测：一项调查

论文：https://arxiv.org/abs/2303.13354

TP-MultiModal-Survey

题目：Multimodal Trajectory Prediction: A Survey

名称：多模态轨迹预测：调查

论文：https://arxiv.org/abs/2302.10463

TP-DMAL-Survey

题目：A Survey on Trajectory Data Management, Analytics, and Learning

名称：轨迹数据管理、分析和学习调查

论文：https://arxiv.org/abs/2003.11547

TSM-ST-Survey

题目：Spatio-Temporal Trajectory Similarity Measures: A Comprehensive Survey and Quantitative Study

名称：时空轨迹相似性度量：综合调查和定量研究

论文：https://arxiv.org/abs/2303.05012

TP-Veh-ML-AD-Survey

题目：Machine Learning for Autonomous Vehicle's Trajectory Prediction: A comprehensive survey, Challenges, and Future Research Directions

名称：自动驾驶车辆轨迹预测的机器学习：综合调查、挑战和未来研究方向

论文：https://arxiv.org/abs/2307.07527

TP-Veh-AD-DL-Survey

题目：A Survey on Deep-Learning Approaches for Vehicle Trajectory Prediction in Autonomous Driving

名称：自动驾驶中车辆轨迹预测的深度学习方法综述

论文：https://arxiv.org/abs/2110.10436

TP-Veh-ML-Survey

题目：Machine Learning for Autonomous Vehicle's Trajectory Prediction: A comprehensive survey, Challenges, and Future Research Directions

名称：自动驾驶车辆轨迹预测的机器学习：综合调查、挑战和未来研究方向

论文：https://arxiv.org/abs/2307.07527

TP-Veh-DK-DL-AD-Survey

题目：Incorporating Driving Knowledge in Deep Learning Based Vehicle Trajectory Prediction: A Survey

名称：将驾驶知识融入基于深度学习的车辆轨迹预测：一项调查

论文：https://ieeexplore.ieee.org/document/10100881

TP-Veh-DL-AD-Survey

题目：A Survey on Deep-Learning Approaches for Vehicle Trajectory Prediction in Autonomous Driving

名称：自动驾驶中车辆轨迹预测的深度学习方法综述

论文：https://arxiv.org/abs/2110.10436

TP-Veh-DL-Survey

题目：A Survey of Vehicle Trajectory Prediction Based on Deep-Learning

名称：基于深度学习的车辆轨迹预测综述

论文：https://ieeexplore.ieee.org/document/10105706

TP-Ped-Veh-Mixed-Env-Survey

题目：Pedestrian Trajectory Prediction in Pedestrian-Vehicle Mixed Environments: A Systematic Review

名称：人车混合环境中的行人轨迹预测：系统综述

论文：https://arxiv.org/abs/2308.06419

TP-Ped-DL-AD-Survey

题目：A Review of Deep Learning-Based Methods for Pedestrian Trajectory Prediction

名称：基于深度学习的行人轨迹预测方法综述

论文：https://www.mdpi.com/1424-8220/21/22/7543

TP-Ped-DL-KB-Survey

题目：Review of Pedestrian Trajectory Prediction Methods: Comparing Deep Learning and Knowledge-based Approaches

名称：行人轨迹预测方法回顾：深度学习和基于知识的方法的比较

论文：https://arxiv.org/abs/2111.06740

２.行为预测

BP-AD-Survey

题目：Behavioral Intention Prediction in Driving Scenes: A Survey

名称：自动驾驶中车辆轨迹预测的深度学习方法综述

论文：https://arxiv.org/abs/2211.00385

BP-Ped-AD-Survey

题目：Pedestrian Behavior Prediction for Automated Driving: Requirements, Metrics, and Relevant Features

名称：自动驾驶的行人行为预测：要求、指标和相关特征

论文：https://arxiv.org/abs/2012.08418

BP-Ped-Urban-Survey

题目：A Literature Review on the Prediction of Pedestrian Behavior in Urban Scenarios

名称：城市场景行人行为预测文献综述

论文：https://dl.acm.org/doi/abs/10.1109/ITSC.2018.8569415

BP-Veh-DL-AD-Survey

题目：Deep Learning-based Vehicle Behaviour Prediction For Autonomous Driving Applications: A Review

名称：基于深度学习的自动驾驶应用车辆行为预测：综述

论文：https://arxiv.org/abs/1912.11676

BP-Driver-Human-Survey

题目：A Taxonomy and Review of Algorithms for Modeling and Predicting Human Driver Behavior

名称：人类驾驶员行为建模和预测算法的分类和综述

论文：https://arxiv.org/abs/2006.08832

３.运动预测

MP-Ped-Veh-AD-Survey

题目：A Survey on Motion Prediction of Pedestrians and Vehicles for Autonomous Driving

名称：自动驾驶行人和车辆运动预测研究综述

论文：https://ieeexplore.ieee.org/document/9559998

MP-SC-AutoVeh-Survey

题目：Scenario Understanding and Motion Prediction for Autonomous Vehicles—Review and Comparison

名称：自动驾驶汽车的场景理解和运动预测——回顾与比较

论文：https://ieeexplore.ieee.org/document/9733973

MP-3D-Human-Survey

题目：3D Human Motion Prediction: A Survey

名称：3D 人体运动预测：一项调查

论文：https://arxiv.org/abs/2203.01593

MTP-Human-Survey

题目：Human Motion Trajectory Prediction: A Survey

名称：人体运动轨迹预测：一项调查

论文：https://arxiv.org/abs/1905.06113

４.交通预测

TP-Traffic-BigData-Survey

题目：Big Data for Traffic Estimation and Prediction: A Survey of Data and Tools

名称：用于交通估计和预测的大数据：数据和工具调查

论文：https://arxiv.org/abs/2103.11824

TP-Traffic-DNN-Survey

题目：Short-term Traffic Prediction with Deep Neural Networks: A Survey

名称：使用深度神经网络进行短期交通预测：一项调查

论文：https://arxiv.org/abs/2009.00712

TP-Traffic-STG4Traffic

题目：STG4Traffic: A Survey and Benchmark of Spatial-Temporal Graph Neural Networks for Traffic Prediction

名称：STG4Traffic：用于交通预测的时空图神经网络的调查和基准

论文：https://arxiv.org/abs/2307.00495

#自动驾驶从1.0到3.0的思考

最近在思考自动驾驶( Autonomous Driving，以下简称AD)的发展趋势，发出来我的观点和大家讨论。

AD 1.0

定义

每个相机的图像输入给不同的模型来检测障碍物、车道线、交通灯等信息，融合模块使用规则来融合这些信息给规控模块，规控输出控车信号。具体架构如下图：

特点

1. 每个相机图像单独过模型

2. 有很多小模型：障碍物模型，车道线模型，交通灯模型等

3. 融合、定位、规控模块都是人工编码

问题

1. 障碍物是白名单制度，无法识别标注对象之外的目标，比如倒地的大卡车，路上的石块等等

2. 障碍物表示为3D框，表示精度有限，比如运货大卡车凸出来的钢管等

3. 规划模块不具备完备性，不考虑车辆运动之间的互相影响

4. 融合、规控模块均为复杂的手工编码，迭代到最后非常容易出现顾此失彼的现象，难以维护

5. 整个Debug流程本质上是用人力做反向传播，消耗的人力资源很多，无法规模化

应用案例

1. TDA4等低算力平台

2. 2020年之前的特斯拉

3. 2022年之前的国内新势力

总结

AD1.0仅支持实现高速场景辅助驾驶，国内新势力也都已经经过了这个阶段。

AD 2.0

定义

各个相机的输入统一给模型，直接由模型完成不同相机及时序间的信息融合，感知模型同时输出障碍物、占据栅格、车道结构等等。规控模型接收感知输出的feature，输出自车预测轨迹或者控车信号。架构如下图

特点

1. 感知只有一个BEV模型，完成多相机时序上的融合工作，输出3D障碍物、Occ、车道结构等信息。

2. 规划也用模型，输出自车的预测轨迹或者控制信号

3. 感知和规划模型必须要联合训练

问题

1. 解决了通用障碍物的问题。但依然无法处理部分没有障碍物，但是需要特别注意的场景，比如说路面上有积水、未凝结的水泥路面、有水渍的环氧地坪地面等。

2. 缺乏对现实世界的常识：比如塑料袋可以压过（物体材质），前方渣土车上的土块看起来要掉（地球有重力），前方路段是小学放学时间（社会规律），前面两个车撞到一起（突发事件）

3. 和人类的交互太弱，目前的人机共驾只是人和汽车方向盘、油门的协同。人类无法告诉车辆『前面第二个路口右转，注意要提前上辅路』这类信息。

应用案例

1. Tesla FSD V12 （2023年11月开始员工内部推送）

2. 英国的自动驾驶公司 Wayve

总结

AD 2.0支持实现城区辅助驾驶，但由于上述问题的存在，依然无法实现无人化。国内新势力在感知端已经完成了AD 2.0的切换，但是规控端还是规则，也可以称之为AD 1.5

AD 3.0

定义

AD 1.0和AD 2.0的架构已经在业界达成共识，但还是支撑不了真正的无人化驾驶。怎么能通向真正的无人化，目前并无确定的方向。

这里介绍一种可能的方案，把多模态大模型(Multi-modal LLM)作为Agent来控车，架构如下图。

相比AD 2.0的输入只有传感器数据，这里多了人类指令交互，机器可以听从人类指令，调整驾驶行为。

特点

1. 由多模态大模型作为核心来控车

2. 可以和人类（车内的乘客和车外的管理人员）进行语言交互

问题

1. 怎么消除MLLM的幻觉问题？

2. 怎么在车上实时的运行MLLM？

应用案例

暂无，硬要说的话可以看看OpenAI投资的自动驾驶公司Ghost Autonomy（Ghost也无法解决上车问题）

总结

这种方案上限很高，有望达到人类级别的驾驶水平。但是目前还在学术探索阶段，还需要几年时间才能落地。

在当前这个时间点，也许可以通过把MLLM部署在云端，来监管车辆自动驾驶的行为，并在必要的时候做出修正，类似于L4的远程司机，这种架构称之为AD 2.5?