Constraint Handling (Hard and Soft Constraints)

Hard constraints are absolute physical or safety limits that must never be violated under any circumstance. They define the fundamental operating envelope of the system.

• Examples: Actuator saturation limits (e.g., maximum steering angle), collision avoidance boundaries, or minimum/mimumum tank levels.
• Implementation: Enforced as strict inequalities (e.g., x ≤ x_max) within the optimization problem. If no feasible solution exists that satisfies all hard constraints, the optimization fails, potentially causing system shutdown.

Soft constraints represent desirable operational limits that are allowed to be violated at a quantifiable cost. This ensures the optimization problem remains feasible.

• Examples: Preferred velocity range, ideal temperature band, or target zone for a robotic arm.
• Implementation: Typically enforced using slack variables (ε) added to the constraint (e.g., x ≤ x_max + ε). A penalty term (e.g., ρ * ε²) is added to the cost function, where ρ is a tuning weight. The optimizer will violate the constraint only if the benefit outweighs the penalty.

Slack variables are auxiliary, non-negative decision variables introduced to convert hard constraints into soft constraints, thereby guaranteeing feasibility.

• Mechanism: A constraint g(x) ≤ 0 is relaxed to g(x) ≤ ε, where ε ≥ 0. The term ρε or ρε² is added to the objective function.
• Purpose: They act as a "safety valve," allowing the controller to temporarily breach a zone (like a soft speed limit) to handle disturbances or conflicting objectives, rather than failing entirely.

Constraint tightening is a robust MPC technique where hard constraints are deliberately made more conservative offline to account for bounded model uncertainty or disturbances, ensuring the real system never violates its true limits.

• Process: The feasible region is shrunk by a "tube" margin. If the nominal predicted state satisfies the tightened constraint, the actual state is guaranteed to satisfy the original constraint.
• Use Case: Critical for safety in applications like autonomous vehicle platooning or chemical process control, where uncertainty must not lead to constraint violation.

A central trade-off in constraint handling is between feasibility (finding any solution that satisfies constraints) and optimality (finding the best solution).

• Infeasibility: Occurs when hard constraints conflict, leaving no solution. This is a critical failure mode.
• The Role of Softening: By softening lower-priority constraints, feasibility is restored. The optimizer then finds the best solution among feasible ones, which may involve minimally violating soft constraints to satisfy higher-priority goals.

Constraints are categorized by the system variable they limit, each with distinct implications.

• State Constraints: Limits on internal states (e.g., robot joint position, chemical concentration). Often critical for safety.
• Input (Control) Constraints: Limits on actuator commands (e.g., motor torque, valve position). These are typically hard due to physical saturation.
• Output Constraints: Limits on measured outputs. These can be challenging as they must be enforced indirectly via the model prediction.

A hard constraint enforces the vehicle's steering angle to remain within the mechanical limits of the steering rack (e.g., ±30 degrees). Violation is physically impossible. A soft constraint encourages the vehicle to stay centered in its lane. The optimizer may allow a temporary, small breach of this lane-centering constraint to avoid a sudden jerk in steering, penalizing the deviation in the cost function instead.

Hard constraints are applied to the joint torques, ensuring they never exceed the maximum ratings of the motors, which would cause overheating or damage. Soft constraints are used for the desired end-effector path. The optimizer may allow the arm to slightly deviate from the ideal Cartesian path to find a sequence of joint angles that satisfies all torque limits, penalizing the path error to keep it minimal.

A hard constraint is placed on the maximum reactor temperature to prevent a runaway exothermic reaction or catalyst degradation. This limit must never be violated. Soft constraints define an optimal operating temperature range for yield. The controller may allow the temperature to drift slightly above this range if necessary to respect the hard maximum, incurring a cost for reduced efficiency but ensuring absolute safety.

A hard constraint mandates that the battery's state-of-charge (SoC) must remain above 15% at all times to prevent deep discharge and permanent cell damage. A soft constraint encourages the SoC to stay above 30% to preserve battery health for long-term use. The flight controller might dip below 30% to complete a critical mission segment, penalizing the low SoC in its plan, but will always initiate a mandatory landing before hitting the 15% hard limit.

Soft constraints are typically implemented using slack variables. These are additional, non-negative optimization variables that quantify the magnitude of a constraint violation.

• The slack variable is added to the constraint, effectively relaxing it.
• A penalty term, weighted by a tuning parameter, is added to the cost function.
• This ensures the optimization problem remains feasible; if a hard constraint makes the ideal solution impossible, the optimizer can 'pay a price' via slack to find the next-best, physically possible solution.

The core trade-off in constraint handling is between feasibility (finding any solution that satisfies all hard constraints) and optimality (finding the best-performing solution).

• Hard constraints-only: Guarantees safety but can lead to infeasibility where no control sequence exists that satisfies all limits, causing the optimizer to fail.
• Soft constraints: Ensure feasibility by allowing controlled violations of less-critical limits, guaranteeing the controller always has a 'fallback' solution, even if sub-optimal. The penalty weight determines how strictly the soft constraint is enforced.

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

• A dynamic model (e.g., state-space equations) predicting future system behavior.
• A cost function to be minimized (e.g., tracking error, control effort).
• A set of constraints on states, inputs, and outputs over the prediction horizon. Hard and soft constraints are explicitly defined within this OCP framework. The solver's ability to find a feasible solution depends entirely on how these constraints are formulated and handled.

Slack variables are auxiliary, non-negative decision variables added to an optimization problem to transform hard constraints into soft constraints. In MPC:

• They are added to constraint equations (e.g., state <= limit + slack).
• A penalty term weighted by a tuning parameter is added to the cost function to penalize any non-zero slack.
• This mechanism ensures the optimization problem remains feasible even when constraints cannot be strictly satisfied, allowing the controller to prioritize which limits are most critical to honor. The magnitude of the slack indicates the severity of the constraint violation.

Feasibility refers to the existence of at least one sequence of control inputs that satisfies all the system's dynamic equations and hard constraints over the prediction horizon. It is a fundamental requirement for the MPC optimization problem. Infeasibility causes the solver to fail. Strategies to ensure feasibility include:

• Careful constraint design and horizon selection.
• Using soft constraints with slack variables.
• Implementing constraint softening or relaxation techniques.
• Employing robust MPC methods that account for uncertainty in advance.

A Control Barrier Function (CBF) is a mathematical tool used to enforce safety constraints by defining a forward-invariant safe set. While not part of core MPC, it is a powerful complementary and sometimes integrated approach:

• A CBF defines a safety boundary; control actions must keep the system state within this boundary.
• It can be used as a safety filter applied to the inputs generated by an MPC or other controller, overriding them only if necessary to avoid constraint violation.
• Recent research explores embedding CBF conditions as constraints within the MPC OCP itself, creating a unified predictive safety framework that is less conservative than pure worst-case robust MPC.

Chance constraints are probabilistic constraints used primarily in Stochastic MPC. Instead of requiring constraints to hold always (hard) or with a penalty (soft), they require satisfaction with a specified probability (e.g., P(state <= limit) >= 0.95).

• They explicitly account for uncertainty in disturbances or model parameters.
• They are less conservative than robust MPC approaches, which plan for the worst-case scenario, leading to better average performance.
• Implementing chance constraints typically involves reformulating them into deterministic, tractable constraints that can be handled by standard convex solvers, often relying on distributional assumptions.

Robust MPC is a class of strategies designed to guarantee constraint satisfaction and stability despite bounded model uncertainty, disturbances, or noise. It handles uncertainty differently from soft constraints or chance constraints:

• It uses a tube-based approach, where a nominal trajectory is computed, and constraints are tightened to ensure the actual, uncertain state remains within a bounded 'tube' around it.
• It employs min-max optimization, where the controller plans for the worst-case realization of uncertainty within a defined set.
• This method provides deterministic, worst-case guarantees but can be computationally intensive and may lead to conservative control actions compared to stochastic or soft-constraint methods.