4、决策规划系统集成：行为决策、路径规划、运动规划模块的接口与集成

各位同学，今天我们来聊聊决策规划系统里最核心的集成问题。说实话，这个环节是自动驾驶系统里最容易出幺蛾子的地方。我见过太多团队，每个模块单独跑都挺好，一联调就崩。为什么？说白了就是接口没定义清楚。

4.1 三个模块到底在干什么？

先理清概念。行为决策、路径规划、运动规划，这三个词听着像，干的活完全不同。

• 行为决策：决定「下一步做什么」。比如：是跟车、变道、还是靠边停车？它输出的是驾驶意图。
• 路径规划：决定「走哪条路」。它生成一条从A到B的几何路径，不考虑动力学约束。
• 运动规划：决定「怎么走」。它把路径变成带时间戳的轨迹，包含速度、加速度、转向角。

嗯，这里要注意。很多新手会把路径规划和运动规划混为一谈。我在项目里遇到过，有人直接把路径规划的输出丢给底层控制，结果车在弯道里直接冲出去了。为什么？因为路径规划只给了几何线，没给速度曲线。

4.2 接口定义：数据流才是命脉

集成这件事，接口定义占七成功力。我个人的习惯是，先画数据流图，再写代码。你想想看，如果行为决策输出的「变道意图」是个枚举值，而路径规划期望的是一个结构体，那联调时就是灾难。

下面是我在项目中常用的接口定义示例：

// 行为决策输出
struct BehaviorOutput {
    ManeuverType type;      // 跟车、变道、停车等
    LaneID target_lane;     // 目标车道ID
    float desired_speed;    // 期望速度
    float time_horizon;     // 该行为有效时间
};

// 路径规划输出
struct PathOutput {
    std::vector<WayPoint> path;  // 路径点序列
    float path_length;           // 路径总长
    float curvature_max;         // 最大曲率
};

// 运动规划输出
struct TrajectoryOutput {
    std::vector<State> trajectory;  // 带时间戳的状态序列
    float duration;                 // 轨迹总时长
    float comfort_score;            // 舒适度评分
};

你看，每个接口都包含了关键信息。行为决策告诉路径规划「我要去哪条车道」，路径规划告诉运动规划「这条路有多弯」，运动规划最后输出可执行的轨迹。一环扣一环。

4.3 集成中的常见坑

解决方案其实不复杂。我建议在接口里加一个时间戳字段，并且要求下游模块必须检查时间戳的有效性。如果发现指令过期，就保持上一帧的行为，直到收到新的有效指令。

4.4 集成测试策略

集成不是一次搞定的。我一般分三步走：

1. 接口一致性测试：先检查数据结构、字段类型、频率是否匹配。这一步用单元测试就能搞定。
2. 模块联调测试：把三个模块串起来，用录好的场景数据回放。看输出轨迹是否合理。
3. 闭环仿真测试：接入车辆模型和仿真环境，跑完整的决策-规划-控制闭环。

4.5 接口版本管理

项目迭代过程中，接口一定会变。我见过最离谱的事，是路径规划改了输出结构，但行为决策那边没人知道，结果联调时崩溃了一整天。

所以，接口版本管理必须做。我建议：

版本	变更内容	影响模块	兼容性
v1.0	初始定义	全部	-
v1.1	BehaviorOutput增加time_horizon	运动规划	向后兼容
v2.0	PathOutput改为样条曲线表示	运动规划、控制	不兼容

每次接口变更，都要通知所有相关模块的负责人。我个人习惯在代码里加一个接口版本宏定义，编译时自动检查版本是否匹配。

4.6 实时性保障

决策规划系统对实时性要求极高。行为决策一般跑10-20Hz，路径规划20-50Hz，运动规划50-100Hz。你想想看，如果运动规划等不到路径规划的结果，车就得停下来。

我常用的做法是：

• 每个模块设置超时阈值，超时后使用上一帧结果
• 使用双缓冲机制，避免读写冲突
• 关键路径上禁用动态内存分配

4.7 总结一下

决策规划系统的集成，说白了就是三件事：接口定义清楚、时序对齐、异常处理到位。我在项目里见过太多团队，花大量时间调算法，却忽略了集成细节。结果算法再牛，跑不起来也是白搭。

嗯，今天就聊到这里。下一章我们会讲控制系统的集成，到时候再聊聊怎么把规划出来的轨迹真正交给车辆执行。