先说个有点反直觉的现象很多做控制的人第一次接触MPC看PPT觉得思路不难无非是“预测未来几步、挑一个最优动作然后重复”。可真到自己写代码的时候往往会卡很久——不知道预测该在哪里算、为什么解出来的控制量一会儿过于激进一会儿又保守、约束明明写了却总报无解。我当年从LQR切到MPC时也卡了将近两个星期后来发现卡住我的不是公式而是没人把“数学上MPC到底在解什么”和“代码里MPC到底要跑哪几步”这两件事的对应关系讲透。这篇【控制理论】MPC二就把这座桥搭起来适合已经看过基础概念、知道滚动优化大概思路但还没真正写过一版能跑的MPC的人。既然是系列第二篇我不再把入门概念从头捋一遍而是把重点放在“从原理到可用代码之间那段没人讲的路”上。整篇文章会围绕四个问题展开MPC凭什么比PID“看得远”、那一串目标函数和约束到底在表达什么、求解器拿到手的优化问题长什么样、以及工程落地时那些让你怀疑人生的坑该怎么绕。为了让这套东西不只是纸面推演最后还会给一个最小可运行的一阶系统MPC仿真并附上可以直接改着玩的Python代码。1. MPC和PID的区别本质在“用没用模型后面的信息”1.1 把PID比作看后视镜开车MPC比作看导航开车很多人一上来就盯着MPC的计算量看觉得它“贵”、反应慢不如PID皮实。这个说法对但也没对到根子上。PID本质上是一个“基于当前误差”的反馈控制器它只知道此刻偏了多少以及误差在往哪个方向变然后据此给出控制量。这很像一个只看后视镜开车的司机能知道刚才偏离车道了也能根据偏离趋势修正方向盘但看不到前面有个弯道所以到了弯道前必然要先冲出去一段才开始打方向。MPC不一样。MPC手上有一张“地图”这个地图就是被控对象的预测模型。模型告诉它如果我此刻给某个控制量未来几步状态会怎么走。于是它可以在脑子里把未来一条路“预演”一遍选出最优的控制序列然后只执行第一步到下一步再重新预演。这相当于看着导航开车知道前方要转弯所以提前减速、提前打方向反应自然更平滑。这就是“预测控制”里“预测”二字的真正含义不是算命而是靠模型外推未来。PID的信息来源只有过去的误差反馈信息MPC的信息来源是模型当前状态目标前馈信息叠加反馈校正信息量完全不同性能上限自然也不同。1.2 预测模型从哪里来机理、辨识、还是数据拟合既然“地图”这么关键那模型从哪来工程里主要有三种来源实际项目往往是混合使用。机理建模根据物理规律直接写出微分方程比如倒立摆的拉格朗日方程、无人机的刚体动力学、电机的电气方程。这种模型物理意义最清晰外推能力最强但很费劲而且有些系统根本机理不明或者机理模型参数很难标定。系统辨识给对象加激励信号阶跃、正弦、伪随机序列采集输入输出数据然后拟合出传递函数或状态空间模型。这是工业现场最常用的路子。很多老工程师不跟你扯什么状态空间直接拿阶跃响应曲线拟合一个一阶惯性加纯滞后模型MPC效果照样不错。数据拟合/学习模型用神经网络、高斯过程这些工具从数据里学一个映射关系。这几年很时髦尤其在那些机理不清但数据丰富的场景。但我要劝一句如果你的系统能机理建模优先用机理能用经典辨识解决别急着上学习模型。模型结构越复杂不确定性来源越多MPC的稳定性分析和保护措施就越难做。记住MPC是“模型驱动”的模型的可靠性直接决定控制的可靠性模型错了预测全是空中楼阁。1.3 三个“多项式”预测模型的三要素抛开具体方程形式一个合格的预测模型至少要包含三样东西状态变量 x用来描述系统当前所处的“位置”比如位置、速度、温度、浓度控制输入 u你可以主动施加的“动作”比如电压、阀位、力矩输出方程 y你实际测量到的量可能是状态的一部分也可能是状态的组合。有了这三样模型可以写成统一的形式连续域是微分方程MPC里一般会离散化成差分方程x(k1) A·x(k) B·u(k) y(k) C·x(k)A叫系统矩阵描述“如果没有外部作用状态自己会怎么变”B叫输入矩阵描述“你给一个u状态会被推动多少”C叫输出矩阵描述“你能看到什么”。这个形式叫状态空间模型是现代控制理论的标准语言。千万不要被这三个字母吓住——它们不过是在讲一个因果故事现在的状态和现在的输入决定下一个时刻的状态。2. 写出一个能求解的MPC从状态空间到目标函数与约束2.1 预测是怎么“展开”的有了模型 x(k1) A·x(k) B·u(k)剩下的就是把这个差分方程多倒腾几步。已知当前状态 x(k)我现在想预测“如果未来Np步的控制量分别是 u(k), u(k1), ..., u(kNp-1)状态会走到哪”那我就可以递推x(k1) A·x(k) B·u(k) x(k2) A·x(k1) B·u(k1) A²·x(k) A·B·u(k) B·u(k1) x(k3) A³·x(k) A²·B·u(k) A·B·u(k1) B·u(k2) ...这一串式子就是“预测模型”。它把未来的状态表示成“当前状态贡献的零输入响应 未来控制量贡献的受控响应”。刚看MPC资料的人常被这里绕晕其实你只需要记住一句话给定初值 x(k) 和控制序列未来状态可以完全算出来。MPC要做的就是在这串可预测的状态里挑一个“最顺眼”的未来。顺不顺眼怎么量化用一个目标函数来描述。2.2 目标函数Q和R到底在平衡什么MPC的标准目标函数长这样J Σ (x(ki) - x_ref)ᵀ·Q·(x(ki) - x_ref) Σ u(ki)ᵀ·R·u(ki)第一项是“状态偏差的代价”意思是“我不想让状态偏离目标值太远”第二项是“控制能量的代价”意思是“我也不想让控制量太大、太折腾”。Q和R是对角权重矩阵它们不是凭空定的而是在表达你的控制偏好。Q大说明你更在意状态偏差系统响应会更“积极”代价是控制量会比较冲R大说明你更在意控制动作的平缓系统响应会变“懒”。本质上这是一个trade-off。很多人把Q和R当成需要“调”的玄学参数其实它俩在表达的是“你的需求是什么”而不是“系统需要什么”。想清楚这一点调参方向就清晰多了。注意这里没有把控制量变化率 Δu 写进目标。实际工程里直接限制u往往不够因为执行器比如舵机、阀门因为惯性或磨损更讨厌“高频大幅摆动”。所以更常见的写法是在目标函数里再加一项 Δu 的惩罚或者直接对 Δu 设约束。不然后果就是MPC解出来的控制量可能符合上下限但每一步都在剧烈跳变执行器根本跟不上控制效果一塌糊涂。2.3 约束MPC真正的“核心资产”MPC和LQR、PID最本质的差别不是预测而是“在优化里显式处理约束”。LQR推导出来的控制律是一个线性反馈 u -Kx它不会主动考虑“电机转速不能超过3000”“阀门开度不能超过100%”“电流不能超过额定值”这些限制。当你靠近约束边界时LQR只会照样按线性反馈算u结果就是饱和或者执行器长时间处于极限状态。MPC把约束作为优化问题的硬性/软性条件直接写进去典型是这样一组u_min ≤ u(ki) ≤ u_max Δu_min ≤ Δu(ki) ≤ Δu_max x_min ≤ x(ki) ≤ x_max所以在MPC里约束不是“事后裁剪”而是“事前规划”。这带来一个很大的工程优势你不需要为约束专门设计抗饱和回路、限幅逻辑、安全保护区约束已经参与了解算。这意味着系统在靠近约束边界时MPC会自动“提前踩刹车”因为它能预见到如果不收着来未来几步就会越过边界。约束写进优化里目标函数负责“选最好的那个解”约束负责“在合法的范围内选”。这两个东西合在一起MPC就变成了一个带约束的最优化问题这也是后面所有数值求解工作的起点。3. 滚动优化的工程真相为什么每步都要全部重算3.1 开环最优不等于闭环最优很多第一次看MPC的人会产生一个疑惑既然我在当前时刻已经解出了一个最优的未来控制序列为什么不把这串控制量一次性发给执行器让系统照着跑完这听上去很合理但实际操作中几乎没有人这么做。原因是模型不可能绝对准确扰动也不可能提前知道。我举个例子。你开车用导航规划出一条“接下来的5公里最优路线”但如果真的拿到了路线就闭着眼睛开中途突然有辆车加塞、临时修路、甚至只是轮胎侧滑了一下你都会立刻脱离那条“最优路线”。正确的做法是方向照导航走但眼睛始终盯着路发现偏差就实时修正路线。MPC的滚动优化就是这个逻辑每个采样时刻用当前实测的状态或者滤波估计的状态作为初值重新做一次预测、重新解一次优化得到新的控制序列但只执行第一步。等到下一个采样时刻状态刷新了再重来一遍。这就是“滚动”的含义——不是在整个运行过程中只做一次规划而是边执行边规划。3.2 反馈校正MPC不是开环控制器这里必须强调一点MPC并不是一个开环控制器它是有反馈的。反馈的环节就在于“每个时刻都用当前状态重新初始化预测”。用状态空间模型做预测时问题其实很微妙你的模型不可能和真实系统完全一样。如果模型有误差那么预测的轨迹和系统实际跑的轨迹必然有偏差。如果只是开环地把控制序列发出去这个偏差会越积越大。但滚动优化相当于每隔一个采样周期就用一次实测状态把预测拉回到真实轨道上偏差被持续“纠正”。这也是为什么很多人学MPC时会觉得“概念简单但写代码总觉得哪里不对”——问题往往出在你有没有在每一个控制周期里正确地把当前状态反馈进去。如果这一步做错了MPC会退化成一个开环的前馈控制鲁棒性会大幅下降和PID闭环相比甚至可能更差。3.3 预测时域Np与控制时域Nc的取舍滚动优化有两个关键参数预测时域Np和控制时域Nc。Np是“看多远”。Np太短系统还没来得及体现出主要动态MPC就只看眼前一点效果类似短视的“近视眼”对惯性大的系统容易振荡Np太长一方面计算量增大另一方面远期预测的模型误差累积很大远期信息其实不太可信而且Np过大还会让系统过于保守响应变慢。经验上Np至少要覆盖被控对象主要动态时间常数的3到5倍比如你的系统稳定时间大概10秒采样周期0.1秒那Np取50到100是合理的。Nc是“未来的控制量允许多少步自由变化”。Nc越接近Np优化变量越多计算越慢行为也越灵活Nc设为1到3时MPC相当于假设“我只管前几步的动作后面保持不动”。工业中经常把Nc设得比Np小很多主要是为了降低计算量。代价是控制自由度减少性能会略打折扣。我的建议是仿真阶段先让NcNp看到性能上限要上实时系统时再把Nc往下调观测性能损失找到性价比最高的点。3.4 每步重算算力花在哪了“每步重算”听起来很浪费但它是MPC鲁棒性的根基。真正让MPC算力吃紧的不是重算本身而是每步重算的那个优化问题规模。Np50、Nc20优化变量就有20个控制量再加状态误差等几十个自由度对于现代计算机来说其实很小。真正费时间的往往是问题“坏条件”数值病态导致的迭代次数上升这点我会在第六节详细说。4. 从最优控制到数值求解MPC求解器到底在解什么4.1 把MPC变成QP问题的过程前面我把MPC写成了“目标函数约束”这听起来很抽象。到了实现阶段你首先要破除一个误区求解器不是在“模拟系统”而是在“解一个二次规划问题”。具体来说把预测递推展开、代入目标函数、把约束整理成矩阵不等式之后MPC会被整理成这样一个标准形式min (1/2)·zᵀ·H·z fᵀ·z s.t. A_ineq·z ≤ b_ineq l_b ≤ z ≤ u_b其中 z 是优化变量向量里面拼接了未来Nc步的控制量和可能的状态偏差H是Hessian矩阵它是从Q、R矩阵经过预测模型“折叠”出来的f是线性项包含目标状态和当前状态的信息约束则全部变成了关于z的线性不等式。这个形式就是标准的二次规划QP。Hessian矩阵H在这里起着双重作用它既是目标函数的二阶曲率也编码了预测模型对控制输入的动态响应。这也是为什么MPC不能简单地用梯度下降乱解——H的性质是否正定、条件数大小直接决定了解算的难度。4.2 手写QP还是用求解器我见过不少人想自己手写MPC求解器从预测矩阵到QP求解器全自己撸一遍。这个想法的学习价值极大真的手写一遍你对MPC的理解会深很多。但工程上我强烈不建议这么做。原因很简单QP求解器是一个高度工程化的数值算法要考虑稀疏性利用、数值稳定性、热启动、计算耗时确定性worst-case execution time等一大堆问题这东西已经是有几十年积淀的领域没必要重复造轮子。你需要做的是理解建模层和求解层的分工。建模层根据模型、Q、R、约束生成H、f、A_ineq、b_ineq。求解层输入这些矩阵输出最优z也就是未来控制序列。在Python里用CVXPY或OSQP在C里用osqp-eigen或acados在MATLAB里用自带MPC工具箱都是这个分工。这里给一个基于OSQP的极小MPC示例。代码不追求性能重在展示“建模层到求解层”的对应关系。以下是一个一阶惯性系统的跟踪MPCimport numpy as np import osqp from scipy import sparse # 离散模型: x(k1) a*x(k) b*u(k) a 0.9 b 0.1 x0 0.0 x_ref 1.0 Np 30 # 预测时域 Nc 10 # 控制时域 # 预测展开: 用Nc个控制量预测Np步状态 # 状态预测 A_pow*x0 B_aug*u_seq A_pow np.array([a**(i1) for i in range(Np)]) B_aug np.zeros((Np, Nc)) for i in range(Np): for j in range(min(i1, Nc)): B_aug[i, j] a**(i-j) * b # 目标函数: min sum((x-x_ref)^2 * q) sum(u^2 * r) q 1.0 r 0.1 H B_aug.T B_aug * q np.eye(Nc) * r f (B_aug.T (A_pow * x0 - x_ref)) * q # 约束: 0 u 1 lb np.zeros(Nc) ub np.ones(Nc) prob osqp.OSQP() prob.setup(Psparse.csc_matrix(H), qf, Asparse.eye(Nc), llb, uub, verboseFalse) res prob.solve() u_opt res.x # 只执行第一步 u_action u_opt[0] print(当前时刻应施加的控制量:, u_action)这个例子很粗糙但对理解MPC的解算结构非常有帮助。你可以看到Hessian矩阵H就是从B矩阵预测矩阵和Q/R权重“折叠”出来的线性项f携带了当前状态和目标信息约束直接作用在控制量上。跑一遍你会直观感受到“预测”“优化”“执行第一步”这三个动作是如何在一个采样周期内完成的。4.3 求解器选型参考不同场景下求解器的选型差异很大我整理一个基于个人经验的对照表求解器语言适用场景优点注意点OSQPC/C/Python中小规模MPC、嵌入式原型开源、对稀疏问题效果好、支持热启动需要预先把问题写成稀疏矩阵qpOASESC实时MPC尤其是冷启动多的情况专门面向MPC场景设计计算快对问题尺度较敏感约束冗余时易退化acadosC/C非线性MPC、需要高刷新率集成了多种QP求解器和NLP求解器使用门槛偏高适合有基础的开发者MATLAB MPC ToolboxMATLAB快速验证算法、学术仿真建模方便可视化完善不适合直接部署到嵌入式硬件CVXPYPython快速原型、教学、离线仿真建模直观改模型快效率低不建议用于实时控制选型建议如果你是在做学习和仿真用CVXPY或MATLAB最舒服如果要做嵌入式实时MPC我建议从OSQP或qpOASES入手先跑通一个最小闭环再考虑上acados这类“全家桶”。别一上来就追求最先进的工具链控制器的核心永远是控制逻辑本身。4.4 实时性的真相采样时间可能比你想象的更宽裕有些人一听MPC就觉得“算不过来”其实是被某些宣传误导了。对于典型的线性MPC状态维度几维到几十维Np几十步优化变量几十个这在现代嵌入式处理器上用OSQP都是微秒到毫秒级的事。真正让计算时间暴涨的往往是状态维度很高、Np很大、约束写得有冗余、或者问题数値病态导致求解器迭代次数飙升。所以解决实时性问题的顺序应该是先确认问题建模是否合理再确认求解器配置是否正确比如禁用无关输出、开启热启动最后才去换更快的求解器。5. 一个能跑的MPC从一阶系统到倒立摆还不够5.1 先跑通一阶再考虑复杂对象很多人拿到MPC代码第一步就打算上倒立摆、四旋翼、机械臂。我真心建议你先在一阶惯性对象上跑通因为一阶系统只有一个状态预测、优化、反馈的每个环节都可以画出来看明白。以第四节那段代码为例你可以做一个测试逐步把Q调大观察控制量的变化把R调大观察响应变慢的速度再把Np缩短观察系统是否出现振荡。这几个实验做完你对MPC的直觉会比看十篇论文都有效。我发现刚接触MPC的朋友最容易在这一步把“Q和R影响目标”错误地理解成“Q和R影响稳定性”——它们影响的是最优解的偏向稳定性则更依赖Np、模型准确度和约束设计。5.2 从一阶到倒立摆差的不是“预测”而是“非线性”一阶系统跑通以后下一个阶段的典型对象是倒立摆。很多人想当然地以为倒立摆无非是多加一个状态、多加一个约束实际上倒立摆是强非线性系统直接用线性MPC做在大角度范围内必然失效。这时你有两条路第一条路线性化MPC。在平衡点附近做线性化得到线性状态空间模型然后用标准线性MPC。这个方案在小角度摆动时效果不错实现也简单。第二条路非线性MPCNMPC。直接用非线性模型目标函数里求解器换成能求解非线性规划的NLP求解器比如acados搭配IPOPT。NMPC性能上限更高但数值难度陡增局部最优、求解时间不确定、初值敏感性都是现实问题。我的建议是如果对象在正常工作点附近非线性不强优先用线性MPC加反馈校正去补足只有当工作范围确实很宽、线性模型无法覆盖时再考虑NMPC。工程上能不用非线性就不用非线性这不是保守而是对鲁棒性负责。5.3 对MPC架构的完整理解状态估计不可忽略写MPC的人还有个常见盲区状态变量常常不是全部可以直接测到的。真实系统里你往往只能测到输出y而状态里的某些维度比如内部温度、速度、受力没有传感器或噪声很大。这时MPC不是直接拿“实际值”做预测而是拿“估计值”做预测。这就需要状态观测器工程里最常见的是卡尔曼滤波器。它把测量输出和模型预测融合起来给出一个尽量准确的状态估计然后把这个估计值送给MPC做滚动优化。这揭示了一个重要事实MPC的性能上限不只取决于优化求解还取决于你给它的状态估计准不准。模型好、求解器快但状态估计一塌糊涂MPC照样拉胯。5.4 调参实战先调什么后调什么关于调参顺序我形成了一套固定的打法先列出来供你参考。先把Np和采样周期定下来。Np必须覆盖对象主要动态的3到5倍时间长度采样周期则要满足香农采样定理并留足求解器计算余量。再把R粗略设一个量级。R的物理含义可以参考比如控制量最大幅值的平方的倒数。调Q阵。Q阵各对角元素其实是在表达“你有多在意对应状态量的偏离”不同状态量量纲不同位置是米、速度是米/秒不能简单地把Q都设成1否则优化会偏向量纲更大的变量。标准的做法是按状态量的典型量纲做归一化。最后微调R。R越小控制动作越凌厉R越大动作越平滑。观察执行器的实际输出调整到既不抖又能快速到位即可。约束按物理极限直接填不要为了“让求解器别报错”而故意放宽约束本身就是信息放宽约束等于主动放弃预测控制的优势。调参过程一定要配合图表观察我每次都会把实际状态、预测轨迹、控制量、约束边界都画在同一张图里一眼就能看出问题出在“预测过冲”还是“控制饱和”还是“约束不可行”。6. 工程落地时那些逃不掉的坑6.1 权重相差太大导致数值病态MPC落地最常踩的坑之一是Q和R的数量级差太多比如Q1000、R0.0001目标函数里两项差的量级可能有千万倍。这会导致Hessian矩阵的条件数差得离谱求解器在数值上近乎“瞎眼”——它对正常的目标变化不敏感稍微一点舍入误差就可能让优化结果抖动。解决方向有三个一是合理归一化状态和控制量不要让量级跨度过大二是用权重矩阵的平方根形式重新参数化目标函数三是选择对数值稳定性更友好的求解器比如OSQP对稀疏病态问题处理得就比较好。记住一个原则目标函数的数值尺度要让所有代价项都在同一个数量级附近求解器才能正常工作。6.2 约束不可行现实世界不允许“无解”做仿真时你可能会遇到一个很经典的错误求解器返回“无解”infeasible problem。控制领域的行话叫约束过强导致可行域为空。比如你把控制量约束设得很紧同时又把状态约束设得很紧模型预测在未来几步发现无论怎么给控制量状态都会越界那这个问题就没有可行解。这时MPC会直接“罢工”——这在实时控制里是致命的。处理思路把物理上不能突破的约束设为硬约束把可以轻度违反的约束设为软约束并给软约束加上一个惩罚权重。软约束的含义是系统被允许在极端情况下略微越界但会付出代价。这样即便某一步出了特殊情况求解器也总能给出一个尽量靠近约束边界的解而不是回复“无解”。工程经验告诉我状态约束几乎都应该做软约束控制输入约束才是真正的硬约束因为输入上限是执行器的物理极限越界意味着执行器根本做不到。6.3 终端约束理论上很漂亮工程上怎么落地经典MPC理论里有一个很重要但是也很骨感的结论为了保证闭环稳定性需要在预测时域末端加终端约束也就是要求x(kNp)必须落到某个终端集合内并且终端代价函数要满足特定条件。这套理论很严谨比如终端等式约束x(kNp)x_ref在理论上能保证渐近稳定但在实际工程中让系统在一个有限时域内精确到达目标状态往往要不现实地拉长Np或者产生巨大的控制量。工程上的常见妥协是把终端等式约束去掉改成一个足够大的终端代价权重也就是在目标函数里额外加一项P·(x(kNp)-x_ref)²其中P取一个较大的矩阵。理论上这叫“近似终端代价”它不能给出绝对的稳定性保证但只要P取得够大实际闭环效果通常可以接受。如果你的系统安全要求极高需要形式化稳定性证明那终端约束这条路不能省需要专门做可达集分析和终端权重设计。6.4 延时补偿计算完成的瞬间系统已经走远了实时MPC有一个非常隐蔽但后果严重的工程问题求解是需要时间的。假设采样周期是50ms求解器用了15ms才算完那么这15ms里系统的状态已经变化了你用“15ms前的状态”解出来的控制量作用在“当前系统”上显然是滞后的。如果控制频率一高、计算时间占比一大这个滞后会导致实际性能明显劣于仿真。工程上的处理手法主要有三种输入延时补偿把被控对象模型扩维把输入延时建模进状态空间MPC在预测时天然把“状态反馈时刻到控制生效时刻”的延时考虑进去。计算延时补偿在k时刻开始求解时先预测出一个“当前控制量u(k)”再去迭代求解未来序列而下一个控制量u(k1)在k1时刻到达之前就已经算好了用“上一时刻对未来状态的预测值”作为初值去做热启动。热启动将上一时刻的优化解作为当前时刻求解器的初始解这样求解速度会大幅提升也是减轻延时影响的有效手段。延时问题在学术仿真里几乎不被提及但在真实系统中往往决定项目成败。我见过太多控制算法“仿真无敌、上机就废”的案例一大半都是延时处理不到位。写到这里回看这些年和MPC打交道的过程我最深的体会是MPC从来不是“调一个Q、R就完事”的控制器它是一个由模型、预测、优化、约束、状态估计、求解器共同构成的系统。任何一个环节没想清楚最终都会在实时运行中以某种形式爆发出来。所以我个人调试MPC时已经把流程固化成了刻板动作先确认模型方向和量纲再确认状态估计靠谱然后才去盯优化求解的结果。参数永远放在最后调因为参数只是把前面所有决策的偏好“翻译”成数值前面的模型和架构错了参数调得再完美也只会在错误的方向上越走越远。希望你少走我当年走过的弯路。
MPC模型预测控制实战：从QP求解到滚动优化落地
先说个有点反直觉的现象很多做控制的人第一次接触MPC看PPT觉得思路不难无非是“预测未来几步、挑一个最优动作然后重复”。可真到自己写代码的时候往往会卡很久——不知道预测该在哪里算、为什么解出来的控制量一会儿过于激进一会儿又保守、约束明明写了却总报无解。我当年从LQR切到MPC时也卡了将近两个星期后来发现卡住我的不是公式而是没人把“数学上MPC到底在解什么”和“代码里MPC到底要跑哪几步”这两件事的对应关系讲透。这篇【控制理论】MPC二就把这座桥搭起来适合已经看过基础概念、知道滚动优化大概思路但还没真正写过一版能跑的MPC的人。既然是系列第二篇我不再把入门概念从头捋一遍而是把重点放在“从原理到可用代码之间那段没人讲的路”上。整篇文章会围绕四个问题展开MPC凭什么比PID“看得远”、那一串目标函数和约束到底在表达什么、求解器拿到手的优化问题长什么样、以及工程落地时那些让你怀疑人生的坑该怎么绕。为了让这套东西不只是纸面推演最后还会给一个最小可运行的一阶系统MPC仿真并附上可以直接改着玩的Python代码。1. MPC和PID的区别本质在“用没用模型后面的信息”1.1 把PID比作看后视镜开车MPC比作看导航开车很多人一上来就盯着MPC的计算量看觉得它“贵”、反应慢不如PID皮实。这个说法对但也没对到根子上。PID本质上是一个“基于当前误差”的反馈控制器它只知道此刻偏了多少以及误差在往哪个方向变然后据此给出控制量。这很像一个只看后视镜开车的司机能知道刚才偏离车道了也能根据偏离趋势修正方向盘但看不到前面有个弯道所以到了弯道前必然要先冲出去一段才开始打方向。MPC不一样。MPC手上有一张“地图”这个地图就是被控对象的预测模型。模型告诉它如果我此刻给某个控制量未来几步状态会怎么走。于是它可以在脑子里把未来一条路“预演”一遍选出最优的控制序列然后只执行第一步到下一步再重新预演。这相当于看着导航开车知道前方要转弯所以提前减速、提前打方向反应自然更平滑。这就是“预测控制”里“预测”二字的真正含义不是算命而是靠模型外推未来。PID的信息来源只有过去的误差反馈信息MPC的信息来源是模型当前状态目标前馈信息叠加反馈校正信息量完全不同性能上限自然也不同。1.2 预测模型从哪里来机理、辨识、还是数据拟合既然“地图”这么关键那模型从哪来工程里主要有三种来源实际项目往往是混合使用。机理建模根据物理规律直接写出微分方程比如倒立摆的拉格朗日方程、无人机的刚体动力学、电机的电气方程。这种模型物理意义最清晰外推能力最强但很费劲而且有些系统根本机理不明或者机理模型参数很难标定。系统辨识给对象加激励信号阶跃、正弦、伪随机序列采集输入输出数据然后拟合出传递函数或状态空间模型。这是工业现场最常用的路子。很多老工程师不跟你扯什么状态空间直接拿阶跃响应曲线拟合一个一阶惯性加纯滞后模型MPC效果照样不错。数据拟合/学习模型用神经网络、高斯过程这些工具从数据里学一个映射关系。这几年很时髦尤其在那些机理不清但数据丰富的场景。但我要劝一句如果你的系统能机理建模优先用机理能用经典辨识解决别急着上学习模型。模型结构越复杂不确定性来源越多MPC的稳定性分析和保护措施就越难做。记住MPC是“模型驱动”的模型的可靠性直接决定控制的可靠性模型错了预测全是空中楼阁。1.3 三个“多项式”预测模型的三要素抛开具体方程形式一个合格的预测模型至少要包含三样东西状态变量 x用来描述系统当前所处的“位置”比如位置、速度、温度、浓度控制输入 u你可以主动施加的“动作”比如电压、阀位、力矩输出方程 y你实际测量到的量可能是状态的一部分也可能是状态的组合。有了这三样模型可以写成统一的形式连续域是微分方程MPC里一般会离散化成差分方程x(k1) A·x(k) B·u(k) y(k) C·x(k)A叫系统矩阵描述“如果没有外部作用状态自己会怎么变”B叫输入矩阵描述“你给一个u状态会被推动多少”C叫输出矩阵描述“你能看到什么”。这个形式叫状态空间模型是现代控制理论的标准语言。千万不要被这三个字母吓住——它们不过是在讲一个因果故事现在的状态和现在的输入决定下一个时刻的状态。2. 写出一个能求解的MPC从状态空间到目标函数与约束2.1 预测是怎么“展开”的有了模型 x(k1) A·x(k) B·u(k)剩下的就是把这个差分方程多倒腾几步。已知当前状态 x(k)我现在想预测“如果未来Np步的控制量分别是 u(k), u(k1), ..., u(kNp-1)状态会走到哪”那我就可以递推x(k1) A·x(k) B·u(k) x(k2) A·x(k1) B·u(k1) A²·x(k) A·B·u(k) B·u(k1) x(k3) A³·x(k) A²·B·u(k) A·B·u(k1) B·u(k2) ...这一串式子就是“预测模型”。它把未来的状态表示成“当前状态贡献的零输入响应 未来控制量贡献的受控响应”。刚看MPC资料的人常被这里绕晕其实你只需要记住一句话给定初值 x(k) 和控制序列未来状态可以完全算出来。MPC要做的就是在这串可预测的状态里挑一个“最顺眼”的未来。顺不顺眼怎么量化用一个目标函数来描述。2.2 目标函数Q和R到底在平衡什么MPC的标准目标函数长这样J Σ (x(ki) - x_ref)ᵀ·Q·(x(ki) - x_ref) Σ u(ki)ᵀ·R·u(ki)第一项是“状态偏差的代价”意思是“我不想让状态偏离目标值太远”第二项是“控制能量的代价”意思是“我也不想让控制量太大、太折腾”。Q和R是对角权重矩阵它们不是凭空定的而是在表达你的控制偏好。Q大说明你更在意状态偏差系统响应会更“积极”代价是控制量会比较冲R大说明你更在意控制动作的平缓系统响应会变“懒”。本质上这是一个trade-off。很多人把Q和R当成需要“调”的玄学参数其实它俩在表达的是“你的需求是什么”而不是“系统需要什么”。想清楚这一点调参方向就清晰多了。注意这里没有把控制量变化率 Δu 写进目标。实际工程里直接限制u往往不够因为执行器比如舵机、阀门因为惯性或磨损更讨厌“高频大幅摆动”。所以更常见的写法是在目标函数里再加一项 Δu 的惩罚或者直接对 Δu 设约束。不然后果就是MPC解出来的控制量可能符合上下限但每一步都在剧烈跳变执行器根本跟不上控制效果一塌糊涂。2.3 约束MPC真正的“核心资产”MPC和LQR、PID最本质的差别不是预测而是“在优化里显式处理约束”。LQR推导出来的控制律是一个线性反馈 u -Kx它不会主动考虑“电机转速不能超过3000”“阀门开度不能超过100%”“电流不能超过额定值”这些限制。当你靠近约束边界时LQR只会照样按线性反馈算u结果就是饱和或者执行器长时间处于极限状态。MPC把约束作为优化问题的硬性/软性条件直接写进去典型是这样一组u_min ≤ u(ki) ≤ u_max Δu_min ≤ Δu(ki) ≤ Δu_max x_min ≤ x(ki) ≤ x_max所以在MPC里约束不是“事后裁剪”而是“事前规划”。这带来一个很大的工程优势你不需要为约束专门设计抗饱和回路、限幅逻辑、安全保护区约束已经参与了解算。这意味着系统在靠近约束边界时MPC会自动“提前踩刹车”因为它能预见到如果不收着来未来几步就会越过边界。约束写进优化里目标函数负责“选最好的那个解”约束负责“在合法的范围内选”。这两个东西合在一起MPC就变成了一个带约束的最优化问题这也是后面所有数值求解工作的起点。3. 滚动优化的工程真相为什么每步都要全部重算3.1 开环最优不等于闭环最优很多第一次看MPC的人会产生一个疑惑既然我在当前时刻已经解出了一个最优的未来控制序列为什么不把这串控制量一次性发给执行器让系统照着跑完这听上去很合理但实际操作中几乎没有人这么做。原因是模型不可能绝对准确扰动也不可能提前知道。我举个例子。你开车用导航规划出一条“接下来的5公里最优路线”但如果真的拿到了路线就闭着眼睛开中途突然有辆车加塞、临时修路、甚至只是轮胎侧滑了一下你都会立刻脱离那条“最优路线”。正确的做法是方向照导航走但眼睛始终盯着路发现偏差就实时修正路线。MPC的滚动优化就是这个逻辑每个采样时刻用当前实测的状态或者滤波估计的状态作为初值重新做一次预测、重新解一次优化得到新的控制序列但只执行第一步。等到下一个采样时刻状态刷新了再重来一遍。这就是“滚动”的含义——不是在整个运行过程中只做一次规划而是边执行边规划。3.2 反馈校正MPC不是开环控制器这里必须强调一点MPC并不是一个开环控制器它是有反馈的。反馈的环节就在于“每个时刻都用当前状态重新初始化预测”。用状态空间模型做预测时问题其实很微妙你的模型不可能和真实系统完全一样。如果模型有误差那么预测的轨迹和系统实际跑的轨迹必然有偏差。如果只是开环地把控制序列发出去这个偏差会越积越大。但滚动优化相当于每隔一个采样周期就用一次实测状态把预测拉回到真实轨道上偏差被持续“纠正”。这也是为什么很多人学MPC时会觉得“概念简单但写代码总觉得哪里不对”——问题往往出在你有没有在每一个控制周期里正确地把当前状态反馈进去。如果这一步做错了MPC会退化成一个开环的前馈控制鲁棒性会大幅下降和PID闭环相比甚至可能更差。3.3 预测时域Np与控制时域Nc的取舍滚动优化有两个关键参数预测时域Np和控制时域Nc。Np是“看多远”。Np太短系统还没来得及体现出主要动态MPC就只看眼前一点效果类似短视的“近视眼”对惯性大的系统容易振荡Np太长一方面计算量增大另一方面远期预测的模型误差累积很大远期信息其实不太可信而且Np过大还会让系统过于保守响应变慢。经验上Np至少要覆盖被控对象主要动态时间常数的3到5倍比如你的系统稳定时间大概10秒采样周期0.1秒那Np取50到100是合理的。Nc是“未来的控制量允许多少步自由变化”。Nc越接近Np优化变量越多计算越慢行为也越灵活Nc设为1到3时MPC相当于假设“我只管前几步的动作后面保持不动”。工业中经常把Nc设得比Np小很多主要是为了降低计算量。代价是控制自由度减少性能会略打折扣。我的建议是仿真阶段先让NcNp看到性能上限要上实时系统时再把Nc往下调观测性能损失找到性价比最高的点。3.4 每步重算算力花在哪了“每步重算”听起来很浪费但它是MPC鲁棒性的根基。真正让MPC算力吃紧的不是重算本身而是每步重算的那个优化问题规模。Np50、Nc20优化变量就有20个控制量再加状态误差等几十个自由度对于现代计算机来说其实很小。真正费时间的往往是问题“坏条件”数值病态导致的迭代次数上升这点我会在第六节详细说。4. 从最优控制到数值求解MPC求解器到底在解什么4.1 把MPC变成QP问题的过程前面我把MPC写成了“目标函数约束”这听起来很抽象。到了实现阶段你首先要破除一个误区求解器不是在“模拟系统”而是在“解一个二次规划问题”。具体来说把预测递推展开、代入目标函数、把约束整理成矩阵不等式之后MPC会被整理成这样一个标准形式min (1/2)·zᵀ·H·z fᵀ·z s.t. A_ineq·z ≤ b_ineq l_b ≤ z ≤ u_b其中 z 是优化变量向量里面拼接了未来Nc步的控制量和可能的状态偏差H是Hessian矩阵它是从Q、R矩阵经过预测模型“折叠”出来的f是线性项包含目标状态和当前状态的信息约束则全部变成了关于z的线性不等式。这个形式就是标准的二次规划QP。Hessian矩阵H在这里起着双重作用它既是目标函数的二阶曲率也编码了预测模型对控制输入的动态响应。这也是为什么MPC不能简单地用梯度下降乱解——H的性质是否正定、条件数大小直接决定了解算的难度。4.2 手写QP还是用求解器我见过不少人想自己手写MPC求解器从预测矩阵到QP求解器全自己撸一遍。这个想法的学习价值极大真的手写一遍你对MPC的理解会深很多。但工程上我强烈不建议这么做。原因很简单QP求解器是一个高度工程化的数值算法要考虑稀疏性利用、数值稳定性、热启动、计算耗时确定性worst-case execution time等一大堆问题这东西已经是有几十年积淀的领域没必要重复造轮子。你需要做的是理解建模层和求解层的分工。建模层根据模型、Q、R、约束生成H、f、A_ineq、b_ineq。求解层输入这些矩阵输出最优z也就是未来控制序列。在Python里用CVXPY或OSQP在C里用osqp-eigen或acados在MATLAB里用自带MPC工具箱都是这个分工。这里给一个基于OSQP的极小MPC示例。代码不追求性能重在展示“建模层到求解层”的对应关系。以下是一个一阶惯性系统的跟踪MPCimport numpy as np import osqp from scipy import sparse # 离散模型: x(k1) a*x(k) b*u(k) a 0.9 b 0.1 x0 0.0 x_ref 1.0 Np 30 # 预测时域 Nc 10 # 控制时域 # 预测展开: 用Nc个控制量预测Np步状态 # 状态预测 A_pow*x0 B_aug*u_seq A_pow np.array([a**(i1) for i in range(Np)]) B_aug np.zeros((Np, Nc)) for i in range(Np): for j in range(min(i1, Nc)): B_aug[i, j] a**(i-j) * b # 目标函数: min sum((x-x_ref)^2 * q) sum(u^2 * r) q 1.0 r 0.1 H B_aug.T B_aug * q np.eye(Nc) * r f (B_aug.T (A_pow * x0 - x_ref)) * q # 约束: 0 u 1 lb np.zeros(Nc) ub np.ones(Nc) prob osqp.OSQP() prob.setup(Psparse.csc_matrix(H), qf, Asparse.eye(Nc), llb, uub, verboseFalse) res prob.solve() u_opt res.x # 只执行第一步 u_action u_opt[0] print(当前时刻应施加的控制量:, u_action)这个例子很粗糙但对理解MPC的解算结构非常有帮助。你可以看到Hessian矩阵H就是从B矩阵预测矩阵和Q/R权重“折叠”出来的线性项f携带了当前状态和目标信息约束直接作用在控制量上。跑一遍你会直观感受到“预测”“优化”“执行第一步”这三个动作是如何在一个采样周期内完成的。4.3 求解器选型参考不同场景下求解器的选型差异很大我整理一个基于个人经验的对照表求解器语言适用场景优点注意点OSQPC/C/Python中小规模MPC、嵌入式原型开源、对稀疏问题效果好、支持热启动需要预先把问题写成稀疏矩阵qpOASESC实时MPC尤其是冷启动多的情况专门面向MPC场景设计计算快对问题尺度较敏感约束冗余时易退化acadosC/C非线性MPC、需要高刷新率集成了多种QP求解器和NLP求解器使用门槛偏高适合有基础的开发者MATLAB MPC ToolboxMATLAB快速验证算法、学术仿真建模方便可视化完善不适合直接部署到嵌入式硬件CVXPYPython快速原型、教学、离线仿真建模直观改模型快效率低不建议用于实时控制选型建议如果你是在做学习和仿真用CVXPY或MATLAB最舒服如果要做嵌入式实时MPC我建议从OSQP或qpOASES入手先跑通一个最小闭环再考虑上acados这类“全家桶”。别一上来就追求最先进的工具链控制器的核心永远是控制逻辑本身。4.4 实时性的真相采样时间可能比你想象的更宽裕有些人一听MPC就觉得“算不过来”其实是被某些宣传误导了。对于典型的线性MPC状态维度几维到几十维Np几十步优化变量几十个这在现代嵌入式处理器上用OSQP都是微秒到毫秒级的事。真正让计算时间暴涨的往往是状态维度很高、Np很大、约束写得有冗余、或者问题数値病态导致求解器迭代次数飙升。所以解决实时性问题的顺序应该是先确认问题建模是否合理再确认求解器配置是否正确比如禁用无关输出、开启热启动最后才去换更快的求解器。5. 一个能跑的MPC从一阶系统到倒立摆还不够5.1 先跑通一阶再考虑复杂对象很多人拿到MPC代码第一步就打算上倒立摆、四旋翼、机械臂。我真心建议你先在一阶惯性对象上跑通因为一阶系统只有一个状态预测、优化、反馈的每个环节都可以画出来看明白。以第四节那段代码为例你可以做一个测试逐步把Q调大观察控制量的变化把R调大观察响应变慢的速度再把Np缩短观察系统是否出现振荡。这几个实验做完你对MPC的直觉会比看十篇论文都有效。我发现刚接触MPC的朋友最容易在这一步把“Q和R影响目标”错误地理解成“Q和R影响稳定性”——它们影响的是最优解的偏向稳定性则更依赖Np、模型准确度和约束设计。5.2 从一阶到倒立摆差的不是“预测”而是“非线性”一阶系统跑通以后下一个阶段的典型对象是倒立摆。很多人想当然地以为倒立摆无非是多加一个状态、多加一个约束实际上倒立摆是强非线性系统直接用线性MPC做在大角度范围内必然失效。这时你有两条路第一条路线性化MPC。在平衡点附近做线性化得到线性状态空间模型然后用标准线性MPC。这个方案在小角度摆动时效果不错实现也简单。第二条路非线性MPCNMPC。直接用非线性模型目标函数里求解器换成能求解非线性规划的NLP求解器比如acados搭配IPOPT。NMPC性能上限更高但数值难度陡增局部最优、求解时间不确定、初值敏感性都是现实问题。我的建议是如果对象在正常工作点附近非线性不强优先用线性MPC加反馈校正去补足只有当工作范围确实很宽、线性模型无法覆盖时再考虑NMPC。工程上能不用非线性就不用非线性这不是保守而是对鲁棒性负责。5.3 对MPC架构的完整理解状态估计不可忽略写MPC的人还有个常见盲区状态变量常常不是全部可以直接测到的。真实系统里你往往只能测到输出y而状态里的某些维度比如内部温度、速度、受力没有传感器或噪声很大。这时MPC不是直接拿“实际值”做预测而是拿“估计值”做预测。这就需要状态观测器工程里最常见的是卡尔曼滤波器。它把测量输出和模型预测融合起来给出一个尽量准确的状态估计然后把这个估计值送给MPC做滚动优化。这揭示了一个重要事实MPC的性能上限不只取决于优化求解还取决于你给它的状态估计准不准。模型好、求解器快但状态估计一塌糊涂MPC照样拉胯。5.4 调参实战先调什么后调什么关于调参顺序我形成了一套固定的打法先列出来供你参考。先把Np和采样周期定下来。Np必须覆盖对象主要动态的3到5倍时间长度采样周期则要满足香农采样定理并留足求解器计算余量。再把R粗略设一个量级。R的物理含义可以参考比如控制量最大幅值的平方的倒数。调Q阵。Q阵各对角元素其实是在表达“你有多在意对应状态量的偏离”不同状态量量纲不同位置是米、速度是米/秒不能简单地把Q都设成1否则优化会偏向量纲更大的变量。标准的做法是按状态量的典型量纲做归一化。最后微调R。R越小控制动作越凌厉R越大动作越平滑。观察执行器的实际输出调整到既不抖又能快速到位即可。约束按物理极限直接填不要为了“让求解器别报错”而故意放宽约束本身就是信息放宽约束等于主动放弃预测控制的优势。调参过程一定要配合图表观察我每次都会把实际状态、预测轨迹、控制量、约束边界都画在同一张图里一眼就能看出问题出在“预测过冲”还是“控制饱和”还是“约束不可行”。6. 工程落地时那些逃不掉的坑6.1 权重相差太大导致数值病态MPC落地最常踩的坑之一是Q和R的数量级差太多比如Q1000、R0.0001目标函数里两项差的量级可能有千万倍。这会导致Hessian矩阵的条件数差得离谱求解器在数值上近乎“瞎眼”——它对正常的目标变化不敏感稍微一点舍入误差就可能让优化结果抖动。解决方向有三个一是合理归一化状态和控制量不要让量级跨度过大二是用权重矩阵的平方根形式重新参数化目标函数三是选择对数值稳定性更友好的求解器比如OSQP对稀疏病态问题处理得就比较好。记住一个原则目标函数的数值尺度要让所有代价项都在同一个数量级附近求解器才能正常工作。6.2 约束不可行现实世界不允许“无解”做仿真时你可能会遇到一个很经典的错误求解器返回“无解”infeasible problem。控制领域的行话叫约束过强导致可行域为空。比如你把控制量约束设得很紧同时又把状态约束设得很紧模型预测在未来几步发现无论怎么给控制量状态都会越界那这个问题就没有可行解。这时MPC会直接“罢工”——这在实时控制里是致命的。处理思路把物理上不能突破的约束设为硬约束把可以轻度违反的约束设为软约束并给软约束加上一个惩罚权重。软约束的含义是系统被允许在极端情况下略微越界但会付出代价。这样即便某一步出了特殊情况求解器也总能给出一个尽量靠近约束边界的解而不是回复“无解”。工程经验告诉我状态约束几乎都应该做软约束控制输入约束才是真正的硬约束因为输入上限是执行器的物理极限越界意味着执行器根本做不到。6.3 终端约束理论上很漂亮工程上怎么落地经典MPC理论里有一个很重要但是也很骨感的结论为了保证闭环稳定性需要在预测时域末端加终端约束也就是要求x(kNp)必须落到某个终端集合内并且终端代价函数要满足特定条件。这套理论很严谨比如终端等式约束x(kNp)x_ref在理论上能保证渐近稳定但在实际工程中让系统在一个有限时域内精确到达目标状态往往要不现实地拉长Np或者产生巨大的控制量。工程上的常见妥协是把终端等式约束去掉改成一个足够大的终端代价权重也就是在目标函数里额外加一项P·(x(kNp)-x_ref)²其中P取一个较大的矩阵。理论上这叫“近似终端代价”它不能给出绝对的稳定性保证但只要P取得够大实际闭环效果通常可以接受。如果你的系统安全要求极高需要形式化稳定性证明那终端约束这条路不能省需要专门做可达集分析和终端权重设计。6.4 延时补偿计算完成的瞬间系统已经走远了实时MPC有一个非常隐蔽但后果严重的工程问题求解是需要时间的。假设采样周期是50ms求解器用了15ms才算完那么这15ms里系统的状态已经变化了你用“15ms前的状态”解出来的控制量作用在“当前系统”上显然是滞后的。如果控制频率一高、计算时间占比一大这个滞后会导致实际性能明显劣于仿真。工程上的处理手法主要有三种输入延时补偿把被控对象模型扩维把输入延时建模进状态空间MPC在预测时天然把“状态反馈时刻到控制生效时刻”的延时考虑进去。计算延时补偿在k时刻开始求解时先预测出一个“当前控制量u(k)”再去迭代求解未来序列而下一个控制量u(k1)在k1时刻到达之前就已经算好了用“上一时刻对未来状态的预测值”作为初值去做热启动。热启动将上一时刻的优化解作为当前时刻求解器的初始解这样求解速度会大幅提升也是减轻延时影响的有效手段。延时问题在学术仿真里几乎不被提及但在真实系统中往往决定项目成败。我见过太多控制算法“仿真无敌、上机就废”的案例一大半都是延时处理不到位。写到这里回看这些年和MPC打交道的过程我最深的体会是MPC从来不是“调一个Q、R就完事”的控制器它是一个由模型、预测、优化、约束、状态估计、求解器共同构成的系统。任何一个环节没想清楚最终都会在实时运行中以某种形式爆发出来。所以我个人调试MPC时已经把流程固化成了刻板动作先确认模型方向和量纲再确认状态估计靠谱然后才去盯优化求解的结果。参数永远放在最后调因为参数只是把前面所有决策的偏好“翻译”成数值前面的模型和架构错了参数调得再完美也只会在错误的方向上越走越远。希望你少走我当年走过的弯路。
 如何快速穿越 8 层组件)
