This is an old revision of the document!
Table of Contents
Planning and Control in the AV Stack
Planning and control are the parts of an autonomous system where perception turns into action. A vehicle does not become autonomous simply by detecting objects or building a map of the world. It must also decide what to do next, determine how that decision can be executed safely, and then convert the planned motion into actuator commands. In other words, this chapter sits in the middle of the autonomy loop: it connects the understanding of the environment to the physical behavior of the vehicle.
The closed-loop chain can be viewed as follows:
- perception and localisation estimate the state of the vehicle and its surroundings;
- prediction estimates how other agents may move;
- decision-making selects the intended maneuver or behavior;
- motion planning generates a feasible path or trajectory;
- control tracks the trajectory through steering, braking, throttle, thrust, or other actuators;
- monitoring and fallback functions supervise execution and trigger replanning or a safe state when needed.
This chain is important because no single layer is sufficient on its own. A motion planner can produce a good trajectory in isolation, but the same plan may become unsafe if perception is delayed, prediction is wrong, localisation drifts, or the controller cannot physically track the path. A controller may behave correctly on a clean reference trajectory, but still create unsafe behavior if the planner issues abrupt commands or if the vehicle state changes faster than the controller can respond. For that reason, planning and control must be treated as a system-level function, not only as a set of individual algorithms.
The role of each layer
| Layer | Main role | Typical input | Typical output | Main validation question |
|---|---|---|---|---|
| Decision-making | Chooses the maneuver or behavior | Goals, scene context, traffic rules, mission state | Stop, yield, follow, overtake, lane change, reroute | Is the chosen behavior correct and rule-compliant? |
| Motion planning | Converts intent into a path or trajectory | Behavioral decision, map, obstacles, vehicle constraints | Safe and feasible trajectory | Can the vehicle execute this path safely and legally? |
| Control | Tracks the planned trajectory | Trajectory, vehicle state, actuator feedback | Steering, braking, throttle, thrust commands | Can the vehicle follow the plan within dynamics and timing limits? |
| Monitoring / fallback | Detects unsafe or degraded execution | Residuals, health signals, timing, confidence metrics | Replanning, slowdown, minimal-risk maneuver, safe stop | Does the system recover safely when things go wrong? |
This structure is useful because it keeps the chapter focused on the system function rather than on one algorithm family only. In an autonomous vehicle, the interesting question is not merely whether a controller works, but whether the complete decision–planning–control chain behaves safely and predictably in the intended Operational Design Domain (ODD).
Why this layer is different from the rest of the stack
Compared with perception and localisation, this chapter deals more directly with action selection and vehicle motion. That makes the safety implications more immediate. A perception error may be serious, but a planning or control error can immediately turn into unsafe motion. This is why planning and control usually require tight timing, careful supervision, and explicit fallback behavior.
At the same time, this layer is also more tightly coupled to vehicle dynamics than higher-level software. The planner cannot ignore turning radius, braking distance, acceleration limits, road friction, actuator delay, or comfort constraints. A behavior module cannot ignore traffic rules, interaction with other agents, or the fact that some maneuvers are safe only in certain conditions. Planning and control therefore sit at the intersection of:
- system intent,
- physical feasibility,
- real-time execution,
- and safety assurance.
Domain differences
The same functional chain exists in all autonomy domains, but the emphasis changes with the physical environment.
| Domain | Main emphasis | Typical planning and control style |
|---|---|---|
| Ground systems | Human interaction, road rules, friction-limited dynamics, low-latency reaction | reactive planning, trajectory tracking, stop/yield behavior, comfort-aware control |
| Airborne systems | Stability, altitude, airspace rules, weather, safety margins | layered control, outer-loop guidance, strict envelope protection |
| Marine systems | Disturbances from waves, currents, wind, sparse infrastructure, long duration | robust control, waypoint navigation, energy-aware mission planning |
| Space systems | Communication delays, orbital mechanics, limited actuation, no real-time human intervention | model-based control, mission planning, trajectory optimization under physical constraints |
Ground vehicles must handle dense interaction with pedestrians, cyclists, lane markings, signals, and other vehicles. Airborne systems face a three-dimensional environment where stability and safety margins dominate. Marine systems operate more slowly, but disturbances and sparse sensing make robustness essential. Space systems are the most constrained of all: decisions are often conservative, highly validated, and based on first-principles dynamics because real-time intervention is limited or impossible.
This is why the chapter cannot treat control and planning as a single universal recipe. The underlying logic is shared, but the validation target changes depending on the domain, the vehicle dynamics, the available sensors, and the consequences of failure.
What this chapter delivers
The purpose of this chapter is to show how autonomous behavior is produced and how it can be validated as a system. The reader should be able to follow the chain from a high-level behavior down to the executed motion:
1. define the maneuver or mission objective; 2. determine how the behavior is represented in the autonomy stack; 3. generate a trajectory or control action that respects constraints; 4. execute the motion through the vehicle dynamics; 5. supervise the result and trigger replanning or fallback if needed.
This chapter therefore acts as the bridge between understanding the environment and proving that the vehicle can act safely inside it. It prepares the reader for the next sections, where the main control strategies, planning architectures, and validation methods are discussed in more detail.
