An Experimental Testbed for Robotic Network...

An Experimental Testbed forRobotic Network Applications

Donato Di Paola, Annalisa Milella, and Grazia Cicirelli

Abstract In the last few years, multi-robot systems have augmented their complex-ity, due to the increased potential of novel sensors and actuators, and in order to sat-isfy the requirements of the applications they are involved into. For the developmentand testing of networked robotic systems, experimental testbeds are fundamental inorder to verify the effectiveness of robot control methods in real contexts. In this pa-per, we present our Networked Robot Arena (NRA), which is a software/hardwareframework for experimental testing of control and cooperation algorithms in thefield of multi-robot systems. The main objective is to provide a user-friendly andflexible testbed that allows researchers and students to easily test their projects ina real-world multi-robot environment. We describe the software and hardware ar-chitecture of the NRA system and present an example of multi-mission control of anetwork of robots to demonstrate the effectiveness of the proposed framework.

1 Introduction

In these last years, multi-robot systems are being widely investigated, since theyoffer better performances than single robot systems in challenging applications, suchas exploration of hostile environments, terrain mapping, space and rescue operations[1],[2],[3],[4].

Due to the intrinsic difficulty in developing and assessing the performances ofmulti-agent control algorithms in real contexts, much work has been carried out onlyanalytically or in simulation [5],[6],[7]. Advanced simulation tools for multi-robotsystems have been also developed, and are available as open source tools (e.g., Stageand Gazebo) or as commercial products (e.g., Webots, Microsoft Robotic Studioetc.).

Donato Di Paola, Annalisa Milella, Grazia CicirelliInstitute of Intelligent Systems for Automation (ISSIA), National Research Council (CNR),via G.Amendola 122/D, 70126 Bari, Italy, e-mail: {dipaola, milella, grace}@ba.issia.cnr.it

1

2 Donato Di Paola, Annalisa Milella, and Grazia Cicirelli

Nevertheless, for complete analysis and testing, and to provide additional insightsto theory, real world experiments are generally desirable. On the other hand, exper-imentation in robotics for comparison of different methods is often difficult due tothe variety of robotic platforms and environments that may be encountered.

Therefore, the development of experimental testbeds is a key issue for the designof effective multi-robot control systems. These testbeds can support all stages ofthe design process, including algorithm development and testing, conventional sim-ulation, robot-in-the-loop simulation, and real robot control, in an integrated way.An example of platform for conducting, evaluating and analyzing experiments inrobotics, named the Teleworkbench, can be found in [8].

In this paper, we describe our experimental set-up, referred to as NetworkedRobot Arena (NRA) that allows us to monitor, control, and test realistic behavioursof relatively simple multi-robot systems. This set-up includes both hardware andsoftware components. The main contribution of the work is the development of alow cost, robust, flexible, and scalable software/hardware system, which uses desk-top mobile robots with a vision-based identification and localization system, and amulti-mission control framework. The control architecture is a hybrid distributed ar-chitecture in which the high-level multi-mission control is performed by a softwaremodule with a number of controllers, each one in charge of managing a sub-network,while the low-level operations are implemented on board each robot.

The proposed framework can serve as a “middle ground” between a totallysoftware-based simulation tool and a full-scale real-world implementation. Fromthe one hand, it allows one to encompass real-world problems difficult to model andmanage in a virtual environment, such as errors in robot identification and localiza-tion, or interactions with other objects. On the other hand, it is based on user-friendlyand flexible tools, which can be used by both researchers and students to easily testtheir projects.

2 Overview of the Networked Robot Arena

In this section, we provide an overview of the NRA. The main goal of the proposedsystem is to set up a hardware and software framework to assist the developmentand testing process of robotic network applications for educational and researchpurposes.

The NRA has the following characteristics, which are typically desired for edu-cation and research testbeds: open software and hardware platform; desktop mobilerobots; low cost; robust, flexible and scalable software; user friendly software devel-opment and maintenance. In order to satisfy these requirements, the NRA featuresthe logical structure shown in Figure 1. The main components of the system are thearena, i.e., the physical environment where the robots operate, and the workstation,i.e., the computer in charge of communicating with the robots and controlling mostof software modules.

An Experimental Testbed for Robotic Network Applications 3

The arena is a bounded and controlled environment in which the robots, wirelessconnected, can move to perform the desired tasks. In order to satisfy the small sizerequirements, in our implementation, the arena is a desk with boundaries and mov-able objects (i.e., small wooden items), which can be arranged to create walls anddivide the environment in different zones. A camera is placed high above the arenato monitor positions and actions of the robots over time. This camera sends imagesto the workstation for elaboration, through a USB port. The output of the imageprocessing algorithm consists of a set of robot IDs and their positions in the arena,which are fed into the control system of the network. A short-range wireless con-nection is adopted to link the robot network with the workstation. The latter runs asoftware architecture, which is in charge of: managing the connections between theworkstation and the network of robots, using appropriate communication libraries;processing the images acquired by the overhead camera; controlling the networkwith high-level decision making algorithms; communicating the control decisionsto the robots. Indeed, control is not totally centralized in the control module of thearchitecture, but it is distributed between the workstation and the network of robots.Furthermore, no a priori knowledge about the environment configuration is requiredby the control system.

In order to facilitate the use of the testbed by researchers and students, MATLABis employed as software development environment. In the next sections, each partof the system architecture is described in more detail.

2.1 Robots and Hardware Infrastructure

As discussed above, two of the design requirements of the NRA are the desktop-sizedimensions of the robots and the possibility to have an open hardware platform.

Keeping in mind these requirements, we analyzed different solutions. First, weselected three robots as possible candidates for the NRA platform: the K-TeamKhepera robot [9], the Lego Mindstorms NXT, and the E-Puck robot. Khepera is

Fig. 1: Schematic representation of the Networked Robot Arena (NRA).


a small size robot, which can be equipped with various sensors, like infra-red prox-imity and ambient light sensors, cameras, and ultrasonic sensors, but it is relativelyexpensive. The Lego Mindstorms NXT is a modular platform with a rich set ofsensors; however, it is not an open platform, and it is not suitable for desktop sizerobotic networks. Finally, we chose the E-Puck robot (see Figure 2(a)), because ofits small size, low cost and open hardware characteristics [10].

The E-puck is a “desktop size” (7.0 cm diameter) differential wheeled mobilerobot. It was originally designed as an education tool for engineering and robotics.It is equipped with a powerful Microchip dsPIC (i.e., dsPIC 30F6014A) microcon-troller, and the following sensors and actuators: eight infrared (IR) proximity sen-sors, placed around the body; a 3D accelerometer that can be used to measure theinclination and acceleration of the robot; three microphones, to localize source ofsound by triangulation; a CMOS colour camera (640 × 480), mounted in the frontof the body; two stepper motors for differential drive; a speaker, connected to theaudio module; a set of LEDs placed on the body to provide a visual interface to theuser; a set of communication interfaces (i.e., a Bluetooth radio link, a RS232 serialinterface, and an infrared remote control receiver).

The hardware infrastructure of the NRA testbed consists of a bounded arena(60 cm × 110 cm) with a wireless communication network, a USB camera, anda high performance workstation (see Figure 2(b)). The camera consists of a USBcolour device, placed at about 150 cm above the arena. It provides robot identity

(a) (b)

Fig. 2: Robots and Hardware Infrastructure: (a) close up of an E-Puck robot insideour arena; (b) the Networked Robot Arena.


and position information for the control system, and can be also used as ground-truth basis for experimental validation of the algorithms. For the given arena androbot size, an image resolution of 640×480 is sufficient to detect and track all therobots. The workstation consists of a high performance computer, equipped with anIntel Core 2 vPro microprocessor and 4 Gb RAM, and is used for control, visualdata processing, and connection with the network of robots.

Since we need short-range communication among the agents, and between theagents and the workstation, we use a Bluetooth wireless network. Due to the smallamount of data passed through the network and the hardware and software mod-ule embedded within the E-Puck, the Bluetooth communication protocol revealed agood choice.

2.2 Software

The main goal of the NRA software architecture is to provide a distributed missioncontrol system, able to manage all the activities of the robotic network. We assumethat the network has to execute a number of missions. Each mission consists of apredefined sequence of tasks, connected by logical rules. Activation and completion

Fig. 3: Layout of the software architecture.


of missions and tasks are triggered by input and output events, respectively. In orderto execute each task, we assume that a set of behaviours, i.e. simple reactive actions,is properly activated on board each robot.

The layout of the software architecture is shown in Figure 3. It consists of thefollowing main parts: the high-level control, communication, and localization andidentification modules, running on the workstation, and the execution module run-ning on each robot. All components are executed on a discrete-time basis: stateupdates, event detection, and commands are all processed at the beginning of eachsample time.

The Controller implements high-level control functionalities, monitoring missionexecution and performing task assignment. In this module, one or more controllercan be run. Each controller, called leader, is in charge of controlling a part of thenetwork, in terms of missions and tasks. More specifically, each leader controls theexecution of the missions in progress (e.g., guaranteeing the satisfaction of prece-dence constraints), sends the configuration information about the tasks that mustbe started on each robot, and receives information about the completed tasks. Eachleader performs its work using a discrete-event model of the domain, a task exe-cution controller, and a conflict resolution strategy, which will be described in thefollowing section. Obviously, if only one leader exists, the control of the networkcan be viewed as a centralized system.

The Executor performs the control at the lower level. This component is im-plemented on each robot through a set of tasks and a set of behaviours needed toaccomplish a given goal. For each task, multiple behaviours can be executed at thesame time. Each behaviour computes an output and when multiple behaviours areactive at the same time, a predefined behaviour arbitration algorithm (e.g., subsump-tion [11] or cooperative methods [12]) can be used to obtain the final control signal.Currently, in our system, a subsumption mechanism is implemented. At the end ofa task, the completion flag and the results are sent to the upper level.

Communication between the Executor and the Controller is guaranteed by theCommunication module. This module provides all high-level control commandsfrom the leaders to the other robots in the network. In particular, in this module,the proper communication libraries are loaded, according to the specified robot.Moreover, the communication module is connected to the vision based localizationand identification module that provides, for each robot, position and identity infor-mation, used to accomplish an assigned task and for behaviour control.

It is worth to note that, although the main objective of this work is that of provid-ing an experimental platform, the proposed system may also be used as a simulationtool by substituting the Executor with an additional Simulation module. The latter,which uses the same interface with the Communication module as the Executor,simulates the behaviour of each robot in a virtual environment, providing robot po-sitions and simulating task execution.

In the rest of this section, further details concerning the hybrid control of thenetwork, as well as the localization and identification module, are provided.


2.2.1 Robot Network Control

As mentioned above, the control of the network is distributed among the compo-nents of the architecture. The overall management of the robotic network is basedon a hybrid control framework: the global network activities are modeled and con-trolled as a Discrete Event System (DES) and the low-level behaviours, for eachrobot, are considered as continuous-time control algorithms trigged by the DES su-pervisor. Moreover, the global model of the network is distributed among a set ofleaders. Each leader can control all activities or a sub-set of them in the network.

The activities domain of the network is modeled as follows: each robot mustexecute a set of missions; each mission is a set of atomic tasks, which may be subjectto priority constraints (i.e., the end of one task may be a necessary prerequisitefor the start of some other ones). To execute each task, the robot must perform apredetermined sequence of behaviours (e.g. GoTo, AvoidObstacle, WallFollowing,Wandering, etc.). Each behaviour runs until an event (either triggered by sensordata or by the supervisory controller) occurs. Two or more behaviours can be activesimultaneously. In such a case, the behaviour arbitration algorithm, on board therobot, computes the appropriate command to be sent to robot actuators. Missionsmay be triggered at unknown times, while the number and type of tasks composing amission is known a priori. Since different missions can run simultaneously, differenttasks may require the same subset of robots. In these cases, conflicts between therobots have to be handled using an efficient task allocation policy in order to avoiddeadlock situations.

The overall control scheme, proposed in this work, is based on the Matrix-basedDiscrete Event modeling and control Framework (MDEF) [13], a tool for modellingand analyzing complex interconnected DES with shared resources, for routing de-cisions, and managing dynamic resources. More precisely, in this work a partialdecentralization of the MDEF is implemented. The set of leaders are considered asa group of centralized MDEFs working on separate parts of the network [14].

All the MDEF builds over a set of key matrices and vectors. Although this pre-sentation is mainly intended for self-containment purposes, it is obviously not pos-sible to provide all the details of the formalism in the limited space available here.Reader therefore is referred to [14] for further details. Suppose that the RN is com-posed of V = {v1, . . . ,vn} robots, which have to accomplish M = {m1, . . . ,ml}missions. Each mission is, in turn, viewable as a sequence of primitive tasks (e.g.,reach the target, take a picture of the target, measure the temperature, collect thetarget, etc.), which requires some low-level behaviors and may be subject to prece-dence constraints (e.g., the target can be collected after it has been found). Thus,T = {t1, . . . , tm} denotes the set of all possible tasks for the RN.

The execution of tasks is governed by a set of rules. More specifically, eachrule specifies all the preconditions for tasks execution, and the resulting con-sequences (postconditions). All rules for all missions in M are defined by theset X = {x1, . . . ,xq}. Thus a mission m j is associated to a specific set of rulesXm j ⊆X . The set of all possible input events (a sensory input, a user command,etc.) is indicated as U = {u1, . . . ,up}. One or more inputs can be considered as


preconditions for a generic mission m j, thus these event are element of the setUm j ⊆U . Besides tasks and rules, generic outputs can be considered as postcondi-tions. All possible outputs in the network are indicated by the set Y = {y1, . . . ,yo}.

Briefly, the MDEF controls the execution of tasks by checking the status of therules at each time sample. Each rule whose preconditions are all true in the currenttime sample is fired, i.e., all the actions described in the consequent part of therule are triggered. The result of the logical preconditions evaluation provide theinformation needed to properly trigger tasks. Since conflicts in the assignment oftasks can occur, before starting the execution of task a multi-agent task allocationalgorithm is performed, such as the Look-Ahead strategy proposed in [15]. Afterthe task allocation step, postconditions are fired properly and robots start assignedtasks and eventually output events are produced.

2.2.2 Robot Identification and Localization

Robot identification and localization is performed using a vision-based trackingsystem. Indeed, E-Puck robots are equipped with encoders, and therefore odome-try could be adopted for robot location estimate. Nevertheless, we use an externalcamera, since it provides an absolute positioning system, thus avoiding error accu-mulation problems. In addition, based on visual information, the robot identificationissue can be easily solved.

We developed an algorithm that is able to simultaneously estimate the globalpositions of all the robots in the arena, determining, at the same time, which loca-tion belongs to which robot. We call this module Simultaneous Localization andIdentification (SLI). The output of the SLI module is fed into the control system.It is assumed that each robot is equipped with a circular coloured “hat” (see Fig-ure 2(b)). Different colours are used for the different robots. Each hat serves as

(a) (b)

Fig. 4: Results of the SLI module: (a) wandering behaviour; (b) wall-following be-haviour.


an artificial landmark for robot detection and identification. Specifically, the SLIincludes a semi-automatic learning procedure that allows us to learn and store amodel for each landmark; then, based on this model, it performs robot localizationand identification through a model matching technique.

The learning phase consists of the following steps. First, various pictures of eachrobot in the arena are acquired by the overhead camera; then, in each picture a polyg-onal area containing the robot is selected manually, and shape and colour informa-tion are extracted by analyzing the pixels of the selected area. Shape informationis represented by using the radius of the minimum enclosing circle for the selectedpolygonal area. Colour is defined, instead, by a three-dimensional vector contain-ing the median of each color component in the HSV color space. The procedure isrepeated for all the pictures, and median values for both the radius and the colorvector are computed and stored. Once the model of each robot has been learned, itcan be used for detecting and identifying all the robots in the arena.

The detection phase is based on a Circular Hough Transform, which allows one todetect all the circular objects within a specified radius interval based on the resultsof the model learning phase. Then, the pixels internal to each detected circle areanalyzed for robot identification, using colour information. Specifically, the medianof hue, saturation and value of the pixels internal to each circle are computed andare stored in a 3D color vector, which is then compared with the available robotmodels. A circle is finally recognized as being one of the robots if the Euclideandistance between its associated color vector and the closest robot color model is lessthan an experimentally determined threshold.

At this step, the position of each robot is expressed as pixel coordinates of thecentre of the circle in the image reference frame. A camera calibration procedureperformed once, after camera installation, allows us to transform the pixel positionin a real-world position. In order to improve the performance of the algorithm interms of speed and accuracy of both detection and identification phase, we imple-mented a Kalman filter-based robot tracking. As an example, Figure 4 shows theresult of the SLI module for four robots in two different experiments. Specifically,in Figure 4(a) the robots are tracked while wandering in the arena; in Figure 4(b),each robot carries out a wall-following task.

3 Experimental Results

In this section, we show the results of an experimental test performed using thesetup described in the previous sections. In this experiment, the network evolvesfrom a single-leader configuration to a multiple-leader configuration, in order forthe robots to perform exploration tasks in different parts of the arena starting froma rendez vous position. In the various phases of the test, the leader robots can bedistinguished from the other ones, as they are green-lighted. In Figure 5(a), the fourrobots form a unique network with one leader (i.e., the green-lighted robot withthe red hat). Figure 5(b) shows the trajectories of the four robots while going to


the rendez vous position. Successively, the network splits into two sub-networks oftwo robots each (Figure 5(c)). Both networks have their own leader (i.e., the green-lighted robot with the blue hat and the green-lighted robot with the red hat). Thetwo teams reach opposite sides of the arena to explore different areas. Figure 5(d)shows the tracked trajectories of the robots after the splitting of the network.

The graph in Figure 6 shows the time trace of the experiment. This graph can beeasily obtained by the saved data of the logging system. In particular, in this figure,we show: the network configuration, i.e. the single leader network (Network AB),and the two sub-networks (Network A and Network B); the missions in progress;the robots assigned to each mission and their network; the activation of tasks. For allthese information a line representing high (activation) or low (deactivation) state isdepicted. In Table 1, the correspondences among missions, robot networks, robotsand tasks are reported for better understanding the graph in Figure 6. It can be no-ticed that Mission 1, which involves all robots (i.e., Network AB), starts at samplinginstant 7. This mission is accomplished at time 33, when each robot in the networkterminates Task 1, that is, the GoToGoal task, in order to reach the rendez vous

(a) (b)

(c) (d)

Fig. 5: (a)-(b) Rendez vous of the networked robots with a unique leader; (c)-(d)splitting of the network into two sub-networks with two different leaders to exploreopposite sides of the arena


Table 1: Correspondences among missions, robot networks, robots, and tasks

Mission ID Network Name Robot ID Task ID

1 AB 1,2,3,4 1

1 2 B 2,4 1,3

3 A 1,3 1,2

point at the centre of the arena. After Mission 1, the network splits into the twosub-networks A and B. As we note, network B starts Mission 2 before network A atthe time instant 33. Obviously, the robots #2 and #4, which are members of networkB, become busy when Mission 2 starts, performing, first, Task 1 and, then, at time47, Task 3 (WallFollowing). At the instant 36, Mission 3 starts involving robots #1and #3. Network A, first, performs Task 1 and, then, Task 2 (ExploreEnvironment).At completion of Mission 3, at time 68, the robots of network A become availableand all the tasks they are involved in terminate. Finally, at time 74, Mission 2 isaccomplished, robots #2 and #4 are released, and all tasks in the whole network aresuccessfully terminated.

Fig. 6: Time trace graph for the experiment of Figure 5 .


4 Conclusions

We described an experimental set-up for multi-robot applications. The small sized,relatively simple robots E-Puck are utilized. A USB camera connected to a highspeed PC is adopted for robot monitoring and global positioning. Image processingprovides the positions of the robots to the control algorithms. The latter are based ondiscrete event framework, for the high level control, and a task and behaviour-baseddistributed control framework at the lower level.

We believe that this test bed is a useful experimental facility, which can be em-ployed for testing multi-robot coordination and control algorithms in graduate andundergraduate courses as well as for research purposes.

References

1. Burgard, W., Moors, M., Stachniss, C., and Schneider. F., 2005. Coordinated multi-robot ex-ploration. In IEEE Transactions on Robotics, 21(3).

2. Fierro, R., Das, A.,, Spletzer, J., Esposito J., Kumar, V., Ostrowski, J.P., Pappas, G., TaylorC.J., Hur Y., Alur, R., Lee, I., Grudic G., Ben Southall, B., 2002. A Framework and Archi-tecture for Multi-Robot Coordination, In The International Journal of Robotics Research,21(10-11), pp. 977–995.

3. Kumar, V., Rus, D., and Singh, S., 2004. Robot and sensor networks for first responders, InIEEE Pervasive Computing, vol. 3, no. 4, pp. 24–33, Oct.

4. Vincent, R., Fox, D., Ko, J., Konolige, K., Limketkai, B., Morisset, B., Ortiz, C., Schulz, D.,and Stewart, B., 2009. Distributed multirobot exploration, mapping, and task allocation. InAnnals of Mathematics and Artificial Intelligence, Springer Netherlands.

5. Pugh, J. and Martinoli, A., 2006. Multi-robot learning with particle swarm optimization. InProceedings of the Fifth International Joint Conference on Autonomous Agents and Multia-gent Systems.

6. Lerman, K., Chris Jones, C., Galstyan, A., Matarc, M.J. 2006. Analysis of Dynamic TaskAllocation in Multi-Robot Systems, International Journal of Robotics Research, 25(3), pp.225–241.

7. Viguria, A., Maza, I., and Ollero, A., 2007. SET: An algorithm for distributed multirobot taskallocation with dynamic negotiation based on task subsets. In Proc. of 2007 IEEE Interna-tional Conference on Robotics and Automation, Roma, Italy.

8. Werner, F., Rckert, U., Tanoto, A, Welzel, J. 2010. The Teleworkbench A Platform for Per-forming and Comparing Experiments in Robot Navigation, IEEE International Conferenceon Robotics and Automation (ICRA), Anchorage, AK, USA

9. Mondada, F., Franzi, E. and Guignard, A., 1999. The Development of Khepera. In Experi-ments with the Mini-Robot Khepera, pp. 7–14.

10. Mondada, F., Bonani, M., Raemy, X., Pugh, J., Cianci, C., Klaptocz, A., Magnenat, S., Zuf-ferey, J.-C., Floreano, D. and Martinoli, A., 2009. The E-Puck, a Robot Designed for Educa-tion in Engineering. In Proceedings of the 9th Conference on Autonomous Robot Systems andCompetitions, 1(1) pp. 59–65.

11. Brooks R.A., 1991. Intelligence without Representation. In Artificial Intelligence, Vol.47, pp.139–159.

12. Payton D.W., Keirsey D., Kimble D.M., Krozel J. and Rosenblatt J.K., 1992. Do whateverworks: A robust approach to fault-tolerant autonomous control, In Applied Intelligence, 2 (3),pp. 225–250.


13. Tacconi, D., Lewis, F., 1997. A new matrix model for discrete event systems: application tosimulation. In IEEE Control System Magazine, Volume 17, Issue 5, pp. 62–71.

14. Di Paola, D., Gasparri, A., Naso, D., Ulivi, G., and Lewis, F. L., 2011. Decentralized TaskSequencing and Multiple Mission Control for Heterogeneous Robotic Networks, In Proc. ofIEEE International Conference on Robotics and Automation.

15. Di Paola, D., Naso, D., and Turchiano, B., 2010. A Heuristic Approach to Task Assignmentand Control for Robotic Networks, In Proc. of the IEEE International Symposium on Indus-trial Electronics (ISIE).

An Experimental Testbed for Robotic Network...

Documents

Transcript of An Experimental Testbed for Robotic Network...