第1章决策规划系统概述

一、决策规划系统概述

大家好，我是这次课程的主讲工程师。今天咱们聊聊决策规划系统——这个在自动驾驶里既关键又容易被忽视的模块。

说实话，我刚开始接触自动驾驶那会儿，总觉得感知和定位才是核心技术。直到有一次在CarMaker里跑仿真，感知模块明明识别到了前方障碍物，车却直直撞了上去……排查了半天，发现是决策规划模块的逻辑没写对。从那以后，我再也不敢小看这个环节了。

决策规划，说白了就是让车“知道该怎么做”。

感知模块告诉车“前面有辆车”，定位模块告诉车“你在哪”，那接下来呢？车是加速超车，还是减速跟车？是向左变道，还是向右避让？这些“下一步动作”的制定，就是决策规划干的事。

我个人习惯把决策规划拆成三个层次：

你想想看，这三个层次缺一个都不行。没有全局路径，车就不知道往哪开；没有行为决策，车就不知道什么时候该变道；没有运动规划，车就算知道要变道，也变不过去——因为轨迹不平滑，方向盘一打就失控。

核心理解：决策规划是自动驾驶的“大脑”，它把感知信息转化为可执行的车辆控制指令。

CarMaker这个工具，我用它做仿真测试已经五六年了。它最大的好处是能提供一个完整的“车辆-环境-传感器”闭环。但很多人容易忽略一点：CarMaker本身并不提供决策规划算法，它只提供接口和仿真环境。

什么意思呢？

就是说，你得自己写决策规划模块，然后通过CarMaker的接口把它集成进去。CarMaker负责模拟车辆动力学、传感器数据、交通场景，你的决策规划模块负责读取这些数据，输出控制指令。

我在项目中遇到过一种情况：团队花了大半年写了一套决策规划算法，在真实车辆上测试效果不错，但一放到CarMaker里仿真就各种报错。后来发现是接口协议没对齐——CarMaker输出的坐标系和我们算法里用的坐标系差了90度。嗯，这种低级错误，犯过一次就记住了。

所以，理解CarMaker中决策规划的角色，其实就三点：

小提示：刚开始用CarMaker做决策规划仿真时，建议先跑一个最简单的“直道跟车”场景。把感知数据直接透传给决策模块，看看能不能正常跟车。这一步通了，再逐步增加复杂度。

下面这张图是我自己整理的决策规划系统架构。在CarMaker里，我们通常把整个系统分成这么几层：

这张图我画得比较简洁，但核心逻辑都在里面了。从上往下看，数据流是单向的：感知输入层拿到CarMaker的环境数据，传给全局路径规划，规划出宏观路线；然后行为决策根据当前场景决定具体动作；运动规划再把这个动作细化成一条可执行的轨迹；最后控制输出层把轨迹转成油门、刹车、转向指令，送回CarMaker。

这里有个坑，我曾经踩过：

避坑指南：我曾经在行为决策和运动规划之间加了一个“轨迹缓存”，想着能减少计算量。结果发现缓存里的轨迹和当前场景对不上——车都开出去两秒了，还在用两秒前的轨迹。嗯，这种优化一定要加时间戳校验，不然就是给自己挖坑。

很多初学者容易把行为决策和运动规划搞混。我简单区分一下：

你看，行为决策输出的是一个“定性”的结果——比如“我要向左变道”。而运动规划输出的是“定量”的结果——比如“接下来3秒内，方向盘打15度，车速从60降到50”。

我个人习惯在CarMaker里调试时，先单独验证运动规划模块。给它一个固定的行为指令（比如“直行跟车”），看看生成的轨迹是否平滑、是否满足车辆动力学约束。运动规划没问题了，再连上行为决策一起测。

调试技巧：在CarMaker里，可以用“Trajectory Viewer”插件直接可视化运动规划输出的轨迹。如果轨迹上有锯齿或者突变，那大概率是规划参数没调好。我一般先检查最大加速度和最大曲率这两个约束。

可能有同学会问：我在真实车上调不行吗？

行，但成本太高了。一次实车测试，场地费、人工费、车辆损耗，少说几千块。而且很多极端场景——比如前车急刹、行人鬼探头——在真实道路上根本不敢测。

CarMaker的好处就是：场景随便搭，参数随便调，撞了也不心疼。

我记得有一次测试一个换道决策逻辑，在CarMaker里跑了上千个随机场景，发现了一个概率极低的bug——当自车速度刚好在某个阈值附近时，行为决策会陷入“换道-取消-换道”的死循环。这种问题在实车测试中几乎不可能复现，但在仿真里一抓一个准。

所以，我的建议是：决策规划算法的开发，一定要以仿真测试为主、实车测试为辅。CarMaker就是那个帮你把“主”做好的工具。

公众号:蓝海资料掘金营，微信deep3321