Agent-Based Control and Communication of a Robot Convoy K. Kawamura, D.M. Wilkes, S. Suksakulchai, A. Bijayendrayodhin, K. Kusumalnukool Center for Intelligent Systems, Vanderbilt University Nashville TN 37235-0131 USA
[email protected] Abstract The design and operation of a user-centric humanrobot interface is key to control and communication for a team of heterogeneous mobile robots moving in a geographically dispersed area. The Center for Intelligent Systems (CIS) at Vanderbilt University is conducting research and development into an agentbased human-robot interface (HRI) involving HelpMate and Trilobot mobile robots. The proposed approach is user-centric and based on concepts from supervisory control. This paper presents our method for multi-robot navigation and control, as well as a communication strategy. Additionally, our Robot Convoy testbed, consisting of a team of heterogeneous robots, is described. Finally, a system status evaluation subsystem is proposed for robust system operation. Key Words: Agent-based system, Intelligent Machine Architecture, human-robot interface, supervisory control, Robot Convoy 1.
Introduction The design and operation of user-centric humanrobot interface is key to control and communications of a team of heterogeneous mobile robots moving in a geographically dispersed area. The Center for Intelligent Systems (CIS) at Vanderbilt University is conducting research and development into agent-based human-robot interface (HRI) under a DARPA sponsorship. It is user-centric, i.e. the user called the Commander Agent will use the HRI screen to supervise the movement of the robots. It is agent-based since control and communication among the human operator and robots are imbedded within an agent-based parallel, distributed robot control architecture called the Intelligent Machine Architecture (IMA) [1]. It is supervisory [2] since the human operator specifies the path for the robot to take and the robot use sensors and internal maps.
2.1 Taxonomy of IMA Agents A brief description of two kinds of IMA agents is given below. Atomic Agents: There are four basic types of atomic agents, plus there is a fifth type that exists as a concession to realistic implementation considerations. 1. Hardware/Resource Agent: Interface to sensor or actuator hardware. Those interfacing to sensors can provide other atomic agents with regular updates of sensor data. Those interfacing to actuators accept commands from and provide updates of current state to other atomic agents. 2. Behavior/Skill Agent: Encapsulate basic behaviors or skills. 3. Environment Agent: Provide an abstraction for dealing with objects in the robot’s environment. This abstraction includes operations that the robot can perform on the object – e.g., “look at.” 4. Sequencer Agent: Perform a sequence of operations; often interacting with one or more environment atomic agents or activating and deactivating one or more atomic agents. Sequencer agents may call other sequencer agents, but there should be an identifiable highest-level sequencer agent. 5. Multi-Type Agent: Combine the functionality of at least two of the first four agent types. For example, in the interests of efficiency of implementation it may be advantageous to combine the hardware and behavior types into a single multi-type agent. Figure 1 shows examples of atomic agents that were built for the HelpMate robot.
Move-to Goal
Camera Pan-Tilt
Follow Path
Coordinate Convoy
Camera
Compass Pause
Move to Point
Joy Stick
Sonar
Laser
2.
The Intelligent Machine Architecture (IMA) The Intelligent Machine Architecture (IMA) is an agent-based robot control architecture [1]. It was initially designed for a humanoid robot system called ISAC [3, 4, 5]. We are applying IMA to the mobile robot navigation problem in order to test the robustness of the software architecture across different types of robot applications.
Odometry Open Space
Generate Path
Stop
Gyro Base
Avoid Obstacle
Resource Behavior/Skill
Land Mark
Obstacle
Activator
Environment Sequencer
Figure 1: Examples of atomic agents for the HelpMate Robot
Compound Agents: An IMA Compound Agent is an interacting group of atomic agents that are coordinated or sequenced by one or more sequencer agents. The highest-level sequencer agent can be envisioned as the root node of a tree with connections and dependencies on other agents on branches. The decomposition of an agent-based system into compound and atomic agents is not unique; it depends on the context of the problem and on the choice of robot architecture for the particular task or behavior. 3.
An Agent-Based HRI Approach Under the IMA architecture, we are employing user-centered interface as a means of designing Graphical User Interface (GUI) for display and control of mobile robots including their sensors. We accomplish this through an agent-based GUI window, which includes a cognitive agent called the Commander Agent. The Commander Agent acts both proactively and reactively. It is proactive in the sense that when the user logs-in, the Commander Agent will check if the user used the system before, and if so, will bring up his/her customized GUI screen. If the user is new, the Commander Agent will ask questions to set up an initial GUI screen. The Commander Agent is reactive in the sense that if the user requests any data on the status of the robot such as the position and the direction the robot is moving, or any specific sensor data, the Commander Agent will retrieve and display the data on the GUI screen. Figure 2 illustrates our agent-based HRI approach.
Self Agent Commander & GUI Agent Interpreter Agent
Command I/O and Status Agents
User Identification Agent
Commands
Commander Agent
Activator Agent
Activ ate & Deact ivate
Performance Agent
Status Information
GUI Agent
Env. & Atomic Agents
Base
Description Agent
Commander-Robot Interface
Command Post
3.1 Self Agent The Self Agent is a compound cognitive agent that activates and maintains the activities of the robot itself. It receives high-level commands from the commander Agent and decomposes them into a set of executable commands. The Self Agent also monitors the system performance and reports significant errors back to the commander Agent. The Self Agent consists of: i) Command I/O and status Agents: The agents that communicate with the Commander Agent. ii) Description Agent: The agent that provides information about other agents in the system, i.e., agent name & job description, active/inactive and success/error/ not executed. iii) Performance Agent: The agent that monitors other agents and reports significant errors to the Commander Agent iv) Activator Agent: The agent that activates the set of agents necessary for a specific goal or task. v) Interpreter Agent: The agent that decomposes high-level commands into a set of executable commands.
Resource Agents
GPS Lidar
SSE
Figure 3: Self Agent
Commander Agent
SES
LES
Off-Line Planning Peer Agent
Egosphere Manager
Commander Interface Agent
A
A
A
Self Agent
Atomic Agents A
A
A 2 on-boards
DBAM Manager Path Planning
Figure 3 shows the data flow among the agents, with an emphasis on communication with the Self Agent. The Command I/O and Status Agents communicate with the Commander Agent. After receiving a highlevel command, the Command I/O and Status Agents send the command to the Interpreter Agent for translating the command into executable commands. The Activator Agent sends the executable command to activate the necessary atomic agents. Finally, the Performance Agent gets status information from the atomic agents in the robot, and then sends their status to the Description Agent to collect and provide this information for feedback to the human.
Peer Agent HelpMate
Trilobot
DataBase Associative Memory
Robot Convoy IMA Agents
Figure 2: Agent-based HRI Approach
3.2 Peer Agent While each robot has a Self Agent to represent its own internal status, Peer Agents are used to represent the other robots of the team. Thus within a robot there is one Self Agent and possibly many Peer Agents, one Peer Agent for each of the other robots. The Peer
Agents handle all communication to and from their respective robots. They can be thought of as representing the Self Agent of the other robots. The Peer Agent is a way to standardize information sharing between robots. Robots with different configurations will be able to understand the information from any other robot’s Peer Agent. For example, Sensory-EgoSphere (SES) [6] are abstract memory structures describing the sensed environment around the robot (see Appendix A for an example of SES). These may be shared between robots and understood by each robot. Similarly, general status information regarding a robot may readily be shared. Additionally, the Peer Agents can be used to broadcast a “heartbeat” signal, to inform the other robots and the commander that the robot is still functioning and communicating. 4.
Multi-Robot Navigation Control Architecture We use supervisory control [2] for multi-robot navigational control [7, 8, 9, 10]. Figure 4 illustrates the entire multi-robot navigational control architecture. 2 onboards
Status, Sensor Readings
Link to Performance Link to Performance
Commands
Link to Description
HelpMate
Subsumption Move-to-Goal
Sensor Evaluation Pause Lidar Eva.
Sonar
S Follow-Path
Sonar Eva.
Commander
Leader Robot
S
Odo
Avoid Obstacle Move-to-Point
S S
Odo Eva.
Status, Sensor Readings
Sensor Lidar
Base Drive
World
Task Commands/ Overdrive
cannot complete the task, it will report to the commander and wait for assistance. The squad robot is assumed to be less capable than the leader robot. In our case, it only has three simple behaviors, e.g., Move-toPoint, Seek Light, and Reach Target. Because of the squad robot’s limited capability, we have not designed any cooperative task execution scheme. Right now, the commander can send the squad robot a simple command such as Reach Target by giving an estimated position of the target. This command will be sent via the leader robot. After the squad robot successfully reaches the target, the leader robot may give a new task. 5.
Communication Among Mobile Robots The human-robot team under consideration consists of a human commander, a leader robot, and several squad robots. As shown in Figure 5, the operator is the commander, HelpMate is the leader robot, and the small Trilobot robots are the squad robots. This human naming scheme suggests a certain structure, and thus communication connectivity, in the hierarchy of the team. The commander is at the highest level of the hierarchy and is connected to the leader robot by a communication channel. The leader robot maintains a communication channel to each of the squad robots. This implied a set of connections represents a minimal set of communication channel connections for a functioning team. Robot 1 Env. & Atomic Agents
The control architecture for HelpMate Navigation
Resourc Base e Agents Sonar
Self Agent 1 Commander & GUI Agents
Performan ce Agent
Trilobot
Link to Performance
Link to Description
User Identificatio n Agent GUI Command Agent er Agent
Squad Robot
Subsumption
Lidar Command I/O and Status Agents
Activation Agent Descriptio n Agent
Sensor Evaluatio n
Sequencer Atomic Agents Localizatio n
Via Points
Reach Target Sensor Camera
Find Target
Light
Seek Light
Odo
Move-to-Point
Goto
Status, Sensor Readings Peer 2
Peer n
Base Drive
IMA Agents World
Robot 2 Robot n-1 Robot n Peer A Peer B
The control architecture for Trilobot Navigation
Ethernet
Self Agent 2
Self Agent SelfAgent nn
Peer k 1 Peer
Figure 4: User-Centric Multi-Robot Navigation Control Architecture
Peer n
Peer 1
Peer k Peer 2
Modem Modem
Software Part Hardware Part
First, the commander specifies a mission including tasks, paths, robots etc., for the robot team based on the current mission and the sensor readings and sends the mission to the Self Agent within the leader robot (see Figure 7). The Self Agent then activates an appropriate set of behaviors such as, Move-to-Point, Avoid Obstacle, Follow-Path, etc. The commander has direct control over the leader robot, while he may only have indirect control over the other robots, the squad robots. The sensor data from the leader and the squad robots are sent to the commander through an external feedback loop. The commander will use that information to modify the goal or design a new task. If the leader robot
Figure 5: Communication Network for the multi-robot system The Commander Agent is responsible for presenting the system status and sensory data to the human commander (via the GUI). As described elsewhere, heartbeat signals can be sent from the squad robots to the leader robot. Each robot will have its own Self Agent representing the robot’s individual information, and will have Peer Agents representing the other robots’ information. For example, if the team consists of HelpMate and two Trilobot robots, then Helpmate will have its own Self Agent and two Peer Agents
representing each Trilobot Self Agent (see Figure 5). Since the leader robot and squad robots are connected to each other by Ethernet network, the commander will be able to observe the information the robots are sharing. Jung and Zelinsky [11] gave an interesting approach to communication between robots using layering solutions. Their protocol is robust when dealing with an uncertain environment but it becomes more complex with increasing layers. Our approach is based on a flat, one-layered communication protocol to avoid some of the complexity in layered protocol. When Trilobot senses an object and wants to share the information, it will generate its own SES and sent back the symbolic description of the object (i.e., a red ball, a green cone etc.) and direction with respect to itself back to the Helpmate through its Peer Agent. The leader robot (Helpmate) with the same symbolic representation will be able to process the new data sent by Trilobot and update its map. 6.
Testbed Robot Convoy To evaluate our system concept, a testbed robot convoy team with heterogeneous mobile robots was used (see Figure 6). Such a team of robots has distinct advantages over a single robot with respect to sensing and mobility.
will be located in Territory 1 of the graphical user interface. The Helpmate robot carries a squad of robots in a convoy configuration. The squad, or Trilobot robots, is carried in a cart behind the Helpmate robot. Helpmate initially waits for instructions from the commander about which direction to navigate. The commander specifies the instructions to the Helpmate using the Mission Planning Agent as shown in Figure 7. After the leader robot receives the mission, the Helpmate robot begins to traverse the course from the home position to the destination. The destination is located in Territory 2. The Helpmate is unable to complete the navigation because the opening in the wall at the border of Territory 1 is too small. The leader robot then opens its cart door to release the Trilobots to enter Territory 2 and explore. The Trilobots mission will be to locate predetermined landmarks in this territory using sensors, such as the camera and sonar. These landmarks will be used in order to find a target object. The Trilobot will post the location of the located target to its SES and also send the location of these objects to the Helpmate. Helpmate subsequently posts the details about the objects to its global map. After the squad of robots has located several landmarks, the commander will then recall the squad to the Helpmate. The Helpmate will then return to the home position carrying the squad of robots. Name: Select Predefined Mission
Add Mission: Add a new mission
Main: Load Robot File, Settings
Mission Control: Load & Save Mission Edited Undo Last Task Select a Mission Plan
Robot: Select a robot used in mission
Mission’s Tasks: Resulting Scripts for a mission
Task’s Specification: Tasks that each robot can perform
Room
Room
Room
Sofa
Figure 6: Robot Convoy
Room
Room
Table
Transportation Cart
HelpMate
Territory 1: Known Environment
The robot convoy was deployed in two Territories as shown in Figure 7, • Territory 1 is a known area, and Helpmate can easily navigate its way to the given location assigned by the commander. • Territory 2 is only partially known and inaccessible to the large robot, so a smaller robot will be needed to explore this area. The home position for the leader robot, Helpmate,
Room
Table
Target Cones
Territory 2: Partially Known Environment Office
Table
Table ISAC
Known Position Cones Table
Figure 7: The Graphical User Interface for ScriptBased Mission Planner and Navigation Plan
7.
System Performance
7.1. Performance Metrics In an interactive human-robot system, the question of good performance as opposed to bad performance does not have a simple answer. From an overall system point of view, we can say that our basic goals are to execute the mission successfully and efficiently and to reduce the control burden on the human operator. Some performance metrics that yield information related to these goals are: 1. Percentage of successful missions – measures the robustness of the approach. 2. Number of commands issued by the commander during the mission – measures the burden placed on the commander. 3. Time to complete the mission – this measures overall efficiency. 4. Measure the physical, emotional, and intellectual fatigue in the commander. While these metrics are suitable for evaluating the approach over a set of missions, it is typically not suited to evaluating performance during the process of executing a mission. However, an overall mission plan is necessarily decomposed into a set of sub-goals. The first three performance metrics mentioned can be applied to the completed sub-goals to evaluate current mission performance. Additionally, other metrics can be used within the execution of a sub-goal. We propose a system status evaluation paradigm, which we describe next. 7.2 System Status Evaluation In any system, errors are situations that cannot be avoided, so it is necessary to have a status monitor to detect the errors that occur. The System Status Evaluation (SSE) [12] resembles a nervous system in that it is distributed throughout most or possibly all agents in the system. At the top is the Performance Agent as shown in Figure 8. Throughout the rest of the system there are components and agents that measure the performance at lower levels. All the information “percolates upward” to the Performance Agent where a high level interpretation can be made. From our experience, the categories of errors are as follows:
system should be able to notify the commander that it needs assistance. 2) Linking Error: Because our systems are fully distributed, links, e.g., numeral links, text links and image links, between agents are indispensable and the system needs to identify this error as soon as possible. 3) Hardware Error: The resource agent(s) connected to the hardware may stop responding or fail to work properly. There are two types of errors that can occur: a) Hardware Not Responding: If the hardware is not responding to command inputs, it needs immediate attention from the commander. To notify the commander or the master robot, the resource agent will send various heartbeat signals according to the health of the hardware; like our heartbeat rhythm when we are in different conditions. b) Hardware Not Working Properly: Hardware may fail in some spots and the hardware controller is sending an erroneous signal. By inspecting our system, the controller for the sensor produces errors in two ways: constant data and rapidly changing data. We will use this behavior for detecting the error. We have been developing Performance Analyzers for both low and high levels. In the Low-Level Performance Analyzer (LLPA) [12], pervasive communication among agents is the key to the analysis. By recording communication timing between agents, and by using statistical measures of the delay, an agent can determine the status of another agent. The LLPA can be used to detect sensor errors and loss of communication among robots including computer and battery failures, and it is used to detect Operational errors using internal closed-loop feedback (individual information inside an agent is used). Parts of Self Agent Report (via the I/O agent)
SSE: Agent Status Report
Operational Status
Operational Status
Link Status
Commander Agent
Series of Tasks (via the I/O agent)
Activation Agent
Seq. Agent n Seq. Agent 3 Seq. Agent 2
Sequencer Agent 1
Performance Agent
Operational Status
1) Operational Error: The system cannot complete its task at a specific time. There are at least two possible things that can produce these errors: a) Communication Errors: If a signal cannot get through to the destination agent, the system will keep trying to deliver the message, and the other agents will “freeze up”. b) Environment Changes: If the environment changes, while the robot is executing a task, it is possible that this change may prevent the robot from achieving its goals. In such a case, the
SSE: Agent Status Report
Link Status
SSE: Agent Status Report
Atomic Atomic Agent Agent Atomic Atomic Agent Atomic Agent Agent
Operational Links Linking Links Hardware Links
Hardware Status
SSE: Sensor Evaluation Link Status
Activation
Figure 8: Performance Agent However, this performance analyzer cannot be used to detect all possible operational errors. In these situations, all the systems are working properly, but the
goal cannot be achieved within an expected time, and the system keeps trying at the normal rate or with the same action. The High-Level Performance Analyzer (HLPA) will be used in this situation to keep track of all the tasks and to inspect the progress of the mission, including robots getting stuck, using information from timing, affect, closed-loop feedback and other highlevel resources such as the SES/LES, Peer Agents, Commander Agent and DBAM (see Figure 2). If progress toward the goal does not improve as time increases, then new actions are necessary. The method for selecting the new actions is an ongoing research activity and will be based on our system decomposition in Figure 2. 8.
Conclusions The design and operation of a user-centric humanrobot interface is key to control and communications for a team of heterogeneous mobile. We have presented a user-centric human-robot interface for supervisory control of a group of mobile robots. The particular system we propose is an agent-based system containing a Commander Agent, a Self Agent and Peer Agents, representing other robots in the team. The Commander Agent and the Self Agent have been described in some detail. These agents are developed using the Intelligent Machine Architecture, and interact with the other IMA agents that comprise the rest of the system. The evaluation of the performance of the proposed usercentric supervisory control system is underway using a heterogeneous robot convoy testbed. This work has been sponsored in part by a grant from DARPA/MARS (Grant #DASG60-99-1-0005). References [1] Pack, R.T., et al, “A Software Architecture for Integrated Service Robot Development”, 1997 IEEE Conf. on Systems, Man, and Cybernetics,
Appendix A
Orlando, pp.3774-3779, September 1997. [2] Sheridan, T. B., “Telerobotics, Automation, and Human Supervisory Control”, MIT Press, 1992. [3] Kawamura, K., et al, “Intelligent Robotic Systems in Service of the Disabled”, IEEE Transactions on Rehabilitation Engineering, v.3, pp.14-21, 1995. [4] Kawamura, K., et al, “Design Philosophy for Service Robots”, Robotics and Autonomous Systems, v.18, pp.109-116, 1996. [5] Wilkes, D.M., et al, “Designing for Human-Robot Symbiosis”, Industrial Robot, 6:1, pp.49-58, 1999. [6] Kawamura, K., Peters II, R.A., Johnson, C., Nilas, P., Thongchai, S., “Supervisory Control of Mobile Robots using Sensory EgoSphere”, Submitted to the 2001 IEEE Int. Sym. on Computational Intelligence in Robotics & Automation, CAN, July 2001. [7] Murphy, R.R., “Introduction to AI Robotics”, MIT Press, Cambridge, MA, 2000. [8] Mataric, M. “Designing and Understanding Adaptive Group Behavior”, Adaptive Behavior 4:1, pp.51-80, December 1995. [9] Billard, A., et al, “Adaptive Exploration of a Frequently Changing Environment by Group of Communicating Robots”, Proc. 7th European Conf. on Artificial Life, ECAL'99, Lausanne, Sep. 1999. [10] Dixon, K., Dolan, J., Huang, W., Paredis, C., Khosla, P., “RAVE: A Real and Virtual Environment for Multiple Mobile Robot Systems”, Proc. of the 1999 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems, vol. 3, pp. 1360-1367, 1999. [11] Jung, D., and Zelinsky, A., “Ground Symbolic Communication between Heterogeneous Cooperating Robots”, Autonomous Robots, vol. 8, pp. 269-292, 2000 [12] Alford, W.A et al, “System Status Evaluation: monitoring the state of agents in a humanoid
Appendix B
Figure 9: Example of Sensory EgoSphere for Trilobot Figure 10: GUI of a Script-Based Mission Planning
system”, Proc. IEEE Systems, Man and Cybernetics, Nashville, TN, v.2, pp.943-948, Oct. 2000.
