IMA: THE INTELLIGENT MACHINE ARCHITECTURE By Robert Todd Pack Dissertation Submitted to the Faculty of the Graduate School of Vanderbilt University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY in Electrical and Computer Engineering March 2003 Nashville, Tennessee

Approved:

Date:

ACKNOWLEDGEMENTS I thank Dr. K. Kawamura for believing in my ideas enough to let me lead his robotics lab into the new area of architecture-driven software design. I thank my committee for their comments, reviews and suggestions that contributed to this effort. I thank my wonderful wife, Ruth, for putting up with me during this very long journey. Finally, I thank God for the ability and the inspiration to develop new contributions to the area of robotics. He has continually guided me back to the idea of robots and I pray that this work will contribute in some small way to the development of service robots that relieve pain and suffering, aid those in need of assistance, or provide companionship to those who are alone.

ii

TABLE OF CONTENTS Page ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi

LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Chapter I. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background . . . . . . . . . . Research Objectives . . . . . Assumptions . . . . . . . . . Summary of Research . . . . Organization of Dissertation

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

II. SOFTWARE ARCHITECTURE FOR INTELLIGENT ROBOTICS Background . . . . . . . . . . . . . . . . . . . Software Architecture . . . . . . . . . . System Complexity and Decomposition Integration and Arbitration . . . . . . Robot Software Architectures . . . . . . . . . Knowledge-Based Architectures . . . . . . . . Behavior-Based Architectures . . . . . . . . . Hybrid Architectures . . . . . . . . . . . . . Multi-Agent Architectures . . . . . . . . . . . Discussion of Issues . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

1 2 6 9 10 12 14

. . . . . . . . . .

14 15 17 18 21 22 28 37 43 49

III. OVERVIEW OF THE INTELLIGENT MACHINE ARCHITECTURE 51 Introduction . . . . . . . . . . Robot-Environment Model . . Agents . . . . . . . . . . Relationships . . . . . . Agent-Object Model . . . . . . Code Development Framework

. . . . . .

51 56 57 60 61 65

IV. ROBOT-ENVIRONMENT MODEL IN THE IMA . . . . . . . . . .

69

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMA Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intelligent Service Robot Domain Agents . . . . . . . . . . .

69 70 71

iii

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Conceptual Agent Interaction Model . . . . . . . . . . . . . IMA Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . Classification of Relationship Types . . . . . . . . . . . . . .

72 75 77

V. AGENT-OBJECT MODEL IN THE IMA . . . . . . . . . . . . . . .

81

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structured Object-Oriented Model . . . . . . . . . . . . . . . . . .

81 88

VI. EXAMPLE SYSTEMS USING THE IMA . . . . . . . . . . . . . . .

96

ISAC: Dual-Armed Humanoid Robot . . . . . . . . . . . . . . . . . Helpmate: Mobile Manipulator . . . . . . . . . . . . . . . . . . . .

96 97

VII. EVALUATION OF THE ARCHITECTURE . . . . . . . . . . . . .

99

VIII. CONCLUSIONS AND FUTURE RESEARCH . . . . . . . . . . . . 101 Appendix A. DEFINITIONS OF IMA TERMS

. . . . . . . . . . . . . . . . . . . 102

IMA Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 B. ROBOTICS TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . 112 C. UML NOTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 114 State Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 D. COMPONENT OBJECT SOFTWARE . . . . . . . . . . . . . . . . 115 The Component Object Model (COM) . . . . . . . . . . . . . . . . 116 Special COM / OLE Interfaces . . . . . . . . . . . . . . . . . . . . 118 E. USING THE CODE FRAMEWORK . . . . . . . . . . . . . . . . . . 122 Introduction . . . . . . . . . . . . . Writing Simple Agent Components . Writing Representation Components Writing Relationship Components . Writing Component Managers . . . Writing Agent Shell Programs . . .

iv

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

122 124 124 124 124 124

Writing Agent Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 126 F. SYNCHRONIZATION MECHANISM . . . . . . . . . . . . . . . . . 127 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

v

LIST OF FIGURES Figure

Page

1. Action Selection Problem . . . . . . . . . . . . . . . . . . . . . . . .

21

2. SMPA Approach [17] . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3. Utility-Based Agent [11] . . . . . . . . . . . . . . . . . . . . . . . .

24

4. InteRRap Architecture [67] . . . . . . . . . . . . . . . . . . . . . . .

27

5. Behavior-Based Approach [17] . . . . . . . . . . . . . . . . . . . . .

29

6. Agent Network Architecture [59]

. . . . . . . . . . . . . . . . . . .

31

7. Blumberg’s Behavioral Architecture [13] . . . . . . . . . . . . . . .

33

8. AuRA Architecture [6] . . . . . . . . . . . . . . . . . . . . . . . . .

36

9. Motion Schema Concept from Arkin [6]

. . . . . . . . . . . . . . .

36

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

10. RCS Layer [2]

11. GLAIR Architecture [48]

. . . . . . . . . . . . . . . . . . . . . . .

41

12. CIRCA Architecture [68]

. . . . . . . . . . . . . . . . . . . . . . .

42

. . . . . . . . . . . . . . . . . . . . . . . . . .

46

14. Suehiro’s Agent Network [87] . . . . . . . . . . . . . . . . . . . . .

47

15. JANUS Architecture [12]

. . . . . . . . . . . . . . . . . . . . . . .

48

16. Map of Robot Architectures . . . . . . . . . . . . . . . . . . . . . .

50

17. IMA Development Process . . . . . . . . . . . . . . . . . . . . . . .

55

18. Correspondence of IMA Agents to System-Level Entities . . . . . .

57

19. IMA Agent Internal Structure . . . . . . . . . . . . . . . . . . . . .

66

20. IMA Agent Classifications . . . . . . . . . . . . . . . . . . . . . . .

73

21. Asynchronous Decision and Computation Processes . . . . . . . . .

74

13. ISAC 2 System [10]

vi

22. Asymmetric Agent Relationships in IMA . . . . . . . . . . . . . . .

79

23. Symmetric Agent Relationships in IMA . . . . . . . . . . . . . . . .

80

24. Structural Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

25. Functional Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

26. Policy Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

27. Simple Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

28. More Complex Connection . . . . . . . . . . . . . . . . . . . . . . .

90

29. Fully Symetric Relationship . . . . . . . . . . . . . . . . . . . . . .

91

30. Agent-Object Model: Top Level Class Diagram . . . . . . . . . . .

92

31. Agent-Object Model: Loading Sequence Diagram . . . . . . . . . .

93

32. Agent-Object Model: Component State Diagram . . . . . . . . . .

94

33. Detail of Relationships and Contributions

. . . . . . . . . . . . . .

95

34. Agent-Network for ISAC Demo . . . . . . . . . . . . . . . . . . . .

97

35. Agent-Network for Helpmate Demo . . . . . . . . . . . . . . . . . .

98

36. UML Model of COM . . . . . . . . . . . . . . . . . . . . . . . . . . 119 37. UML Model IDispatch . . . . . . . . . . . . . . . . . . . . . . . . . 121 38. UML Model of Framework Base Classes

. . . . . . . . . . . . . . . 125

39. Agent Time Synchronization Mechanism . . . . . . . . . . . . . . . 128

vii

LIST OF TABLES Table

Page

1. Summary of Architectural Properties . . . . . . . . . . . . . . . . .

viii

49

CHAPTER I INTRODUCTION This work investigates the problem of designing software for intelligent machines, such as service robots. Intelligent machines get information from a set sensors and control a set of actuators. Intelligent machines incorporate the ability to react to changes in their environment, incorporate a-priori knowledge and work to complete tasks. Thus, they are both deliberative and reactive in their operation. Between the sensors and actuators of an intelligent machine lies a computational mechanism and software that together must provide paths from sensing to action that allow the intelligent machine to complete its tasks. The software architecture of an intelligent machine is a plan for building the software system that resides between sensors and actuators and utilizes the underlying computing mechanism to complete its tasks. The resulting software system provides the connection between sensing and action for the intelligent machine. Many solutions to the design problem exist and serve a wide variety of robot development communities. The problem of intelligent service robot control will be discussed in the context of current approaches, and the contribution of software architecture will be identified. Next, several available intelligent robot-control architectures are described, classified, and compared based on architectural features. Finally, a new approach to this software design problem that takes advantage of advances in object-based software engineering is described and evaluated based on reuse of code and scalability of performance. This new software architecture is based on a philosophy [51] that places more

1

importance on versatility and extensibility than development of a single, general mechanism, acknowledges the need for multiple processing paths from robot sensors to robot actuators, provides a way to manage multiple internal representations, and takes advantage of commonly available computer systems. This new software architecture guides the development of robot control software and specifies a distributed network of independent, cooperating and competing software modules termed agents. These agents and the connections between them form an active object-oriented model of the physical resources, behaviors, skills, and tasks that constitute the robot as well as the internal models of robot users and physical objects in the robot’s environment.

Background The Intelligent Machine Architecture (IMA) is a software architecture that supports the development of integrated control software for intelligent service robots and potentially, other intelligent machines. Thus, this work is the union of software architecture and various design approaches for building intelligent robots. It is also concerned with achieving and maintaining software system integration by following a software architecture that guides development. A software architecture is a kind of plan or template for building a related class of software systems. An architecture provides descriptions of the components and connections between them at certain levels of abstraction [?]. A system (set of components and their connections with a purpose) conforms to an architecture if the contstraints imposed by the architecture are met. Small-scale architectural descriptions (template for building a piece of a system) are called design patterns [23]

2

in the object-oriented design community. To define “intelligent systems” or “intelligent service robots”, I submit that these systems utilize sensing to capture relevant aspects of their environment, and their own internal resources of computation and physical action to achieve some physical task. Intelligent systems should be characterized purely by observable intelligent action instead of any special internal features. An intelligent machine should be able to bring physical, computational, and informational resources together to complete its tasks. As a guideline, intelligent service robot behavior should resemble some aspects of the behavior of animals and humans when presented with similar problems. Intelligent service robots should be able to use their computational, sensory, and physical resources to achieve goals and respond to changes in the environment. Erman has attributed the following properties to intelligent systems [32] and these properties are quoted again by Booch [14] in the context of software engineering: • They pursue goals that vary over time. • They incorporate, use, and maintain knowledge. • They exploit diverse, ad hoc subsystems embodying a variety of selected methods. • They interact intelligently with users and other systems. • They allocate their own resources and attention. From the viewpoint of software architecture, the most important characteristic is the ability to exploit diverse subsystems that embody a variety of methods. 3

This and other experience suggests strongly that there is no one way to implement the software system for an intelligent machine, so an architecture will need to be versatile to address this problem. The ability to incorporate, use, and maintain an internal representation of knowledge is one possible method for guiding behavior as pointed out in the work of Agre and Chapman [1], and several other methods have been used successfully by Brooks, et al. [19, 63, 59]. Thus, there is no unique solution to the problem of creating the software system that exhibits intelligent behavior on a particular intelligent machine or even agreement on how it might be achieved. It is likely that the essence of intelligent behavior is the structured integration of various components in a large and complex system that accounts for such a diversity of methods. Service robots are one type of intelligent machine that is designed to interact with human users in relatively unstructured environments. Other definitions of the term “robot” include the word “programmable” or “reprogrammable”; for example, the robotics frequently asked questions list [30] gives this definition: “A reprogrammable, multifunctional manipulator designed to move material, parts, tools or specialized devices through various programmed motions for the performance of a variety of tasks.” This reiterates the problem that the robot’s software system must solve. In contrast, the Random House Dictionary describes a robot as “An automatic device that performs functions normally ascribed to humans or a machine in the form of a human.” [91] Thus, the performance goals for an intelligent robot system are continually increasing in complexity. Ironically, it is often thought that, as soon as robots can effectively handle a problem, then it is no longer a challenge since “even robots can do that.” This suggests the criterion that 4

robot software should be designed to evolve over time and have new capabilities added to it. McFarland points out that intelligent systems are ultimately characterized by their externally observable behavior [63], not on the theoretical elegance of their internal mechanisms. Since we commonly attribute intelligence to animals or people and have little knowledge of the mechanisms involved, it is a practical measure of intelligence. This type of definition of intelligence is also attributed to Turing, who proposed the now famous Turing Test [33]. In this test a machine tries to convince a person that it is really another person by answering a series of questions from the real person. This test ignores the fact that intelligent behavior exists in many forms and that human language understanding is not necessary for intelligence. However, the common feature of these viewpoints is the idea that intelligence is accessible only through observing intelligent behavior. For the purpose of design and development of such systems, the intelligent machine must be viewed as a system and the software used in the intelligent machine is a software subsystem. This software system needs an architecture that can guide development and manage the complexity of development and improvement over time. The designer of a robot may want the robot to go down a cluttered hall and not get stuck, get lost, or do any damage. However, this externally observable behavior has no simple or unique implementation on a given set of robot hardware. If the problem or domain is more structured and problem description is more formal, then methods that deliberate based on logical models are a good match. If the problems are essentially reactive, like mobile robots in dynamic environments, then the behavior-based methods can excel because they rely on simple reactive rules 5

to select actions. Many researchers are now combining the these approaches in the software systems for robot control. This work represents an effort to design a software architecture that combines support for both types of control and the progressive development of the software system itself over time.

Research Objectives Software design for intelligent robotic systems is a large, open-ended problem. A number of partially successful approaches in current practice address this type of software design. When given a robot, a machine that is a physically integrated set of computers, sensors and actuators, it is natural to ask the question, How can I make this machine intelligent? How can I make it solve problems? Handle new situations? Interact with humans and other robots? The answer lies in the control software for the robot. Few existing systems emphasize the importance of software architecture in the design of the software system despite the fact that control software is frequently developed based on tacit assumptions that define how the overall software system will be structured and influences the success of implementation and improvement over time. Some software systems are intended to be models of cognitive processes [4] or animal behaviors [63], while others are based on assuming that the world follows a formal, logical model [35] and some are essentially ad-hoc [17]. If the desired intelligent behavior of a service robot could be defined directly in terms of systems of differential equations, modern control theory would be a powerful tool that would let us build controllers easily. If the domain could be adequately defined by a set of production rules or statements in the predicate

6

calculus, then classical AI would solve the problem for us by applying symbolic knowledge of a formal model of the environment and robot. Newer architectures, like behavior-based AI, let us specify which behaviors we would like, but these approaches remain controversial because they are thought to be mostly ad hoc. Interactions in such systems are difficult to manage as the software system grows [70]. Few attempts have been made to model the interactions in these systems except for the work of Kosecka [53] on discrete-event modeling. Intelligent behaviors can be partially realized by a variety of methods. The specification and expectations for the behaviors are often imprecise. The complexity of building a software system to exhibit intelligent behaviors is a design problem that must be managed by an explicit software architecture. There is a distinct lack of an accepted approach for building robot software systems that exhibit intelligent and robust behavior in less structured environments, like the software for service robots. Instead, a patchwork of disparate methods are used. This is because many architectures used for intelligent robot control were originally designed to illustrate the functioning of a single principle, mechanism, or cognitive model and were pressed into service to help manage the software system for a robot. At a recent International Conference on Robotics and Automation panel discussion, systems integration was identified as one of the grand challenges facing robotics research in the future [28]. These concerns form the motivation for this work. Needed is an effort to develop new software architectures that address the problem of building integrated robot control software systems, take advantage of the wide array of fundamental developments in the robotics community, draw on the growing field of software engineering, and guide 7

the software development process to manage complexity. This work is in the spirit of explicit architecture-driven software design that is currently supported by a variety of methods in professional software practice such as object-oriented design and modeling of systems [14, 76, 39], as well as more formal research projects on modeling and developing system architectures such as MULTIGRAPH [88, 89] and architecture-centered design of software systems [41, 3]. Some applications of object-oriented concepts to design of software for robots have been described in Configurable Modular Reference Here, Bagchi, others. The objective of this work is to design a software architecture for intelligent service robot software systems by bringing previous developments in robot architectures together with recent advances in software architecture to help manage the inherent complexity of software development for this domain. Another motivation for this work is that the search for intelligent behavior in intelligent machines may be better served by developing an architecture that supports integration of existing ideas and methods, rather than the search for the “silver bullet” [16] that will give us intelligent robots. Some conceptual tools are becoming available from the field of software engineering to help address integration issues. This dissertation presents the design of a new software architecture for intelligent service robot software systems that draws on recent advances in software engineering, object-oriented modeling and design, and other robot control architectures. This architecture represents a unique approach to software for robot control for the following reasons: • The architecture is designed and expressed using common visual notation for

8

software architecture. • It is a two-level architecture that specifies a high-level model as well as an implementation-level model for the robot control software. • It is implemented using standard, commercially available distributed object software technology, and standard programming languages. • It explicitly supports reuse of software at a high level and a low level. • It is designed to support evolution of the resulting software system at the system level and at the implementation level, by enforcing strong encapsulation, and a separation of the aspects of the software.

Assumptions This work is based on several assumptions that reflect the pragmatic attitude of the author. The implementation of this system should take advantage of current commercial hardware and software platforms so that it can be delivered in lower cost environments. The resulting design will undoubtedly favor the development of software for a network of workstation-class computers with various I/O interfaces, connected using traditional LAN technology, that form the computational hardware for a robot. Additionally, many research efforts in this area start by building their own libraries for network transport, message passing, and other communication primitives. However, standard commercial tools exist to fill such roles in system design and should be reused in an effort to make research software more closely related

9

to currently available software. Furthermore, no experience is gained or contribution made by developing these tools unless specific advantages are required for the resulting system to operate. This work is intended to create a system architecture that can be implemented using traditional programming languages on commercially available operating system platforms. Thus, the availability of hard real-time properties for the underlying system is not required, and instead a soft real-time mechanism that incorporates an explicit representation of time is used to let the software be aware of time. Finally, this work favors an experimental approach to robot software development. There is no reason to believe that intelligent machines, especially service robots, can be adequately and completely specified in advance or have a fixed, known set of components and functionality. Much research needs to be done in service robot design and the software architecture presented herein is intended to support exploratory, incremental, and rapid development of software systems to explore problems in service robotics. Thus, this work could be viewed as a kind of software development tool that helps organize subsystems and guide development while keeping the software system integrated into a single working whole as new components are added to the software system.

Summary of Research In the following review, it will be seen that very few intelligent robot software systems are described in terms of software architecture. The typical mechanism used for describing the software system for a robot is an ad hoc diagram that is represents data flow between various functional modules of the robot. Some

10

architectures are also described in terms of a set of functional layers. Despite the wide availability of relatively standard approaches for describing many aspects software architecture in graphical terms [46, 14, 76] and the fact that many reviewed approaches are intended to illustrate a pattern for software design, most robot software architectures are presented as a functional block diagram that resembles a simple flow chart. The emergence of Software Engineering as a new discipline [41] and the development of concepts in software architecture provide us with new abstractions [88, 3, 80] that support the development of software architectures for intelligent machines that are expressed using some of the widely accepted visual notations for software architecture. The future holds promise for even more structured and formal approaches. The last decace has seen a revolution in the development of robot software systems that combine reactivty and deliberation as well as the growth of research on multi-agent systems. These developments are all influences on the design presented in this dissertation. This work will offer a new architecture for building the software system that is a part of an intelligent machine, such as a service robot. This new architecture draws from ideas that are now commonly used in object-oriented software development and provides structures that support the integration of the wide variety of components required to build the software system for an intelligent machine. The design of this new architecture facilitates development of reusable, modular and configurable components and connectors. Integration is supported by viewing connections between components as a special type of component. This kind of duality of connections (links between system components) and connectors (components that represent a link) provides a model where new link types and new 11

components may both be accomodated as the system grows and is common in software architecture research [3]. The architecture has been used to develop demonstrations of service robot capability and is evaluated on the basis of performance, scalability and reuse.

Organization of Dissertation The remainder of this document is organized as follows: Chapter 2 investigates the role of software architecture and reviews a wide variety of software systems for intelligent robots from a software engineering point of view. Chapter 3 introduces a new architecture for robot software development, called the intelligent machine architecture (IMA). The intelligent machine architecture comprises the following things: • The Robot-Environment model which describes the software at a high level comparable to the level at which robot software is typically described. Chapter 4 is devoted to describing this level of the architecture. • The Agent-Object model which describes how the robot-system level entities and relationships are implemented using component-object software [64]. Chapter 5 is devoted to describing this level of the architecture, and an appendix describes the component-object technology used for implementation. • The Component Software Framework which describes the software framework implementing these ideas in C++ that supports developers use of the architecture. A description of this framework is provided in an appendix.

12

Because software architecture an be so abstract, Chapter 7 describes a test-bed system and shows how the Intelligent Machine Architecture is used to describe the Robot-Environment model of two intelligent service robot demonstration systems. This chapter also includes examples of how the Agent-Object model is used to describe selected agents within these demonstration systems. First, we will begin with a review of software systems for robots with an emphasis on software architecture issues.

13

CHAPTER II SOFTWARE ARCHITECTURE FOR INTELLIGENT ROBOTICS We shape our buildings; thereafter they shape us. - Sir Winston Churchill

Background Although it is practical that intelligent machines ultimately be measured by their behavior [63], such machines are not black boxes. It is of primary importance to the development and implementation of intelligent machines, like service robots, that there exist a carefully designed architecture to guide development of the software system that utilites the robot’s computational resources to connect sensors and actuators. There is currently no accepted software architecture for general robot control or even an agreement on what is desirable for such an architecture. However, many disparate approaches are available. This presents the opportunity to take the best features of several design methods and philosophies and combine them into a new and potentially powerful approach to the design of robotic control systems. The architecture design problem then becomes how to decompose the system and to provide mechanisms for software integration that support intelligent behavior, help to mange the complexity of the design process, and support software reuse. One of Brooks’s observations will guide the selection of architectural features: “The complex behavior of a system emerges from the intensive interactions of its internal structure with the physics of the outside world” [17]. The software that

14

supports such complex behavior on a robot quickly becomes complex as tasks are added, requirements for robustness are increased, and constraints on resources are imposed by the physical design of the robot. The following sections will describe the role of software architecture in the design of software systems for robots and then a review of software systems and architectures from the robotics literature will follow, ending in a summary of architectural issues and features from the literature.

Software Architecture The type of computer hardware and the name of the operating system does not constitute an architecture for the software of an intelligent machine. Arkin [7] points out that an architecture is a set of organizing principles and basic components that form the basis for the system. By describing the fundamental components and their interactions, an intelligent control system is decomposed into more primitive abstractions that serve as models for the physical resources, skills, behaviors, and tasks that are developed in the control system. This abstraction is the set of building blocks and interactions with which to construct the software system for intelligent robots. These building blocks, their interactions, and the principles behind them constitute a system architecture. Thus, a software architecture for intelligent robot control is a set of organizing principles and fundamental components that help designers manage the complexity of building robot control software that supports intelligent action. A good architecture also serves as a model of the robot’s capabilities, tasks, and resources

15

and provides an abstraction of the intelligent machine for developers of the system. Given the above discussion, the primary functions of software architecture for intelligent control are as follows (drawn from ideas in Garlan [41]): • The architecture must model the behaviors, skills, resources, and tasks of the robot with more fundamental elements that represent the building blocks used to synthesize an intelligent control system. This decomposition helps manage the complexity of system development. • The architecture must provide a set of mechanisms and connectors for integrating these fundamental elements into an overall system so that the desired intelligent behavior can be realized. As Shaw [81] puts it, an architecture is “components and connectors.” The specification of an architecture is a description of components and the connections between components. A good architecture can provide a set of abstractions that are easy to use and understand. It is also desirable to reuse the components of a software system to build larger systems, adding new or different components as needed. We would also like to incorporate new types of connection between elments (connectors) as the system grows, so that the overall system is extensible both with new components and new connectors. This requires that the architecture support a strong concept of subsystem and connection so that the design of reusable sub-systems is encouraged.

16

System Complexity and Decomposition One major aspect of developing a software system for an intelligent machine, like a service robot, is that such systems immediately present a monumental software engineering project for any group attempting to develop a system of appreciable size. This problem is compounded by the fact that most task and problem descriptions are in a proscriptive format, while software provides only a prescriptive interface to the system as described by Stewart [85]. This is sometimes called “impedance mismatch” between specification and design in software systems (by Booch [14]). The software system can become quite complex, and this complexity grows with the level of complexity of the tasks that are desired. Several authors have commented on system complexity; below is a collection of comments that reflect directly on system architecture problems (collected by Booch [14]): • “Frequently complexity takes the form of a hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until some lowest level of elementary components is reached. [26]” • “The choice of what components in a system are primitive is relatively arbitrary and is largely up to the discretion of the observer of the system. [83]” • “Intracomponent linkages are generally stronger than intercomponent linkages. This fact has the effect of separating the high-frequency dynamics of the components – involving the internal structure of the components – from the low-frequency dynamics – involving interaction among components. [83]”

17

• “Hierarchic systems are usually composed of only a few different kinds of subsystems in various combinations and arrangements.” • “A complex system that works is invariably found to have evolved from a simple system that worked... A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. [40]” To address the problem of system complexity, an architecture must provide models for system decomposition and integration. A broad range philosophies guides which methods are in use. Knowledge-based approaches decompose the system into pieces of knowledge and reasoning mechanisms. Behavior-based approaches decompose the system into directly interacting behaviors. Hybrid systems may have both knowledge-based and behavior-based elements. The types of connections that are permitted in the software define how the system grows when new elements are added. Some architectures are essentially fixed and only “data” or “knowledge” is added, while other archtiectures change structure to accomodate new elements or functions.

Integration and Arbitration Integration is the connection between components, and although there are many types of connections, the most complex types of connection use some kind of arbitration mechanism to control aspects of the interaction. Typical software integration is interface-connections (Shaw) and more advanced plug-and-socket systems

18

that insure the interactions are correct and protocols are followed. However, intelligent machines may need architectures that support a further type of integration called arbitraiton. Some architectures specify a single arbitration mechanism. Thus arbitration mechanism are ways of achieving high-level integration in a system, but other types of integration must be supported as well. Viewed as a whole, the intelligent control software operates by selecting actions for the robot actuators to achieve tasks and goals. Maes describes this as the action selection problem [59] for intelligent agents. Identifying the action selection problem places the focus on building software that provides resources and mechanisms for action selection. The connector used in any one approach and may vary in its properties, but action selection, or action arbitration, is the bottom line for intelligent activity. Given a set of inputs, arbitration uses some properties of those inputs to produce an effective output. Selection of an input is one class of mechanism for arbitration, while combination of inputs is a different class. Some mechanism is also needed to provide a set of alternative actions to feed into this action selection process. This is where other types of connectors are used. Arbitration is not limited to computing physical outputs of a system. It can be applied at various levels within the software to manage resources for action selection (sensor action arbitration), allocate resources to goals (task/goal arbitration), and control actuators (motor action arbitration). Figure 1, adapted from Bagchi [9], shows a generalized picture of a software system for an intelligent machine. The boxes in the diagram are intended to describe what happens in the system at a conceptual level and do not indicate a particular software structure per se. The idea of the figure is to show that some 19

elements of the software (Motor Action Agency and Sensor Action Agency) are involved in building varying levels of abstraction for the use of closed loop processes at various levels (Skill/Behavior Agnecy). While other elements of the software are involved in sequencing or goal directed control (Task Agency). These high-level, goal-directed elements of the software rely on the abstractions provided by lower level components. There is also the possibility that some elements of the software are involved in modeling the environment, and capturing the current context in a form that is useful for action. Many reviewed architectures provide some form of these elements, but few architectures investigate building the functionality of each of these elements from an object-oriented or agent-based perspective. Arbitration mechanisms form an important element of intelligent system behavior. They enable a software system to handle new types of connections where multiple paths from sensors to actuators come together and combine various sources of influence. In the sensory processing for an intelligent service robot, action selection relates to sensor fusion. For example, sensor fusion combines sensor data into logical sensors, much like those developed by Luo [58], to be used by other modules. Intelligent motion control can use arbitration to combine influences on motion (goal points, obstacles) to yield an overall path that simultaneously meets several goals for the robot, similar to motor schema used by Arkin [5]. For planning and sequencing, an arbitration mechanism may be used to predict or activate a sequence of operations as shown by Bagchi [9]. The action selection or arbitration mechanism is pervasive in the design of intelligent control software and many reviewed architectures focus on the development of a single arbitration mechanism that serves as the connector for combining components in the software system. 20

Figure 1. Action Selection Problem The flexibility and power of an architecture depends on the types of arbitration mechanisms it supports. Rigid architectures typically allow only a single mechanism, while more flexible architectures combine several arbitration mechanisms at different points in the system. The architecture developed in this dissertation supports an open set of arbitration mechanisms that can grow with the rest of the software system.

Robot Software Architectures Intelligent robots need an explicit software architecture to manage the complexity of developing the many modules and components required for intelligent behavior. Robotics researchers need an approach that allows them to apply new techniques, algorithms, and mechanisms to build integrated systems. Providing the resources and mechanisms that generate intelligent behavior on a robot can be 21

viewed as a complex system integration problem. One way to manage the complexity of development is to adopt a software architecture that specifies possible components and connections. The architecture specifies a system decomposition that divides the system into simpler elements and provides integration mechanisms for combining the simpler elements into the whole control system. Inherent in this integration is a kind of action selection or arbitration process. What follows is a review of architectures, each of which provides its own solutions to the architecture problem and a discussion of various architectural features.

Knowledge-Based Architectures Both the State Operator and Result (SOAR) architecture by Laird and Newell [54, 55] and the Adaptive Control of Thought (ACT*) approach of Anderson [4] are examples of knowledge-based approaches to the intelligent systems problem. Some authors call them deliberative because the declarative representation used requires application or “deliberation” in order to generate actions. This process is usually based on the evaluation of a knowledge base expressed in logic or a search process [11] with heuristic evaluation of alternative situations (situation calculus) [77]. The resources, tasks, and goals in the system are all represented as knowledge, usually defined in the form of a logical language or production rules. The focus of these approaches is the pursuit of explicitly represented goals and the aquisition, manipulation, and application of “knowledge.” When a sufficiently restricted environment is used, these architectures excel by applying their knowledge of that environment. The essential limitation of such architectures is that they are prescriptive in nature. Every element and action must be prescribed and defined by a

22

formal set of rules. The robot must maintain a formal model of its world in order to act within that world. Most approaches in knowledge-based architectures are based on the physical symbol system hypothesis described by Rich [73]. Given an appropriate world model, these systems can solve intricate problems. The success of these architectures in reasoning problems like games has given them the reputation as the best path toward general intelligence. To be useful for robots the A.I techniques must be embedded in an architecture for the agent, and due to the monolithic nature of the representation used in traditional approaches, a centralized “intelligent agent structure” was devised using the sense, model, plan, act (SMPA) loop shown in Figure 2. This approach has been used to build the control systems for robots like Shakey [?] and has been extended to include notions from utility theory [77, 11]. These extensions resulted in a new architecture in which to apply A.I. techniques called the utility-based agent approach, shown in Figure 3. Although it incorporates a kind of soft value judgment (utility), this new approach is also essentially monolithic in structure and serial in processing. The important aspect to note is that the A.I. reasoning methods are a single mechanism for selection of action and the architecture is the structure that supports the use of this mechanism as a robot (or other) system controller. The A.I. mechanism is very complex, but the architecture of the software is essentially a single, serial data flow diagram. There have been recent developments of a new type of model for knowledgebased agents. This model was influenced by philosophical contributions of Dennett [29] and his psychology of the intentional stance. The concept is that some systems are most easily described in terms of beliefs, desires, and intentions (BDI), 23

Figure 2. SMPA Approach [17]

Figure 3. Utility-Based Agent [11]

24

which are separate parts of the agent. Researchers on multi-agent systems have picked up this concept, and several BDI architectures have been implemented with some success. Belief is typically implemented as a traditional knowledge base of the agent. Desires are explicit representations of goals or goal-states that need not be realizable or consistent with the rest of the knowledge base. Some desires are selected to be goals for the agent, and plans are developed to achieve these goals. Intentions are usually a set of partially instantiated plans associated with a set of goals that the agent has developed to achieve its desires. The BDI architecture is primarily a conceptual framework in which various traditional AI techniques are employed to build an agent [42]. In this respect it resembles the utility-based agent [77] used as a model for more recent AI systems. The “desires” of a utilitybased agent are implicitly represented by the utility function, but BDI agents explicitly represent their desires using the same language as the agent knowledge base. Extensive work has been invested in developing a formal model for this type of agent. Most models in this category rely on the use of modal branching-time logic [92] to describe the interactions between agents and the interactions between belief, desire, and intentions, while others use more easily managed state machines to model the interaction between agents [25]. This line of research is interesting because of its relationship to the philosophical concepts about cognitive science that are borrowed from Dennett. The intentional stance was co-opted for the design of systems, but the multiple-drafts concept was completely ignored, although it was introduced in the same body of work. This could be because of the desire to make the BDI concept fit neatly into the rigid and serial structure of more traditional AI approaches. 25

Rao [72] introduces a variation of the BDI architecture by showing the development of AgentSpeak(L), an agent communication language that supports communication between agents that are based on reasoning mechanisms. Mayfield [62] evaluates another agent communication language called the Knowledge Manipulation and Query Language, which is part of a suite of languages developed to support knowledge-based, multi-agent software systems. Both of these architectures base communication on speech-act theory. This architecture, developed by Muller [67], borrows from the BDI line of development and builds up a three layered architecture with behaviors on the bottom, a local knowledge-based system in the middle, and a social knowledge-based system at the top to control coordination between multiple agents as shown in Figure 4. The InteRRap architecture was simulated and then tested on a small group of miniature robotic forklifts. Each robotic forklift was represented by an InteRRap agent, and they all cooperated to perform tasks in a simulated loading dock environment. Another development in multi-agent systems is the emerging research area of Agent-Oriented programming. The premise of this work is that the intentional stance is naturally used by developers when speaking about software, so software development tools and environments should support specification of programs in terms of the intentional stance. This typically involves specifying a software system as a set of knowledge based agents that communicate using an agent communication language. The first such system is AGENT0 [82], where the agents were simple rule systems, but AGENT0 has been extended by the development of PLACA [90], where each agent is endowed with a symbolic planning mechanism as well. 26

Figure 4. InteRRap Architecture [67]

27

Behavior-Based Architectures Behavior-Based AI is a relatively new approach to intelligent control of robots that has more in common with cybernetics than with classical AI. It was initially developed as an example to contrast with systems that prevailed in classical artificial intelligence practice at the time. Common features in all behavior-based approaches are that the system is decomposed into behaviors, which are self-contained control mechanisms for a robot, and the output commands from the modules are combined through some arbitration mechanism to produce the resulting externally observable behavior of some physically situated robot. This approach frees the designer from the need for an explicit representation of the world within a robot. Early successes in this field have caused a reorganization of robotic architecture development, and the once discounted reactive control mechanism has been re-evaluated and used successfully on real robots in complex environments by Brooks [18], Gomi [44, 43], and Ferrell [34]. The emergence of behavior-based approaches to AI that draw extensively from biology and ethology has changed the landscape of intelligent systems architecture. Subsumption by Brooks [17, 19], Motor Schema by Arkin [5], and the Distributed Architecture for Mobile Navigation by Rosenblatt [75] are a few examples of architectures that combine many sources of behavior into an intelligent-acting system. These architectures depart totally from the concept of combining “knowledge,” which is fraught with problems of representation and search, and instead combine the output of several behavior sources into the resulting externally observable behavior of a robot. The arbitration mechanism for combining the behavior varies

28

Figure 5. Behavior-Based Approach [17] in each case, but the principle is the same. Figure 2 shows a traditional serial approach to robot control that includes the sense, model, plan, and act loop (SMPA). Figure 5 shows the more parallel behavior-based approach. Each behavior includes only enough modeling and processing to handle its purpose, as opposed to the SMPA approach where the sensor data must be converted into a world model before a decision can be made about acting. Recently, the development of behavior-based architectures has included more sophisticated mechanisms for action selection, especially by Maes [59], who developed fully distributed arbitration, and by Blumberg [13], who added the concept of hierarchical composition of behavior sources. These architectures are a great advance over the initial subsumption architecture that was based on an extremely minimalist view of cognition and provided an intentionally over simplified architectural connection mechanism. Very recent developments in this line of robot architecture are presented by 29

Colombetti [24]. His approach combines more formal behavior modeling with behavior system synthesis and on-line learning of behavior. Colombetti also applies behavior-based controllers to domains not traditionally investigated by behaviorbased AI, such as robot manipulator control. The initial behavioral approaches all possessed a common trait: they focused on a single combination mechanism (subsumption or fixed priority) that combined the outputs of behaviors. Another approach, taken by Maes [59], was called the Agent Network Architecture (ANA), which decomposes a system into behaviors, but the combination mechanism is modeled after goal selection dynamics in animals and is related to utility-theory. Her approach was to build a spreading-activation network that allowed both excitatory and inhibitory links shown in Figure 6. The dynamics of the “activation energy” spreading across the network were used to select the currently active behavior, and that behavior would be a complete competence module that had control over all of the robot’s actuators until the activation spread to another behavior. The activation energy spread is based on the types of links between competence modules: • Successor Links - A competence module that is active spreads activation forward through these links to modules for which it is a kind of “precondition.” • Predecessor Links - A competence module that is not active spreads activation backward through these links to modules that are preconditions for itself. • Conflictor Link - A competence module (executable or not) decreases the 30

Figure 6. Agent Network Architecture [59]

31

activation of modules related to it through these links. Activation is also generated within a competence module when it detects a match between its preconditions and the environment; this allows environmental conditions to affect the patterns of activation on the network. The mathematical model used by Maes is based on a STRIPS [35] model where the environment is described by a set of logical propositions, and each behavior or competence module changes the set of propositions as a result of being activated. Maes provides a mathematical model for the spreading of activation between the nodes in the Agent Network Architecture (ANA) in [60]. Blumberg augmented the behavioral network of Maes with the concept of hierarchical behavior decomposition and behavior interaction [13]. In his model, shown in Figure 7, behaviors represented by the circles are organized into loosely overlapping hierarchies, and at each level in the hierarchy is a group of behaviors in competition for activation energy. Each group is denoted by the boxes surrounding the behavior nodes in the network. The darker nodes have higher levels of activation in the diagram, with the darkest nodes being the current winners at each level. An additional feature of this approach is that the winner on each level takes suggestions from the losers on that level into account when it takes action. Another major improvement in this approach is that the “sub behavior” modules can be reused by the higher level behaviors, and no signle behavior is responsible for all actuation of the physical system. This model of behavioral decomposition is much more practical from an implementation standpoint. The key to this model is that activation spreads both downward and upward in the hierarchy. Activation

32

Figure 7. Blumberg’s Behavioral Architecture [13] that spreads up represents influences of the current state of the lowest levels of the system like sensors and actuators, while activation that spreads down comes from the top level behaviors and can represent goals of the behavior system. Thus, the dynamic spreading of activation results in a goal- and state-directed selection of which behaviors to activate. Blumberg uses a spreading activation mechanism similar to the one developed by Maes to activate behaviors. Blumberg considers several influences on activation including releasing mechanisms (rmit ), internal variables computed by each behavior (ivit ), links to other behaviors (vmt ), and level of interest in a behavior (liit ). The activation of each behavior in the network (vit ) is computed using the equations below, and the resulting activation is used to determine which behaviors in a behavior group are activated (shown as darker colors in Figure 7):

33





vit = M ax liit · Combine 



rmki ,





ivjt  −





nmi · vmt  , 0

(1)

m

j

k



where vit is the activation value of behavior i at time t; liit is the level of interest, and rmkt and ivjt are the values of the releasing mechanism and internal behavior variables. The term (nmi ) is a weight of connection between other behaviors in the group. Combine is a function used to convert these parameters into a single activation value for the behavior. Internal variables are updated using the following equations: ivit = (ivi(t−1) · dampi ) + growthi −



ef f ectskit

(2)

k

ef f ectskit = (modif yGainki · vk(t−1) )

(3)

Levels of interest for behavior and releasing mechanisms are updated using the following equations: liit = Clamp(((lii(t−1) · dampi ) + growthi − (vi(t−1) · bRatei )), 0, 1)

rmit = Clamp(T emporalF ilter(t, rmi(t−1) , F ind(sit , dM ini , dM axi )·

(4)

(5)

F ilter(sit ) · W eight(sit , dOpti )), mini , maxi ) From the software architecture point of view, spreading activation represents a very unusual way to coordinate processing modules in the system. There is no central locus of control, and decisions are made locally by each module. The communication between modules is extremely simple and low bandwidth; the connector for spreading activation is like the software realization of a single signal 34

carrying wire between agents with little or no semantic content. Nevertheless, these approaches provide a viable alternative to traditional architectural connections between software modules that are potentially less fragile to evolution of the system. AuRA [6] is a highly practical hybrid approach to robot control that focuses on the mechanism for motor command combination. The mechanism for combining motor commands is called motion schema and is inspired by biological models of motor control. This architecture allows motion commands from a wide variety of sources to contribute to robot motor control. The expressive power of motor schemas for movement control is key to the AuRA architecture shown in Figure 8. Motion schema are like reactive commands or reactive programs, and the schema manager arbitrates between the active schema to compute the resulting command using a weighted summation. Deliberative and reactive influences are combined in AuRA by combining the resulting influences at the schema level. The original motor schema could be interpreted in terms of a two-dimensional vector field that influences robot motion shown in Figure 9. Motor schema are of several varieties: • Goal Attractor - Field points toward goal at every point. • Obstacle Repulsor - Field points away from obstacle in region around the obstacle. • Direction - Field is uniform at all points. • Path Region - Field points toward a bounded region. • Noise - Field is random at all points (Helps to avoid local minima). 35

Figure 8. AuRA Architecture [6]

Figure 9. Motion Schema Concept from Arkin [6]

36

The overall influence of the schema contributions on robot motion is computed as a kind of weighted sum of forces of active schema, where k ranges over the activated schema, Fkschema is the contribution of schema k, and Wkschema is the relative weight of schema k:

Ftotal =

k

Fkschema · Wkschema

schema k Wk

(6)

Then this total force is converted to a velocity command for the robot through a simplified damping model for each robot axis j, where Fjtotal is the component of Ftotal along actuator axis j (from Cameron [22]): Vjdesired

Fjtotal = dampingj

(7)

Most of the other components in the AuRA system exist to contribute schema based on deliberative processing or reactive rules. Motor schema were recently extended by Cameron [22] to handle more degrees of freedom by assigning a pseudoforce interpretation of the schema contributions. The schema concept was generalized from the original two-dimensional vector field to a full six-dimensional (both position and orientation) force field. These enhancements allow the schema arbitration mechanism to be used to combine contributions for a multi-axis system, such as a mobile robot with a manipulator, by propagation of pseudo-forces along the axes of the robot in a manner similar to the Newton-Euler dynamics equations in Craig [27].

Hybrid Architectures The success of reactive behavior-based systems prompted several groups to adopt a hybrid approach that combines reactive mechanisms with more traditional 37

knowledge-based approaches, such as the work on integrating world knowledge with reactivity in (AuRA) [5, 6]. Others developed the concept of using planning as a resource for action selection instead of the mechanism of action selection [1]. Another approach is to have a reactive action selection mechanism and provide it with a “future sensor” that looks ahead and contributes to the current action. These approaches highlight the fact that previous developments in planning, modeling, and search have a distinct place as predictors and resources that contribute to the action selection process for intelligent robots. Many of the hybrid architectures are examples of the layered system design pattern [21] applied at the system level, where each layer provides an abstraction for the next higher layer based on resources in a lower layer. The RCS architecture evolved through many stages, and unlike many of the following “hybrid” architectures that are attempts to attach a behavior-based subsystem to an existing, centralized artificial intelligence system, RCS-1 began as essentially a behavior-based control system. The current version of RCS, called RCS-4, is based on a hierarchy of computation and organization. The implementation of the resulting systems takes the form of a layered system as described above with a fixed, overall structure for each layer. In addition, the design stipulates that all modules of all layers of the system are attached to a central knowledge database that contains information to support the world-model-based portions of each layer in the system. A layer from RCS-4 is depicted in Figure 10. Each layer includes a sensory processor (SP), a world modeler (WM), a behavior generator (BG) and a value judgment (VJ) module. These elements correspond

38

Figure 10. RCS Layer [2] roughly to the components of the utility-based agent described eariler in this review. Sensory processing, world modeling, and behavior generation all share access to the knowledge database and to operator interfaces. The architecture describes the layering of these blocks in a time-based hierarchy of computation with the servo layer on the bottom, followed by the primitive layer, elementary move layer, task layer, etc., each with larger scope in time. This architecture is a very extensive example of the layered system design pattern combined with the concept that each layer is an intelligent sub-system. The assumption of uniform access to a large, shared knowledge database and operator interfaces weakens the usefulness of this approach as a method for building a distributed system. The notions of concurrency in this approach are based on strict top-down hierarchical control and progressive abstraction by the layers. A similar architecture is the Grounded Layered Architecture for Intelligent Robots (GLAIR) developed by Hexmoor [48, 47], shown in Figure 11. It divides

39

the systen into three levels, but at the bottom level the communication is similar to that used by CIRCA. Reactive Action Packages (RAP) developed by Firby [36, 37] embody a philosophy similar to GLAIR and CIRCA. Each RAP is a reactive subprogram, instantiated by a higher level reasoning mechanism. The power of these architectures is that there is a higher-level monitor for the behavior-based levels of the system, and there is usually an accompanying specification of behaviors in terms of pre-conditions, post-conditions, conflicts, and required collaborators that provides a way for the higher level system to activate a “good” set of behaviors. One way to view these approaches is that they are essentially methods of automatically programming behavior-based systems. All action (observable behavior) of the robot comes from the behavior-based layers of these systems, and the only purpose of the higher levels is to “turn on and tune” the appropriate set of behavior mechanisms to achieve certain goals. Another example of the programmable reactive system is CIRCA, developed by Musliner [68]. This approach is focused on real-time issues and is shown in Figure 12. CIRCA consists of a reactive mechanism controlled by executing a schedule of primitive programs created by the deliberative mechanism and scheduled based on knowledge of real-time deadlines and execution times of actions. These primitive programs are called test-action pairs or TAPs and represent the reactive program used by the reactive component of CIRCA to control its actions. CIRCA also describes the concept of anytime algorithms, which are iterative improvement search algorithms that can be run as a part of a real-time system and have the execution system specify how much time will be spent on a solution where the quality of the solution depends on the time allotted to the algorithm. CIRCA 40

Figure 11. GLAIR Architecture [48]

41

Figure 12. CIRCA Architecture [68] depends heavily on explicit modeling of the robot software and environment. It uses its own knowledge of the performance of software modules to generate TAP schedules to meet hard real-time deadlines for response. However, it is limited by reliance on a primitive world model that may be hard to maintain and extend and was tested on a single processor system without a real-time operating system to actually enforce its guaranteed response times. CIRCA models the world (and the controlled robot) as a set of discrete states that are reached through transitions (like a finite state machine). These transitions represent actions of the agent (action transitions), changes in the world (event transitions), and passage of time (temporal transitions). Unlike many state machine approaches, a transition includes a model of time. Each action of the robot that causes a world state change may have a finite time duration, and this time model is used to schedule TAPs for the real-time subsystem that meet rigorus real-time constraints. One problem for the AI subsystem is the discrete set of world states, each represented by a set of first order predicate calculus clauses.

42

This representation limits what can be effectively used as a world state in the AI subsystem. However, in restricted domains it is possible to build TAP schedules that meet hard real-time deadlines that guarantee a certain level of performance. From a software architecture standpoint the real time component of CIRCA is an instance of the microkernel design pattern for software systems [21], and the interaction between reactive and deliberative components can be viewed in terms of the reflective design pattern [21] as well. The artificial intelligence laboratory at SRI international developed a similar layered approach that is based on building the low-level robot control from a set of behavior schemas, expressed in multivalued (fuzzy) logic [79]. This approach develops a number of interesting techniques for specifying direct control of a mobile robot using fuzzy rules grouped into coherent units called behavior schemas. In turn, the outputs of these behavior schemas are blended together (via a weighting function) by the outputs of fuzzy rules used to detect context. The technique is called context dependent blending of behavior schemas. In addition to this reactive control system, their architecture uses a traditional planning system to build up sets of behavior schemas and assign the blending rules, so it is also a kind of automatic programming in the spirit of CIRCA and other hybrid, layered architectures.

Multi-Agent Architectures “Agent”, is employed to an extremely wide variety of things in the literature.

43

However, there are a few distinct architectural uses of the term. In objectoriented system modeling [76] and distributed A.I. [78], the word describes an independent software module within a system that interacts with other independent software modules to solve some problem. Some approaches use multiple agents (multi-agent approaches) as the overall system organization, while others create a microcosm of classical AI within a set of agents where each agent senses, models, plans, and executes using a formal reasoning mechanism. Software agents are linked directly through message-based communication as in MIX [49] or by blackboards (described below). Each agent can be an expert in its own domain and work with others to cover a larger domain. These architectures suffer from some of the same problems as traditional AI because of the need to represent the world explicitly using a physical symbol system. There is a tacit assumption that some universal meaning exists which enables any agent to communicate with other agents in any type of relationship. This means that agents share semantics. While it may be possible to develop such a language, it may not be efficient for simple relationships or too verbose and cumbersome for complex relationships. The Knowledge Query and Manipulation Language (KQML) and the Knowledge Interchange Format (KIF) are two developments along this line and are described in the context of intelligent agents by Mayfield [62] and by Wooldridge [93]. These languages allow intelligent knowledge-based agents to interact using speech acts. Essentially, speech acts are forms of communication that are represented as structured message passing between modules. The concept of using interacting networks of “agents” or components to control

44

an intelligent system comes from distributed AI [78, 31]. One sketch of this multiagent intelligent system is found in Minsky’s Society of Mind [65], which suggests the concept of an agent as a distinct unit of system organization as well as the composition of agents into agencies using very simple connections. One appeal of this approach is that it maps well to multiprocessor computational architectures for implementation. Based on this sketch, Lim [57] developed an approach for agent-based programming of mobile robots that did not rely on blackboard communication. Agents communicate by passing messages to a set of ports on other agents and each agent processes messages as they arrive at its ports. There is little structuring of the messages in this architecture so the representations used for communication may become harder to manage as the system grows. However, the ability to hierarchically compose software modules is quite powerful in this architecture. This power comes from the fact that it is essentially an instance of the pipes and filters design pattern [23]. A network of software modules connected using a blackboard was developed by Bagchi [10] for the ISAC 2 system. This system is depicted in Figure ??. Some of the software modules in this system represent functional aspects of the system, while others are more encapsulated, like the arm module which captures a software model of the robot arm itself. This software system was successfully used to develop demonstrations of an intelligent service robot system. Although it provided very flexible operation, the blackboard caused problems because of its centralized role in nearly all communications between modules. Furthermore, the interaction between modules was essentially ad hoc and had no formal language. Over time the complexity of the system grew such that the blackboard language 45

Figure 13. ISAC 2 System [10] itself was a major limitation to development progress. Suehiro [86, 87] describes one attempt to implement a society of Minsky-type agents to control a robot system. His work points out the limitations of current software design in terms of interfaces between modules. Many systems have semantic links, which imply a shared understanding between linked modules to properly interpret signals on those links (like the blackboard language of ISAC2 above). However, other non-semantic (or analogical) links may be built between software modules that work more like the links in neural networks. Thus, each module observes patterns of activation on its inputs and produces patterns of activation on its outputs based on internal computation and internal state. This is illustrated by 46

Figure 14. Suehiro’s Agent Network [87] Figure 14. However, there are no explicit “messages in a language” sent between two agents. Some hybrid approaches combine many complex features, like the multipleblackboard approach described by Beyer and Smieja [12, 84]. This approach resulted in the JANUS architecture, which represents the control system for a robot as a society of agents. This architecture is shown in Figure 15. One unique feature of JANUS is the use of components called reagents, which stands for reflective agents. These reflective agents contribute knowledge and commands to their connected blackboards but also include a confidence measure with each contribution. The reflective agent has a self-evaluation mechanism that allows it to adapt its

47

Figure 15. JANUS Architecture [12] confidence levels. The reflective agent combined with the multiple-blackboard architecture allows each agent to be an expert in a specific area and show this to other agents through confidence measures associated with each contribution. By allowing agents to connect to two blackboards, agents may function as a general map of one “blackboard space” to another.

48

Architecture ANA Subsumption CIRCA JANUS InteRRap AuRA SMPA ISAC2 MIX IMA

Components Competence Modules Behaviors Knowledge, Reactive Reagents Behavior, Local and Social Knowledge, Reactive Knowledge Agents Agents Agents

Integration Spreading Activation Suppression Automatic Programming Free Form (Blackboard) Hierarchical Control Automatic Programming Reasoning Free Form (Blackboard) Knowledge Exchange (Speech Acts) Multiple Agent Relationships

TABLE 1 Summary of Architectural Properties Discussion of Issues From the preceeding review if can be seen that descriptions of intelligent machine software systems from the literature frequently involve software architecture and frequently describe their architecture in very informal terms. Some of the reviewed systems, principally knowledge based approaches, describe software architectures with a goal of using a fixed set of software modules and connections to which knowledge is added that will control a robot. Other approaches, notably behavior-based approaches, have the view of the software system gaining new structure as it is developed over time. Hybrid approaches are frequently divided into two parts. The knowledge based part is designed to automatically program the behavior based part in some way. Below, Table 1 shows a selected group of architectures, their primary components and methods for integration. Figure ?? is an attempt to map out many of the reviewed architectures in terms of their derivation, influences from other fields, and basic decomposition method.

49

Figure 16. Map of Robot Architectures

50

CHAPTER III OVERVIEW OF THE INTELLIGENT MACHINE ARCHITECTURE The power of intelligence stems from our vast diversity, not from any single, perfect principle. Eventually, very few of our actions and decisions come to depend on any single mechanism. Instead, they emerge from conflicts and negotiations among societies of processes that constantly challenge one another. - Marvin Minsky

Introduction The Intelligent Machine Architecture (IMA) [71, 50] uses a two levels of abstraction to describe the software system for an intelligent machine. The high level model is called the robot-environment model. This model describes the software system in terms of a group of software agentsconected by a set of relatioships. This agent-based decomposition helps developers manage the inherent complexity of system integration for intelligent robots by emphasizing strong encapsulation and reusability and by capturing interactions between system components with an explicit representation of connections. The concepts used for this agent-based decomposition are inspired by Minsky’s Society of Mind [65]. The architecture also includes an implementation level model that describes each of the agents and relationships in the high-level model as a network of software modules called component objects. This level is called the agent-object model. A software system built under the IMA is a system of concurrently executing software agents, formed

51

from reusable component objects, that use the computational, sensory and actuator resources to perform the tasks for an intelligent machine, such as a service robot. At the same time this network can be seen to describe a kind of model of the robot and environment and therefore is called the robot-environment model. Each relationship between agents encapsulates and manages the protocol of communication and usually involves an arbitration mechanism that governs the interaction between participants. This two-level architecture addresses software engineering issues such as reuse, extensibility, and management of complexity, as well as system engineering issues like parallelism, scalability, reactivity, and robustness. The IMA draws on ideas from many modern robot software architectures including the Subsumption Architecture [19], AuRA [6], CIRCA [68], GLAIR [48], and others and represents the synthesis of many ideas from these systems and from software architecture research [81, 88] into an pattern for the development of software subsystems of intelligent machines. The basic elements of our agent-based system architecture are agents and relationships. The agent-based system forms a model and controller of the robot system, which is implemented by a lower-level, explicit software model used to manage development and software reuse. Thus, there are two modeling levels in the intelligent machine architecture: the robot-environment modeling level and the agent-object modeling level. The robot-environment modeling level describes the robot as a set of resource, skill, behavior, task, and environmental agents that are dynamically connected by a set of relationships. The agent is modeled as a concurrent decision or computation process that is fed input representations and modifies output representations through relationship protocols. The agent-object 52

level supports the assembly of these agents through combining many reusable subcomponents (state, policy, and mechanism ) and their parameters. In addition, these sub-components can be customized with developer-supplied changes using the code framework. Our architecture uses two levels of modeling to minimize dependence on particular internal representations. Thus, a particular model of a particular task or type of robot is not a part of the architecture; it is part of an application developed within the architecture. We also employ modeling of each agent as an individual, independent software system to facilitate component reuse in our development process and provide the potential for tools to be developed to automatically modify system structure and generate new agents. In continunally improved systems, such as a research service robots, it can be impossible to formally validate the design of the system. Validation can be expensive in terms of development time so it is proposed that at the architectural level, monitoring should be used to ensure proper operation. Monitoring introduces little overhead and is robust to rapid development of the system. The monitoring properties need to be specified only once, and if testing of the system yields monitoring errors, then developers have a detailed error log to guide improvements. Monitoring is also applicable to environments where there is run-time adaptation and reconfiguration, whereas using formal verification in an evolving system may be costly in terms of performance. It is interesting to note that robustness of operation to environmental changes is also closely related to robustness of the robot software to evolutionary design. The loosely coupled network of agents is insensitive to changes in the software implementation because the level model of the system controls the overall structure 53

but makes fewer commitments about specific mechanisms or algorithms used to evaluate intputs and compute outputs. The high level model provides a shell around the implementation level model that isolates the integration of the system from changes and improvements within a single agent. The isolation between these models also allows individual agents to select and use different mechanisms as the environment changes, but still keep the overall structure of the software system intact. The IMA supports the construction, reuse, and configuration of networked agent systems that capture the robot and its environment. Encapsulation scope at runtime is not the same as encapsulation scope at design/configuration time. For example, modules of nearly any type may be incorporated, and multiple composition mechanisms (aspects) can be described at run-time and at design time. At run-time the dynamic configurability provides a degree of fault-tolerance while allowing an iterative, experimental development style that is advantageous for exploratory software system development [19]. A diagram of related development processes using IMA is shown in Figure 17. Each agent is based on a single element of the domain-level system description and tightly encapsulates all aspects of that element, much like the concept of object in object-oriented systems. The agent serves as a scaffolding for everything the software system knows or does relating to an element of the robot, tasks or environment. For example, Figure 18 shows that IMA agents are built to represent the physical resources of the robot (e.g., Arms, Pan-Tilt Head, Image Capture, Sound Capture, Speech I/O, Sonar, Lidar, etc.) as well as behaviors (e.g., Avoid Collisions, Coordinate Movements, Emergency Reflexes), skills (e.g., 54

Figure 17. IMA Development Process

55

Visual Tracking, Grasping, Visual Servoing), and tasks (e.g., Feed Soup, Find Object, Assemble Parts). However, the model of the environment is also developed as a set of agents that share the robot’s physical resources (e.g., Bowls, Blocks, Parts, Walls, Places, Forks, Collections) and engage in a process of anchoring [79] to keep their state coherent with the world as experienced by the robot’s sensor resources. Any system that captures elements of the environment in a model would engage in such a process, and the environment agents in IMA are a distributed, parallel embodiment of that process of “actively modeling” the environment. Another software agent represents the user of the system. This user agent uses the resources of the robot to estimate the state of the user and represents what the system knows about the user. One feature of this loosely coupled system design is that the agent-based decomposition facilitates parallel processing and can take advantage of both distributed and SMP computer systems more effectively than monolithic architectures to handle larger systems, if communication is controlled properly. Finally, each agent acts locally based on internal state and provides a set of services to other agents through various relationships.

Robot-Environment Model In the terms used by Rumbaugh [76], IMA agents are like actors (they use other agents as resources, have a thread of execution) and servers (they provide resources for other agents as well). The agent-based decomposition of the system is a generic idea; however, the robotics domain suggests a classification scheme for IMA agents that conceptually divides the system into several rough layers based on the types of relationships they support and what they model in the system.

56

Figure 18. Correspondence of IMA Agents to System-Level Entities In a relationship between agents, one agent provides another agent with resources for action. This model of action and communication requires a different view of system design and is more loosely coupled than traditional software approaches. One justification for this tradeoff is the time value of information in robotic systems. Unless some information in the software system can become a resource for action, it rapidly becomes useless for the robot to retain, process, or evaluate the information.

Agents An Agent within the IMA approach is assumed to have certain properties that separate it from the typical uses of the term “Agent” and focus on what is essential to being an agent. Some authors stipulate that agents must be able to

57

reason, hold explicitly represented beliefs, and maximize utility [92, 72, 38], but that is not essential to the usefulness of the agent concept as an abstraction for the development of software systems [8, 69, 61]. • Autonomy - Agents own their sub-components. They are separate and distinct concepts in the domain for which the software is written. Thus, they have an inside and an outside that are necessary for strong conceptual encapsulation at the system level and support interaction through well-defined ports called relationships and links. An agent might be viewed as an active subsystem in the overall software system. • Proactivity - Agents act locally, based on their own internal state, resources, and observations of other agents through specific relationships. The core of the agent’s operation is a decision or action selection process that may take the form of a state machine or other computational process that maps inputs and local state to updates of outputs. • Reactivity - Agents are reactive because they respond to changes in their external environment. The agent operates in a continual loop, checking conditions, running computations, and updating outputs, so changes are detected and appropriate actions can be selected. • Connectivity - Agents are connected to each other because they model only a single concept and need services provided by other agents to make a complete system. The connections between agents can be simple data flows, or more complex relationships. Complex connections support arbitration between connected agents and are used to model interactions that communicate 58

commands or internal state values from other agents. • Resource Limits - Any real system is resource limited, however there needs to be some way to express this in the software system that allows the software system to adjust operation based on resource usage. Therefore relationships between agents have several aspects. The primary aspects deal with communicating information between the agents, while other aspects associate some state of the agent with resources. These other aspects can form the input for an arbitration process that selectively updates or incorporates information of other agents in the relationship, thus respecting resource limits during interaction. Internally, an agent’s action selection process can use an element of the agent’s state to vary it’s choice of computations to consume more or less computational resources. Another important aspect of IMA is the loosely coupled, asynchronous operation of the agents in the system. By using the abstraction of asynchronous, decision-making agents, it is possible to simplify the system model at a high level. There is often a great temptation to over-specify the higher levels of a system that lead to very brittle operation. The collection of asynchronously executing agents provides an abstraction that eliminates many concerns about synchronization, because the architecture provides each agent with a knowledge of time that allows each local decision process to evaluate information based on its age relative to that agent. The agents in IMA work much more like a group of control loops, that traditional software systems; continually sampling inputs, updating states and computing new outputs.

59

Relationships One novel aspect of IMA is the explicit use of a set of architectural connectors called agent relationships. These relationships capture interaction between agents that includes both typical software interactions (like function signatures, sequences of method calls, etc.) as well as less structured interactions (like spreading activation, or motion schema for example). By building a system from these multiaspect connectors, it is possible to combine reusable resource limiting mechanisms and take advantage of the use of more explicit interaction as well. The relationships between agents are implemented as sets of reusable component objects that are aggregated within a controlling agent, allowing that agent to participate in a given relationship. This allows each relationship to be implemented once and be configured and reused throughout the network of agents. An IMA relationship supports structured communication between the participants in that relationship and usually provides an arbitration mechanism that is suited to the particular relationship. The idea of relationship in IMA is that it is a high-level connector between the high level components of the software system. In previous architectures for robots, many designs have offered only a single connector type (e.g., Signal Subsumption in the Subsumption Architecture or Spreading Activation in the Agent Network Architecture). Some examples of complex relationships and the associated arbitration mechanisms are as follows: • Actuator Arbitration - Pseudo impedance models, extension of Cameron [22, 69].

60

• Sensory Arbitration - Voting schemes, activation maps, consensus mechanisms as in Luo [58]. • Goal Arbitration - Spreading activation from Bagchi [9] and Maes [59]. • Context Arbitration - Spreading activation from Anderson [4]. In IMA, the agent is a container for services that shields the overall system from changes in the implementations and mechanisms that make up the services provided. By splitting the overall design into two levels, it is possible to evolve one level (improve the algorithms and mechanisms within an agent) without affecting the other level (overall agent network). It is also possible to add new connectors (relationships) to the architecture within minimal impact on older parts of the system.

Agent-Object Model The IMA Agent is a concurrently executing, potentially goal-seeking software component that is equipped with links to other agents, called relationships. Each agent contains at least one thread of execution, a set of relationships to other agents, and perhaps access to hardware of the system. The agent also contains a number of representations that are used for internal computation or to denote the state of a relationship to other agents. In general the agent is an autonomus decision-making software module. It takes all of the accumulated state that is available internally and locally (from relationships and other links) and makes a decision to perform certain actions based on this locally available information. These actions can include hardware output (if the agent is connected to hardware),

61

computation, or communication with other agents. What follows is an introduction to the model of an IMA Agent itself. This is the model used to build agents from reusable component obejcts. This model permits explicit representation of software configuration and on-line modification of the agent system and individual agents. The IMA divides the model of robot control software into four components that capture four primary aspects of the agent system design problem: • Agents - Concurrency, scoping, and decision-making; decision objects. • Relationships - Interaction protocols, connection ports; protocol objects. • Representations - Communication, complex information, encapsulation; state objects. • Activities and Actions - Algorithms, computations, decision processes; functional objects. The agent model also relies on reusable sets of component-objects to facilitate growth of the system over time. By building software using this model, developers of the system focus on modeling distinct concepts and providing services relevant to the robot control system instead of becoming the “algorithm in a box” that is typical of many functional-modular software systemss. The IMA uses algorithms, representaitons, and links between agents as component-objects within each agent, and each of these elements can be reused in many agents, in varied configurations or for completely different purposes at the same time. For example, a new object classification algorithm is developed as a component object. Then, by editing a few 62

decision rules in each agent, this new method for recognition can be used by many different elements of the system. No new “module” must be built and interfaced to the system to provide this algorithmic service; the integration happens at a much finer-grained level that is conceptually appropriate in the context of the evolving robot control system. As shown in Figure 19, agents are built from a standard set of components that follow current design patterns for object-oriented system design, including: • Agent Manager - Provides the scaffolding on which other pieces of the agent are built, as well as features such as persistence. This element also provides a meta-level interface through which another agent can inspect its own composition and perhaps alter it if necessary. This feature is currently intended to be used to support on-line interactive tools for agent construction and tuning, but it could be used in other ways. • Agent Engine and Activities - The engine provides the central action selection process for an individual agent and invokes other agent components. Activities are other, concurrent processes within the agent. These can be used as background processing or to separate deliberative processes and reactive processes within an agent to assign different priority levels. The engine and other activities are based on a concurrent finite state machine model [46]. Like any other part of an agent, The engine and activities are replaceable components that can be upgraded or altered to address the needs of specific agents within a growing system. The current engine can support a hierarchical state machine for agent action selection.

63

• Agent Representations - These components are a kind of generalized production for the agent that includes the evaluation of agent components, as well as an invocation mechanism for performing computations, assignments, and state updates. • Agent Resources - These elements of the agents are data repositories, algorithms, tools, and links to the state of other agents. These elements are evaluated, invoked, and updated by the invocation of mechanisms within the agent. Components can be simple or composite component objects. Some components might provide a kind of scratchpad or internal workspace for the decision engine and other components, while other components are algorithmic resources that allow the agent to invoke highly efficient and optimized computations in a particular situation. • Agent Component Managers - These elements are wrappers for the agent components that handle object persistence and provide visual interfaces to the components that are used by developers to build up the agent systems more easily. Component managers also provide a place for knowledge about system properties to be stored. Thus, the component managers can be used to implement design rules to prevent a component from being misused within an agent. This is a kind of metadata about the component. • Relatioship Components - These elements encapsulate the connections between agents in the system. They range from simple data flow to complex multi-way data flows with arbitration mechanisms. The important aspect is

64

that such interactions are encapsulated in a set of components that help isolate agents from changes and details of the implementation of relationships between agents. All intelligent behavior results from the local decision process. The decision process is not merely a condition/response sequence; it may include computation as well. For example, it may utilize a transformation or time-varying mapping with memory. The IMA framework focuses on managing the control state, decision process, and data state for agents by using the agent-object model to describe the composition of the agent in terms of interacting component objects. The interactions at the component object level are specified as method calls on interfaces between components. IMA lets certain aspects of the decision process be encapsulated and reused and totally encapsulates and reuses the framework used to link a set of distributed decision processes. Many of the core operations, such as event times, are benchmarked at run-time, saved with the system state, and are logged to files for each agent. This provides the system designer with a run-time assessment that monitors real-time performance to use in decisions, update computations, updates, and actions. Instead of modeling abstract computation for verification, this architecture benchmarks itself while running and provides monitoring as an alternative.

Code Development Framework The abstract concepts presented in this chapter are intended as a conceptual guide to developing agents in IMA. These concepts encourage developers to think in terms of developing larger-scale, more reusable, elements of the system (IMA 65

Figure 19. IMA Agent Internal Structure

66

Components) instead of plain algorithms or traditional monolithic programs. The abstractions of representation, mechanism, and policy encourage a disciplined and modular style of development that accomodates changes more easily by reducing or eliminating “hidden” interactions between components and forcing these interactions out into explicit consideration. However, an architecture is useless if developers are not encouraged to use it and it does not help them work more rapidly or improve their development process in some way. This is why the development of IMA is accompanied by the development of a code framework (a set of base classes in C++) that reduce the effort needed for developers to follow the constraints of the architecture. These base classes provide a starting point and easy access to the agent-object model from a more traditional programming language. Thus, a base class available for each of the agent components that implements much of the common functionality required: • IMA Component- This is the generic base class for all agent components and provides minimal naming, persistence, and component linking features. • Mechanism- This base class adds the mechanism invocation interface and provides a standardized way to invoke this component as a mechanism. • Representation- This base class adds proxy and source functionality and interfaces that support remote, multicast communication between source and proxy representations. This class encapsulates one method of communication between representations. Additional mechanisms are possible because communication is encapsulated at this level. 67

• Policy- This base class has an active thread scheduled by the underlying operating system. These objects provide sequencing and decision-making for the agent. They invoke various other mechanisms in the agent based on their state and the state of other agent components. • Agent Manager- This class provides a basic implementation of the agent timing service, persistence management, and agent event dispatching for the other components within an agent. It also serves as the bridge between the agent components and the outside world because it handles interactions with the agent locator service and the agent shell. These base-classes are described in further detail in an appendix for those interested in the implementation details and interfaces involved in creating the abstraction of the agent-object model.

68

CHAPTER IV ROBOT-ENVIRONMENT MODEL IN THE IMA Introduction IMA is based on the concept of software as a multi-agent system that models the robot, task, and environment. The multi-agent network controls the robot and is a model for the robot system at the same time. This structure is augmented by a lower-level model for implementing agents from component-object software. Thus, there is an implementation relationship between the distributed agent-level abstraction of the system and the component object network. IMA uses a network of software-agents to represent the control software for a robot system, plus the same network is a model for the robot system and environment. This model is based on object-oriented models that favor strong encapsulation of modeled entities and explicit relationships between modeled entities. IMA supports a kind of self modeling design that reflects the structure of the robot system and environment in the software itself. In even the simplest monolithic robot systems, certain aspects of the robot and environment are reflected in the software structure. However, “models of the environment” are usually treated as passive data that are manipulated by a fixed algorithmic mechanism. It may be useful to go beyond this approach by incorporating ideas from object-oriented modeling that suggest building an agent-based system that enforces strong encapsulation. As the system grows, the model grows as well; each agent may add new information, as well as new methods for dealing with these pieces, to the model, and new relationships may add new interactions

69

to the model. The IMA Robot-Environment model is a model of which particular instances are controllers of a particular robot system. What is gained with this approach is that the resulting systems may be evolved by adding new agents and relationships along with the policies and mechanisms needed to capitalize on the new capability, with less chance of compromising the functioning of the resulting system. The system-level model is a pattern for building an active model of the robot and its environment from entities called agents and relationships. The agent-level model, described in the next chapter, shows how to build agents and relationships from sets of distributed component-objects. The primary elements in the robot-environment model are agents and relationships. These are the “components and connectors” of the architecture at this level of abstraction. These components and connectors will in turn be described by networks of component objects that implement the high-level agent model as a lower-level concurrent, distributed object system.

IMA Agents The agent concept forms the basis for a model of robot software that is flexible in structure and grows over time. An agent in IMA is a software abstraction for some element of the overall robot system. Agents are independent, asynchronously executing software modules that communicate with other such modules using agent relationships. The concept of agent in IMA is also related closely to the concept of object from object-oriented programming. Agents represent independent loci of computation and decision in the system and may have access to hardware interfaces of the robot.

70

Intelligent Service Robot Domain Agents A classifiation of IMA agents is described by Figure 20, which shows how one level of the agent network depends on lower levels of the network, like the rings in an operating system. The following classification scheme is intended to show how an agent network might be used to model a robot system and is not a specific “rule” of IMA design. However, IMA was designed with the intent of supporting implementation of agent systems as described below. It is intended to help a reader understand what agents might be used to model, based on common terminology from other robot architectures. The higher levels of the robot control system are task agents, skill agents, and several types of behavior agents. Task agents are responsible for decomposing highlevel tasks into subtasks and sequencing the application of skills and activation of behaviors. Environment agents form an active internal model of things external to the robot. The environment agents provide a model of physical objects, robot users, and the robot’s environment that is accessible to other agents. Skill and behavior agents are built by combining several lower-level resource agents and a feedback mechanism to achieve coordinated action. Behaviors include continuously operating collision avoidance and reflexes for safety and limits, while skills include visual tracking, grasping, manipulating objects, and navigating. The network of skills and behaviors is not flat and may include composite skills and behaviors that represent a sequence or collection of simultaneously active sub-units. Thus, a composite skill is illustrated by visual servoing which includes simultaneous tracking (a low level skill) and directional manipulator control (another low level skill). The inner agents in Figure 20 are most closely related to the robot hardware and 71

provide an agent-based abstraction of the robot hardware to higher layers. The inner layers are divided into actuator resource agents, which model transfer of energy from the robot to the environment, and sensory resource agents, which model sensing or energy transfer from the environment to the robot. The interactions and arbitration mechanisms at this level of the system normally support both motor action arbitration and sensor action arbitration. Motor action arbitration combines influences from the skills and behaviors of the system into the resulting motor actions of a robot mechanism, and sensor action arbitration combines influences from many source agents into a resulting sensor action that influences the behaviors and goals of the system.

Conceptual Agent Interaction Model An asynchronous model for decision, computation, and contribution is depicted in Figure 21. Each evaluates the data it has available in a decision process, executes come computational mechanisms based on this decision and then sends updates to other agents. This is the conceptual model for the central activity in of each agent and how updates and computations lead to different types of latency as information travels between agents in the agent network. I am aware that this subsection needs more description. The asynchronous operation of the agents can be an advantage for the system, if certain criteria are met by the relationships used to link agents. By adopting this model there is the potential that significant amounts of computation and communication will be wasted. However, there is a compensating mechanism in the relationships between agents. Relationships update and use only a subset of the

72

Figure 20. IMA Agent Classifications

73

Figure 21. Asynchronous Decision and Computation Processes possible connections to minimize communication and computation wasted on old information. Furthermore, it is possible to connect relationships into a kind of context control system like spreading activation, so that only the currently relevant elements of the system will receive significant amounts of processing power and communication bandwitdh. This is one aspect where IMA differs from traditional software architectures that focus purely on connectivity and protocol, to a level where the architecture addresses context and resource limiting. By controlling the resources available to agents, it is possible to decrease processing and communication to less useful agents, and then later, as the situation changes, increase their level of interaction. The remaining aspect to consider is the method for constructing agents and methods of agent interaction. The agent concept in IMA is a modeling abstraction for bundles of related software modules called components, described in the next

74

chapter, while interactions between agents are introduced below.

IMA Relationships Every relationship between agents represents explicit communication path between the agents that follows a specific protocol. This link encapsulates not only interface signature (methods, arguments, data types) but also carries the protocol required (sequence of function calls, exchange of messages, etc.) needed to make a logically correct connection based on the roles of participants in the relationship. Thus, each agent may participate in many relationships and in various roles in each relationship. One example of a relationship might be message-passing link between agents. These are often described in multi-agent systems that are based on speech-act theory. The protocol for this type of link is trivial, and there are only two possible roles: sender and receiver. This type of link depends heavily on shared semantics between components (i.e., the receiver can understand the language and meaning used by the sender). This dependence can be a weakness in system development, while the totally flexible structure of message-passing is an advantage of this kind of architectural connection. It is straightforward to get every module in the system connected using messages, but very difficult to keep this shared language under control as the system grows. The ISAC2 system suffered from this limitation [10]. Another example of a relationship is spreading activation. This relationship also has a simple update protocol and also has very little semantic content because only a single number is passed between agents. The meaning of the activation level is determined locally by the response of each agent to changes in activation levels.

75

The types of interactions that are common in typical robot software rely on semantic connections. These are connections between software modules that share an explicit or (more dangerous for system growth) implicit semantics for the signals that pass between the agents. These types of interactions are like “speech acts” described by many multi-agent system researchers. This is an attempt to formalize the concept of communication as just another action that an agent may select. The pinnacle of such architectures is the BDI agent model. The shared semantics of the language used by communicating agents defines the meaning of the signals that pass between agents. Other types of systems rely less on shared-semantic connections. In these systems the connections are signals that travel between elements of the system, and each element of the system has a local interpretation of these signals (i.e., each element has its own local semantics). This is how computer hardware systems work. Agents connected like this are described by Minsky, and some limited implementation was attempted by Suehiro [87]. This kind of non-semantic connection is exploited in spreading activation systems, as well as in behavior-based systems. The “escape” from semantics is one source of the power of these architectures but results in a system that works much more like a nonlinear dynamic system than a traditional software system. The message passing (speech act) model of communication between agents captures the procedure for sending messages as an explicit part of the model. Object-oriented software can be viewed as a specialization of this type of message passing where there is a special shared semantics. In object-oriented programming there is an implied reference in all messages. Thus, when an object gets a message, there is an implied “you” in the message allowing the sender to only specify what 76

message and the recipients for that message and then each recipient responds to the message based on its type. This is the polymorphism property in object-oriented models. The asynchronous nature of agents in IMA places a specific set of constraints on all agent relationships. By assuming that each agent has a set of local representations and is an independent decision-making software module, a relationship must provide resources for decision that are updated asynchronous to the local decision process. They must provide contributions to the decision process that can be evaluated on the basis of both semantic and non-semantic content, and they must provide a notion of time that permits old information to be ignored by the system.

Classification of Relationship Types The model for agent relationships is that each agent in a particular relationship has some set of data that is considered to be its contribution to the relationship. Each relationship is treated as a separate type of interaction, and two different relationships cannot be connected. Only agents participating in the same type of relationship are connected. An agent updates its contribution asynchronous to all other agents. The contribution of an agent is a structure that contains everything needed for local decisions to use the contribution, including timing information that enables an agent to ignore old contributions, for example. The relationship also defines a mechanism that, when invoked, computes the effective contribution of the relationship. This mechanism is the arbitration mechanism for the relationship. Thus, relationships cache the contributions from agents and keep track of

77

timing so that the cache may be evaluated based on age. Periodically an arbitration mechanism is invoked to evaluate the current set of contributions and provide some type of “effective contribution” for the relationship. Furthermore, contributions to relationships may affect which participants receive updates when the state of the relationship is updated by other agents. There are two broad classes of relationships in IMA. Asymmetric relationships, shown in Figure 22, are typical of agents involved in motion control or sensor fusion. Symmetric relationships, shown in Figure 23, are typical of agents involved in sequencing, attention control, or other higher-level aspects of robot control. The primary difference is how the arbitration mechanism is used. In asymmetric agents, only the agent on the “receiving end” of the relationship uses the arbitration mechanism to combine contributions (e.g., motion schema), while in symmetric relationships, many agents use the arbitration mechanism to combine contributions (e.g., spreading activation). These figures are intended to show that the relationship is treated as a component of each agent, and hides some of the details of module interconnection between the agents.

78

Figure 22. Asymmetric Agent Relationships in IMA

79

Figure 23. Symmetric Agent Relationships in IMA

80

CHAPTER V AGENT-OBJECT MODEL IN THE IMA Introduction This level of the model describes how an agent is built from a collection of component objects. Strong encapsulation and separation of policy, mechanism, and representation are sought in this model. The goal of such separation is to make the development process of agents more structured and facilitate the reuse of software components. Each agent in an IMA system is a persistent collection of connected objects of the following classes: • Agent Components - Agent components are component objects that support a set of interfaces for management by the agent manager as well as interfaces for persistence to streams (blocks of bytes) and storages (hierarchical databases of named streams). The agent component generally also supports an external interface that exposes its specific functionality. Representations, Relationships and Policy components are all sub-classes of agent components. • Agent Managers - Each agent has only one agent manager. This object supports a set of interfaces to establish local connectivity as well as establish a high-resolution local clock and locate other agents in the system. The agent manager is also responsible for handling the process of loading and initializing the connections between other agent components. • Component Links - Each agent component may define a set of outgoing 81

ports called component links. These ports are references to other components within the agent that are automatically managed by the framework. Component links use the agent manger to help locate their targets by name and are automatically restored when an agent is loaded from persistent storage. • Activity and State Components - These components give the agent its internal activity and control its response to events and the results of computation. The activity component is an object that encapsulates an operating system thread (i.e., it is scheduled for execution by the underlying operating system) and provides an explicit representation of the control-state within an agent. The partner to the activity component is the state component. Each activity may have many states, and a state may contain many concurrent activities or states. Thus, this forms a hierarchical model of the control state of an agent that is explicitly represented by component objects that are part of the agent structure. • Representation and Mechanism Components - Representation components are the foundation of communication between agents. A representation component is a distributed component object that supports multi-cast of its state to a set of proxy objects in other agents. Through the representation, multi-cast mechanism agents can observe certain peices of the state of other agents. • Component Managers - Component managers are an extension of the software to permit interconnection with standard OLE and ActiveX software 82

technologies, used to build multi-media documents and other documentcentered software on the PC platform. Component managers provide a view of a single agent component when inserted into an OLE or ActiveX container.h Component managers allow the components of agents to be visualized using graphical editors and support rendering of graphical or textual representations into web pages containing an ActiveX component manager. This concept is an example of the bridge design pattern [23] used to connect two separate systems and the component managers are the bridge components: they support some custom IMA interfaces and some standard OLE and ActiveX interfaces. • Relationships and Links - The connections between agents are also represented as components that are the endpoints of those connections in each agent. Several types of links between agents are supported, from simple data flow to full IMA relationships with arbitration mechanisms to selectively update and use contributions from each participant. These components provide a local view of the relationship between agents to all the other components within the agent. Through polymorphism of component objects, relationship and link components will be used like mechanisms or representations by other agent components. One of the ideas in this object model is to separate three aspects of the agent’s operation into components that represent a concrete realization of the software aspects of structure (Figure 24), functionalty (Figure 25) and policy (Figure 26). Any program has these aspects, but frequently they are mingled or weaved together

83

in lines of source code. By separating these aspects it is possible to develop more structured and reusable software a a relatively fine-grained level. These aspects address connectivity, data flow, and control flow as separate views of the software system. The following figures show the different aspects and which components are involved in representing that aspect withing an agent. The structural aspect of the agent has two different concepts. Figure 24 shows that the agent is organized as a tree of component objects originating with the agent manager object as the root. This structure is efficient for grouping and collecting the various components within the agent as well as for storing the components to persistent storage. Another type of connection between agent components is supported as well. This type of connection is called the component link. Component links complement the explicit, strongly typed incoming interfaces provided by component objects, by adding support for strongly typed outgoing interface connections. Thus, each agent component is designed to support a set of incoming interfaces and explicitly connect to a set of other interfaces on other components. These agent links are managed automatically by the framework and are a kind of interface-connection architecture as described by Shaw [81]. The relationship between agents is represented as a set of components that are “endpoints” of the relationship in each agent. These components encapsulate the communication between agents, as well as protocol and the most complex types of relationships capture arbitration mechanisms as well. Figure 27 shows a simple way to connect agents by setting up data flow between them. This simple connection provides one agent with a view into the state of another agent that is time synchronized relative to the destination agent. More complex types of connections 84

Figure 24. Structural Aspect

85

Figure 25. Functional Aspect

86

Figure 26. Policy Aspect

87

are built by aggregating and and managing sets of such simple links using other components. Figure 28 shows a more complex connection that includes agent links which are structured two way connections, as well as a relationship component which organizes links and provides arbitration for one end of the relationship. This type of connection if common in agents that take multiple inputs, like agents that represent physical mechanisms on the robot. Figure 29 shows a connection where each end of the relationship has a relationship component that acts as manager and arbiter in the relationship. This type of connection is used to create symmetric relationships like spreading activation between agents.

Structured Object-Oriented Model The following descriptions and diagrams provide a more structured view of the component object system that constitutes the agent-object model of IMA. The model will be presented using a combination of description in English and a visual notation called the Unified Modeling Language (UML). This practice is common in the object-oriented software community and a variety of similar methods have been combined into UML [14, 76, 39]. These components are also represented in Figure ?? which shows an overall class diagram relating the components. The class diagram shows some of the static structure and class hierarchy of IMA components. One of the primary functions of this system of objects is to load an agent from persistent storage and restore component links between all the objects in the agent. This process is shown in Figure 31, a UML sequence diagram. The corresponding states of each agent component are shown in Figure 32, a

88

Figure 27. Simple Data Flow

89

Figure 28. More Complex Connection

90

Figure 29. Fully Symetric Relationship

91

Figure 30. Agent-Object Model: Top Level Class Diagram

92

Figure 31. Agent-Object Model: Loading Sequence Diagram

93

Figure 32. Agent-Object Model: Component State Diagram UML state diagram. UML state diagrams are also similar to statecharts developed by Harel [46]. A detailed view of relationship components is shown in Figure 33. This figure shows that relationships manage groups of contributions which are in turn composite sets of representations (source or proxy) from a single other agent. This layering of structure allows relationships to capture very complex interaction while still using a regular and modular set of software elements.

94

Figure 33. Detail of Relationships and Contributions

95

CHAPTER VI EXAMPLE SYSTEMS USING THE IMA This chapter describes the agent networks and some of the agent-object models for agents used to create the control software for two quite different robot systems in our laboratory. The development of these example systems is one kind of validation of the IMA. This shows that the architecture works and can be used to build robot control systems. The explanations in the following sections are intended to reveal the types of design decisions that were used in selecting the agents and relationships for the ISAC and Helpmate systems. Several individual agents will also be described in detail to show how component objects were used to create these agents.

ISAC: Dual-Armed Humanoid Robot The first system used to test IMA is a dual-armed humanoid called ISAC. ISAC provides a rich testbed for robot development due to the availability of many sensors and actuators and the relatively unstructured tasks for which it is used. ISAC is equipped with stereo color vision, voice I/O, and two arms with force sensing. Figure 34 shows a network of agents is used to realize a simple service-robot demonstration on the ISAC system. The goal of this demonstration is to feed soup to a disabled user who sits in front of the robot and asks for help using voice commands.

96

Figure 34. Agent-Network for ISAC Demo Helpmate: Mobile Manipulator The second system used to test IMA is the Helpmate robot. This is a mobile robot equipped with a simple arm, stereo color vision, LIDAR, and SONAR systems. Figure 35 shows the network of agents is used to realize a simple fetch demonstration on the Helpmate robot. The goal of this demonstration is to fetch an object from another room and bring it back to ISAC.

97

Figure 35. Agent-Network for Helpmate Demo

98

CHAPTER VII EVALUATION OF THE ARCHITECTURE In addition to the development of the robot control systems described in the previous chapter, IMA has been evaluated further to try to discover how it affects the development process and properties of the resulting system. One purpose of software architecture is to provide useful abstractions that work at a level higher than traditional programming methods [81] and confer some set of properties to conforming systems. Another purpose of software architecture is to describe the decomposition and integration between components as well as functionality in a form that can be used to guide the development process and improve it in some way. Typical evaluations of architecture include: • Capability - The architecture provides a means to express concepts or describe systems that cannot be adequately described by other architectures. • Scalability - The architecture adequately describes systems as they grow larger, needing a comparable increase in resources. • Productivity - The architecture provides abstractions (and tools) that increase the productivity of the development process. Capability is an issue that is too vague to measure ,and, in a rigorous sense, all architectures that are Turing complete are equivalent because they can be used to compute any computable function. Thus, it comes down to comparing how easy it is to model some system within the architecture.

99

Scalability is an issue that is measured in many ways. However, scalability does not mean that the architecture can help solve larger problems with the same resources. It means that the architecture can solve larger problems with proportionaly larger resources. These resources are often described in terms of processing power or communications bandwidth between elements of ths system. Thus, architectures that are centralized frequently have problems with this measure, because performance of the central component always limits growth of the resulting system. Distributed architectures don’t escape this problem because growth of communications overhead between system elements can also swamp the system performance. The IMA addresses scalability by avoiding centralized bottlenecks whenever possible and remaining asynchronous and distributed. Productivity is an elusive measure of software architectures that has been cast in many forms from lines-of-code (LOC) to newer more object-oriented measures, such as reuse. Architecture can increase productivity by making the development process of each component easier, by supporting high levels of component reuse, or by supplying tools that automatically handle redundant or repetitive coding. The IMA tries to achieve improved productivity by supporting very strict encapsulation and high levels of reuse at the component level. This evaluation is not complete.

100

CHAPTER VIII CONCLUSIONS AND FUTURE RESEARCH The IMA needs to be used and evaluated in a variety of ways so that we can learn how to make better architectures. Over time the success or failure of the IMA will become more apparent as measures of reuse and scalability are tested by the continuing development process of service robot capability. Like any development tool, the IMA needs other development tools to complement it. Much work can be done to create tools that are built to develop within the IMA. Improved graphical editors of agents and relationships are just one possible addition. Due to the explicit nature of connectivity in IMA, it is possible to develop automatic “connection checking” tools to ensure that a set of agents is configured according to a specification. There is also the basic support for monitoring real-time aspects of agents and the possibility that monitoring could be added to continuously guarantee certain timing deadlines within agents. As formal concepts about software architecture are developed [3, 89], it may be possible to adapt the structured, informal architecture presented herein to a more formal specification of a design pattern for robot software.

101

APPENDIX A DEFINITIONS OF IMA TERMS The Intelligent Machine Architecture uses extensive technical terminology, some of which is from object-oriented software engineering, current software technology, robotics, multi-agent systems, and other research areas. This list is intended to help our lab keep the pieces and terminology straight. Terminology is important and influences how people think about development of a system and that this list is intended to helps the reader handle the abstract terminology used in descriptions of IMA. Loaded terms are shown in italics and will be defined further in the list or are being defined as they are introduced. The reader should be familiar with terms from robotics and from object-oriented programming.

IMA Terminology Agent - This term is used in a wide variety of research areas to refer to different things. In IMA an agent is an active software module that is a model for some element of our robot system, skills, behavior, tasks, or environment. By building links (called relationships) between agents we can capture data and control flow between elements of our system. The network of agents is intended to form the control system for a robot and model the robot system at the same time. An IMA agent is also distinctive for its separation of policy, state, and mechanism. Typical software systems mix policies and mechanisms, but IMA agents keep these elements separate. Another way to look at an agent is to view it as a collection of persistent component objects

102

that define the state, policy and mechanism of the agent. A multi-agent system comprises a set of agents and the relationships between these agents. The IMA employs a model of the robot system that uses multiple agents to capture and encapsulate the different parts of the system. The concept of agent is closely related to the concept of object in object-oriented software engineering and agent as used by Marvin Minsky in Society of Mind. Agent Types - These are classes of agents that roughly group agents by the aspect of the robot system they model. Resource Agents own the hardware of the system and supply the “bottom layer” of IMA (e.g., the sensors and actuators of the robots). Behavior or Skill Agents connect sensors and actuators to achieve certain types of sensory-motor dynamics (e.g., visual servoing). Task Agents activate sets of Behavior or Skill Agents in sequences to achieve a specific goal. Environment Agents represent objects or the user of the robot system. These agents use the resources of the robot to engage in a process called “anchoring” whereby they try to track the state of the realworld entities that they model. Some environment agents represent purely a-priori information like workspace boundaries or permanent objects in the environment (The Table Agent for ISAC). The environment agents are a way of bringing together what the robot “knows” about a particular element of its environment. Environment Agents are not limited to mechanical things like cups. One excellent environment agent would be the lighting agent that would use camera data history to compute an ambient lighting estimate that could then be used to influence the computation in other agents that used

103

camera images, for example. Agents may also be “collection agents” (i.e., they represent and manage collection or group of other agents) Collection Agents might dynamically create instances (other agents) based on input from the environment. The explicit structure of IMA agents makes this process much simpler. Representation - This term refers to an element of the “state space” of an agent in a general sense. The concept of having representation components is that there is a general way to encapsulate and refer to pieces of the state of an agent. The type of representation may vary from floating point vectors to text strings or images, but by classifying certain components as state, the distinction between state, policy, and mechanism can be made more clear than in traditional programming. Representations can also be compound representations that combine several smaller, simpler representations from the same source (agent) into a larger representation. Finally, there are composite representations that combine representations from several different sources (other agents). Representation objects encapsulate the communication mechanism between different processes and computers in our network at a very fine-grained level. The benefit of this encapsulation is that the mechanism used for run-time communication of data may be varied without changing any of the code (policies, mechanisms) that uses the representation objects. The communication mechanism is based on a proxy-server model, where the source agent that owns the representation has a representation component that is a server to a set of proxy components that are remote copies of the

104

representation used by other agents. A remote (or proxy) representation is like a window into a portion of the state of another agent. In IMA the concept of representation (proxy and server) is implemented as a base class that allows new representation types to be added easily as needed. Representation base classes also provide a simple clock synchronizing mechanism so that correlation of representations from the distributed system elements is meaningful and allows sound decisions to be made within each agent based on a synchronized virtual clock. Policy - This term defines the strategy or, implicitly, the goal for an agent. The policy of an agent represents the flow of control within an agent. IMA Agents realize this control-state as a concurrent hierarchical finite state machine. This is an advanced form of state machine but is in principle the same concept. One way to view a policy is to think of it as a conditional plan. Most advanced planning systems produce a conditional plan whose representation is a finite state machine. The policy controls how to organize or sequence computations (the mechanism) of the agent in response to external or internal events. In IMA Agents, policy is implemented by a set of component objects that are active (they have a thread of control and are scheduled for execution by the underlying operating system) called activities and other components called states. These two components can be combined to build state machines that control agent policy and operation sequencing. The conditions and actions in the state machine descriptions can use fuzzy logic to provide

105

linguistic softness when required, but the state transition functions use traditional Boolean logic. The policy components are implemented as derived classes from a base class that allows other active objects to be added easily as needed. For example, a completely different policy mechanism could be used within an agent (such as spreading activation). The policy uses a uniform interface to activate or invoke components that provide the mechanism of the agent. Mechanism - The mechanism of the agent comprises a set of components that work like traditional algorithms, but with policy removed. Thus, the mechanism of the agent captures algorithms that are like transformations (representation in to representation out) or functionals. For example, control laws, image processing operations, and spatial transformations are all examples of mechanisms that are common in robotic systems. The mechanisms of an agent are a set of possible actions from a planning standpoint and form a basis for the agent policy. The mechanism is controlled by the policy and they cooperate to create a continuous flow of computation that changes in response to events entering the agent or the results of internal computations. Mechanisms are the simplest components because they require little special support and are essentially packages around traditional algorithms, so a simple base class is defined to make it easy to add new mechanisms to the system as well. Many of the elements of systems that are commonly called “modules” would be called mechanisms under IMA. Together, mechanisms, representations, and

106

policies form a kind of highly structured object-oriented program that realizes dynamically changing processing within an IMA Agent. The explicit notion of “mechanism” helps to separate the two levels (robot-environment and agent-object models) by allowing a system level entity to be described and used independently of the mechanism that it uses internally for implementation. Relationships - These are links between agents that capture certain common patterns of interaction between agents. The relationship is implemented in IMA as a base class from which new relationship types may be easily derived. Each type of relationship is realized by a component object in each agent that supports the relationship type. Each relationship has a set of participants (other agents that want to interact with the owner of a relationship) and an effective state. The contribution of each participant is realized by a component object (representation proxy). A relationship has its own mechanism and policy for handling the contributions of the participants. Thus, a relationship is like a package of reusable representation, policy, and state that allows an agent to handle a certain type of interaction. Examples of relationships are the motion schema relationship, which allows multiple participants to influence the motion of robot mechanisms, and the spreading activation relationship, which allows participants to create a distributed dynamic system that can control sequencing at the agent level. Relationships can come in two broad classes: semantic and non-semantic. The semantic relationship requires that the implementation of two agents shares a common set assumptions in order

107

to operate (these are sometimes called logical links), while non-semantic relationships do not require common semantics (or meaning). An example of a semantic link command is “Go to x, y, z” which requires that the frame of reference be shared to have any meaning, while an example of a non-semantic link is “My activation is a” from spreading activation. It is possible in IMA to create a kind of compound link between agents that has some semantic parts as well as some non-semantic parts. Non-semantic links work well for controlling context and modulating decisions, while semantic links provide very compact forms for interaction (due to the inherent assumptions). IMA tries to take advantage of both types of system organization by providing compound links. Relationships between agents can also be written and used to build up networks of agents that resemble class systems from object-oriented modeling. Component Object - These are blocks of software (sometimes called components or software components) that are structured around the ability to access multiple interfaces at run-time using a binary interface standard (i.e., Language Independent). An interface is merely a set of virtual function calls into the object. Each interface to a component object is defined in an Interface Definition Language (IDL) that describes the method names, arguments, return values, and properties needed to generate remote object calls to the interface. Thus, the IDL tool provides a way to easily build interfaces that can be called across process or machine boundaries. The interfaces on all the component objects in IMA are defined in an IDL file. IMA Agents use a specific type

108

of component objects invented by Microsoft that follow a the Component Object Model (COM). All COM objects support a special interface called IUnknown. This interface exists only to allow other interfaces to be accessed a run-time. IUnknown provides a kind of late binding for component objects. Another way to look at component objects is to examine how they differ from “regular objects” (i.e., C++): They support polymorphism by having different components that support the same interface. They support strong encapsulation because they can be used only through an interface obtained via the IUnknown interface. They support identity because all references to the IUnknown interface on a component must be the same value. They do not support implementation inheritance, because inheritance breaks encapsulation. Many aspects of component objects are relevant and useful and described fully in the on-line help on every machine in our lab. Component objects that support special interfaces for loading and storing them are called persistent objects. A persistent object can be stored on disk and reloaded to its previous state for later use. All IMA component objects support persistence (built into the base classes), and thus the entire description of an agent can be saved into a file and reloaded later. Agent Component - Agent components are component objects that support a certain set of interfaces (the IMA Base Interfaces) that provide persistence as well as the ability to be accessed by name, respond to events, and be monitored by other component objects. The other elements of an agent, namely representations, policy components, relationships, and mechanisms,

109

are all types (sub-classes) of agent components because they all support the set of agent component interfaces. The Framework classes (base classes) in IMA facilitate the development of Agent Components and implement the common interfaces and functions automatically. It is technically possible to develop agent components purely from the interface specifications; however, this would not take advantage of the framework classes that greatly reduce the effort required. Agent Manager - The agent manager is a special object that owns the rest of the components within an agent and is responsible for managing persistence (saving and loading) as well as for locating components within the agent. It provides a name-space for the components of an agent, and this component is really the “identity” of the agent within the agent system. When one agent refers to another agent it is (at first) talking to interfaces of the agent manager. The agent manager is a generic component implemented as a class in IMA to be reused in all agents. Any component that implements the interfaces defined on the agent manager could also serve as an agent manager. This opens up the possibility of hierarchical agents (i.e., agents that literally contain other agents); I am not sure how useful this will be in our current systems. Agent Shell - This is a program (in the traditional sense) that has an agent manager that it uses to load an agent from persistent storage and use the agent. The shell is a kind of tool for interacting with the agent. Several types of shells can be useful. Graphical editor shells can be built to view

110

the agent components, edit properties, specify new policies, add or remove components, etc. Simpler shells can be used to run agents without a user interface, if needed. The agent shell merely provides a process address space for the execution of the agent itself, and multiple agents can run within one shell if needed. This emphasizes one major difference between typical software systems and IMA agents: IMA agents are not programs. They are collections of persistent, executable component objects that can be manipulated in many ways and support a basic set of interfaces needed to be saved, loaded, connected, and activated. By supporting this type of functionality, IMA can provide a basis for a wide variety of development tools that aid agent monitoring, debugging, design, evaluation, and possibly learning in the future. Software Framework - These are a set of C++ base classes that simplify the process of writing component objects that are representations, mechanisms, relationships, and policies. They do all of the dirty work and implement the common or tedious portions required for integration of “standard code fragments” with IMA. By deriving new components from these base classes,a developer will end up with components that can be used as a portion of an agent. The base classes allow developers to leverage a lot of development work into development of new components and agents; for example, the active components (threaded objects) took weeks to properly implement and debug, but they can now be reused by typing a few lines of code in a class definition in any new policy components.

111

APPENDIX B ROBOTICS TERMINOLOGY The following appendix will describe some of the terms and acronyms used in this dissertation that relate to robotics systems and hardware to help a reader in understanding the text. LIDAR - This device a laser-radar device that provides a coarse range image by measuring the time-of-flight of a laser beam while scanning it over an area. Mobile robots use this sensor to detect obstacles.

112

APPENDIX C UML NOTATION Many of the class, sequence, state, and other diagrams in this disseration have used a structured visual notation. This notation has evolved through several generations of object-oriented modeling and design and represents a very recent unification of several approaches; hence the name, “Unified Modeling Language” (UML). The UML provides a highly structured visual notation for modeling of software or other systems and a good tutorial is provided by Fowler [39]. Currently, efforts to formalize the semantics of UML are being developed, but it is still an informal technique for description of systems. However, UML is far from ad hoc and represents the current best-practice method for effectively communicating objectoriented software designs in visual form. What follows is an extremely brief description of some UML notation elements. A compact tutorial can be found in [39], with exhaustive technical definitions and descriptions available in several new books on the subjectreferences here.

Class Diagrams Class diagrams are used to show the entites in the software and the relationships between them at a specific level of abstraction. Class diagrams use boxes and lines to show classes and associations between classes. Some associations, like inheritance, show the structure of the software. One aspect of UML that is new is a notation to show interfaces as a separate concept from “object”, which is a necessity for properly describing COM components and interfaces in the Java

113

language.

Sequence Diagrams Sequence diagrams show the paths of threads of execution through a set of objects and interfaces (typically defined in a class diagram). These sequences may illustrate serial or concurrent operation.

State Diagrams State diagrams show the control states of a set of objects. The control state is represented in a state diagram as a concurrent, hierarchical, finite state machine much like those described by Harel [46]. This allows state diagrams to show states, events and concurrency at varying levels of abstraction in the model.

114

APPENDIX D COMPONENT OBJECT SOFTWARE The Intelligent Machine Architecture is based on recent developments in component object software technology [64, 94]. Although it may have been faster to implement an initial system using traditional elements, a component object software technology was selected for the following reasons: • Strong Encapsulation - Access to component functionality is always through explicit interfaces with strong interface typing by globally unique identifiers. • Dynamic Linking - Components can be loaded and unloaded under explicit control, by unique identifier, during program execution. • Interface Abstraction and Definition - Interfaces can be defined using an abstract interface definition language (IDL) that aids in the generation of component code and helps separate the interface from implementation details. • Language Independence - Components can be implemented in any language that supports function pointers, such as C++, VisualBasic and Java. • Version Control - By strong typing of components (by globally unique identifiers) it is possible to support multiple versions of components and smoothly add new components and versions to a working system. • Tool Support - Commercial off-the-shelf (COTS) tools now support component software and also support the automatic generation of remote procedure 115

calling (RPC) code from the interface definition language. By building IMA on this higher-level software model, the architecture itself becomes language independent as well. Furthermore, the elements of IMA are supported (at least at a low level) by commercially available software tools that help reduce the cost and complexity of code development.

The Component Object Model (COM) The particular component object technology used for this implementation of the IMA is the Microsoft Component Object Model (COM) [64, 52, 45], although other alternatives are available, such as CORBA [94]. This component object model is an emerging de facto standard for the implementation of component software and does not have the overhead associated with CORBA. COM is now beginning to be supported on platforms other than the Microsoft Windows systems, including some implementations on UNIX and Linux. COM provides a very flexible set of primitive abstractions that support component software. Several complete descriptions of COM and its internal mechanisms are available in the above references and in both Brockschmidt [15], who describes how OLE is implemented using COM, and Rogerson [74], who describes the fundamental aspects of COM and the newer distributed component object model (DCOM) [20]. What follows is a brief introduction to the concepts and facilities of COM as relevant to the development of the IMA. The primary abstraction in COM is the Interface. An Interface is a set of functions and their calling signatures (arguments) grouped together with a unique identifier called an Interface Identifier (IID). It is interesting to note that the 116

explicit representation of the interface as a unique IID can greatly simplify future architectural tools that might test a system for connectivity between interfaces. The interfaces in COM can be defined like pure-virtual classes in C++ but are more easily defined using the Interface Definition Language (IDL). This language is supported by a compiler that turns the interface definitions into header files for C / C++ code development, type-libraries that store the interface signature in binary form, and the remoting code needed to call the interface across process boundaries. The availability of this tool is a primary reason for the use of component object software for the development of IMA. Another abstraction in COM is the COM Class. A COM Class is a block of executable code defined by a unique identifier called a Class Identifier (CLSID). A COM Class implements a set of COM Interfaces by providing the base interface IUnknown. The code for the class may reside in a traditional executable program or in a dynamic link library(DLL). In either case the operating system provides a mechanism to automatically load code for requested COM classes and unload these classes when they are no longer in use. The IUnknown interface is mandatory for all COM Components and allows client software (or other components) to request additional interfaces from the component at run-time. It is thus a kind of program-controlled linking. However, it prevents clients from knowing anything about the “inheritance” of the component they are using. The component is merely seen as a set of interfaces. IUnknown provides an additional important function for any COM component. The value of the IUnknown pointer is the identity of the component. Thus, given any two IUnknown pointers it is valid to compare the pointer values to test for component 117

object identity. By implementing the IUnknown interface, COM components also support polymorphism. Thus, any two components that implement the same interface are said to be polymorphic with respect to that interface. Furthermore, any two components that implement the same set of interfaces are interchangeable as far as a client program is concerned. The object model for the basic COM interface and relationship between interfaces is shown in Figure 36.

Special COM / OLE Interfaces Microsoft has also defined suites of interfaces based on COM that provide the foundation for other software technologies such as OLE, ActiveX or DirectX, etc. These suites of interfaces provide a range of component-object-based services to any program developed using COM. Some important subsets of interfaces are: • IPersist Interfaces - This set of interfaces allows objects to tell clients they support various forms of persistence, such as streams and storages. • IDispatch Interface - Allows objects to support named methods and properties through a special “interpreted function call” interface, which is shown in Figure 37. • ITypeInfo Interface - Components have an associated type library that defines the signatures of all their methods in binary form. • IStream Interface - This interface is implemented by the operating system to support persistence of objects to stream-like media (files, memory buffers, transport streams). 118

Figure 36. UML Model of COM

119

• IStorage Interface - This interface is implemented by the operation system to support hierarchical object databases to be stored onto various media.

120

Figure 37. UML Model IDispatch

121

APPENDIX E USING THE CODE FRAMEWORK Introduction Most engineers are not trained to develop reusable software; however, it is essential to embrace this new mode of development to simplify development of more complex systems. It may be tempting to assume that everything in IMA is an agent because the concept of multi-agent systems is appealing and the term is used (misused) in many contexts. This is not the case; only things that represent a fully encapsulated concept can be IMA agents. This completely rules out the concept of a general object-recognition agent, because such an agent would break the encapsulation of many parts of the system and would ultimately be a point of failure. Instead, the elements of the world that are modeled in software (i.e., the utensils in the ISAC demo) are captured as agents, and each agent uses an object-recognition algorithm as a mechanism based on its particular policy. This type of system structure has three very important advantages: (1) It is inherently parallel and allows agents on separate processors to run mechanisms in parallel for increased speed. (2) It acknowledges that a mechanism (object-recognition algorithm) and the agent (a software model of a physical entity) are at different levels of abstraction. (3) Multiple mechanisms (algorithms) can be supported and selected by an agent based on the situation and new algorithms are easily added to increase the capability of the system. This example extends to employing various control algorithms, multiple visual servoing algorithms, tracking algorithms, etc. To achieve this kind of flexibility in a system, it is essential to separate policy from

122

mechanism and to separate the system level model from the implementation level model. Thus, not everything is an agent. Most of the development effort in IMA will be spent in developing agent components (mechanisms, policies, relationships, and representations). The code framework focuses on simplifying and speeding up this process for developers. Some members of a development team will develop components, while others will work on building the agents that use these components. This means that there are several types of development work under IMA, while in the past teams used a “one person = one module” philosophy. This also leads into an example of how IMA is designed to evolve over time. Given a system operating with a set of agents that does a feeding demonstration, a developer discovers an improved control algorithm. Under IMA, only the control algorithm itself will need to be implemented and inserted into an existing agent. The system level model is not changed and this is conceptually correct. The policy of the controller agent will also have to be changed to use the new algorithm, but after that, a whole working system results with the new algorithm in place. Most of the code of an agent remains unchanged and is reused (copied) in new versions of the agent, while new algorithms (mechanisms) or policies are added to improve operation. This leads to one of the major drawbacks of the IMA. Bootstrapping the system (building the initial set of agents and components to get things started) is extremely difficult and little or no results are seen until it is nearly finished. This is a difficult hurdle and one that is shared by many systematic development methods that focus on architecture driven development of software. The basic classes used to create components within the IMA agent-object model 123

are shown in Figure 38.

Writing Simple Agent Components These components are derived from the base class CComponentImpl which provides:

Writing Representation Components These components are derived from the base class CRepresentationImpl.

Writing Relationship Components These components are derived from the base class CRelationshipImpl.

Writing Component Managers These components are derived from the base class CComponentManagerImpl and all OLE control base classes. Thus, they are OLE custom controls that are hooked into other IMA interfaces.

Writing Agent Shell Programs Agent shell programs provide a process space and implement an object that supports the agent manager interfaces for IMA. Any program can serve as a shell program that implements the agent manager interfaces. The program can be a simple console program or a full Windows program. By writing a Windows program that supports the commonly available functionality of an OLE container it is possible to configure a suite of component managers to view and interact visually on the screen with the components of an agent.

124

Figure 38. UML Model of Framework Base Classes

125

Writing Agent Tools Agent tools are programs that understand the file format used to store the agent components in persistent storage as well as the basic IMA component interfaces. These programs can be used to automatically generate or configure agents from scripts, for example.

126

APPENDIX F SYNCHRONIZATION MECHANISM The purpose of this synchronization mechanism is to allow agents to model and offset the skew between their local clocks due to message delay and real clock skew. The mechanism used is based on message exchange (Remote Procedure Call is a kind of message exchange for these purposes), and it allows two agents to estimate clock skew using just two procedure calls. Although this mechanism can also be used to create a kind of global clocking in a system, IMA does not have a central “global” entity to keep this clock. The mechanism used for synchronization between agents in IMA is based on a simple distributed clocking algorithm that uses time-stamps to estimate clock skew between agents. The primary assumption of this algorithm is that the delay between the source and destination is symmetric for message traffic, at least on average. This algorithm is described by Levi [56] and is intended for use in LAN environments. Should the architecture be used in a WAN environment, another clocking mechanism may have to be employed. However, the low cost of this method and the high accuracy possible with it justify its use in the current implementation. Other distributed clocking schemes are available like logical clocks [66], but they frequently sacrifice the notion of time intervals to achieve absolutely monotonic labeling of events in the system. Thus, there is no notion of “time” except that event A happened before event B. The synchronization mechanism is used to establish an agent-relative clock for each agent in the system so that any information about time sent from one agent in the system can be interpreted properly by another agent in the system. Figure 39

127

Figure 39. Agent Time Synchronization Mechanism shows the messages and associated times for synchronization between two agents i and j. After the first message from i to j, agent j can compute the time difference: d1 = Cj (T2 )−Ci (T1 ), and it can be seen that d1 = uji +(e1 −e2 ). Now agent j sends another message back to agent i who computes the value of the time difference: d2 = Ci (T4 ) − Cj (T3 ), and again it can be seen that: d2 = uij + (e3 − e4 ), if the error values in the clock readings are modeled as clock skew and additional error terms: (e1 − e2 ) = Sj − Ej1 where Sj is the clock skew (offset) from i to j. Once agent i is in possession of the second timestamped message, it can compute the following:

uji − uij E 1 − Ej2 d1 − d2 = Sj + − j 2 2 2

(8)

If the communication delay is symmetric between the two agents, then the clock skew Sj is known within an error on the order of the sampling error of the individual clocks in the agents. The same scheme can be applied again in the opposite direction so that both agents can compute the skew of the clock relative to the other agent using the further messages on the diagram. After synchronization,

128

agent clocks will drift apart due to imperfections in the match of system crystals or other inherent differences. However, this synchronization mechanism is built into the base-classes that make up the IMA Framework, and the skew is updated as a part of each agent interaction. Thus, this mechanism is typically applied at least once every few seconds between agents, and the drift of synchronization over the timespan of a few seconds is quite minimal. A series of experiments were run to test that such a synchronization mechanism would be valid for time intervals that are typical of the modules in our systems (on the order of several seconds). Timing is based on a hardware performance clock that is represented as a 64-bit integer that is made available under the Win32 API. The frequency of the clock varies from system to system, but this frequency is also made available as a run-time parameter that can be used to convert clock ticks into highly accurate timing values. This hardware clock runs many orders of magnitude faster than the scheduling clock of the operating system (100Khz to 200Mhz) depending on the processor type, giving the possibility of microsecond timing resolution. Times are converted to double precision floating point numbers of seconds when used in IMA and based on a time zero at agent startup. This representation will preserve microsecond accuracy over intervals up to ten thousand seconds (2.7 hours) in length, and millisecond accuracy over intervals of days of system operation.

129

REFERENCES

[1] Philip E. Agre and David Chapman. What are plans for? In Designing Autonomous Agents: Theory and Practice from Biology to Engineering and Back, volume 6, pages 17–34. MIT Press/Elsevier Science Publishers, 1990. [2] James Albus. A reference model architecture for intelligent systems design. Technical Report 5502, National Institute of Standards and Technology, 1994. [3] Robert J. Allen. A Formal Approach to Software Architecture. Carnegie Mellon University, 1997.

PhD thesis,

[4] John R. Anderson. The Architecture of Cognition. Harvard University Press, 1983. [5] Ronald C. Arkin. Towards the unification of navigational planning and reactive control. In AAAI Spring Symposium on Robot Navigation, 1989. [6] Ronald C. Arkin. Integrating behavioral, perceptual and world knowledge in reactive navigation. Robotics and Autonomous Systems, 6:105–122, 1990. [7] Ronald C. Arkin. Just what is a robot architecture anyway? Turing equivalency versus organizing principles. In AAAI Spring Symposium: Lessons Learned from Implemented Software Architectures for Physical Agents, 1995. [8] Christof Baeijs, Yves Demazeau, and Luis Alvares. SIGMA: Application of multi-agent systems to cartographic generalization. In Walter Van der Velde and John W. Perram, editors, Agents Breaking Away: 7th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, pages 163–176. Springer-Verlag, January 1996. [9] Sugato Bagchi, Gautam Biswas, and Kazuhiko Kawamura. Interactive task planning under uncertainty and goal changes. Robotics and Autonomous Systems, 18:157–167, 1996. [10] Sugato Bagchi and Kazuhiko Kawamura. An architecture for a distributed object-oriented robotic system. In IEEE/RSJ International Conference on Intelligent Robots and Systems, volume 2, pages 711–716, July 1992. [11] Edward A. Bender. Mathematical Methods in Artificial Intelligence. Computer Society Press, 1996.

IEEE

[12] Uwe Beyer and Frank Smieja. JANUS: A society of agents. Technical Report GMD 840, German National Research Centre for Computer Science (GMD), Germany, 1994. [13] Bruce M. Blumberg and Tinsley A. Galyean. Multi-level direction of autonomous creatures for real-time virtual environments. In Computer Graphics Proceedings, SIGGRAPH-95, August 1995. 130

[14] Grady Booch. Object-Oriented Analysis and Design. Addison-Wesley, 1994. [15] Craig Brockschmidt. Inside OLE : Second Edition. Microsoft Press, Redmond, WA, 1995. [16] F. P. Brooks. No silver bullet: Essence and accidents of software engineering. Computer, 20(4):10–19, April 1987. [17] Rodney A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, RA-2(1), March 1986. [18] Rodney A. Brooks. A robot that walks; emergent behaviors from a carefully evolved network. A.I. Memo 1091, 1989. [19] Rodney A. Brooks. The whole iguana. Science. The MIT Press, 1989.

In Michael Brady, editor, Robotics

[20] Nat Brown and Charlie Kindel. Distributed component object model protocol – dcom/1.0. Technical report, Microsoft, Redmond, Washington, May 1996. [21] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture : A System of Patterns. John Wiley and Sons, 1996. [22] J. Cameron, D. MacKenzie, K. Ward, R. C. Arkin, and W. Book. Reactive control for mobile manipulation. In IEEE Conference on Robotics and Automation, 1993. [23] Erich Camma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [24] M. Colombetti, M. Dorigo, and G. Borghi. Behavior analysis and training–a methodology for behavior engineering. IEEE Transactions on Systems, Man and Cybernetics, 26(3), 1996. [25] Milton Correa and helder Coelho. Around the architectural agent approach. In Cristiano Castelfranchi and Jean-Pierre Muller, editors, From Reaction to Cognition: 5th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, pages 172–185. Springer-Verlag, August 1993. [26] P. Courtois. On time and space decomposition of complex structures. Communications of the ACM, 28(6):596, 1985. [27] John J. Craig. Introduction to Robotics. Addison-Wesley, 1989. [28] Jill D. Crisman and George Beckey. Grand challenges for robotics and automation: The 1996 ICRA panel discussion. IEEE Robotics and Automation Magazine, 3(4):10–16, December 1996.

131

[29] Daniel C. Dennett. Consciousness Explained. Little, Brown and Company, 1991. [30] Kevin Dowling. Robotics: comp.robotics frequently asked questions. Available via anonymous ftp from ftp://rtfm.mit.edu/pub/usenet/nes.answers/robotics-faq, 1994. [31] Edmund H. Durfee and Thomas A. Montgomery. A hierarchical protocol for coordinating multiagent behaviors. In Proceedings of The Eighth National Conference on Artificial Intelligence, pages 86–93, 1990. [32] L. Erman, J. Lark, and F. Hayes-Roth. ABE: An environment for engineering intelligent systems. IEEE Transactions on Software Engineering, 14(12):1758, 1988. [33] E.A. Feigenbaum and J. Feldman. Computing machinery and intelligence. In Computers and Thought. McGraw Hill, New York, 1963. [34] Cynthia Ferrell. Robust agent control of an autonomous robot with many sensors and actuators. Master’s thesis, Massachusetts Institute of Technology, 1991. [35] R. E. Fikes and H. J. Nilsson. STRIPS: A new approach to the application of theorem proving to problem solving. Artificial Intelligence, 2(3-4):189–208, 1971. [36] R. James Firby. Lessons learned from the animate agent project (so far). In AAAI Spring Symposium: Lessons Learned from Implemented Software Architectures for Physical Agents, 1995. [37] R. James Firby. Task execution: Interfacing to reactive skill networks. Don’t Know, pages 146–153, 1995.

In

[38] Klaus Fischer, Jorg P. Muller, and Markus Pischel. A pragmatic BDI architecture. In Intelligent Agents II: IJCAI ’95 Workshop, pages 203–218, August 1995. [39] Martin Fowler and Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language. Addison-Wesley, 1997. [40] J. Gall. Systemantics: How Systems Really Work and How They Fail. The General Systemantics Press, Ann Arbor, MI, 1986. [41] David Garlan and Mary Shaw. An introduction to software architecture. Technical Report CMU-CS-94-166, Carnegie Mellon University, School of Computer Science, Pittsburgh, PA, January 1994. [42] Fausto Giunchiglia and Enrico Giunchiglia. Ideal and real belief about belief: Some intuitions. In Walter Van der Velde and John W. Perram, editors, Agents Breaking Away: 7th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, pages 1–12. Springer-Verlag, January 1996. 132

[43] Takashi Gomi and Kohichi Ide. Vision based navigation for an office messenger robot. In IEEE/RSJ International Conference on Intelligent Robots and Systems, 1994. [44] Takashi Gomi and Phillip Volpe. Collision avoidance using behavioral-based ai techniques. In Intelligent Vehicles Symposium, 1993. [45] Crispin Goswell. The COM programmer’s cookbook. Technical report, Microsoft, Redmond, Washington, 1995. [46] David Harel. Statecharts: A visual formalism for complex systems. In Science of Computer Programming, volume 8, pages 231–274. North-Holland, 1987. [47] Henry H. Hexmoor, Johan M Lammens, and Stuart C. Shapiro. An autonomous agent architecture for integrating ‘unconscious’ and ‘conscious’, reasoned behaviors. In Computer Architectures for Machine Perception 93, 1993. [48] Henry H. Hexmoor, Johan M. Lammens, and Stuart C. Shapiro. An autonomous agent architecture for integrating unconscious and conscious, reasoned behaviors. In AAAI Spring Symposium: Lessons Learned from Implemented Software Architectures for Physical Agents, 1995. [49] Carlos A. Iglesias, Jose C. Gonsalez, and Juan R. Velasco. MIX: A general purpose multiagent architecture. In M. Wooldridge, J.P. Muller, and M. Tambe, editors, Intelligent Agents II: IJCAI ’95 Workshop, pages 251–267. SpringerVerlag, August 1995. [50] Kazuhiko Kawamura and Robert Todd Pack. Object-based software architecture for service robot development. In ICAR ’97 Workshop on Service Robots, page to add, July 1997. [51] Kazuhiko Kawamura, D. Mitch Wilkes, Todd Pack, Magued Bishay, and J. Barile. Humanoids: Future robots for home and factory. In International Symposium on Humanoid Robots, pages 53–62. Waseda University, Tokyo, Japan, October 1996. [52] Charlie Kindel. Designing COM interfaces. Redmond, Washington, 1995.

Technical report, Microsoft,

[53] Jana Kosecka and Luca Bogoni. Application of discrete events systems for modeling and controlling robotic agents. In IEEE Conference on Robotics and Automation, pages 2557–2562, 1994. [54] J. Laird and S. Newell. An analysis of SOAR as an integrated architecture. In SIGART Bulletin 2, pages 85–90, 1991. [55] J. Laird, S. Newell, and P. Rosenbloom. SOAR: an architecture for general intelligence. Artificial Intelligence, 33:1–64, 1987.

133

[56] Shem-Tov Levi and Ashok K. Agrawala. Real Time System Design. McGrawHill, 1990. [57] William Lim. An agent-based approach for programming mobile robots. In IEEE Conference on Robotics and Automation, pages 3584–3589, 1994. [58] Ren C. Luo and Michael G. Kay. Multisensor integration and fusion in intelligent systems. IEEE Transactions on Systems, Man and Cybernetics, 19(5), 1989. [59] Pattie Maes. Behavior-based artificial intelligence. In Proceedings of the 2nd Conference on Adaptive Behavior. MIT Press, 1993. [60] Pattie Maes. Modeling adaptive autonomous agents. pages 135–162, 1994. [61] Pierre Marcenac. 1997.

The multiagent approach.

In Artificial Life, 1,

IEEE Potentials, 16(1):19–22,

[62] James Mayfield, Yannis Labrou, and Tim Finin. Evaluation of KQML as an agent communication language. In M. Wooldridge, J.P. Muller, and M. Tambe, editors, Intelligent Agents Volume II – Proceedings of the 1995 Workshop on Agent Theories, Architectures and Languages. Springer-Verlag, 1996. [63] David McFarland and Thomas Bosser. Robots. The MIT Press, 1993.

Intelligent Behavior in Animals and

[64] Microsoft. The Microsoft object technology strategy: Component software. Technical report, Microsoft, Redmond, Washington, February 1996. [65] Marvin Minsky. The Society of Mind. Simon and Schuster, 1986. [66] Sape Mullender. Distributed Systems. Addison-Wesley, 1993. [67] Jorg P. Muller. 1996.

The Design of Intelligent Agents.

Springer-Verlag, Berlin,

[68] David John Musliner. CIRCA: Cooperative Intelligent Real-Time Control Architecture. PhD thesis, University of Michigan, 1993. [69] Lars Overgaard, Henrik G. Petersen, and John W. Perram. Motion planning for an articulated robot: A multi-agent approach. In John W. Perram and Jean-Pierre Muller, editors, Distributed Software Agents and Applications: 6th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, pages 206–219. Springer-Verlag, August 1994. [70] Robert Todd Pack, Joe L. Christhoper, and Kazuhiko Kawamura. A rubbertuator-based structure-climbing inspection robot. In ICRA ’97, pages 1869–1874, April 1997. 134

[71] Robert Todd Pack, M. Wilkes, G. Biswas, and K. Kawamura. Intelligent machine architecture for object-based system integration. In AIM ’97, page to add, June 1997. [72] Anand S. Rao. Agentspeak(l): BDI agents speak out in a logical computable language. In Walter Van der Velde and John W. Perram, editors, Agents Breaking Away: 7th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, pages 42–71. Springer-Verlag, January 1996. [73] Elaine Rich and Kevin Knight. Artificial Intelligence. McGraw Hill, 1991. [74] Dale Rogerson. Inside COM: Microsoft’s Component Object Model. Microsoft Press, Redmond, WA, 1997. [75] Julio K. Rosenblatt. DAMN: A distributed architecture for mobile navigation. In AAAI Spring Symposium: Lessons Learned from Implemented Software Architectures for Physical Agents, 1995. [76] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and WIlliam Lorensen. Object Oriented Analysis and Design. Prentice-Hall, 1991. [77] Stuart Russell and Peter Norvig. Artificial Intelligence: A Modern Approach. Prentice-Hall, New Jersey, 1995. [78] Ashraf Saad. A survey of robot architectures and robotic teamwork in the fields of decentralized robotics and distributed artificial intelligence. Intelligent Robotics Lab, Vanderbilt University, 1993. [79] Alessandro Saffiotti, Kurt Konolige, and Enrique H. Ruspini. A multivalued logic approach to integrating planning and control. Technical report, Artificial Intelligence Center: SRI International, 1994. [80] Mary Shaw and David Garlan. Software Architecture: Perspecitvies on an Emerging Discipline. Prentice Hall, 1996. [81] Mary Shaw, R.DeLine, D.Klein, T.Ross, D.Young, and G.Zelesnik. Abstractions for software architecture and tools to support them. IEEE Transactions on Software Engineering, April 1995. [82] Y. Shoham. 1993.

Agent-oriented programming.

Artificial Intelligence, 60:51–92,

[83] H. Simon. The Sciences of the Artificial. The MIT Press, Cambridge, MA, 1982. [84] Frank J. Smieja and H. Muhlenbein. Reflective modular neural network systems. Technical Report GMD 633, German National Research Centre for Computer Science (GMD), Germany, March 1992.

135

[85] John Stewart. The implications for understanding high-level cognition of a grounding in elementary adaptive systems. Robotics and Autonomous Systems, 16(2-4):107–116, 1995. [86] Takashi Suehiro and Kosei Kitagaki. Multi-agent based implementation of robot skills. In IEEE Conference on Robotics and Automation, pages 2976– 2981, 1996. [87] Takashi Suehiro, Hironobu Takahashi, and Hiroshi Yamakawa. Research on real world adaptable autonomous systems: Development of a hand-to-hand robot. In RWC 1997, 1997. [88] Janos Sztipanovits, Gabor Karsai, and Hubertus Franke. MULTIGRAPH: An architecture for model-integrated computing. In ICECCS’95, pages 361–368, November 1995. [89] Janos Sztipanovits, Gabor Karsai, and Hubertus Franke. Model-integrated program synthesis environment. In IEEE Symposium on Engineering of Computer Based Systems, March 1996. [90] S.R. Thomas. PLACA, an Agent Oriented Programming Language. thesis, Stanford University, 1993.

PhD

[91] Laurence Urdang, editor. The Random House College Dictionary. Random House, Inc., 1984. [92] Michael Wooldridge. Time, knowledge and choice. Technical report, Department of Computing, Manchester Metropolitan University, Chester Street, Manchester M1 5GD, United Kingdom, 1994. [93] Michael Wooldridge. Time knowledge and choice. In M. Wooldridge, J.P. Muller, and M. Tambe, editors, Intelligent Agents II: IJCAI ’95 Workshop, pages 79–96. Springer-Verlag, August 1995. [94] Zhonghua Yang and Keith Duddy. CORBA: A platform for distributed object computing. ACM Operating Systems Review, 30(2):4–31, April 1996.

136

ELECTRICAL ENGINEERING IMA: THE INTELLIGENT MACHINE ARCHITECTURE ROBERT TODD PACK Thesis under the direction of Professor K. Kawamura This dissertation discusses the problem of designing software for intelligent robot control from a software architecture viewpoint. The motivation for this work and the issue of what constitutes an intelligent control system is discussed. The complexity of building an integrated intelligent system is described, and system architecture is offered as a tool to manage that complexity. General properties of system architectures are described and current architectures are reviewed, including classical Artificial Intelligence, Behavior-Based Artificial Intelligence, hybrids, and related approaches. Classical Artificial Intelligence (AI) has typically used a knowledge-based decomposition of the design problem, Behavior-Based AI decomposes this problem into goal-achieving modules called behaviors, and hybrid approaches use elements of each type. A proposal for the development of a novel system architecture is included, and potential applications are discussed. This new architecture combines principles from object-oriented software engineering, previous approaches to intelligent machine software, and current ideas about software architecture to produce a new pattern for guide intelligent machine software. We are developing this new software architecture, called the Intelligent Machine Architecture, for the engineering of intelligent control systems. This new approach breaks an intelligent control system into groups of agents and provides a model of relationships that link agents. The architecture features component object-based

software design, uses a new approach to object-based software development and is suitable for implementation in a distributed processing environment. The approach will be tested by a group of twenty software developers as we build new intelligent control software for several service robots in our lab. Thus, the key feature of this architecture is its ability to support the effort of software intergration involving many partial solutions to the problem of intelligent control into a single coherent robot control system.

Approved

Date