处理自动驾驶控制问题久了你会发现真正决定一辆车开起来稳不稳的往往不是规划算法有多聪明而是底层控制器在“模型已经不准了”的时候还能不能稳住。Apollo平台里被反复提到的MRAC模型参考自适应控制Model Reference Adaptive Control就是专门干这件事的。这篇内容适合正在上手Apollo控制模块的开发者也适合那些想搞清楚控制理论到底怎么落到自动驾驶实车里的同学。我会从原理讲起再拆到Apollo的工程实现细节最后把实际调参和二次开发中踩过的坑一并说出来。1. 先把MRAC的原理讲明白它到底在“自适应”什么1.1 模型误差是控制系统的“房间里的大象”我做控制这行这些年最大的感受是教科书上的控制算法都是拿精确模型推导的但工程现场拿到手的模型从来都不精确。车辆质量会变轮胎胎压和磨损会变路面附着系数会变底盘执行机构的老化程度也会变。如果你把一辆车当成一个固定不变的系统去设计控制器跑一段时间后参数早就对不上了。这就是所谓的“模型不确定性”。它分两类参数不确定性模型结构知道但里面的数值不知道。比如整车质量、空气阻力系数、轮胎侧偏刚度这些量标定过一次但之后会随载荷、胎压、温度漂移。结构不确定性模型结构本身就简化了。车辆动力学那么多非线性、时滞、执行器动态你写进控制器里的数学模型永远只是真实系统的一个近似片断。传统控制思路是先建立模型再基于模型设计固定参数的控制器。一旦模型误差变大固定增益就压不住误差了。MRAC的核心思路不是去预判误差有多大的上界而是在线调整控制器参数让闭环系统逼近期望的动态特性。说得直白点它不依赖一个特别准的模型而是靠实时反馈把参数“试”出来。1.2 参考模型、可调控制器、自适应律MRAC的三件套MRAC这个名字拆开看就清楚了。“模型参考”指的是我们先设定一个参考模型这个模型描述了我们期望车辆被控之后应该表现出什么动态行为“自适应控制”指的是控制器参数不是离线一次性算好而是根据实际跟踪误差在线调整。整套系统有三块参考模型Reference Model一个我们期望的、稳定的、性能良好的系统模型。比如希望油门踩下去之后车速变化像一个一阶惯性环节那样平滑不会超调。可调控制器Adjustable Controller控制器里有一些可以实时变化的参数比如比例增益、前馈增益。这些参数驱动被控对象让实际系统往参考模型的方向走。自适应律Adaptation Law根据实际系统输出和参考模型输出之间的误差实时调整控制器参数的规则。误差大就大幅度修正参数误差小就微调甚至冻结。可以打一个比方参考模型是驾校教练给你演示的标准动作你的车是学员控制器是你的肌肉发力方式自适应律就是教练看你动作偏差后给出的纠正信号。你每做一遍动作教练就纠正一次直到你的动作和标准动作足够接近。1.3 一个一阶系统的推导看懂误差怎么被“吸”回去理论不看公式永远隔一层。工程上最常见的MRAC推导从一个一阶被控对象开始被控对象ẋ -a x b u参考模型ẋ_m -a_m x_m b_m r其中 a_m 0说明参考模型本身是稳定的r 是参考输入比如期望加速度。注意实际系统的 a 和 b 我们并不知道精确值只知道它们存在而且 b 的正负号是已知的这带正负号在工程上对应“控制方向不能反”。控制器设计成带两个可调参数的形式u θ_x x θ_r r代入被控对象后闭环系统变成ẋ (-a b θ_x) x b θ_r r如果控制参数恰好取到理想值也就是θ_x* (a - a_m) / bθ_r* b_m / b那么闭环系统就变得和参考模型完全一样。问题是 a 和 b 未知θ* 也算不出来。所以干脆不直接算理想值而是用误差来驱动参数逼近它。定义跟踪误差 e x - x_m经过代入和化简可以得到误差动态方程ė -a_m e b(θ_x - θ_x*) x b(θ_r - θ_r*) r注意看这个结构误差的变化率由三部分构成。第一部分是参考模型自己提供的稳定项 -a_m e把误差往回拉后面两块是参数偏差乘以系统状态和参考输入。参数偏得越多对误差的驱动力越大。接着构造一个二次型的Lyapunov函数同时包含跟踪误差和参数误差V 1/2 e² b/(2γ_x)(θ_x - θ_x*)² b/(2γ_r)(θ_r - θ_r*)²对时间求导后如果自适应律选成θ̇_x -γ_x e xθ̇_r -γ_r e r那么交叉项正好全部抵消最后得到V̇ -a_m e² ≤ 0这说明跟踪误差会持续减小最终收敛到零。整个推导里最漂亮的地方在于我们根本不需要知道 a 和 b 的具体数值只需要保证 b 的符号已知θ* 是否存在不要求我们知道。自适应律自己会去找那个目标参数。这种基于Lyapunov函数设计的MRAC保证了渐近稳定性比早期MIT规则那种基于梯度的近似方法要稳得多。Apollo里用的就是这套Lyapunov设计框架因为自动驾驶场景对稳定性要求很苛刻不太能接受“至少局部稳定”这种结论。2. Apollo控制模块里的MRAC定位与价值2.1 Apollo控制模块在整条链路里负责什么先说清楚Apollo的整体工作流程。感知模块输出障碍物和车道线定位模块给出车辆位置姿态规划模块生成一条包含速度、加速度、曲率的参考轨迹。到了控制模块任务就是在每一个控制周期内计算出方向盘转角、油门开度、刹车压力让车沿着参考轨迹走。Apollo控制模块的输入包括参考线、车辆实时状态位置、朝向、速度、加速度以及底盘反馈信号。输出是底盘控制命令。整个控制模块内部又分为横向控制和纵向控制两大块横向控制跟踪参考轨迹的横向位置偏差和航向角偏差输出前轮转角纵向控制跟踪期望速度和期望加速度输出油门和刹车百分比。MRAC这两个方向都能用。在横向控制里它补偿轮胎参数变化和车辆动力学模型误差在纵向控制里它补偿质量、坡道阻力和风阻带来的加速度偏差。Apollo官方在纵向控制中引入MRAC的设计意图正是为了让车辆在不同载荷、不同坡道条件下依然能准确跟踪期望加速度而不是像纯PID一样靠固定参数硬扛。2.2 横纵向控制的不确定性远比你想的多很多刚接触车辆控制的人会低估模型误差的严重程度。其实一辆车的纵向动力学模型写出来大致是这个形式m a F_drive - F_brake - F_roll - F_aero - F_grade每一项都有误差。整备质量 m 在空车和满载之间可能差出30%以上滚阻系数受轮胎胎压影响空气阻力受车速和风速干扰坡度阻力的坡度信息虽然可以从地图得到但实时性和精度都有限。如果控制器把所有这些都当成常量处理那遇到一个大坡或者一次满载工况加速度跟踪误差会非常难看。横向控制同样复杂。线性二自由度自行车模型里的关键参数“轮胎侧偏刚度”会随着轮胎磨损、胎压、载荷转移、路面附着系数发生大幅变化。这些参数经常偏离标称值30%以上。用偏得离谱的模型去算LQR或者MPC算出来的最优控制输入自然是不准确的。MRAC的价值就在于它把这些误差当成未知但有界的因素不追求事先建模精确而是靠自适应机制在线补偿。这在工程上的意义很大因为“把参数测量精确”的成本远高于“让控制器适应参数变化”。2.3 为什么不靠PID、LQR或者MPC硬扛有人会问PID不也能自适应吗把增益调得大一点不就能抵抗扰动了吗这是两个层次的问题。PID的积分项确实能消除稳态误差但面临的问题是相位滞后和积分饱和。干扰大的时候积分累计过多超调就来了车辆容易来回振荡。而且PID不包含任何关于被控对象的“期望动态特性”它只是在压误差不是把系统引向一个精心设计的动态。LQR和MPC的问题在于对模型精度的依赖。LQR需要准确的A、B矩阵MPC更是把预测模型用作优化核心。模型差个30%优化出来的控制量自然差得离谱。MPC还能靠滚动优化和约束处理救回来一部分LQR则是纯粹的开环模型补偿加上闭环状态反馈模型误差直接影响控制效果。MRAC的优势在于它用在线参数调整代替了离线的精确建模。它不需要你给一个特别准确的“标称模型”只要参考模型设得合理自适应律就会把实际系统往参考模型方向拉。这相当于给固定模型控制器加了一层“在线校正器”。当然MRAC也不是万能的它不擅长处理硬约束也不擅长复杂非线性所以在Apollo里它更多是作为PID或者LQR控制器的补充层存在而不是完全替代。3. 拆解Apollo中MRAC的关键设计与实现思路3.1 系统模型怎么建状态量怎么选真正上手写MRAC之前第一步是把被控对象的状态量选好。Apollo的纵向控制MRAC中状态量通常取速度误差和加速度误差构成的增广状态。参考模型一般取一个二阶线性系统代表期望的加速度跟踪动态s_ref(s) ωₙ² / (s² 2ζωₙ s ωₙ²)这里的 ωₙ 和 ζ 分别代表参考模型的自然频率和阻尼比。直观解释就是你希望车辆对期望加速度的响应像一个质量-弹簧-阻尼系统那样上升时间适中、没有明显超调。ωₙ越大响应越快但真实车辆执行器有延迟目标定得太快反而稳定不住。为什么不直接用一阶模型因为车辆纵向加速度本身是一个状态速度是加速度的积分从期望加速度到底盘响应再到速度变化中间至少是二阶关系。用一个二阶参考模型能更准确地表达“速度跟随期望速度”的动态过程同时也不至于高阶到让自适应律过于复杂。在横向控制里状态量选择略有不同常见的是横向偏差、航向角偏差、横摆角速度和横向速度。MRAC在横向上的典型任务是实时估计等效的轮胎侧偏刚度或者补偿前轮的等效转角偏差。模型用线性二自由度自行车模型作为基础结构但参数是可变的。3.2 参考模型和自适应律的设计细节参考模型设计是MRAC里最讲究玄学的地方。参考模型太快自适应控制器得使出浑身解数去追一个物理上追不上的信号输出会剧烈摆动参考模型太慢控制效果会显得很肉车辆跟线慢吞吞的变道感觉像在漂移。我的经验是参考模型的带宽设定要基于执行器的真实物理极限。Apollo的纵向控制周期一般是10到20毫秒正常乘用车的油门和刹车响应时间在200到500毫秒。参考模型的自然频率不宜超过真实执行器响应频率的1/2到1/3。比如底盘响应带宽是1Hz参考模型带宽定在0.3到0.5Hz就比较稳妥。自适应律的设计重点在于参数增益和修正方向。标准形式已经推导过了增益 γ 的选择影响参数收敛速度。在Apollo工程实现中自适应律不会直接用原始状态信号而是先把信号过一次低通滤波降低高频噪声对参数更新的污染。原因是车辆上的速度信号经过传感器采集之后有噪声直接用原始信号求误差再求参数导数很容易把噪声当成扰动去调节参数导致参数一直在抖。这类工程化处理在教科书里往往一笔带过但在实车上要是不处理参数抖动直接反映到油门和刹车上乘客体验会非常差。3.3 稳定性证明之外的工程兜底理论上Lyapunov函数证明了渐近稳定前提是理想条件成立没有未建模动态、没有测量噪声、参数变化速度足够慢、参考输入持续激励。实际的工程条件个个都违反这些假设所以稳定性的保证之外Apollo的MRAC实现还需要几层兜底参数投影给控制器参数设定上界和下界防止参数漂移到不合理范围。比如等效质量参数不可能为负也不可能超过满载质量的某个倍数。死区策略当跟踪误差小于某个阈值时冻结自适应律的更新防止微小噪声持续累积参数漂移。参数变化率限幅即使误差很大单次参数更新量也不能过大避免参数阶跃导致控制量冲击。抗积分饱和设计当油门或刹车达到执行器限位时停止参数更新否则参数会继续累积但输出已经饱和下个周期会出现严重的超调。这一块是MRAC从论文走向Apollo实车的关键。理论证明保证的是“路最后能走到头”工程兜底保证的是“路上不撞墙”。没有这些兜底MRAC在仿真里跑得再漂亮上了车也是白搭。3.4 Apollo中的MRAC与常规PID/LQR的配合逻辑这里要澄清一个常见误解Apollo引入MRAC不是要把PID和LQR全部换成一套新控制算法而是在保留经典控制框架的基础上增加一个自适应补偿环节。纵向控制的典型配合是上层计算期望加速度这个加速度先通过一个基于标定表的逆模型映射成油门或刹车百分比作为前馈然后误差信号通过PID或MRAC修正前馈量。MRAC在这里的作用是修正标定表和实际车辆响应之间的偏差。空载时标定表可能很准满载时偏差就出现了MRAC在线调整的是这个修正增益。横向控制的典型配合是标称模型算出一个LQR最优反馈增益然后使用MRAC补偿模型参数误差带来的残余偏差。这样做的优点很明显LQR的稳定性和MPC的约束处理能力都保住了MRAC负责把前端模型偏差造成的性能损失补回来。这也是Apollo选择“保留经典控制器叠加自适应层”的原因工程上改动小、回退容易、效果可量化比彻底推翻重构要实用得多。4. 实践记录调参、部署与常见问题4.1 拿到配置项后推荐的参数整定顺序动手调Apollo控制参数之前强烈建议先建立一个参照系比如在同一个固定场景直线加速、匀速巡航、定曲率弯道下录制一组“关掉MRAC”的基线数据。后面所有自适应参数的调整效果都跟这个基线比才有意义。参数整定顺序我给一个保守但有效的路径先定参考模型的时间和阻尼比。先给一个比实际执行器响应慢一些的模型确认车能稳定跟上再逐步加快。再调自适应增益。从非常小的值开始比如0.01量级观察跟踪误差的收敛速度和参数更新量的波动。逐渐加大直到误差收敛速度满意但参数更新曲线仍然平滑。然后配置参数投影边界。观察正常工况下参数收敛到哪个范围把边界定在留有一定余量的区间。最后调节死区和限幅。这个取决于你们对乘客舒适性的要求死区太大会让误差一直存在没有补偿太小会让参数始终在抖动。这四步做完之后建议跑一遍多工况测试空载和满载、平路和坡道、低速和高速。MRAC的价值恰恰体现在工况切换时的自适应速度上所以必须专门测工况切换场景。比如空载跑完马上满载跑看加速度跟踪误差的峰值有多大、多久回落到可接受范围。4.2 常见问题与排查速查表MRAC实车调试中遇到的问题其实高度集中整理成一个速查表方便排查典型现象可能原因优先排查方向参数长时间不收敛自适应增益太小或参考输入缺乏持续激励增大增益在匀速段考虑冻结参数参数高频抖动信号噪声污染自适应增益偏大检查滤波截止频率降低增益控制量阶跃冲击参数更新限幅不够或投影边界过宽加大变化率限幅缩小参数边界加速度跟踪持续偏差死区设置过大误差落在死区内缩小死区检查参考模型是否过快满载后跟踪变差自适应参数尚未收敛到新工况增大增益检查参数投影是否卡边界高速时出现振荡参考模型带宽过高或执行器响应跟不上降低参考模型频率增加相位裕度这几个问题里最隐蔽的是“参考输入缺乏持续激励”。MRAC的自适应律需要参考输入足够“丰富”才能让参数持续可辨识。车辆长时间匀速直线行驶时参考输入基本恒定参数辨识条件不充分可能出现参数不收敛但不影响跟踪的现象。遇到这种情况不一定要强行让参数收敛合理做法是在匀速段降低参数更新的权重避免参数在不充分激励下漂到奇怪的位置。4.3 我的几条实在建议第一MRAC并不是越复杂越好。别一上来就写带高增益观测器、带扰动观测器的“豪华版”MRAC。Apollo本身已经提供了稳定的基础控制框架先在小范围内验证标准MRAC的价值再考虑扩展。第二仿真验证一定要带上模型不确定性。很多人只在标称模型下测试MRAC调出来的参数一点鲁棒性都没有。在仿真里故意把车辆质量增加20%、轮胎刚度降低15%MRAC的优势才看得出来。第三数据采集和回放别偷懒。我用Apollo开发时会把控制模块的关键信号期望加速度、实际加速度、参考模型输出、自适应参数、油门刹车命令整包记录下来。调参过程中哪些改动产生了什么效果全靠回放对比才能确认。很多线上异常问题事后翻数据回放比现场排查效率高得多。第四MRAC的参数不是越多越好。参数过多会导致自适应律调节的是同一个方向的多余自由度反而容易激发参数耦合振荡。能用两个参数解决的问题绝对不要用四个参数。4.4 一个我印象很深的实测场景说一个我印象很深的实测案例。某次做满载标定测试车上坐了四个人加上后车厢堆满设备总质量比标称值多了大概25%。按标称模型调好的PID纵向控制器在60km/h匀速巡航时遇到一段约4%的坡道速度掉到55km/hPID积分扛了半天才把速度拉回来超调又冲到63km/h整个坡道段的速度曲线像条波浪。换成MRAC之后同一个坡道初次驶入时速度还是掉了一点但自适应参数大概在2秒内完成了显著调整第二次驶入同一条坡道时速度偏差已经明显缩小第三次基本看不出掉了。这就是“自适应”三个字的含义不依赖先验精确建模靠在线修正一步步逼近理想性能。那次之后我对MRAC的工程价值有了很实在的认识。它不能替代一个好的基础控制器也不能让一个物理上就做不到快速响应的底盘变得身轻如燕但它能在模型不准确的时候把控制性能从“不可接受”拉回到“基本可用”再调优到“表现不错”的水平。对Apollo这种面向真实道路环境的自动驾驶平台来说这一个能力就足够让MRAC有它存在的必要。