| Both sides previous revisionPrevious revision | |
| en:safeav:ctrl [2026/04/24 09:25] – raivo.sell | en:safeav:ctrl [2026/06/02 22:15] (current) – momala |
|---|
| ====== Control, Planning, and Decision-Making ====== | ====== Control, Planning, and Decision-Making ====== |
| |
| | Autonomous vehicles do not become safe only by perceiving the world correctly. They must also decide what to do, plan a feasible motion, and execute that motion through the vehicle actuators. This chapter focuses on the part of the autonomy stack that transforms environmental understanding into safe action: decision-making, motion planning, and control. |
| | |
| | In a simplified closed-loop view, the autonomy pipeline can be described as follows: |
| | |
| | * perception and localisation estimate the state of the environment and the ego vehicle; |
| | * prediction estimates how other actors may move; |
| | * decision-making selects the intended behaviour or manoeuvre; |
| | * motion planning generates a feasible trajectory; |
| | * control tracks the trajectory through steering, braking, throttle, thrust, or other actuators; |
| | * monitoring and fallback functions supervise the result and trigger replanning or minimal-risk behaviour when needed. |
| | |
| | These functions are strongly interdependent. A motion planner may generate a valid trajectory when tested in isolation, but still fail at system level if perception is delayed, localisation drifts, prediction is uncertain, or the controller cannot physically track the planned path. Similarly, a controller may perform well against a clean reference trajectory, but still produce unsafe or uncomfortable behaviour if the planner generates abrupt, infeasible, or poorly timed commands. For this reason, validation of planning and control cannot be limited to unit testing of individual algorithms. Unit testing is necessary, but it must be connected to integration testing, system-level scenario testing, and operational validation inside the intended Operational Design Domain (ODD). |
| | |
| | The goal of this chapter is therefore not only to introduce common control and planning methods, but to show how they can be validated as part of a complete autonomous vehicle system. The chapter first positions decision-making, motion planning, and control within the autonomy stack. It then discusses the main methods and architectures used in these layers, including classical control, AI-based control, behavioural decision-making, and trajectory planning. The emphasis is placed on the validation implications of these methods: what must be checked, what evidence is needed, and how failures may appear when the component is integrated into the full system. |
| | |
| | A central idea in this chapter is that planning and control validation should be scenario-based. Autonomous vehicles operate in environments where safety depends on interactions between the ego vehicle, other road users, infrastructure, road geometry, environmental conditions, and vehicle dynamics. Therefore, it is not enough to ask whether a planner works for one example case. Instead, engineers must define scenario families, vary their parameters, measure system behaviour, and evaluate whether the vehicle remains safe, legal, comfortable, and robust under the expected range of conditions. |
| | |
| | The chapter introduces the progression from functional scenarios to logical scenarios and then to concrete test cases. A functional scenario describes the situation in natural language, such as an ego vehicle overtaking a slower vehicle or yielding to a pedestrian. A logical scenario defines the relevant parameter ranges, such as vehicle speeds, distances, road geometry, visibility, and actor behaviour. A concrete scenario assigns specific parameter values and becomes an executable test case. This structure helps connect high-level safety requirements to repeatable validation activities. |
| | |
| | Different test methods provide different types of evidence. Simulation enables broad exploration of scenario spaces. Software-in-the-Loop testing allows real planning and control software to be executed in a virtual environment. Hardware-in-the-Loop testing introduces real or representative hardware, communication timing, ECUs, and actuator interfaces. Formal methods can help define safety properties and search for counterexamples. Test tracks provide controlled physical confirmation of selected scenarios, while real-world testing provides evidence from the actual ODD under monitored conditions. A credible validation strategy combines these methods rather than relying on any single one. |
| | |
| | The chapter also connects planning and control validation to the broader systems-engineering process. In the V-model perspective introduced earlier in the handbook, planning and control appear at several validation levels: component verification, integration testing, system validation, and operational validation. This means that the same function must be examined from multiple viewpoints. At component level, the question may be whether a controller tracks a reference trajectory within acceptable error. At system level, the question becomes whether the complete vehicle behaves safely when perception, prediction, planning, control, actuation, timing, and fallback behaviour interact in a realistic scenario. |
| | |
| | By the end of this chapter, the reader should understand how to move from algorithm descriptions to a validation workflow. The intended process is to define the function under test, identify its ODD and assumptions, design scenarios, select measurable performance and safety criteria, choose suitable test methods, and package the resulting evidence for safety assurance. In this way, control, planning, and decision-making are treated not only as algorithmic topics, but as productization and validation targets within the autonomous vehicle development lifecycle. |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | /* =========== Commented |
| | |
| Autonomous systems across ground, airborne, marine, and space domains share common architectural layers—perception, decision-making, and control—but diverge significantly due to differences in dynamics, environmental uncertainty, and safety constraints. **Ground systems** (e.g., automotive and mobile robots) operate in highly structured yet cluttered environments with frequent interactions with humans and infrastructure. Their control algorithms emphasize real-time responsiveness, friction-limited dynamics, and precise low-speed maneuvering (e.g., PID/MPC controllers tuned for tire-road interaction). Decision-making often relies on rule-based systems augmented with probabilistic reasoning to handle traffic laws and agent interactions, while path planning combines graph-based methods (A*, D*) for global routing with sampling-based or optimization-based planners (RRT*, MPC) for local obstacle avoidance under tight latency constraints. | Autonomous systems across ground, airborne, marine, and space domains share common architectural layers—perception, decision-making, and control—but diverge significantly due to differences in dynamics, environmental uncertainty, and safety constraints. **Ground systems** (e.g., automotive and mobile robots) operate in highly structured yet cluttered environments with frequent interactions with humans and infrastructure. Their control algorithms emphasize real-time responsiveness, friction-limited dynamics, and precise low-speed maneuvering (e.g., PID/MPC controllers tuned for tire-road interaction). Decision-making often relies on rule-based systems augmented with probabilistic reasoning to handle traffic laws and agent interactions, while path planning combines graph-based methods (A*, D*) for global routing with sampling-based or optimization-based planners (RRT*, MPC) for local obstacle avoidance under tight latency constraints. |
| |
| |
| **Space systems** operate in the most extreme and least forgiving environment, where delays, limited actuation, and orbital mechanics dominate. Control algorithms are heavily model-based, often derived from first principles (e.g., astrodynamics), with limited opportunity for real-time correction. Decision-making is typically conservative and highly validated, with increasing use of onboard autonomy for deep-space missions where communication delays preclude human-in-the-loop control. Path planning is fundamentally different—focused on trajectory design using orbital transfers, optimization under gravitational constraints, and fuel minimization rather than obstacle avoidance. Across these domains, the progression from ground to space reflects a shift from reactive, data-driven approaches toward predictive, model-based, and highly verified methods, driven by increasing consequences of failure and decreasing opportunities for real-time human intervention. | **Space systems** operate in the most extreme and least forgiving environment, where delays, limited actuation, and orbital mechanics dominate. Control algorithms are heavily model-based, often derived from first principles (e.g., astrodynamics), with limited opportunity for real-time correction. Decision-making is typically conservative and highly validated, with increasing use of onboard autonomy for deep-space missions where communication delays preclude human-in-the-loop control. Path planning is fundamentally different—focused on trajectory design using orbital transfers, optimization under gravitational constraints, and fuel minimization rather than obstacle avoidance. Across these domains, the progression from ground to space reflects a shift from reactive, data-driven approaches toward predictive, model-based, and highly verified methods, driven by increasing consequences of failure and decreasing opportunities for real-time human intervention. |
| | */ |
