夜雨聆风
从飞控转自动驾驶，我最先困惑的是控制
写飞控那几年，PX4的串级PID是我最熟悉的武器。位置环50Hz、速度环50Hz、姿态环250Hz、角速度环直接干到1000Hz。四层PID嵌套，外层输出喂给内层，最内层以2.5毫秒的周期死磕电机PWM。这套架构飞了无数架飞机，稳定得像物理定律。
转到自动驾驶，打开Apollo的modules/control/目录，我愣了一下。
三个子目录：mpc_controller、lat_based_lqr_controller、lon_based_pid_controller。三套控制器并排摆着，不是串联，是可选。
PX4那种从位置一路串到角速度的四层嵌套，在Apollo里压根不存在。取而代之的是横向和纵向的解耦思路，每条路上挂一套独立控制器。
控制模块到底干什么
据Apollo官方文档（https://apolloauto.readthedocs.io/en/latest/howto/how_to_tune_control_parameters/ ）描述，控制模块接收三样输入：规划轨迹、当前车辆状态、HMI驾驶模式指令，输出方向盘、油门、刹车控制命令。规划告诉你未来沿这条曲线走，控制负责算出此刻方向盘打多少度、油门踩多深。
据51CTO博客对Apollo源码的分析（https://blog.51cto.com/u_15941409/14427989 ），ControlComponent继承自TimerComponent，定时执行。流程是数据校验、Pad指令检查、调度控制器生成ControlCommand、俯仰角补偿、发布指令。
我在实车上跑过这套流程。TrajectoryAnalyzer先做轨迹匹配——找到当前时刻在规划轨迹上最近的点，算出横向误差、航向误差、纵向位置误差。这些误差就是控制器的输入。
MPC：用QP求解未来10步的最优控制
打开mpc_controller.h（https://tracelessle.github.io/apollo6.0-doxygen/html/mpc__controller_8h_source.html ），几个关键常量跳出来：
constint basic_state_size_ = 6;
constint controls_ = 2;
constint horizon_ = 10;
6个状态量、2个控制量、预测步长10。状态向量是[e_y, e_y_dot, e_theta, e_theta_dot, e_s, e_s_dot]，分别是横向误差、横向误差变化率、航向误差、航向误差变化率、纵向位置误差、纵向速度误差。控制量是方向盘转角delta_f和加速度a。
MPC的思路说白了：每个控制周期，基于当前状态预测未来10步的轨迹，同时优化这10步的控制输入序列，使得代价函数最小。代价函数长这样：
J = Σ[x(k)ᵀ Q x(k) + u(k)ᵀ R u(k)]
Q矩阵惩罚状态偏差，R矩阵惩罚控制量大小。约束包括系统动力学方程x(k+1) = A·x(k) + B·u(k)、控制输入上下界、状态上下界。
据DeepWiki对Apollo源码的分析（https://deepwiki.com/ApolloAuto/apollo/6.1-mpc-controller ），Apollo用OSQP求解器来解这个QP。MpcOsqp类把整个MPC问题打包成标准QP形式——稀疏矩阵P和q构成代价函数，约束矩阵A配合上下界l和u。每次控制周期调一次Solve()，拿到最优控制序列，只用第一步。
滚动优化。下一周期重新测量状态，重新求解。这是MPC和LQR的根本区别——MPC每步都在解一个优化问题，LQR一次性算好增益矩阵，之后只是矩阵乘法。
MPCController类里还有几个值得注意的方法。UpdateState负责从定位和底盘数据更新当前状态向量，UpdateMatrix在每个周期重新计算离散化的状态转移矩阵A_d和控制矩阵B_d——因为速度变了，动力学矩阵就变了。FeedforwardUpdate做前馈补偿，利用路径曲率信息提前给出方向盘转角，减少稳态误差。ComputeLateralErrors和ComputeLongitudinalErrors分别算横向和纵向误差，前者依赖位置和航向，后者依赖TrajectoryAnalyzer的匹配结果。这些方法串起来就是一次完整的控制周期：更新状态、更新矩阵、前馈补偿、求解QP、输出指令。
源码里还有数字滤波器的初始化逻辑，InitializeFilters根据配置文件设置截止频率和滤波器系数。方向盘输出前要过一道低通滤波，避免QP求解结果的高频抖动直接灌进转向执行器。这个细节我在实车上踩过坑——滤波器截止频率设太高，方向盘会抖；设太低，响应延迟，弯道入口总是慢半拍。
LQR：Riccati方程一次解，后面全是乘法
LQR控制器在lat_based_lqr_controller目录下。据Apollo官方调参文档，横向LQR控制器的车辆模型是带侧滑的bicycle model——动力学模型，不是纯运动学模型。状态量4个：横向误差、横向误差变化率、航向误差、航向误差变化率。
LQR的核心是求解离散Riccati方程，拿到最优状态反馈增益K。控制律极其简洁：u = -K·x。K矩阵在车辆参数和速度确定后可以离线计算，运行时只做一次矩阵乘法。
配置文件里Q矩阵的4个对角元素分别对应横向误差权重、横向误差率权重、航向误差权重、航向误差率权重。Lincoln MKZ的典型配置是matrix_q: [0.05, 0.0, 1.0, 0.0]——航向误差权重最高，横向误差率权重为零。航向跟住了，横向位置自然收敛。调参顺序文档写得很清楚：先调航向误差权重消除航向偏差，再调横向误差权重收敛位置。
车辆参数写得细：前后轮侧偏刚度cf和cr、轴距wheelbase、整车质量mass、质心到前后轴距离lf和lr、转动惯量iz。这些参数直接进动力学方程构建状态矩阵A和控制矩阵B。速度变化时A和B会变，Apollo在不同速度下重新计算增益——这是和固定增益PID的本质区别。
源码里有个SolveLQRProblem函数，接收连续时间的A和B矩阵，先做离散化得到A_d和B_d，然后迭代求解离散Riccati方程直到收敛。迭代次数和收敛阈值在配置文件里可调，默认最大迭代100次。每次速度变化超过阈值就重新算一遍增益，算完缓存下来，下一个周期直接用。我在调试时发现一个现象：速度从30km/h跳到60km/h的瞬间，增益矩阵K的变化幅度不小，方向盘指令会有一个明显的阶跃。解决方式是在速度变化时做增益插值平滑，不让K矩阵跳变。
PID：纵向速度跟踪，级联加标定表
纵向控制用PID，代码在lon_based_pid_controller。不是单环，是级联结构——位置PID外环输出喂给速度PID内环。位置控制器输出期望速度修正量，速度控制器输出期望加速度。
高速和低速用不同PID参数。典型配置：高速时kp=1.0, ki=0.3, kd=0.0，低速时kp=0.5, ki=0.3, kd=0.0。切换速度一般设在一个coasting speed附近。
PID输出加速度后，还要过一道标定表。这张表是实车测出来的查找表，把目标加速度映射成具体的油门开度百分比或刹车压力。不同车速下同样的加速度需求对应不同的踏板开度，标定表补偿的就是这种非线性。
Apollo还在PID上加了数字滤波器做噪声抑制，前馈控制器做相位补偿。这些都是在基础PID上打补丁，弥补PID本身没有模型预测能力的短板。
默认为什么是LQR+PID而不是MPC
这是个好问题。Apollo的默认配置是LQR管横向、PID管纵向。MPC作为可选项存在，不是默认。
原因可以拆成几层。
MPC每次控制周期都要解一个QP。状态维度6、控制维度2、预测步长10，决策变量规模不算大，但OSQP的求解时间不是零。据DeepWiki分析，OSQP的收敛速度依赖问题条件数，最大迭代次数和收敛容差都可配置。LQR呢？增益矩阵K预先算好，运行时只做一次1乘4的矩阵乘法——K是1×4的行向量，乘上4维状态向量，直接输出方向盘转角。在嵌入式控制器算力有限的车载平台上，这个差距是实打实的。
约束处理是MPC的杀手锏。方向盘转角上限、加速度上下界、方向盘转速限制，MPC能显式塞进优化问题里。LQR做不到——它只管最优，不管约束。遇到约束边界，LQR的输出可能物理上不可执行，只能靠后处理硬裁剪。
那默认还用LQR？因为LQR+PID在大多数场景下够用了。直线巡航、温和变道、常规跟车，LQR的跟踪精度和MPC差距不大。真正需要MPC发力的极端场景——急转弯、大曲率连续弯道、紧急避障——在量产L2/L3里频率不高。工程上够用就是最好的选择。
和PX4的四层串级PID放一起看
据PX4官方文档（https://docs.px4.io/v1.15/en/flight_stack/controller_diagrams ），多旋翼控制架构是教科书级的串级PID：位置环P控制器、速度环PID、姿态环P（四元数）、角速度环PID。四层从外到内频率递增，最外层50Hz，最内层1000Hz。外层输出是内层的设定值，信号从上往下流，反馈从下往上回。
Apollo的思路完全不同。不搞多层级联，把控制问题拆成横向和纵向两个独立维度。横向用模型预测控制或LQR，纵向用PID。没有外层输出喂内层的串级结构，每套控制器直接算出最终控制量。
原因在于被控对象不同。多旋翼是欠驱动系统，四个电机直接控制六个自由度，姿态和位置强耦合——不调姿态就没法控制水平位置。串级PID天然适合这种耦合：先稳住角速度，再稳姿态，再稳速度，再稳位置。
汽车不一样。方向盘直接管横向，油门刹车直接管纵向，两个维度基本解耦。横向和纵向可以独立设计控制器，不需要串级结构。Apollo用bicycle model描述横向动力学，把轮胎侧偏特性纳入模型，比纯PID更准。纵向更简单，速度跟踪用PID加标定表就够了。
争论一：MPC还是LQR
技术社区吵了好几年的问题。MPC能处理约束，LQR不能。MPC每步解QP，LQR只做矩阵乘法。MPC可以预测未来，LQR只有瞬时反馈。
支持MPC的人说，自动驾驶的安全场景就是约束边界场景——方向盘打到极限、急刹到轮胎抱死。这些场景下MPC的约束处理能力是保命的能力。LQR在约束边界处行为不可预测，只能靠硬裁剪，裁完了就不再最优。
支持LQR的人说，车载控制器算力有限，MPC的QP求解时间在最坏情况下不可控。OSQP虽然有迭代上限，但收敛速度依赖问题条件数。如果QP发散，MPC输出的控制指令可能比PID还差。LQR的增益矩阵离线算好，运行时零不确定性。
我的看法：Apollo的做法其实给了答案——默认LQR+PID兜底，MPC作为高性能选项。不是非此即彼，是分层兜底。但这也引出一个工程问题：两套控制器的行为一致性怎么保证？LQR和MPC在同一个弯道给出的方向盘角度可能差好几度，切换瞬间的跳变怎么处理？Apollo的源码里我没找到特别优雅的平滑过渡机制。
争论二：bicycle model够不够用
Apollo的LQR和MPC用的都是bicycle model——把汽车简化成一根车轴上前后两个轮子。模型里只有侧偏刚度cf和cr，没有轮胎的非线性特性、没有悬架动力学、没有路面附着系数。
这个简化在低速和干燥路面下问题不大。高速过弯或湿滑路面时，bicycle model的预测精度明显下降。轮胎侧偏力在大侧偏角下进入非线性区，bicycle model的线性假设失效。有团队在GitHub上提过issue，反映Apollo的LQR在80km/h以上大曲率弯道横向误差明显增大。
完整车辆动力学模型需要更多参数——Pacejka轮胎模型参数、悬架K&C特性、空气动力学系数——标定成本极高。bicycle model只需要cf、cr、mass、lf、lr、iz六个参数，工程上可落地。这是精度和工程可行性的经典权衡。学术上可以用完整轮胎模型加多自由度悬架动力学，但参数标定的成本和时间周期在量产项目中不可接受。
留个问题
PX4用四层串级PID飞了十年，Apollo用bicycle model加LQR跑了百万公里。两套系统被控对象不同，不能直接类比。但有个问题一直困扰我：如果给汽车也上四层串级PID——位置环管轨迹跟踪、速度环管纵向、横摆角速度环管横向稳定性、转向角环管执行器——理论上行得通，为什么没有主流自动驾驶公司这么做？
PID的调参经验积累太厚是原因之一。但更深层的原因，我猜是控制频率。PX4最内层1000Hz，汽车CAN总线控制周期通常100Hz。频率差一个数量级，串级PID的内环增益来不及响应。
这个猜测对不对，我不确定。欢迎拍砖。
