8. Robotic Systems Architectures and Programming
Total Page:16
File Type:pdf, Size:1020Kb
187 8. RoboticRobotic Systems Architectures and Programming Syste David Kortenkamp, Reid Simmons 8.1 Overview.............................................. 187 Robot software systems tend to be complex. This 8.1.1 Special Needs complexity is due, in large part, to the need to con- of Robot Architectures .................. 188 trol diverse sensors and actuators in real time, in 8.1.2 Modularity and Hierarchy.............. 188 the face of significant uncertainty and noise. Robot 8.1.3 Software Development Tools.......... 188 systems must work to achieve tasks while moni- toring for, and reacting to, unexpected situations. 8.2 History ................................................ 189 Doing all this concurrently and asynchronously 8.2.1 Subsumption ............................... 189 adds immensely to system complexity. 8.2.2 Layered Robot Control Architectures 190 The use of a well-conceived architecture, 8.3 Architectural Components ..................... 193 together with programming tools that support 8.3.1 Connecting Components................ 193 the architecture, can often help to manage that 8.3.2 Behavioral Control........................ 195 complexity. Currently, there is no single archi- 8.3.3 Executive .................................... 196 tecture that is best for all applications – different 8.3.4 Planning ..................................... 199 architectures have different advantages and dis- 8.4 Case Study – GRACE ............................... 200 advantages. It is important to understand those strengths and weaknesses when choosing an 8.5 The Art of Robot Architectures ............... 202 architectural approach for a given application. 8.6 Conclusions and Further Reading ........... 203 This chapter presents various approaches to architecting robotic systems. It starts by defining References .................................................. 204 terms and setting the context, including a recount- ing of the historical developments in the area of robot architectures. The chapter then discusses connecting those components. Throughout, em- in more depth the major types of architectural phasis will be placed on programming tools and components in use today – behavioral control environments that support these architectures. (Chap. 38), executives, and task planners (Chap. 9) A case study is then presented, followed by a brief – along with commonly used techniques for inter- discussion of further reading. 8.1 Overview The term robot architecture is often used to refer to two robot system might use a publish–subscribe message related, but distinct, concepts. Architectural structure passing style of communication, while another may use refers to how a system is divided into subsystems and a more synchronous client–server approach. Part A how those subsystems interact. The structure of a robot All robotic systems use some architectural structure system is often represented informally using traditional and style. However, in many existing robot systems it boxes and arrows diagrams or more formally using tech- is difficult to pin down precisely the architecture being 8 niques such as unified modeling language (UML)[8.1]. used. In fact, a single robot system will often use sev- In contrast, architectural style refers to the computational eral styles together. In part, this is because the system concepts that underlie a given system. For instance, one implementation may not have clean subsystem bound- 188 Part A Robotics Foundations aries, blurring the architectural structure. Similarly, the sults if the response never arrives or if a response to architecture and the domain-specific implementation are some other request happens to arrive first. In contrast, often intimately tied together, blurring the architectural systems that use publish–subscribe tend to be more style(s). reliable: because messages are assumed to arrive asyn- This is unfortunate, as a well-conceived, clean chronously, the control flow typically does not assume architecture can have significant advantages in the spe- any particular order in which messages are processed, cification, execution, and validation of robot systems. and so missing or out-of-order messages tend to have In general, robot architectures facilitate development by less impact. providing beneficial constraints on the design and im- plementation of robotic systems, without being overly 8.1.2 Modularity and Hierarchy restrictive. For instance, separating behaviors into modular units helps to increase understandability and One common feature of robot architectures is modu- reusability, and can facilitate unit testing and validation. lar decomposition of systems into simpler, largely independent pieces. As mentioned above, robot sys- 8.1.1 Special Needs of Robot Architectures tems are often designed as communicating processes, where the communications interface is typically small In some sense, one may consider robot architectures as and relatively low bandwidth. This design enables the software engineering. However, robot architectures are processes/modules to handle interactions with the envi- distinguished from other software architectures because ronment asynchronously, while minimizing interactions of the special needs of robot systems. The most impor- with one another. Typically, this decreases overall sys- tant of these, from the architectural perspective, are that tem complexity and increases overall reliability. robot systems need to interact asynchronously, in real Often, system decomposition is hierarchical – modu- time, with an uncertain, often dynamic, environment. In lar components are themselves built on top of other addition, many robot systems need to respond at varying modular components. Architectures that explicitly sup- temporal scopes – from millisecond feedback control to port this type of layered decomposition reduce system minutes, or hours, for complex tasks. complexity through abstraction. However, while hier- To handle these requirements, many robot archi- archical decomposition of robotic systems is generally tectures include capabilities for acting in real time, regarded as a desirable quality, debate continues over controlling actuators and sensors, supporting concur- the dimensions along which to decompose. Some archi- rency, detecting and reacting to exceptional situations, tectures [8.2] decompose along a temporal dimension dealing with uncertainty, and integrating high-level – each layer in the hierarchy operates at a character- (symbolic) planning with low-level (numerical) control. istic frequency an order of magnitude slower than the While the same capability can often be implemented layer below. In other architectures [8.3–6], the hierar- using different architectural styles, there may be ad- chy is based on task abstraction – tasks at one layer vantages of using one particular style over another. are achieved by invoking a set of tasks at lower levels. As an example, consider how a robot system’s style In some situations, decomposition based on spatial ab- of communications can impact on its reliability. Many straction may be more useful, such as when dealing with robot systems are designed as asynchronous processes both local and global navigation [8.7]. The main point is that communicate using message passing. One popular that different applications need to decompose problems communication style is client–server, in which a mes- in different ways, and architectural styles can often be sage request from the client is paired with a response found to accommodate those different needs. from the server. An alternate communication paradigm is publish–subscribe, in which messages are broadcast 8.1.3 Software Development Tools asynchronously and all modules that have previously Part A indicated an interest in such messages receive a copy. While significant benefit accrues from designing sys- With client–server-style message passing, modules typ- tems using well-defined architectural styles, many ically send a request and then block, waiting for the architectural styles also have associated software tools 8.1 response. If the response never comes (e.g., the server that facilitate adhering to that style during implemen- module crashes) then deadlock can occur. Even if the tation. These tools can take the form of libraries of module does not block, the control flow still typically functions calls, specialized programming languages, or expects a response, which may lead to unexpected re- graphical editors. The tools make the constraints of the Robotic Systems Architectures and Programming 8.2 History 189 architectural style explicit, while hiding the complexity computer aided design (ORCCAD)[8.6], provide of the underlying concepts. constrained ways to assemble systems, and then auto- For instance, inter-process communication libraries, matically generate code that adheres to the architectural such as common object request broker architecture style. (CORBA)[8.8] and inter-process communication (IPC) In each case, the tools facilitate the development package [8.9], make it easy to implement message pass- of software in the given style and, more importantly, ing styles, such as client–server and publish–subscribe, make it impossible (or, at least, very difficult) to vio- respectively. Languages, such as Subsumption [8.10] late the constraints of that architectural style. The result and Skills [8.11] facilitate the development of data- is that systems implemented using such tools are typ- driven, real-time behaviors, while languages such as the ically easier to implement,