Handbook of Robotics Chapter 8: Robotic Systems Architectures and Programming
Total Page：16
File Type：pdf, Size：1020Kb
Handbook of Robotics Chapter 8: Robotic Systems Architectures and Programming David Kortenkamp TRACLabs Inc. 1012 Hercules Houston TX 77058 [email protected] Reid Simmons Robotics Institute, School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh PA 15241 [email protected] Chapter 8 Robotic Systems Architectures and Programming Robot software systems tend to be complex. This difficult to pin down precisely the architecture being complexity is due, in large part, to the need to control used. In fact, a single robot system will often use diverse sensors and actuators in real time, in the face of several styles together. In part, this is because the significant uncertainty and noise. Robot systems must system implementation may not have clean subsystem work to achieve tasks while monitoring for, and boundaries, blurring the architectural structure. reacting to, unexpected situations. Doing all this Similarly, the architecture and the domain-specific concurrently and asynchronously adds immensely to implementation are often intimately tied together, system complexity. blurring the architectural style(s). The use of a well-conceived architecture, together with This is unfortunate, as a well-conceived, clean programming tools that support the architecture, can architecture can have significant advantages in the often help to manage that complexity. Currently, there specification, execution, and validation of robot is no single architecture that is best for all applications systems. In general, robot architectures facilitate – different architectures have different advantages and development by providing beneficial constraints on the disadvantages. It is important to understand those design and implementation of robotic systems, without strengths and weaknesses when choosing an being overly restrictive. For instance, separating architectural approach for a given application. behaviors into modular units helps to increase understandability and reusability, and can facilitate unit This chapter presents various approaches to architecting testing and validation. robotic systems. It starts by defining terms and setting the context, including a recounting of the historical Special Needs of Robot Architectures developments in the area of robot architectures. The chapter then discusses in more depth the major types of In some sense, one may consider robot architectures as architectural components in use today – behavioral software engineering. However, robot architectures are control (see Ch. 38), executives, and task planners (see distinguished from other software architectures because Ch. 9) – along with commonly used techniques for of the special needs of robot systems. The most inter-connecting those components. Throughout, important of these, from the architectural perspective, emphasis will be placed on programming tools and are that robot systems need to interact asynchronously, environments that support these architectures. A case in real time, with an uncertain, often dynamic, study is then presented, followed by a brief discussion environment. In addition, many robot systems need to of further reading. respond at varying temporal scopes – from millisecond feedback control to minutes, or hours, for complex 8.1. Introduction tasks. To handle these requirements, many robot architectures The term robot architecture is often used to refer to two include capabilities for acting in real time, controlling related, but distinct, concepts. Architectural structure actuators and sensors, supporting concurrency, refers to how a system is divided into subsystems and detecting and reacting to exceptional situations, dealing how those subsystems interact. The structure of a robot with uncertainty, and integrating high-level (symbolic) system is often represented informally using traditional planning with low-level (numerical) control. “boxes and arrows” diagrams or more formally using techniques such as UML [Jacobson et al 1998]. In While the same capability can often be implemented contrast, architectural style refers to the computational using different architectural styles, there may be concepts that underlie a given system. For instance, advantages of using one particular style over another. one robot system might use a publish-subscribe As an example, consider how a robot system’s style of message passing style of communication, while another communications can impact its reliability. Many robot may use a more synchronous client-server approach. systems are designed as asynchronous processes that communicate using message passing. One popular All robotic systems use some architectural structure and communication style is client-server, in which a style. However, in many existing robot systems it is message request from the client is paired with a response from the server. An alternate communication Software Development Tools paradigm is publish-subscribe, in which messages are broadcast asynchronously and all modules that have While significant benefit accrues from designing previously indicated an interest in such messages systems using well-defined architectural styles, many receive a copy. With client-server style message architectural styles also have associated software tools passing, modules typically send a request and then that facilitate adhering to that style during block, waiting for the response. If the response never implementation. These tools can take the form of comes (e.g., the server module crashes) then deadlock libraries of functions calls, specialized programming can occur. Even if the module does not block, the languages, or graphical editors. The tools make the control flow still typically expects a response, which constraints of the architectural style explicit, while may lead to unexpected results if the response never hiding the complexity of the underlying concepts. arrives or if a response to some other request happens to For instance, inter-process communication libraries, arrive first. In contrast, systems that use publish- such as CORBA [Orfali et al 1997] and IPC [Simmons subscribe tend to be more reliable: because messages & Whelan 1997], make it easy to implement message are assumed to arrive asynchronously, the control flow passing styles, such as client-server and publish- typically does not assume any particular order in which subscribe, respectively. Languages, such as messages are processed, and so missing, or out-of-order, Subsumption [Brooks 1990b] or Skills [Firby & Slack messages tend to have less of an impact. 1995] facilitate the development of data-driven, real- time behaviors, while languages such as ESL [Gat Modularity and Hierarchy 1997] and PLEXIL [Verma et al 2005] provide support One common feature of robot architectures is modular for reliably achieving higher-level tasks. Graphical decomposition of systems into simpler, largely editors, such as found in ControlShell [Schneider et al independent pieces. As mentioned above, robot 1998], Labview [Labview] and ORCCAD [Borrelly systems are often designed as communicating processes, 1998], provide constrained ways to assemble systems, where the communications interface is typically small and then automatically generate code that adheres to the and relatively low bandwidth. This design enables the architectural style. processes/modules to handle interactions with the In each case, the tools facilitate the development of environment asynchronously, while minimizing software in the given style and, more importantly, make interactions with one another. Typically, this decreases it impossible (or, at least, very difficult) to violate the overall system complexity and increases overall constraints of that architectural style. The result is that reliability. systems implemented using such tools are typically Often, system decomposition is hierarchical – modular easier to implement, understand, debug, verify, and components are themselves built on top of other maintain. They also tend to be more reliable, since the modular components. Architectures that explicitly tools provide well-engineered capabilities for support this type of layered decomposition reduce commonly needed control constructs, such as message system complexity through abstraction. However, passing, interfacing with actuators and sensors, and while hierarchical decomposition of robotic systems is handling concurrent tasks. generally regarded as a “desirable quality”, debate continues over the dimensions along which to 8.2. History decompose. Some architectures (c.f. [Albus 1995]) decompose along a temporal dimension – each layer in Robot architectures and programming began in the late the hierarchy operates at a characteristic frequency an 1960s with the Shakey robot at Stanford University order of magnitude slower than the layer below. In [Nilsson 1969] (see Figure 8.1). Shakey had a camera, other architectures ([Brooks 1986; Firby 1987; a range finder, and bump sensors, and was connected to Simmons 1994; Borrelly 1998]), the hierarchy is based DEC PDP-10 and PDP-15 computers via radio and on task abstraction – tasks at one layer are achieved by video links. Shakey’s architecture was decomposed invoking a set of tasks at lower levels. In some into three functional elements: sensing, planning, and situations, decomposition based on spatial abstraction executing [Nilsson 1980]. The sensing system may be more useful, such as when dealing with both translated the camera image into an internal world local and global navigation (c.f., [Kuipers 2000]. The