Bench2Drive面向闭环端到端自动驾驶的多能力基准测试
Bench2Drive：面向闭环端到端自动驾驶的多能力基准测试
Bench2Drive: Towards Multi-Ability Benchmarking of Closed-Loop End-To-End
Autonomous Driving
Bench2Drive：面向闭环端到端自动驾驶的多能力基准测试
Abstract
在基础模型快速扩展的时代，自动驾驶技术正迈向一个变革的门槛，端到端自动驾驶（E2E-AD）因其以数据驱动方式扩展的潜力而崭露头角。然而，现有的E2E-AD方法大多采用开环日志重放方式进行评估，以L2误差和碰撞率作为指标（例如，在nuScenes数据集中），但这并不能全面反映算法在驾驶方面的性能，这一点近期已在业界得到认可。对于那些在闭环协议下评估的E2E-AD方法，它们通常在固定路线进行测试（例如，在CARLA模拟器中的Town05Long和Longest6路线），以驾驶得分作为指标，但由于指标函数的不平滑性和长路线中存在的大量随机性，驾驶得分具有很高的波动性。此外，这些方法通常使用自行收集的数据进行训练，这使得在算法层面进行公平比较变得不可行。
为了满足全自动驾驶（FSD）对全面、真实、公平的测试环境的迫切需求，我们推出了Bench2Drive
，这是首个以闭环方式评估端到端自动驾驶（E2E-AD）系统多种能力的基准测试平台
。Bench2Drive的官方训练数据由200万帧完全标注的图像组成 ，这些数据是从CARLA v2模拟器的13638个短视频片段中收集的
，这些片段均匀分布在44个交互场景（如切入、超车、绕行等） 、23种天气条件（晴天、雾天、雨天等）
和12个城镇（城市、村庄、大学等） 中。其评估协议要求E2E-AD模型在不同地点和天气条件下通过44个交互场景，总计220条路线
，从而全面且清晰地评估它们在不同情况下的驾驶能力。我们在Bench2Drive上实现了最先进的E2E-AD模型并对其进行了评估，提供了关于当前状况和未来方向的见解。
1 Introduction
近年来，自动驾驶领域取得了巨大的发展，这得益于基础模型的快速进步和扩展[1–3]。这些进展引领了端到端自动驾驶（E2E-AD）系统的新时代[4–8]，这些系统有望通过可扩展的数据驱动方法实现车辆自动化，与传统的基于模块的感知[9–13]、预测[14–17]、规划[18–20]流水线相对立。E2E-AD系统的设计初衷是从海量数据中学习
，有望彻底改变车辆智能化的格局。
尽管E2E-AD系统取得了诸多进展，但其评估方法仍然是关键瓶颈。以下是对当前评估方法存在问题及需求的详细归纳：
当前评估方法
开环评估
：一种流行的评估方式是使用如nuScenes等数据集中的专家轨迹记录进行日志重放，即开环评估。这种方法通常使用原始传感器信息作为输入，预测自车未来的位置。
评估指标：采用与记录轨迹的L2误差和碰撞发生率作为评估指标。
存在问题
规划能力展示不足：由于分布偏移、因果混淆[26, 27]等问题，开环评估指标在展示规划能力方面存在不足。
nuScenes数据集问题：其验证集规模小且不平衡（约75%的帧仅要求继续直线行驶），导致仅编码自车状态（位置、速度等）即可实现与复杂传感器输入方法相似的L2误差，这凸显了对闭环评估基准的需求。
需求
闭环评估基准：鉴于开环评估的局限性，业界广泛呼吁建立闭环评估基准，以更全面、真实地评估E2E-AD系统的性能。
CARLA是闭环端到端自动驾驶（E2E-AD）评估中最广泛使用的模拟器之一。在其框架下，已经建立了诸如Town05Long和Longest6等基准测试，这些测试包含多条路线，要求自动驾驶系统（AD系统）在特定的时间限制内安全完成。然而，这些基准测试仅评估了诸如车道保持、转弯、避障和遵守交通信号灯等基本技能[29,
30]，未能检验AD系统在复杂且交互式的交通环境下的驾驶能力。最新的CARLA排行榜v2引入了39个挑战性场景，旨在评估AD系统在更复杂情况下的鲁棒性
。尽管如此，官方评估路线长度在7至10公里之间，且充满了各种场景，这对AD系统构成了巨大挑战，往往难以完美完成
，如**图2（a）**所示。因此，由于驾驶分数指标采用了指数衰减函数，使得有效比较不同的AD系统变得具有挑战性，因为它们的得分往往非常低。例如，在当前的排行榜v21中，参与方法的得分低于100分中的10分。此外，现有方法通常自行收集数据，这使得在算法层面进行公平比较变得不可行。
为了解决自动驾驶（AD）系统评估中面临的上述挑战，开发一个能够细致且公平地评估其能力的新基准至关重要。为此，我们推出了 Bench2Drive
，这是一个旨在全面、真实且公平地评估端到端自动驾驶（E2E-AD）系统的闭环环境新基准。Bench2Drive
拥有一个由最先进的专家模型Think2Drive收集的官方训练数据集 ，该数据集包含200万帧完全标注的图像，这些图像来源于13638个视频片段。它
涵盖了44种不同的交互式场景
，如切入、超车、绕行等，这些场景发生在不同的天气条件和城镇环境中，从繁忙城市中心的晴天到古色古香村庄中的雾天应有尽有。评估协议包括 220条短路线
，每条路线长度仅约150米 ，且只包含一个特定场景
。这样，对单项技能的评估就是独立的，从而能够对44种不同技能集中的自动驾驶系统熟练程度进行详细比较。此外，每条路线的简短性减轻了指数衰减函数对驾驶分数的影响，使得能够更准确、更有意义地比较不同系统之间的性能。这样一个结构化和有针对性的基准，将更清晰地揭示每个自动驾驶系统的优缺点，从而能够实现有针对性的改进和更精细的技术开发。
综上所述，所提出的Bench2Drive基准具有以下特点：
• 全面覆盖各种场景：Bench2Drive旨在测试自动驾驶系统（AD系统）在44种交互式场景中的表现，提供对复杂情境下能力的全面评估。
•
细致的技能评估：通过构建包含220条短路线的评估体系，每条路线专注于一个特定的驾驶场景，Bench2Drive能够详细分析和比较不同AD系统在单个任务上的表现。
• 闭环评估协议：Bench2Drive以闭环方式评估AD系统，其中AD系统的动作直接影响环境。这种设置能够准确评估AD系统的驾驶性能。
•
多样化的大规模官方训练数据：Bench2Drive包含一个标准化的训练集，该训练集包含来自13638个视频片段的200万帧完全标注的图像，这些图像涵盖了多种场景、天气和城镇条件。这确保了所有AD系统都在丰富且相似的条件下进行训练，这对于算法层面的公平比较至关重要。
这些特点使Bench2Drive成为自动驾驶领域的开创性基准，为研究人员提供了一个在现实、全面和公平的环境中优化和评估其端到端自动驾驶（E2E-AD）系统的关键工具。我们在
Bench2Drive上实施了几个经典基线 ，包括 TCP、ThinkTwice、DriveAdapter、UniAD、VAD和AD-MLP
，并对它们进行了评估。我们确认了L2误差等开环指标无法反映实际驾驶性能的事实。对于经典的闭环指标——驾驶分数，我们发现它缺乏细节，且其严厉的惩罚措施鼓励了过于保守的驾驶策略，而Bench2Drive则提供了对不同方法能力的全面理解。
2 Related Work
2.1 Planning Benchmarks
自动驾驶领域的基准测试已经从专门的数据集（如用于感知的KITTI ，用于行为预测的NGSIM/highD 、BARK
）发展到综合形式的数据集，如nuScenes 、Argoverse 和Waymo
，这些数据集促进了对各种协同系统组件的评估。最近，基于学习方法的规划能力评估已成为一个研究热点[37–41]。在 表1
中，我们比较了规划基准。虽然nuScenes 提供了开环指标，但由于缺乏闭环模拟，它受到了无法充分评估规划能力的批评[23, 24,
19]。此外，其验证集存在不平衡问题，有很大一部分（75%）的场景仅要求直线驾驶，因此无法充分挑战自动驾驶系统（AD系统）在复杂环境中的决策能力。nuPlan
和Waymax 提供了闭环评估，但仅限于边界框级别的评估，不包括传感器模拟，因此不适合端到端自动驾驶（E2E-AD）方法 。Longest6
是CARLA排行榜V1的修改版，仅评估基本技能，如车道保持、转弯、避碰和交通信号灯识别。CARLA排行榜V2
缺少专家演示数据。正如社区广泛讨论的那样[42,
43]，缺少官方训练集使得不同方法的比较停留在系统层面而非算法层面。Bench2Drive通过提供大规模、标注丰富的官方训练数据集以及多能力评估集来解决这些不足。这使得能够对自动驾驶系统的驾驶能力进行更细致、更有信息量的评估，克服了现有基准测试依赖所有路线的平均得分作为主要性能指标的限制。
2.2 End-to-End Autonomous Driving
端到端自动驾驶（E2E-AD）的概念可以追溯到20世纪80年代。近年来，神经网络，尤其是Transformer的出现，展示了缩放定律的强大力量，这重新激发了人们对E2E-AD的热情[46–50]。然而，它们要么仅以开环方式进行评估[51,
4, 22, 52]，要么在相对简单的场景（如Town05Long/Longest6）中进行评估[53, 54, 42,
55–60]。Bench2Drive提供了一个具有挑战性和全面性的平台，用于比较E2E-AD方法的能力。
3 Bench2Drive
Bench2Drive由在CARLA中收集的大规模、完全标注的数据集（作为官方训练集）、用于细致驾驶技能评估的评估工具包，以及针对训练数据集和评估工具包定制的几种最先进的端到端自动驾驶（E2E-AD）方法实现组成。所有数据、代码和检查点均在GitHub和Huggingface上以Apache
License 2.0发布。我们将在下一节中详细介绍。
3.1 Data Collection Agent
数据采集代理（专家）负责收集数据，以便学生模型可以从这些数据中学习 。在真实世界中，这通常由人类来完成
，比如驾驶汽车在城市中穿梭，就像KITTI、nuScenes、Waymo和Argoverse等数据集的制作过程一样。然而，这需要大量的人力。在模拟环境中，有一个廉价的替代品——教师模型
。教师模型会使用真实世界中无法获得的信息（称为特权信息），例如周围代理的真实位置、状态和意图，以及交通信号灯的真实状态等
。因此，使用CARLA的人要么编写规则[43, 61]，要么训练一个强化学习（RL）模型[50, 31]，以利用这些特权信息在模拟环境中进行驾驶 。
在本工作中，我们使用基于世界模型的强化学习教师 ——Think2Drive在CARLA中进行导航和数据收集
，因为它是唯一一个能够在构建Bench2Drive时解决所有44个场景的专家模型
。值得注意的是，在Bench2Drive发布后，基于规则的专家模型PDM-Lite2也开源了 ，用户可以根据自己的需求进行使用。
3.2 Expert Dataset
在闭环方式下评估的现有端到端自动驾驶（E2E-AD）方法[5, 6, 56, 57]通常使用CARLA模拟器自行收集数据。然而，正如[42,
43]所强调的，这些数据集的大小和分布对性能有着显著影响，这使得在算法层面进行公平比较变得具有挑战性。为了解决这一问题，我们构建了一个包含全面标注的大型专家数据集，标注内容包括三维边界框、深度和语义分割，采样频率为10Hz，作为官方训练集。由于专家信息可能是学生模型的重要指导[49,
27, 60]，我们还提供了专家模型——Think2Drive的价值估计和特征。图3
给出了概述。为了方便社区重新实现现有的端到端自动驾驶方法，我们采用了与nuScenes相似的传感器配置 ：
• 1个激光雷达：64通道，85米探测范围，每秒60万个点
• 6个摄像头：全方位覆盖，900x1600分辨率，JPEG压缩（质量等级20）
• 5个雷达：100米探测范围，30°水平和垂直视场角
• 1个惯性测量单元（IMU）和全球导航卫星系统（GNSS）：提供位置、偏航角、速度、加速度和角速度信息
• 1个鸟瞰图（BEV）摄像头：用于调试、可视化和遥感
• 高清地图（HD-Map）：包含车道、中心线、拓扑结构、动态灯光状态以及交通信号灯和停车标志的触发区域
这样的配置旨在提供一个全面且标准化的数据集和评估环境，以促进端到端自动驾驶方法的研究和发展。
此外，为了应对感知和行为角度数据长尾分布所带来的挑战——这是自动驾驶领域的一个重大瓶颈（在nuScenes数据集中，约75%的片段仅涉及自车直行），我们确保天气条件、景观和行为数据的分布尽可能均匀。与CARLA排行榜V2的官方路线相比，我们增加了更多场景的可选位置，如
图4
所示，从而增强了数据的多样性。此外，我们还设计了5个超出排行榜V2范围的额外场景，以增强行为的多样性，具体细节见附录G。附录B中给出了场景、天气和城镇的分布情况。如图所示，Bench2Drive数据集在感知和行为多样性方面均十分丰富。
在数据划分方面，我们将驾驶过程分割成多个短片段，每个片段大约150米长，并包含一个特定的场景。这种分割方式便于进行单个驾驶技能的课程学习。为了适应不同的计算能力，我们设计了三个数据子集：mini（10个片段，用于调试和可视化）、base（1000个片段，与nuScenes相当，适合8xRTX3090服务器）和full（10000个片段，用于大规模研究）
。
3.3 Multi-Ability Evaluation
现有的规划基准测试[28, 38,
37]通过计算所有提供路线上的平均分数来评估自动驾驶系统的性能。这种方法虽然能够提供驾驶能力的一般概述，但无法准确指出不同方法的具体优缺点。更糟糕的是，CARLA中的现有基准测试，如Longest6和排行榜V2，覆盖了几公里的路程，导致驾驶分数指标存在很大差异。这种差异的产生是因为违规分数通过累积乘法来惩罚错误，这可能会极大地扭曲结果
。例如，考虑三次测试运行，每次都完成了90%的路线，但闯红灯的次数不同：0次、1次和2次。相应的驾驶分数将是90、900.7=63和900.7*0.7=44.1，这导致了一个很大的标准差——18.9，从而使得方法之间的比较不可靠。
为了解决这些问题，我们为所有44个场景提出了一个更细致的评价框架，即每个场景设计5条不同的短路线（每条大约150米长），每条路线都有不同的天气和城镇背景，总共形成220条路线。这种方法使人们能够通过独立的技能来评估自动驾驶系统的能力，从而进行更详细的分析，并减少差异。此外，我们总结了5项城市驾驶中的高级技能：汇入车流、超车、让行、交通标志识别和紧急制动，如
表2 所示，并报告了每项技能的分数
。这种分离式设计可以更清楚地了解自动驾驶系统哪些技能处理得有效，哪些技能处理得不好，从而更细致地理解系统性能 。
3.3 Multi-Ability Evaluation
现有的规划基准测试[28, 38,
37]通过计算所有提供路线的平均分数来评估自动驾驶（AD）系统的性能。这种方法提供了驾驶能力的一般概述，但无法准确指出不同方法的特定优势和劣势。更糟糕的是，CARLA中的现有基准测试，如Longest6和Leaderboard
V2，涵盖了数公里的路程，导致驾驶分数指标存在高方差。这种方差产生的原因在于，违规分数通过累积乘法对错误进行惩罚，这可能会极大地扭曲结果。例如，考虑三次测试运行，每次都完成了90%的路线，但闯红灯的次数不同：分别为0次、1次和2次。相应的驾驶分数将是90、90
- 0.7 = 63和90 * 0.7 * 0.7 = 44.1，这导致了一个很大的标准差——18.9，因此使得方法之间的比较不可靠。
为了解决这些问题，我们为所有44个场景提出了一个更细致的评价框架，即每个场景设计5条不同的短路线（每条大约150米长），每条路线都有不同的天气状况和城镇背景，总计220条路线。这种方法使人们能够按单项技能评估自动驾驶（AD）系统的能力，从而减少方差，进行更详细的分析。此外，我们总结了5项城市驾驶的高级技能：并线、超车、让行、交通标志识别和紧急制动，如
表2 所示，并报告了每项技能的得分
。这种解耦设计让人们更清楚地了解自动驾驶系统哪些技能处理得有效，哪些技能处理得不好，从而更细致地了解系统性能。
正式来说，评估集包含220条路线，每条路线在一个特定的城镇和天气条件下定义了一对起点位置（ x s r c , y s r c x_{src},
y_{src} xsrc,ysrc）和终点位置（ x d s t , y d s t x_{dst},y_{dst}
xdst,ydst）。给定原始传感器输入（摄像头、激光雷达、惯性测量单元/全球定位系统等）以及目标航点，自动驾驶车辆应从起点行驶到终点。我们设计了两个指标来评估性能：
• 成功率（SR）
：该指标衡量在规定时间内且没有交通违规的情况下成功完成的路线比例。如果自动驾驶车辆没有任何违规行为地到达目的地，则该路线被视为成功。成功率按成功路线数与总路线数的比率计算，如等式1（左）所示。
• 驾驶分数（DS） ：该指标遵循CARLA
的官方指标作为参考。它同时考虑路线完成度和违规行为处罚。具体来说，它计算路线完成度的平均值，并根据违规行为的严重程度进行处罚
，如等式1（右）所示。此外，驾驶分数还根据相同类型或组的路线总数进行了归一化处理 。
其中， n s u c c e s s n_{success} nsuccess 和 n t o t a l n_{total} ntotal
分别表示成功路线的数量和总样本数量；Route-Completion𝑖 表示第 𝑖 条路线已完成的路线距离的百分比； p i , j p_{i,j}
pi,j 表示第 𝑖 条路线上第 𝑗 项违规行为的处罚。有关违规类型及处罚分数的详细信息，请参阅附录F。
此外，除了算法的目标达成能力之外，我们还提出以下两个指标来衡量驾驶轨迹的效率和平稳性：
• 效率 ：CARLA团队已经实现了一个功能，用于检查自动驾驶汽车的速度是否过低
。这是通过将车辆的速度与附近车辆的速度进行比较来确定的 ：
该函数使用车辆在当前帧的速度和附近车辆的平均速度来计算速度百分比 。CARLA排行榜在每条路线上设置了四个检查点
，并在自动驾驶车辆到达检查点时检查其速度。具体来说，如果车辆比附近车辆快，则驾驶效率会高于100% 。检查结果作为处罚被纳入最终驾驶分数中
。然而，由于只有四个检查点，车辆必须在到达下一个检查点之前行驶完总路程的25%
。这导致低速处罚值具有很高的方差，使得驾驶能力在驾驶分数中的体现变得复杂。为了缓解这个问题，我们将检查点的数量增加到20个
。现在，每行驶完总路程的5%就进行一次速度检查，并且该检查结果不再纳入驾驶分数的计算中
。最终的驾驶效率指标定义为所有检查点速度百分比的平均值 。
如果自动驾驶车辆未能通过初始的5%检查点，则该路线不被纳入最终的驾驶效率指标计算中
。为了考虑可能出现异常速度峰值的情况（例如，当车辆从当前地图层掉落时），会过滤掉超过1000%的速度百分比值 。
平稳性（舒适感）
：平稳性与人类体验密切相关，因此需要比较自动驾驶策略与众多人类驾驶专家的行为来对其进行衡量。为此，我们遵循流行的nuPlan基准的平稳性（也称为舒适感）协议
，该协议评估自动驾驶车辆的最小和最大纵向加速度 、横向加速度的最大绝对值 、偏航率 、偏航加速度
、加速度变化率（jerk）的纵向分量 以及加速度变化率向量的最大幅值
。这些变量将与从nuPlan的人类专家轨迹研究中实证确定的默认值阈值进行比较 。平稳性（舒适感）的衡量基于这些值是否落在专家值的上下限范围内
。
其中，平稳性变量（vars）包括：纵向加速度 - 专家范围：[-4.05, 2.40]，最大绝对横向加速度 - 专家范围：[-4.89, 4.89]，偏航率
为了解决这些问题，我们为所有44个场景提出了一个更细致的评价框架，即每个场景设计5条不同的短路线（每条大约150米长），每条路线都有不同的天气状况和城镇背景，总计220条路线。这种方法使人们能够按单项技能评估自动驾驶（AD）系统的能力，从而减少方差，进行更详细的分析。此外，我们总结了5项城市驾驶的高级技能：并线、超车、让行、交通标志识别和紧急制动，如
表2 所示，并报告了每项技能的得分
。这种解耦设计让人们更清楚地了解自动驾驶系统哪些技能处理得有效，哪些技能处理得不好，从而更细致地了解系统性能。
正式来说，评估集包含220条路线，每条路线在一个特定的城镇和天气条件下定义了一对起点位置（ x s r c , y s r c x_{src},
y_{src} xsrc,ysrc）和终点位置（ x d s t , y d s t x_{dst},y_{dst}
xdst,ydst）。给定原始传感器输入（摄像头、激光雷达、惯性测量单元/全球定位系统等）以及目标航点，自动驾驶车辆应从起点行驶到终点。我们设计了两个指标来评估性能：
• 成功率（SR）
：该指标衡量在规定时间内且没有交通违规的情况下成功完成的路线比例。如果自动驾驶车辆没有任何违规行为地到达目的地，则该路线被视为成功。成功率按成功路线数与总路线数的比率计算，如等式1（左）所示。
• 驾驶分数（DS） ：该指标遵循CARLA
的官方指标作为参考。它同时考虑路线完成度和违规行为处罚。具体来说，它计算路线完成度的平均值，并根据违规行为的严重程度进行处罚
，如等式1（右）所示。此外，驾驶分数还根据相同类型或组的路线总数进行了归一化处理 。
其中， n s u c c e s s n_{success} nsuccess 和 n t o t a l n_{total} ntotal
分别表示成功路线的数量和总样本数量；Route-Completion𝑖 表示第 𝑖 条路线已完成的路线距离的百分比； p i , j p_{i,j}
pi,j 表示第 𝑖 条路线上第 𝑗 项违规行为的处罚。有关违规类型及处罚分数的详细信息，请参阅附录F。
此外，除了算法的目标达成能力之外，我们还提出以下两个指标来衡量驾驶轨迹的效率和平稳性：
• 效率 ：CARLA团队已经实现了一个功能，用于检查自动驾驶汽车的速度是否过低
。这是通过将车辆的速度与附近车辆的速度进行比较来确定的 ：
该函数使用车辆在当前帧的速度和附近车辆的平均速度来计算速度百分比 。CARLA排行榜在每条路线上设置了四个检查点
，并在自动驾驶车辆到达检查点时检查其速度。具体来说，如果车辆比附近车辆快，则驾驶效率会高于100% 。检查结果作为处罚被纳入最终驾驶分数中
。然而，由于只有四个检查点，车辆必须在到达下一个检查点之前行驶完总路程的25%
。这导致低速处罚值具有很高的方差，使得驾驶能力在驾驶分数中的体现变得复杂。为了缓解这个问题，我们将检查点的数量增加到20个
。现在，每行驶完总路程的5%就进行一次速度检查，并且该检查结果不再纳入驾驶分数的计算中
。最终的驾驶效率指标定义为所有检查点速度百分比的平均值 。
如果自动驾驶车辆未能通过初始的5%检查点，则该路线不被纳入最终的驾驶效率指标计算中
。为了考虑可能出现异常速度峰值的情况（例如，当车辆从当前地图层掉落时），会过滤掉超过1000%的速度百分比值 。
平稳性（舒适感）
：平稳性与人类体验密切相关，因此需要比较自动驾驶策略与众多人类驾驶专家的行为来对其进行衡量。为此，我们遵循流行的nuPlan基准的平稳性（也称为舒适感）协议
，该协议评估自动驾驶车辆的最小和最大纵向加速度 、横向加速度的最大绝对值 、偏航率 、偏航加速度
、加速度变化率（jerk）的纵向分量 以及加速度变化率向量的最大幅值
。这些变量将与从nuPlan的人类专家轨迹研究中实证确定的默认值阈值进行比较 。平稳性（舒适感）的衡量基于这些值是否落在专家值的上下限范围内
。
其中，平稳性变量（vars）包括：纵向加速度 - 专家范围：[-4.05, 2.40]，最大绝对横向加速度 - 专家范围：[-4.89, 4.89]，偏航率- 专家范围：[-0.95, 0.95]，偏航加速度 - 专家范围：[-1.93, 1.93]，加速度变化率的纵向分量 - 专家范围：[-4.13,
4.13]，加速度变化率向量的最大幅值 - 专家范围：[-8.37, 8.37]。只有当所有平稳性变量都满足平稳性标准时，轨迹才被认为是平稳的 。
在nuPlan中，平稳性是通过在整个轨迹上逐帧评估这些变量来确定的，这使得它容易受到局部驾驶行为的影响。例如，如果前方车辆突然刹车，自动驾驶车辆也必须紧急刹车以避免碰撞
。即使在这种情况下，自动驾驶车辆的紧急刹车行为是恰当的，并且在其他时候其驾驶是平稳的，但整个轨迹仍可能被判定为不平稳，从而导致不合理的评估结果。为了缓解这个问题，我们在时间步长间隔
𝑛=20 处对整个轨迹进行分段评估 。
最终的平稳性指标定义为平稳轨迹段数与总段数的比率 。
具体来说，如果自动驾驶车辆被阻塞（速度持续低于0.1超过60秒） ，导致一个失败案例
，该段轨迹仍被视为平稳，因为其速度对人类来说是安全的。请注意，如果一条轨迹的总帧数少于20帧，则该轨迹将不包括在平稳性评估中 。
在nuPlan中，平稳性是通过在整个轨迹上逐帧评估这些变量来确定的，这使得它容易受到局部驾驶行为的影响。例如，如果前方车辆突然刹车，自动驾驶车辆也必须紧急刹车以避免碰撞
。即使在这种情况下，自动驾驶车辆的紧急刹车行为是恰当的，并且在其他时候其驾驶是平稳的，但整个轨迹仍可能被判定为不平稳，从而导致不合理的评估结果。为了缓解这个问题，我们在时间步长间隔
𝑛=20 处对整个轨迹进行分段评估 。
最终的平稳性指标定义为平稳轨迹段数与总段数的比率 。
具体来说，如果自动驾驶车辆被阻塞（速度持续低于0.1超过60秒） ，导致一个失败案例
，该段轨迹仍被视为平稳，因为其速度对人类来说是安全的。请注意，如果一条轨迹的总帧数少于20帧，则该轨迹将不包括在平稳性评估中 。4 Experiments
4.1 Baselines & Datasets
为了给社区建立一个起点，我们在Bench2Drive中实现了几种经典的端到端自动驾驶（E2E-AD）方法，包括：
• UniAD明确地进行感知和预测，并使用Transformer
Query来传输信息。同时，我们还在Bench2Drive中实现了常用的BEVFormer，
• VAD也采用了Transformer Query，但使用了向量化的场景表示，从而提高了效率。
• AD-MLP简单地将自动驾驶车辆的历史状态输入到多层感知器（MLP）中来预测未来轨迹，这是历史状态插值规划器的一个简单基线。
• TCP仅使用前置摄像头和自动驾驶车辆状态作为输入来预测轨迹和控制信号。它是CARLA v1中一个简单而有效的基线。
• ThinkTwice通过分层细化规划路线并提炼专家特征，推广了从粗到精的理念。
• DriveAdapter 提出了一种新的范式，通过解耦感知和规划的学习，并通过适配器模块连接这两部分，从而充分释放专家模型的潜力。
考虑到社区内可用的计算资源各不相同，我们在基础子集（1000个片段）上训练了这些基线模型。我们使用950个片段进行训练，留出50个片段用于开环评估。我们确保验证集中包含44种场景中的每一种场景至少一个片段，并且天气分布是平衡的。AD-MLP和TCP使用1张A6000显卡进行训练
，而ThinkTwice、DriveAdapter、UniAD和VAD则使用8张A100显卡进行训练
。对于闭环评估，我们在CARLA中运行了第3.3节中提到的所有220条测试路线的模型，并相应地计算了指标。请注意，某些模型在某些特定路线上可能会出现错误行为（例如，行驶到一些错误的位置），导致CARLA崩溃而无法得分。我们将这些路线的得分视为0。有关更多实现细节，请参阅附录C。
4.2 Results
在 表3 和 表4 中，我们比较了基线端到端自动驾驶（E2E-AD）方法的开环和闭环评估结果，得出了以下发现：
开环指标可以指示模型的收敛情况，但无法进行高级比较。AD-
MLP的L2误差较高，在闭环评估中表现极差，而VAD的L2误差较低，闭环表现良好。这表明我们可以使用 L2 误差来验证神经网络的收敛状态和拟合情况，即当
L2 误差非常高时，系统内应该存在问题。在这种情况下，AD-
MLP不使用原始传感器数据，类似于盲目驾驶，因此无法拟合数据集。值得注意的是，与nuScenes的发现不同，由于Bench2Drive中行为多样性更好
（如 图5 所示），AD-MLP在Bench2Drive中无法获得良好的L2误差。另一方面，与VAD相比，UniAD-
base的L2误差更低，但闭环表现更差，这与[19, 24]中的发现一致。开环评估忽略了分布偏移和因果混淆[26,
27]等问题，因此无法对良好拟合数据集的模型进行有意义的比较，这凸显了闭环评估的重要性。在效率和平滑性方面，我们可以看到AD-
MLP由于快速失败和卡顿，效率最低。与TCP-traj相比，UniAD具有更高的效率和更平滑的轨迹，这证明了UniAD的规划头后优化方法的有效性 。
专家特征蒸馏提供了重要的指导。如[49,
50]所指出的，由于自动驾驶（AD）的输入空间是高维的，即包含多个图像和点云，端到端自动驾驶（E2E-AD）方法往往容易过拟合。而专家特征已经具备了强大的驾驶知识，通过蒸馏这些特征有助于缓解过拟合问题。因此，采用专家特征蒸馏的方法（如TCP、ThinkTwice、DriveAdapter）与未采用的方法（如VAD、UniAD）相比，性能上有显著提升
。从TCP-traj在有蒸馏和无蒸馏情况下的对比中，我们可以观察到类似的趋势。然而，在真实世界环境中，获取专家特征可能比较困难，这值得进一步研究 。
交互式行为难以学习 。所有模型在涉及强烈交互（如并线、超车、紧急制动）的技能得分上都不尽如人意
。这可能源于两个方面：（I）长尾问题。尽管我们确保了不同场景下的片段数量相似，但一个片段中只有少数帧涉及交互行为
。因此，学习起来可能颇具挑战性。（II）模仿学习范式。直接对控制信号或轨迹进行监督训练，可能无法为交互过程中的博弈、思考和推理过程提供指导
。更先进的训练范式可能是一个有前景的方向 。
4.3 Case Analysis
我们进行可视化处理，并将结果上传至 。针对所有五项能力，我们选择了一些具有代表性的场景进行可视化
，其中一些基线方法成功，而一些基线方法失败，以便于比较和分析。我们提供了相应的失败分析，以便用户和从业者能够了解现有端到端自动驾驶（E2E-AD）方法的优点、缺点以及未来的工作方向。
5 Conclusion
在这项工作中，我们推出了Bench2Drive，这是一个专为端到端自动驾驶方法的闭环评估而设计的新基准。我们开源了一个全标注的大规模数据集作为官方训练集，并提供了一个多功能评估工具包，用于细致的驾驶技能评估。我们在Bench2Drive中测试了最先进的端到端自动驾驶（E2E-AD）方法，并评估了它们的优缺点，这为未来的发展方向提供了见解。
局限性：由于CARLA模拟器的渲染效果与现实世界存在差异，因此可以像同期工作NAVSIM
那样，利用真实世界的数据集作为补充。实际上，在端到端自动驾驶算法评估领域存在一个两难困境：
生成模型，如扩散模型，可能具有提供逼真且响应迅速的渲染效果的潜力，该领域已有一些开创性工作[67–69]。然而，扩散模型中的幻觉和伪影问题需要进一步探索。
社会影响
：自动驾驶（AD）系统的部署具有彻底改变交通运输的巨大潜力，但同时也带来了重大的伦理和安全问题。Bench2Drive可以作为一个平台，在受控和模拟的环境中严格验证自动驾驶系统的能力，有助于在实际部署前发现潜在的缺陷。主要风险之一是模拟与现实之间的差距——即自动驾驶系统在模拟环境和真实环境中的表现差异。模拟很难完全复制真实驾驶条件的复杂性和不可预测性。存在一种风险，即自动驾驶系统可能在模拟环境中表现良好，但由于罕见边缘情况、意外的人类行为或变化的环境条件等未建模因素而在真实场景中失败
。Bench2Drive旨在补充而非取代真实世界测试 ，并且必须强调，模拟只是更广泛验证过程的一部分，该过程必须包括大量的道路测试 。
Checklist
清单位于参考文献之后。请仔细阅读清单指南，了解如何回答这些问题。对于每个问题，请将默认的[TODO]更改为[Yes]、[No]或[N/A]。强烈建议您为答案提供理由，可以通过引用论文中的相应部分或提供简短的行内说明来实现。例如：
• 您是否包含了代码和数据集的许可证？[Yes] 参见第3节。
请不要修改问题，并且只使用提供的宏来回答。请注意，清单部分不计入页数限制。在您的论文中，请删除此说明块，仅保留上面的清单部分标题以及下面的问题/答案。
1.对于所有作者……
(a) 摘要和引言中的主要陈述是否准确反映了论文的贡献和范围？[Yes]
(b) 您是否描述了您工作的局限性？[Yes]
(c ) 您是否讨论了您工作可能产生的任何负面社会影响？[Yes]
(d) 您是否阅读了伦理审查指南并确保您的论文符合这些指南？[Yes]
2.如果您包含了理论结果……
(a) 您是否陈述了所有理论结果的完整假设集？[N/A]
(b) 您是否包含了所有理论结果的完整证明？[N/A]
3.如果您进行了实验（例如基准测试）……
(a) 您是否包含了重现主要实验结果所需的代码、数据和说明（在补充材料中或作为URL提供）？[Yes]
(b) 您是否指定了所有训练细节（例如数据划分、超参数及其选择方式）？[Yes]
© 您是否报告了误差条（例如，在多次运行实验后关于随机种子的误差条）？[No]
(d) 您是否包含了所使用的计算总量和资源类型（例如GPU类型、内部集群或云服务提供商）？[Yes]
4.如果您正在使用现有资源（例如代码、数据、模型）或整理/发布新资源……
(a) 如果您的工作使用了现有资源，您是否引用了资源的创作者？[Yes]
(b) 您是否提到了资源的许可证？[Yes]
© 您是否在补充材料中以URL的形式包含了任何新资源？[Yes]
(d) 您是否讨论了是否以及如何从您正在使用/整理的数据所涉及的人员那里获得同意？[N/A]
(e) 您是否讨论了您正在使用/整理的数据是否包含个人身份信息或冒犯性内容？[N/A]
5.如果您使用了众包或对人类受试者进行了研究……
(a) 如果适用，您是否包含了给予参与者的完整指示文本以及截图？[N/A]
(b) 如果适用，您是否描述了任何潜在的参与者风险，并提供了机构审查委员会（IRB）批准的链接？[N/A]
© 您是否包含了支付给参与者的预计时薪以及用于参与者补偿的总金额？[N/A]
A Details of Data Collecting
The collection of data is a mix of automatic pipelines and manual checking. We
give details below:
数据的收集 结合了自动流程 和人工检查 。以下提供详细信息：
路线 ：我们使用专家模型Think2Drive在预定义的路线文件上运行 ，并且只保留那些没有违规行为的路线
。我们设计了一个遍历所有地图的算法，以确定是否可以触发某个场景 ，目的是尽可能多地覆盖城镇
。通过人工检查来确保天气、城镇和场景的平衡 。CARLA的行为和渲染有时会出现错误 ，如 图7
所示，我们手动过滤掉这些有问题的片段 。
标注 ：我们使用CARLA的官方API来收集标注信息
。值得注意的是，这些API中存在一些错误：（I）从API中获取的所有行人的速度值都为0 。我们
在训练基线方法时，通过微分运算手动计算了行人的速度
。（II）速度表和惯性测量单元（IMU）的返回值可能为None。我们在训练时，用0来填充这些值
。（III）**CARLA中的一些停车标志在地上，因此没有边界框。**为了弥补这一点，我们用矩形记录所有的停车标志，以表示它们的触发范围
。（IV）通过API获取的一些静态车辆的旋转角度和位置是错误的 。因此，我们使用正确的中心和范围来获取它们的3D边界框 。
对象类别 ：考虑到不同对象的不同属性，我们 将所有对象分为四大类 ，并按类别存储：车辆 、交通标志 、交通信号灯 和
行人 。车辆进一步细分为 静态车辆 和 动态车辆
。静态车辆在整个场景中保持静止，通过从“static.prop.mesh”获得的唯一角色标识符进行区分。交通标志包括限速标志、停车标志、让行标志、警告标志（包括施工警告、交通警告和事故警告）、路面障碍物和锥形路标
。值得注意的是，涉及触发范围的标志，如限速标志、停车标志和让行标志，其触发范围内也存储了矩形
。警告标志和锥形路标的坐标是根据其角色类的中心和范围获得的，而路面障碍物由于坐标不准确，需要进行额外的转换
。对于交通信号灯，交通标志和交通信号灯的触发范围坐标是相对于角色的，因此需要进行额外的转换。每个交通标志/信号灯由两部分组成：灯杆和灯/标志本身，而API提供的边界框仅指灯/标志部分。
坐标系 ：与Nuscenes使用的Y轴向下的右手坐标系不同，CARLA采用的是Unreal Engine坐标系
，即Z轴向上的左手坐标系 。在指南针中，相对于北方（在Unreal Engine中为[0.0, -1.0,
0.0]）的方位意味着在左手坐标系中，指南针的标准偏航角（yaw angle）是罗盘读数减去π/2（1/2
pi）。在极少数情况下，这可能会导致出现非数字（NaN）值，需要手动进行过滤 。
地图信息 ：高清地图（HD-
Map）根据道路ID（road_ids）和车道索引（lane_index）进行组织。每条车道都包含点的世界坐标和方位、车道类型、颜色标识符以及相邻的道路ID-
车道ID（包括左侧、右侧和连接的道路ID和车道ID），以及拓扑结构（例如，“交叉路口”（Junction）、“正常路段”（Normal）、“进入正常路段”（EnterNormal）、“进入交叉路口”（EnterJunction）、“通过正常路段”（PassNormal）、“通过交叉路口”（PassJunction）、“开始多变化交叉路口”（StartJunctionMultiChange）或“开始多变化正常路段”（StartNormalMultiChange））。触发体积（Trigger_Volumes）代表交通标志的触发区域，其中“点”（Points）指定触发体积的顶点位置，“类型”（Type）可以是“停车标志”（StopSign）或“交通信号灯”（TrafficLight），而“父角色位置”（ParentActor_Location）提供了与触发体积相关的父角色的位置详细信息。
数据压缩 ：为减小文件大小，我们参考采用压缩数据格式 。图像使用JPG格式压缩，质量参数设为20。为避免闭环评估中的训练-验证差异，我们
在推理过程中也采用内存中的JPG压缩与解压缩技术
。语义分割图和深度数据存储为PNG文件，激光雷达点云使用名为laszip的专用压缩算法进行压缩，JSON文件则采用GZIP格式压缩 。
B Distribution of Scenarios, Towns and Weathers
如 图8 所示，天气的分布几乎均匀
，而城镇的分布则以Town12和Town13为主。这种不平衡来源于两个方面：（I）CARLA团队故意将新城镇（如Town12和Town13）设计得比老城镇大得多
，以便社区能够在城市级场景中探索应用。因此，我们在更大的城镇中收集了更多数据，以获得更多样化的景观
。（II）排行榜v2中的许多新场景是最近设计的，因此老城镇不支持新场景所需的布局
。例如，分离出口需要有其他停放车辆的存在。因此，我们不得不在新城镇中收集更多数据，以确保场景类型的平衡。
C Implementation Details of Baselines
对于所有基线端到端自动驾驶（E2E-AD）方法，我们严格遵循其官方开源代码、环境和配置。不过，我们进行了以下一些修改：（I）对于有物体检测模块的方法，我们根据CARLA更改了检测类别
。（II）Bench2Drive的数据采集频率为10Hz
，而带有边界框的nuScenes数据集为2Hz。由于Bench2Drive的视频片段更长，因此与nuScenes相比，Bench2Drive基础版的数据帧大约多10倍，但冗余度也更高。对于计算需求较高的方法，如UniAD/VAD/ThinkTwice/DriveAdapter，我们训练了10个周期（epochs），而原版训练周期更少。由于训练步骤数量相似，我们观察到的损失水平也相似。（III）由于ThinkTwice和DriveAdapter需要专家的鸟瞰图（BEV）特征，我们使用Think2Drive专家来重新生成这些专家特征。此外，为了与其他方法进行公平比较，我们将这两种方法都修改为使用6个摄像头而不使用激光雷达（LiDAR）。
D Training and Evaluation Resource Requirements
我们报告了训练和评估基线所需的资源。请注意，通过使用更多的GPU在更多路线上并行评估，可以线性地加快评估速度。
E Behavior Model of NPC Agents
在CARLA中，CARLA Agent预设了三种行为类型：谨慎型、正常型和激进型。这些行为类型决定了 非玩家角色（NPC）
的驾驶行为，影响着速度、对其他车辆的反应以及安全协议等因素。每种行为模式的关键参数包括：
• max_speed：设定NPC车辆能达到的最大速度（km/h）。
• speed_lim_dist：以km/h为单位，定义车辆目标速度与当前限速之间的差值。
• speed_decrease：控制NPC在接近前方较慢车辆时的减速情况。
• safety_time：估算如果前方车辆突然刹车，本车发生碰撞的时间。
• min_proximity_threshold：定义NPC采取规避动作或紧跟前车等行动前的最小距离。
• braking_distance：NPC为避免碰撞而进行紧急停车的距离。
• tailgate_counter：一个计数器，用于防止NPC在上一次紧跟行动后太快地发起新的紧跟行动。
这些行为设计会与主体车辆（自动驾驶车辆）进行交互，确保非玩家角色（NPCs）在模拟中对主体车辆的存在和动作做出响应。不同行为风格的参数如下：
behavior_agent.py文件中针对非玩家角色（NPC）车辆的基于规则的行为决策算法如下所示：
行人的行为特点是他们会以恒定速度始终沿着路线行走，且不能倒退行走
。在自动驾驶场景中，行人安全至关重要。当自动驾驶车辆与人类交互时，行人具有最高优先级，自动驾驶车辆应学会无论交通状况如何都要给行人让路。
F Details about Infraction Score
在 表7 中，我们给出了排行榜v2设计的每项违规的扣分分数。
G Description of Scenarios
Bench2Drive在CARLA排行榜V2的基础上提供了44个弯道场景。下面我们将详细介绍这些场景：
H Author Statement
如发生侵权等情况，我们承担全部责任，并确认数据、代码和检查点的许可如第3节所述。
I License
所有数据、代码和检查点均在GitHub和Huggingface上，遵循Apache 2.0许可证。
J Datasheet
J.1 Motivation
该数据集是为了什么目的而创建的？是否有特定的任务？是否有需要填补的特定空白？请提供描述。我们构建此基准测试是为了满足全自动驾驶（FSD）全面且真实的测试环境需求。主要任务是端到端自动驾驶。现有的基准测试无法为端到端自动驾驶（E2E-AD）方法提供闭环的粒度驾驶技能评估。
谁创建了数据集（例如，哪个团队、研究小组）并代表哪个实体（例如，公司、机构、组织）？本数据集由来自上海交通大学人工智能学院和计算机科学与工程系的ReThinkLab实验室的贾晓松、杨振杰、李奇峰、张志远、颜俊池整理。
J.2 Distribution
该数据集是否会分发给代表其创建的实体（例如，公司、机构、组织）之外的第三方？是的。
数据集将以何种方式分发（例如，网站上的tarball、API、GitHub）？所有数据、代码和检查点均可在GitHub（https://github.com/Thinklab-
SJTU/Bench2Drive）和Huggingface（https://huggingface.co/datasets/rethinlab/Bench2Drive）上获取。