Applying Robot-in-the-Loop-Simulation to Mobile Robot Systems

Transcription

1 1 Applying Robot-in-the-Loop-Simulation to Mobile Robot Systems Xiaolin Hu, Member, IEEE Abstract Simulation-based study plays important roles in robotic systems development. This paper describes robot-in-theloop simulation, which is a novel simulation method that we developed to allow real robots and robot models to work together for system-wide measurement and test. To support robot-in-theloop simulation, a simulated virtual environment is developed. Several kinds of sensor/actuator interface models are defined to allow real robots to interact with the virtual environment. To demonstrate the capability of robot-in-the-loop simulation, three mobile robot examples were developed and are presented in the paper in an incremental way. These examples illustrate the usages and configurations of robot-in-the-loop simulation under different situations. Index Terms Robot-in-the-loop-Simulation, Virtual Environment, Mobile Robots, ing and Simulation, DEVS M I. INTRODUCTION odeling and simulation plays important roles in the process of robotic software development. It allows control algorithms to be tested and configurations to be experimented before they are deployed to real robots. Traditionally, people view simulation as an activity happens only in the early stages of a development process. When the process reaches the implementation/realization stage, the simulation models are discarded and the control logics are reimplemented. This approach tends to introduce new errors during the process of realization. To address this issue, our previous research [1, 2] has developed a model continuity methodology, which effectively links simulation-based study to real robot realization. Specifically, the model continuity methodology allows the same decision-making models studied in simulation to be deployed to real robots for execution. This methodology increases the confidence that the final system implements the behavior as been designed, and will carry out the functions as been tested by simulation methods. The model continuity methodology links two stages of robotic system development: the simulation stage where robot models are used, and the real execution stage where real Manuscript received November 19, This research was supported by NSF grant DMI , DEVS as a Formal Framework for Scalable Enterprise Systems. Xiaolin Hu is with the Georgia State University, Computer Science Department, Atlanta, GA USA (phone: ; fax: ; xhu@cs.gsu.edu). robots are employed. To further bridge the gap between simulation and real system experimentation, an intermediate stage is also developed that is characterized as using combined models and real robots. This capability, which we refer to as robot-in-the-loop simulation, brings simulation-based study one-step closer to the reality and provides the flexibility to allows real robots to be experimented in a virtual environment. It is especially useful for large-scale cooperative robotic systems whose complexity and scalability severely limit experimentations in a physical environment using all real robots. This research is an extension to our research on model continuity. It is based on the DEVS (Discrete Event System Specification) [3] formal modeling and simulation framework. Using a formal framework fosters treating model verification and simulation-based validation formally. This in turn nurtures systematic development methods and integrative development environments. The term robot-in-the-loop simulation is directly related to hardware-in-the-loop-simulation (HILS). HILS is a technique frequently applied in computer system design, especially for embedded systems and control systems design. A Hardware-in-the-Loop-Simulation (HILS) refers to a system in which parts of a pure simulation have been replaced with actual physical components. This is based on the belief that once physical components are added into the loop, unmodeled characteristics can be investigated, and controls can be further refined. The use of HILS eliminates expensive and lengthy iterations in machining and fabrication of parts, and speeds development towards a more efficient design. Robotin-the-loop-simulation, by sharing the same belief that higher simulation fidelity will be reached when real system components are brought into study, provides several advantages that are especially useful for complex and largescale robotic systems. For example, when a physical environment is not available to test a robot (such as a Mars Rover), robot-in-the-loop simulation allows the robot to be tested and evaluated in a virtual environment. This is in a similar way as that pilots are trained in a virtual reality environment. For distributed robotic systems that include a large number of robots, robot-in-the-loop simulation allows one or two real robots to be tested and evaluated together with many other robot models simulated on computers. Many simulation environments have been developed to study multi-robot systems. For example, MuRoS [4] supports simulation of several multi-robot applications such as cooperative manipulation, formation control, foraging, etc.

2 2 The Stage [5] is a robot simulator that simulates a population of mobile robots, sensors and objects in a two-dimensional bitmapped environment. Unlike the 2D multi-robot simulators mentioned above, ÜberSim [6] provides 3D simulation and is specifically targeted for simulating games of robot soccer. Other 3D multiple robot simulators include Gazebo [7], which is a multi-robot simulator for outdoor environments. Gazebo is able to generate both realistic sensor feedback and physically plausible interactions between objects. A commercial 3D simulating package worth of mentioning is Webots [8], which is a simulator originally developed for the Kephera robot but now able to support other types of mobile robots including wheeled and legged robots. The Webots simulation software provides users with a rapid prototyping environment for modeling, programming and simulating mobile robots. None of these multi-robot simulations, however, involves any real system components such as real sensors, real actuators, or real robots. Our research, by taking a hybrid approach, allows real robots as well as robot models to be studied together in a simulation-based virtual environment. It also emphasizes the continuous transition from simulation-based study to real robot execution. This paper is organized as follows. Section 2 gives a brief review of DEVS that serves as the formal basis of this research. Section 3 introduces the architecture of robot-in-theloop simulation and an incremental study process. Section 4 describes three kinds of Activities that serve as the interfaces between robots and virtual/real environments. Section 5 presents three examples in detail to illustrate how real robots can be studied together with a virtual environment. Finally, section 6 concludes this work. II. A BRIEF INTRODUCTION OF DEVS The DEVS (Discrete Event System Specification) [3] formalism is derived from generic dynamic systems theory and has been applied to both continuous and discrete phenomena. It provides a formal modeling and simulation (M&S) framework with well-defined concepts of coupling of components, hierarchical, modular model construction, and an object-oriented substrate supporting repository reuse. It enjoys the property of closure under coupling which justifies treating coupled models as components and enables hierarchical model composition constructs. DEVS is not just a theoretical framework, as it has been operationalized to serve as a practical simulation and execution tool in a variety of implementations. There are two kinds of models in DEVS: atomic model and coupled model. Atomic models are the basic components. Coupled models have multiple sub-components and can be constructed in a hierarchical way. An atomic model contains the following information: the set of input ports through which external events are received; the set of output ports through which external events are sent; the set of state variables and parameters; the time advance function which controls the timing of internal transitions; the internal transition function which specifies to which next state the system will transit after the time given by the time advance function has elapsed; the external transition function which specifies how the system changes state when an input is received; the confluent transition function which is applied when an input is received at the same time that an internal transition is to occur; the output function which generates an external output just before an internal transition takes place. Atomic models may be coupled in the DEVS formalism to form a coupled model. A coupled model tells how to couple (connect) several component models together to form a new model. This latter model can itself be employed as a component in a larger coupled model, thus giving rise to hierarchical construction. A coupled model contains the following information: the set of components; the set of input ports; the set of output ports; the coupling specification. The formalisms and more description about the DEVS modeling and simulation framework can be found at [3]. An atomic model may start/stop a DEVS Activity, which essentially can be any kind of computation task. An activity may or may not return result to the atomic model. If an activity returns result to the atomic model, the result can be put on a reserved input port (the "outputfromactivity" port) as an external event and then be processed by the model s external transition function. A more detailed description about different kinds of Activities is given in Section 4. III. THE ARCHITECTURE AND PROCESS An architecture for robot-in-the-loop simulation has been developed in [9]. This architecture includes an environment model and a collection of robot models. The environment model represents the real environment within which the robotic system will be executed. It forms a virtual environment for robots and may include virtual obstacles, virtual robots (robot models), or any other entities that are useful for simulation-based study. A robot model represents the control software that governs the robot s decision-making and communication. It also includes sensors and actuators to support interactions between robots and the environment model. We clearly separate a robot s decision-making unit, which is modeled as a DEVS atomic or coupled model, from the sensors and actuators that are modeled as DEVS Activities. Couplings can be added between sensor/actuator Activities and the environment model, thus messages can be passed between them. The clear separation between a robot s decision-making model and its sensor/actuators makes it possible for the decision-making model to interact with different types of sensors/actuators, as long as the interface functions between them are maintained the same. To support robot-in-the-loop simulation where a real robot s decision-making model can interact with a virtual environment (the environment model), we configure the real robot to use a combination of real and virtual sensors/actuators. A real sensor/actuator interact with a real environment and a virtual sensor/actuator interact

3 3 with the virtual environment. Figure 1 shows such a configuration with one real mobile robot. In this example, the mobile robot uses its virtual sensors to get sensory input from the virtual environment and uses its real motor interface to drive the robot. As a result, this real robot moves in a physical field based on the sensory input from a virtual environment. Within this virtual environment, the robot sees virtual obstacles that are simulated on computers and makes decisions based on those inputs. Meanwhile, virtual robots (robot models) can also be added so the real robot can sense them and communicate/coordinate with them. This capability of robot-in-the-loop simulation makes it possible to conduct system-wide tests and measurements without waiting for all real robots to be available, because the rest of robots can be provided by the simulation-based virtual environment. virtual obstacle virtual counterpart of the real robot virtual robots virtual environment virtual sensors Control HIL actuators virtual environment are simulated on a computer. The model that controls the real robots runs on the real robots. The couplings between robots (robot models and real robots) are maintained the same so the real and virtual robots can communicate with each other in the same way as that in the first step, even though messages are actually passed across the network. The final step is the real system experiment, where all real robots run in a real physical environment. These robots use real sensors and actuators. This incremental simulationbased study process establishes an operational procedure to measure and evaluate cooperative robotic systems. IV. ACTIVITY DEVS Activities act as sensor/actuator interfaces and play important roles in the incremental study process. Based on the three steps in the process, three kinds of Activities are developed. Figure 2 shows these Activities and their relationships with the decision-making and the environment model (or real environment). abstractactivity RTActivity wireless communication Environment Real Environment computer mobile robot Figure 1: Architecture of robot-in-the-loop simulation coupling (a) abstractactivity (b) RTActivity Including real robots into simulation-based study brings an important issue that needs to be resolved: the synchronization between real robots and the virtual environment. For example, in Figure 1, when the decision-making model issues a moving command, the real robot will move a distance in the physical environment. This change of the robot s position should also be updated by the virtual environment. For this purpose, each real robot has a virtual counterpart in the virtual environment. When a real robot moves, the position of its virtual counterpart will be updated. Thus synchronization between the real robot and the virtual environment is actually the synchronization between the real robot and its virtual counterpart. By integrating robot-in-the-loop simulation with conventional simulation and real system experiment, we developed an incremental study process [9]. This process includes three steps and supports smooth transitions between them. The first step is conventional simulation, where all components are models simulated on a computer. These robot models are equipped with virtual sensors and virtual actuators to interact with an environment model. The second step is robot-in-the-loop simulation where one or more real robots are studied together with other virtual robots (robot models) that are simulated on a computer. In this step, the virtual robots still use virtual sensors/actuators. However, depending on the study objectives, the real robots may use a combination of virtual and real sensors/actuators. The virtual robots and the Environment abstractactivity coupling (c) HILActivity Figure 2: Activities HILActivity Real Environment In conventional simulation, abstractactivities (Figure 2a) are used to act as virtual sensors or actuators. An abstractactivity is used by the to get input from and send output to the environment model. To support that, an abstractactivity can add couplings to the environment model thus messages can be passed between them. A function addactivitycoupling() has been developed to support this. In real time execution, RTActivities (Figure 2b) are used to drive the real sensors and actuators. An RTActivity is a thread that interacts with the hardware interfaces. Through RTActivities, the that resides on a real robot can interact with the real environment. This allows the real robot to get sensory input from the real environment and to move in the real environment. In robot-in-the-loop simulation, HILActivities (Figure 2c) are used. Since robot-in-the-loop-simulation is an intermediate step between conventional simulation and real time execution, a HILActivity combines the functions of both abstractactivity and RTActivity. A HILActivity is a thread thus

4 4 it can talk to the hardware interfaces. In the meantime, it can add couplings to the environment model thus to send synchronization messages to it. Using HILActivity, the that resides on a real robot can interact with the real environment, while in the meantime synchronize with the environment model. Section V gives some specific examples to show how synchronization is achieved. To keep the unchanged through different stages, we require that abstractactivity, RTActivity, and HILActivity should maintain the same interface functions with the. To facilitate this, an ActivityInterface has been developed which is implemented by all the three Activities. Thus a model can start an Activity in the following way: ActivityInterface a = new abstractactivity(name); //or RTActivity, or HILActivity startactivity (a); V. THREE MOBILE ROBOT EXAMPLES This section presents three examples in an incremental way to illustrate how robot-in-the-loop simulation can be used in different situations. For demonstration purpose, these examples use a type of mobile robot that is simplified from the robots that we developed in [10]. These robots have four IR sensors (one on each side) to detect distance to objects. They have two motors (left and right) that can drive robots to move forward/backward and to turn around the center. In these examples, a robot model consists of three parts: a decision-making model, an IR sensor Activity and a motor Activity. The decision-making model gets input from IR sensors and sends commands to motors. For different systems, the decision-making models are different. For example, the decision-making model for the team formation example includes logic to dynamically establish a team; the decisionmaking model for the robot convoy example includes logic to maintain the convoy system s formation. Without losing generality, we assume the decision making model is an atomic model with name Decision_making. This is the model that starts sensor/motor Activities. The IR sensor Activity is in charge of getting IR sensory input. The motor Activity is in charge of driving a robot to move around. Depending on different steps of the incremental study process, different formats of them will be employed. In the following text we refer to IR_abstract and Motor_abstract as abstractactivities for IR sensor and motor respectively. Similarly, IR_HIL and Motor_HIL are HILActivities; IR_RT and Motor_RT are RTActivities. During conventional simulation, IR_abstract and Motor_abstract are used. During real system experiment, IR_RT and Motor_RT are used. During robot-in-the-loop simulation, combination of HILActivities and abstractactivities may be used. In this paper, we only consider the combination of IR_abstract and Motor_HIL. To support simulation-based study, an environment model is developed. This environment model is responsible to keep track of robots movement and provides sensory dada when robots need it. Specifically, the Environment model includes a set of TimeManager models and a SpaceManager model. For each robot, there is a corresponding TimeManager, which models the time for this robot to complete a movement. The SpaceManager models the moving space, including the dimension, shape and location of the field and the obstacles inside the field. It also updates and keeps track of robots (x,y) positions and moving directions during simulation. Such tracking is needed to supply robots with the correct sensory data. Following the incremental study process, each example goes through conventional simulation, robot-in-the-loop simulation, and real system experimentation. In this paper we only consider robot-in-the-loop simulation. During robot-inthe-loop simulation, one or more real robots are placed in an open field. The Decision_making models (tested by conventional simulation) of these robots are downloaded to the real robot hosts. Other models such as the Environment model reside on other networked computers and are driven by the DEVS distributed simulation environment. Depending on the desired configuration, a Decision_making model resident on a real robot may use the robot s real sensor/actuator (implemented by HILActivity) to interact with the real environment or use abstractactivity as virtual sensor/actuators to interact with the environment model. Below we show in detail how robot-in-the-loop simulation be achieved within the contexts of three robotic examples. Pseudo code is provided. A. A Single Robot Ant This simple example describes a robot ant that senses the environment and moves around. Specifically, if the ant detects there is obstacle ahead, it turns right or left based on a random number; otherwise, it moves forward. Assuming the Decision_making model of this robotic ant works in conventional simulation on a computer. Nevertheless, it may fail when it controls a real robot in a real physical environment. For example, the Decision-making model may make a decision based on the time to complete a specific movement. However, the real value of this time can only be measured if a real robot is used. In situations like this and others, robot-in-the-loop simulation allows real robots to be used in simulation-based study, thus increasing the confidence that the control logic will be correct in real system s execution. In this example, we want to make sure that when the robot senses an obstacle ahead, it will turn an appropriate angle. To check this, we configure robot-in-theloop simulation in the way that the real robot uses virtual sensors to get inputs form the environment model and uses HIL motors to moves in a physical environment. Code from the Decision_making To allow this to happen, the Decision-making model starts two Activities: an IR_abstract and a Motor_HIL. The IR_abstract allows the robot to gets sensory input from the environment model. The Motor_HIL drives the robot to move

5 5 in a physical environment. Below is the corresponding code to start these two Activities. ActivityInterface sensora=new IR_abstract (); startactivity(sensora); ActivityInterface motora = new Motor_HIL (); startactivity(motora); Once sensora and motora are started, sensora regularly sends sensory data (obtained from the environment model) to the Decision_making model through the outputfromactivity port. The Decision_making model processes this input and then calls motora s move() method to move the robot. Below shows the Decision_making model s external transition function deltext(). public void deltext(double e,message x){ if (messageonport(x,"outputfromactivity")) { //receive sensory data from sensora sensordata = x.getvalonport("outputfromactivity"); // process input if (obstacleahead) motora.move("rotatecw"); // rotate else motora.move("forward"); // move forward Code from IR_abstract The responsibility of IR_abstract is to obtain IR sensory data from the Environment model and then pass the data to the Decision_making model. To achieve this, IR_abstract first establishes communication channels with the Environment model by adding couplings to it. The code below adds a coupling between the Environment model s output port IRData and the IR_abstract s input port IRData. addactivitycoupling ("Environment", "IRData", IR_abstract, "IRData"); With this coupling, the Environment model can send IR sensory data to the IR_abstract and trigger IR_abstract s external transition function deltext(). In deltext(), IR_abstract calls the returnresults() function to pass the data to the Decision_making model, which processes the data in the way as described above. Below is a code fragment to show this. public class IR_abstract extends abstractactivity{ public void deltext(double e,message x){ if (messageonport(x," IRData ")) { sensordata = x.getvalonport("irdata "); returnresults(sensordata); // send to Decision-making Code from HIL_motor The HIL_motor drives the motors of the robot to move around. Thus it needs to interact with the interface (the driver ) of the motors. Meantime, when the robot moves, HIL_motor is responsible to synchronize the robot s movement with the Environment model. To allow synchronization messages to be passed to the Environment model, a coupling is added between HIL_motor and the Environment model. The code below shows this. In the code, MSI_Control is the interface class of the motors. MSI_Control motorcontrol = new MSI_Control(); addactivitycoupling( Motor_HIL, "HILmove", "Environment", "HILmove"); When the Decision_making model calls the move() method of HIL_motor, HIL_motor calls MSI_Control s corresponding functions to drive the motors. After the movement is completed, a movecomplete message will be triggered by the motors and is captured by HIL_motor s movementcomplete() method, which then sends a synchronization message to the Environment model. The move() and movementcomplete() methods of HIL_motor are shown below. public class HIL_motor extends HILActivity { public void move(string direction){ if(direction.startswith("forward")) motorcontrol.moveforward(speed, distance); else if(direction.startswith("backward")) motorcontrol.movebackward(speed, distance); else if(direction.startswith("rotatecc")) motorcontrol.ccrotation(speed, distance); else if(direction.startswith("rotatecw")) motorcontrol.cwrotation(speed, distance); public void movementcomplete() { movecomplete = true; sendoutput("hilmove", new entity(moveparameter)); The synchronization message moveparameter is sent out on the output port HILmove of HIL_motor. This message is passed to the input port HILmove of the Environment model, which updates the robot s position based the moveparameter message received. Note that this approach assumes the real robot will move the exact distance as specified by the moveparameter. This is not true in reality. Thus as time proceeds the error between the real robot s moved distance in the physical world and the distance updated in the virtual environment will accumulate. A more advanced synchronization mechanism may be developed by using a

6 6 separated monitoring system to track the motion of the real robot. It then updates the information, such as the distance and time of a robot s movement, to the Environment model to synchronize them. This is the approach taken by [11] where an overhead camera is used to record robot s movement and then synchronize with the environment model. The above description outlines the major interactions among the Decision_making model, IR_Abstract, and motor_hil that allow a real robot to sense a virtual environment and moves in the physical world. Due to space limitation, the Environment is not shown here. A movie that records robot-in-the-loop simulation for this example can be found at [12]. To make this movie, we recorded the movement of the real robot (in the physical world) and its virtual counterpart (in the virtual environment) concurrently. The movie clearly shows that when the robot senses an obstacle ahead (from the virtual environment), the real robot (in the physical environment) turns. It also shows the synchronization between the real robot and the simulated environment. B. A Team Formation System While the last example describes a single robot, this example shows a cooperative robotic system that includes two robots. The purpose of this example is to show that a real robot can coordinate with a robot model simulated on a computer. This system was initially developed in [13]. Here we present the recent progress that we made by applying robot-in-the-loop simulation. This example describes a dynamic team formation system that includes two robots. The team formation process starts with both robots moving around and trying to find each other. Initially, there is no connection between these two robots although they are connected to a software process, called a Manager, on a wireless laptop. When two robots find each other, the Manager establishes direct connections between them and asks them to organize into a team. Then they begin the Leader-Follower march: one robot follows the other with the same movement. For example, if the leader turns right, the follower turns right too. Three models: Robot1, Robot2, Manager and an Environment model were developed. Below we show how robot-in-the-loop simulation can be setup to allow the leader robot robot1 (a real robot) to be tested with Robot2 (a model) within a virtual environment simulated on a computer. Note that in robot-in-the-loop simulation, the couplings between the two robots are maintained the same as those in conventional simulation. To setup this robot-in-the-loop simulation, model Robot1 is downloaded to a real robot robot1 and is executed by a realtime execution engine; model Robot2, Manager and the Environment model are simulated on a computer. Since Robot2 is a model, we configure it to use IR_abstract and Motor_abstract to interact with the Environment model. For robot1, we configure it to use IR_abstract and Motor_HIL. This is the same configuration as the one described in the first example. The code below shows the IR sensor Activity and motor Activity started by robot1 and Robot2 respectively. For robot1 ActivityInterface sensora=new IR_abstract (); startactivity(sensora); ActivityInterface motora = new Motor_HIL (); startactivity(motora); For Robot2 ActivityInterface sensora=new IR_abstract (); startactivity(sensora); ActivityInterface motora = new Motor_abstract (); startactivity(motora); The IR_Abstract and motor_hil are the same as those in the first example. The Motor_abstract (for Robot2) provides a move() method for the Decision_making model to invoke. In this method, the Motor_abstract passes the command message to the Environment model by calling a method sendoutput(). To support the message passing, a coupling needs to be added between Motor_abstract and the Environment model. The code fragment below shows this. public class Motor_abstract extends abstractactivity{ public void initialize(){ addactivitycoupling( Motor_abstract, "move", "Environment", "move"); public void move(string direction){ moveparastring = direction +"_"+ speed +"_"+ distance; sendoutput ("move",new entity(moveparastring)); Similar to the first example, a movie [12] was made to show two robots movement (in the physical world and in the virtual world). In this movie, the blue robot is the virtual counterpart of the real robot, which is the leader after team formation. The green robot is a robot model. C. A Robot Convoy System This example shows a robot convoy system that consists of an indefinite number of robots, saying N robots (N>1). These robots are in a line formation where each robot (except the leader and the ender) has a front neighbor and a back neighbor. The interest of this example is to show that more than one real robot can be used in robot-in-the-loop simulation. These real robots can work together with many other robot models that are simulated on computers. One of the main goals of this convoy system is to maintain the coherence of the line formation and to synchronize robots movements. Synchronization means a robot cannot move forward if its front robot doesn t move, and it has to wait if its back robot doesn t catch up. To serve this purpose, synchronization messages are passed between a robot and its neighbors. To achieve coherence of the line formation, the moving parameters of a front robot are passed back to its immediate back robot. This allows the back robot to plan its

7 7 movement accordingly based on its front robot s movement. The system has no global communication and coordination. A model of the system was developed in [9] and is shown by Figure 3. BReadyIn FReadyOut BReadyIn FReadyOut FReadyIn FReadyOut BReadyOut Robotn Robot3 Robot2 BReadyIn Robot1 FReadyIn BReadyOut FReadyIn BReadyOut Figure 3: System model of the robotic convoy system To see how robot-in-the-loop simulation can play a role in this example, we consider an experimental setup that includes two real robots, Robot_k and Robot_k+1 as shown in Figure 4. These two robots neighbor each other and stay in the middle of the convoy team. The rest of the team is composed of robot models. These two real robots are physically placed in an open space. They are initially lined up so one follows the other. One interesting aspect of this experiment is that these two robots represent different situations from the configuration point of view. The front real robot needs to follow Robot_k-1, which is a robot model simulated on a computer. The back real robot needs to follow Robot_k, which is a real robot. Thus in this experiment, Robot_k (the front real robot) is equipped with IR_abstract to gets sensory input from the virtual environment, while Robot_k+1 uses its real IR sensor IR_RT to track a real robot in the physical environment. Both robots are equipped with Motor_HIL to move in the physical environment. All other robot models use IR_abstract and Motor_abstract. The code below shows the IR_RT and Motor_HIL used by Robot_k+1. ActivityInterface sensora=new IR_RT (); startactivity(sensora); ActivityInterface motora = new Motor_HIL (); startactivity(motora); Environment Robot_1 Robot_k-1 Robot_k+2 Robot_n Real environment Figure 4: A robot-in-the-loop simulation setup The IR_RT is responsible to check the real physical environment regularly and return the sensory data to the Decision_making model. The pseudo code of IR_RT is shown below. In the code, sensorcontrol is the interface class (the driver ) of the IR sensor. public class IR_RT extends RTActivity{ public void run() { while (true) { distance = sensorcontrol.checkdist("front"); returntheresult(new entity(distance)); Thread.sleep(300); By running robot-in-the-loop simulation with this setup, several results can be collected and analyzed. For example, we can check if the back real robot follows its front robot in the physical environment (Assuming they do in conventional simulation). If these two robots lose each other in robot-inthe-loop simulation, it means the Decision_making models need to be refined. Notice that in this scenario, we can discover the problems by using only several real robots instead of all real robots. With robot-in-the-loop simulation, we can also compare some measurement results with the results collected from conventional simulation, and then use this information to refine the robot models under development. For example, for the experiment in Figure 4, we can measure the back real robot s position errors (based on the location of its front robot in the physical space), and then compare it with that collected from the conventional simulation. This information will be useful to analyze and to refine the model for this convoy system. A movie [12] of this example has been recorded by using four robots, among which the second and third ones are real robots. Similar to the two other movies, this movie includes two windows. One window shows the movements of two real robots. The other window shows the movements of simulated robot models, among which the second and third models are the counterparts of two real robots. Thus the second and third robot models movements are synchronized with the two real robots movements. VI. CONCLUSION This paper describes three mobile robot examples to illustrate how robot-in-the-loop simulation can be setup in various situations. We note that the purpose of these examples is to demonstrate the main concepts, as we believe the impact of this research is beyond the scope of these illustrative examples. As the technology of robotic systems advance rapidly, integrative development methods and systematic measurement process play more and more important roles in handling the complexity of these systems. The model continuity methodology that we developed and the robot-inthe-loop simulation presented in this paper promise such a systematic way to develop cooperative robotic systems. ACKNOWLEDGMENT The author thanks Arizona Center for Integrative ing and Simulation (ACIMS) and Professor Bernard P. Zeigler for providing the opportunity to conduct this research. REFERENCES [1] X. Hu, A Simulation-based Software Development Methodology for Distributed Real-time Systems, Dissertation, University of Arizona, 2003

8 [2] X. Hu, and B.P. Zeigler, Continuity in the Design of Dynamic Distributed Real-Time Systems, IEEE Transactions On Systems, Man And Cybernetics Part A: Systems And Humans, to be published [3] B.P. Zeigler, Kim, T.G., et al.. Theory of ing and Simulation. New York, NY, Academic Press, 2000 [4] L. Chaimowicz, M. Campos, and V. Kumar, Simulating Loosely and Tightly Coupled Multi-Robot Cooperation. In Anais do V Simp_osio Brasileiro de Automa_c~ao Inteligente (SBAI), Canela, RS, Brazil, September [5] R. Vaughan, Stage: a multiple robot simulator. Technical Report IRIS , Institute for Robotics and Intelligent Systems, School of Engineering, University of Southern California, [6] B. Browning, E. Tryzelaar, ÜberSim: a multi-robot simulator for robot soccer, Proceedings of the second international joint conference on Autonomous agents and multiagent systems, 2003 [7] A. Howard, N. Koenig, Gazebo, Version User Manual, University of Southern California technique report, 2004 [8] O. Michel, Webots: Professional Mobile Robot Simulation, International Journal of Advanced Robotic Systems, Vol. 1, Num. 1, pages 39-42, 2004 [9] X. Hu, and B. P. Zeigler, Measuring Cooperative Robotic Systems Using Simulation-Based Virtual Environment, Performance Metrics for Intelligent Systems Workshop, August 2004 [10] J. Peipelman, N. Alvarez, K. Galinet, R. Olmos.: 498 A & B Technical Report. Department of Electrical and Computer Engineering, University of Arizona, 2002, unpublished. [11] K. Komoriya; Tani, K., Utilization of the virtual environment system for autonomous control of mobile robots, Intelligent Motion Control, Proceedings of the IEEE International Workshop on, Volume: 2, August 1990 [12] [13] X. Hu, and Zeigler, B. P., Continuity to Support Software Development for Distributed Robotic Systems: a Team Formation Example, Journal of Intelligent & Robotic Systems, Theory & Application, pp , January,