State Constraints and Input Constraints

State constraints are limits imposed directly on the system's internal state variables (e.g., position, velocity, temperature, concentration). They define the safe or permissible region of operation.

• Purpose: Ensure safety and operational limits (e.g., a robot's joint angles, a chemical reactor's temperature, a vehicle's position within a lane).
• Formulation: Typically expressed as $g(x_k) \leq 0$ for predicted states $x_k$ across the horizon.
• Example: A drone's altitude must remain between 5m and 100m: $5 \leq h_k \leq 100$.

Input constraints (or control constraints) are limits on the manipulated variables or actuator commands (e.g., motor torque, valve position, thrust). They represent physical actuator saturation.

• Purpose: Model the physical limits of actuators to prevent damage and ensure feasibility (e.g., maximum steering angle, pump flow rate limits).
• Formulation: Typically expressed as $h(u_k) \leq 0$ for control inputs $u_k$.
• Example: A motor's torque cannot exceed 10 Nm: $-10 \leq \tau_k \leq 10$.

This classification defines how strictly a constraint must be enforced.

• Hard Constraints: Must never be violated. They represent absolute physical or safety limits (e.g., a valve cannot be more than 100% open). Infeasibility of the optimization occurs if no solution satisfies all hard constraints.
• Soft Constraints: Are allowed to be violated at a penalty. They represent desirable operating regions rather than absolute limits (e.g., a preferred temperature range). Implemented using slack variables added to the cost function, which are penalized when the constraint is active.

A core challenge in MPC is ensuring the online optimization problem remains feasible—that a control sequence exists which satisfies all constraints.

• Recursive Feasibility: A property guaranteeing that if an optimization problem is feasible at time $t$, it will remain feasible at $t+1$. This is often ensured through careful design of terminal constraints.
• Feasibility Recovery: Strategies like constraint softening or hierarchical constraint relaxation are used when the problem becomes infeasible due to large disturbances, prioritizing critical safety constraints.

A terminal constraint requires the predicted state at the end of the horizon, $x_{N}$, to lie within a terminal set $\mathbb{X}_f$. This is a key theoretical tool for guaranteeing closed-loop stability.

• Purpose: Forces the finite-horizon MPC problem to behave like an infinite-horizon optimal controller, ensuring stability.
• Common Design: The terminal set is often chosen as a control invariant set associated with a local stabilizing controller (e.g., a Linear Quadratic Regulator).
• Practical Note: While critical for stability proofs, strict terminal constraints can be restrictive; they are often combined with a terminal cost.

In Robust MPC, constraints are proactively tightened to ensure they will be satisfied for all possible realizations of bounded uncertainty or disturbance.

• Mechanism: The original constraint set $\mathbb{X}$ is shrunk to a smaller, robustly positive invariant tube $\mathbb{X} \ominus \mathbb{E}$, where $\mathbb{E}$ bounds the possible state error due to disturbances.
• Result: The controller plans within this smaller, safer region, guaranteeing that the actual system, subject to disturbances, will never violate the original constraints.
• Trade-off: Increased robustness comes at the cost of reduced nominal performance (a smaller feasible region).

Constraint handling is the methodology for enforcing limits within an MPC optimization. Hard constraints are absolute physical limits (e.g., maximum joint angle, actuator saturation) that must never be violated. Soft constraints are desirable limits (e.g., staying near a path) that can be breached at a penalty, often implemented using slack variables to ensure the optimization problem remains feasible even when conflicts arise.

The Optimal Control Problem (OCP) is the core mathematical formulation solved at each MPC step. It is defined by three components:

• A dynamic model predicting state evolution.
• A cost function to minimize (e.g., tracking error, energy).
• A set of constraints on states and inputs. State and input constraints are explicitly encoded as inequality equations within this OCP, making MPC a constrained optimal control strategy.

A Control Barrier Function (CBF) is a mathematical tool used to formally guarantee safety by defining a forward-invariant safe set. In relation to MPC constraints:

• CBFs can be used as a safety filter, overriding or modifying MPC inputs to ensure constraint satisfaction.
• They can be integrated directly into the MPC OCP as additional safety constraints, creating a unified CBF-MPC framework that combines optimality with rigorous safety certificates.

Robust MPC extends standard MPC to handle model uncertainty and disturbances while guaranteeing constraint satisfaction. It treats state and input constraints conservatively:

• Constraint tightening: Feasible regions are shrunk to create a buffer against worst-case disturbances.
• Tube-based MPC: The controller maintains the predicted state within a bounded "tube" around a nominal trajectory, ensuring the real system stays within constraints despite noise. This makes constraints robust to real-world imperfections.

Chance constraints are a probabilistic method for handling uncertainty within Stochastic MPC. Instead of enforcing constraints strictly (like hard constraints) or for worst-case scenarios (like robust MPC), they require constraints to be satisfied with a specified probability (e.g., 95%).

• Example: "The robot must stay within its lane with 99% probability."
• This approach is less conservative than robust MPC but requires knowledge of the disturbance distribution, providing a balance between performance and risk.

Feasibility refers to the existence of at least one sequence of future control inputs that satisfies all system dynamics, state constraints, and input constraints over the prediction horizon. It is a fundamental requirement for the MPC optimization problem to have a solution.

• Infeasibility occurs when constraints are too tight or conflicting, causing the solver to fail.
• Recursive feasibility is a key property in MPC design, ensuring that if the problem is feasible at the initial time, it remains feasible at all future times, which is crucial for closed-loop stability.