Note Wisdom
These annotated notes break down Stanford AA203 Lecture 12 on MPC feasibility, explaining key theorems, proof logic, control invariant terminal sets, and the practical tradeoffs between guaranteed feasibility and control performance.
Institution: Stanford
Original Course: Stanford AA203 Optimal and Learning-Based Control | Spring 2026 | Lecture 12: Feasibility of MPC
Instructor Bio: Taught by Prof. Marco Pavone and Dr. Daniele Gammelli, with deep theoretical contributions to MPC stability and feasibility research.
Course Description: This lecture dives into MPC feasibility and stability theory. It covers recursive feasibility conditions, terminal constraint design, and formal stability guarantees, and introduces efficient implementations such as explicit MPC.
This is the 12th lecture in Stanford’s AA203 course, continuing directly from the last one on MPC feasibility. The roadmap for the day: finish persistent feasibility, move into stability, cover offline vs online optimization, and then extend MPC to trajectory tracking. The lecturer mentioned that industry practitioners sometimes get the trajectory tracking formulation wrong, so that part is meant to prevent a common mistake. The available transcript, though, focuses mostly on the math behind persistent feasibility, with a short detour into terminal constraint design.
Setup is linear time-invariant systems with polyhedral state and control constraints. Last time introduced a bunch of set concepts: one-step controllable sets, control invariant sets, positive invariant sets, feasibility sets. The one that matters most here is X₁ — the truncated one-step feasibility set. It's all states where there exists a feasible control that lands you in a valid state one step ahead.
This isn't purely theoretical. Ten years ago, solvers and onboard hardware were slow enough that precomputing these sets offline was a standard way to cut online computation and reduce delay. That context helps explain why this theory mattered for real MPC deployment.
The lecturer also noted that at least one final exam question will test understanding of these set definitions.
The first result: if X₁ is control invariant, then the MPC control law is persistently feasible. Meaning at every time step in closed loop, the optimization problem has at least one valid solution. You never hit a point where the solver can't find a control that satisfies all constraints.
The proof is mostly pattern matching with definitions. You show X₁ is a subset of both the state constraint set X and the predecessor set of X₁ itself. Then connect to the full-horizon feasibility set X₀: any state that can reach X₁ in one step is also a valid starting point for the full MPC problem. Apply recursively across time steps.
The subscript notation is easy to mix up. X₁ is the truncated one-step feasibility set, not the first state in a trajectory. The lecturer explicitly warned about this, and it's worth keeping straight when the proof jumps between X₀, X₁, and predecessor sets.
This lemma by itself isn't directly useful for tuning MPC. It's a stepping stone to a more general result.
The lemma only covers a prediction horizon of 1, which is almost never the case in practice. The main theorem generalizes it to any horizon length M.
The statement: if the terminal set Xբ — the set you constrain the final state to lie in — is control invariant, then the entire MPC problem is persistently feasible.
The proof works backwards from the terminal condition. If Xբ is control invariant, then the set of states that can reach Xբ in N−1 steps is also control invariant. Keep applying this logic step by step back to X₁, then invoke the earlier lemma.
The intuition: if you know you can stay inside the terminal set once you get there, then every earlier step also has a valid path forward. Feasibility propagates backwards through the horizon.
The simplest control invariant terminal set is the origin. If zero control is allowed, sitting at the origin and doing nothing keeps you there forever. So forcing the MPC problem to end at the origin guarantees persistent feasibility.
The catch: forcing the system to reach the origin by the end of the horizon is very restrictive. It eliminates a huge number of possible control sequences, and the remaining ones often require more control effort. You get the feasibility guarantee, but you might be controlling suboptimally — wasting energy or actuating harder than necessary.
Terminal constraints are a tuning knob, not a fundamental part of MPC. You add them to get the guarantee, but you want them as relaxed as possible so they don't unnecessarily constrain the optimization.
There are much larger control invariant sets than just the origin. Later in the course they'll cover computational tools to calculate them, and problem set 3 will give practice with those tools. The bigger the terminal set you can use while keeping it control invariant, the better the performance while still keeping the guarantee.
This theory only applies cleanly to linear time-invariant systems with polyhedral constraints. All the set operations rely on linear dynamics and polyhedral constraints. For nonlinear systems or non-polyhedral constraints, these guarantees don't hold the same way, and the lecturer didn't address how to adapt the ideas.
There also wasn't a concrete example of what a control invariant set actually looks like for a simple physical system — a pendulum, a mobile robot. The computational tools come later, so for now the theory feels somewhat disconnected from actual MPC tuning.
It's also worth remembering this is only a sufficient condition. A persistently feasible MPC system doesn't require a control invariant terminal set. This theorem gives a reliable, provable way to design for feasibility if you want that guarantee.
By the end of this section, the core point is clear: feasibility of MPC depends on how you design the terminal constraint, and there's a direct tradeoff between the strength of the feasibility guarantee and control performance. Control invariant sets and backwards induction give a way to prove persistent feasibility, but picking a terminal set that balances reliability and efficiency is up to the designer. The rest of the lecture — stability, offline computation, trajectory tracking — falls outside the available transcript.
Content Disclaimer: This article is for general reference only and does not constitute professional R&D guidance, production process advice or quality certification. All material performance data has specific test premises; readers should verify parameters against actual equipment and working conditions.
All contents below are exclusive to the paid Word file, NOT available on this web page

