1. 课程导入

自动驾驶系统的研发链条可以粗略划分为“感知—决策—控制—验证”四个环节，而仿真验证是贯穿始终、成本占比极高的一环。要让仿真真正具备工程价值，前提是拥有一个可运行、可复现、可扩展的虚拟世界：道路几何、车道拓扑、交通标志、路口信号、静态障碍物、动态交通参与者，以及与之匹配的传感器视角。RoadRunner 正是 MathWorks 体系中承担“场景与道路建模”这一核心职责的工具，它把地图数据、道路设计意图和三维场景资产整合为可被仿真引擎直接消费的场景描述。

理解 RoadRunner 的定位，关键是把它放进整条工具链中去看，而不是孤立地把它当作一个“画路软件”。下面的信号链图展示了从原始地理数据到仿真场景、再到测试用例的完整数据流，RoadRunner 位于“场景构建”这一中枢位置。

一、核心原理：为什么需要专门的场景建模工具

仿真场景的本质是“对真实道路环境的结构化抽象”。如果直接用三维建模软件手工搭建，会面临三个难以回避的问题：几何精度难以保证（车道宽度、曲率半径、坡度不满足规范）、语义信息缺失（模型只有外形，没有车道连接关系与交通规则）、无法批量生成与参数化（每个场景都要重做）。RoadRunner 的设计思路是把“道路工程语义”前置：用户以车道、路口、标线、标志为基本操作单元，工具自动维护几何约束与拓扑连接，最终导出既含几何又含语义的场景描述。

从数据模型上看，RoadRunner 场景通常包含四层信息：

• 几何层：道路中心线、车道边界、路面高程与横坡；
• 拓扑层：车道之间的连接、路口转向关系、出入口；
• 语义层：车道类型、限速、交通标志、信号灯相位；
• 资产层：建筑、树木、护栏、路灯等三维模型及其摆放。

这四层信息共同决定了仿真中车辆能否“看懂”道路。缺少拓扑层，规划模块就无法完成路口决策；缺少语义层，感知模块的交通标志识别就没有真值可对齐。

二、方法流程：从零到可运行场景的典型路径

一个完整的 RoadRunner 场景工程通常遵循如下流程，建议在课程学习中反复对照这条主线：

1. 确定场景范围与精度要求：明确是高速、城市道路还是停车场，决定是否需要导入 GIS 或点云底图。
2. 建立道路骨架：绘制中心线，设置车道数与宽度，生成路面。
3. 构建路口与连接：处理交叉口、匝道汇入汇出，检查车道连通性。
4. 添加标线与标志：按规范布置车道线、停止线、导向箭头、限速牌。
5. 布置静态资产：建筑、绿化、护栏、路灯，注意与车道保持安全距离。
6. 配置信号与动态元素：信号灯相位、行人过街、动态车辆初始位姿。
7. 导出与验证：导出 RRHD、FBX 或 OpenDRIVE，在仿真引擎中加载并检查。

三、案例场景：一个城市十字路口的建模要点

以最常见的城市十字路口为例，RoadRunner 建模时需要重点关注以下参数与检查项：

在实操中，可以先用一段简单的导出配置检查场景是否完整：

# 导出 OpenDRIVE 时的典型检查项
export.format = "OpenDRIVE"
export.version = "1.6"
check.laneConnectivity = true
check.signalMapping   = true
check.assetClearance  = true

这些检查项并非 RoadRunner 的强制命令，而是工程实践中建议固化的自检清单。把它们写成脚本或检查表，可以显著降低返工率。

四、误区与复盘：初学者最容易踩的坑

误区一：把 RoadRunner 当成纯三维建模工具。实际上它的核心价值在语义与拓扑，外观只是附属。只追求“看起来像”，会导致仿真中车辆行为异常。

误区二：忽略坐标系与单位。导入 GIS 数据时若坐标系不匹配，道路会出现拉伸或偏移。建议在项目开始时就统一坐标参考与单位制。

误区三：一次性建太大场景。大场景加载慢、调试难。建议按“路口—路段—区域”分层构建，先保证单点正确，再拼接成网。

误区四：不做版本管理。场景文件会频繁修改，缺少版本管理会导致无法复现历史测试结果。建议将场景工程纳入 Git 或专用资产库。

五、学习目标与整体课程框架

本课程共 30 章，围绕“能建、能导、能验、能复用”四个能力目标展开。学习路径大致分为四个阶段：

• 基础阶段：界面认知、道路绘制、车道与标线、路口构建；
• 进阶阶段：信号配置、静态资产、动态元素、场景参数化；
• 工程阶段：导出格式、仿真引擎对接、传感器配置、批量场景生成；
• 实战阶段：典型场景复现、问题排查、场景库管理与团队协作。

学完本课程，你应当能够独立完成一个中等复杂度城市路网的建模与导出，并能在仿真引擎中验证其可用性。更重要的是，你会建立起“场景即测试资产”的工程意识——每一个场景都不是一次性的演示，而是可复用、可迭代、可度量的验证资源。