4、决策规划层误判：行为预测、路径规划、控制指令中的逻辑漏洞
各位同行，今天我们聊一个非常核心的问题——决策规划层的误判。
感知层看错了，那是「看」的问题。但决策规划层出问题，那是「想」的问题。说白了，车已经知道前面有个行人，但它决定「加速冲过去」——这就是逻辑漏洞。我在项目中遇到过好几次，这种问题比感知漏检更难排查，因为逻辑错误往往不会触发任何故障码。
4.1 行为预测的「想当然」陷阱
行为预测模块，本质上是猜别人的意图。猜对了，皆大欢喜。猜错了，就是误判。
我见过最典型的案例：一辆车在路口打左转向灯，但实际直行。我们的系统预测它要左转，于是减速让行。结果后车追尾了。谁的责任？系统预测错了。
核心问题：行为预测模型过度依赖「历史轨迹 + 信号灯/转向灯」的统计规律，忽略了「人类驾驶员可能犯错」这个事实。
为什么会这样？因为训练数据里，打左转灯然后左转的样本占了95%以上。模型学到的就是「左转灯 → 左转」。但现实世界不是这样的。你想想看，你自己开车时有没有打过转向灯但没转？肯定有。
我个人习惯在行为预测模块里加一个「不确定性量化」层。不是输出一个确定的行为类别，而是输出概率分布。比如：
// 传统做法：输出单一预测
Prediction: { lane_change_left: 0.95, lane_keep: 0.05 }
// 我建议的做法：输出概率分布 + 置信度
Prediction: {
lane_change_left: { probability: 0.70, confidence: 0.60 },
lane_keep: { probability: 0.25, confidence: 0.30 },
lane_change_right: { probability: 0.05, confidence: 0.10 }
}当置信度低于某个阈值时，系统应该进入「保守模式」——宁可多等一秒，也不要冒险。
避坑指南：我曾经在某个项目中，行为预测模型对静止车辆的预测准确率只有60%。原因是训练数据里静止车辆大多是「停车状态」，但实际场景中静止车辆可能是「故障车」或「等待转弯的车」。后来我强制要求：对静止目标，预测模块必须输出至少3种可能的未来轨迹，否则不允许下发控制指令。
4.2 路径规划中的「死胡同」逻辑
路径规划的逻辑漏洞，往往出现在「边界条件」上。正常行驶时没问题，但遇到极端场景，规划器就傻了。
我印象最深的一个案例：某车型在高速上遇到施工改道，路障把车道收窄到只剩2.3米宽。规划器算出来的路径，车身宽度1.9米，理论上能过。但它没考虑后视镜的宽度。结果后视镜刮到了路障。
这不是感知的问题，感知已经检测到了路障。这是规划器「对车辆包络的建模不够精细」。
| 漏洞类型 | 典型表现 | 后果 |
|---|---|---|
| 包络建模不足 | 只考虑车身，忽略后视镜/保险杠 | 刮擦、碰撞 |
| 时间窗口过短 | 规划周期内找不到可行路径 | 急刹、停车 |
| 代价函数缺陷 | 过度追求舒适性，牺牲安全性 | 避让不及时 |
| 死锁状态 | 两个目标互相等待，规划器卡死 | 系统无响应 |
路径规划还有一个常见问题：代价函数设计不合理。比如，有些系统把「舒适性」的权重设得太高，导致遇到障碍物时，规划器选择「轻微减速」而不是「紧急避让」。这在大多数场景下没问题，但遇到突然横穿的行人，就来不及了。
注意：代价函数的权重不是一成不变的。我建议根据场景动态调整。比如在高速上，舒适性权重可以高一些；但在城市道路、学校区域，安全性权重必须压倒一切。这个逻辑必须在规划器里写死，不能交给模型去学。
4.3 控制指令的「过度拟合」问题
控制层的问题，往往出在「控制指令与物理世界的脱节」。
举个例子：系统规划了一条路径，要求车辆以0.3g的减速度制动。控制模块收到指令后，执行了。但实际车辆的制动响应有延迟，最终减速度只有0.25g。结果就是——追尾了。
这不是规划的问题，规划是对的。这是控制模块「没有考虑执行器的延迟和误差」。
我个人习惯在控制指令下发前，加一个「可行性校验」步骤：
// 控制指令可行性校验伪代码
function validateControlCommand(cmd, vehicleState) {
// 1. 检查执行器能力边界
if (cmd.steeringAngle > maxSteeringAngle) {
return false; // 超出转向极限
}
// 2. 检查响应延迟
let expectedDecel = cmd.deceleration * (1 - brakeDelayFactor);
if (expectedDecel < requiredDecel) {
return false; // 实际减速度不够
}
// 3. 检查联合约束（转向+制动同时执行时的耦合效应）
if (cmd.steeringAngle > 10 && cmd.deceleration > 0.3) {
return false; // 高速转向时急刹可能导致失控
}
return true;
}还有一个容易被忽视的点：控制指令的时序一致性。我记得有一次排查问题，发现车辆在弯道中突然抖动。查了半天，发现是控制模块在同一个控制周期内，先后下发了「左转5度」和「左转3度」两个指令，执行器在两个指令之间来回切换，导致抖动。
避坑指南：我曾经在控制模块里加了一个「指令平滑器」。不是简单的低通滤波，而是基于车辆动力学模型的预测校正。简单说：控制模块下发指令前，先预测一下车辆在下一个100ms内的实际响应，如果预测结果与规划目标偏差超过阈值，就拒绝执行，并上报给规划层重新规划。
4.4 逻辑漏洞的系统性防御
说了这么多问题，那怎么防？我总结了几条经验：
- 分层冗余：决策规划层不能只有一个「最优解」，必须同时维护一个「安全解」。当最优解不可行时，自动切换到安全解。
- 逻辑自检：每个决策指令下发前，都要经过一个「常识检查器」。比如：车速100km/h时，转向角度不能超过15度。这种规则不需要模型，写死就行。
- 回滚机制：当控制指令执行后，车辆的实际状态与预期状态偏差超过阈值，系统必须有能力「撤销」当前指令，回退到上一个安全状态。
- 仿真验证：我建议每个逻辑变更，都要在至少1000个随机场景中跑一遍仿真。不是跑常规场景，而是跑「边界场景」——比如路面摩擦系数0.1、行人突然横穿、前车急刹等。
一句话总结：决策规划层的误判，本质上是「系统对不确定性的处理能力不足」。感知有不确定性，预测有不确定性，控制也有不确定性。一个好的系统，不是消除不确定性——那不可能——而是学会与不确定性共存，并在不确定性超出边界时，安全地降级。
嗯，这部分内容比较烧脑。但如果你能把决策规划层的逻辑漏洞理清楚，那ADAS系统里80%的疑难杂症你都能找到根因。下一章我们聊聊「执行层响应异常」的问题，那又是另一番天地了。