企业官网建设流程全解析

1. 规划模块到底在自动驾驶里扮演什么角色

很多人第一次接触自动驾驶系统时，注意力往往被感知模块吸引——激光雷达点云、摄像头图像、目标检测框，这些视觉化的东西确实抓眼球。但真正决定一辆车“怎么走”的，其实是规划模块。感知告诉你周围有什么，规划告诉你接下来几秒钟方向盘打多少、油门踩多深、刹车什么时候点。它是整个系统从“看见”到“行动”的桥梁。

我接触Apollo这套开源自动驾驶框架有一段时间了，规划模块是我花精力最多的部分。原因很简单：感知模块的评估指标相对客观，mAP、召回率这些数字摆在那里；控制模块也有成熟的PID和MPC理论支撑。唯独规划，它既要处理复杂的道路拓扑，又要应对动态障碍物的博弈，还得兼顾乘坐舒适性，几乎是一个多目标优化问题的大杂烩。

这篇文章面向的读者，是那些已经对自动驾驶有基本认知、想深入理解规划模块内部运作机制的人。不管你是刚入行的算法工程师，还是做机器人方向想迁移到自动驾驶的学生，又或者是负责系统集成的工程人员，我都会尽量把Apollo规划模块的设计思路、核心算法、实操配置和踩坑经验讲清楚。全文基于我自己的项目实践和源码阅读经验，涉及具体参数的地方我会说明取值逻辑，但不会照搬某个特定版本的默认配置——因为版本迭代太快，理解原理比记住数字重要得多。

Apollo的规划模块在整个架构中处于中间层。上游是感知和预测，下游是控制。感知给出障碍物信息，预测给出未来若干秒的轨迹估计，规划则综合这些信息、高精地图、路由信息，生成一条安全、舒适、合法的行驶轨迹。这条轨迹通常包含位置、速度、加速度、时间戳等信息，控制模块再根据它计算具体的执行器指令。

规划模块要解决的问题可以拆成几个层次。最上层是路由规划，决定从起点到终点走哪条路，这个通常在导航层面完成。中间层是行为决策，比如当前该跟车、换道、超车还是避让。最底层是运动规划，生成具体的轨迹点。Apollo的规划模块主要聚焦在后两层，尤其是运动规划。

为什么规划这么难？因为自动驾驶面对的是一个动态、不确定、多智能体交互的环境。人类驾驶员开车时，很多决策是下意识的，不需要显式建模。但机器不行，它必须把每一个决策都变成可计算的问题。跟车距离多少算安全？换道时后车会不会加速？前方车辆突然刹车怎么办？这些问题在数学上都没有唯一解，只能通过工程手段不断逼近一个“足够好”的方案。

Apollo规划模块的核心设计哲学是“场景驱动”。什么意思呢？它不试图用一个统一的算法解决所有问题，而是把驾驶过程拆分成一个个具体的场景——车道跟随、换道、借道避让、路口通行、泊车等等。每个场景有自己的决策逻辑和轨迹生成策略，场景之间通过状态机切换。这种设计的好处是每个场景可以独立优化，坏处是场景之间的切换逻辑容易出问题，边界情况特别多。

我个人的体会是，理解Apollo规划模块，关键不是去背某个算法的公式，而是理解它的分层架构和场景管理机制。一旦你把这两条线理清楚，再看具体的轨迹生成算法，就会觉得顺理成章。

2. 规划模块的整体架构与核心思路拆解

2.1 分层架构：从路由到轨迹的完整链路

Apollo规划模块的架构可以粗略分为四层。第一层是路由规划，它接收起点和终点，基于高精地图生成一条全局路径。这一层通常不涉及动态障碍物，纯粹是图搜索问题。第二层是行为决策层，它根据当前场景、交通规则、障碍物信息，决定车辆应该采取什么行为。第三层是轨迹生成层，根据决策结果生成具体的轨迹。第四层是轨迹评估与选择层，当有多条候选轨迹时，选出最优的一条。

这四层之间是逐级细化的关系。路由规划给出的是车道级别的路径，行为决策把它细化成“在当前车道跟车”或“换到左侧车道”这样的指令，轨迹生成再把它变成带时间戳的轨迹点，轨迹评估最后做一次安全性和舒适性校验。

为什么要分这么多层？因为每一层解决的问题性质不同。路由规划是离散的图搜索，行为决策是离散的状态选择，轨迹生成是连续优化，轨迹评估是多指标排序。把它们混在一起会导致问题维度爆炸，既不好调试也不好优化。

2.2 场景驱动：为什么不用一个算法打天下

Apollo规划模块最显著的特征是场景管理。它把驾驶过程拆成若干典型场景，每个场景有独立的处理逻辑。常见的场景包括：车道跟随、换道、借道避让、路口通行、人行横道通行、泊车、靠边停车等。

这种设计的逻辑基础是：不同场景下的约束条件和优化目标差异太大，用统一算法很难兼顾。比如车道跟随主要考虑跟车距离和速度平滑，换道则要额外考虑目标车道的前后车距离和换道时机，路口通行又要处理交通灯和交叉车流。如果强行用一个算法覆盖所有场景，要么约束条件复杂到无法求解，要么求解出来的轨迹在某些场景下表现很差。

场景驱动的另一个好处是可解释性强。当规划结果出现问题时，你可以快速定位到是哪个场景的逻辑出了问题，而不是面对一个黑盒模型无从下手。这在功能安全要求极高的自动驾驶领域非常重要。

但场景驱动也有代价。最大的问题是场景切换的边界处理。比如车辆从车道跟随切换到换道，什么时机切换？切换过程中如果换道条件突然不满足了怎么办？这些边界情况往往是bug的重灾区。Apollo的做法是引入场景状态机和场景优先级，但即便如此，实际调试中仍然需要大量测试来覆盖各种边界。

2.3 参考线：规划问题的降维利器

Apollo规划模块里有一个非常关键的概念叫参考线。简单说，参考线就是一条平滑的、以车辆当前位置为起点的局部路径，它通常沿着当前车道的中心线生成，但也会根据障碍物和决策结果做调整。

参考线的作用是把二维的规划问题降维成一维。车辆在参考线上的位置用纵向位移s表示，垂直于参考线的偏移用横向位移l表示。这样轨迹规划就变成了在s-l坐标系下的优化问题，复杂度大大降低。

为什么可以这样降维？因为绝大多数驾驶场景下，车辆都是沿着道路方向行驶的，横向偏移不会太大。用参考线作为基准，可以把问题分解成纵向的速度规划和横向的路径规划，两者可以独立优化再合成。这比直接在笛卡尔坐标系下做二维优化要高效得多。

参考线的生成和维护是规划模块的基础工作。它需要从高精地图中提取车道中心线，做平滑处理，然后根据车辆位置截取一段。参考线的质量直接影响后续规划的效果。如果参考线不平滑，轨迹就会抖动；如果参考线太短，规划视野就不够。

2.4 决策与规划的耦合关系

在Apollo的架构里，决策和规划是分开的，但耦合非常紧密。决策模块输出的是一个抽象的指令，比如“跟车”、“换道”、“避让”，规划模块根据这些指令生成具体轨迹。但决策模块在做判断时，又需要依赖规划模块提供的可行性信息。

举个例子，决策模块决定要换道，但它怎么知道换道是否安全？它需要规划模块生成一条换道轨迹，然后评估这条轨迹是否与障碍物冲突。如果冲突，决策模块就要放弃换道。这就形成了一个反馈循环。

这种耦合关系在实际工程中需要小心处理。如果决策太激进，规划可能生成不安全的轨迹；如果决策太保守，车辆可能一直不敢换道，影响通行效率。Apollo通过场景优先级和代价函数来平衡，但参数调优仍然需要大量实车测试。

3. 核心算法与实操要点解析

3.1 路径规划：从A到B的几何问题

路径规划解决的是“走什么形状的线”的问题，不涉及时间维度。Apollo中常见的路径规划方法包括基于采样的方法和基于优化的方法。

基于采样的方法，比如Lattice Planner，会生成一组候选路径，然后用代价函数评估选最优。候选路径的生成方式通常是在参考线基础上做横向偏移，偏移量按一定间隔采样。比如横向偏移从-2米到+2米，每隔0.5米采样一条，就得到9条候选路径。每条路径再用多项式或样条曲线平滑。

这种方法的优点是实现简单、鲁棒性好，因为候选路径覆盖了各种可能性，总能找到一条可行的。缺点是计算量大，采样密度和计算量成正比，而且生成的路径不一定是最优的，只是在采样集合里最优。

基于优化的方法则把路径规划变成一个数学优化问题。目标函数通常包含平滑度、与参考线的偏差、与障碍物的距离等项，约束条件包括车辆运动学限制、道路边界等。求解方法有二次规划、非线性优化等。

优化方法的优点是理论上可以找到最优解，而且可以显式地加入各种约束。缺点是求解可能失败，尤其是约束冲突时。另外，优化问题的凸性也很难保证，非凸问题容易陷入局部最优。

Apollo实际使用的是混合策略：先用采样生成粗略的候选路径，再用优化做精细调整。这样既保证了鲁棒性，又提高了路径质量。

实操中，路径规划有几个关键参数需要注意。横向采样间隔决定了路径的精细程度，太小会导致计算量激增，太大可能漏掉可行解。通常城市道路用0.3到0.5米，高速可以用1米。路径平滑的权重需要根据车辆特性调整，权重太大路径会过于保守，太小则可能抖动。

3.2 速度规划：时间维度上的决策

速度规划解决的是“以什么速度走”的问题。它通常和路径规划解耦，在给定的路径上做纵向速度优化。Apollo的速度规划主要考虑几个因素：与前车的距离、限速、交通灯、舒适性约束。

速度规划的核心是生成一条速度曲线，通常用s-t图表示。横轴是时间，纵轴是纵向位移。速度曲线就是s-t图上的一条曲线，斜率就是速度。速度规划的目标是在满足约束的前提下，让这条曲线尽可能平滑、高效。

Apollo的速度规划常用动态规划加二次规划的组合。动态规划先在离散的s-t网格上搜索一条粗略的速度曲线，考虑障碍物约束和速度限制。然后二次规划在动态规划结果附近做精细优化，加入加速度、加加速度的平滑项。

动态规划的好处是能处理非凸约束，比如障碍物在s-t图上的投影可能形成复杂的可行域。但动态规划的精度受网格分辨率限制，太粗会不准确，太细计算量爆炸。二次规划则能在局部做精确优化，但需要动态规划提供一个好的初始解。

速度规划中最棘手的是动态障碍物的处理。预测模块给出障碍物的未来轨迹后，需要把它投影到s-t图上，形成一条“障碍物带”。速度曲线不能穿过这条带。如果障碍物带把可行域切断了，就需要决策模块介入，比如换道或减速让行。

实操中，速度规划的舒适性约束很关键。加速度通常限制在2到3米每二次方秒，加加速度限制在2到5米每三次方秒。这些值直接影响乘坐体验。太激进乘客会晕车，太保守通行效率低。我试过把加加速度限制从3降到1.5，乘坐舒适性明显提升，但同样的路况下通行时间增加了约15%。

3.3 轨迹生成中的多项式与样条

Apollo轨迹生成大量使用多项式曲线。最常见的是五次多项式，因为它可以同时约束位置、速度、加速度的边界条件。比如换道轨迹，已知起点和终点的位置、速度、加速度，就可以用五次多项式拟合出一条平滑曲线。

五次多项式的形式是：位置关于时间的函数，最高次项是五次。为什么是五次？因为位置、速度、加速度三个量在起点和终点各有一个约束，总共六个约束，正好确定六个系数。如果只用三次多项式，只能约束位置和速度，加速度不连续，乘坐体验差。

但五次多项式也有问题。它假设整条轨迹用一个多项式描述，对于长距离或复杂场景，一个多项式可能不够灵活。这时候会用分段多项式或样条曲线。样条曲线在分段点处保证一定阶数的连续性，比如C2连续意味着加速度连续。

Apollo中还有一种常用的曲线叫螺旋线，它的曲率关于弧长是线性变化的。螺旋线的好处是曲率连续，适合生成平滑的转弯轨迹。在泊车和窄路掉头场景中，螺旋线用得比较多。

实操中，多项式系数的求解是一个线性方程组问题，可以用矩阵运算快速求解。但要注意数值稳定性，时间跨度太大时，高次项会引入数值误差。通常单段多项式的时间跨度不超过8秒，再长就要分段。

3.4 障碍物处理与借道避让逻辑

障碍物处理是规划模块最复杂的部分之一。Apollo把障碍物分为静态和动态两类，处理方式不同。静态障碍物主要是路沿、锥桶、停放的车辆等，动态障碍物包括行驶中的车辆、行人、自行车等。

对于静态障碍物，规划模块需要判断它是否在路径上，如果是，就要生成避让路径。避让路径的生成通常是在参考线基础上做横向偏移，偏移量要保证与障碍物有足够的安全距离。安全距离的取值要考虑车辆宽度、障碍物宽度、以及一定的余量。通常余量取0.3到0.5米。

动态障碍物的处理更复杂，因为它的位置随时间变化。Apollo的做法是把动态障碍物的预测轨迹投影到s-t图和s-l图上，形成时空约束。速度规划在s-t图上避开障碍物，路径规划在s-l图上避开障碍物。

借道避让是一个典型场景。当本车道前方有慢速车辆或静止障碍物时，车辆需要借用对向车道绕行。这个场景的难点在于对向车道可能有来车，必须确保避让过程中不与来车冲突。Apollo的借道避让场景会同时考虑本车道障碍物和对向车道来车，生成一条既能绕过障碍物又不与来车冲突的轨迹。

实操中，借道避让的触发条件需要仔细调参。触发太早会导致不必要的借道，触发太晚可能来不及避让。通常根据障碍物距离和相对速度来判断，比如障碍物距离小于50米且相对速度大于5米每秒时触发。但这个阈值需要根据车辆制动性能和道路限速调整。

4. 实操过程与核心环节实现

4.1 参考线生成的完整流程

参考线生成是规划模块的第一步，也是最基础的一步。它的输入是高精地图、车辆当前位置、路由信息，输出是一条平滑的局部路径。

第一步是从高精地图中提取当前车道和相邻车道的中心线。高精地图通常以车道为单位存储，每条车道有一系列离散点表示中心线。提取时需要根据车辆位置找到最近的车道，然后向前后延伸一定距离。延伸距离取决于规划视野，城市道路通常需要150到200米，高速需要250到300米。

第二步是车道中心线的拼接和平滑。如果车辆跨越多个车道，需要把多段中心线拼接起来。拼接点处可能不光滑，需要用样条曲线做平滑。平滑的权重需要平衡保真度和光滑度，权重太大参考线会偏离车道中心，太小则平滑效果不明显。

第三步是参考线的截取和坐标转换。以车辆当前位置为起点，沿参考线截取一段，然后把笛卡尔坐标转换成s-l坐标。s是沿参考线的纵向位移，l是垂直于参考线的横向偏移。转换需要计算每个点到参考线的投影，通常用最近点搜索加局部优化。

第四步是参考线的实时更新。车辆行驶过程中，参考线需要不断向前延伸、向后截断。更新频率通常和规划周期一致，比如10赫兹。更新时要注意保持参考线的连续性，避免跳变。

实操中，参考线生成有几个容易出问题的地方。一是高精地图的车道中心线可能不准确，尤其是在路口和匝道处。这时候需要结合感知结果做修正。二是参考线在弯道处可能不够平滑，导致轨迹抖动。可以在平滑时加入曲率约束。三是参考线更新时的跳变问题，可以通过限制更新幅度或做插值来缓解。

4.2 场景管理与状态机配置

Apollo的场景管理通过状态机实现。每个场景是一个状态，场景之间有切换条件。状态机的配置通常在配置文件里定义，包括场景列表、切换条件、优先级等。

场景切换条件通常基于车辆状态和环境信息。比如从车道跟随切换到换道的条件可能是：相邻车道有足够空间、本车道前方有慢车、驾驶员打了转向灯等。这些条件在配置文件里用布尔表达式描述，运行时逐条判断。

场景优先级决定了多个场景同时满足条件时哪个生效。比如换道场景和避让场景可能同时触发，如果换道优先级更高，车辆会先换道；如果避让优先级更高，车辆会先避让。优先级的设置需要根据安全性和通行效率权衡，通常安全相关的场景优先级更高。

状态机的配置需要仔细测试。我踩过的一个坑是场景切换条件过于宽松，导致车辆在车道跟随和换道之间反复切换，轨迹抖动严重。后来把换道条件加严，要求相邻车道前后车距离都大于某个阈值，并且持续一段时间才触发，问题才解决。

另一个坑是场景退出条件不完整。比如换道场景触发后，如果换道过程中目标车道突然出现障碍物，场景应该退出还是继续？如果退出，车辆可能停在两个车道之间，非常危险。Apollo的做法是换道场景一旦触发就执行到底，除非遇到紧急情况。这个逻辑需要在配置时明确。

4.3 轨迹优化问题的构建与求解

轨迹优化是规划模块的核心计算环节。Apollo的轨迹优化通常构建成一个二次规划问题，目标函数是二次型，约束是线性的。

目标函数通常包含几项：与参考线的偏差、速度偏差、加速度平滑项、加加速度平滑项。每一项有对应的权重，权重决定了优化结果偏向哪个目标。比如与参考线偏差的权重越大，轨迹越贴近参考线；加速度平滑权重越大，轨迹越平滑但可能偏离参考线。

约束条件包括：车辆运动学约束、道路边界约束、障碍物约束、速度限制等。运动学约束通常用自行车模型描述，道路边界约束来自高精地图，障碍物约束来自感知和预测。

二次规划的求解可以用开源求解器，比如OSQP或qpOASES。这些求解器效率很高，通常能在几毫秒内求解几百个变量的问题。但二次规划要求问题是凸的，如果约束或目标函数非凸，就需要先做凸化处理，或者改用非线性求解器。

实操中，轨迹优化的调试主要是调权重。权重没有标准值，需要根据车辆特性和场景调整。我的经验是先用默认权重跑通，然后针对具体问题调整。比如轨迹抖动就加大平滑权重，轨迹偏离参考线就加大偏差权重。但要注意权重之间的平衡，一项权重太大可能导致其他项被忽略。

另一个经验是约束的松弛。有时候约束太紧会导致问题无解，这时候需要引入松弛变量，允许约束在一定范围内被违反，但在目标函数里惩罚这种违反。松弛变量的权重需要仔细设置，太小起不到松弛作用，太大则约束形同虚设。

4.4 规划结果的评估与选择

当有多条候选轨迹时，需要评估选最优。Apollo的轨迹评估通常考虑几个维度：安全性、舒适性、效率、合法性。

安全性评估主要看轨迹与障碍物的距离、是否超出道路边界、是否满足动力学约束。舒适性评估看加速度、加加速度、曲率变化率。效率评估看轨迹的通行时间、是否贴近限速。合法性评估看是否遵守交通规则，比如不闯红灯、不压实线。

每个维度有对应的代价函数，总代价是各维度代价的加权和。权重反映了不同维度的重要性。安全性权重通常最高，因为安全是底线。舒适性和效率的权重需要平衡，太偏向舒适会导致通行效率低，太偏向效率则乘坐体验差。

评估选择的一个难点是代价函数的归一化。不同维度的代价量纲不同，直接相加没有意义。通常需要做归一化处理，比如除以一个参考值，或者用排名代替绝对值。Apollo的做法是对每个维度做归一化，然后加权求和。

实操中，轨迹评估的权重需要根据场景调整。高速场景可以适当提高效率权重，城区场景则要提高安全性和舒适性权重。另外，评估指标的计算要考虑实时性，太复杂的评估会影响规划周期。

5. 常见问题与排查技巧实录

5.1 轨迹抖动与不平滑问题排查

轨迹抖动是规划模块最常见的问题之一。表现是车辆行驶过程中方向盘反复微调，乘坐体验差。抖动的原因可能有很多，排查时需要逐层分析。

首先看参考线是否平滑。参考线不平滑会直接导致轨迹抖动。可以在规划模块的输出里打印参考线的曲率，如果曲率变化剧烈，说明参考线需要更好的平滑处理。

其次看优化问题的权重。加速度和加加速度的平滑权重太小会导致轨迹抖动。可以尝试加大这些权重，观察抖动是否改善。但权重太大会导致轨迹响应变慢，需要平衡。

再次看规划周期和控制周期的匹配。如果规划周期太长，控制模块拿到的轨迹更新不及时，也会导致抖动。通常规划周期在10到20赫兹，控制周期在50到100赫兹。规划周期太短会增加计算负担，太长则响应不及时。

还有一个容易被忽略的原因是坐标转换的精度。s-l坐标和笛卡尔坐标之间的转换如果精度不够，会引入噪声。尤其是在弯道处，投影误差会被放大。可以检查坐标转换的实现，确保用了足够精确的数值方法。

我遇到过一次抖动问题，排查了很久才发现是参考线更新时的跳变导致的。车辆行驶过程中，参考线每隔一定距离会重新截取，截取点如果处理不好会产生跳变。后来在截取时加了插值和平滑，问题才解决。

5.2 规划失败的典型原因与应对

规划失败指的是优化问题无解，或者求解时间超限。这是比较严重的问题，因为规划失败意味着车辆没有可执行的轨迹，必须降级或紧急停车。

规划失败的常见原因有几个。一是约束冲突，比如障碍物把可行域完全堵死，或者道路边界和障碍物约束矛盾。这时候需要检查约束的生成逻辑，看是否有不合理的约束。有时候是障碍物的安全距离设得太大，导致可行域太窄。

二是初始解太差。优化问题通常需要一个初始解，如果初始解离最优解太远，求解器可能不收敛。可以尝试用上一周期的解作为初始解，或者用采样方法生成一个粗略的初始解。

三是求解器参数不合适。最大迭代次数、收敛容差这些参数需要根据问题规模调整。迭代次数太少可能不收敛，太多则求解时间超限。

四是数值问题。优化问题里的矩阵如果条件数太大，求解会不稳定。可以做预处理，比如归一化变量、正则化矩阵。

应对规划失败，Apollo有降级策略。如果规划失败，首先尝试用上一周期的轨迹，如果上一周期也没有，就生成一条紧急停车轨迹。紧急停车轨迹通常是一条简单的减速到停的曲线，不追求最优，只保证安全。

实操中，规划失败的日志非常重要。Apollo会记录失败原因、约束状态、求解器输出等信息。排查时要仔细看日志，定位是哪个约束导致的失败。我习惯在开发阶段打开详细日志，虽然会影响性能，但排查问题方便很多。

5.3 场景切换异常的处理经验

场景切换异常是另一个高频问题。表现是车辆行为突然变化，比如从跟车突然变成换道，或者场景反复切换导致轨迹抖动。

场景切换异常的原因通常是切换条件设计不合理。比如换道条件只考虑了目标车道的前车距离，没考虑后车距离，导致换道后后车紧急刹车。或者切换条件没有加持续时间要求，导致条件在边界处反复满足和不满足。

处理这类问题，首先要梳理场景切换的状态转移图，确保每个切换都有明确的进入和退出条件。进入条件要严格，避免误触发；退出条件要完整，避免卡死。其次要加迟滞，比如条件满足后持续一段时间才切换，避免抖动。

还有一个经验是场景切换时要考虑轨迹的连续性。如果两个场景生成的轨迹差异很大，切换时会有跳变。可以在切换时做轨迹混合，或者让新场景的轨迹从当前轨迹平滑过渡。

我踩过的一个坑是换道场景的退出条件没考虑换道完成的情况。车辆换道完成后，应该退出换道场景回到车道跟随，但退出条件只写了“换道失败”，没写“换道完成”，导致车辆换道后一直停留在换道场景，行为异常。后来把退出条件补全，问题解决。

5.4 常见问题速查表

5.5 调试工具与日志分析技巧

Apollo规划模块的调试主要靠日志和可视化工具。日志方面，规划模块会输出每个周期的输入、输出、中间结果、耗时等信息。可视化方面，可以用工具把参考线、候选轨迹、障碍物、s-t图等画出来，直观地看规划结果。

我常用的调试流程是：先看日志确认规划是否成功，如果失败看失败原因；然后看可视化，确认参考线和轨迹的形状是否合理；最后看s-t图和s-l图，确认障碍物处理和速度规划是否正常。

日志分析时要注意几个关键指标。规划耗时是最重要的，如果耗时接近规划周期，说明计算负担太重，需要优化。轨迹数量反映了采样密度，太多会增加计算量，太少可能漏掉可行解。约束违反量反映了优化问题的求解质量，如果违反量大，说明约束太紧或求解不充分。

可视化工具方面，Apollo自带一些可视化插件，但功能有限。我习惯自己写一些脚本，把规划结果导出成图片或动画，方便对比不同参数的效果。尤其是在调参阶段，可视化能大大加快迭代速度。

还有一个技巧是录制回放。把实车或仿真的数据录下来，离线回放，可以反复调试同一段数据，观察参数变化的影响。这比实车调试效率高很多，而且可以覆盖一些实车难以复现的边界情况。

6. 规划模块的扩展与优化方向

6.1 从规则驱动到学习驱动的演进

Apollo的规划模块目前以规则驱动为主，场景逻辑和优化问题的构建都依赖人工设计。这种方式的优点是可控、可解释，缺点是泛化能力有限，难以覆盖所有长尾场景。

近年来的趋势是引入学习驱动的方法。比如用神经网络做行为决策，输入感知和预测结果，输出决策指令。或者用强化学习做轨迹规划，通过大量仿真训练，让模型学会在各种场景下生成合理轨迹。

学习驱动的方法优势在于泛化能力，理论上可以处理规则难以描述的场景。但挑战也很明显：训练数据难获取、模型可解释性差、安全验证困难。在功能安全要求极高的自动驾驶领域，纯学习驱动的方法短期内很难落地。

比较务实的路线是规则驱动加学习增强。用规则保证基本的安全和合法性，用学习处理规则难以覆盖的场景。比如用规则生成候选轨迹，用学习模型做轨迹评估和选择。这样既保留了规则的可控性，又引入了学习的泛化能力。

6.2 多车交互与博弈规划

当前的规划模块主要考虑自车的优化，对其他车辆的交互建模比较简单，通常假设其他车辆按预测轨迹行驶。但实际交通中，其他车辆也会对自车的行为做出反应，形成博弈。

多车交互的规划需要考虑其他车辆的反应。比如换道时，如果目标车道后车看到自车换道意图后加速，自车应该放弃换道还是加速切入？这涉及到博弈论中的均衡分析。

Apollo目前对交互的处理比较保守，通常假设其他车辆不会让行，自车需要找到足够安全的间隙才换道。这种策略安全但效率低，在拥堵场景下可能一直换不了道。

未来的方向是引入博弈规划，显式建模其他车辆的决策过程，寻找纳什均衡或斯塔克尔伯格均衡。但博弈规划的求解复杂度很高，实时性是个大问题。目前有一些近似方法，比如用迭代最优响应代替精确均衡求解，但效果还需要验证。

6.3 规划模块的性能优化实践

规划模块的计算耗时直接影响规划周期，进而影响车辆响应速度。性能优化是工程落地的重要环节。

性能优化可以从几个层面入手。算法层面，选择复杂度低的算法，比如用采样代替优化，或者用查表代替在线计算。实现层面，优化代码，减少不必要的内存分配和拷贝，用并行计算加速。配置层面，调整规划周期和采样密度，在精度和速度之间平衡。

我做过一次性能优化，把规划耗时从50毫秒降到20毫秒。主要措施包括：减少候选轨迹数量，从20条降到10条；简化障碍物约束，只考虑最近的10个障碍物；用查表代替部分在线计算。优化后规划周期从20赫兹提高到50赫兹，车辆响应明显更灵敏。

但性能优化不能牺牲安全性。减少候选轨迹数量可能漏掉可行解，简化障碍物约束可能忽略潜在风险。优化后必须做充分的测试，确保安全性没有下降。

6.4 仿真测试与实车验证的衔接

规划模块的测试通常先在仿真环境里做，再上实车。仿真环境可以低成本、高效率地覆盖大量场景，尤其是危险场景。实车验证则检验真实环境下的表现。

仿真测试的关键是场景库的构建。场景库要覆盖典型场景和边界场景，包括各种交通状况、天气条件、道路类型。场景库的质量直接决定测试的覆盖度。

Apollo的仿真平台支持场景回放和场景生成。场景回放是把实车录制的数据在仿真里重现，用于回归测试。场景生成是用参数化方法生成大量变体场景，用于覆盖测试。

仿真到实车的衔接需要注意几个问题。一是仿真模型的精度，感知和预测在仿真里通常是理想的，实车则有噪声和误差。规划模块需要对这些误差有鲁棒性。二是仿真的时间同步，仿真里时间可以精确控制，实车则有延迟和抖动。三是仿真的场景分布，仿真场景库可能和实际道路分布有偏差，导致过拟合。

我的经验是仿真测试通过后，实车验证要循序渐进。先在封闭场地做低速测试，再在简单道路做中速测试，最后在复杂道路做全速测试。每个阶段都要有明确的通过标准，不达标不进入下一阶段。

7. 个人实操体会与建议

规划模块是自动驾驶系统里最像“手艺活”的部分。感知和控制有成熟的理论和工具，规划则更多依赖工程经验和场景积累。同样的算法，参数调得好不好，效果可能差很多。

我最大的体会是：不要试图一步到位设计一个完美的规划器。先从简单场景做起，把车道跟随做稳，再逐步加换道、避让、路口通行。每加一个场景，都要充分测试，确保不影响已有场景。场景之间的交互是最容易出问题的地方，要特别小心。

另一个体会是数据的重要性。规划模块的调试离不开数据，尤其是边界场景的数据。我习惯在实车测试时录制所有数据，回来后离线分析。很多问题在实车时来不及细看，离线可以反复回放，慢慢排查。

还有一点是保持敬畏。规划模块直接决定车辆行为，一个参数错误可能导致严重事故。任何改动都要经过充分测试，不能凭感觉调参。我见过有人为了赶进度，改了参数没测试就上车，结果车辆在路口突然急刹，幸好没出事。这种教训要引以为戒。

最后分享一个小技巧：在规划模块里加一个“影子模式”，让规划器在后台运行但不控制车辆，把规划结果和人类驾驶员的行为做对比。这样可以低成本地收集规划器的表现数据，发现潜在问题。我在项目里用这个方法发现了不少边界场景的问题，比实车测试效率高很多。