1. 从“单步贪心”到“滚动时域”MPC算法演进的底层逻辑很多人第一次接触模型预测控制Model Predictive Control, MPC脑子里蹦出来的画面是“解一个带约束的优化问题”。这个印象不算错但它只描述了MPC的“当下形态”完全没解释它为什么会长成今天这个样子。我在实际做控制器开发的时候踩过最大的一个坑就是把MPC当成一个静态的数学工具去用结果遇到模型失配、工况突变的时候控制器表现得像个“书呆子”——明明约束都满足但就是控制效果差得离谱。后来我才意识到MPC的每一次算法迭代背后都是被真实工程问题“逼”出来的。你不理解这些问题的来龙去脉就永远只能照猫画虎地调参而不知道参数背后的物理意义。这一篇我想把MPC算法的发展进程掰开揉碎了讲清楚。不是按时间线流水账式地罗列而是按“每一代算法解决了上一代的什么痛点”这个逻辑来展开。你会看到从最早的启发式思想到如今和深度学习、分布式计算结合的前沿方向MPC的演化路径其实非常清晰每一步都在回答同一个问题——如何在计算资源有限、模型不完美、环境不确定的条件下依然做出“足够好”的控制决策。如果你正在做自动驾驶、机器人、过程控制、能源管理这些领域的控制算法开发或者你是个研究生正在啃MPC的论文这篇文章应该能帮你把散落在各处的知识点串成一条线。我会尽量用生活化的类比来解释那些看起来吓人的数学概念同时把关键的技术细节和实操中的坑都摊开来讲。1.1 为什么MPC的思想源头比你以为的要早得多很多人以为MPC是上世纪七八十年代才冒出来的东西其实它的核心思想——“预测未来、滚动优化”——在更早的控制实践中就有雏形了。上世纪六十年代过程控制领域有一批工程师在处理化工反应釜、精馏塔这类大滞后、强耦合的系统时发现传统的PID控制器根本搞不定。PID的逻辑是“看当前误差调当前输出”但化工过程的响应往往滞后几分钟甚至几十分钟等你看到误差再调黄花菜都凉了。这批工程师的做法很朴素他们根据对过程机理的理解在脑子里或者纸上“推演”一下未来一段时间系统会怎么走然后提前把控制量调好。这种“人肉预测”虽然粗糙但它抓住了MPC最本质的东西——利用模型信息来补偿反馈的滞后。后来法国工程师Richalet在1978年正式提出了“模型预测启发控制”Model Predictive Heuristic Control, MPHC这被公认为MPC的正式起点。注意“启发”这个词说明当时的算法还带有很强的经验色彩理论保证并不完善。紧接着Cutler和Ramaker在1980年提出了动态矩阵控制Dynamic Matrix Control, DMC这个算法在壳牌公司的炼油厂里跑通了一下子让工业界看到了MPC的实用价值。DMC的核心是用阶跃响应模型来预测未来输出然后通过最小化预测误差和控制量增量的加权平方和来求解控制律。它的出现标志着MPC从“启发式”走向了“算法化”。但DMC有个硬伤它处理约束的能力很弱基本上只能靠事后裁剪来勉强满足约束这在安全要求高的场景里是致命的。1.2 约束处理MPC真正甩开其他控制器的分水岭如果说预测是MPC的灵魂那约束处理就是MPC的杀手锏。我经常跟团队里的新人说你如果只把MPC当成一个“多步预测的PID”那你就白学了。MPC真正厉害的地方在于它能把系统的物理限制、安全边界、执行器饱和这些“硬约束”直接写进优化问题里在求解控制律的时候就保证约束不会被违反。这个能力在工业界有多重要举个例子。假设你在控制一个机械臂关节力矩有上限工作空间有障碍物。用PID或者LQR你只能先算出控制量然后发现力矩超了再截断或者发现要撞了再紧急刹车。这种“先犯错再纠正”的逻辑在高速场景下根本来不及。而MPC在每一步优化的时候就把力矩上限和障碍物约束作为不等式条件放进去解出来的控制量天然就是安全的。这就是约束最优控制的威力。但约束的引入也带来了巨大的计算负担。早期的MPC因为算力不够只能用在采样周期很慢的过程控制里比如几秒甚至几分钟一次。直到上世纪九十年代末到本世纪初随着内点法、有效集法这些凸优化算法在嵌入式处理器上的落地MPC才开始在机器人、无人机这些快动态系统上普及。我印象很深的是2010年前后很多做四旋翼的团队还在用显式MPCExplicit MPC来规避在线求解就是把优化问题的解预先算好存成查找表。现在回头看那真是算力匮乏时代的无奈之举。1.3 从线性到非线性MPC算法演进的一条主线MPC算法发展的另一条主线是模型复杂度的提升。最早的DMC、MAC模型算法控制用的都是线性模型因为线性模型的预测和优化都有闭式解或者高效的数值解法。但现实世界是非线性的——机器人的动力学是非线性的电池的充放电特性是非线性的化工过程的反应速率也是非线性的。用线性模型去近似在工况偏离工作点的时候就会出大问题。于是非线性MPCNonlinear MPC, NMPC成了研究热点。NMPC的预测模型是非线性的优化问题也变成了非凸的求解难度指数级上升。我读博的时候实验室里做NMPC的师兄最头疼的就是“局部最优解”问题——求解器经常收敛到一个次优解控制器表现时好时坏。后来大家开始用序列二次规划SQP、内点法IPM这些数值方法配合热启动warm start技巧才把NMPC的实时性做到了可接受的水平。但NMPC的计算量依然是个大问题。一个典型的NMPC问题如果预测时域是20步控制时域是5步状态维度是12维那优化变量就有60个约束可能有上百个。在嵌入式平台上每毫秒要解这么一个问题对算力和内存都是严峻考验。所以工业界在实际落地的时候往往会在“模型精度”和“计算负担”之间做折中——要么用线性化模型加误差补偿要么用神经网络来拟合非线性动力学这就是后来数据驱动MPC的雏形。2. 工业MPC的黄金时代DMC、MAC与QDMC的三足鼎立上世纪八十年代到九十年代是工业MPC的黄金时代。那时候的过程控制领域谁要是能在DCS分布式控制系统里嵌一个MPC模块那绝对是技术实力的象征。这个时期涌现了三个最具代表性的算法DMC、MAC和QDMC。它们各有侧重但共同奠定了工业MPC的基本框架。我翻过不少那个年代的工程报告发现一个很有意思的现象这些算法的诞生几乎都是被具体的工业痛点逼出来的而不是在象牙塔里凭空想出来的。2.1 DMC用阶跃响应说话让现场工程师也能看懂DMC动态矩阵控制的核心思想非常直观它用系统的阶跃响应系数来构建预测模型。你给系统一个阶跃输入记录输出随时间的变化得到一组响应系数这组系数就代表了系统的动态特性。预测的时候把未来控制量增量的影响叠加到当前输出上就得到了未来输出的预测值。这个做法为什么能在工业界迅速推广因为它不需要精确的机理模型。在化工、炼油这些领域很多过程的机理复杂到根本写不出准确的微分方程但做阶跃响应测试却是现场工程师的日常操作。DMC把“建模”这件事从“推导方程”变成了“做实验测数据”门槛一下子降低了很多。但DMC的局限性也很明显。首先它只适用于开环稳定的系统对于积分过程或者不稳定过程需要先做预处理。其次它处理约束的能力很弱基本上只能靠“截断”来满足输入约束输出约束更是很难保证。我见过一个老旧的DMC控制器在工况突变的时候因为输出约束没处理好导致反应釜温度冲破了安全上限幸好有紧急停车系统兜底。这件事让我深刻认识到没有约束处理能力的MPC在安全关键场景里就是个定时炸弹。2.2 MAC脉冲响应模型与参考轨迹的巧妙结合MAC模型算法控制和DMC几乎是同期出现的它的建模思路是用脉冲响应系数。你给系统一个脉冲输入记录输出的衰减过程得到一组脉冲响应系数。预测的时候用卷积和的形式来计算未来输出。MAC的一个亮点是引入了参考轨迹的概念——它不是让输出直接去跟踪设定值而是让输出沿着一条平滑的曲线逐渐逼近设定值。这个设计非常巧妙。在工业过程中设定值的阶跃变化往往会导致控制量剧烈波动进而引发执行器的磨损和能耗的浪费。参考轨迹相当于给系统加了一个“软启动”让过渡过程变得平缓。我在做温度控制的时候就借鉴了这个思路把设定值的变化率限制住效果立竿见影——超调量降了一半调节时间只增加了不到10%。但MAC也有自己的问题。脉冲响应模型对噪声非常敏感因为脉冲响应在时域上是衰减的如果测量有噪声辨识出来的脉冲响应系数就会失真。而且MAC的预测时域必须覆盖到脉冲响应衰减到零的时间对于慢过程来说这个时域会非常长计算量也就上去了。所以MAC在实际应用中往往需要配合滤波器来抑制噪声或者用阶跃响应模型来替代。2.3 QDMC把二次规划引入MPC约束处理终于有了理论保证QDMC二次动态矩阵控制是DMC的升级版它的核心改进是把优化问题从“最小二乘”升级成了“二次规划”Quadratic Programming, QP。QP的标准形式是在线性约束下最小化一个二次目标函数。QDMC把输入约束、输出约束、控制量增量约束都写成线性不等式然后调用QP求解器来求解。这个改进的意义是革命性的。它第一次让MPC的约束处理有了严格的理论保证——只要QP问题可行解出来的控制量就一定满足所有约束。而且QP问题如果是凸的目标函数是二次的约束是线性的那局部最优解就是全局最优解不存在陷入次优解的烦恼。但QP的求解计算量比最小二乘大得多。在八十年代的计算条件下一个中等规模的QP问题可能需要几秒甚至几十秒才能解出来。所以QDMC最初只能用在采样周期很慢的过程控制里。我查过一些老资料当时有些工厂为了跑QDMC专门配了一台小型机来做优化计算DCS只负责数据采集和执行。这种“上位机优化下位机执行”的架构一直延续到了今天的很多工业MPC系统里。2.4 这个时期MPC算法的共同短板模型失配与鲁棒性缺失DMC、MAC、QDMC虽然各有千秋但它们有一个共同的软肋对模型失配非常敏感。这些算法都假设预测模型是准确的如果实际系统特性和模型有偏差控制性能就会急剧下降甚至导致闭环不稳定。我在现场调试的时候遇到过好几次因为阀门特性变化导致模型失配MPC控制器开始振荡的情况。那时候的解决办法很笨——重新做阶跃响应测试更新模型系数。但这个过程耗时耗力而且如果工况频繁变化根本来不及更新。这个痛点直接催生了下一阶段的算法演进鲁棒MPC和自适应MPC。鲁棒MPC的思路是在建模的时候就把不确定性考虑进去设计一个对模型误差不敏感的控制律。自适应MPC的思路是在线辨识模型参数实时更新预测模型。这两条路线后来都发展出了丰富的理论体系我将在下一节详细展开。3. 鲁棒与自适应当MPC遇上“不听话”的真实系统真实系统从来不会乖乖按照你建的模型去运行。阀门会磨损催化剂会老化环境温度会变化负载会波动。这些因素导致模型和实际系统之间永远存在偏差。鲁棒MPC和自适应MPC就是专门对付这个问题的两把利器。我在实际项目里这两种方法都用过各有各的适用场景也各有各的坑。3.1 鲁棒MPC把不确定性“框”起来用保守换安全鲁棒MPC的核心思想是我不去猜模型误差具体是多少我只假设误差在一个已知的范围内比如参数在某个区间内变化或者存在有界的外部扰动。然后我设计一个控制律使得在这个范围内无论误差取什么值闭环系统都能保持稳定并满足约束。这个思路听起来很稳妥但代价是保守性。因为你要保证“最坏情况”下的性能所以控制动作往往会偏保守导致正常工况下的控制效果不够激进。我做过一个对比实验同一个温度控制系统用名义MPC不考虑不确定性的时候调节时间只要5分钟但模型失配后会振荡用鲁棒MPC的时候调节时间变成了8分钟但模型失配后依然稳定。这3分钟的代价换来了安全性的巨大提升在安全关键场景里是完全值得的。鲁棒MPC的一个经典方法是管束MPCTube MPC。它的思路是把实际状态分解成“名义状态”和“误差状态”名义状态按照名义模型演化误差状态被限制在一个“管束”里。控制律的设计保证误差状态始终在管束内而名义状态满足约束。这样就把一个不确定性问题转化成了确定性问题求解起来方便很多。但管束MPC的保守性也比较明显因为管束的半径是根据最坏情况算出来的实际误差往往比最坏情况小得多。3.2 自适应MPC在线辨识让模型跟着系统一起“进化”自适应MPC走的是另一条路既然模型会变那我就在线辨识模型参数实时更新预测模型。这样控制器就能跟上系统的变化保持较好的性能。自适应MPC通常包含两个模块一个是参数辨识模块用递推最小二乘法RLS或者卡尔曼滤波来估计模型参数另一个是MPC控制器用更新后的模型来求解控制律。这个思路在理论上很漂亮但实操中有几个坑。第一个坑是辨识激励不足。如果系统长时间运行在稳态输入输出数据的变化很小辨识算法就得不到足够的信息来更新参数参数估计会漂移甚至发散。我遇到过好几次系统在稳态运行了几个小时后自适应MPC的参数突然跑飞了导致控制量剧烈波动。后来我加了一个“死区”逻辑——只有当输入输出的变化超过一定阈值时才允许更新参数这才把问题稳住。第二个坑是辨识和控制的耦合。辨识需要激励信号但控制希望系统平稳两者是矛盾的。如果为了辨识而故意注入激励信号就会影响控制性能如果不注入激励辨识又可能不准确。这个矛盾在自适应MPC里一直存在实际工程中往往需要在“辨识质量”和“控制性能”之间做折中。我的经验是在工况变化的时候适当放宽辨识的更新条件让参数快速跟上在稳态的时候冻结参数更新避免不必要的波动。3.3 鲁棒与自适应的融合L1自适应MPC的启示鲁棒MPC和自适应MPC各有优劣那能不能把两者结合起来答案是肯定的。L1自适应MPC就是一个典型的融合方案。它的思路是用自适应律来估计不确定性但估计出来的不确定性不直接用于控制而是通过一个低通滤波器来“平滑”后再补偿。这样既保留了自适应对慢变不确定性的跟踪能力又避免了高频估计噪声对控制性能的影响。我在一个运动控制项目里试过L1自适应MPC效果确实比纯鲁棒MPC好——在模型失配30%的情况下跟踪误差比纯鲁棒MPC小了将近一半而且控制量没有出现高频抖振。但L1自适应MPC的参数整定比较麻烦滤波器的带宽、自适应增益这些参数需要反复调试。我的经验是先把自适应增益调小保证系统稳定然后再逐步增大增益直到性能满足要求但又不出现振荡。这个过程有点像调PID但比调PID复杂得多因为涉及到的参数更多耦合关系也更复杂。3.4 实操心得鲁棒MPC和自适应MPC的选型建议到底该用鲁棒MPC还是自适应MPC我的建议是看两个维度不确定性变化的快慢和安全要求的严格程度。如果不确定性是慢变的比如催化剂老化、设备磨损而且安全要求极高比如化工反应釜、核电站那鲁棒MPC更合适。因为鲁棒MPC的设计保证了最坏情况下的稳定性不需要在线辨识可靠性更高。虽然保守一些但安全第一。如果不确定性是快变的比如负载突变、环境扰动而且安全要求相对宽松比如机器人的轨迹跟踪、无人机的姿态控制那自适应MPC更合适。因为自适应MPC能快速跟上变化性能更好。但需要做好辨识的鲁棒性设计防止参数跑飞。如果两者都有那就考虑融合方案比如L1自适应MPC或者鲁棒自适应MPC。但融合方案的复杂度更高调试周期更长需要权衡项目的时间和资源。4. 计算效率的革命从显式MPC到分布式MPCMPC的计算负担一直是制约其应用范围的核心瓶颈。尤其是在嵌入式平台上算力、内存、功耗都是硬约束。我刚开始做嵌入式MPC的时候经常为了省几毫秒的计算时间把预测时域从20步砍到10步结果控制性能大打折扣。后来随着算法和硬件的进步这个问题才逐步缓解。这一节我想聊聊MPC在计算效率方面的几次关键突破。4.1 显式MPC把在线优化变成离线查表显式MPCExplicit MPC是Bemporad等人在2002年提出的一个巧妙思路。它的核心观察是对于线性系统加线性约束加二次目标函数的MPC问题最优控制律是状态的分段仿射函数。也就是说整个状态空间可以被划分成若干个多面体区域每个区域对应一个仿射控制律。这些区域和控制律可以离线计算好在线运行的时候只需要判断当前状态落在哪个区域然后套用对应的控制律就行了。这个思路把在线优化问题转化成了点定位问题计算量从“解QP”降到了“查表”速度提升了好几个数量级。我试过在一个采样周期1毫秒的电机控制上跑显式MPC用普通的单片机就能实现这在在线QP求解的时代是不可想象的。但显式MPC也有明显的局限。首先区域的数量随着状态维度和约束数量的增加呈指数增长。一个状态维度为10、约束数量为20的问题区域数量可能达到数万个存储这些区域的数据就需要很大的内存。其次显式MPC只适用于线性系统和二次目标函数对于非线性系统或者非二次目标函数分段仿射的性质就不成立了。所以显式MPC在实际应用中往往用在状态维度较低、约束相对简单的场景比如小型的运动控制系统。4.2 一阶方法用迭代换精度适合嵌入式平台另一条提升计算效率的路线是使用一阶优化方法比如梯度投影法、交替方向乘子法ADMM。这些方法的特点是每次迭代的计算量很小主要是一阶导数运算但收敛速度比内点法、有效集法这些二阶方法慢。不过对于MPC来说我们并不需要把优化问题解到非常高的精度——因为预测本身就有误差解得太精确反而浪费计算资源。所以一阶方法在MPC里反而有优势。ADMM在MPC里的应用特别值得一说。ADMM把原问题分解成几个子问题每个子问题可以独立求解然后通过交换变量来协调。这种分解结构天然适合并行计算。我在一个多关节机器人的控制项目里用过ADMM-based MPC把每个关节的控制问题作为一个子问题在FPGA上并行求解整体计算时间比串行QP求解快了将近10倍。当然ADMM的收敛速度依赖于惩罚参数的选取参数选得不好迭代次数会很多。我的经验是惩罚参数可以按照问题的尺度来粗略估计然后在调试中微调。如果发现迭代次数太多就增大惩罚参数如果发现解的质量不好就减小惩罚参数。4.3 分布式MPC把大问题拆成小问题对于大规模系统比如电网、交通网络、多机器人系统集中式MPC的优化变量维度太高求解起来非常困难。分布式MPC的思路是把大系统拆成若干个子系统每个子系统有自己的局部MPC控制器子系统之间通过交换边界信息来协调。分布式MPC的挑战在于协调机制的设计。如果子系统之间不协调各自为政可能会导致整体性能下降甚至不稳定。常见的协调方法有分布式ADMM、对偶分解、一致性算法等。我在一个微电网能量管理的项目里用过分布式MPC每个微电网单元作为一个子系统通过交换功率缺额信息来协调。实测下来分布式MPC的求解时间比集中式MPC少了60%以上而且某个子系统通信中断时其他子系统依然能正常运行鲁棒性更好。但分布式MPC也有自己的坑。最大的坑是通信延迟和丢包。如果子系统之间的通信不可靠协调信息不能及时更新分布式MPC的性能就会下降。我在项目里加了一个“通信中断检测”逻辑当检测到通信中断时子系统自动切换到“孤岛模式”用局部信息做保守控制等通信恢复后再切回协调模式。这个逻辑虽然增加了复杂度但大大提升了系统的可靠性。4.4 实操建议如何根据平台算力选择MPC实现方式选择MPC的实现方式核心是看平台算力和控制性能要求的匹配。我整理了一个简单的选型参考平台类型算力水平推荐MPC实现方式典型采样周期高性能工控机强在线QP/NLP求解10ms-1s嵌入式ARM Cortex-A中等一阶方法ADMM等1ms-10ms嵌入式ARM Cortex-M弱显式MPC或简化MPC0.1ms-1msFPGA/GPU并行强分布式MPC或并行ADMM0.01ms-1ms这个表只是粗略参考实际选型还要考虑内存大小、功耗限制、开发周期等因素。我的建议是先用高性能平台验证算法再逐步往嵌入式平台移植。移植的过程中最大的挑战往往不是算法本身而是数值精度和实时性的平衡。比如在ARM Cortex-M上浮点运算能力有限可能需要用定点数来实现这就会引入量化误差影响控制性能。我一般会先用浮点仿真验证算法然后再做定点化定点化之后一定要重新做闭环测试因为量化误差可能会让原本稳定的系统变得不稳定。5. 数据驱动与学习型MPC当神经网络遇上滚动优化最近几年MPC领域最热的方向之一就是和数据驱动、机器学习结合。传统的MPC依赖于机理模型但很多复杂系统的机理模型根本写不出来或者写出来太复杂没法实时求解。数据驱动MPC的思路是用神经网络或者高斯过程来拟合系统的动力学然后用这个数据驱动的模型来做预测。这个方向听起来很前沿但实操中的坑也不少。5.1 神经网络MPC拟合能力强但稳定性保证是难题神经网络MPCNN-MPC的基本框架是用一个神经网络来学习系统的状态转移函数然后把神经网络嵌入到MPC的预测模型中。神经网络的优势是拟合能力强可以逼近任意非线性函数而且训练过程是离线的在线只需要做前向推理计算速度很快。但NN-MPC有一个致命的弱点缺乏稳定性保证。传统的MPC有Lyapunov稳定性理论支撑只要终端约束和终端代价设计得当就能保证闭环稳定。但神经网络是个黑箱你没法从理论上保证它的预测误差有界更没法保证闭环稳定。我在一个无人机控制的项目里试过NN-MPC训练数据覆盖了大部分飞行工况但在极端工况下比如强风扰动神经网络的预测误差突然变大导致控制器输出异常差点炸机。后来大家想了很多办法来提升NN-MPC的可靠性。比如用物理信息神经网络PINN把物理约束嵌入到网络结构中保证预测结果满足基本的物理规律或者用集成学习的方法训练多个神经网络用它们的预测方差来估计不确定性当不确定性太大时切换到保守控制器。这些方法在一定程度上缓解了问题但离“理论保证”还有距离。5.2 高斯过程MPC自带不确定性估计但计算量随数据量增长高斯过程Gaussian Process, GP是另一种常用的数据驱动建模方法。和神经网络不同GP天然提供预测的不确定性估计——它不仅给出预测均值还给出预测方差。这个方差信息可以直接用于MPC的约束收紧在预测方差大的地方把约束收紧一些保证安全。GP-MPC在安全关键场景里很有吸引力因为它的不确定性估计是有理论依据的。但GP的计算量随着数据量的增加而立方增长对于在线学习来说数据量会越来越大计算量很快就受不了了。常用的解决办法是使用稀疏GP或者局部GP只保留一部分关键数据点。我在一个机械臂抓取的项目里用过稀疏GP-MPC把数据点从几千个压缩到几百个计算时间从几百毫秒降到了几毫秒精度损失在可接受范围内。5.3 强化学习与MPC的结合用RL调参用MPC保底强化学习RL和MPC的结合是另一个热门方向。RL擅长在复杂环境中学习策略但缺乏安全保证MPC擅长处理约束但需要精确模型。两者结合的方式有很多种我比较看好的一种是用RL来调整MPC的参数比如预测时域、权重矩阵、约束边界而MPC负责底层控制。这样既利用了RL的探索能力又保留了MPC的安全保证。我在一个自动驾驶仿真项目里试过这种方案。用RL来调整MPC的跟车距离和速度权重在不同的交通流密度下RL能自动找到比较合适的参数组合比人工调参的效率高很多。但RL的训练需要大量的仿真数据而且训练出来的策略泛化能力有限——换一个交通场景可能就需要重新训练。所以这种方案目前还停留在仿真阶段实际落地还需要解决泛化性和安全性的问题。5.4 数据驱动MPC的落地建议从“辅助”到“主导”的渐进路线如果你打算在实际项目里尝试数据驱动MPC我的建议是走渐进路线。不要一上来就把机理模型完全扔掉用纯神经网络替代。更稳妥的做法是先用机理模型作为基础用数据驱动方法来补偿模型误差。比如用神经网络来学习机理模型和实际系统之间的残差然后把机理模型加残差补偿作为预测模型。这样既保留了机理模型的可解释性和稳定性保证又利用了数据驱动方法的拟合能力。等残差补偿的效果稳定了再逐步增加数据驱动方法的比重。比如在机理模型不太准确的工况区间让神经网络承担更多的预测任务在机理模型准确的区间依然以机理模型为主。这种“混合模型”的思路在实际项目中更容易落地也更容易获得团队的认可。6. 从算法演进看MPC的工程落地我踩过的那些坑聊完了算法发展我想回到工程落地的角度分享一些我在实际项目中踩过的坑。这些坑有些是因为对算法理解不够深入有些是因为对硬件和环境的估计不足还有些纯粹是经验不足。希望这些教训能帮你少走弯路。6.1 预测时域不是越长越好计算量与性能的平衡点刚开始做MPC的时候我总觉得预测时域越长控制器就越“有远见”性能应该越好。于是我把预测时域从10步加到了50步结果计算时间暴涨实时性完全没法保证。更糟糕的是性能并没有明显提升反而因为优化问题的维度太高求解器经常收敛到次优解控制效果还不如短时域。后来我学乖了开始系统地测试不同预测时域下的控制性能。我发现对于大多数系统预测时域只要覆盖到系统的“主要动态响应时间”就够了。比如一个一阶惯性系统时间常数是1秒采样周期是0.1秒那预测时域取10到20步就足够了。再往后预测输出的变化已经很小了增加时域对性能的贡献微乎其微但计算量是线性增长的。我的经验是先用短时域跑通然后逐步增加时域观察性能的提升曲线。当性能提升变得平缓时就停止增加。这个“拐点”就是比较合适的预测时域。另外控制时域控制量变化的步数通常比预测时域短一般取预测时域的1/4到1/3。控制时域太短控制自由度不够太长计算量又上去了。6.2 权重矩阵整定从“玄学”到“有章可循”MPC的目标函数里通常有状态权重矩阵Q和控制量权重矩阵R。这两个矩阵的整定是我见过的最“玄学”的环节。很多论文里直接给一个对角矩阵说“经过整定后效果良好”但怎么整定的一个字都不提。我刚开始也是瞎试调了几天都没调好。后来我总结了一套方法先把Q设为单位矩阵R设为一个很小的值比如0.01让控制器优先跟踪设定值。然后观察控制量的变化如果控制量太剧烈就增大R如果跟踪太慢就减小R。等R调到一个合理的范围后再调Q。Q的对角元素对应不同状态的权重哪个状态跟踪不好就增大对应的权重。但要注意Q和R是相对的同时放大或缩小它们控制效果不变。所以整定的时候固定一个调另一个就行。还有一个技巧用归一化来处理不同量纲的状态。比如位置误差是米速度误差是米/秒如果直接放在Q矩阵里量纲不一样权重就没法公平比较。我一般会把每个状态除以其允许的最大偏差做归一化处理这样Q矩阵的对角元素就可以统一设为1整定起来简单很多。6.3 约束冲突与可行性恢复当优化问题无解时怎么办MPC的优化问题在理论上可能无解尤其是在约束很紧、扰动很大的情况下。如果优化问题无解控制器就不知道该输出什么系统可能会失控。我在一个化工过程控制的项目里就遇到过这个问题因为进料流量突然增大导致液位约束和温度约束冲突QP求解器报“infeasible”控制器直接卡死了。后来我加了一个可行性恢复机制。具体做法是把输出约束做成“软约束”在目标函数里加一个惩罚项允许约束在紧急情况下被短暂违反但违反的代价很高。这样即使硬约束冲突优化问题依然有解控制器会输出一个“尽量满足约束”的控制量而不是直接卡死。等工况恢复正常后软约束的惩罚项会把系统拉回到约束边界内。这个机制救了我好几次。但要注意软约束的惩罚权重不能太小否则约束会被频繁违反也不能太大否则和硬约束没区别还是会无解。我一般会把软约束的惩罚权重设为状态权重的10到100倍具体数值根据约束的重要程度来定。6.4 模型失配的在线检测与应对别等系统振荡了才反应过来模型失配是MPC的“慢性病”早期没症状等发现的时候往往已经晚了。我后来养成了一个习惯在线监测预测误差。具体做法是每一步都把上一时刻的预测输出和实际输出做对比计算预测误差。如果预测误差持续偏大就说明模型可能失配了。检测到模型失配后可以采取几种应对措施。一是降低控制器的 aggressiveness比如增大R矩阵让控制量变化更平缓避免因为模型误差导致振荡。二是切换到备用控制器比如PID或者鲁棒控制器等模型更新后再切回MPC。三是触发模型重新辨识用最近的数据更新模型参数。我在实际项目中一般会先降低aggressiveness观察一段时间如果预测误差还是降不下来再触发重新辨识。这个在线检测机制虽然简单但非常有效。我建议每个MPC项目都加上这个功能成本很低但能避免很多大问题。6.5 采样周期与计算延迟的匹配别让“计算”拖了“控制”的后腿MPC的计算需要时间如果计算时间接近甚至超过采样周期控制性能就会严重下降。我在一个电机控制的项目里采样周期是1毫秒但MPC的计算时间平均是0.8毫秒有时候会超过1毫秒。结果就是有些控制周期里控制量来不及更新电机出现明显的转矩脉动。解决这个问题的办法有几个。一是优化代码把计算时间降下来。比如用定点数代替浮点数用查表代替实时计算用并行计算加速求解。二是增大采样周期给计算留出足够的时间。但采样周期增大可能会影响控制带宽需要权衡。三是采用“延迟补偿”在预测模型里把计算延迟考虑进去预测未来更长时间的输出补偿延迟的影响。我最后采用的是延迟补偿加代码优化的组合方案。延迟补偿让控制器“提前”考虑计算延迟代码优化把计算时间降到了0.5毫秒以下。两者结合转矩脉动明显减小控制性能达到了要求。7. 写在最后MPC算法演进的变与不变回顾MPC几十年的发展从DMC到QDMC从鲁棒MPC到自适应MPC从显式MPC到分布式MPC再到如今的数据驱动MPC算法形态一直在变但核心思想始终没变用模型预测未来用优化求解控制用滚动时域应对不确定性。所有的算法创新都是在回答同一个问题——如何在模型不完美、计算资源有限、环境不确定的条件下做出安全、高效的控制决策。我在实际项目中最大的体会是没有“最好”的MPC算法只有“最合适”的MPC算法。选型的时候不要盲目追求新算法而是要根据具体的应用场景、平台算力、安全要求来综合考虑。有时候一个简单的DMC就能解决的问题没必要上复杂的NMPC。有时候一个显式MPC就能满足实时性要求没必要折腾分布式MPC。另外MPC的落地从来不是算法一个人的事。它需要和传感器、执行器、通信网络、计算平台紧密配合。我见过太多算法很漂亮但工程落地一塌糊涂的案例。所以如果你正在做MPC的项目我的建议是尽早把算法放到真实平台上跑尽早暴露工程问题。仿真环境里跑得再好到了真实系统上总会有你意想不到的问题。早发现早解决比在仿真里调参数有意义得多。最后分享一个小技巧建立自己的MPC调试工具箱。把常用的测试用例、性能指标、调试脚本整理好每次做新项目的时候直接复用。我这些年积累了一个工具箱里面有阶跃响应测试脚本、闭环性能评估脚本、模型失配模拟脚本等等。有了这个工具箱新项目的调试周期能缩短一半以上。这个习惯是我从一位资深工程师那里学来的受益至今。