简介：面向自动驾驶研发工程人员及相关专业学生，这份PDF系统梳理了从车辆底层控制到上层决策的完整规控算法知识链路。内容围绕六大课程目标展开，涵盖自动驾驶系统构成与核心技术、车辆运动学与动力学建模、坐标系与电控开发、多目标追踪与多传感器融合方法、行为决策与路径规划，以及基于线控底盘的ADAS设计实施。资源为单份PDF文档，压缩包约205KB，轻量便携，便于收藏、打印或反复查阅。文档引入软件定义汽车、横纵垂耦合动力学分层协调控制、系统辨识与状态估计、KKT优化原理、换道行为决策方法、LKA/LCA/ACC/AEB等常规ADAS设计，并结合工程案例讲解实现细节，帮助读者贯通理论控制方法与功能落地。目前已有117人学习使用，可作为自动驾驶入门与进阶的系统性参考资料。
1. 自动驾驶规控算法是那把“最后落地的方向盘”
大多数人聊自动驾驶，注意力都在感知上——摄像头认出了什么、激光雷达点云里那个轮廓是不是行人。但真正决定这辆车是平顺并入还是贴着护栏回正、是刹得人仰马翻还是稳稳停住的，是规控（规划与控制）算法。感知看错了可以靠多传感器融合兜底，规控算错了没有兜底，因为它是链路上最后一个物理动作的执行者，方向盘和油门刹车一动，就没有后悔药了。这个领域的工作量比感知更琐碎，也更需要系统性，适合那些既有数学功底又愿意盯实车数据的工程师。本文想聊透一件事：自动驾驶规控算法的开发框架长什么样、测试要怎么搭才能不翻车，以及我把常见坑位摸过一遍后总结出的可行路径。
2. 规控到底在做什么：从任务拆解到算法选型逻辑
2.1 规控的职能边界：路线、行为、轨迹、执行四层怎么分
很多刚入行的开发者习惯把规控当成一个整体来调，遇到问题就“调参数”，这是最大的认知包袱。行业里成熟的做法是把它拆成四个层级来对待，每一层的职责、更新频率和调试手段都完全不同。
- 全局路径规划（Route Planning）：起点到终点之间的道路级路径，通常在导航启动时计算一次，频率极低，但对语义地图质量敏感。
- 行为决策（Behavior Decision）：当前时刻该执行什么驾驶意图，比如跟车、变道、让行、停车等待，输出的是离散状态和宏观目标。
- 运动规划（Motion Planning）：把行为决策变成一条时间上有解的轨迹，包含位置、速度、加速度、加加速度（jerk）序列。
- 运动控制（Motion Control）：轨迹作为输入，输出方向盘转角、油门和制动指令，让车实际跟随这条轨迹。
这四个层级对应的时间尺度分别是分钟级、百毫秒级、几十毫秒级和十毫秒级。理解这个边界最重要的价值在于：调试时你能准确找到问题层。表现是方向盘震荡，通常是控制层阻尼和增益配比的问题；表现是换道时贴着某条边界太近，大概率是运动规划里的采样范围或代价权重出了问题；表现是该变道不变道，就要回头检查行为决策逻辑，而不是去调控制器参数。
我曾经在一个模拟项目X里处理过一个经典案例：A同学调了三天控制参数，车辆仍然在弯道内测压线，最后发现是全局路径在车道级切换处残留了一个跳变点，轨迹规划出来的曲线本身就不连续，控制器再强也救不回来。这恰好说明了层级拆分在排错里的核心地位。
2.2 核心算法选型：Lattice、MPC、LQR、PID 到底按什么标准挑
每个层级都有对应的主流算法族，选型不是越复杂越好，而是看算力预算、工况范围、调试成本和稳定性的平衡。
| 层级 | 常见算法 | 优势 | 劣势 | 适用条件 |
|---|---|---|---|---|
| 全局路径 | A*、Dijkstra、Hybrid A* | 实现简单、工程经验多 | 未考虑车辆运动学约束（普通A*） | 结构化道路优先用车道级路径，泊车/非结构化用Hybrid A* |
| 行为决策 | 状态机、决策树、蒙特卡洛树搜索 | 状态机直观可解释 | 长尾场景组合爆炸 | 量产项目里状态机仍是主力，可决策性的场景再上学习 |
| 运动规划 | Lattice Planner、EM Planner、样条曲线、优化方法 | 采样方法直观可控 | 优化方法迭代慢且可能无解 | 低速泊车和结构化道路场景目前最成熟 |
| 运动控制 | 纯跟踪、PID、LQR、MPC | 纯跟踪实现最快 | 高速工况跟踪误差显着 | 低速、调试期用纯跟踪/PID；主控首选MPC |
这里重点展开两个选择场景。
场景一：横向控制的 MPC 与 LQR 之间怎么选。LQR 的优点是求解快、鲁棒性好，在车辆线性区域内表现很好，不需要在线优化；缺点是难以直接处理不等式约束，比如方向盘转角限位、横摆角速度包络，实际做出来很多约束是靠标定“惩罚项”间接表达的。MPC 的优势是可以把执行器饱和、侧偏角包络、跟踪误差边界直接在滚动优化里当硬约束塞进去；代价是每帧都要解一个QP（二次规划）问题，对算力和求解器实时性有要求。量产项目的主流选择是用 MPC 做中高速横纵向综合控制，低速工况退化为 PID 或纯跟踪。
场景二：运动规划里采样和优化哪个是主干。如果你所在的团队还在算法验证阶段，Lattice Planner 是最容易跑通、也是问题最容易解释的路径。它按纵向位移或时间把轨迹采样成一组候选，再逐个算代价挑最优，逻辑透明。而基于优化的方案（比如把轨迹规划转成二次规划问题）在密集场景里有更好的最优性，但工程上要处理约束冲突、求解失败时的 fallback。我的建议是：先用采样法把业务逻辑理清，再根据具体场景决定是否迁移到优化方法。迁移的触发信号很明确——候选轨迹粒度不够、弯道换道时总在两条采样轨迹之间跳来跳去，导致方向盘抖动。
2.3 横纵向解耦：为什么所有架构最后都会回到这个老问题上
规控工程上另一个绕不开的设计决定是横纵向解耦还是联合优化。横向负责转向，纵向负责速度与跟车距离。联合优化在理论上可以把换道时“边转边刹”的最优曲线算出来，但实际工程里它会显著放大非线性，尤其是轮胎侧偏特性和制动模型叠加后，问题复杂度爆炸式上升。
产业实践中主流的做法是横纵向解耦，并在高层做协调逻辑。具体到开发时，我会强制要求团队用“先横后纵”的调试顺序：
- 先固定纵向速度不变，把横向跟踪调收敛；
- 再固定横向路径为直线，把纵向跟车和速度规划调平顺；
- 最后打开耦合，只在换道、弯道减速等场景里做速度-曲率协调。
这样处理的好处是每个环节的变量少，出问题容易定位。你会发现大量实际“翻车”现象都是在解耦边界处发生的，比如弯道中突然丢目标导致纵向急减速，横向还保持着原来的转角，车会有一个明显的“拧”的感觉。这种问题必须靠场景层做协调，加一个“弯道内速度变化率上限”的约束，单纯依赖运动规划本身是压不住的。
3. 从零搭一套规控开发框架：最小可用实现的四个步骤
3.1 坐标系统与数学基础：Frenet坐标系和车辆运动学是地基
规控算法开发和感知有一个显着差别：感知在图像坐标系、雷达坐标系、车辆坐标系之间反复切换，规控的核心计算则主要在 Frenet 坐标系（以车道中心线为参考线的 s-l 坐标）和笛卡尔坐标系之间来回变换。不理解这套坐标变换，后面读代码和改轨迹都会非常痛苦。
Frenet 坐标系用纵向位移 s（沿参考线前进的距离）和横向偏移 l（到参考线的垂直距离）描述车辆位置。它最大的意义是让道路形状从“弯的”变成“直的”，因为参考线已经包含了曲率信息。运动规划在 s-l 坐标系里采样轨迹，再映射回笛卡尔坐标序列，控制层再基于笛卡尔坐标做跟踪。
车辆运动学模型方面，开发前期用自行车模型（Bicycle Model）就足够。它的状态是位置 (x, y) 和航向角 ψ，输入是前轮转角 δ 和速度 v，表达式如下：
# 自行车运动学模型离散递推 import math def kinematic_update(x, y, yaw, velocity, steer_angle, dt, wheelbase=2.8): """ 离散化自行车模型 - x, y: 后轴中心当前位置 - yaw: 航向角，单位弧度 - velocity: 纵向速度（后轴） - steer_angle: 前轮转角，单位弧度 - dt: 步长，秒 - wheelbase: 轴距，米 """ x_new = x + velocity * math.cos(yaw) * dt y_new = y + velocity * math.sin(yaw) * dt yaw_new = yaw + velocity / wheelbase * math.tan(steer_angle) * dt return x_new, y_new, yaw_new逻辑说明：这里所有变量都以后轴中心为基准，是行业准则。后轴中心的横向速度为零，前轮转角的变化对横摆角速度的贡献由轴距和当前车速决定。参数说明：dt 在控制循环里通常取 20ms 或 50ms，越小精度越高但计算量也线性上升，仿真初期用 50ms 足够。wheelbase 直接决定了弯道中车辆转弯半径和轨迹跟踪特性，不同车型不能共用同一套参数，这是后面标定环节要重点覆盖的变量。
3.2 轨迹采样与代价评估：用最直白的 Lattice Planner 打通流程
我并不建议大家一上来就啃论文级的优化规划器。先用一个能跑的 Lattice Planner 打通“采样→评估→跟踪”完整链路，观察车辆如何跟随轨迹，比自己埋头调 MPC 参数更能建立起直觉。这里我贴一个简化版代码，覆盖横向轨迹采样。
# 横向Lattice轨迹生成与选择（一维简化） import numpy as np def generate_lateral_trajectories(d_current, d_target, ds, dt, t_max=3.0): """ 以五阶多项式生成横向偏移轨迹集合 - d_current: 当前横向偏移 - d_target: 目标横向偏移（换道时取邻近车道中心） - ds: 不同轨迹的速度偏好，影响完成换道所需的时间 - dt: 时间步长 - t_max: 轨迹总时长 """ lats = [] for T in np.arange(2.0, t_max + 0.1, 0.5): # 换道完成时间从2秒到3秒采样 # 五阶多项式系数，满足起终点边界条件 a0 = d_current a1 = 0.0 # 起点横向速度为0 a2 = 0.0 # 起点横向加速度为0 a3 = (20 * (d_target - d_current)) / (2 * T**3) a4 = (30 * (d_current - d_target)) / (2 * T**4) a5 = (12 * (d_target - d_current)) / (2 * T**5) t = np.arange(0, T, dt) l = a0 + a1 * t + a2 * t**2 + a3 * t**3 + a4 * t**4 + a5 * t**5 lats.append((T, l)) return lats def evaluate_lateral_cost(lats, current_speed, comfort_weight=1.0): """ 代价函数：只考虑横向加速度最大绝对值 comfort_weight: 舒适性权重，值越大越倾向平缓轨迹 """ best = None best_cost = float('inf') for T, l in lats: a_lat = np.gradient(np.gradient(l)) / 0.05 # 近似横向加速度 cost = np.max(np.abs(a_lat)) * comfort_weight + T * 0.5 if cost < best_cost: best_cost = cost best = (T, l) return best逻辑说明：横向轨迹以五阶多项式生成，边界条件满足横向位置、速度和加速度的连续性。这里刻意用最大横向加速度做代价，因为它是舒适性最重要的代理指标。evaluate_lateral_cost在工程实践里通常还要加上碰撞风险、参考线偏离惩罚、目标车舒适度等因素，但第一版不要贪多，先跑起来再逐步增加代价项。参数说明：T的采样区间决定了换道激进程度——2秒完成换道符合普通乘用车城市换道，1.5秒会显得急促，3秒以上在高速路比较合适。
3.3 控制器的开发次序：为什么先用 PID 标定，再换 MPC 做正式版
开发次序是我反复强调的一个习惯：新平台上线第一天直接用 MPC，出了问题你根本不知道是模型误差大、还是权重没调好、还是求解器设置不对。而 PID 参数含义直白，哪怕你看不懂内部矩阵数学，也知道把 P 调小可以让转向柔和。我一般在每个新车型上做这样一轮顺序操作：
# 纯跟踪控制器：横纵向解耦阶段的基础实现 import math class PurePursuit: def __init__(self, wheelbase=2.8, lookahead=2.0): self.wheelbase = wheelbase self.lookahead = lookahead # 前视距离，车速越高要越大 def compute_steer(self, x, y, yaw, path, velocity): """ 纯跟踪算法：找前视点，算圆弧曲率，输出转角指令 - path: 未来轨迹点序列 (x, y) - lookahead 应随速度线性增长，此处简化为固定值 """ min_dist = float('inf') target_idx = 0 for i, (px, py) in enumerate(path): d = math.hypot(px - x, py - y) if d < min_dist: min_dist = d target_idx = i # 从当前最近点开始找第一个距离>=lookahead的点 for i in range(target_idx, len(path)): px, py = path[i] d = math.hypot(px - x, py - y) if d >= self.lookahead: target_point = (px, py) break alpha = math.atan2(target_point[1] - y, target_point[0] - x) - yaw # 车辆转角与曲率的关系：tan(delta) = 2 * wheelbase * sin(alpha) / ld steer = math.atan2(2.0 * self.wheelbase * math.sin(alpha), self.lookahead) return steer逻辑说明：纯跟踪的核心思想是让车辆沿着一条虚拟圆弧走向前方的目标点。这个目标点距离当前点的弧长由 lookahead 参数控制，它本质上就是“看多远来决策”。代码里通过遍历轨迹点找到第一个距离超过前视距离的点作为目标，然后利用正弦定理把横向误差换算为转角。参数说明：lookahead 是唯一的关键参数，低速取 1.5~3 米，中高速按0.5 * velocity + 2.0之类的公式随速度增长，否则会出现低速振荡或高速“切弯”的问题。注意，纯跟踪只在标定初期用，正式跑完流程后建议立刻切换到带约束的 MPC，因为纯跟踪没有动力学预测能力，无法在极限工况保证安全。
3.4 MPC 最小实现框架：从模型差异到工程落地
当团队决定上 MPC 时，我会要求先搭最简版本：目标函数只包含纵向跟随误差、横向误差、转向角变化率三项，约束只包含方向盘转角上下限和加速度上下限。
# MPC 目标函数与约束框架（伪代码，示意结构） # 状态向量: [横向误差, 航向误差, 转向角, 转向角速度] # 控制输入: 前轮转角增量 def mpc_step(x0, ref_trajectory, system_model, config): """ 同步求解每一帧的QP问题 - ref_trajectory: 未来N步的期望轨迹（来自运动规划） - system_model: 线性化后的车辆动力学模型 - config: MPC参数集合，包含权重和约束 """ # 构造预测方程：x_{k+1} = A x_k + B u_k (线性时变) # 目标函数 J = sum(状态误差^T Q 状态误差 + u^T R u + du^T Rdu du) # 硬约束: |steer| <= config.steer_limit # |accel| <= config.accel_limit # 用osqp或自定义求解器解QP # solution = quadprog_solve(H, f, Aineq, bineq) return solution_controls逻辑说明：MPC 每一帧都要做三件事——基于当前时刻的车辆模型预测未来 N 步的状态演变，将跟踪问题表达为一个带约束的二次规划，求解后只取第一步控制量执行，下一帧重复这个过程。参数说明：预测时域 N 的典型值是 10~30 步，对应 0.5~1.5 秒；权重 Q 控制跟踪优先度，R 控制控制量幅值，Rdu 控制控制量变化率。新手最容易踩的坑是 R 和 Rdu 设得太小，导致方向盘高频抖动；另一个坑是模型没有把执行器延迟（通常是 100~200ms）加进去，高速下会出现相位滞后。工程上补齐执行器延迟后再调控制性能，才是一条正道。
4. 规控测试体系搭建：仿真、回放、实车的三层验证怎么排布
4.1 仿真是第一个过滤器，但仿真通过不代表问题解决
测试体系里最核心的理念是“留好退路”。规控算法有它天然的弱势：实车测试成本高并且安全风险大，所以必须用高覆盖度的仿真将大部分问题拦截在实验室阶段。仿真层的价值不是“证明“算法正确，而是“快速找出明显错误”——逻辑上缺了个状态、目标丢失时没有 fallback 路径、轨迹平滑性差导致控制量跳变，这些问题在仿真里都会以非常显眼的指标异常暴露。
仿真通常分三个深度：纯软件在环（SIL），环境、车辆模型、传感模型全是数字的；硬件在环（HIL），控制器跑在实际的域控制器硬件上，但环境仍是数字的；实车在环则把车辆放在试验场，但部分传感数据用注入的虚拟目标替代。三个层级的测试成本和置信度依次上升，规控团队至少要在前两层把问题清掉七八成再上实车，这是行业实践里的共识。
| 层级 | 车辆模型 | 环境模型 | 主要解决的问题 | 建议占比 |
|---|---|---|---|---|
| SIL软件在环 | 动力学模型 | 仿真环境 | 逻辑缺陷、边界场景、参数初调 | 60% |
| HIL硬件在环 | 动力学模型 | 仿真环境 | 接口问题、实时性、控制器性能 | 30% |
| 实车/场地 | 真实车辆 | 真实场地 | 标定收敛、执行器响应、主观平顺 | 10% |
4.2 最小可用仿真场景拆解：场景定义、车辆模型和评测指标
仿真场景的搭建不必追求大而全，但一定要覆盖规控的核心测试电压。我在项目初期会先搭三种场景：
# 仿真场景构建示意（Python风格定义） scenario = { "type": "cut_in", # 旁车切入场景 "ego_lane_id": 0, "obstacle": { "start_x": 100, "start_y": -3.5, # 目标车初始在相邻车道 "target_speed": 72.0 / 3.6, # 目标车速 "cut_in_time": 3.0, # 第3秒开始切入 "cut_in_lateral_dist": 3.5 # 横向移动3.5米进入本车道 }, "road": {"curvature": 0.001, "speed_limit": 80.0 / 3.6}, "duration": 20.0, "metrics": ["min_ttc", "max_accel", "lateral_jerk", "tracking_error"] }逻辑说明：这段场景定义表达的核心思想是“可控变量”。切入车在哪个时刻启动、横向移动多少、车速多快，都被固化成参数，这样不同算法版本之间的对评比有意义。参数说明：cut_in_time和cut_in_lateral_dist是最关键的两个参数——切得太缓测不出算法的反应灵敏度，切得太急又会逼出太多的误制动。注意：metrics 里min_ttc是最小碰撞时间，量产标准通常要求大于某个安全阈值；lateral_jerk则直接反映乘客舒适度，这也是仿真阶段最容易复现主观评价问题的客观指标。
场景跑完后，分析侧要有同一套评价逻辑。我习惯用一个叫“场景通过率 + 异常标签”的双层输出：基本面场景要求全通过，边界场景记录失败原因并按严重程度分级。仿真不是只为了过，而是为了留下“为什么没过”的证据链，给开发人员节省大量翻阅日志的时间。
4.3 数据回放是最便宜、最容易被低估的测试资产——用降级回放还原现场
仿真是前置过滤器，数据回放则是后置验尸官。真实测试里程里攒下来的数据是规控团队最珍贵的材料，尤其是带有问题标签的片段——换道失败、跟车空挡过大、弯道压线、停车点头——这些数据比任何人工构造的场景都能揭示算法缺陷，因为真实世界的噪声细节是仿真造不出来的。
回放测试的核心做法是把录制好的感知目标序列（障碍物清单、车道线、交通灯状态）按时间戳重新注入规划模块，让算法在当前代码版本下重新计算轨迹和控制指令，再观察结果。这个过程可以离线批处理，跑 1000 个场景只需要一个晚上，却能把“这个版本是不是比上个版本好”的问题回答得很具体。
# 离线回放批处理命令（示意） replay_tool \ --data_dir ./recorded_scenes/cutin_fail/ \ --algorithm_config ./config/planning_v2.yaml \ --control_config ./config/control_mpc.yaml \ --output_dir ./replay_results/ \ --metrics_file ./metrics/safety_comfort.yaml逻辑说明：回放工具读取录制数据中的感知目标序列，用当前版本的规控算法重新计算输出，最后输出关键指标和可视化结果。参数说明：algorithm_config和control_config独立拆分很有必要——如果规划和控制放在一个配置里，修改控制参数后对规划结果的影响会污染问题定位；拆开后可以单独评估控制器改进的价值。注意：回放通过不代表实车能过，因为早期的录制数据往往不包含当前版本的执行器延迟补偿差异，但回放失败一定意味着实车大概率失败，这个方向性判断对迭代很有价值。
4.4 实车验证：规控测试进入“不可完全复现”的阶段要做好哪些准备
仿真和回放搭建得再完整，最终仍然要做实车验证。原因是模型不可能完全等价于真实车辆：轮胎非线性、转向执行器摩擦、制动盘温度对制动性能的影响、路面附着系数变化，这些建模难度极高，全部依赖仿真只会让系统在边界处过度自信。
实车验证的关键管理动作是状态冻结。上实车前，算法版本、标定参数表、场景列表都要冻结，测试过程中的任何修改都必须登记，绝不允许“顺手改个参数再试一次”。经验数据是：实车上发现的问题里，有一半以上源于“上路前改了一行代码但没跑回归仿真”这种贪快行为。
实车测试的阶段也有次序：先封闭场地低速反复跑基础跟车和过弯，收集控制量曲线和跟踪误差；再做开放道路的道路测试，重点验证变道和复杂路口的决策逻辑；最后才做包含“不可预期情况”的压力测试，比如旁车强行加塞。每个阶段的准入条件依赖于前一个阶段的指标达标，这套顺序带来的好处是，即使出了问题，影响范围也被限制在可控范围内。
5. 规控开发与测试中的避坑实战：现象、根因、解决办法
5.1 轨迹“看起来平滑”但控制输出一直在抖
现象：仿真里看横向误差曲线是正常的，跟踪误差在 5 厘米内，但转向指令一直在小幅度高频抖动，实车上方向盘有持续细碎震动，严重时会导致转向系统过热保护。
原因：这一类问题 90% 不是控制器的增益问题，而是规划轨迹的曲率不连续。采样生成的轨迹在相邻轨迹点之间，如果只用多项式拟合位置而忽略曲率连续性，一阶不连续点对控制器而言相当于持续激励噪声。另一种常见来源是参考线在车道级切换处、曲率突变处没有做平滑后处理。
解决：在轨迹输出到控制器之前增加一个曲率平滑过滤器，我通常采用滑动窗口平均或者基于样条拟合的重采样。平滑窗口不宜过大，否则会引入相位延迟，导致车辆“走内涵”。建议先以 5~10 个采样点的窗口处理，观察控制抖动的频谱变化，再逐步收窄。这里有一个血泪经验：不要只调控制器里的低通滤波器，那样治标不治本。
5.2 换道时车辆先向内偏再修正，严重时蹭到车道边界
现象：开启换道功能后，车辆在变道初期先朝目标车道方向“过冲”了半个车身位，然后剧烈修正，车内明显甩动。
原因：这是典型的方向盘执行器延迟补偿不足。MPC 内部预测模型假设转向执行能在 20ms 内到位，而真实转向系统从指令发到机械动作到位有 100~200ms 延迟。预测状态比实际超前了 100ms 以上，控制器在换道的动态过程中持续进行过激修正。
解决：在控制模型里增加执行器延迟模块，最简单的方式是把转角指令经过一阶惯性环节再送进预测模型。具体时间常数先用仿真标定，再用实车数据校准。此外，换道轨迹的目标横向速度不能设太高，横向换道时间取 3 秒比 2 秒的修正超调小一个数量级。在量产里，我通常会加上“换道过程中限制横向加速度变化率”的约束，用“让车慢一点换道”换取乘客舒适度。
5.3 跟车场景突然急刹——明明目标车减速不快，但算法输出制动猛踩
现象：拥堵路段跟车，前车只是轻点刹车，自车却出线了接近全力制动的峰值减速度，车内乘员被安全带勒得明显不适。
原因：常见根因是纵向规划对目标的加速度估计使用了差分，而感知输出目标速度带有噪声，差分后噪声被放大，导致预测目标会在“减速→加速”间高频切换。规划器响应了这个虚假的加速度波动，控制层为了惩罚跟踪误差也一起配合，最终表现为猛踩刹车。
解决：先对感知输出做平滑和限幅，目标加速度估计再加一个低通滤波或者改进的自适应滤波器。更根本的修法是纵向规划里增加期望加速度变化率（jerk）的限制项，让制动指令本身不可能产生跳跃。记住一条默认准则：纵向控制里所有涉及目标车的运动状态估计，都要比自车状态多一级滤波，因为感知那边输出的是唯一数据源，错一步，控制端会被放大成百倍体感的动作。
5.4 AEB 与规控同时触发，制动“抢方向盘”——系统接管冲突
现象：前车急刹，在规划模块输出舒适的减速轨迹之前，AEB 已经介入制动，同时横向控制还在执行原来的转向路径，两个系统互相干扰，车辆跑出来的轨迹很奇怪，有轻微偏航。
原因：这是典型的多层控制系统接管权问题。AEB 属于独立安全模块，它的触发判定有自己的预测模型和阈值；规控的纵向控制器不知道 AEB 已经接管，还在按自己的轨迹计算油门制动。两者同时输出，底层执行器仲裁逻辑混乱。
解决：规控模块开发时一定要与 AEB 模块约定清晰的接管协议。通常做法是 AEB 触发后，规划模块收到override信号，立即停止输出纵向指令，横向则切换到“保持当前曲率的过渡路径”。这需要在仿真里显式构造“AEB 触发”场景来反复验证，很多团队因为知道这个场景但没测试到位，实车才发现了问题。给读者的建议：场景库里必须保留一类 AEB 交互场景，而且要在每次版本发布前跑一遍回归。
5.5 仿真全过但实车一上高速就偏航——模型仿真置信度陷阱
现象：同一套场景，仿真里全部通过且指标优秀，上实车后在弯道里轮胎啸叫、横向误差逐渐扩大，最终偏出车道。
原因：这通常是仿真车辆模型过于简化导致的。低速工况理想轮胎模型和真实模型差异不大，但高速弯道中轮胎侧偏角大，线性轮胎假设失效，侧向力计算不准，控制器实际预测的横摆角速度远低于真实值，最终横向控制动作不足。
解决：在高速场景仿真中，务必将轮胎模型切换为魔术公式或者包含侧偏角修正的简化模型，不能只用一个线性侧偏刚度走天下。在实车调校前，先做“模型验证”流程——在试验场上跑几个预定义工况，比如定圆变径、稳态回转、双移线，将仿真输出和实车跟踪结果对比。如果横向误差在弯道中随速度线性增大，基本可以断定是模型不准，而非控制器参数问题。务必记住：仿真模型标定是实车测试的前置条件，跳过这一步的团队都会付出代价。
6. 把测试结果返还到算法开发：一套贯穿版本迭代的闭环习惯
做规控算法和做其他软件最大的不同是：它的每一项改动都应该能被“量化地评价”。我的一个习惯是把所有灰度版本的仿真和回放结果汇成一张大表，然后把问题场景按优先级排序，强行要求每个版本至少解决掉前 3 个问题再发新版本。这个习惯看似简单，却能把团队从“跟着感觉调参”中解放出来。
| 版本 | 基本跟车 | 切入制动 | 弯道跟踪 | 换道平顺性 | 人工评价 |
|---|---|---|---|---|---|
| v1.2 | 92% | 88% | 85% | 74% | 转向偏激进 |
| v1.3 | 94% | 91% | 90% | 82% | 减速时机略晚 |
| v1.4 | 95% | 95% | 92% | 88% | 可接受 |
这个表格看起来简单，但真正做到并不容易，因为每一项指标背后都需要一套独立的场景集和评价脚本。表格的价值在于：它把“感觉上变好了”替换成“数字上变好了”，而这恰恰是规控工程里防止一代代堆砌补丁、最终系统臃肿难维护的唯一防线。
另一个贯穿全流程的习惯是“一个场景一个标签”——每一条失败的记录都要有明确的场景描述、触发条件和现象标签。久而久之，这个库会变成你最宝贵的资产。为什么？因为新算法版本上传时，你不用重新想测什么，只需把前 200 个高频标签直接跑回归。这个能力是后期所有算法迭代效率的地基。
日常开发中我还会强制自己保留“反例测试”的清单，即那些明知大概率失败但仍要去跑的场景。比如雨雪天的低附着路面、夜间无车道线时靠路沿行驶、车辆临近控制系统极限时的介入表现。这类场景无法通过仿真完全复现，但它的意义是帮助我们随时知道自己这套算法的边界在哪里——有边界感，比把性能再往前推一毫米更重要。
在规控领域，新入行的工程师总想先用最前沿的算法证明自己，而我的第一课往往是先建立测试回归习惯。因为算法本身的优劣，往往需要在十万公里甚至百万公里的真实场景里才能完全看清，而一个能持续复现、可追溯的测试体系，才是让每一行代码改动都知道自己改对了没有的根基。希望这套思路能帮你在规控这条路上少走几步弯路。
本文还有配套的精品资源，点击获取
