1. 从一次模拟测试的“幽灵刹车”说起前阵子帮一个做仿真测试的朋友看数据他负责的一个模拟项目在闭环测试里频繁出现一种怪现象车辆在空旷路段突然减速明明前方没有任何障碍物感知模块也没有报出异常目标但决策模块就是给出了制动指令。我们把日志拉出来逐帧回放最后定位到问题出在决策算法的状态机切换逻辑上——一个本该被过滤掉的瞬时噪声触发了“潜在风险”状态而状态机在退出该状态时又过于保守导致车辆反复在“正常行驶”和“谨慎通行”之间横跳。这件事让我重新翻出自己这几年在决策算法上踩过的坑想系统聊聊自动驾驶决策这一层的设计思路。决策算法在整个自动驾驶栈里处于一个很微妙的位置往上它要消化感知和预测模块输出的不确定性往下它要给控制模块下达明确、可执行、且符合车辆动力学约束的指令。它不像感知那样有明确的精度指标也不像控制那样有清晰的稳定性判据决策的好坏往往要到整个系统跑起来、甚至跑够足够多的里程之后才能暴露出来。这篇文章适合谁看如果你正在做自动驾驶相关的开发、测试或者对决策规划模块的设计逻辑感兴趣想搞清楚“为什么这么设计”“参数怎么调”“出了问题往哪查”那接下来的内容应该能给你一些直接可用的参考。我会从整体架构讲到具体实现再到问题排查尽量把每个选择背后的理由说清楚。2. 决策算法的整体架构与设计取舍2.1 分层决策与端到端到底怎么选决策算法目前主流的两条路线一条是分层式一条是端到端。分层式的典型做法是把决策拆成全局路径规划、行为决策、局部运动规划三层每一层有明确的输入输出和职责边界。端到端则是用一个大模型直接从感知输出映射到控制指令中间不显式定义决策层。我自己的经验是分层式在工程落地阶段更可控。原因很直接出了问题你能定位。感知有偏差、预测有误差、决策逻辑有漏洞、控制响应不及时这些在分层架构里可以逐层排查。端到端模型一旦表现异常你很难说清楚到底是哪一环出了问题调试成本极高。而且分层式架构允许你在每一层单独做验证和回归测试这对功能安全要求极高的场景来说是刚需。但分层式也有它的代价。层与层之间的接口设计非常关键接口定义得太窄上层的信息传不下来决策就会“盲人摸象”接口定义得太宽下层要处理的信息量爆炸实时性又保不住。我见过一个项目行为决策层只给局部规划层传了一个目标点和一条参考线结果局部规划层在复杂避障场景下频繁出现轨迹抖动因为缺少足够的上下文来判断周围车辆的意图。端到端路线在近几年确实有进展尤其是在一些结构化程度较高的场景里表现不错。但我的判断是短期内它更适合作为分层架构的补充或者特定场景的专用方案而不是完全替代分层式。一个比较务实的做法是在分层架构的某一层内部引入学习型方法比如用神经网络来做行为决策的分类但整体框架仍然保持分层。2.2 状态机、行为树还是规则引擎行为决策层的实现方式常见的有三种有限状态机、行为树、规则引擎。有限状态机是最直观的。每个状态对应一种驾驶行为比如“跟车”“换道”“超车”“避让”状态之间的转移条件用规则来定义。它的优点是逻辑清晰、容易验证缺点是状态数量会随着场景复杂度指数增长。我做过一个统计一个中等复杂度的城市道路场景如果要把所有可能的驾驶行为组合都枚举出来状态数量轻松超过两百个。这时候状态机的维护成本就非常高了而且状态之间的转移条件很容易出现冲突或者遗漏。行为树在这方面要好一些。它把行为组织成树形结构每个节点代表一个行为或者一个条件判断通过组合节点来控制执行顺序。行为树的优势在于可复用性和可扩展性你可以把一些通用的行为子树抽出来在不同场景里复用。而且行为树的执行逻辑是深度优先的天然适合处理“优先执行某个行为不满足条件再尝试下一个”这类逻辑。缺点是对并行行为的支持不够直观需要额外设计。规则引擎则是另一种思路。你把决策逻辑写成一系列规则引擎根据当前状态和输入数据来匹配规则并执行。规则引擎的优点是灵活修改规则不需要改代码适合快速迭代。但规则多了之后规则之间的优先级和冲突处理会变得很麻烦而且规则引擎的性能通常不如前两者。我目前比较倾向的方案是行为树为主、状态机为辅。用行为树来组织整体的决策流程在需要严格状态管理的局部比如换道过程中的几个阶段用状态机来保证逻辑的确定性。这样既保留了行为树的灵活性又在关键环节有明确的状态约束。2.3 不确定性怎么传下来决策算法面临的一个核心挑战是感知和预测模块输出的结果都带有不确定性。感知可能把远处的卡车误检成轿车预测可能对行人过马路的意图判断错误。决策层如果直接把这些带有不确定性的结果当成确定值来处理就很容易做出激进或者保守的决策。常见的做法是在接口里传递置信度或者概率分布。比如预测模块输出周围每个目标未来几秒的轨迹分布决策层根据这些分布来评估不同行为的安全性。但这里有个工程上的难点概率分布的信息量很大如果每个目标都传完整的分布数据量会非常可观实时性压力很大。我试过的一种折中方案是预测模块输出每个目标的几条候选轨迹每条轨迹带一个概率值决策层只处理这几条候选轨迹。这样既保留了不确定性信息又把数据量控制在可接受的范围内。具体保留几条候选轨迹要根据场景来定。高速公路场景下目标行为比较单一三条左右就够了城市道路场景下目标可能的意图更多可能需要五到八条。还有一个容易被忽略的点是不确定性不仅来自感知和预测还来自决策算法自身。比如状态机在某个状态下停留的时间过长或者行为树在某个分支上反复切换这些都会引入额外的决策不确定性。我在设计的时候会加一些显式的约束比如状态切换的最小间隔、行为切换的滞回区间来抑制这种自引入的不确定性。3. 核心模块的细节拆解与实操要点3.1 行为决策的状态设计行为决策的状态设计是整个决策算法的骨架。我一般会从场景出发来梳理状态而不是从算法出发。具体做法是先把目标场景里所有可能出现的驾驶行为列出来然后根据行为之间的转移关系来合并或者拆分状态。以城市道路场景为例基础状态大概包括车道保持、跟车、换道、超车、避让、路口通行、停车让行。每个状态内部还可以细分比如换道可以分成换道准备、换道执行、换道完成三个阶段。跟车可以分成稳定跟车、接近前车、前车切出三个子状态。状态转移条件的设计有几个原则。第一转移条件要尽量基于可观测的量而不是基于推断的量。比如“前车距离小于阈值”是可观测的“前车意图变道”是推断的后者作为转移条件就容易出问题。第二转移条件要有明确的优先级。多个条件同时满足时哪个优先触发这个必须提前定义清楚否则就会出现状态跳变。第三转移条件要加滞回。比如进入“避让”状态的距离阈值和退出“避让”状态的距离阈值应该不一样避免在阈值附近反复切换。注意状态转移条件里尽量不要用“或”逻辑。我踩过的坑是一个状态有多个进入条件用“或”连接结果其中一个条件因为传感器噪声频繁触发导致状态反复进入。后来改成每个条件单独设一个子状态用优先级来管理问题就解决了。3.2 轨迹生成与筛选行为决策确定之后下一步是生成具体的行驶轨迹。轨迹生成的方法很多常见的有基于采样的方法、基于优化的方法、基于曲线拟合的方法。基于采样的方法是在车辆前方撒一系列候选终点然后对每个终点生成一条轨迹再根据代价函数来筛选最优轨迹。这种方法的优点是实现简单、容易并行化缺点是在复杂场景下采样密度不够会导致轨迹质量下降采样密度太高又会影响实时性。我一般会根据场景来动态调整采样密度高速公路场景下采样可以稀疏一些城市道路场景下采样要密一些。基于优化的方法则是把轨迹生成问题转化成一个优化问题目标函数里包含安全性、舒适性、效率等多项指标约束条件包括车辆动力学约束、道路边界约束、障碍物避让约束等。这种方法的优点是生成的轨迹质量高缺点是求解时间长而且容易陷入局部最优。我在实际项目里一般会用优化方法来做轨迹的精细调整而不是从头生成。基于曲线拟合的方法是用多项式或者样条曲线来拟合一条轨迹优点是生成速度快、轨迹平滑缺点是对复杂场景的适应能力有限。我一般只在结构化程度很高的场景里用这种方法比如高速公路的巡航场景。轨迹筛选的代价函数设计是个技术活。我一般会把代价分成几类安全性代价、舒适性代价、效率代价、合法性代价。安全性代价包括与障碍物的距离、碰撞时间等舒适性代价包括加速度、加加速度、曲率变化率等效率代价包括行驶时间、速度偏差等合法性代价包括是否压线、是否超速等。每一类代价的权重需要根据场景来调而且不同场景下的权重差异可能很大。3.3 与预测模块的接口设计决策和预测之间的接口设计直接决定了决策算法能拿到多少有效信息。我见过两种极端的做法一种是预测模块只给决策模块传一条最可能的轨迹另一种是传完整的概率分布。前者信息量太少后者信息量太大。我比较推荐的方案是传一个“轨迹集”每条轨迹带一个概率值同时附带一些关键的语义信息比如目标的类型、当前的运动状态、可能的意图标签。这样决策模块既能看到多种可能性又能根据语义信息来做更精细的判断。接口的更新频率也很关键。预测模块的更新频率通常比感知低因为预测需要一定的观测窗口。如果决策模块按照感知的频率来调用预测结果就会出现同一份预测结果被多次使用的情况。我一般会在接口里加一个时间戳决策模块根据时间戳来判断预测结果是否过期。过期的话要么等待更新要么用外推的方式来估计。还有一个细节是坐标系的一致性。感知、预测、决策、控制可能使用不同的坐标系接口转换的时候如果处理不当就会引入额外的误差。我一般会在项目初期就统一坐标系定义并且在接口文档里明确标注每个字段的坐标系和单位。4. 完整决策流程的实现与参数调优4.1 从感知输入到行为决策的完整链路假设我们有一个典型的城市道路跟车场景前方有一辆慢车左侧车道有车流右侧是实线。决策算法的完整处理链路大概是这样的第一步接收感知和预测的输出。感知给出前方慢车的位置、速度、尺寸预测给出慢车未来几秒的轨迹分布同时给出左侧车道各车辆的位置和速度。第二步评估当前状态。当前状态是“车道保持”但前车距离在缩小速度差在增大需要判断是否进入“跟车”状态。第三步行为决策。根据前车距离、速度差、左侧车道是否满足换道条件、右侧是否允许换道等因素决定是继续跟车、尝试换道、还是减速保持距离。第四步轨迹生成。如果决定跟车生成一条保持安全距离的轨迹如果决定换道生成一条从当前车道平滑过渡到左侧车道的轨迹。第五步轨迹筛选和输出。对生成的候选轨迹进行安全性、舒适性、效率评估选出最优轨迹输出给控制模块。这个链路看起来简单但每一步都有很多细节。比如第二步里前车距离和速度差的阈值怎么定我一般会用碰撞时间作为主要指标同时辅以距离阈值。碰撞时间的阈值通常设在2到3秒距离阈值根据车速来定低速时距离阈值小一些高速时大一些。第三步里换道条件的判断需要考虑左侧车道前后车的距离和速度以及换道所需的时间。我一般会计算一个“换道可行性指标”综合左侧车道前后车的碰撞时间、换道所需时间、以及换道过程中的加速度约束来判断是否可行。4.2 关键参数的选取与计算过程决策算法里有很多参数我挑几个最关键的来说说怎么定。碰撞时间阈值。这个参数决定了决策算法对潜在碰撞风险的敏感程度。设得太小决策过于激进安全性没保障设得太大决策过于保守通行效率低。我的经验值是高速公路场景下设在2.5到3秒城市道路场景下设在1.5到2秒。计算方法是碰撞时间等于两车距离除以相对速度。比如前车距离50米相对速度20米每秒碰撞时间就是2.5秒。换道最小间隙。这个参数决定了在什么条件下允许换道。计算方法要考虑换道所需的时间和目标车道前后车的运动状态。假设换道需要4秒目标车道后车速度比自车快5米每秒那么换道完成后后车与自车的距离至少要有20米的安全余量加上换道过程中后车行驶的距离总的间隙需求大概是40到50米。实际取值还要考虑车辆尺寸和驾驶员风格。跟车时距。这个参数决定了跟车时保持多远的时间距离。我一般会设一个基础值比如1.5秒然后根据车速和场景来调整。低速时减小到1.2秒高速时增大到2秒。这个参数直接影响乘坐体验和通行效率需要反复调。状态切换滞回区间。这个参数用来抑制状态抖动。比如进入“避让”状态的距离阈值是30米退出“避让”状态的距离阈值可以设成35米中间5米就是滞回区间。滞回区间的大小要根据传感器噪声水平和场景动态来定噪声大、场景变化快的时候滞回区间要相应增大。4.3 仿真验证与实车测试的衔接决策算法在仿真里跑通只是第一步实车测试才是真正的考验。我一般会把验证过程分成三个阶段纯仿真、硬件在环、实车测试。纯仿真阶段主要验证逻辑正确性。用场景库里的各种场景来跑看决策算法在各种边界条件下的表现。这个阶段要重点关注的是状态切换是否合理、轨迹生成是否平滑、参数是否在合理范围内。硬件在环阶段主要验证实时性和接口兼容性。把决策算法部署到目标硬件上用真实的传感器数据或者回放数据来跑看算法的耗时是否满足要求接口是否有数据丢失或者延迟。实车测试阶段主要验证实际表现。这个阶段要特别小心因为实车测试有安全风险。我一般会先在封闭场地里做低速测试确认基本功能正常再逐步提高速度、增加场景复杂度。实车测试的时候一定要有安全员随时准备接管而且要有明确的分级测试计划。提示仿真里跑得再好实车测试也可能出问题。我遇到过仿真里完全正常的换道逻辑实车上因为传感器安装角度偏差导致目标车道后车的距离估计偏大换道时差点发生碰撞。所以实车测试前的传感器标定和验证绝对不能省。5. 常见问题与排查技巧实录5.1 决策抖动与状态频繁切换决策抖动是决策算法最常见的问题之一。表现是车辆在某个场景下反复做出不同的决策比如一会儿加速一会儿减速或者一会儿准备换道一会儿又取消。排查思路是这样的先看状态切换的日志确认是哪个状态在频繁切换。然后看切换的触发条件是哪个输入量在阈值附近波动。最后看这个输入量的来源是感知噪声、预测误差、还是决策算法自身的逻辑问题。我遇到过的原因大概有这么几类感知噪声导致距离或者速度估计波动预测模块输出的轨迹概率分布变化太快状态切换的滞回区间设得太小多个转移条件的优先级不明确。解决办法对应也有几类在感知输入上加滤波在预测接口上加时间平滑增大滞回区间明确转移条件的优先级并且给每个条件单独设阈值。5.2 轨迹不可行或违反动力学约束轨迹生成之后有时候会出现轨迹不可行的情况比如曲率超过车辆最小转弯半径或者加速度超过车辆动力极限。这种问题一般在仿真阶段就能发现但如果参数调得不好实车上也可能出现。排查的时候先看轨迹的曲率和加速度曲线确认是哪个约束被违反了。然后看轨迹生成算法的参数比如采样密度、优化目标函数的权重、约束条件的松弛量。常见的原因是采样密度不够导致轨迹在障碍物附近出现急转弯或者优化目标函数里舒适性权重太低导致轨迹过于激进。解决办法增加采样密度尤其是在障碍物附近调整目标函数权重提高舒适性代价的占比在约束条件里加入硬约束确保生成的轨迹一定满足动力学要求。5.3 与预测模块的时序不一致决策和预测的时序不一致会导致决策算法使用过期的预测结果从而做出错误的判断。表现是车辆对周围目标的运动状态反应迟钝或者做出与当前场景不符的决策。排查方法是在接口里加时间戳记录每次决策使用的预测结果的时间戳然后看时间戳的延迟分布。如果延迟经常超过预测模块的更新周期就说明时序有问题。解决办法调整决策和预测的调用频率确保决策使用的预测结果是最新的在预测接口里加超时机制预测结果过期时要么等待更新要么用外推来估计在决策算法里加时序一致性检查发现时序异常时降级处理。5.4 常见问题速查表问题现象可能原因排查方法解决措施决策抖动状态切换滞回不足查看状态切换日志增大滞回区间决策抖动感知噪声检查输入数据波动加滤波轨迹不可行采样密度不足检查轨迹曲率增加采样密度轨迹不可行约束松弛过大检查约束满足情况收紧约束时序不一致调用频率不匹配检查时间戳延迟调整调用频率决策过于保守碰撞时间阈值过大检查阈值设置降低阈值决策过于激进碰撞时间阈值过小检查阈值设置提高阈值6. 一些个人体会和后续可以尝试的方向决策算法这个领域我觉得最难的还不是算法本身而是怎么把不确定性管好。感知有不确定性预测有不确定性决策自身也有不确定性这些不确定性叠加在一起很容易让整个系统变得不可控。我的经验是与其追求消除不确定性不如学会和不确定性共处。在接口设计上保留不确定性信息在决策逻辑里显式地处理不确定性在参数调优时考虑不确定性的影响这些做法比单纯追求高精度感知和预测更务实。另外一点体会是决策算法的评价指标不能只看安全性。安全性是底线但舒适性和通行效率同样重要。我见过一些项目决策算法过于保守安全性确实好但乘坐体验很差通行效率也低最后用户不愿意用。所以在调参的时候一定要把舒适性和效率纳入考量找到一个平衡点。后续可以尝试的方向我觉得有几个值得关注。一个是把学习型方法引入到行为决策层用数据来驱动决策逻辑的优化而不是完全靠人工规则。另一个是决策算法的可解释性尤其是在出问题的时候能够清楚地解释为什么做出了某个决策这对调试和验证都很重要。还有一个是多车交互场景下的决策现在大部分决策算法还是把周围车辆当成独立的目标来处理但实际上车辆之间的交互会影响彼此的决策这个方向还有很多工作可以做。我在实际项目里踩过的坑大部分都跟参数调优和场景覆盖有关。参数调优没有捷径就是反复试、反复调但一定要有系统的方法不能瞎调。场景覆盖也是一样要尽量把边界场景都考虑到不能只测常规场景。这些经验听起来很朴素但确实是最管用的。
