IMPLEMENTING MULTIPLE ROBOT ARCHITECTURES USING MOBILE AGENTS L. M. Cragg and H. Hu Department of Computer Science, University of Essex, Wivenhoe Park, Colchester, CO4 3SQ E-mail: {lmcrag, hhu}@essex.ac.uk Keywords: mobile agents, multiple telerobots, remote control Abstract In this paper we propose a mobile agent architecture for the remote control of multiple mobile robots (via the Internet, subject to indeterminate delay and limited bandwidth). We employ intelligence at the remote robot side in order to facilitate efficient control. Two experiments are presented to support our architecture design, and to show how, due to its implementation in a mobile agent development environment, it is flexible adaptable and intuitive. 1 Introduction Internet robot systems use Internet Software Protocols (e.g. TCP/IP) for communication between system components, and Internet Communication Infrastructure as transmission hardware. Such systems are widely accessible (via standard web browsers), and cost effective (using low cost off the shelf components). Many Internet based robot systems have been developed recently, e.g. KhepOnTheWeb [4], University of Essex TeleRobot [9] and Multiple Foraging Robots [7]. Most of these systems employ a Client/Server based Architecture in which Direct Control Commands (e.g. left, right, faster, slower, etc.) are sent between Client (User) and Server (Robot) across the Internet. Some systems employ semiautonomous behaviour at the robot side to increase robot intelligence, allowing a user to control a robot at a higher level of abstraction (e.g. waypoints), leaving an intelligent robot controller to coordinate low level behaviour (as found in the Internet Robot Xavier [4]). Mobile Agents are goal driven and autonomous, can be reactive, adaptable, dynamic, temporally continuous, operate asynchronously, communicate, and learn [8,6]. Because they can provide all of these characteristics and move from place to place, mobile agents can provide the functionality found in all other distributed computing architectures, combined in a unified development environment. They also provide a natural design philosophy for distributed computing systems compared to amalgamations of other distributed computing paradigms, which can require complex interconnected networks of heterogeneous computing nodes to provide the same functionality. Mobile agents offer many positive characteristics which have not been widely employed in multiple robot control. In this paper we show how mobile agents can aid in the development of architectures for multiple robot control. The rest of this paper is structured as follows. Section 2 provides Background Information on Mobile Agents. Section 3 describes our Architecture and Hardware/Software Environment. Section 4 describes Experiments conducted to support our design. Section 5 provides a Description and Analysis of Experiment Results and Discussion. Section 6 provides Conclusions and Future Directions for our work. 2 Previous Work on Mobile Agents 2.1 Mobile Agents vs. Distributed Computing Paradigms Figure 1 highlights the main difference between Mobile Agents and all other distributed computing paradigms. In Client/Server, Remote Computation and Code on Demand, communication occurs across a communication medium between structurally heterogeneous sites. Such communication can involve requests for task execution or knowledge, the transportation of knowledge, or the movement of task results. Multiple exchanges may occur via the communication medium in the course of an interaction. Figure 1: Distributed Computing Paradigms In contrast, communication in the Mobile Agent Paradigm mainly occurs locally between mobile agent and computing services at any one of a number of structurally homogeneous sites (i.e. Agent Servers). A communication medium is employed by the mobile agent to migrate to the source of services, however subsequent task communication usually occurs locally. This allows mobile agents to improve task execution and efficiency in Internet applications by reducing Internet communication and therefore delay.
2.2 Mobile Agent Execution Environment Mobile Agents exist within an execution environment provided by multiple agent servers as shown in Figure 2. Agent servers provide areas known as places in which an agent can reside and interface with functionality provided by the server and host computer. Most agent servers and mobile agents are written in Java, which as an interpreted computer language is executable on heterogeneous computer platforms. Multiple host computers provide a distributed (but unified) mobile agent execution environment, in which places can be uniquely identified using host IP addresses. Agent servers may contain multiple places so that mobile agents can simultaneously migrate. Basic mobile agents are lightweight computing components, because many of the functions which they execute are provided by agent servers in a function library e.g. agent creation, destruction, cloning, migration and fault tolerant storage to a computer hard drive. Mobile agents can make use of many communication mechanisms for remote communication including sockets, RMI and CORBA. However, agent migration and local communication are more often employed. 2.4 Multiple TeleRobot Control In order to test different types of control mechanism, Ali [2], developed a taxonomy of multiple telerobot tasks as shown in Figure 3. Tasks are classified based on movement types which multiple telerobots might be expected to achieve. Tasks can be broadly split into those in which robots move towards a location convergence <3,4,7,8>, or cover an area coverage <1,2,5,6>. These task groups can be broken down further into movement to (convergence/coverage), or movement while (converging/covering), during which robots may be in relatively known (formation), or unknown (random) positions. Most real world robot applications can be classified using this taxonomy e.g. box pushing <2>, homing <3>. Figure 2: Mobile Agent Execution Environment 2.3 Mobile Agent Based Robot Systems Mobile agents have been used to achieve fitted autonomy in the Internet control of a single assembly robot arm in [8]. Fitted autonomy being defined as the ability to adjust the level of autonomy, at a remote place, to fit the needs of an application. Mobile agents in the system migrate to a remote robot place to adjust a robot arm s level of autonomy by controlling it locally, using declarative plans, in the process reducing the effect of Internet delay. Mobile agents are used for the supervisory control of multiple robots in a space exploration scenario in [6], where a mobile agent migrates to a remote robot location to trouble shoot problems by coordinating or adjusting robot autonomy. Such a method, as with the work in [8], moves intelligence to the remote location for local interaction thereby reducing communication delay. In [3], an established fault tolerant multiple robot architecture (ALLIANCE), is implemented in a mobile agent environment. This work explores how functional extensions to multiple robot architectures can be made using mobile agents. Mobile agents are used to extend adaptability (simultaneous, automatic, remote updating of multiple robot control code) and fault tolerance (retention of mission level data) in the architecture. Figure 3: Taxonomy of TeleRobot Tasks [2] 3 System Design 3.1 System Architecture Our systems architecture is shown in Figure 4. The architecture contains five types of agent which include: Remote Control Agent executes the multiple robot control strategies offered by the local control agent GUI. The local control agent sends commands to the remote control agent e.g. number of robots, control type, control parameters etc. The remote control agent then controls single, or multiple robots, based on these commands, and obtains feedback from robots for use in coordinating their movement. The remote control agent communicates with multiple robot interface agents. A single robot interface agent resides on each robot. Robot Interface Agent a robot interface agent provides an interface to robot functionality for the remote control agent, allowing movement and sensor feedback functions. Robot interface agents shield the remote control agent from underlying robot platforms with a standard control interface, and can encapsulate control feedback protocols for other robots if required, to allow heterogeneous robot team control. Local Display Agent the local display agent provides a multiple robot display GUI (Figure 5). This display shows the current location (x, y, theta) of robots in the environment.
Remote Display Agent the remote display agent obtains feedback data from robots, and provides this to the local display agent to allow it to display robot locations. Local Control Agent the local control agent provides a user with the multiple robot control GUI (Figure 5), including a number of different types of multiple, and single robot control mechanism. In single robot control, a user is able to set the heading and forward or backward distance to move of a single robot. A user is able to move multiple robots simultaneously in a similar way. In addition to these controls, four methods of multiple robot control are available. These methods allow a multiple robot team to be moved simultaneously to converge on a point <3,7>, diverge from a point <1,5>, line up (horizontally or vertically) <2,6> or form about a point <4,8> (form based on number of robots i.e. 3 triangle, 4 square etc). environment and function library for Java based mobile agents. The function library provides agent creation, destruction, cloning, migration and persistent storage functions. Apache Web Server is used to store agent Java class files. The Grasshopper 2 Agent Servers obtain class files from this central repository. ActivMedia s Aria robot control software allows various levels of control to be applied to ActivMedia Pioneer 2DX robots, it is written in C++ but provided with a Java wrapper, allowing Aria commands to be written directly in Java based applications/agents. Figure 4: System Architecture Figure 5: Multiple Robot Control and Position GUIs 3.2 Hardware and Software The agents described in the previous section are implemented in the hardware/software environment shown in Figure 6. This implementation includes two Windows XP and one Linux PC. The Windows XP PCs contain Java 1.4 and Grasshopper 2 Agent Server [5] (to host mobile agents). One of them contains Apache Web Server v2.0 (to serve Java mobile agent class files to Grasshopper Servers). The Linux PC contains SSH (to allow Grasshopper Servers to be remotely started on robots). The implementation also includes three ActivMedia Pioneer 2DX mobile robots [1], each running Linux and network accessible via wireless LAN. Each robot contains Java 1.3, a Grasshopper 2 Agent Server and ActivMedia s Aria robot control software. Grasshopper 2 is a free OMG MASIF compliant Java based mobile agent server, which provides an execution Figure 6: Implementation Hardware and Software Security in our robot lab prevents us from migrating mobile agents into the robot LAN, therefore we use the two Windows XP PCs inside the LAN to represent the local and remote PCs shown in Figure 4, and simulate Internet delay between them by delaying inter computer/robot commands. The local control agent and display agent reside on the local PC. The remote control agent and display agent reside on the remote PC. The robot interface agents reside (one each) on the three robots. Having described our system implementation and architecture, the next section describes experiments conducted to support our implementation design. 4 Experiments As previously mentioned we have been attempting to develop a multiple telerobot control system, which can be effectively operated across Internet connections, despite indeterminate delay and limited bandwidth. Our approach has been to employ intelligence in the system to improve the overall efficiency with which a multiple robot team can be controlled, and to locate this intelligence at the remote robot side (encapsulated in a mobile agent), for optimum robot coordination. In the following section we conduct a number of experimental trials to support this implementation. The first set of experiments show why we have employed intelligence in our system to coordinate the activity of multiple robots, rather than allowing a single user to attempt to coordinate all robots at a low level. In this set of experiments we compared the use of intelligence in the system to allow a user to conduct high level group control of
a multiple robot team, with a system in which no intelligence was used to aid the user (other than their own intelligence to control robots low level behaviour). In the second set of experiments we used the same intelligence i.e. multiple robot control mechanism (remote control agent) at two different locations in the system. We show how the same type of intelligence employed locally, compares to intelligence located at the remote robot site, in a system which employs Internet communication between local and remote sites. 4.1 Intelligent vs. Manual Control In these experiments we controlled multiple robots using intelligent supervisory group control coordinated using a mobile agent, and direct manual individual control coordinated by a user. In Set-Up 1 we controlled three mobile robots in the four tasks shown in Figure 7 and demonstrated for task <4> in Figure 8. We controlled each robot individually, waiting for command execution on each robot to finish before conducting further commands. We moved robots in the directions shown by arrows. A single experimental trial was classed as the movement of all robots from start to end position, and was conducted in a 4m x 4m lab environment without obstacles. In these experiments we did not include any additional delay to that which might normally be found in an Internet LAN. Five trials were conducted for each control type in each of the four tasks. the system, on the local PC. Because intelligence was located at the local PC, all low level control commands were sent across the Internet to reach robots. In Set-Up 2 we placed intelligence (remote control agent) at the remote side of the system, on the remote PC. Because intelligence was located at the remote PC low level control commands could be sent locally via robots Internet LAN. In order to remotely control the robots a user needed to send only high level control commands across Internet WAN. We simulated Internet delay between the local and remote PC s at three levels, low (no additional delay i.e. LAN), medium (low+3000ms delay) and high (low+6000ms delay). We simultaneously controlled three mobile robots successively in each delay condition, in the four tasks described previously. 5 Results and Analysis 5.1 Intelligent vs. Manual Control Figure 9 and Table 1 show the average trial times (in seconds) for the Intelligent vs. Unintelligent Control Experiments. Control Type/Task <1> <2> <3> <4> Unintelligent Control 37.90 44.99 36.63 174.30 Intelligent Control 16.54 16.40 16.30 52.82 Table 1: Intelligent vs. Unintelligent Control Results Figure 7: Experiment Tasks 1 2 3 4 5 6 7 8 Figure 8: Robot Movements in Experiment Task <4> In Set-Up 2 we controlled three mobile robots in the same tasks as in Set-Up 1. However in these trials we controlled robots using intelligence provided by a mobile agent to coordinate low level robot behaviour. This allowed us to simultaneously move the robot group rather than individual robots. 4.2 Local Intelligence vs. Remote Intelligence In these experiments we assessed how the position of intelligence affected the control of multiple robots in systems which employ Internet communication, and may therefore be susceptible to varying levels of delay. In Set-Up 1 we placed intelligence (remote control agent) at the local side of Figure 9: Intelligent vs. Unintelligent Control Results These results show, that as one would expect, it is more effective to control multiple mobile robots using intelligence rather than using an unintelligent system. Without intelligence a user can only focus effectively on the control of one robot at a time. By including intelligence in the system, a user can delegate low level control to that intelligence, and concentrate on controlling the overall movement of the robot group. 5.2 Local vs. Remote Intelligence Figure 10 and Table 2 show the average trial times (in seconds) for the Local vs. Remote Intelligence Experiments. These experiments show that the location of intelligence in the system is important when Internet delay may affect communication. Figure 10 shows that as delay increases, it generally takes longer to control the multiple robot team when intelligence is located at the local, rather than the remote side of the system. This is highlighted in the results for tasks <1,3,4>. An anomaly is shown in the results for task <2>, this anomaly may occur because less intelligence/low
level control commands are required in this task by the remote control agent, relative to other tasks. Figure 10: Local vs. Remote Intelligence Results Control Type/Task <1> <2> <3> <4> Local (Low Delay) 15.12 15.77 15.22 48.93 Local (Med Delay) 31.45 32.46 31.10 107.88 Local (High Delay) 49.39 48.03 49.12 173.90 Remote (Low Delay) 14.92 15.84 14.79 49.47 Remote (Med Delay) 40.69 29.12 34.60 168.25 Remote (High Delay) 56.07 40.68 61.10 239.63 Table 2: Local vs. Remote Intelligence Results Increased delay is likely to occur in tasks <1,3,4> for two reasons. First, when intelligence is located locally, more low level control commands must be sent across the Internet WAN, rather than Internet LAN connection (Internet WAN being subject to greater levels of delay). Second, because there can be a greater discrepancy between execution of commands or feedback received across Internet WAN, robot movement is more unpredictable. The main effect of locating intelligence at the local PC was to (i) increase task execution time due to increased command execution delay, and (ii) increase command execution/feedback delay variability, causing control predictability to be reduced. Locating intelligence at the local PC side, led to a system which was inherently unsafe, and incapable of predictable control. 5.3 Discussion The reason why we chose to implement our multiple telecontrol architecture in a mobile agent environment, is based on the following characteristics of mobile agents: Increased System Flexibility/Extendibility mobile agents encapsulate all of the functionality found in other distributed computing architectures in a single environment, which makes the future extension of a system easier. Adaptation mobile agent mobility allows us to easily adapt our system, both during development and at run-time. Experiments conducted in [3] show that mobile agents are especially effective for updating control code in multiple robot systems. Intuitive Design Environment using mobile agents we do not need to develop our basic system around a heavily interconnected amalgamation of alternative distributed computing paradigms, instead the system is based around a single design philosophy, consisting of independent but unified islands of functionality, which we can chose to connect or disconnect as required. Software Engineering agents are an intuitive mechanism in which to encapsulate functionality. Mobile agents extend the abstraction of software development offered by object oriented programming, and the functionality which an agent oriented software engineering methodology offers. 6 Conclusions and Future Work In this paper we have examined the implementation of a multiple telerobot system which can be controlled across the Internet, despite indeterminate delay and limited bandwidth. We show through experiments how the use and appropriate locating of intelligence in our system can help to effectively and safely control multiple robots, despite indeterminate Internet delay. We implement our system in a mobile agent environment, because it allows increased flexibility, adaptability, and a more intuitive design environment than found in an amalgamation of other distributed computing paradigms. The telerobot control architecture presented in this paper was developed in the same mobile agent execution environment as the autonomous fault tolerant architecture implemented in [3], highlighting the flexibility of the mobile agent development environment. In future work we hope to increase the intelligence of the remote control agents in this system incorporating learning to improve robot control efficiency. References [1] ActivMedia Robotics, Software, Documentation and Technical Support, ActivMedia Robotics, WWW, http://robots.activmedia.com/techhome.html (2004) [2] K.Ali, MultiAgent TeleRobotics: Matching Systems to Tasks, PhD Thesis, Georgia Tech Mobile Robot Lab, USA, (1999) [3] L.Cragg and H.Hu, Implementing ALLIANCE in Networked Robots using Mobile Agents, Proceedings of IAV 2004, 5 th IFAC Symposium on Intelligent Autonomous Vehicles, July 5-7 th, Lisbon, Portugal, (2004) [4] K.Goldberg and R.Siegwart (Eds.), Beyond Webcams: An Introduction to Online Robots, MIT Press, (2002) [5] IKV++ Technologies AG, Grasshopper 2 Homepage, WWW, http://www.grasshopper.de/, IKV++ Technologies AG, (2004) [6] T.Papaioannou, Mobile Agents: Are They Useful For Establishing A Virtual Presence In Space?, Agents with Adjustable Autonomy Symposia, Part of AAAI 1999 Spring Symposium Series (1999) [7] P.W.Tsui and H.Hu, A Framework for Multi-Robot Foraging over the Internet, Proceedings of IEEE Int. Conference on Industrial Technology, Bangkok, Thailand, 11-14 th Dec (2002) [8] W.J.Vieira, L.M.Camarinha-Matos and L.Octavio Castolo, Fitting Autonomy and Mobile Agents, 8 th International Conference on Emerging Technologies and Factory Automation (ETFA 2001), Vol. 2, (2001) [9] L.Yu, P.W.Tsui, Q.Zhou and H.Hu, A Web-based Telerobotic System for Research and Education at Essex, IEEE/ASME Int. Conference on Advanced Intelligent Mechatronics, pp.284-289, Como, Italy, 8-11 July (2001)