u013250861的博客

我会把这张表做成“”而不是只列论文名：先核对每个模型截至的公开代码、训练目标和数据接口，再单独给你一套。对于没有公开 RL recipe、只有推理代码或训练细节不完整的模型，我会明确标出来，避免把“论文里提到”误写成“可复现”。。截至今天 NVIDIA 官方开源主线已经是。

开环or闭环？自动驾驶数据应该这样选

自动驾驶中数据集如何采集和标注？一条视频告诉你

从公开数据集看，差异主要在 4 件事上：1）是只标注，还是标注；2）坐标系用还是；3）每个轨迹点只存xy，还是还带上ψ（航向）、v（速度）、时间戳、valid mask 等；4）时间采样密度和预测时域不同。nuPlan 更像“规划监督”，Waymo/Argoverse 2 更像“多目标轨迹/运动预测监督”，nuScenes 的 prediction 接口则常被拿来做未来点监督。

自动驾驶算法的训练、评测和论文复现高度依赖公开数据集。KITTI；Cityscapes；BDD100K；nuScenes；nuPlan；KITTI-360；ONCE；PandaSet；A2D2；DAIR-V2X。官网需要注册或接受数据许可；数据位于 Google Drive、Google Cloud 或欧美对象存储；数据量达到数百GB甚至数TB；OpenDataLab上可能存在多个同名或相关仓库；

自动驾驶算法的训练和论文复现高度依赖公开数据集。KITTI；Cityscapes；BDD100K；nuScenes；nuPlan；KITTI-360；ONCE；PandaSet；A2D2；DAIR-V2X。官网需要注册登录；下载链接位于 Google Drive 或 Google Cloud；数据托管在美国或欧洲的对象存储；单个数据集达到数百 GB，甚至数 TB；下载链接具有时效性；部分国内镜像并不包含最新版本或全部模块；

优先看 Waymo、nuScenes、Argoverse 2、ONCE、KITTI。来列，优先放主流/高影响力数据集。

在自动驾驶、机器人和轨迹预测任务中，一个非常常见的问题是：本文将结合下面这段代码，完整解释这个问题：navsim/common/dataclasses.py核心转换函数为：navsim/planning/simulation/planner/pdm_planner/utils/pdm_geometry_utils.py本文会围绕以下问题展开：1. 整体背景：为什么要从 Global 转 Local？在自动驾驶数据中，每一帧自车都有一个位姿 ：其中：例如，当前帧的自车位姿为：未来第一帧的自车位

nuPlan-devkit 是一个面向自动驾驶 planning 的官方研究级工具链：它把真实驾驶数据、地图、scenario 构建、planner 接口、开环/闭环仿真、指标评测和 nuBoard 可视化整合在一起，适合开发和评估自动驾驶规划算法。

数据集优点局限Waymo感知数据质量高；camera/LiDAR 标注丰富；Motion 场景数量大；预测与交互任务成熟；leaderboard 活跃对传统 closed-loop ego planning 支持不如 nuPlan 原生；数据格式和版本较复杂；完整数据体量大nuPlan面向 planning 设计；有闭环仿真；有交通规则/舒适性/进度等规划指标；真实长时驾驶 log；场景标签丰富原始传感器只公开子集；不如 Waymo 适合纯感知 benchmark；

zabiz = a + bizabii2−1i^2 = -1i2−1qwxiyjzkqwxiyjzkqwxyzqwxyzwww：实部，也叫 scalar；xyzx, y, zxyz：虚部，也叫 vector part；ijki, j, kijk：三个虚数单位。在中，数组abicjdkabicjdk也就是说，wxyzwxyz。

用稳定、紧凑的方式表示三维空间中的旋转和姿态。自动驾驶系统需要不断处理车辆、相机、激光雷达、毫米波雷达、IMU、障碍物检测框等对象在三维空间中的位置和朝向。对于一个物体来说，仅知道它在哪里是不够的，还需要知道它“朝向哪里”。这个“朝向”本质上就是三维旋转问题，而四元数正是解决三维旋转问题的重要工具。相比欧拉角，四元数可以避免万向锁问题；相比旋转矩阵，四元数只需要 4 个数，表达更加紧凑。因此，在自动驾驶感知、定位、融合、预测和控制模块中，四元数都非常常见。如果按照。

自动驾驶数据中出现四元数，本质上是因为系统需要描述三维空间中的旋转。但不同位置的四元数来源不同。

这个字段在 OpenScene / NAVSIM 中看起来像是后期整理出来的字段名，但它背后的姿态数据来自 nuPlan 的自车。这是因为 OpenScene / NAVSIM 会把 nuPlan 中的 ego pose 信息整理成自己的 metadata。nuPlan 中目标框相关的内容通常属于 object annotation 或 lidar box 一类，而。但是 nuPlan 的自车姿态四元数不是这个东西。它不是后期人工标注人员根据图像或点云框出来的。在 nuPlan 数据库中，自车姿态保存在。

nuPlan 是底层大规模真实驾驶数据和闭环规划基准；OpenScene 是基于 nuPlan 的轻量化、任务增强版数据集；NAVSIM 则是在 OpenScene 上构建的端到端驾驶评测框架/数据切分/非反应仿真 benchmark。名称角色和另外两个的关系nuPlan原始大规模真实驾驶规划数据集OpenScene 的上游来源OpenScenenuPlan 的压缩重分发 + occupancy/端到端任务数据NAVSIM 官方使用的数据基础NAVSIM端到端驾驶评测框架与 benchmark。

OpenScene 数据集OpenScene 数据集。

nuPlan 数据集nuPlan 数据集。

在 NAVSIM 的语境下，一个scene_name下包含的所有帧，并不一定就是一个训练 sample。scene_name 的所有帧≠ 一个 NAVSIM 训练 sampleNAVSIM Scene 对象≈ 一个训练 / 评测 sample从 log 中的连续帧序列里切出来的一个固定长度窗口，并进一步封装成 NAVSIM 的Scene对象。源码中Scene原始数据里的 scene_nameNAVSIM 源码里的 Scene 对象这两个概念不是同一个层级。

原始长时间采集记录│├── 可能被切成多个 log slice│││ ││ ││ │ └── token = 当前帧 token│ ││ │ └── token = 当前帧 token│ ││ │ └── token = 当前帧 token│ ││ └── ...│└── 另一个_log_name.pkl└── ...

在这里插入代码片。

根据代码库中的文档，这个文件名遵循 NAVSIM 数据集的日志命名规范，格式为：对 的解析如下：总结：由 28号采集车 在 2021年10月6日下午5点43分07秒 录制的日志，包含第 508 帧到第 877 帧，共 369 帧（约 184 秒，按 2Hz 帧率）。同样属于 子集。738 = 369 × 2，正好是两倍关系。原因在于文件名中的帧索引和 pickle 内部实际存储的帧率不同：从 的注释也可以印证：场景提取以 2Hz 为基准，所以文件名里的帧范围按 2Hz 编号（369 帧 ≈ 1