Robotic systems
The ultimate goal of studying robotics is to be able to make working robots. That requires making choices about which robotics components (planning, sensing, control, hardware, etc.) to integrate into the robot system, and how to configure all these components.
Fifty years of robotics research have produced some architectures (i.e., specific combinations of robotics components, both in software and in hardware) that have proven to work in practice, i.e., to solve particular goals. This Chapter of the WEBook describes these architectures. In addition, the wider robotics community has given birth to a number of sub-communities, or applications domains (“field robotics”, “assembly automation”,etc.). Finally, we describe how people can interact with autonomous robotic systems.
In many robotic systems, the components of modelling, planning, sensing and regulation/control are closely interacting, at various levels. The following three levels are often identified (implicitly) in the literature (with a sample of the terminology that occurs in the literature):
- Reactive/Operational/Motion/Hard realtime: the sensor signals and the planned motion are immediately transformed into actuation setpoints, and (almost) no model information is used, and that model remains fixed during the whole task.
- Deliberative/Tactical/Task/Soft realtime: the sensor signals are interpreted within one or more possible (dynamic) models, and the current controller can be changed according to the outcome of this model interpretation. A replanning action can be needed when such a deviation from the current plan is recognized.
- Reflective/Strategical/Mission/Non-realtime: the robot system is able to “reflect” about its interaction with its environment, and to generate its own models and plans, based on what it is learning from the sensor information acquired during the execution of lower-level programs.
Robotics as a three-level hierarchy of planning, sensing,
control and modelling modules.
The precise boundaries between the three levels cannot be defined unambiguously, but this pattern of three hierarchical layers does appear quite often. The criterion to decide what activities run at the same level is the amount of interaction (data exchange and execution synchronization) that takes place between components: components with “high” interaction belong to the same level in the hierarchy.
Dividing a robot controller into (hierarchical) levels is a systems or architectural choice of the developer, and the WEBook again has a neutral stance towards which architectures are “better” than others. But, even without committing oneself to one particular architecture, the concept of interacting components at various levels is helpful in structuring the material in the WEBook; hence, various Sections of the Robotics Part of the WEBook use this hierarchical structure to some extent.
The WEBook makes the distinction between functionality on the one hand, and architecture on the other hand: every robotic system is one particular integration (“architecture”) of a set of functionalities, and these functionalities can be described independently from the system in which they are used.
This distinction between architecture and functionality is visible in the thematic structure of this Robotics chapter of the WEBook: software and hardware architectures descriptions are separated from the chapters describing the modelling, planning, sensing and control functionalities. Each of the latter chapters also has its own robotics-independent sections, that appear in the Basic Science and Technology chapters.