Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| en:safeav:ctrl:strategies [2026/06/02 23:00] – momala | en:safeav:ctrl:strategies [2026/06/02 23:37] (current) – momala | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Planning and Control in the AV Stack ===== | + | ====== 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. | 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. | ||
| Line 14: | Line 14: | ||
| 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. | 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 ==== | + | ===== The role of each layer ===== |
| ^ Layer ^ Main role ^ Typical input ^ Typical output ^ Main validation question ^ | ^ Layer ^ Main role ^ Typical input ^ Typical output ^ Main validation question ^ | ||
| Line 24: | Line 24: | ||
| 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). | 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 ==== | + | ===== Why this layer is different from the rest of the stack ===== |
| Compared with perception and localisation, | Compared with perception and localisation, | ||
| Line 34: | Line 34: | ||
| - and safety assurance. | - and safety assurance. | ||
| - | ==== Domain differences ==== | + | ===== Domain differences |
| The same functional chain exists in all autonomy domains, but the emphasis changes with the physical environment. | The same functional chain exists in all autonomy domains, but the emphasis changes with the physical environment. | ||
| Line 48: | Line 48: | ||
| 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. | 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 ==== | + | ===== 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: | 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: | ||
