USE CASE

Plan the next move — with the limits built in.

Most controllers react to the present. Model Predictive Control plans: at every step it solves an optimization over a horizon of future moves, picks the best one that respects every constraint, applies it, and re-plans. That's what lets it do the thing simpler controllers can't — honor hard limits on inputs and states, exactly, without the overshoot you get from just clipping a controller that didn't know the limit was there. This program builds MPC from the LQR baseline up through constrained, offset-free control on a real plant.

A constrained MPC settling with no overshoot while a saturating LQR overshoots, with the input held inside its limit band
0
input-constraint violations
1.29
extra overshoot from a saturating LQR
2e-8
unconstrained MPC vs LQR (the anchor)
1.5e-4
offset-free tracking error under load
10
design notebooks
5 / 5
requirements PASS
THE ANCHOR

First, prove it reduces to what you trust.

Before claiming MPC does anything special, the program proves it does nothing wrong: with no constraints and a long horizon plus the right terminal cost, MPC reproduces the optimal LQR controller to 2×10⁻⁸. That equivalence is the correctness anchor — it means the MPC machinery is exactly the LQR you already trust, plus the ability to add constraints. Everything interesting comes from those constraints.

An LQR controller regulating a state to zero — the optimal unconstrained baseline
The baseline: an LQR regulates the plant to its setpoint optimally — when nothing is in the way. It's the right answer to the unconstrained problem, and the controller MPC must reproduce before it earns the right to do more.
Constrained MPC settling without overshoot while a saturating LQR overshoots, the input held inside its band
The hero: with a hard input limit, an aggressive LQR commands more than the actuator can deliver — it saturates and overshoots by 1.29. Constrained MPC plans around the limit: it respects the band exactly (0 violations), doesn't overshoot, and still settles faster. Planning beats clipping.
STATE LIMITS

Some limits aren't on the actuator — they're on the system.

Input limits are one thing; the harder constraints are on the states themselves — a velocity that mustn't be exceeded, a temperature that mustn't be crossed. Because MPC predicts the trajectory, it can keep a state inside its bound by acting before the bound is reached. Where the LQR blows through a velocity cap to 4.18, the constrained MPC rides exactly along the 3.0 limit and recovers — the constraint becomes part of the plan, not a wall hit after the fact.

MPC holding a velocity exactly at its limit while an LQR blows through it
A state constraint: the LQR velocity blows through the −3 cap to −4.18 because it never knew the limit existed; the constrained MPC rides along the cap and recovers. Predicting the trajectory is what lets you respect a limit on the state, not just the input.
REAL PLANTS

Track a setpoint with no offset — and a building to prove it.

A constant load pushes a naive controller off its setpoint forever. Add an input-disturbance estimator and MPC becomes offset-free: it infers the load and cancels it, holding the reference to 1.5×10⁻⁴ where the naive version sits at 0.06. The program lands the whole stack on a real first-order HVAC thermal zone — a bounded heater tracking a stepping comfort schedule, holding the room in its comfort band 98% of the time.

Offset-free MPC rejecting a load disturbance by estimating and cancelling it
Offset-free tracking: an input-disturbance estimator infers the load (its estimate converging to the true 0.6) and cancels it, so the output holds its reference where a naive MPC would settle with a standing error. Estimation and control, working together.
An MPC-controlled HVAC zone tracking a comfort-temperature schedule inside its band
A real plant: a first-order RC building-thermal zone under MPC, the bounded heater tracking a stepping comfort schedule and holding the room inside its comfort band 98% of the time. The constrained-optimal-control story on something you'd actually deploy.
VALIDATION

Every number re-derived at sign-off.

The V&V notebook rebuilds each controller from scratch and re-derives the requirements, printing a PASS/FAIL board.

ResultRequirement
Unconstrained MPC = LQR2e-8R-01 < 1e-3
Input constraint violation0R-02 ≤ 0
Saturated-LQR extra overshoot1.29R-03 > 0
State (velocity) cap held0.0003R-04 ≤ 0.05
Offset-free tracking under load1.5e-4R-05 < 1e-2
HONEST SCOPE

Linear MPC, soft state constraints, dense QP.

The deliverable is ten notebooks and the dossier — MPC is optimization-in-the-loop on a (linearized) plant, not an acausal network, so there's no custom block or canvas. State and output constraints are enforced as soft penalties rather than hard polytopic constraints, and the QP is solved densely via Optim rather than an embedded sparse QP solver (the production path is noted). The plants are linear or linearized, and there's no real-time/embedded codegen here — that's the autopilot→Rust path this would feed. What the program delivers is the full constrained-optimal-control story — LQR anchor, input and state constraints, offset-free tracking, a real HVAC plant, tuning, robustness and move-blocking — every number re-runnable, closing the optimizer-in-the-loop gap the microgrid flagship named.

Put an optimizer in your own control loop.

Book a walkthrough and we'll set up your plant, your constraints and your horizon, and run the constrained-control and tuning studies live.

DjiniousLabOne engineering notebook for model-based design — model, simulate, and generate on a living digital replica.