做运动控制这几年MPC模型预测控制是同行问我最多的话题之一。早些年一提 MPC大家都觉得是论文里的东西落地难、算不动现在反过来了无人机、机器人、精密运动平台、车辆运动控制几乎到处都是 MPC 的身影。尤其是 LTV MPC也就是线性时变模型预测控制在轨迹跟踪这类场景里几乎成了默认解法。这篇文章我就把一套完整的 LTV MPC 设计链路讲清楚预测模型怎么搭、线性化怎么做、代价函数和约束怎么调、代码怎么写、遇到不可行和抖振怎么排查。适合已经有 PID、LQR 基础想往预测控制方向深一步的工程师和研究生。1. 为什么控制器选型最终绕到 MPC 和 LTV MPC1.1 约束与预测MPC 相比 PID/LQR 的本质区别传统的 PID 和 LQR 不是不好用而是存在两个结构性的短板。第一个短板是不能显式处理约束。电机有力矩上限转向机构有角度极限执行器有速率限制这些物理约束无时无刻不在。PID 和 LQR 的应对方式是不问未来事后限幅——计算出一个指令如果超限就剪掉。剪掉之后系统实际执行的变量和控制器认为的变量不一致就会产生积分饱和、抗饱和逻辑、控制性能退化等一系列连锁问题。我调试过一个移动机器人用 LQR 做轨迹跟踪速度指令超过电机上限后被限幅机器人会在弯道处明显往外飘调增益效果非常有限因为问题压根不在增益上。第二个短板是没有前瞻性。反馈控制只根据当前误差做决策看不到未来两秒路况的变化。同样是过弯一个能看到前方曲率增大的控制器会在进弯前就减速而纯反馈的 LQR 只有在真正进入弯道、误差显现之后才开始反应必然慢半拍。MPC 的核心思想就是在每个采样时刻拿一个预测模型把未来一段时间预测时域 N的行为算出来在满足约束的前提下优化出一段最优控制序列然后只执行第一步下一步重新来。这就是常说的滚动优化、滚动时域。因为这个优化问题里有预测、有约束、有代价函数所以 MPC 既能提前看到未来又能把约束当作一等公民来处理——约束不是事后剪的而是在求解时就保证了。1.2 线性时变模型非线性轨迹跟踪的现实答案线性 MPC 的问题也很直接它只有一组固定的 A、B 矩阵必须在某个工作点附近线性化。如果你跟踪的路径比较平缓、速度变化不大一个工作点撑全场是可以的。可一旦轨迹曲率变化明显或者速度范围很宽单一线性模型就无法代表系统行为。举一个很直观的例子。用运动学模型描述一个差速机器人ẋ v·cosθẏ v·sinθθ̇ ω其中 v 是线速度ω 是角速度θ 是航向角。这个系统的输入矩阵 B 里含有 cosθ 和 sinθ。机器人在不同朝向时同样的 v 作用在 x 方向和 y 方向的效果完全不同。你用一个固定的 B 矩阵去描述一个正在掉头转向的机器人预测误差会很大后面约束都成了笑话。LTV MPC 的做法是在每一个采样时刻沿着参考轨迹或者当前的运行轨迹逐点做线性化得到一组随时间/沿轨迹变化的矩阵序列 A(k)、B(k)用它们搭一个时变预测模型。虽然每一步解出来的仍是一个凸的二次规划QP但模型本身抓住了系统在不同运行点上的非线性特征。这就是线性时变四个字的含义问题是线性的模型是变化的。为什么不直接上非线性 MPCNMPC因为在工程落地上NMPC 是要在每个时刻解一个非线性规划NLP非凸、求解时间不可控、需要专门的求解器和初值策略调试成本高好几个量级。而 LTV MPC 仍然是一个 QP有成熟的求解器、有可靠的热启动策略、求解时间可以压得很稳。所以对绝大多数轨迹跟踪应用LTV MPC 是性价比最高的中间路线非线性信息够用凸优化的便利也够用。2. LTV MPC 的理论地基预测模型、线性化与误差模型2.1 从非线性运动学模型到逐点线性化先定一个问题框架。被控对象是连续非线性系统ẋ f(x, u)给定一条参考轨迹包含状态轨迹 x_ref(k) 和输入轨迹 u_ref(k)k 0, 1, …, N。在轨迹上的每个点做一阶泰勒展开f(x, u) ≈ f(x_ref(k), u_ref(k)) A_c(k)(x − x_ref(k)) B_c(k)(u − u_ref(k))其中 A_c(k) 和 B_c(k) 是 f 对状态和输入在参考点处的雅可比矩阵。对差速机器人而言A_c(k) [ ∂f/∂x ] [0, 0, −v_r·sinθ_r] [0, 0, v_r·cosθ_r] [0, 0, 0]B_c(k) [ ∂f/∂u ] [cosθ_r, 0] [sinθ_r, 0] [0, 1]这里的下标 r 表示第 k 个参考点上的值。可以看到B 矩阵确实随 θ_r 在变化这正是 LTV 模型比固定线性模型更贴近真实系统的地方。有了连续时间的雅可比矩阵之后要做离散化。最朴素的离散化是前向欧拉A I A_c·dtB B_c·dt。在采样周期相对于系统动态足够小的时候欧拉法的精度够用。如果采样周期偏大、系统动态偏快建议用更精确的离散化方法比如对增广矩阵做矩阵指数运算。但实际项目里我通常先用欧拉法搭起框架再根据仿真和实测精度决定是否升级。2.2 误差状态与参考残差项的处理定义误差状态 e(k) x(k) − x_ref(k)输入偏差 δu(k) u(k) − u_ref(k)。那么预测方程可以写成e(k1) ≈ A(k)·e(k) B(k)·δu(k) d(k)这里有个很容易被忽略的项 d(k)它是参考轨迹和模型之间的残差d(k) f(x_ref(k), u_ref(k)) − x_ref(k1)如果参考轨迹是用同一个离散模型生成的d(k) 理论上为零可以省略。很多教材例子都默认这种情况。但实际工程里参考轨迹往往来自路径规划层它可能只考虑了运动学或者纯几何关系并没有严格满足你用于控制的动力学模型。这种情况下如果不算 d(k)预测就会出现系统性偏差体现为跟踪的稳态误差。我踩过这个坑。有一次把规划层给的轨迹直接接到 LTV MPC 上仿真结果里机器人和参考轨迹之间总有一个固定偏差调大 Q 权重也没用。后来检查发现参考轨迹那些点上用模型推算出来的下一时刻状态和给的参考状态对不上差了常数项。把 d(k) 补进预测方程之后偏差立刻消失。所以判断是否要 d(k) 的标准很简单参考轨迹是否由控制模型自身生成。是则不需要不是则必须补。使用误差状态而不是绝对状态还有一个实际好处数值尺度更合理。如果参考状态本身就很大比如车辆位置坐标上千而误差只有零点几用绝对状态组装代价函数时数值上很容易出现病态。用误差状态代价函数里每一项都围绕偏差展开尺度自然得多。2.3 增量式写法隐式积分与抗模型失配上面的表达式用 δu 作为决策变量代价函数惩罚的是输入相对参考的偏差。这种写法在模型完全匹配时很好用但一旦存在未建模动态、参数漂移或者外部扰动系统容易出现静态偏差。原因很简单代价函数里没有对误差的积分作用MPC 本质上是一个带约束的比例前馈控制器。一个非常实用的改进是把决策变量换成控制增量 Δu(k) u(k) − u(k−1)并把上一拍的实际输入 u(k−1) 扩充进状态。这样预测模型变成增广形式[x(k1); u(k)] [A(k), B(k); 0, I] · [x(k); u(k−1)] [B(k); I] · Δu(k)对 Δu 加代价等价于给系统加入了隐式的积分作用。模型失配时误差会持续反映在 Δu 上推动实际输入不断修正直到误差被消除。代价是状态维度增加、QP 规模略大但对 3 到 6 维状态的小系统来说这点开销可以忽略。我个人的习惯是做轨迹跟踪的 LTV MPC默认就用增量式写法。它带来的鲁棒性提升非常明显尤其是当你没有做扰动观测器、没有在线参数估计的时候增量式是最便宜的抗静差手段。3. 代价函数与约束的工程化设计3.1 权重矩阵 Q、R、终端权的实际语义典型的跟踪代价函数长这样J Σ e(k)ᵀ·Q·e(k) Σ δu(k)ᵀ·R·δu(k) e(N)ᵀ·Q_N·e(N)Q 是状态误差权重R 是输入权重Q_N 是终端代价。对角线权重 Q_ii 的含义可以理解为这个方向允许多大误差的倒数。一个很实用的起步套路是归一化如果你希望位置误差控制在 0.1 米以内那么 Q 对应位置的元素可以取 1/(0.1)² 100希望航向误差控制在 0.1 弧度以内则航向权重取 1/(0.1)² 100。这样设置之后各项的代价量级大致均衡后续微调也更有手感。R 的语义类似如果线速度允许的变化幅度是 0.5 m/sR 对应元素取 1/(0.5)² 4。注意 R 不是越小越好。R 太小会让控制动作过于激进尤其在有测量噪声和模型误差的时候会表现为控制量毛刺、抖动。R 太大则响应迟钝、跟踪滞后。一个好的起步点是用上面的归一化方法得到初始值然后仿真观察再按 2 倍、5 倍的步长调整 Q 和 R 的相对比例。有一个重要但容易被忽略的结论Q、R 同时乘以同一个常数最优解路径不变在无约束或约束不激活的意义下只有相对比例才真正影响控制性能。但绝对数值会影响求解器的数值条件和收敛速度所以不建议权重设得太离谱比如上千万量级。终端代价 Q_N 的作用是缓解有限时域带来的近视问题。没有终端代价时预测时域末尾的状态误差不受惩罚控制器会在最后几步出现不管后果的激进动作。实际调参时如果发现末端轨迹有明显的回头趋势或者最后几步约束总是贴着边界多半就是终端代价没设好。工程上两种做法一是把 Q_N 取为 Q 的 5 到 10 倍简单有效二是求解参考工作点处的离散黎卡提方程把 Q_N 设为无穷时域 LQR 的代价矩阵理论味道更足实现也不复杂。3.2 约束的加法与软约束约束分为几类。输入约束最常见比如电机转速上下限、转向角度上下限一般直接写成硬约束u_min ≤ u ≤ u_max。状态约束比如位置不能越过安全边界、速度不能超过上限也能加但要小心一个问题状态约束必须和参考轨迹、模型能力一致。如果参考轨迹本身就要求机器人走出约束范围那这个 QP 永远不可行。对于状态约束我强烈建议用软约束加惩罚的写法而不是硬约束。做法是引入松弛变量 s把状态约束写成g(e) ≤ s ε其中 s ≥ 0并在代价函数里加上 M·‖s‖这样一来正常情况下约束严格满足极端情况下系统可以牺牲一点约束来换取可行性避免整个控制器崩溃。罚系数 M 要取一个比较大的值比如比状态权重高两个数量级但也不能无限大否则数值上又回到硬约束的状态。另一个经常出现在代码评审里的问题是用 δu 作为决策变量时约束必须加在实际输入 u u_ref δu 上而不是直接对 δu 限幅。我有一次看到别人写的代码设置了 −u_max ≤ δu ≤ u_max以为在限制输入但参考输入 u_ref 本身就有 1.0加上 δu 之后实际输入到了 2.0完全超限。约束写错位置后面的性能分析都是白做。3.3 采样周期、预测时域、控制时域的配套选型这三个参数是配套的不能单独拍脑袋。采样周期 dt 原则上要能分辨系统的主要动态经验上取开环主导时间常数的 1/10 到 1/20。对移动机器人20ms 到 100ms 都是常用区间对更慢的过程对象比如温度控制、楼宇系统可以到秒级。预测时域 N 乘以 dt 要覆盖从当前到系统基本稳定的时间跨度。如果期望闭环稳定时间在 2 秒左右dt 取 0.1 秒那么 N 至少取 20。很多人问是不是 N 越大越好。理论上不完全是。N 太大计算量增加更重要的是远处的线性化模型本身已经不可信了LTV 模型的优势到远处会被线性化误差侵蚀。所以 N 应当覆盖目标时间但没必要盲目翻倍。我在工程里通常先按 1 到 2 倍的期望稳定时间估算 N再在仿真里对比 N10 看性能是否明显提升如果没有就维持原值。控制时域 M 是另一个自由度。它表示从第 M 步开始输入保持恒定。缩短 M 可以直接减少决策变量数量显著降低计算量代价是控制自由度减少。对嵌入式平台M 取 N 的 1/3 到 1/2 是常见的折中。但 LTV MPC 因为在时域内模型本身在变缩短 M 相当于假设后半段输入不变这个假设在模型变化明显时略粗暴。所以如果计算预算允许我倾向于不缩短 M而是先把 N 缩到够用即可。参数取值偏小的影响取值偏大的影响起步参考值采样周期 dt模型失真、约束信息丢失计算开销大主导时间常数 / 10预测时域 N前瞻不足、易失稳计算量大、远端模型失真覆盖 1~2 倍稳定时间控制时域 M控制自由度不足计算量大N 的 1/3 ~ 1/2权重 R控制猛、易抖响应慢、跟踪滞后按输入允许量归一化4. LTV MPC 从公式到代码的完整实现4.1 单步优化与滚动时域的算法主循环不管用什么语言、什么求解器LTV MPC 的主循环结构都是一样的。每个采样周期做这几件事拿到当前状态估计值 x_k状态估计器输出的不是理想状态。截取参考轨迹窗口x_ref[0..N]、u_ref[0..N−1]。对窗口内每个参考点做线性化和离散化得到 A(k)、B(k)必要时计算残差 d(k)。组装 QP 问题决策变量是误差状态序列和控制偏差序列代价函数包含 Q、R、Q_N约束包含模型方程和输入/状态约束。调用求解器求解。6. 取出最优序列的第一个控制偏差 δu(0)计算实际输入并下发执行。等待下一个采样时刻把预测窗口整体向前平移一步重复上述过程。第 7 步就是滚动时域的含义。每次只执行第一步但每步都重新优化。这个反馈机制天然能抵抗一部分模型失配和扰动因为误差每步都会被看到并修正。4.2 Python OSQP 的参考实现下面给一套完整可跑的参考实现用 Python 的 cvxpy 建模、OSQP 求解。对象是差速机器人参考轨迹是圆形匀速运动。import numpy as np import cvxpy as cp # 采样周期与预测时域 dt 0.1 N 25 nx, nu 3, 2 # 状态[x,y,theta]输入[v,omega] # 权重矩阵 Q np.diag([10.0, 10.0, 0.5]) R np.diag([0.1, 0.1]) QN np.diag([50.0, 50.0, 2.0]) # 输入约束 u_min np.array([-0.5, -1.5]) u_max np.array([1.5, 1.5]) def discrete_ltv(x_eq, u_eq): 在参考点 (x_eq, u_eq) 处线性化并欧拉离散化 th x_eq[2] v u_eq[0] A np.array([ [1.0, 0.0, -v * np.sin(th) * dt], [0.0, 1.0, v * np.cos(th) * dt], [0.0, 0.0, 1.0] ]) B np.array([ [np.cos(th) * dt, 0.0], [np.sin(th) * dt, 0.0], [0.0, dt] ]) return A, B def nonlinear_step(x, u): 真实被控对象(仿真用)前向欧拉 return x np.array([ u[0] * np.cos(x[2]), u[0] * np.sin(x[2]), u[1] ]) * dt def mpc_step(x_current, x_ref, u_ref): 求解单步 LTV MPC返回第一个控制偏差 du e cp.Variable((nx, N 1)) du cp.Variable((nu, N)) cost 0.0 cons [e[:, 0] x_current - x_ref[0]] for k in range(N): A, B discrete_ltv(x_ref[k], u_ref[k]) # 预测模型误差状态递推 cons [e[:, k 1] A e[:, k] B du[:, k]] # 实际输入必须落在约束内 u_actual u_ref[k] du[:, k] cons [u_min u_actual, u_actual u_max] # 代价 cost cp.quad_form(e[:, k], Q) cp.quad_form(du[:, k], R) # 终端代价 cost cp.quad_form(e[:, N], QN) prob cp.Problem(cp.Minimize(cost), cons) prob.solve(solvercp.OSQP, warm_startTrue) if prob.status not in (cp.OPTIMAL, cp.OPTIMAL_INACCURATE): print(solver status:, prob.status) return None return du[:, 0].value # 参考轨迹半径2.0的圆角速度0.6 rad/s r, w 2.0, 0.6 T_total 20.0 ts np.arange(0, T_total, dt) x_ref np.array([[r * np.cos(w * t), r * np.sin(w * t), w * t np.pi / 2] for t in ts]) u_ref np.array([[w * r, w] for t in ts]) # 线速度r*w角速度w # 初始状态故意给一个偏移 x np.array([2.5, 0.0, 0.0]) for i in range(len(ts) - N - 1): xr x_ref[i:i N 1] ur u_ref[i:i N] du mpc_step(x, xr, ur) if du is None: print(第, i, 步求解失败) break u ur[0] du x nonlinear_step(x, u) # 这里记录仿真轨迹画图对比即可这套代码的关键点有三个。第一线性化和离散化是在每个参考点上单独做的所以 A、B 序列里包含轨迹的形状信息。第二约束加在总是实际输入上不是加在 du 上。第三OSQP 开了 warm_start连续滚动求解时上一个时刻的解作为下一个时刻的初值收敛速度明显加快。如果参考轨迹不是由模型自身生成的记得在预测方程里补残差项把上面代码里的递推约束改成d nonlinear_step(x_ref[k], u_ref[k]) - x_ref[k 1] cons [e[:, k 1] A e[:, k] B du[:, k] d]这就是前面说的 d(k) 项。补上它跟踪精度才守得住。4.3 求解器为什么选 OSQP以及向嵌入式移植的路径在原型验证阶段我推荐 OSQP原因是它在小规模凸 QP 上收敛快、支持热启动而且接口简单。cvxpy 里的 OSQP 默认参数对绝大多数 MPC 问题够用。如果遇到收敛慢可以调整容差参数 eps_abs、eps_rel 到 1e-5 左右或者限制最大迭代次数换取稳定求解时间。另一个选择是 qpOASES它属于 active-set 方法对中小规模密集 QP 很有优势尤其在 QP 维数不超过几百的时候。ECOS、SCS 是内点法体系鲁棒但偏慢一般用于离线验证而不是在线滚动。到嵌入式落地阶段我会把 cvxpy 拿走直接用求解器原生接口组装 QP。思路是把预测时域固定下来矩阵维度全部静态分配A、B 序列每步只更新数值、不改变稀疏结构。OSQP 的原生接口支持这种只更新数据、不重建立问题的模式速度能比 cvxpy 包装层快一个量级。如果目标平台资源更紧还可以采用 condensing 技术把状态变量消掉只保留控制变量把 QP 规模从 (N1)nx Nnu 压缩到 N*nu。这部分内容展开又是一篇长文但对小状态系统效果立竿见影。5. 实操中的常见问题与排查细节5.1 求解器报不可行不可行是所有 MPC 落地时最先遇到的坎。问题本身不复杂你给出的约束集合和模型预测在某个采样时刻没有交集。常见的触发原因有这么几类。第一参考轨迹本身不满足约束。比如输入约束是 −1.5 到 1.5而参考轨迹要求的角速度是 2.0那无论怎么优化控制序列都会碰壁。检查方法是把参考输入轨迹拉出来逐点对比约束上下限一眼就能看出问题。第二硬的状态约束过于激进。比如要求机器人未来 2 秒内位置误差必须落在 0.01 米以内而当前误差是 0.5 米线性化模型又不可能瞬间把误差拉回来于是不可行。解决办法是软约束或者把约束分段放松。第三终端等式约束。有些人喜欢加 e(N) 0这在理论上能保证稳定但在 LTV 框架下经常因为线性化误差导致不可行。我建议改用终端不等式约束或者干脆只有终端代价。排查不可行问题的顺序我一般这样走先去状态约束试跑只保留输入约束再检查参考输入是否在约束范围内然后取消终端约束看能否可行最后如果还不行检查数值问题比如权重矩阵尺度悬殊、状态变量单位不一致。绝大多数不可行问题在第三、第四步就能定位。5.2 跟踪偏差、末端抖动与控制量毛刺跟踪出现稳态偏差先不要急着调大 Q。按我前面的经验先确认两件事参考轨迹到底满不满足模型残差项 d(k) 有没有补上模型失配是不是系统性原因。如果这两个都不是再考虑把控制系统改成增量式写法或者加一个简单的状态观测器来估计扰动项。末端抖动表现在预测时域后段参考轨迹已经接近目标但控制序列在后半段剧烈摆动。这通常说明终端代价权重太小或者 R 权重过小导致控制增量惩罚不足。我会先加大 Q_N观察曲线是否平滑下来如果还抖再增加 R 或对 Δu 加惩罚。控制量毛刺是另一个常见现象。注意区分真抖和数值噪声真抖通常是权重配比的问题R 太小数值噪声则表现为相邻两个采样周期的控制指令毫无规律地跳动这时优先检查状态估计是否过于敏感比如直接用带噪声的测量值而没有滤波。解决方法对测量做滤波或者把代价函数改成对控制增量 Δu 惩罚都会很有效。5.3 实时性卡顿与计算瓶颈实时性不够先做量化把每次求解时间打印出来看是均值高还是尾部有个别尖峰。普遍问题出现在几个地方。一是求解器容差设得太严。对于 MPC控制精度并不需要解到机器精度。把 eps_abs、eps_rel 放到 1e-4 到 1e-5大多数情况下性能损失完全可以忽略但求解速度能提升好几倍。二是没有热启动。OSQP 的 warm_start 用上一拍的解作为初值在新问题与旧问题相似度高时迭代次数会大幅下降。这在滚动时域里几乎是免费的性能红利务必开启。三是预测时域过长。这个不用多解释决策变量数量直接决定 QP 规模。如果缩 N 之后性能可以接受那就缩。四是 QP 建模层的开销。cvxpy 这类库每次都会重建问题结构对实时性要求高的场合是瓶颈。落到原生接口后单步耗时往往能降低一个量级。5.4 问题症状速查表现象常见原因排查建议求解器返回不可行参考输入超约束范围 / 硬状态约束过紧 / 终端约束太强先去掉状态约束和终端约束逐步加回定位冲突源跟踪有稳态偏差参考不满足模型、d(k) 缺失、模型失配补残差项改用增量式写法控制量高频抖动R 过小、噪声敏感、对 u 而非 Δu 惩罚增大 R、滤波测量值、惩罚 Δu预测末端动作怪异终端代价不足增大 Q_N 或改为 LQR 终端矩阵求解时间波动大容差过严、缺热启动放宽容差、开启 warm_start某个方向响应慢权重相对比例失衡按允许误差归一化重新设 Q、R5.5 关于线性化误差的一个提醒最后单独说一句线性化误差。LTV MPC 的预测模型每步都是近似的误差在预测时域内会累积。预测时域越长误差越大。这就是为什么我前面反复强调别过度拉长 N。在实际项目中我习惯在仿真里故意加 10% 到 20% 的参数扰动跑多组随机场景看控制器是否还能稳定。不要只盯着一条完美曲线就拍板MPC 的鲁棒性测试比精确性测试重要得多。6. 我的调参经验次序与后续扩展6.1 从 LQR 起步的调参流程我把调参这件事拆成四步每一步都验证后再进下一步。第一步先不管约束把 MPC 当成一个有限时域的 LQR 来调。设置一个足够大的 N关掉约束直接用 LQR 的整定思路确定 Q、R 的相对比例观察闭环响应快慢和阻尼。第二步把输入约束加上。这时重点检查控制器在接近约束边界时是否平滑是不是总在边界上摩挲。如果频繁撞边说明 R 偏小控制动作和约束产生了持续冲突。第三步加上状态约束和软约束。这个阶段重点验证可行性尤其是在各种初始状态下求解器都应该返回最优解而不是不可行。第四步处理实时性。仿真没问题之后不断压缩求解时间观察性能折损找到求解时间和控制性能之间的平衡点。这套流程我用了很多次基本没有翻过车。直接一上来就把全套约束、权重、时域一次性配好出问题的时候根本分不清是哪一环节引起的。6.2 从 LTV MPC 再往上的路线LTV MPC 做扎实之后往上走的路径很清晰。如果模型非线性更强线性化误差已经不可接受下一步是 NMPC但要做好求解器和初值管理的准备。如果问题主要出在模型失配和参数漂移可以做自适应 MPC把模型参数在线辨识和 MPC 控制器耦合起来。如果想让 MPC 在极端情况下也能体面降级可以在代价函数里加入安全和性能的多目标处理这也是目前业界落地关注的方向。我个人最推荐的路线是先把 LTV MPC 的每个环节吃透尤其是线性化点选取和残差处理这两处细节。因为这两处是 LTV MPC 区别于教科书线性 MPC 的核心也是实际项目中最容易出问题的地方。把它们弄明白之后无论是往 NMPC 走还是往自适应方向走底子都是通的。做控制这么多年我最深的体会就是算法本身不难难的是知道每一步为什么这么做。LTV MPC 是一个不吃亏的选择值得花时间。 
长河君 · 2026/10/14 22:06:58 · 阅读 1.2k LTV MPC深度解析：从线性化建模到轨迹跟踪控制实践
做运动控制这几年MPC模型预测控制是同行问我最多的话题之一。早些年一提 MPC大家都觉得是论文里的东西落地难、算不动现在反过来了无人机、机器人、精密运动平台、车辆运动控制几乎到处都是 MPC 的身影。尤其是 LTV MPC也就是线性时变模型预测控制在轨迹跟踪这类场景里几乎成了默认解法。这篇文章我就把一套完整的 LTV MPC 设计链路讲清楚预测模型怎么搭、线性化怎么做、代价函数和约束怎么调、代码怎么写、遇到不可行和抖振怎么排查。适合已经有 PID、LQR 基础想往预测控制方向深一步的工程师和研究生。1. 为什么控制器选型最终绕到 MPC 和 LTV MPC1.1 约束与预测MPC 相比 PID/LQR 的本质区别传统的 PID 和 LQR 不是不好用而是存在两个结构性的短板。第一个短板是不能显式处理约束。电机有力矩上限转向机构有角度极限执行器有速率限制这些物理约束无时无刻不在。PID 和 LQR 的应对方式是不问未来事后限幅——计算出一个指令如果超限就剪掉。剪掉之后系统实际执行的变量和控制器认为的变量不一致就会产生积分饱和、抗饱和逻辑、控制性能退化等一系列连锁问题。我调试过一个移动机器人用 LQR 做轨迹跟踪速度指令超过电机上限后被限幅机器人会在弯道处明显往外飘调增益效果非常有限因为问题压根不在增益上。第二个短板是没有前瞻性。反馈控制只根据当前误差做决策看不到未来两秒路况的变化。同样是过弯一个能看到前方曲率增大的控制器会在进弯前就减速而纯反馈的 LQR 只有在真正进入弯道、误差显现之后才开始反应必然慢半拍。MPC 的核心思想就是在每个采样时刻拿一个预测模型把未来一段时间预测时域 N的行为算出来在满足约束的前提下优化出一段最优控制序列然后只执行第一步下一步重新来。这就是常说的滚动优化、滚动时域。因为这个优化问题里有预测、有约束、有代价函数所以 MPC 既能提前看到未来又能把约束当作一等公民来处理——约束不是事后剪的而是在求解时就保证了。1.2 线性时变模型非线性轨迹跟踪的现实答案线性 MPC 的问题也很直接它只有一组固定的 A、B 矩阵必须在某个工作点附近线性化。如果你跟踪的路径比较平缓、速度变化不大一个工作点撑全场是可以的。可一旦轨迹曲率变化明显或者速度范围很宽单一线性模型就无法代表系统行为。举一个很直观的例子。用运动学模型描述一个差速机器人ẋ v·cosθẏ v·sinθθ̇ ω其中 v 是线速度ω 是角速度θ 是航向角。这个系统的输入矩阵 B 里含有 cosθ 和 sinθ。机器人在不同朝向时同样的 v 作用在 x 方向和 y 方向的效果完全不同。你用一个固定的 B 矩阵去描述一个正在掉头转向的机器人预测误差会很大后面约束都成了笑话。LTV MPC 的做法是在每一个采样时刻沿着参考轨迹或者当前的运行轨迹逐点做线性化得到一组随时间/沿轨迹变化的矩阵序列 A(k)、B(k)用它们搭一个时变预测模型。虽然每一步解出来的仍是一个凸的二次规划QP但模型本身抓住了系统在不同运行点上的非线性特征。这就是线性时变四个字的含义问题是线性的模型是变化的。为什么不直接上非线性 MPCNMPC因为在工程落地上NMPC 是要在每个时刻解一个非线性规划NLP非凸、求解时间不可控、需要专门的求解器和初值策略调试成本高好几个量级。而 LTV MPC 仍然是一个 QP有成熟的求解器、有可靠的热启动策略、求解时间可以压得很稳。所以对绝大多数轨迹跟踪应用LTV MPC 是性价比最高的中间路线非线性信息够用凸优化的便利也够用。2. LTV MPC 的理论地基预测模型、线性化与误差模型2.1 从非线性运动学模型到逐点线性化先定一个问题框架。被控对象是连续非线性系统ẋ f(x, u)给定一条参考轨迹包含状态轨迹 x_ref(k) 和输入轨迹 u_ref(k)k 0, 1, …, N。在轨迹上的每个点做一阶泰勒展开f(x, u) ≈ f(x_ref(k), u_ref(k)) A_c(k)(x − x_ref(k)) B_c(k)(u − u_ref(k))其中 A_c(k) 和 B_c(k) 是 f 对状态和输入在参考点处的雅可比矩阵。对差速机器人而言A_c(k) [ ∂f/∂x ] [0, 0, −v_r·sinθ_r] [0, 0, v_r·cosθ_r] [0, 0, 0]B_c(k) [ ∂f/∂u ] [cosθ_r, 0] [sinθ_r, 0] [0, 1]这里的下标 r 表示第 k 个参考点上的值。可以看到B 矩阵确实随 θ_r 在变化这正是 LTV 模型比固定线性模型更贴近真实系统的地方。有了连续时间的雅可比矩阵之后要做离散化。最朴素的离散化是前向欧拉A I A_c·dtB B_c·dt。在采样周期相对于系统动态足够小的时候欧拉法的精度够用。如果采样周期偏大、系统动态偏快建议用更精确的离散化方法比如对增广矩阵做矩阵指数运算。但实际项目里我通常先用欧拉法搭起框架再根据仿真和实测精度决定是否升级。2.2 误差状态与参考残差项的处理定义误差状态 e(k) x(k) − x_ref(k)输入偏差 δu(k) u(k) − u_ref(k)。那么预测方程可以写成e(k1) ≈ A(k)·e(k) B(k)·δu(k) d(k)这里有个很容易被忽略的项 d(k)它是参考轨迹和模型之间的残差d(k) f(x_ref(k), u_ref(k)) − x_ref(k1)如果参考轨迹是用同一个离散模型生成的d(k) 理论上为零可以省略。很多教材例子都默认这种情况。但实际工程里参考轨迹往往来自路径规划层它可能只考虑了运动学或者纯几何关系并没有严格满足你用于控制的动力学模型。这种情况下如果不算 d(k)预测就会出现系统性偏差体现为跟踪的稳态误差。我踩过这个坑。有一次把规划层给的轨迹直接接到 LTV MPC 上仿真结果里机器人和参考轨迹之间总有一个固定偏差调大 Q 权重也没用。后来检查发现参考轨迹那些点上用模型推算出来的下一时刻状态和给的参考状态对不上差了常数项。把 d(k) 补进预测方程之后偏差立刻消失。所以判断是否要 d(k) 的标准很简单参考轨迹是否由控制模型自身生成。是则不需要不是则必须补。使用误差状态而不是绝对状态还有一个实际好处数值尺度更合理。如果参考状态本身就很大比如车辆位置坐标上千而误差只有零点几用绝对状态组装代价函数时数值上很容易出现病态。用误差状态代价函数里每一项都围绕偏差展开尺度自然得多。2.3 增量式写法隐式积分与抗模型失配上面的表达式用 δu 作为决策变量代价函数惩罚的是输入相对参考的偏差。这种写法在模型完全匹配时很好用但一旦存在未建模动态、参数漂移或者外部扰动系统容易出现静态偏差。原因很简单代价函数里没有对误差的积分作用MPC 本质上是一个带约束的比例前馈控制器。一个非常实用的改进是把决策变量换成控制增量 Δu(k) u(k) − u(k−1)并把上一拍的实际输入 u(k−1) 扩充进状态。这样预测模型变成增广形式[x(k1); u(k)] [A(k), B(k); 0, I] · [x(k); u(k−1)] [B(k); I] · Δu(k)对 Δu 加代价等价于给系统加入了隐式的积分作用。模型失配时误差会持续反映在 Δu 上推动实际输入不断修正直到误差被消除。代价是状态维度增加、QP 规模略大但对 3 到 6 维状态的小系统来说这点开销可以忽略。我个人的习惯是做轨迹跟踪的 LTV MPC默认就用增量式写法。它带来的鲁棒性提升非常明显尤其是当你没有做扰动观测器、没有在线参数估计的时候增量式是最便宜的抗静差手段。3. 代价函数与约束的工程化设计3.1 权重矩阵 Q、R、终端权的实际语义典型的跟踪代价函数长这样J Σ e(k)ᵀ·Q·e(k) Σ δu(k)ᵀ·R·δu(k) e(N)ᵀ·Q_N·e(N)Q 是状态误差权重R 是输入权重Q_N 是终端代价。对角线权重 Q_ii 的含义可以理解为这个方向允许多大误差的倒数。一个很实用的起步套路是归一化如果你希望位置误差控制在 0.1 米以内那么 Q 对应位置的元素可以取 1/(0.1)² 100希望航向误差控制在 0.1 弧度以内则航向权重取 1/(0.1)² 100。这样设置之后各项的代价量级大致均衡后续微调也更有手感。R 的语义类似如果线速度允许的变化幅度是 0.5 m/sR 对应元素取 1/(0.5)² 4。注意 R 不是越小越好。R 太小会让控制动作过于激进尤其在有测量噪声和模型误差的时候会表现为控制量毛刺、抖动。R 太大则响应迟钝、跟踪滞后。一个好的起步点是用上面的归一化方法得到初始值然后仿真观察再按 2 倍、5 倍的步长调整 Q 和 R 的相对比例。有一个重要但容易被忽略的结论Q、R 同时乘以同一个常数最优解路径不变在无约束或约束不激活的意义下只有相对比例才真正影响控制性能。但绝对数值会影响求解器的数值条件和收敛速度所以不建议权重设得太离谱比如上千万量级。终端代价 Q_N 的作用是缓解有限时域带来的近视问题。没有终端代价时预测时域末尾的状态误差不受惩罚控制器会在最后几步出现不管后果的激进动作。实际调参时如果发现末端轨迹有明显的回头趋势或者最后几步约束总是贴着边界多半就是终端代价没设好。工程上两种做法一是把 Q_N 取为 Q 的 5 到 10 倍简单有效二是求解参考工作点处的离散黎卡提方程把 Q_N 设为无穷时域 LQR 的代价矩阵理论味道更足实现也不复杂。3.2 约束的加法与软约束约束分为几类。输入约束最常见比如电机转速上下限、转向角度上下限一般直接写成硬约束u_min ≤ u ≤ u_max。状态约束比如位置不能越过安全边界、速度不能超过上限也能加但要小心一个问题状态约束必须和参考轨迹、模型能力一致。如果参考轨迹本身就要求机器人走出约束范围那这个 QP 永远不可行。对于状态约束我强烈建议用软约束加惩罚的写法而不是硬约束。做法是引入松弛变量 s把状态约束写成g(e) ≤ s ε其中 s ≥ 0并在代价函数里加上 M·‖s‖这样一来正常情况下约束严格满足极端情况下系统可以牺牲一点约束来换取可行性避免整个控制器崩溃。罚系数 M 要取一个比较大的值比如比状态权重高两个数量级但也不能无限大否则数值上又回到硬约束的状态。另一个经常出现在代码评审里的问题是用 δu 作为决策变量时约束必须加在实际输入 u u_ref δu 上而不是直接对 δu 限幅。我有一次看到别人写的代码设置了 −u_max ≤ δu ≤ u_max以为在限制输入但参考输入 u_ref 本身就有 1.0加上 δu 之后实际输入到了 2.0完全超限。约束写错位置后面的性能分析都是白做。3.3 采样周期、预测时域、控制时域的配套选型这三个参数是配套的不能单独拍脑袋。采样周期 dt 原则上要能分辨系统的主要动态经验上取开环主导时间常数的 1/10 到 1/20。对移动机器人20ms 到 100ms 都是常用区间对更慢的过程对象比如温度控制、楼宇系统可以到秒级。预测时域 N 乘以 dt 要覆盖从当前到系统基本稳定的时间跨度。如果期望闭环稳定时间在 2 秒左右dt 取 0.1 秒那么 N 至少取 20。很多人问是不是 N 越大越好。理论上不完全是。N 太大计算量增加更重要的是远处的线性化模型本身已经不可信了LTV 模型的优势到远处会被线性化误差侵蚀。所以 N 应当覆盖目标时间但没必要盲目翻倍。我在工程里通常先按 1 到 2 倍的期望稳定时间估算 N再在仿真里对比 N10 看性能是否明显提升如果没有就维持原值。控制时域 M 是另一个自由度。它表示从第 M 步开始输入保持恒定。缩短 M 可以直接减少决策变量数量显著降低计算量代价是控制自由度减少。对嵌入式平台M 取 N 的 1/3 到 1/2 是常见的折中。但 LTV MPC 因为在时域内模型本身在变缩短 M 相当于假设后半段输入不变这个假设在模型变化明显时略粗暴。所以如果计算预算允许我倾向于不缩短 M而是先把 N 缩到够用即可。参数取值偏小的影响取值偏大的影响起步参考值采样周期 dt模型失真、约束信息丢失计算开销大主导时间常数 / 10预测时域 N前瞻不足、易失稳计算量大、远端模型失真覆盖 1~2 倍稳定时间控制时域 M控制自由度不足计算量大N 的 1/3 ~ 1/2权重 R控制猛、易抖响应慢、跟踪滞后按输入允许量归一化4. LTV MPC 从公式到代码的完整实现4.1 单步优化与滚动时域的算法主循环不管用什么语言、什么求解器LTV MPC 的主循环结构都是一样的。每个采样周期做这几件事拿到当前状态估计值 x_k状态估计器输出的不是理想状态。截取参考轨迹窗口x_ref[0..N]、u_ref[0..N−1]。对窗口内每个参考点做线性化和离散化得到 A(k)、B(k)必要时计算残差 d(k)。组装 QP 问题决策变量是误差状态序列和控制偏差序列代价函数包含 Q、R、Q_N约束包含模型方程和输入/状态约束。调用求解器求解。6. 取出最优序列的第一个控制偏差 δu(0)计算实际输入并下发执行。等待下一个采样时刻把预测窗口整体向前平移一步重复上述过程。第 7 步就是滚动时域的含义。每次只执行第一步但每步都重新优化。这个反馈机制天然能抵抗一部分模型失配和扰动因为误差每步都会被看到并修正。4.2 Python OSQP 的参考实现下面给一套完整可跑的参考实现用 Python 的 cvxpy 建模、OSQP 求解。对象是差速机器人参考轨迹是圆形匀速运动。import numpy as np import cvxpy as cp # 采样周期与预测时域 dt 0.1 N 25 nx, nu 3, 2 # 状态[x,y,theta]输入[v,omega] # 权重矩阵 Q np.diag([10.0, 10.0, 0.5]) R np.diag([0.1, 0.1]) QN np.diag([50.0, 50.0, 2.0]) # 输入约束 u_min np.array([-0.5, -1.5]) u_max np.array([1.5, 1.5]) def discrete_ltv(x_eq, u_eq): 在参考点 (x_eq, u_eq) 处线性化并欧拉离散化 th x_eq[2] v u_eq[0] A np.array([ [1.0, 0.0, -v * np.sin(th) * dt], [0.0, 1.0, v * np.cos(th) * dt], [0.0, 0.0, 1.0] ]) B np.array([ [np.cos(th) * dt, 0.0], [np.sin(th) * dt, 0.0], [0.0, dt] ]) return A, B def nonlinear_step(x, u): 真实被控对象(仿真用)前向欧拉 return x np.array([ u[0] * np.cos(x[2]), u[0] * np.sin(x[2]), u[1] ]) * dt def mpc_step(x_current, x_ref, u_ref): 求解单步 LTV MPC返回第一个控制偏差 du e cp.Variable((nx, N 1)) du cp.Variable((nu, N)) cost 0.0 cons [e[:, 0] x_current - x_ref[0]] for k in range(N): A, B discrete_ltv(x_ref[k], u_ref[k]) # 预测模型误差状态递推 cons [e[:, k 1] A e[:, k] B du[:, k]] # 实际输入必须落在约束内 u_actual u_ref[k] du[:, k] cons [u_min u_actual, u_actual u_max] # 代价 cost cp.quad_form(e[:, k], Q) cp.quad_form(du[:, k], R) # 终端代价 cost cp.quad_form(e[:, N], QN) prob cp.Problem(cp.Minimize(cost), cons) prob.solve(solvercp.OSQP, warm_startTrue) if prob.status not in (cp.OPTIMAL, cp.OPTIMAL_INACCURATE): print(solver status:, prob.status) return None return du[:, 0].value # 参考轨迹半径2.0的圆角速度0.6 rad/s r, w 2.0, 0.6 T_total 20.0 ts np.arange(0, T_total, dt) x_ref np.array([[r * np.cos(w * t), r * np.sin(w * t), w * t np.pi / 2] for t in ts]) u_ref np.array([[w * r, w] for t in ts]) # 线速度r*w角速度w # 初始状态故意给一个偏移 x np.array([2.5, 0.0, 0.0]) for i in range(len(ts) - N - 1): xr x_ref[i:i N 1] ur u_ref[i:i N] du mpc_step(x, xr, ur) if du is None: print(第, i, 步求解失败) break u ur[0] du x nonlinear_step(x, u) # 这里记录仿真轨迹画图对比即可这套代码的关键点有三个。第一线性化和离散化是在每个参考点上单独做的所以 A、B 序列里包含轨迹的形状信息。第二约束加在总是实际输入上不是加在 du 上。第三OSQP 开了 warm_start连续滚动求解时上一个时刻的解作为下一个时刻的初值收敛速度明显加快。如果参考轨迹不是由模型自身生成的记得在预测方程里补残差项把上面代码里的递推约束改成d nonlinear_step(x_ref[k], u_ref[k]) - x_ref[k 1] cons [e[:, k 1] A e[:, k] B du[:, k] d]这就是前面说的 d(k) 项。补上它跟踪精度才守得住。4.3 求解器为什么选 OSQP以及向嵌入式移植的路径在原型验证阶段我推荐 OSQP原因是它在小规模凸 QP 上收敛快、支持热启动而且接口简单。cvxpy 里的 OSQP 默认参数对绝大多数 MPC 问题够用。如果遇到收敛慢可以调整容差参数 eps_abs、eps_rel 到 1e-5 左右或者限制最大迭代次数换取稳定求解时间。另一个选择是 qpOASES它属于 active-set 方法对中小规模密集 QP 很有优势尤其在 QP 维数不超过几百的时候。ECOS、SCS 是内点法体系鲁棒但偏慢一般用于离线验证而不是在线滚动。到嵌入式落地阶段我会把 cvxpy 拿走直接用求解器原生接口组装 QP。思路是把预测时域固定下来矩阵维度全部静态分配A、B 序列每步只更新数值、不改变稀疏结构。OSQP 的原生接口支持这种只更新数据、不重建立问题的模式速度能比 cvxpy 包装层快一个量级。如果目标平台资源更紧还可以采用 condensing 技术把状态变量消掉只保留控制变量把 QP 规模从 (N1)nx Nnu 压缩到 N*nu。这部分内容展开又是一篇长文但对小状态系统效果立竿见影。5. 实操中的常见问题与排查细节5.1 求解器报不可行不可行是所有 MPC 落地时最先遇到的坎。问题本身不复杂你给出的约束集合和模型预测在某个采样时刻没有交集。常见的触发原因有这么几类。第一参考轨迹本身不满足约束。比如输入约束是 −1.5 到 1.5而参考轨迹要求的角速度是 2.0那无论怎么优化控制序列都会碰壁。检查方法是把参考输入轨迹拉出来逐点对比约束上下限一眼就能看出问题。第二硬的状态约束过于激进。比如要求机器人未来 2 秒内位置误差必须落在 0.01 米以内而当前误差是 0.5 米线性化模型又不可能瞬间把误差拉回来于是不可行。解决办法是软约束或者把约束分段放松。第三终端等式约束。有些人喜欢加 e(N) 0这在理论上能保证稳定但在 LTV 框架下经常因为线性化误差导致不可行。我建议改用终端不等式约束或者干脆只有终端代价。排查不可行问题的顺序我一般这样走先去状态约束试跑只保留输入约束再检查参考输入是否在约束范围内然后取消终端约束看能否可行最后如果还不行检查数值问题比如权重矩阵尺度悬殊、状态变量单位不一致。绝大多数不可行问题在第三、第四步就能定位。5.2 跟踪偏差、末端抖动与控制量毛刺跟踪出现稳态偏差先不要急着调大 Q。按我前面的经验先确认两件事参考轨迹到底满不满足模型残差项 d(k) 有没有补上模型失配是不是系统性原因。如果这两个都不是再考虑把控制系统改成增量式写法或者加一个简单的状态观测器来估计扰动项。末端抖动表现在预测时域后段参考轨迹已经接近目标但控制序列在后半段剧烈摆动。这通常说明终端代价权重太小或者 R 权重过小导致控制增量惩罚不足。我会先加大 Q_N观察曲线是否平滑下来如果还抖再增加 R 或对 Δu 加惩罚。控制量毛刺是另一个常见现象。注意区分真抖和数值噪声真抖通常是权重配比的问题R 太小数值噪声则表现为相邻两个采样周期的控制指令毫无规律地跳动这时优先检查状态估计是否过于敏感比如直接用带噪声的测量值而没有滤波。解决方法对测量做滤波或者把代价函数改成对控制增量 Δu 惩罚都会很有效。5.3 实时性卡顿与计算瓶颈实时性不够先做量化把每次求解时间打印出来看是均值高还是尾部有个别尖峰。普遍问题出现在几个地方。一是求解器容差设得太严。对于 MPC控制精度并不需要解到机器精度。把 eps_abs、eps_rel 放到 1e-4 到 1e-5大多数情况下性能损失完全可以忽略但求解速度能提升好几倍。二是没有热启动。OSQP 的 warm_start 用上一拍的解作为初值在新问题与旧问题相似度高时迭代次数会大幅下降。这在滚动时域里几乎是免费的性能红利务必开启。三是预测时域过长。这个不用多解释决策变量数量直接决定 QP 规模。如果缩 N 之后性能可以接受那就缩。四是 QP 建模层的开销。cvxpy 这类库每次都会重建问题结构对实时性要求高的场合是瓶颈。落到原生接口后单步耗时往往能降低一个量级。5.4 问题症状速查表现象常见原因排查建议求解器返回不可行参考输入超约束范围 / 硬状态约束过紧 / 终端约束太强先去掉状态约束和终端约束逐步加回定位冲突源跟踪有稳态偏差参考不满足模型、d(k) 缺失、模型失配补残差项改用增量式写法控制量高频抖动R 过小、噪声敏感、对 u 而非 Δu 惩罚增大 R、滤波测量值、惩罚 Δu预测末端动作怪异终端代价不足增大 Q_N 或改为 LQR 终端矩阵求解时间波动大容差过严、缺热启动放宽容差、开启 warm_start某个方向响应慢权重相对比例失衡按允许误差归一化重新设 Q、R5.5 关于线性化误差的一个提醒最后单独说一句线性化误差。LTV MPC 的预测模型每步都是近似的误差在预测时域内会累积。预测时域越长误差越大。这就是为什么我前面反复强调别过度拉长 N。在实际项目中我习惯在仿真里故意加 10% 到 20% 的参数扰动跑多组随机场景看控制器是否还能稳定。不要只盯着一条完美曲线就拍板MPC 的鲁棒性测试比精确性测试重要得多。6. 我的调参经验次序与后续扩展6.1 从 LQR 起步的调参流程我把调参这件事拆成四步每一步都验证后再进下一步。第一步先不管约束把 MPC 当成一个有限时域的 LQR 来调。设置一个足够大的 N关掉约束直接用 LQR 的整定思路确定 Q、R 的相对比例观察闭环响应快慢和阻尼。第二步把输入约束加上。这时重点检查控制器在接近约束边界时是否平滑是不是总在边界上摩挲。如果频繁撞边说明 R 偏小控制动作和约束产生了持续冲突。第三步加上状态约束和软约束。这个阶段重点验证可行性尤其是在各种初始状态下求解器都应该返回最优解而不是不可行。第四步处理实时性。仿真没问题之后不断压缩求解时间观察性能折损找到求解时间和控制性能之间的平衡点。这套流程我用了很多次基本没有翻过车。直接一上来就把全套约束、权重、时域一次性配好出问题的时候根本分不清是哪一环节引起的。6.2 从 LTV MPC 再往上的路线LTV MPC 做扎实之后往上走的路径很清晰。如果模型非线性更强线性化误差已经不可接受下一步是 NMPC但要做好求解器和初值管理的准备。如果问题主要出在模型失配和参数漂移可以做自适应 MPC把模型参数在线辨识和 MPC 控制器耦合起来。如果想让 MPC 在极端情况下也能体面降级可以在代价函数里加入安全和性能的多目标处理这也是目前业界落地关注的方向。我个人最推荐的路线是先把 LTV MPC 的每个环节吃透尤其是线性化点选取和残差处理这两处细节。因为这两处是 LTV MPC 区别于教科书线性 MPC 的核心也是实际项目中最容易出问题的地方。把它们弄明白之后无论是往 NMPC 走还是往自适应方向走底子都是通的。做控制这么多年我最深的体会就是算法本身不难难的是知道每一步为什么这么做。LTV MPC 是一个不吃亏的选择值得花时间。