1 Foundations and Concept
1.1 Basic idea of receding horizons
Receding-horizon control optimizes behavior over a finite future window but does not commit to the entire planned sequence. At each control step, it computes an optimal set of future control inputs across a horizon length. The controller then applies only the first portion (often the first control input), advances time by one step, updates the system’s measured state (or an estimate), and repeats the optimization using the newly revealed information. This “look ahead, then replan” mechanism helps the controller adapt to disturbances and modeling errors.
1.2 Relation to MPC and finite-horizon optimization
The term model predictive control (MPC) is commonly used for receding-horizon control in systems where the optimization explicitly uses a dynamical model. In finite-horizon optimization, the goal is to minimize a cost accumulated over a time interval, subject to system dynamics and constraints. Receding-horizon control turns that finite-horizon problem into a feedback strategy by repeatedly solving it as time progresses, effectively converting open-loop plans into a closed-loop policy.
1.3 Closed-loop operation and feedback updates
Because the controller recomputes plans at every time step, it forms a closed-loop behavior: the applied action depends on the current state information. This feedback update can be based directly on sensor measurements or on an estimator’s belief state. The approach typically yields improved robustness compared with methods that generate a fixed sequence offline, since each new measurement corrects the plan for the remaining horizon.
1.4 Prediction model and state estimation assumptions
Receding-horizon control relies on a model to predict future trajectories. The model may be exact, approximate, or deliberately simplified. In practice, controllers often assume that the state used for optimization is sufficiently accurate—either by measuring the required variables or by using an observer (state estimator). The quality of predictions depends on both model fidelity and estimation error; many design choices in later sections aim to manage uncertainty and maintain reliable performance.
2 Mathematical Formulation
2.1 Discrete-time control problem setup
2.1.1 State and input definitions
2.1.1.1 Handling system dynamics (generic form)
A discrete-time receding-horizon controller considers a system whose state evolves according to a dynamical relationship. In a generic form, the next state depends on the current state, the applied input, and possibly exogenous signals such as disturbances or references. Symbolically, one commonly writes \[ x_{k+1} = f(x_k, u_k, w_k), \] where \(x_k\) denotes the state at time step \(k\), \(u_k\) the control input, and \(w_k\) any additional influences. During optimization, \(f\) provides the predicted evolution over the prediction horizon.
2.2 Cost function design
The cost function encodes the control objectives over the horizon. Typical elements include tracking terms (e.g., deviation from a desired reference), effort penalties (e.g., magnitude or smoothness of inputs), and possibly terms that discourage excessive changes in control or states. The cost is evaluated for predicted states and inputs across time steps within the horizon, producing a scalar value to minimize.
2.3 Constraints handling
2.3.1 Hard constraints vs soft constraints
Constraints restrict feasible trajectories. Hard constraints enforce limits strictly by declaring them as non-negotiable during optimization; if violated, the corresponding trajectory is infeasible. Soft constraints relax those limits by allowing violations at a cost, usually using slack variables and additional penalty terms. Softening improves robustness to minor infeasibilities caused by noise, discretization effects, or imperfect models.
2.4 Optimization problem structure
2.4.1 Feasibility considerations and initialization
At runtime, the controller must solve an optimization problem for the current state. Feasibility depends on whether there exists a control sequence that satisfies dynamics and constraints from the present estimate forward. Common practical strategies include initializing with a feasible guess (often from the previous solution), introducing slack variables, or ensuring that the constraint set admits at least one admissible trajectory for the expected state region. Proper initialization reduces runtime failures and improves controller continuity.
3 Control Loop Implementation
3.1 Measuring or estimating the current state
The optimization at time \(k\) starts from a state value. This state may be measured directly or obtained from an estimator that fuses sensor readings with the system model. Estimation uncertainty can be handled implicitly by robust design choices or explicitly by using an augmented state representation; however, the basic control loop still requires a single state estimate to seed the optimization.
3.2 Solving the optimization at each step
Once the current state is known, the controller solves the finite-horizon optimization problem. The solver uses the prediction model, the cost function, and the constraint set to compute an optimal sequence of inputs. For real-time systems, the solution method must be fast enough to complete before the next control update, leading to careful selection of solver algorithms and horizon lengths.
3.3 Applying the control move (“first step only”)
After solving, only the first control action in the optimal sequence is applied to the plant (for example, \(u_k^\*\)). The remaining planned actions are discarded or retained only as a starting guess for the next iteration. This choice prevents the controller from overcommitting to predictions that may become outdated after new measurements arrive.
3.4 Shifting the horizon and updating predictions
At time \(k+1\), the horizon is shifted forward by one step. The controller constructs a new predicted trajectory beginning at the newly estimated state. The previously computed optimal input sequence can be used for warm-starting: the second input from the prior solution becomes a natural initial candidate for the next optimization, often improving convergence speed.
4 System Models and Modeling Choices
4.1 Linear vs nonlinear dynamics
Receding-horizon control can be formulated using linear dynamics or nonlinear models. Linear models often lead to computationally tractable optimization problems, especially when combined with quadratic costs and convex constraints. Nonlinear formulations can capture complex behavior more accurately but generally increase solver difficulty and may require more sophisticated numerical methods. Choosing between them involves a trade-off between modeling accuracy and real-time solvability.
4.2 Reference tracking and setpoint regulation
Two common objective patterns are tracking and regulation. Tracking aims to follow a time-varying reference signal, potentially including constraints on how quickly the system may move or how far it can deviate from desired trajectories. Regulation targets driving the system to a constant setpoint or equilibrium. Both can be expressed within the same optimization framework by adjusting reference terms in the cost function and, if needed, in the constraint specification.
4.3 Disturbance modeling and robustness
Disturbances can be incorporated in multiple ways. A controller may explicitly include disturbance states, treat disturbances as measurable inputs, or assume bounded disturbance sets and design for worst-case behavior (conceptually, “robust MPC”). Alternatively, it may rely on feedback replanning to correct errors as disturbances manifest. The extent of disturbance modeling affects both accuracy and computational load.
4.4 Model mismatch and uncertainty representations
Even with a carefully identified model, mismatch remains. Uncertainty can be represented through bounds, probabilistic assumptions, or scenario-based approximations. Controllers may use conservative constraint tightening, penalties that reduce sensitivity to errors, or estimation mechanisms that reduce the mismatch in the optimized state. The goal is to retain stable and safe behavior despite imperfect predictions.
5 Numerical Methods and Solver Integration
5.1 Convex vs non-convex MPC formulations
The optimization structure determines how reliably and quickly a solver can find a solution. Convex formulations, arising for example from linear dynamics with convex constraints and convex cost terms, typically allow efficient algorithms with strong guarantees about global optimality. Non-convex formulations, often tied to nonlinear dynamics or nonconvex constraints, may require iterative methods that can converge to locally optimal solutions, making robustness and warm-starting more critical.
5.2 Typical algorithm families
5.2.1 Gradient-based methods
Gradient-based approaches use first-order or second-order information to minimize the cost. They are common in continuous optimization settings and can be effective when derivatives are available or can be approximated.
5.2.1.1 Initialization and warm-starting
Warm-starting provides a previous solution or partial solution as an initial iterate for the next optimization. Since the problem changes gradually from one time step to the next (especially due to the shifted horizon), a good initial guess can reduce the number of iterations needed and improve real-time performance.
5.2.2 Active-set and constraint-aware methods
Constraint-aware algorithms handle bounds and other constraints directly, often by maintaining an estimate of which constraints are active at the solution. Active-set strategies can be efficient when the active set changes slowly over time, and they can better exploit structure from constraint types like input bounds and linear inequalities.
5.2.3 Sampling-based approaches (high level)
Sampling-based approaches explore candidate control sequences or uncertain trajectories via randomized or scenario-driven methods. At a high level, they are used when the problem is hard to optimize deterministically, such as under severe nonlinearity or uncertainty. These methods can be computationally expensive, so practical implementations often limit samples or use hybrid strategies.
5.3 Handling infeasibility in practice
Infeasibility can occur when constraints are too tight relative to the current state or when modeling errors lead to impossible demands. Common responses include softening constraints with slack variables, relaxing certain bounds in a controlled way, or using backup control laws for emergency operation. Additionally, controllers can monitor solver outcomes and switch modes when optimization fails persistently.
5.4 Real-time performance considerations
5.4.1 Iteration limits and time budgeting
Real-time systems impose strict deadlines for computation. Implementations often use iteration caps, early stopping criteria, and time-budget policies. If the optimization is not fully solved before the deadline, the controller may apply the best available approximation of the optimal move. The resulting behavior depends on solver quality and the controller’s sensitivity to suboptimal solutions.
6 Constraints and Safety-Oriented Design
6.1 Actuator saturation and rate limits
Actuator saturation constrains the maximum and minimum values of inputs, while rate limits restrict how quickly inputs can change. Both are common in physical systems due to hardware limitations and safety concerns. Encoding them in the optimization prevents the controller from requesting commands that the plant cannot deliver or that could cause excessive stress.
6.2 State bounds and safety envelopes
State constraints restrict variables such as position, velocity, temperature, or other safety-relevant quantities. Safety envelopes can be expressed as bounds on states directly or indirectly through constraints on predicted trajectories. These constraints guide the optimization to remain within safe operating regions across the entire prediction window, not only at the current time.
6.3 Softening constraints with penalties
When strict safety limits cannot be maintained for all circumstances due to disturbances or estimator error, soft constraints offer a compromise. Slack variables allow small violations, while penalties discourage unnecessary or persistent departures from the desired bounds. The penalty weights determine how aggressively the controller avoids violation versus how quickly it recovers when violations occur.
6.4 Constraint prioritization strategies
Not all constraints have equal importance. Constraint prioritization schemes treat some limits as more critical than others, either by assigning higher penalty weights to specific violations, by using hierarchical optimization structures, or by ordering feasibility objectives. Prioritization helps prevent the controller from sacrificing safety-critical requirements to achieve less critical performance goals.
7 Stability, Feasibility, and Performance Guarantees
7.1 Conditions for stability (overview)
Stability analysis for receding-horizon control often depends on properties of the system model, the cost function, and the constraint set. Many results use assumptions like controllability, appropriate choice of terminal ingredients, and certain forms of cost and dynamics regularity. In practice, designers aim to choose settings that support stable closed-loop behavior rather than relying on empirical tuning alone.
7.2 Recursive feasibility concepts
Recursive feasibility means that if the optimization is feasible at one time step, it remains feasible at subsequent steps under the receding-horizon policy. This property can be crucial for avoiding runtime infeasibility as the controller continues to operate. Ensuring recursive feasibility typically involves adding terminal constraints or selecting terminal sets that guarantee the existence of future admissible trajectories.
7.3 Terminal cost and terminal constraints
Terminal ingredients are additional terms applied at the horizon end. A terminal cost shapes the optimization near the end of the horizon by approximating the effect of controlling beyond the computed window. Terminal constraints can restrict the terminal state to lie in a region from which a safe and feasible continuation is possible. Together, these mechanisms often strengthen theoretical guarantees.
7.4 Trade-offs between performance and guarantees
Guarantees usually require conservative design choices, such as longer horizons, carefully designed terminal sets, or stricter constraint handling. Longer horizons can improve performance but increase computational burden. Softer constraints and aggressive cost weights may improve tracking but weaken formal assurances. Effective controller design balances these factors for the intended operating context.
8 Software Engineering for Receding-Horizon Controllers
8.1 Architecture of an MPC module
A typical implementation contains several components: a plant model interface (for prediction), a cost and constraint specification, an optimizer wrapper, an estimator interface for state estimation, and an actuator output interface. The module often exposes configuration options such as horizon length, sampling time, constraint bounds, and solver tolerances.
8.2 Data flow: sensors, estimator, optimizer, actuator
Sensor data feeds the state estimator, producing the state estimate used by the optimizer. The optimizer then solves the finite-horizon problem and returns the current control move. That command is sent to the actuator interface, and the cycle repeats. Because each component introduces latency and uncertainty, system designers frequently account for timing alignment—ensuring that the state estimate corresponds to the correct time instant for applying the optimized input.
8.3 Configuration management for horizons and constraints
Practical systems must manage parameters across environments and builds. Horizon length, sampling time, cost weights, and constraint bounds often require careful versioning. Configuration management supports reproducible behavior across testing, simulation, and deployment, and it reduces the risk of mismatches between model assumptions and constraint definitions.
8.4 Determinism and reproducibility in solver behavior
Optimization solvers may exhibit nondeterminism due to parallel execution, floating-point effects, or stopping criteria. Reproducibility is important for debugging and validation. Engineers often enforce consistent solver settings, fix random seeds when sampling is used, and standardize numerical tolerances to reduce variability between runs.
8.5 Logging, monitoring, and debug tooling
Robust tooling captures solver status, iteration counts, objective values, constraint residuals, and computation times. Logging enables diagnosis of performance regressions, frequent infeasibility events, or numerical instability. Monitoring may include alerts when computation time approaches deadlines or when constraint violations exceed expected levels.
8.6 Interface design between control software and optimizers
A clean interface defines how states, references, constraints, and predicted disturbance data are provided to the optimizer. It also specifies how the solver returns results, including status codes and diagnostic information. Strong interface design supports maintainability and makes it easier to swap solvers or adjust problem formulations without rewriting the entire controller.
9 Testing and Validation
9.1 Unit tests for models and constraint logic
Testing typically begins with verification of model propagation, cost evaluation, and constraint enforcement. Unit tests can check that discrete-time dynamics updates are correct, that constraint bounds are applied as intended, and that slack-variable logic for soft constraints behaves consistently across edge cases.
9.2 Simulation-based verification
Before deployment, controllers are evaluated in simulation with representative models. Simulation allows systematic exploration of operating conditions, including reference changes and varying disturbance profiles. It also provides visibility into internal variables such as predicted trajectories and constraint activity patterns.
9.3 Scenario and edge-case testing
Beyond nominal scenarios, testing targets edge cases such as near-boundary operation, abrupt setpoint changes, sensor dropouts, and rapid actuator saturation. These cases can reveal weaknesses in warm-starting, feasibility handling, and robustness to estimator errors.
9.4 Hardware-in-the-loop considerations
Hardware-in-the-loop testing integrates real computation timing and communication interfaces with simulated plant dynamics. This approach captures real-time constraints and can expose issues that pure simulation misses, such as delays, quantization effects, and mismatches in sampling alignment.
9.5 Metrics: tracking error, constraint violation, computation time
Validation uses quantitative metrics including tracking performance (e.g., root-mean-square error), degree and duration of constraint violation (if soft constraints are enabled), and computation time relative to control deadlines. Together, these metrics provide a balanced view of both control quality and real-time feasibility.
10 Common Use Cases and Variants
10.1 Reference tracking in robotics and automation
Receding-horizon control is used for trajectory tracking in robotic arms, mobile robots, and automated machinery. Constraints naturally represent joint limits, collision-avoidance-related safety margins, velocity bounds, and actuator capabilities. The repeated replanning helps maintain performance when environments or conditions change unexpectedly.
10.2 Vehicle motion planning with control constraints (general)
In vehicle control, receding-horizon optimization can handle kinematic and dynamic constraints and incorporate limits on steering, acceleration, and braking. It can also optimize smoothness and comfort by penalizing aggressive control actions. More generally, MPC-style approaches are valued for their structured constraint handling.
10.3 Economic and multi-objective MPC (conceptual)
Beyond tracking, MPC can optimize broader objectives such as operational efficiency or energy usage. Economic MPC modifies the cost to reflect these goals while still using receding-horizon feedback. Multi-objective variants combine several criteria—performance, smoothness, safety margins, and energy—often using weighted costs or switching policies.
10.4 Learning-augmented MPC (overview)
Learning-augmented MPC integrates data-driven components with the optimization loop. Examples include using learned models for dynamics approximation, learning cost weights, or improving disturbance predictions. The optimization still enforces constraints, while learning can improve prediction accuracy or adaptation in changing environments.
10.5 Distributed or hierarchical receding-horizon schemes
Large-scale systems may use distributed implementations where multiple optimizers coordinate, or hierarchical schemes where a high-level planner provides references and a low-level MPC enforces feasibility and dynamics. These variants aim to manage computational complexity and improve scalability while maintaining constraint-aware control.