尧图网站建设 
先把结论丢在前面如果你打算靠深度强化学习、模仿学习或者 rule-based 方法做自动驾驶决策规划研究开箱即用的闭环仿真环境目前就两个选择——CARLA 和 NuPlan。CARLA 胜在传感器仿真和端到端感知但它的规划接口对规控算法研究者并不友好NuPlan 恰好相反它把 perception 那套东西全部抽离直接给你一个高保真的封闭道路环境和一套标准的 planner 评测流程。这篇笔记我结合自己在 Nuplan-devkit 上的实战经历把从零搭建环境、跑通第一个仿真实验以及在 PyCharm 里调试的完整过程记录下来。文中的所有步骤和踩坑点都来自我实际跑过的环境适合刚接触自动驾驶仿真、打算用 NuPlan 做规划算法研究的同学直接参考。1. Nuplan-devkit 到底解决什么问题——先说清楚再动手1.1 规划算法研究者的标准考场NuPlan 是 Motional 联合多家机构推出的自动驾驶规划 benchmark 平台。它和 CARLA、SUMO 这类通用仿真器的本质区别是NuPlan 只关心给定感知结果和路线意图planner 应该输出什么轨迹这个单一问题。我打个比方。CARLA 像是一个完整的驾校考场车感、灯光、路况全都要管NuPlan 则像是科目二的专用场地场地固定、规则清晰、评判标准明确你只需要专心练好几个规定动作就行。它的数据采集自波士顿、新加坡、拉斯维加斯等多个真实城市包含了大量老司机的人类驾驶轨迹这一点非常关键——这意味着你做模仿学习或者验证闭环规划算法时有一个高度真实的环境可以回放。从项目结构上看nuplan-devkit 的核心模块可以分四块NuPlanDB数据管理模块负责加载和解析大规模驾驶日志数据包括场景、地图、智能体状态、交通灯状态等。Simulation闭环仿真引擎负责将规划器的输出作用于虚拟环境推进环境状态更新。Planning规划器接口定义你可以在这里实现自己的算法或者调用官方提供的 baseline。Metrics评测模块官方定义了一系列量化指标从安全性、舒适性、效率等多个维度评估你的 planner 表现。1.2 为什么要用 Nuplan 而不是自己写个仿真器很多初学者觉得我可以用 SUMO 模拟交通流在自己的代码里做规划验证但我劝你尽早放弃这个念头。自己做仿真器最大的问题不是实现不了而是评判标准不被认可。你自建的场景、自定的打分逻辑写论文时审稿人不认横向对比时同行也没法复现。NuPlan 提供了 3000 多个带标注的场景这些场景可以自动划分 train/val/test 集配合官方的日志回放机制实验结果是可复现、可对比的。另外Nuplan-devkit 本身是用 Python PyTorch 写的这对做深度学习算法的同学太友好了。不需要碰 C不需要编译复杂的 ROS 节点只要懂 Python 就能改 planner、跑评测学习曲线比 CARLA 低一大截。1.3 我的选型理由和适用边界我选 Nuplan 的核心理由是它自带闭环评测能力。很多研究者在 CARLA 上做的所谓闭环实验其实只是把感知结果喂给规划器然后让规划器输出轨迹并没有一个统一的闭环反馈机制。NuPlan 的评测指标严格对齐了真实驾驶场景中的 safety 和 comfort例如碰撞检测、驾驶舒适度、限速遵守度还有一项很实用的make_progress专门检测车辆是不是在原地不动。它不适合什么场景呢如果做感知算法、传感器融合或者端到端的 vision-language 模型NuPlan 帮不上忙因为它的输入已经是结构化的 high-level 状态表示不涉及原始传感器数据。另外NuPlan 的仿真步长是 0.1 秒动力学模型相对简化做底盘控制层面的研究也不合适。理清这个边界之后你就能判断这个工具到底适不适合自己的方向。2. 环境准备一套真正省心的配置方案2.1 硬件门槛到底有多高很多同学一看是自动驾驶仿真下意识觉得需要 3090 起步。这里必须先纠正一个误区NuPlan 的规划仿真阶段不需要 GPU 渲染因为它的场景是结构化的不是图像流。做纯规划评测的时候CPU 就能跑官方建议 16G 内存以上实际测试 32G 会更舒服。但如果你要用它训练学习类 planner比如模仿学习或者强化学习那么一张 8G 显存的 GPU 就很有必要了。我自己的机器配置是i7-12700 32G 内存 RTX 3060 12G。实测下来跑一个 baseline 场景的闭环仿真CPU 模式大概 2 到 3 秒一个场景完全能接受。如果数据集的场景多批量跑评测时主要瓶颈是数据 I/O不是计算。2.2 Python 环境与依赖版本对不上就是灾难的开始Nuplan-devkit 官方支持的 Python 版本是 3.8 和 3.9。这看起来是个小细节但真的有人在这里卡住。我一开始用系统的 Python 3.10 直接装结果一堆依赖报错后来才意识到官方没有全面适配 3.10。强烈建议使用 Conda 管理环境原因有两点。一是environment.yml文件已经写好了所有依赖的版本直接conda env create -f就能一键建好环境省去逐个pip install的麻烦二是不同项目之间的隔离避免把系统 Python 环境搞得一团糟。官方environment.yml里核心依赖大致如下name: nuplan channels: - pytorch - conda-forge dependencies: - python3.9 - pip - pytorch1.13.1 - torchvision - pip: - -r requirements.txt这个文件会自动安装 PyTorch、bokeh、hydra-core、pandas、ipython 等一堆东西。有些依赖比较大比如 PyTorch下载慢很正常耐心等就好。提示如果你的网络环境访问 PyPI 或 Anaconda 官方源很慢建议先配置国内镜像源把 conda 的 channel 和 pip 的 index-url 都换掉能省下一大把时间。实测安装命令在基础环境干净的前提下整体耗时 20 分钟左右取决于网速。这里有个经验不要让 conda 和 pip 混着乱装有些依赖 conda 里有、有些只在 pip 里有官方 environment.yml 已经平衡好了。如果你发现缺少某个包优先用 pip 补装不要轻易升级或降级整个环境里的已有包否则很容易破坏依赖关系。2.3 数据集下载定位到官方 CDN 的完整过程环境装好了只是第一步真正占用时间的是数据集的下载。NuPlan 提供三种数据集mini、trainval和test。做学习和开发阶段mini就够了它是完整数据集的极小切片大约 1G 多包含几十个场景足够跑通流程。等算法成熟了再考虑下载完整数据集。官方推荐在项目根目录创建一个data文件夹然后下载压缩包解压到里面。完整的目录结构大致是nuplan-devkit ├── data │ └── nuplan │ ├── maps │ ├── mini │ └── splits ├── docs ├── nuplan ├── tutorial └── environment.yml注意maps文件夹里放的是 HD 地图数据一般几百 M必需要下载mini是仿真场景数据。这两个都缺一不可。我在第一次运行时就是因为没下载 maps结果程序一直报找不到地图文件排查了半天才发现是这个原因。3. 安装与首次运行从 clone 到跑通第一个场景3.1 克隆代码库与分支选择官方仓库地址是https://github.com/motional/nuplan-devkit.git。这里有一个关键建议不要直接 clone main 分支的最新代码优先选择带 tag 的稳定发布版本。因为 main 分支经常在更新有时候接口会变教程里的代码跑不通是常有的事。我个人用了v1.2版本整体比较稳定文档和示例代码都能对应上。命令很简单git clone --branch v1.2 https://github.com/motional/nuplan-devkit.git cd nuplan-devkit代码量不算小网络差的话可能需要一点时间。clone 完成后先不要急着装环境先确认environment.yml里面的 Python 版本跟你本机条件是否匹配。3.2 创建虚拟环境与安装依赖接下来创建 conda 环境conda env create -f environment.yml conda activate nuplan这一步会自动创建名为nuplan的 conda 环境并安装所有依赖。前面说过整个过程比较漫长而且中间如果某个包版本冲突会直接中断。我遇到过的比较典型的问题是torch1.13.1和某些 CUDA 版本不匹配在 conda 里安装时会出现 solver 卡死的情况。解决办法有两种用mamba替换 conda 作为包管理器速度快且解决冲突能力强conda install mamba -c conda-forge mamba env create -f environment.yml手动将environment.yml中的 PyTorch 改成 CPU 版本如果本机没有 NVIDIA GPU具体做法是把pytorch1.13.1替换成pytorch-cpu并指定对应的 channel。我个人建议能用 GPU 就用 GPU毕竟后面训练模型的时候用得上。但如果你是纯仿真评测不用学习类 plannerCPU 版也够用。3.3 验证核心包导入是否正常环境装好之后先做一个最快的 smoke testpython -c import nuplan; print(nuplan.__file__)如果能正常输出路径说明核心包安装没问题。接着再看一下hydra能不能正常导入因为 NuPlan 的配置文件全部基于 Hydra 管理这部分出错后面基本没法玩python -c from hydra import initialize; print(hydra ok)如果这两步都没问题就可以进入下一步尝试运行官方 tutorial 里的 Jupyter Notebook。tutorial目录下有官方提供的nuplan_tutorial.ipynb主要演示加载数据集、构建仿真场景、运行 planner 这整个流程。强烈建议先打开跑一遍能帮你快速理解整个平台的数据流和运行机制。3.4 首次运行时的关键配置项以 YAML 文件为例NuPlan 的每个实验配置都由 Hydra 的 YAML 文件管理。运行仿真实验时最简命令是python nuplan/planning/script/run_simulation.py \ simulationclosed_loop_nonreactive_agents \ plannersimple_planner \ scenario_buildernuplan_mini \ workersequential \ experiment_uidmy_first_exp这里我解释一下这几个参数都干了什么simulation选择仿真模式。closed_loop_nonreactive_agents意味着智能体不会对自车做激烈反应适合刚开始调试 planner 时使用。如果做更真实的测试后面可以换closed_loop_reactive_agents。planner选择规划器。simple_planner是官方写好的一个简单规则规划器只管往前走。修改为simple_vector_map_planner可以体验基于向量地图的规划。scenario_builder指定数据集的加载方式。nuplan_mini对应的是 mini 数据集。worker并行方式。sequential是单线程跑代码容易调试以后需要批量跑了可以换ray分布式模式。这个 YAML 配置体系初看有点绕但用顺手之后你会发现非常方便。把实验相关参数全剥离到配置里换数据集、换 planner、换场景都只是一行命令的事不需要动代码。3.5 第一次跑通看到的日志长什么样跑通后你会看到类似这样的输出[info] Building scenarios from database [info] Running simulation for scenario: 0000_... [info] Planner computed trajectory successfully [info] Metrics computed: ego_acceleration, ego_jerk, ...如果看到了Planner computed trajectory successfully说明整个链路已经通了。此时在输出目录下会生成.json或.parquet格式的仿真结果文件。很多人到这步就以为完事了其实远没有——你需要用官方提供的可视化工具把结果加载出来亲眼看到车辆轨迹、场景回放才算真正掌握这套工具。这个放到第 5 节说。4. PyCharm 配置技巧把 Nuplan 项目变成可调试的工程4.1 为什么要在 PyCharm 里跑而不是纯命令行很多资深研究者习惯命令行 VSCode但我个人强烈建议用 PyCharm 跑 Nuplan 项目原因有三个调试体验好。规划算法优化的时候最需要的就是在某个 step 打断点查看自车状态、障碍物信息、planner 输出的轨迹点。PyCharm 的断点调试和变量监视面板比命令行 print 大法效率高一个数量级。科学计算支持完善。PyCharm 专业版对 Jupyter、科学模式以及数组可视化的支持都很成熟numpy 数组可以直接在变量面板里以表格形式展开。代码导航方便。Nuplan-devkit 的源码有几十万行PyCharm 的跳到定义和全局搜索比 VSCode 更顺手很多时候顺着源码调用关系就能搞清楚某个参数是干什么用的。当然PyCharm 不便宜但社区版也足够完成调试和开发工作。这里我不提任何激活的灰色手段说实话写代码这件事没必要用破解版社区版免费且功能对你做 NuPlan 开发完全够用。4.2 正确配置 Conda 解释器的完整步骤用 PyCharm 打开 nuplan-devkit 根目录后第一步是配置 Python 解释器。在File Settings Project: nuplan-devkit Python Interpreter里点击齿轮图标选Add Interpreter Add Local Interpreter。在弹出的界面里选Conda Environment Existing Environment然后把 interpreter 路径指向你刚才创建的那个nuplan环境。在 Windows 上路径一般是C:\Users\用户名\anaconda3\envs\nuplan\python.exe在 macOS 或 Linux 上一般是~/anaconda3/envs/nuplan/bin/python很多同学在这里会犯一个错误直接选系统的python或base环境的解释器结果跑起来各种缺包但其实包都装在nuplan这个环境里。所以配置完后一定要确认 PyCharm 右下角显示的环境名称是nuplan而不是别的。4.3 设置工作目录与运行入口Nuplan 项目里有大量相对路径引用比如data/、exp/、output/这些路径默认以项目根目录为基准。直接用 PyCharm 右上角的运行按钮跑run_simulation.py时因为默认的工作目录可能不对经常会报FileNotFoundError。记住这个时候第一反应不应该是改代码而是改工作目录配置。在Run/Debug Configurations中选择当前运行的 Python 文件在Working directory一栏里填上 nuplan-devkit 的根目录绝对路径。这一步很多人忽略它比代码本身更能解决找不到文件的报错。另外建议在运行之前设置几个常用的环境变量比如NUPLAN_DATA_ROOT/path/to/nuplan-devkit/data NUPLAN_MAPS_ROOT/path/to/nuplan-devkit/data/maps这两个环境变量设置了之后代码里有些默认路径会直接读取这些值省去频繁修改 YAML 配置的麻烦。在 PyCharm 里可以通过设置Run Configuration的环境变量栏添加也可以在操作系统层面配置。4.4 让 PyCharm 认识 NuPlan 的第三方依赖与语法用 Conda 装完依赖后PyCharm 可能会对某些第三方包报找不到引用的红色波浪线这通常是因为索引还没有完全建立。等右下角的索引进度条跑完大部分警告会消失。如果还有个别包索引不到可以在File Invalidate Caches清理缓存后重启。更实用的一个技巧是先在 PyCharm 的 Python Console 里执行一次import nuplan确认解释器工作正常然后你在编辑 matplotlib、pandas 相关代码时代码补全和自动导入会顺畅很多。4.5 调试仿真的进程管理顺序执行和断点位置建议当你运行run_simulation.py时官方默认的workersequential模式下程序会一个场景一个场景地跑。如果场景数量多、仿真步数长你在 PyCharm 里直接按停止按钮可能会发现程序停不下来因为它正在跑循环。这时候更好的调试策略是先用scenario_count1这个配置参数限制只跑一个场景然后在这个场景上打断点调试。python nuplan/planning/script/run_simulation.py \ simulationclosed_loop_nonreactive_agents \ plannersimple_planner \ scenario_buildernuplan_mini \ workersequential \ scenario_count1 \ experiment_uiddebug_1scenario这样单场景调试的时候每一步的 planner 输出、自车状态、代价计算都能一步步跟效率高很多。等逻辑没问题了再拿掉这个参数批量跑。5. 数据流与核心接口不搞清楚这几点改 planner 必翻车5.1 NuPlan 场景数据的组织方式跑通 hello world 之后别急着换算法。先花半小时搞清楚 NuPlan 的数据流和组织形式后面能少走很多弯路。内存中最核心的数据结构是Scenario它代表一个时间片段里的完整交通环境。一个 scenario 包含地图信息Map API包括车道中心线、路口边界、停车线、限速等。智能体状态TrackedObjects所有在场景中出现的车辆、行人、骑行者的历史轨迹和状态。自车状态Ego State当前车辆的位置、朝向、速度、加速度。交通灯状态Traffic Light Status信号灯的相位和时序。在 NuPlan 的分层设计中规划器通常通过AbstractPlanner接口与仿真器交互。你需要实现的核心方法体大概长这样class MyPlanner(AbstractPlanner): def __init__(self, config): # 初始化参数、加载模型等 pass def compute_planner_trajectory( self, current_input: PlannerInput, ) - Trajectory: # 从 current_input 中获取历史数据 history current_input.history # 调用你的算法决策 waypoints self._plan(history) # 返回轨迹对象 return Trajectory(waypoints)5.2 PlannerInput 里装了什么这是整个接口最重要的输入。它包含两部分History随着仿真不断推进仿真器会把每一帧的自车状态、周围障碍物、地图信息缓存起来形成一个滑动窗口历史。你的 planner 拿到这个 history理论上可以访问到从场景开始到当前帧的所有信息。Future某些模式下才有非闭环评测模式下planner 可以看到未来 GT 轨迹用于开环评估。闭环模式下不会给你未来信息。很多初学同学容易混淆的一点是current_input.history拿到的障碍物信息已经是过去的状态如果你直接用最新一帧去规划需要自己在代码里提取history.observations的最后一帧同时注意坐标系是在全局坐标系还是相对坐标系。5.3 地图 API 调用时最容易犯的坐标系错误NuPlan 的坐标系一共有两种全局世界坐标系和相对自车坐标系。地图数据车道线、边界线用的是全局坐标而很多 planner 内部计算用的是相对坐标。我踩过一个很深的坑直接把地图上的车道中心线坐标当成自车周围的局部坐标去计算结果规划出来的轨迹完全跑偏。后来才发现官方在MapAPI里提供了get_nearest_centerline这样的方法它会返回一段离散化的车道中心线点列同时提供全局和局部两种坐标。你需要在拿到数据之后做一个显式的坐标变换# 从全局坐标转到自车局部坐标 ego_pose history.ego_states[-1].center global_points map_api.get_nearest_centerline(...) local_points global_points - ego_pose这个看起来很简单但就是有好多人在这一步翻车。我的建议是在写任何距离、朝向计算之前先打印一帧数据看一眼数值范围。全局坐标一般是几千到几万的大数自车局部坐标一般在 -100 到 100 的范围内一眼就能分辨出来。5.4 评测指标到底在测什么当你跑完一次仿真会得到很多 metrics或者也可以调用官方 eval 脚本计算。常用的核心指标包括Ego No Collision自车是否发生碰撞这是最重要的安全指标。如果碰撞了planner 基本不及格。Ego Time to CollisionTTC时间到碰撞是安全冗余度的量化数值越小说明时刻在悬崖边试探。Ego Jerk 和 Ego Acceleration舒适度指标。加加速度太大乘客会觉得顿挫。Progress自车在目标路径上走了多远。它和安全性一起看能判断一个 planner 是不是安全地原地不动避免规划器为了不撞车就直接停车。Traffic Light Adherence是否遵守红绿灯。自定义指标也不难官方把指标计算解耦成了独立的模块你可以继承MetricBase类实现自己的compute逻辑然后通过配置文件注册。这个后面可以做论文实验时再深入前期先把官方指标吃透就行。6. 避坑实录从环境到代码的六个高频报错修复6.1 scons 缺失导致的编译报错很多版本的环境里scons并没有被列为显式依赖但在某些地图工具或扩展包编译时需要用到。我遇到过一次报错信息是ImportError: No module named scons当时一头雾水因为 scons 通常是一个独立的构建工具不是 Python 库。排查链路先pip list | grep scons发现确实没装。然后pip install scons再重新运行报错消失。这个坑也提醒我一件事Nuplan-devkit 的依赖非常多且杂官方文档无法覆盖所有环境差异遇到缺啥就补啥别自己硬刚。6.2 pyarrow 版本冲突引发 dataset 加载失败用 mini 数据集跑仿真时如果报错涉及到pyarrow.lib.ArrowInvalid或者和 parquet 文件读取相关的异常基本都是 pyarrow 版本不对导致。NuPlan 的数据文件大量使用 parquet 格式存储pyarrow 就是底层读取引擎。我的处理办法是先把当前环境的 pyarrow 卸了重装pip uninstall pyarrow -y pip install pyarrow12.0.1版本号不用照抄以本地 conda 环境能解析为准。装好之后测试一下python -c import pyarrow.parquet as pq; print(ok)确认导入正常再跑仿真。6.3 bokeh 版本过新导致可视化接口失效可视化在 NuPlan 里是一个重头戏官方用了 bokeh 做轨迹和场景回放。新版本 bokeh 在 API 上有过一轮大改如果按官方文档调用旧版 API 而装的是新版 bokeh会出现AttributeError: module bokeh.models has no attribute Range1d之类的诡异报错排查起来非常迷惑。官方environment.yml会锁定一个相对保守的 bokeh 版本如果你自己乱升级过就会踩坑。解决办法是回退版本pip install bokeh2.4.3装完后重新加载 notebook 或者重启 PyCharm可视化就正常了。6.4 hydra 配置里找不到自定义 planner在run_simulation.py里通过plannerxxx指定 planner 时如果 hydra 提示找不到对应的配置说明你的 planner 类没有被注册到配置系统中。NuPlan 用hydra.main管理配置planner 的注册路径在nuplan/planning/script/configs下做结构映射。处理方法是把你的自定义 planner 文件放到规划器目录下同时确认在__init__.py里 import 了一次这样 hydra 在扫描配置时才能识别到。参考结构nuplan/planning/simulation/planner/ ├── __init__.py # 必须显式 import 你的类 ├── my_planner.py # 你的实现 └── simple_planner.py6.5 Jupyter 内核连不上已创建的 conda 环境官方 tutorial 是 Jupyter Notebook但如果你在 PyCharm 里直接打开.ipynb默认可能会选错内核导致 import nuplan 失败。解决办法是在终端里先激活 nuplan 环境然后做内核注册conda activate nuplan python -m ipykernel install --user --name nuplan然后回到 PyCharm 的 notebook 编辑界面在右上角选择内核nuplan重新执行即可。6.6 运行耗时过长先分清是 I/O 瓶颈还是计算瓶颈跑批量仿真时如果场景数一多就变得很慢需要学会判断瓶颈位置。最简单的做法先跑一个场景看耗时再跑十个场景看耗时如果几乎是线性增长那就是计算瓶颈如果从 1 个场景涨到 2 个场景耗时翻了四五倍大概率是数据加载和 I/O 占了主导。针对 I/O 瓶颈我亲测有效的两个方案把数据集放到 SSD 上不要放在机械硬盘。NuPlan 高频读 parquet 文件SSD 提升非常明显。用workerray替换workersequential让多个 worker 并行处理不同场景。但需要pip install ray并且注意内存要够。7. 可视化与实验管理从一坨结果中看出门道7.1 用官方 notebook 加载结果文件仿真跑完会在输出目录下生成很多中间产物其中最重要的是*.parquet文件记录了每一帧自车、障碍物的位置和状态。官方在tutorial里给了nuplan_tutorial.ipynb其中有专门的章节展示如何加载仿真结果和绘制回放。其实你还可以直接用pandas加载它看里面的数据结构import pandas as pd df pd.read_parquet(path/to/result.parquet) print(df.head())一般会有时间戳、自车 x/y、航向角、速度、加速度等列。这时候你可以用 matplotlib 画个简单的轨迹图快速检查 planner 的输出是否合理不用等官方可视化工具加载完效率高很多。7.2 官方 visualization 组件的使用限制官方也提供了更高级的可视化工具比如nuplan/planning/script/run_visualization.py它能渲染完整的地图、动态交通流和自车轨迹效果确实很酷。但实际操作中我遇到过几个限制一是渲染需要比较多的内存场景一多可能直接 OOM二是对某些型号的 GPU 在渲染模式下兼容性不好会报一些 OpenGL 相关的错误。如果你只是想快速抽查几个场景的效果建议还是优先用 matplotlib 静态画图或者用 bokeh 的自包含 HTML 导出功能。把轨迹画出来叠加在官方提供的地图上已经能覆盖 90% 的 debug 需求。7.3 实验命名的经验不要用默认 experiment_uid官方默认的experiment_uid是一串时间戳和随机数跑多了之后输出目录一多自己都分不清哪个是哪个。我的习惯是显式指定一个有意义的experiment_uid比如20250226_simple_planner_mini_test同时在输出目录里放一个config.yaml的备份这样每个实验都能回溯关键参数。按照 NuPlan 的默认设计experiment_uid会作为输出目录名目录下自动保存本次运行的 hydra 配置。这个习惯一旦养成后面做对比实验、写论文复现都会感谢当时的自己。8. 最后再分享三点实操心得第一个心得环境搭建不是一次性的而是贯穿整个项目周期的。别以为 Conda 环境建好之后就一劳永逸。NuPlan 的依赖库迭代很快不同版本的官方代码对第三方库的兼容性要求差异巨大。我在项目中期升级了一次 bokeh结果整个可视化模块全部报错花了大半天才回滚到稳定版本。所以如果你项目跑得正顺尽量不要频繁升级环境里的核心依赖。第二个心得跑仿真前先想清楚你要回答什么问题。NuPlan 提供了极丰富的场景库和评测指标但正因为丰富你很容易被各种 fancy 的实验带偏。刚开始做项目时先固定在最简单的场景配置和 baseline planner 上把整个实验闭环跑通再逐步增加复杂度。这个顺序反过来大概率会整天纠结在环境配置和 bug 上反而忘了最初要验证的算法假设。第三个心得批量跑实验前先在小规模数据集上做一次完整的 pre-check。我有一次直接提交了几百个场景的批量评测任务跑了两小时后才发现某个指标配置写错了所有结果作废重来。之后我学乖了每次批量跑之前都先在 mini 数据集上跑一个场景检查输出文件格式、指标数值范围是否合理再做全量实验。整体用下来Nuplan-devkit 是一套真正面向规划算法研究者的专业工具学习曲线不算平缓但一旦跑通对算法迭代速度和实验可信度的提升是实打实的。希望这篇实战笔记能帮你少踩几个坑把这套环境真正用起来。 自动驾驶规划仿真实战：NuPlan环境搭建与避坑全指南
先把结论丢在前面如果你打算靠深度强化学习、模仿学习或者 rule-based 方法做自动驾驶决策规划研究开箱即用的闭环仿真环境目前就两个选择——CARLA 和 NuPlan。CARLA 胜在传感器仿真和端到端感知但它的规划接口对规控算法研究者并不友好NuPlan 恰好相反它把 perception 那套东西全部抽离直接给你一个高保真的封闭道路环境和一套标准的 planner 评测流程。这篇笔记我结合自己在 Nuplan-devkit 上的实战经历把从零搭建环境、跑通第一个仿真实验以及在 PyCharm 里调试的完整过程记录下来。文中的所有步骤和踩坑点都来自我实际跑过的环境适合刚接触自动驾驶仿真、打算用 NuPlan 做规划算法研究的同学直接参考。1. Nuplan-devkit 到底解决什么问题——先说清楚再动手1.1 规划算法研究者的标准考场NuPlan 是 Motional 联合多家机构推出的自动驾驶规划 benchmark 平台。它和 CARLA、SUMO 这类通用仿真器的本质区别是NuPlan 只关心给定感知结果和路线意图planner 应该输出什么轨迹这个单一问题。我打个比方。CARLA 像是一个完整的驾校考场车感、灯光、路况全都要管NuPlan 则像是科目二的专用场地场地固定、规则清晰、评判标准明确你只需要专心练好几个规定动作就行。它的数据采集自波士顿、新加坡、拉斯维加斯等多个真实城市包含了大量老司机的人类驾驶轨迹这一点非常关键——这意味着你做模仿学习或者验证闭环规划算法时有一个高度真实的环境可以回放。从项目结构上看nuplan-devkit 的核心模块可以分四块NuPlanDB数据管理模块负责加载和解析大规模驾驶日志数据包括场景、地图、智能体状态、交通灯状态等。Simulation闭环仿真引擎负责将规划器的输出作用于虚拟环境推进环境状态更新。Planning规划器接口定义你可以在这里实现自己的算法或者调用官方提供的 baseline。Metrics评测模块官方定义了一系列量化指标从安全性、舒适性、效率等多个维度评估你的 planner 表现。1.2 为什么要用 Nuplan 而不是自己写个仿真器很多初学者觉得我可以用 SUMO 模拟交通流在自己的代码里做规划验证但我劝你尽早放弃这个念头。自己做仿真器最大的问题不是实现不了而是评判标准不被认可。你自建的场景、自定的打分逻辑写论文时审稿人不认横向对比时同行也没法复现。NuPlan 提供了 3000 多个带标注的场景这些场景可以自动划分 train/val/test 集配合官方的日志回放机制实验结果是可复现、可对比的。另外Nuplan-devkit 本身是用 Python PyTorch 写的这对做深度学习算法的同学太友好了。不需要碰 C不需要编译复杂的 ROS 节点只要懂 Python 就能改 planner、跑评测学习曲线比 CARLA 低一大截。1.3 我的选型理由和适用边界我选 Nuplan 的核心理由是它自带闭环评测能力。很多研究者在 CARLA 上做的所谓闭环实验其实只是把感知结果喂给规划器然后让规划器输出轨迹并没有一个统一的闭环反馈机制。NuPlan 的评测指标严格对齐了真实驾驶场景中的 safety 和 comfort例如碰撞检测、驾驶舒适度、限速遵守度还有一项很实用的make_progress专门检测车辆是不是在原地不动。它不适合什么场景呢如果做感知算法、传感器融合或者端到端的 vision-language 模型NuPlan 帮不上忙因为它的输入已经是结构化的 high-level 状态表示不涉及原始传感器数据。另外NuPlan 的仿真步长是 0.1 秒动力学模型相对简化做底盘控制层面的研究也不合适。理清这个边界之后你就能判断这个工具到底适不适合自己的方向。2. 环境准备一套真正省心的配置方案2.1 硬件门槛到底有多高很多同学一看是自动驾驶仿真下意识觉得需要 3090 起步。这里必须先纠正一个误区NuPlan 的规划仿真阶段不需要 GPU 渲染因为它的场景是结构化的不是图像流。做纯规划评测的时候CPU 就能跑官方建议 16G 内存以上实际测试 32G 会更舒服。但如果你要用它训练学习类 planner比如模仿学习或者强化学习那么一张 8G 显存的 GPU 就很有必要了。我自己的机器配置是i7-12700 32G 内存 RTX 3060 12G。实测下来跑一个 baseline 场景的闭环仿真CPU 模式大概 2 到 3 秒一个场景完全能接受。如果数据集的场景多批量跑评测时主要瓶颈是数据 I/O不是计算。2.2 Python 环境与依赖版本对不上就是灾难的开始Nuplan-devkit 官方支持的 Python 版本是 3.8 和 3.9。这看起来是个小细节但真的有人在这里卡住。我一开始用系统的 Python 3.10 直接装结果一堆依赖报错后来才意识到官方没有全面适配 3.10。强烈建议使用 Conda 管理环境原因有两点。一是environment.yml文件已经写好了所有依赖的版本直接conda env create -f就能一键建好环境省去逐个pip install的麻烦二是不同项目之间的隔离避免把系统 Python 环境搞得一团糟。官方environment.yml里核心依赖大致如下name: nuplan channels: - pytorch - conda-forge dependencies: - python3.9 - pip - pytorch1.13.1 - torchvision - pip: - -r requirements.txt这个文件会自动安装 PyTorch、bokeh、hydra-core、pandas、ipython 等一堆东西。有些依赖比较大比如 PyTorch下载慢很正常耐心等就好。提示如果你的网络环境访问 PyPI 或 Anaconda 官方源很慢建议先配置国内镜像源把 conda 的 channel 和 pip 的 index-url 都换掉能省下一大把时间。实测安装命令在基础环境干净的前提下整体耗时 20 分钟左右取决于网速。这里有个经验不要让 conda 和 pip 混着乱装有些依赖 conda 里有、有些只在 pip 里有官方 environment.yml 已经平衡好了。如果你发现缺少某个包优先用 pip 补装不要轻易升级或降级整个环境里的已有包否则很容易破坏依赖关系。2.3 数据集下载定位到官方 CDN 的完整过程环境装好了只是第一步真正占用时间的是数据集的下载。NuPlan 提供三种数据集mini、trainval和test。做学习和开发阶段mini就够了它是完整数据集的极小切片大约 1G 多包含几十个场景足够跑通流程。等算法成熟了再考虑下载完整数据集。官方推荐在项目根目录创建一个data文件夹然后下载压缩包解压到里面。完整的目录结构大致是nuplan-devkit ├── data │ └── nuplan │ ├── maps │ ├── mini │ └── splits ├── docs ├── nuplan ├── tutorial └── environment.yml注意maps文件夹里放的是 HD 地图数据一般几百 M必需要下载mini是仿真场景数据。这两个都缺一不可。我在第一次运行时就是因为没下载 maps结果程序一直报找不到地图文件排查了半天才发现是这个原因。3. 安装与首次运行从 clone 到跑通第一个场景3.1 克隆代码库与分支选择官方仓库地址是https://github.com/motional/nuplan-devkit.git。这里有一个关键建议不要直接 clone main 分支的最新代码优先选择带 tag 的稳定发布版本。因为 main 分支经常在更新有时候接口会变教程里的代码跑不通是常有的事。我个人用了v1.2版本整体比较稳定文档和示例代码都能对应上。命令很简单git clone --branch v1.2 https://github.com/motional/nuplan-devkit.git cd nuplan-devkit代码量不算小网络差的话可能需要一点时间。clone 完成后先不要急着装环境先确认environment.yml里面的 Python 版本跟你本机条件是否匹配。3.2 创建虚拟环境与安装依赖接下来创建 conda 环境conda env create -f environment.yml conda activate nuplan这一步会自动创建名为nuplan的 conda 环境并安装所有依赖。前面说过整个过程比较漫长而且中间如果某个包版本冲突会直接中断。我遇到过的比较典型的问题是torch1.13.1和某些 CUDA 版本不匹配在 conda 里安装时会出现 solver 卡死的情况。解决办法有两种用mamba替换 conda 作为包管理器速度快且解决冲突能力强conda install mamba -c conda-forge mamba env create -f environment.yml手动将environment.yml中的 PyTorch 改成 CPU 版本如果本机没有 NVIDIA GPU具体做法是把pytorch1.13.1替换成pytorch-cpu并指定对应的 channel。我个人建议能用 GPU 就用 GPU毕竟后面训练模型的时候用得上。但如果你是纯仿真评测不用学习类 plannerCPU 版也够用。3.3 验证核心包导入是否正常环境装好之后先做一个最快的 smoke testpython -c import nuplan; print(nuplan.__file__)如果能正常输出路径说明核心包安装没问题。接着再看一下hydra能不能正常导入因为 NuPlan 的配置文件全部基于 Hydra 管理这部分出错后面基本没法玩python -c from hydra import initialize; print(hydra ok)如果这两步都没问题就可以进入下一步尝试运行官方 tutorial 里的 Jupyter Notebook。tutorial目录下有官方提供的nuplan_tutorial.ipynb主要演示加载数据集、构建仿真场景、运行 planner 这整个流程。强烈建议先打开跑一遍能帮你快速理解整个平台的数据流和运行机制。3.4 首次运行时的关键配置项以 YAML 文件为例NuPlan 的每个实验配置都由 Hydra 的 YAML 文件管理。运行仿真实验时最简命令是python nuplan/planning/script/run_simulation.py \ simulationclosed_loop_nonreactive_agents \ plannersimple_planner \ scenario_buildernuplan_mini \ workersequential \ experiment_uidmy_first_exp这里我解释一下这几个参数都干了什么simulation选择仿真模式。closed_loop_nonreactive_agents意味着智能体不会对自车做激烈反应适合刚开始调试 planner 时使用。如果做更真实的测试后面可以换closed_loop_reactive_agents。planner选择规划器。simple_planner是官方写好的一个简单规则规划器只管往前走。修改为simple_vector_map_planner可以体验基于向量地图的规划。scenario_builder指定数据集的加载方式。nuplan_mini对应的是 mini 数据集。worker并行方式。sequential是单线程跑代码容易调试以后需要批量跑了可以换ray分布式模式。这个 YAML 配置体系初看有点绕但用顺手之后你会发现非常方便。把实验相关参数全剥离到配置里换数据集、换 planner、换场景都只是一行命令的事不需要动代码。3.5 第一次跑通看到的日志长什么样跑通后你会看到类似这样的输出[info] Building scenarios from database [info] Running simulation for scenario: 0000_... [info] Planner computed trajectory successfully [info] Metrics computed: ego_acceleration, ego_jerk, ...如果看到了Planner computed trajectory successfully说明整个链路已经通了。此时在输出目录下会生成.json或.parquet格式的仿真结果文件。很多人到这步就以为完事了其实远没有——你需要用官方提供的可视化工具把结果加载出来亲眼看到车辆轨迹、场景回放才算真正掌握这套工具。这个放到第 5 节说。4. PyCharm 配置技巧把 Nuplan 项目变成可调试的工程4.1 为什么要在 PyCharm 里跑而不是纯命令行很多资深研究者习惯命令行 VSCode但我个人强烈建议用 PyCharm 跑 Nuplan 项目原因有三个调试体验好。规划算法优化的时候最需要的就是在某个 step 打断点查看自车状态、障碍物信息、planner 输出的轨迹点。PyCharm 的断点调试和变量监视面板比命令行 print 大法效率高一个数量级。科学计算支持完善。PyCharm 专业版对 Jupyter、科学模式以及数组可视化的支持都很成熟numpy 数组可以直接在变量面板里以表格形式展开。代码导航方便。Nuplan-devkit 的源码有几十万行PyCharm 的跳到定义和全局搜索比 VSCode 更顺手很多时候顺着源码调用关系就能搞清楚某个参数是干什么用的。当然PyCharm 不便宜但社区版也足够完成调试和开发工作。这里我不提任何激活的灰色手段说实话写代码这件事没必要用破解版社区版免费且功能对你做 NuPlan 开发完全够用。4.2 正确配置 Conda 解释器的完整步骤用 PyCharm 打开 nuplan-devkit 根目录后第一步是配置 Python 解释器。在File Settings Project: nuplan-devkit Python Interpreter里点击齿轮图标选Add Interpreter Add Local Interpreter。在弹出的界面里选Conda Environment Existing Environment然后把 interpreter 路径指向你刚才创建的那个nuplan环境。在 Windows 上路径一般是C:\Users\用户名\anaconda3\envs\nuplan\python.exe在 macOS 或 Linux 上一般是~/anaconda3/envs/nuplan/bin/python很多同学在这里会犯一个错误直接选系统的python或base环境的解释器结果跑起来各种缺包但其实包都装在nuplan这个环境里。所以配置完后一定要确认 PyCharm 右下角显示的环境名称是nuplan而不是别的。4.3 设置工作目录与运行入口Nuplan 项目里有大量相对路径引用比如data/、exp/、output/这些路径默认以项目根目录为基准。直接用 PyCharm 右上角的运行按钮跑run_simulation.py时因为默认的工作目录可能不对经常会报FileNotFoundError。记住这个时候第一反应不应该是改代码而是改工作目录配置。在Run/Debug Configurations中选择当前运行的 Python 文件在Working directory一栏里填上 nuplan-devkit 的根目录绝对路径。这一步很多人忽略它比代码本身更能解决找不到文件的报错。另外建议在运行之前设置几个常用的环境变量比如NUPLAN_DATA_ROOT/path/to/nuplan-devkit/data NUPLAN_MAPS_ROOT/path/to/nuplan-devkit/data/maps这两个环境变量设置了之后代码里有些默认路径会直接读取这些值省去频繁修改 YAML 配置的麻烦。在 PyCharm 里可以通过设置Run Configuration的环境变量栏添加也可以在操作系统层面配置。4.4 让 PyCharm 认识 NuPlan 的第三方依赖与语法用 Conda 装完依赖后PyCharm 可能会对某些第三方包报找不到引用的红色波浪线这通常是因为索引还没有完全建立。等右下角的索引进度条跑完大部分警告会消失。如果还有个别包索引不到可以在File Invalidate Caches清理缓存后重启。更实用的一个技巧是先在 PyCharm 的 Python Console 里执行一次import nuplan确认解释器工作正常然后你在编辑 matplotlib、pandas 相关代码时代码补全和自动导入会顺畅很多。4.5 调试仿真的进程管理顺序执行和断点位置建议当你运行run_simulation.py时官方默认的workersequential模式下程序会一个场景一个场景地跑。如果场景数量多、仿真步数长你在 PyCharm 里直接按停止按钮可能会发现程序停不下来因为它正在跑循环。这时候更好的调试策略是先用scenario_count1这个配置参数限制只跑一个场景然后在这个场景上打断点调试。python nuplan/planning/script/run_simulation.py \ simulationclosed_loop_nonreactive_agents \ plannersimple_planner \ scenario_buildernuplan_mini \ workersequential \ scenario_count1 \ experiment_uiddebug_1scenario这样单场景调试的时候每一步的 planner 输出、自车状态、代价计算都能一步步跟效率高很多。等逻辑没问题了再拿掉这个参数批量跑。5. 数据流与核心接口不搞清楚这几点改 planner 必翻车5.1 NuPlan 场景数据的组织方式跑通 hello world 之后别急着换算法。先花半小时搞清楚 NuPlan 的数据流和组织形式后面能少走很多弯路。内存中最核心的数据结构是Scenario它代表一个时间片段里的完整交通环境。一个 scenario 包含地图信息Map API包括车道中心线、路口边界、停车线、限速等。智能体状态TrackedObjects所有在场景中出现的车辆、行人、骑行者的历史轨迹和状态。自车状态Ego State当前车辆的位置、朝向、速度、加速度。交通灯状态Traffic Light Status信号灯的相位和时序。在 NuPlan 的分层设计中规划器通常通过AbstractPlanner接口与仿真器交互。你需要实现的核心方法体大概长这样class MyPlanner(AbstractPlanner): def __init__(self, config): # 初始化参数、加载模型等 pass def compute_planner_trajectory( self, current_input: PlannerInput, ) - Trajectory: # 从 current_input 中获取历史数据 history current_input.history # 调用你的算法决策 waypoints self._plan(history) # 返回轨迹对象 return Trajectory(waypoints)5.2 PlannerInput 里装了什么这是整个接口最重要的输入。它包含两部分History随着仿真不断推进仿真器会把每一帧的自车状态、周围障碍物、地图信息缓存起来形成一个滑动窗口历史。你的 planner 拿到这个 history理论上可以访问到从场景开始到当前帧的所有信息。Future某些模式下才有非闭环评测模式下planner 可以看到未来 GT 轨迹用于开环评估。闭环模式下不会给你未来信息。很多初学同学容易混淆的一点是current_input.history拿到的障碍物信息已经是过去的状态如果你直接用最新一帧去规划需要自己在代码里提取history.observations的最后一帧同时注意坐标系是在全局坐标系还是相对坐标系。5.3 地图 API 调用时最容易犯的坐标系错误NuPlan 的坐标系一共有两种全局世界坐标系和相对自车坐标系。地图数据车道线、边界线用的是全局坐标而很多 planner 内部计算用的是相对坐标。我踩过一个很深的坑直接把地图上的车道中心线坐标当成自车周围的局部坐标去计算结果规划出来的轨迹完全跑偏。后来才发现官方在MapAPI里提供了get_nearest_centerline这样的方法它会返回一段离散化的车道中心线点列同时提供全局和局部两种坐标。你需要在拿到数据之后做一个显式的坐标变换# 从全局坐标转到自车局部坐标 ego_pose history.ego_states[-1].center global_points map_api.get_nearest_centerline(...) local_points global_points - ego_pose这个看起来很简单但就是有好多人在这一步翻车。我的建议是在写任何距离、朝向计算之前先打印一帧数据看一眼数值范围。全局坐标一般是几千到几万的大数自车局部坐标一般在 -100 到 100 的范围内一眼就能分辨出来。5.4 评测指标到底在测什么当你跑完一次仿真会得到很多 metrics或者也可以调用官方 eval 脚本计算。常用的核心指标包括Ego No Collision自车是否发生碰撞这是最重要的安全指标。如果碰撞了planner 基本不及格。Ego Time to CollisionTTC时间到碰撞是安全冗余度的量化数值越小说明时刻在悬崖边试探。Ego Jerk 和 Ego Acceleration舒适度指标。加加速度太大乘客会觉得顿挫。Progress自车在目标路径上走了多远。它和安全性一起看能判断一个 planner 是不是安全地原地不动避免规划器为了不撞车就直接停车。Traffic Light Adherence是否遵守红绿灯。自定义指标也不难官方把指标计算解耦成了独立的模块你可以继承MetricBase类实现自己的compute逻辑然后通过配置文件注册。这个后面可以做论文实验时再深入前期先把官方指标吃透就行。6. 避坑实录从环境到代码的六个高频报错修复6.1 scons 缺失导致的编译报错很多版本的环境里scons并没有被列为显式依赖但在某些地图工具或扩展包编译时需要用到。我遇到过一次报错信息是ImportError: No module named scons当时一头雾水因为 scons 通常是一个独立的构建工具不是 Python 库。排查链路先pip list | grep scons发现确实没装。然后pip install scons再重新运行报错消失。这个坑也提醒我一件事Nuplan-devkit 的依赖非常多且杂官方文档无法覆盖所有环境差异遇到缺啥就补啥别自己硬刚。6.2 pyarrow 版本冲突引发 dataset 加载失败用 mini 数据集跑仿真时如果报错涉及到pyarrow.lib.ArrowInvalid或者和 parquet 文件读取相关的异常基本都是 pyarrow 版本不对导致。NuPlan 的数据文件大量使用 parquet 格式存储pyarrow 就是底层读取引擎。我的处理办法是先把当前环境的 pyarrow 卸了重装pip uninstall pyarrow -y pip install pyarrow12.0.1版本号不用照抄以本地 conda 环境能解析为准。装好之后测试一下python -c import pyarrow.parquet as pq; print(ok)确认导入正常再跑仿真。6.3 bokeh 版本过新导致可视化接口失效可视化在 NuPlan 里是一个重头戏官方用了 bokeh 做轨迹和场景回放。新版本 bokeh 在 API 上有过一轮大改如果按官方文档调用旧版 API 而装的是新版 bokeh会出现AttributeError: module bokeh.models has no attribute Range1d之类的诡异报错排查起来非常迷惑。官方environment.yml会锁定一个相对保守的 bokeh 版本如果你自己乱升级过就会踩坑。解决办法是回退版本pip install bokeh2.4.3装完后重新加载 notebook 或者重启 PyCharm可视化就正常了。6.4 hydra 配置里找不到自定义 planner在run_simulation.py里通过plannerxxx指定 planner 时如果 hydra 提示找不到对应的配置说明你的 planner 类没有被注册到配置系统中。NuPlan 用hydra.main管理配置planner 的注册路径在nuplan/planning/script/configs下做结构映射。处理方法是把你的自定义 planner 文件放到规划器目录下同时确认在__init__.py里 import 了一次这样 hydra 在扫描配置时才能识别到。参考结构nuplan/planning/simulation/planner/ ├── __init__.py # 必须显式 import 你的类 ├── my_planner.py # 你的实现 └── simple_planner.py6.5 Jupyter 内核连不上已创建的 conda 环境官方 tutorial 是 Jupyter Notebook但如果你在 PyCharm 里直接打开.ipynb默认可能会选错内核导致 import nuplan 失败。解决办法是在终端里先激活 nuplan 环境然后做内核注册conda activate nuplan python -m ipykernel install --user --name nuplan然后回到 PyCharm 的 notebook 编辑界面在右上角选择内核nuplan重新执行即可。6.6 运行耗时过长先分清是 I/O 瓶颈还是计算瓶颈跑批量仿真时如果场景数一多就变得很慢需要学会判断瓶颈位置。最简单的做法先跑一个场景看耗时再跑十个场景看耗时如果几乎是线性增长那就是计算瓶颈如果从 1 个场景涨到 2 个场景耗时翻了四五倍大概率是数据加载和 I/O 占了主导。针对 I/O 瓶颈我亲测有效的两个方案把数据集放到 SSD 上不要放在机械硬盘。NuPlan 高频读 parquet 文件SSD 提升非常明显。用workerray替换workersequential让多个 worker 并行处理不同场景。但需要pip install ray并且注意内存要够。7. 可视化与实验管理从一坨结果中看出门道7.1 用官方 notebook 加载结果文件仿真跑完会在输出目录下生成很多中间产物其中最重要的是*.parquet文件记录了每一帧自车、障碍物的位置和状态。官方在tutorial里给了nuplan_tutorial.ipynb其中有专门的章节展示如何加载仿真结果和绘制回放。其实你还可以直接用pandas加载它看里面的数据结构import pandas as pd df pd.read_parquet(path/to/result.parquet) print(df.head())一般会有时间戳、自车 x/y、航向角、速度、加速度等列。这时候你可以用 matplotlib 画个简单的轨迹图快速检查 planner 的输出是否合理不用等官方可视化工具加载完效率高很多。7.2 官方 visualization 组件的使用限制官方也提供了更高级的可视化工具比如nuplan/planning/script/run_visualization.py它能渲染完整的地图、动态交通流和自车轨迹效果确实很酷。但实际操作中我遇到过几个限制一是渲染需要比较多的内存场景一多可能直接 OOM二是对某些型号的 GPU 在渲染模式下兼容性不好会报一些 OpenGL 相关的错误。如果你只是想快速抽查几个场景的效果建议还是优先用 matplotlib 静态画图或者用 bokeh 的自包含 HTML 导出功能。把轨迹画出来叠加在官方提供的地图上已经能覆盖 90% 的 debug 需求。7.3 实验命名的经验不要用默认 experiment_uid官方默认的experiment_uid是一串时间戳和随机数跑多了之后输出目录一多自己都分不清哪个是哪个。我的习惯是显式指定一个有意义的experiment_uid比如20250226_simple_planner_mini_test同时在输出目录里放一个config.yaml的备份这样每个实验都能回溯关键参数。按照 NuPlan 的默认设计experiment_uid会作为输出目录名目录下自动保存本次运行的 hydra 配置。这个习惯一旦养成后面做对比实验、写论文复现都会感谢当时的自己。8. 最后再分享三点实操心得第一个心得环境搭建不是一次性的而是贯穿整个项目周期的。别以为 Conda 环境建好之后就一劳永逸。NuPlan 的依赖库迭代很快不同版本的官方代码对第三方库的兼容性要求差异巨大。我在项目中期升级了一次 bokeh结果整个可视化模块全部报错花了大半天才回滚到稳定版本。所以如果你项目跑得正顺尽量不要频繁升级环境里的核心依赖。第二个心得跑仿真前先想清楚你要回答什么问题。NuPlan 提供了极丰富的场景库和评测指标但正因为丰富你很容易被各种 fancy 的实验带偏。刚开始做项目时先固定在最简单的场景配置和 baseline planner 上把整个实验闭环跑通再逐步增加复杂度。这个顺序反过来大概率会整天纠结在环境配置和 bug 上反而忘了最初要验证的算法假设。第三个心得批量跑实验前先在小规模数据集上做一次完整的 pre-check。我有一次直接提交了几百个场景的批量评测任务跑了两小时后才发现某个指标配置写错了所有结果作废重来。之后我学乖了每次批量跑之前都先在 mini 数据集上跑一个场景检查输出文件格式、指标数值范围是否合理再做全量实验。整体用下来Nuplan-devkit 是一套真正面向规划算法研究者的专业工具学习曲线不算平缓但一旦跑通对算法迭代速度和实验可信度的提升是实打实的。希望这篇实战笔记能帮你少踩几个坑把这套环境真正用起来。