SocietyProject Part 2: Specification

Ben Damonte, Lance Hutchinson,Jennifer Knowles, and Sebastian Smith

Team 42CS425: Software EngineeringInstructor: Dr. Sergiu DascaluMarch 13, 2006

Department of Computer Science and EngineeringUniversity of Nevada, Reno

Contents

1 Introduction 2

2 Functional Requirements 82.1 Priority 1 Functional Requirements . . . . . . . . . . . . . . . 8

2.1.1 Behavior Subscription . . . . . . . . . . . . . . . . . . 82.1.2 Publish Data . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Loading Plugins . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Unloading Plugins . . . . . . . . . . . . . . . . . . . . 92.1.5 Sociologist Plugin for Reporting Network Status . . . . 92.1.6 Sociologist Listing Current Debug Data . . . . . . . . . 92.1.7 Behavior Portal Code Repository . . . . . . . . . . . . 92.1.8 Behavior Portal Documentation . . . . . . . . . . . . . 10

2.2 Priority 2 Functional Requirements . . . . . . . . . . . . . . . 102.2.1 SSL Encrypted Network Communication Support . . . 102.2.2 Tab Completion . . . . . . . . . . . . . . . . . . . . . . 102.2.3 GUI for Manipulating Plugins . . . . . . . . . . . . . . 112.2.4 Listing Loaded Modules Plugin . . . . . . . . . . . . . 112.2.5 Sociologist Plugin for Graphing Network Status . . . . 112.2.6 Sociologist GUI for Real-Time Visualization of Network 112.2.7 Behavior Portal Blogs . . . . . . . . . . . . . . . . . . 122.2.8 Behavior Portal Forums . . . . . . . . . . . . . . . . . 12

2.3 Priority 3 Functional Requirements . . . . . . . . . . . . . . . 122.3.1 Dynamically Distributable Behaviors . . . . . . . . . . 122.3.2 Runtime Profiling of Behavior Network . . . . . . . . . 132.3.3 Command-Line Runtime Configuration Plugin . . . . . 132.3.4 Sociologist GUI Runtime Configuration . . . . . . . . . 132.3.5 Sociologist Performance Modification GUI . . . . . . . 142.3.6 Behavior Portal Code Repository Searching . . . . . . 142.3.7 Behavior Portal Blogs Searching . . . . . . . . . . . . . 14

3 Non-Functional Requirements 153.1 Priority 1 Non-Functional Requirements . . . . . . . . . . . . 15

3.1.1 Language Requirement . . . . . . . . . . . . . . . . . . 153.1.2 Architecture Requirement . . . . . . . . . . . . . . . . 153.1.3 Operating System Compatibility . . . . . . . . . . . . . 153.1.4 Writing Standard . . . . . . . . . . . . . . . . . . . . . 15

1

3.2 Priority 2 Non-Functional Requirements . . . . . . . . . . . . 153.2.1 License Requirement . . . . . . . . . . . . . . . . . . . 153.2.2 Documentation Standard . . . . . . . . . . . . . . . . . 16

3.3 Priority 3 Non-Functional Requirements . . . . . . . . . . . . 163.3.1 Scalability Requirement . . . . . . . . . . . . . . . . . 163.3.2 Distributed Computing . . . . . . . . . . . . . . . . . . 16

4 Use Case Modeling 164.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 reDrawGraph . . . . . . . . . . . . . . . . . . . . . . . 174.1.2 updateData . . . . . . . . . . . . . . . . . . . . . . . . 184.1.3 listModules . . . . . . . . . . . . . . . . . . . . . . . . 184.1.4 unloadModule . . . . . . . . . . . . . . . . . . . . . . . 194.1.5 publish . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.6 recv . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.7 send . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.8 subscribe . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.9 postBlog . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.10 postToForum . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.1 inspectBehavior . . . . . . . . . . . . . . . . . . . . . . 224.2.2 loadModule . . . . . . . . . . . . . . . . . . . . . . . . 234.2.3 closeSocket . . . . . . . . . . . . . . . . . . . . . . . . 234.2.4 retrieveCode . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Requirements Traceability Matrix 24

6 Initial Snapshots 26

7 Contributions of Team Members 29

Glossary 29

1 Introduction

2

Title: Society: A Publish/Subscribe Framework for Behavior

Based Control

Name: Sebastian Smith, Senior

Ben Damonte, Senior

Lance Hutchinson, Senior

Jennifer Knowles, Senior

Mentor: Monica Nicolescu, Assistant Professor

Department: Department of Computer Science and Engineering

Abstract:

The behavior-based control paradigm is a mature method for implementing intelligent robot

controllers. This technique uses the interactions of simple behaviors to produce complex

emergent behaviors - a behavior that is observed externally that was not explicitly programmed

into the system. Typical controller implementations allow behaviors to communicate with each

other. The behavior network resulting from these interconnects provides added capabilities and a

high degree of decentralization, but significantly complicates implementation. To ease the

workload of developers of these systems we propose a framework called Society that utilizes the

publish/subscribe communication paradigm for dynamically creating behavior networks. This

architecture will allow developers to utilize complex interconnects without concern for the low-

level mechanics of communication. Removal of one of the most complicated elements of

behavior-based controller design - the behavior network - will allow developers to focus

primarily on design of individual behaviors. This shift of focus can provide many desirable

effects, including code reuse, more robust behaviors, exploitation of the distributed nature of

behavior-based systems, simplification of behavior network programming, and increased

network complexity. Herein we describe the publish/subscribe communication paradigm upon

which the Society architecture has been constructed, and its application to the behavior-based

domain.

4

Society: A Publish/Subscribe Framework for Behavior-based Control Sebastian Smith, Ben Damonte, Lance Hutchinson, and Jennifer Knowles

Department of Computer Science and Engineering, MS 171 University of Nevada, Reno, Reno, Nevada 89557

ssmith@cse.unr.edu

Synopsis Behavior-based systems are a mature method for robot control, but are often very difficult to implement. We present a framework, called Society, which uses the publish/subscribe communication paradigm to simplify the implementation of behavior-based systems.

Introduction Behavior-based systems are a proven method of robot control that uses the interactions of simple behaviors to produce complex behavior that was not explicitly programmed into the system. The term “behavior” is abstract, and may be defined as any simple function of a robot. Complexity arises from simple behaviors when they are interconnected into a network. Interconnections are very dynamic, allowing sequential and parallel execution, and the sharing of data. Unfortunately, this flexibility comes at a price: behavior networks significantly complicate the design and implementation of behavior-based systems, as developers must now focus on the creation of both behaviors and networks thereof. While each behavior is typically different, the same behavior interconnection mechanism is used in linking behaviors. Through the Society framework we aim to simplify this interconnection mechanism by introducing a general network programming tool so that developers can focus primarily on the creation of behaviors. We begin this document by discussing the motivations for the creation of Society. We then expand upon the publish/subscribe communication paradigm upon which Society is based. Then, we discuss Society as a solution to our motivations. Finally, an initial experiment to determine the scalability of the Society architecture is discussed.

Motivation There are three primary motivations behind the creation of the Society framework: simplification of behavior-based programming, increase in the complexity of behavior-based networks, and exploitation of the distributed nature of behavior-based systems. In traditional behavior-based control developers must explicitly create interconnections between each behavior. The leftmost image in Figure 1 represents a generic behavior network. Each behavior in this scheme is connected through bidirectional links with every other behavior. To

add a behavior to this network a developer must explicitly program 2

2 nn − interconnections,

where n is the number of behaviors in the network. Understandably, this approach is not scalable due to the large number of behavior connections. We propose to apply a publish/subscribe communication paradigm, which will result in minimizing the total number of interconnections,

5

thus simplifying the behavior network implementation. This approach is shown in the rightmost image of Figure 1. In this diagram a server-based (publish/subscribe) architecture is used. This model requires only one bidirectional interconnect per behavior added to the system, which is a considerable improvement over the growth rate of traditional behavior networks. Requiring only a single interconnection per behavior not only simplifies implementation of behavior-based systems, but also increases the number of supported behaviors.

Figure 1

As we identified previously, the complexity of designing behavior networks using the traditional method is significant, often limiting the number of total behaviors in a system, due to the large number of explicitly programmed interconnects. If the interconnections between behaviors are more complicated than the graph shown in the leftmost image of Figure 1, programming interconnects for a large number of behaviors may become far too difficult for a human to complete. By requiring only one interconnection per behavior the publish/subscribe communication paradigm can provide developers with a means of scaling behavior networks to unprecedented sizes, including thousands of behaviors, while requiring the same computational resources as traditional behavior networks. Since the scalability of behavior networks is greatly increased, exploitation of the highly distributed nature of behavior-based system will be critical to maintaining the performance of these systems. Behavior-based systems are naturally fit for distributed computation, as behaviors can work together in parallel, possibly while running on multiple hosts. This is a very desirable characteristic since robots often lack the computational power required for compute-intensive behaviors like face recognition. Since standard behavior interconnects are difficult to implement it should follow that implementing interconnections that robustly span multiple hosts is a more difficult task, especially when behavior response time is critical. Fortunately, the publish/subscribe communication paradigm provides the developer with one simple method of networking behaviors regardless of their location. All, behaviors, whether residing on a robot or on a foreign host will use the exact same method for connecting to a behavior network.

6

The Publish/Subscribe Paradigm Publish/subscribe is a high performance communication paradigm designed for use in large-scale, distributed applications [1]. This paradigm uses a central server to dynamically network producer and consumer subsystems. Unlike traditional communication paradigms that use direct interconnections, all components in the publish/subscribe paradigm are loosely coupled. This means that producers know nothing of the consumers they service, and vice versa. To facilitate the creation of dynamic networks publish/subscribe utilizes three components: the event notification system, the publisher, and the subscriber [1].

Figure 2

The Event Notification System (ENS) is the locus of communication within a publish/subscribe system. As can be seen in Figure 3, all publishers and subscribers in a system communicate directly with the ENS. As subscribers are added to the system they register their interest in specific events with the ENS. The ENS, in turn, creates an internal route from the publisher responsible for producing the desired event to the subscribing subsystem. An event is not limited to one subscriber. Rather, there can be an enormous number of subscribers associated with any one event. An example of this is illustrated in Figure 3, where there are two subscribers to one event. This system provides the loosely coupled nature of the publish/subscribe paradigm. In comparison to the event notification system, the publisher and subscriber components of this paradigm are considerably simpler. A publisher is any subsystem that produces an event, and a subscriber is any subsystem that consumes an event. While simpler in terms of communication, these two components are responsible for the overall behavior of the system.

Society The Society framework is an implementation of the publish/subscribe communication paradigm designed specifically for use with behavior-based systems. It is composed of two primary components: the Society Server, and the Society Client Application Programming Interface (API). The Society Server is an implementation of the event notification system from the previous section. It facilitates communication between all subscribed objects. The Society Client API is a tool for developers to easily subscribe elements to the Society Server. To use the Society Client API a developer simply states the inputs a behavior requires and the outputs it provides, then subscribes the behavior to the Society Server. The Society server then dynamically creates a virtual network between the outputs and inputs of behaviors.

7

Experimentation To test the scalability of the Society framework we designed an experiment to measure the real-time performance of the system with a large number of behaviors. Table 1 displays the results of this experiment run on three different computer architectures: an Intel Pentium-III clocked at 750MHz, an Intel Pentium-M 760 clocked at 2.0GHz, and Dual AMD Opterons clocked at 1.8GHz.

Table 1: Number of Behaviors Supported Behaviors at Different Real-time limits

Real-time limit 0.10s 0.2s 0.3s 0.4s

Pentium-III 750Mhz 150 300 350 400

Pentium-M 760 450 600 720 800

Dual Opteron 244 3000 X X X

The results show that the Society framework scales differently on different system architectures. Regardless of these differences in performance, the publish/subscribe communication paradigm allows for scalability of behaviors hard to achieve in traditional behavior networks. Even on the slowest machine, the Intel Pentium-III 750MHz we see support for over ten times the number of behaviors typically implemented in current behavior based systems.

Conclusion Behavior-based systems are a flexible means of robot control, but behavior interconnections make implementation of behavior-based systems difficult. By application of the publish/subscribe communication paradigm to behavior networks developers are able to simplify behavior network programming, easily distribute behaviors across different hosts, and increase the complexity of behavior networks.

Acknowledgements

Special thanks to Dr. Monica Nicolescu.

References

[1] Eugster, Patrick Th., et al. “The Many Faces of Publish/Subscribe” . ACM Computing Surveys. 2, June 2003. 114-131.

2 Functional Requirements

2.1 Priority 1 Functional Requirements

Requirements of Priority 1 are absolutely necessary for the success of theSociety project and will be included in the final release.

2.1.1 Behavior Subscription

The system shall provide a method to subscribe a behavior to theSociety Server. This mechanism will report all inputs and outputs of abehavior to the Society Server.

Rationale: Given the inputs and outputs of every behavior theSociety Server can dynamically create a network that relays theoutput of a given behavior to all interested behaviors.

2.1.2 Publish Data

The system shall provide a method for a behavior to publish datato the Society Server. This mechanism will send data to the SocietyServer using a routable network protocol.

Rationale: When a behavior issues a ”Publish” message to theSociety Server the payload data will be routed to all subscribedbehaviors.

2.1.3 Loading Plugins

The system shall provide a method for loading plugins during ex-ecution. This method will load plugins into the Society Server which willalter the way the server operates.

Rationale: The Society Server will be more flexible if plugins canbe dynamically loaded during execution. For instance, a debuggerplugin can be loaded into the server to make the server outputdebug information on a predetermined TCP port. This will allowexternal monitoring and debugging of Society during execution.

8

2.1.4 Unloading Plugins

The system shall provide a method for removing loaded pluginsduring execution. This will allow a completely dynamic plugin system tobe created. When a loaded plugin is no longer needed, it can be removedfrom the system without halting execution.

Rationale: When the need for the functions provided by a pluginare met, the plugin is no longer needed and should be removed.For example, when debugging information is no longer neededfrom the Society Server, the debug plugin can be removed.

2.1.5 Sociologist Plugin for Reporting Network Status

The system shall provide a plug-in method for reporting the statusof each network component. This method will allow the developer tooutput any debug data they desire.

Rationale: Debug capability is essential to the development oflarge scale, behavior based networks. Because the system is dis-tributable, it is imperative that the central server provides ameans of collecting this output.

2.1.6 Sociologist Listing Current Debug Data

The system shall provide a way to list current debug data. Thismethod will present the user with a list of behaviors that are currently re-porting debug data to the server.

Rationale: Users need to be able to see the debug data that eachbehavior is reporting.

2.1.7 Behavior Portal Code Repository

The system shall provide a code repository for the Society andSociologist software. This repository will provide a locus of open-sourcedistribution for Society and Sociologist.

Rationale: Society and its extensions are to be released underthe GNU Public License (GPL) for open public access and use.A repository provides a convenient, maintainable, and currentmethod for realizing this type of release.

9

2.1.8 Behavior Portal Documentation

The system shall provide documentation of Society and its exten-sions. This will allow for easy access to all available documentation for theproject. This method also allows for documentation updates to be immedi-ately available to consumers.

Rationale: As with any piece of software, providing documen-tation is an essential element in the project. Given the multi-faceted and ever evolving nature of this project, access to currentdocumentation is vital.

2.2 Priority 2 Functional Requirements

Requirements of Priority 2 are scheduled for inclusion in the project and willmake the Society project much more complete.

2.2.1 SSL Encrypted Network Communication Support

The system shall provide SSL encrypted network communication.This mechanism will allow the Society Server to communicate securely withall subscribed behaviors.

Rationale: Connections between the Society Server and subscribedbehaviors on a foreign host could be hijacked. Packets could beinjected into the network that cause unpredictable behavior ontarget robots. SSL encryption will protect Society communica-tion from attacks of this sort.

2.2.2 Tab Completion

The system shall provide tab completion - similar to the Bourne-Again SHell - in the Society command line interface.

Rationale: Tab completion will allow users to easily interface withthe host file system and functions of the command line interface.

10

2.2.3 GUI for Manipulating Plugins

The system shall provide a GUI for manipulating plugins. This GUIwill provide an easy-to-use interface to the Society Server. Here, a user willbe able to determine what plugins are running and be able to load and unloadplugins.

Rationale: A GUI-based plugin manager will be easier to use andmore productive than a command-line plugin manager.

2.2.4 Listing Loaded Modules Plugin

The system shall provide a way to list currently loaded modules.This method will present the user with a list of modules that are currentlyloaded in the system.

Rationale: Users need to be able to see what plugins are currentlyaltering the function of the Society Server in order to properlyanticipate the output of their programs.

2.2.5 Sociologist Plugin for Graphing Network Status

The system shall provide a plug-in method for graphing the currentstatus of the network. This method will display a graph of the behaviorsrunning in the system.

Rationale: Use of the Society system will be more effective ifdevelopers have a way of viewing the current status of variouscomponents of the network. This method will be able to showthe topology of the system as well as the status of each displayednode.

2.2.6 Sociologist GUI for Real-Time Visualization of Network

The system shall provide a GUI that will allow real-time visual-ization of the network. This GUI will provide a navigable view of thenetwork.

Rationale: A GUI-based network browser will be easier to useand more productive than producing static network snapshots.

11

2.2.7 Behavior Portal Blogs

The system shall provide developer blogs. This will allow the devel-opers to maintain regular records of their work throughout the project.

Rationale: Blogs of this type allow for community involvement asresearchers can maintain awareness of the progress of the project.Interest in the project may be maintained through this interac-tion. For instance, researchers may become disinterested in theproject if long periods of time elapse between releases. By usingthe blogging system, the community is kept informed about thedirection and progress of the project, and knows that the projectis still alive.

2.2.8 Behavior Portal Forums

The system shall provide online forums for use by the Society com-munity. This feature enables active community participation in the project.

Rationale: The community aspect of robotics research is vitalto this field’s development and growth. By providing a way forresearchers to openly discuss Society and related projects, interestin the project is enhanced, community knowledge is shared andbuilt upon, and the development team is made aware of the needsand interests of the community.

2.3 Priority 3 Functional Requirements

Requirements of Priority Level 3 are items that would make Society the mostcomplete, but are the most long term. These items may be included in thefinal release, but due to time constraints or other unforeseen circumstances,may be eliminated.

2.3.1 Dynamically Distributable Behaviors

The system shall provide the ability to dynamically distribute sub-scribed behaviors among different hosts. This mechanism will allowthe Society Server to unsubscribe a behavior from one host, download itfrom that host, transmit it to a different host, execute the behavior, andresubscribe it to the Society Server.

12

Rationale: Performance of the Society-based behavior networkcould be dynamically optimized using this method. For example,in a multi-agent system compute intensive behaviors could besent to robots that have a lot of idle compute cycles, allowing thenetwork to make better use of its compute resources.

2.3.2 Runtime Profiling of Behavior Network

The system shall provide the ability to profile the execution of thebehavior network at runtime. This mechanism will allow the SocietyServer offer suggestions as to how a developer may rearrange a network toyield better performance.

Rationale: The use of runtime profiling with dynamic distribu-tion of behaviors will allow the system to rearrange the networkdynamically for best performance.

2.3.3 Command-Line Runtime Configuration Plugin

The system shall provide a full command-line shell to configure theserver during execution. This would provide a more dynamic usabilityto the server than setting options at runtime or compile-time.

Rationale: Users can dynamically configure Society without hav-ing to stop the Server and re-read configuration files or recompile.This allows for faster development and makes the software moreuser-friendly.

2.3.4 Sociologist GUI Runtime Configuration

The system shall provide a full GUI shell to configure the serverduring execution. This GUI would provide the same functionality as thecommand-line shell, only it would be presented in a graphical environment.

Rationale: The learning curve for a GUI shell would be fasterthan that of a command-line shell.

13

2.3.5 Sociologist Performance Modification GUI

The system shall provide a GUI that will allow the user to changethe performance of the system. This GUI will provide a means of chang-ing the network topology during runtime. This method should allow the userto change behavior dependencies, and allow the user to ’drag’ behaviors fromone physical machine to another.

Rationale: A visual, adaptive means of modifying network struc-tures would greatly increase productivity.

2.3.6 Behavior Portal Code Repository Searching

The system shall provide a search function for browsing the coderepository. This would enable users to find downloads more quickly.

Rationale: Manually browsing through large repositories of codecan be a time consuming and frustrating process. This processcan be enhanced by allowing the user to search for the name ortopic of the file and go directly to that download. For instance,if a user wishes to download a particular module, it may takesignificant time to browse through all available modules, but asearch can find the module in seconds.

2.3.7 Behavior Portal Blogs Searching

The system shall provide a search function for the developer blogs.This function would allow users to quickly find updates relating to certainparts of the project that interest them.

Rationale: Browsing through days, months, or years of blogs tofind updates on a certain part of the project is a tedious andtime consuming process. This process can be made practical bysearching for keywords in the blogs.

14

3 Non-Functional Requirements

3.1 Priority 1 Non-Functional Requirements

3.1.1 Language Requirement

The system shall be implemented using C++. The system will compileusing the GNU Compiler Collectionss C++ compiler, g++.

3.1.2 Architecture Requirement

The system shall run on the Intel IA32 hardware platform. Thewidely used Intel 32-bit x86 architecture will provide high compatibility forusers of the Society API.

3.1.3 Operating System Compatibility

The system shall run on the GNU/Linux operating system. Theopen-source nature of Linux, combined with the large Linux focus in highperformance, scientific computing makes it a perfect choice for the develop-ment and use of the Society API.

3.1.4 Writing Standard

All written documents shall be formatted using LATEX. The useof LATEX enables automation of many tedious tasks such as Table of Con-tents generation, Lists of Figures, Glossary creation, etc. LATEX is also anextremely portable format that can be easily exported to many documenttypes such as PDF, HTML, PostScript, etc.

3.2 Priority 2 Non-Functional Requirements

3.2.1 License Requirement

The system shall be released under the GPL. The GPL license providesan open-source platform allowing for other developers to contribute to theSociety project.

15

3.2.2 Documentation Standard

The system shall be documented using Doc++. Doc++ will providea central documentation repository that can be easily updated with codechanges and is easily ported to many media types including print and web-based publications.

3.3 Priority 3 Non-Functional Requirements

3.3.1 Scalability Requirement

The system shall be scalable. Through the use of POSIX threads, thesystem will be able to scale on a single or multi-CPU system while maintain-ing simulated parallelism.

3.3.2 Distributed Computing

The system shall be usable in a distributed or parallel environment.Implementation of communication using TCP/IP sockets will enable a Soci-ety based program to be run on a multiple-machine distributed computingenvironment or cluster.

4 Use Case Modeling

See Figure 1 for a Use Case Diagram. 10 Detailed use case templates arelisted below.

16

Figure 1: Use Case Diagram

4.1 Use Cases

4.1.1 reDrawGraph

17

4.1.2 updateData

4.1.3 listModules

18

4.1.4 unloadModule

4.1.5 publish

19

4.1.6 recv

4.1.7 send

20

4.1.8 subscribe

4.1.9 postBlog

21

4.1.10 postToForum

4.2 Scenarios

4.2.1 inspectBehavior

22

4.2.2 loadModule

4.2.3 closeSocket

23

4.2.4 retrieveCode

5 Requirements Traceability Matrix

24

Figure 2: Requirements Traceability Matrix

25

6 Initial Snapshots

Initial Snapshot 1: The interface for the Society Debug Visualizer. Thissnapshot shows the basic interface as well as a sample network.

26

Initial Snapshot 2: The interface for the Society Debug Visualizer. Afterthe blue ’info’ button is pressed, the system will display the debug data forthe selected behavior. The data for ’behavior 4’ is shown above.

27

Initial Snapshot 3: The interface for the Society Plugin Manager. Here wehave the functionality to Load, Unload, and List currently loaded modules.The function of each button is provided in the status bar as a tooltip whenthe mouse rolls over the button.

Initial Snapshot 4: The dialog which opens upon clicking the ”List Mod-ules” button in the main program window. Here, all currently running Soci-ety plugins are listed. The OK button returns to the main window.

28

7 Contributions of Team Members

Jennifer Knowles: functional requirements, detailed scenario and detaileduse cases for the Behavior Portal, contributions of team members, glossaryaddendum, requirements traceability matrix, document compilation and for-matting. Sebastian Smith: NURS introduction, references, use cases for So-ciety Server and Society Client API. Ben Damonte: functional requirements,detailed scenario and detailed use cases for Sociologist, UML, use case imagecreation, snapshots 1 & 2. Lance Hutchinson: functional requirements, de-tailed scenario and detailed use cases for the plugin architecture, snapshots3 & 4.

Glossary

actuator: A mechanism that puts something into action such as drive motors,grippers, etc.

Behavior Portal: A web-based portal for behavior-based developers.

behavior-based robotics: One of three dominant robot control paradigms.Behavior-based controllers consist of a structured network of interact-ing behaviors [1].

behavior: A process or control law that achieves and/or maintains goals.

buffer: An object used to pass information between sensor, actuator, andcontrol entities in the Society API.

contextual data: Data stored in buffers and used by behaviors will conformto the context in which it is needed. e.g. sonar data vs. laser data.

distributing: Assignment of a single job to processors spread across multiplephysical machines.

Latex, LATEX: A set of formatting macros built on top of the TEX type-setting language.

Linux: A trademark for an open-source version of the UNIX operating sys-tem.

29

parallel: The simultaneous performance of multiple operations.

Player: An open-source robotic device interface. http://playerstage.sourceforge.net

plugin, plug-in: A modular object which can be dynamically linked into aprogram to provide extra functionality. Given adequate specifications,plugins can be developed by a third-party without access to or thor-ough knowledge of the program’s source code.

portal: A website offering useful services and information to a large commu-nity.

repository: A central location for storage and retrieval of data, such as sourcecode and documentation, which is to be shared among a communityof users.

robot: A mechanical device that sometimes resembles a human and is capableof performing a variety of often complex human tasks on command orby being programmed in advance.

sensor: A device that receives and responds to a signal or stimulus such asa camera, laser, or sonar range-finding.

socket: The Berkeley Unix mechanism for creating a virtual connection be-tween processes.

subscribe: To request to receive messages sent to the buffer.

thread: A portion of a program that can run independently of and concur-rently with other portions of the program.

time quantum: Amount of time given to each thread for execution.

References

[1] Mataric, Maja. Behavior-Based Control: A Brief Primer. USC Centerfor Robotics and Embedded Systems.<http://www-robotics.usc.edu/ maja/bbs.html> .Description: This site, created by a leading researcher in behavior-based robotics, contains a brief definition of behavior-based control. It

30

also contains links to some of Maja’s papers – many of which can beindirectly related to the Society framework.

[2] Breazeal, Cynthia. A Motivational System for Regulating Human-Robot Interaction.Artificial Intelligence Laboratory, Massachusetts Institute of Technol-ogy. <http://web.media.mit.edu/%7Ecynthiab/Papers/BreazealAAAI98.pdf>

Description: This paper describes the behavior-based motiva-tional system used on the Kismet robot. Kismet is used in human-robotinteraction research.

[3] Seraji, Homayoun. Behavior-Based Robot Navigation on Challenging Terrain:A Fuzzy Logic Approach. IEEE.<http://ieeexplore.ieee.org/iel5/70/21926/01019461.pdf> .Description: This paper describes a behavior-based learning agent fortraversing challenging terrain. It is used in conjunction with robots todetermine if they can traverse terrain.

[4] Rodney Brooks. A Robust Layered Control System For A Mobile Robot.IEEE.<http://www.cse.unr.edu/m̃onica/Courses/CS493-790/PapersPDF/Brooks ARobustLayer.pdf> .Description: This paper describes the subsumption architecture.Modern behavior-based control inherits many qualities from thesubsumption architecture.

[5] Player/Stage Project. 12 September 2005.<http://playerstage.sourceforge.net> .Description: This is the homepage of the Player/Stage Project. Playeris the robot device interface we will be building our API on top of.

[6] Gerkey, Brian P., Maja J. Mataric. “Murdoch: pub-lish/subscribe task allocation for heterogeneous agents”.Internation Conference on Autonomous Agents Proceedings of thefourth international conference on Autonomous Agents (2000): 203 –204.Description: Murdoch utilizes the publish/subscribe communicationparadigm for dynamically distributing tasks among multiple robots.This architecture is similar to Society, but is implemented at a higherlevel of abstraction. This as a successful architecture.

31

[7] Eugster, Patrick Th., et al. “The many faces of publish/subscribe”.ACM Computing Surveys 35.2 (2003): 114 – 131.Description: This paper describes the publish/subscribe communica-tion paradigm, and common implementation methods. This paper isplaying a critical role in the development of the Society Server.

[8] Arkin, Ronald C. Behavior-based Robotics. MIT Press, 2000.Description: This book describes the behavior-based robot controlparadigm. It is this paradigm that we will be using the Society frame-work to model.

32