Model Predictive Control (MPC) predicts what a present command will do over coming steps, selects a sequence of commands that best balances tracking and effort while satisfying constraints, applies only the first command, then measures and solves again. This receding-horizon loop is valuable when inputs have limits, state variables have safety bounds, inputs interact, or future curvature and delay matter. It is used from process plants to vehicles, robot motion, and energy systems.
MPC is not a universal replacement for PID. A predictive optimizer with a late state estimate, a wrong model, an infeasible problem, or a missed deadline does not become safe because its mathematical constraints look complete. Many sound architectures retain fast PID current/velocity loops underneath MPC for path, energy, thermal, or multivariable coordination. Read ROS 2 Primer for the execution boundary and Visual SLAM Primer for the timing and localization assumptions that feed a mobile-robot controller.
The practical conclusion
- Put input, input-rate, state, and safety constraints into the optimization rather than clipping an unconstrained command afterward.
- Specify what happens when the solver is late, numerical, or infeasible before deploying. Deadline, fallback, and independent stop behavior are parts of the controller.
- Start with the smallest model that predicts the relevant time scale. A larger model can worsen runtime, identification error, and maintenance without improving decisions.
- Tune horizon and weights from explicit operational priorities: safety margin, tracking, energy, wear, comfort, and computation—not by blindly raising a tracking weight.
Intuition: decide to brake before the curve
A simple feedback controller can turn a vehicle after it sees lateral error. MPC can consider the curve ahead, speed, steering range, tire limits, acceleration, and obstacle clearance together. It evaluates candidate steering and acceleration sequences, chooses one that remains within the feasible region, executes the first move only, then discards the old prediction when a new measurement arrives. MPC is therefore not a fortune teller. It is feedback control that repeatedly tests short-lived hypotheses about the future.
Signal flow and the receding horizon
Diagram: Duskcoil, conceptual rather than measured. A predicted trajectory is a model-based candidate, and must be updated by observation after an action is applied.
A minimal linear MPC formulation
For the discrete linear model
x is state, u input, w disturbance and y output. Across a prediction horizon N, a common quadratic cost is
where \Delta u_k=u_k-u_{k-1}. Q expresses the importance of state tracking; R penalizes command magnitude; S penalizes abrupt change; P is a terminal weight. These are engineering priorities in mathematical form. Penalizing lateral error alone, for example, can produce violent steering that is unacceptable for passengers, tires, or an actuator.
The essential difference from an unconstrained regulator is the explicit feasible set:
The bounds can represent steering, current, temperature, joint angle, battery state, pressure, or obstacle clearance. Constraints can conflict. Keep an inviolable collision or hardware limit hard; use a nonnegative slack \epsilon only for deliberately relaxable constraints, and penalize it, e.g. \rho\lVert\epsilon\rVert^2. Record when slack was used: a soft constraint is a declared compromise, not proof that the violation is harmless.
Estimation, delay, and model mismatch
MPC predicts from x_k, but x_k is normally a sensor-fusion estimate. For a mobile robot using visual SLAM, localization latency, relocalization jumps, and inconsistent frames corrupt the initial state of every optimization; see Visual SLAM Primer. Solving a perfect problem with an old state and a new reference gives a physically late command.
Mismatch includes friction, payload, wind, tire slip, changing thermal capacity, and unmodeled flex. Responses include disturbance-state augmentation or integral action, online parameter updates, multiple models, robust/tube MPC margins, and a fast stabilized inner loop. None replaces independent stopping behavior when the mismatch is outside the design envelope.
Tuning horizon and weights
Choose sample time T_s and horizon N so NT_s covers the relevant delay, stopping distance, dominant transient, and route curvature—but not so far that runtime and far-future model error dominate. A shorter control horizon can hold later inputs constant and reduce decision variables.
Tune in this order: fix units and hard safety bounds; choose tracking weights Q for the operational task; raise R and S to manage energy, wear and smoothness; then measure worst-case solver time and infeasibility under noise, load, latency and disturbance. Raising Q until the system “looks fast” often asks the optimizer to spend inputs that are unavailable or unsafe.
| Observation | Plausible cause | Inspect first | Typical action |
|---|---|---|---|
| Late in a curve | horizon too short; state delay | predicted vs. measured path, timestamps | adjust horizon, speed plan, delay handling |
| Jagged commands | low S; noisy estimate | \Delta u and sensor trace | increase move penalty; improve estimator/filter |
| Frequent slack/limits | mismatch; no margin | slack, active constraints, disturbance | add margin, disturbance model, gentler reference |
| No solution | conflicting constraints | solver status and active set | define infeasible policy; soften only allowed bounds |
| Deadline misses | problem too large/variable | worst-case solve time | reduce model/horizon; configure solver |
Relationship to PID and safety
An MPC loop might run at 10–100 Hz to issue velocity, attitude, or trajectory references, while motor drivers or ros2_control PID loops close current, velocity, or position at a higher rate. The MPC must know what the inner loop can actually deliver: saturation, delay, timeout, and tracking limits. If the optimizer is late or infeasible, the lower loop needs a defined safe reference such as zero speed, controlled deceleration, or hold.
Safety protections must remain independent from the optimizer: emergency stop, collision detection, hard travel limits, overcurrent/overtemperature protection, velocity monitoring, and communication watchdogs. Define a response for a missing solve, a numerical error, stale state, invalid reference, and an estimator fault. Feasibility in the optimization model is not the same thing as real-world safety.
Current software, products, and research examples
MPC has moved from continuous process industries into vehicles, robotics, and energy management. A deployed implementation includes a solver, model identification, state estimation, monitoring, and deadline management—not only a cost function. OSQP publishes an open-source convex quadratic-programming solver and MPC-oriented material. MathWorks’ MPC overview describes the prediction, constraint, and repeated-optimization structure. They are primary implementation references, not product endorsements.
On the robotics side, ros2_control manages hardware interfaces, controller lifecycles, asynchronous update concerns, and controller chaining. Putting an MPC node into ROS 2 does not by itself establish real-time scheduling, state/reference timestamp alignment, or a safe independent lower loop. Current research includes nonlinear MPC, learned dynamics, distributionally robust MPC, and joint perception–planning optimization; runtime, explainability, uncertainty, and safety assurance remain practical limits.
Implementation checklist
- Define units, frames, update rates, latency, and freshness for state, input, disturbance, and reference.
- Separate hard physical constraints from deliberately soft operational ones.
- Test worst-case solve time, timeout, infeasibility, and numeric-failure fallback.
- Log predictions, measurements, input sequence, active constraints, slack, and solver status on one clock.
- Inject mismatch, disturbance, slip, sensor delay/loss, and communication loss.
- Ensure the MPC understands inner-loop saturation and that independent stop protection works if MPC, ROS 2, or estimation fails.