Challenges of the Multi-robot Team in the GUARDIANS Project

Challenges of the multi-robot team in the GUARDIANSproject

Lyuba Alboul, Joan Saez-Pons, Jacques Penders1 and Leo Nomdedeu2

1 Centre for Robotics and Automation, Sheffield Hallam University, Sheffield, UK{L.Alboul, J. Saez-Pons, J.Penders }@shu.ac.uk

2 Computer Engineering and Science, University Jaume I (UJI), 12071 Castellon, [email protected]

Abstract. The GUARDIANS multi-robot team is being designed to be deployedin a large warehouse to assist firefighters in the event or danger of a fire. Thelarge size of the environment together with development of dense smoke thatdrastically reduces visibility, represent major challenges in search and rescue op-erations. The GUARDIANS robots act alongside a firefighter and should provide,among others, the following tasks: to guide or accompany the firefighters on thesite while indicating possible obstacles and locations of danger and maintainingcommunications links. In order to fulfill the aforementioned tasks the robots needto be able to exert certain behaviours. Among the basic behaviours are capabilitiesto unite in a group - generate a formation - and navigate on the site while keep-ing this formation. The basic control model used to generate these behaviours isbased on the so-called social potential field framework, which we adapt to ful-fill specific tasks of the GUARDIANS scenario. All of the tasks can be achievedwithout central control, and some of the tasks can be performed even withoutexplicit communication among the robots. We discuss advantages and shortcom-ings of our model and present samples of implementation on ERA-MOBI robots,commonly referred to as Erratics.

1 Introduction

The GUARDIANS3 (Group of Unmanned Assistant Robots Deployed In AggregativeNavigation by Scent) project is an FP6, EU funded project, which aims at developinga team (swarm) of heterogenous autonomous robots to assist fire-fighters in search andrescue operations in an industrial warehouse in the event or danger of fire [9].The challenge of the GUARDIANS project is to apply the team of robots for performingtasks in a real-life situation.The GUARDIANS scenario has been chosen after consulting with South Yorkshire Fireand Rescue Service, UK, referred further to as SYFIRE. They indicated that industrial

3GUARDIANS runs from 2007 to 2010, and involves the following partners: Sheffield HallamUniversity (coordinator), Robotic Intelligence Lab, Jaume-I University, Spain; Heinz NixdorfInstitute, University of Paderborn, Germany; Institute of Systems and Robotics, University ofCoimbra, Portugal; Space Application Services, Belgium; K-Team Switzerland; Dept. of Elec-trical and Electronics Engineering, TOBB University of Economics and Technology, Turkey;Robotnik Automation, Spain; and South Yorkshire Fire and Rescue Service, UK.

2 Alboul, Penders, Saez-Pons, Nomdedeu

warehouses in the emergency of fire are a major concern to them. Searching for victimsis dangerous due to the several, interrelated, factors. Firstly, enormous dimensions ofthe warehouses already represent a challenge for a search, which only aggravates bythe expected low visibility when smoke develops. Next are the time constraints; one isbeing the amount of oxygen in the breathing apparatus of a firefighter which sufficesfor about 20 minutes, another one is the crawling speed if smoke has been developed(approximately 12m a minute) - firefighters can proceed about 240m with a full tank.Taking into account that they have to negotiate the 20 minutes of air between gettingin and getting out, the maximum advance they can make is only 120m which is lessthan the largest dimension of the modern warehouses. Another issue related to the timeconstraint is such phenomenon asflashover, which can occur also very quickly [3].However, as SYFIRE pointed out that apart from the smoke, the warehouse is, in gen-eral, in a normal and orderly state. This implies that ground is easily passable and there-fore no particular restrictions on robots motion are imposed; even wheeled mini robotsare suitable.The multi-robot team in the GUARDIANS projects consists mostly of mini-robotsKhepera III and middle-sized Erratic robots, presented in Figure 1.

(a) (b) (c)

Fig. 1. Team robots in GUARDIANS, (a) Khepera III (K-TEAM), (b) ERRATIC robot (VidereDesign). (c) Robot Guardian.

These robots are intended to be applied in some, possibly large, quantity. An exceptionis the robot called Guardian, developed by the partner Robotnik Automation. This robotcan be a member of a team, but also can perform certain task where a more powerfulrobot may be needed, such as carrying tools for firefighters.The paper is organised as follows. Section 2 gives a short introduction to the teamrobotics, with a focus on the GUARDIANS multi-robot team cooperation and tasksto be performed. Section 3 is dedicated to the description of the basic control modelin the GUARDIANS, that provides necessary navigation behaviours required from aheterogenous group of robots in the GUARDIANS scenario. Section 3 proceeds with adescription of implementation of the algorithms based on the presented control model,on the Erratics robots, and indicates the encountered challenges. Section 4 discusses inbrief current work and concludes the paper.

Challenges of the multi-robot team in the GUARDIANS project 3

2 Team robotics

Team or Collective robotics are divided in two major streams:accidental or non-intenti-onal cooperationandintentional cooperation[16]. Conventionally, the Swarm roboticsparadigm is used for non-intentional cooperation; cooperation just happens and emergesfrom the group behaviour without being made explicit. Intentional cooperation can bedescribed as combining particular behaviours aiming at an explicit goal. Robots in-teracting with people can comprise both aspects, whereas people, in general, interactintentionally with robots.

2.1 GUARDIANS robot team cooperation

The GUARDIANS robots team should exercise certain cooperation in order to fulfilthe tasks assigned to them. The tasks can be roughly split into two main categories.The tasks of the first category provide direct assistance to fire-fighters, such as guidinga firefighter, accompanying them and indicating them possible obstacles and locationsof danger. The second category comprises the so-called supportive tasks that can befulfilled without a human squad-leader, such as deployment on the site, positioning asbeacons and maintaining communication. Some tasks of both categories are overlapped,such as searching and navigating the environment; the main difference is that in the firstcategory the robots act within an immediate vicinity of the human, and therefore theirsensor range covers only a relatively small area of the environment, whereas in thesecond category of tasks the robots can disperse in the site and therefore the perceptionof the environment is more global.In both categories both non-intentional and intentional cooperation are applied. There-fore, some developments from the Swarm robotics are used. Swarm robotics research isdistinguished by the following criteria [17]: a swarm consists of(i) a large number, of(ii) homogenous,(iii ) autonomous,(iv) relatively incapable or inefficient robots with(v) local sensing and communication capabilities.The GUARDIANS group of robots does not comply directly to this definition. Firstof all, the group consists of non-homogenous robots (different either by physical pa-rameters, or by their functionality), and human agents can be also part of the group.Secondly, the number of robots in the group may be not very large in particular if robotsaccompany a firefighter.However, some characteristics of a swarm are present as well. The GUARDIANSgroup does not have a predetermined size, and due to huge dimensions of a warehousea large number of robots may be required to fulfil tasks in the second category (criterion(i)). Communication with the outside might not be possible and the human being willbe busy ensuring their own safety, thus autonomy (criterion(iii )) is a requirement. Asingle robot cannot do much in a large warehouse (criterion(iv)) and as communicationcannot be guaranteed the robot cannot but rely on local information (criterion(v)).Swarm robotics is also often divided into so-called communicative-less and commu-nicative robotics. The former case, in general, means that ‘communication’ is assumedto be implicit, i.e. robots react to each other without explicitly exchanging messages,whereas in communicative swarm robots can exchange information. In GUARDIANS


both types of swarm robotics are used; some more details are given in Section 3 andSection 4.The GUARDIANS project uses developments of swarm robotics field, whenever is ap-propriate and in what follows the term ‘swarm’ is also used to describe correspondingbehaviours. Surveys on recent advances and the state-of-the-art in swarms can be foundin [4, 18, 10] and a web database on swarm robotics related literature has been compiledon the dedicated site4.In this paper we focus mostly on basic navigation behaviours of multi-robot or human-robot teams, which have to be achieved without central and on-line control. The be-haviours described are needed in both categories of GUARDIANS robots’ tasks, andthey are essential when robots directly assist the firefighter. These behaviours, gener-ally speaking, can be also achieved without explicit communication and therefore canbe still applicable when communication links are severed. In this case we can speak ofnon-intentional cooperation. The generated global behaviour is relatively independentof the number of robots in the team, that makes the team also robust to failures of indi-vidual robots. These behaviours can be enhanced if the robots communicate, and thuscooperation becomes intentional. We briefly touch upon this enhancement at the end ofSection 3 and in Section 4.

2.2 GUARDIANS team description

In the GUARDIANS scenario main performers are robots, humans and obstacles, whichwe identify as classes of GUARDIANS agents. The classes are: 1) the class of robotsr i ,i = 1,2, . . . ,n; 2) the class of humans (fire-fighters)h j , j = 1,2, . . . ,m; and 3) the classof obstaclesok, k = 1,2, . . . , l .The class of robots, which may beheterogenous, can be split in several sub-classes ofhomogenousrobots and robots may be eitherholonomicor non-holonomic. The agentsare situated in a domainD ⊂ R2. In a real-life situation of fire fighting, humans ingeneral act in groups of two: one person takes the role of the leader and the secondis the follower. However, we assume that only one human being is present and thehuman takes the role of leader. Nevertheless the tasks of the robot team is not just tofollow the human but also to assist him/her to navigate safely and prevent the humanfrom colliding with obstacles. To a certain extent, robots take the role of the secondfirefighter acting as a reference unit. The human does not communicate to the robotsand is in this context beyond control and performs two basic behaviours: standing stillor moving. The robots have to organize themselves into some kind of formations eithersurrounding or following the firefighter and maintain this formation throughout.Robots and humans are referred further to asactive agents, and obstacles aspassivecorrespondingly.The robots actindependentlyandasynchronously. We also assume that they areoblivi-ous, meaning that they do neither remember observations nor computations performedin previous steps contrary to the assumptions made in [6]. However, this assumptioncan be relaxed in order to produce more stable behaviours (see Section 4). The sensingrange of each robot may vary from zero to infinity. We refer to the sensing range of a

4http://swarm-robotics.org/


robot as itsvisibility domain. In the current section thefield of viewof each robot issupposed to be 360 degrees, resulting in acircular visibility domain. Let us note thata robot can have several visibility domains each for each sensor installed on a robot.However, we can select one visibility domain as the main one and do all the reasoningwith respect to this domain.We assume that each robot can recognise humans and distinguish robots from obsta-cles and humans. In computational simulations this is done by indicating the class ofan agent, for example, by assigning a specific flag to the agents of the same class. Inpractice, this can be achieved in various ways. Depending on the sensors a trackingsystem can be developed, focussing on the characteristics of the stepping feet (of ahuman) [13]. Other techniques (for communicating robots) which are being developedand tested in the GUARDIANS consortium, include the use of ultrasonic sensors, ra-dio signal intensity, and IR. In our implementation trials the robots are able to localisethemselves and the other robots in their visibility domains by using a rough map of theenvironment provided to them. We do not involve here explicit interaction between arobot team and a firefighter, as human-robot interface development does not belong tothe basic behaviours of the robot teams. We refer the reader to related papers of theGUARDIANS consortium members [12, 11].

2.3 Human-multirobot team formations

(a) (b)

Fig. 2. Two examples of human-multirobots formations. (a) Maximal formation, (b) Minimalformation.

In the GUARDIANS scenario, formations are defined as groups of agents establishingand maintaining a certain configuration without a predetermined shape (opposite to theassumption expressed, for example, in [7, 2]) but without spreading too much from eachother. One of requirement of the GUARDIANS (human)-multirobot formation is itsadaptability: formation can be stretched and deformed when obstacles are in the closevicinity since the firefighter has to be protected and escorted all times. Considering agroup of agents as a graph (network) where each agent represents a node, and agentsare interconnected via their visibility domains, we can define formation as follows:


Definition 1. The GUARDIANS formation represents a connected graph, where nodesare robots or a human and edges are virtual links between the nodes, with a propertythat each edge is situated in the intersection of the visibility domains of nodes which itconnects.

The definition implies that the distancer i between neighboring agents (either a robotor a human) does not exceed the certain valuedmax. dmax can be defined to be smalleror equal either to the (smallest) radius of the visibility domains or reaction domains ofagents. This definition is similar to the definition of the formation given in [8].Neither initial positions, nor final positions of agents are predefined. To some extent,this definition complies with the definition proposed in [5], where the group determinesautonomously the most appropriated assignment of positions in the formation.The definition of formation given above can be specified further.Indeed, both configurations presented in Figure 2 comply with Definition 1. Both con-figurations can be useful for GUARDIANS scenario. The one on the left can occurwhen a group passes a narrow passage, and the one the right may be desirable in anopen space. The connected graph that describes a formation may contain loops.We, therefore, define adegree g, g= 1, ...,n−1 of a formation by the minimum numberof the visibility domains that contain a spanning tree of the graph of a formation. We putg = ∞ if there are agents without virtual links in their visibility domains (essentially, itmeans that there is no formation). In Figure 2 amaximal(g = n−1) andminimal (g =1) formations are depicted. In the latter case the ‘visibility’ domain of the firefighteris depicted by a dashed line and this visibility domain contains the most ‘compact’spanning tree.

3 Control model

In order to achieve formation generation and their maintenance we apply robot-robotand robot-fire-fighter avoidance/attraction as well as robot-obstacle avoidance. Our me-thod is based on the social potential field framework, which was introduced by Reif andWang [15].The method for generating navigation behaviour patterns in mixed human-robot groupsin complex environments has been initially discussed in [1].We defineRobot-Human, Robot-Robot and Robot-Obstacle Potential Functions.The robots have to avoid collision with the human and obstacles, and at the same timeto be able to approach and keep the human within their sensor range. While robots ‘see’the fire-fighter they will execute repulsion behaviour among themselves; however if agroup of robots have lost a fire-fighter in their visibility domain, we would like thatrobot do not disperse and therefore attraction behaviour is executed towards the robotsin a robot’s visibility domain. Therefore the aforementioned functions are defined asfollows:

1. Robot-human potential functionPHumanbetween the robotrm and the HumanH is:

PHuman(dHrm

) =1

(khrr(dHrm−whrr))2 +

1(khra(dH

rm−whra))2 (1)


wherekhrr , khra, whrr andwhra are scaling parameters, anddHrm

is the distance be-tween the robotrm and the humanH.

2. Robot-Robot Potential functionPRobot between the robotrm and the robotr i is, inthe presence of the human in a robot visibility domain, is defined

PRobot(dr irm

) =1

(krr (dr irm−wrr ))2 (2)

wherekrr andwrr are scaling parameters anddr irm is the distance between the robot

rm and the robotr i . Obviouslydr irm = drm

r i. In this case only the repulsion term is

present. If a robot loses the human, thenPRobot has a similar form toPhuman.In the presence of a human we assume that robots avoid each other, by exerting oneach other the repulsive forceIR(m,i), the magnitude of which is determined givenby the derivativePrr (rmi) of PRobot(d

r irm) with respect todr i

rm.In the absence of a human in the visibility domain of a robot, the force acting on therobot by other robots in its visibility domain becomes a combination of attractionand repulsion similar to the potential function between a robot and the human inorder to avoid spreading robots in the site. The corresponding function is:

PRobot(dr irm

) =1

(krr (dr irm−wrr ))2 +

1(kra(d

r irm−wra))2 (3)

wherekrr , kra, wrr andwra are scaling parameters, anddr irm is the distance between

the robotrm and the robotr i .3. Robot-Obstacle Potential FunctionPRobot is defined between the robotrm and the

obstacleOs as

PObstacle(dOsrm

) =1

(kro(dOsrm −wro))2

(4)

wherekro andwro are scaling parameters anddOsrm

is the distance between the robotrm and the obstacleOs. We assume that robots avoid the obstacles and therefore donot introduce the ‘attraction’ term.

The social potential functionPSocial of rm is defined as the sum of the aforementionedpotential functions:

PSocial(Xrm) = POR (Xrm)+P

r jr i (Xrm)+PH

r (Xrm)

=S

∑s=1

PObstacle(dOsrm

)+M

∑j=1, j 6=i

PRobot(dr irm

)+PHuman(dHrm

) (5)

The artificial force−→F Arti(Xrm) which is ‘acting’ on robotrm is, therefore, computed as

the sum of gradients of corresponding potential functions:

−→F Arti(Xrm) =

−→F Arti Obstacle(Xrm)+

−→F Arti Robot(Xrm)+

−→F Arti Human(Xrm)


Table 1.Values of the parameters used in the potential functions employed for simulation.

Potential Function Parameter Value

Robot-Obstacle kro = 5.00, wro = 0.49Robot-Robot krr = 2.00, wrr = 0.98

kra = 2.00, wra = 4.00Robot-Human khrr = 5.00, whrr = 0.82

khra = 2.00, whra = 4.00

Parameters The parameters of all the employed potential functions are shown in thetable 1.This selection is loosely based on the specifications and characteristics of the consideredsystem. We use the dimensions of an Erratic robot (given in Table 2), but it can be easilyadapted to other types of robots.

Table 2.Basic parameters of the ERA-MOBI robot.

ER-AMOBI Parameter Value

Dimensions L = 40cm,W = 41cm,H = 15cmMaximum Speed 2ms−1

Sensors Laser Range Finder-Hokuyo(range 4m)

For example, the robot’s size determines the value of the contact distance, i.e. for therobot-obstacle potential functionwro represents the distance at which the edges of therobot and the obstacle would come into physical contact (wro = 0.49). The same selec-tion criteria applies to the robot-obstacle (wrr ,wra) and robot-human (whrr ,whra) contactdistances. The parameterkro in the potential function (4) determines at which distancethe repulsive potential starts pushing the robot away from the obstacle. Choosingkro = 5means that the robot will not start avoiding the obstacles until approximatelydOs

Rm= 1.5

meters. The same selection criteria has been applied for the parameters of the remainingpotential functions.

Algorithm The pseudocode of the algorithm that uses the Social Potential forces ap-proach for the implementation in the real-world scenario can be seen in Algorithm 1.Each robot calculates the resultant social potential force(Fx,Fy) which dictates the ve-locity of each robot(vx,vy). We use a discrete-time approximation to the continuousbehaviour of the robots, with time-step∆ t. The speed of the robots is bounded to amaximum velocityVmax. The output of thecompute motionalgorithm is the directionand the speed of the robot.


Algorithm 1 Compute motion1: for all robots but current roboti do2: determine the distancer to robot j3: determine the spherical coordinateθ to r j4: netForce= SocialPotentialForce(r)5: Fx⇐ Fx(netForce)×cos(θ)6: Fy⇐ Fy(netForce)×sin(θ)7: end for8: ∆vx⇐ ∆ t×Fx

9: ∆vy⇐ ∆ t×Fy

10: vx⇐ vx +∆vx

11: vy⇐ vy +∆vy

12: if ‖v‖> Vmax then13: vx⇐ (vx×Vmax)/‖v‖14: vy⇐ (vy×Vmax)/‖v‖15: end if16: speed⇐‖v‖17: direction⇐ tan−1(vy/vx)18: move the robot with speed and direction

Our algorithms have been tested using and Player/Stage software5 that allows theirdirect application to real robots. Simulation results comply with our theoretical consid-erations regarding formation generation and keeping, and show that our algorithms arerobust and capable to deal with teams of different sizes and failure of individual agents,both robots and humans.

Stability considerations The presented control model has been analysed for stability.The stability analysis is based on geometric concepts which avoids heavy computationwhile providing qualitative proofs of attainability of desired formations under certainconditions. Some results on stability analysis were presented in [1]. The main conclu-sions are the following (sufficient conditions for formation maintenance):

1. In the absence of obstacles the robot are always gathered around the human, form-ing a minimal formation, if at the initial step the robots and human are in formationaccording to our definition;

2. In the presence of obstacles, if the human (at rest) and robot agents are in forma-tion at any step, all robots will gather around the human. Thedegf in of the finalformation does not exceed thedeginit of the initial one;

3. If the human moves and robots are in formation at any step, the robot team willfollow the human.

In the cases 2) and 3) some robots may be lost due to the fact that an obstacle will appearin their visibility domain which may break the formation. In Section 4 we present anadaptation of our framework by introducing some, still very limited, ‘memory’ to arobot.

5http://playerstage.cvs.sourceforge.net/viewvc/playerstage/papers/


3.1 Examples of Implementation

Fig. 3.Agents chart used in demo’s

We have tested our algorithms on Erratic’s mobile platforms. Four Erratic platformsequipped with: 1) On board computer equipped with wi-fi; and 2) Hokuyo laser-rangefinder, ‘participated’ in the tests. One of the robot ‘played’ the role of a firefighter. Themain goal of the implementation was to demonstrate that robots are able to generate aformation and keep the formation while follow a human (or a leader robot).The implementation of our algorithms in the real-world scenario with the ERRATICrobots represented a challenging issue. Most of the efforts focussed on achieving a re-liable way of detecting the components of the multi robot human team without usingany sort of tracking system. The considered solution implied to design an architectureenvironment capable of implementing different robot behaviors (aggregation and fol-lowing), handle communication, run distinct robot navigation algorithms (localizationand collision avoidance), define different agent types, interact with the hardware in-volved (actuators and sensors), interface with the users and everything combined withdifferent software platforms (Player, Javaclient and JADE).In order to mimic relative robot detection and distance estimation that is still undervalidation, robots were provided with a map of the environment in which they localisethemselves by using the Adaptive Monte-Carlo localisation method.JADE (Java Agent Development Environment)6 was used to take care of the agent’slife-cycle and other agent-related issues. JADE provides a runtime environment and

6http://jade.tilab.com/papers-exp.htm


Fig. 4.Software components used for demo’s

agent communication and management facilities for rapid and robust agents-based de-velopments. In our demonstration we have developed 4 different types of agents, asshown in Figure 3, each one having a clear role in the demo. Note that agents here aredifferent from our the classes of agents determined in Section 2.Each agent is composed of a set of behaviours that determines how this agent acts orreacts to stimuli. For our demo we have developed several communication, swarming,and following behaviours, and assigned them in different ways to different agent typesto get a set of multi-functional agents. By doing so, we are able to share the robots andhuman poses through the whole team, allowing swarming techniques to take advantageof these essential data.In Figure 4 we can see the combination of software pieces that plays in our team. Player,from Player/Stage, acts as a Hardware Abstraction Layer, allowing us to forget specifichardware problems. JavaClient allows us to connect to the Player server from a Javaenvironment, while JADE provides us the ability to use Agents. In terms of runtime,Agents, and their behaviours, run on top of an agent container provided by the JADE,making use of the JavaClient to access Player facilities.Some of implementations were demonstrated during the evaluation of the GUARDIANSproject’s progress in Brussels in January 2009, and were met enthusiastically by the au-dience. In Figure 5 snapshots of video of the experiments on formation generation andkeeping on a group of Erratic’s robots are presented. The robots with a flag ‘plays’ therole of the firefighter.


(a) (b)

Fig. 5. Two snapshots of experiments on formation generation and maintenance using Erratic’s .(a) Formation generation, (b) Formation maintenance.

4 Work in development

The control models, based on artificial potential fields, have drawbacks such as get-ting in local minima. Our control model is not an exception, however we establishedthe important condition that would prevent undesirable local minima: the robots haveto be in formation, as defined in Section 2, at any step. It means that a robot may not‘sense’ the leader/human/goal at any step, but a chain (path) must exist consisting of’formation’ edges, that connects the robot to the leader/human/goal. Some authors re-alise this (without explicitly formulating neither sufficient nor necessary conditions).However, in order to avoid local minima, all robots are either assumed to be able tosense the leader or its equivalent at any step, or be able to reproduce the previous stepsof the leader [14, 6]. This leads to extensive computation and higher complexity of thecorresponding algorithms.We presently work on a method which only slightly increases necessary computations.We allow a robot to ‘remember’ the force between a robot and the leader at the previousstep. A robot at each step calculates the force/direction between itself and the leader andremember this force till the next step. The force which was calculated at the step beforethe previous one the robot ‘forgets’. Therefore, at each step a robot has two ‘human-robot’ forces in its memory. If a robot senses the leader it applies the current force, ifthe robot is lost, it applies the force at the previous step. An informal idea behind thisapproach is that a robot may lose the leader only if an obstacle or another robot ‘blocks’the ’view’ of the leader. If the obstacle is the reason of losing the leader, it means thatthe leader turns along the obstacle, otherwise it will not disappear. Therefore, if a robotcontinues to follow the previous direction, it may achieve a point where it will sense theleader again. If robots communicate than this method can be applied to several ‘lost’robots as well. In this case the robots do not attract to each other, but follow only thedirection calculated at the previous step. While the formal justification of this methodis still under consideration, we have tested this new approach on a group of three robots(one being a leader) in a simulated setting. Snapshots of a simulation in Player/Stageis presented in Figure 6. Currently we are working on the extension of the method torobots team of arbitrary sizes. We are also developing a framework that will combine


the described basic behaviours with other behaviours, such as wall following, and alloweasy ‘switch’ between behaviours.

(a) (b)

(c) (d)

Fig. 6. Behaviour pattern of a robot team by using the adapted algorithm. (a) Robots are movingin a triangular formation, following the leader; (b) One of the robot-followers lost the leader; (c)The robot ’found’ the leader; (d) The robots resumed moving in a triangular formation

.

Acknowledgements

The authors wish to acknowledge that the GUARDIANS project is a cooperation be-tween staff at all project partners, as well as Master students, Chathura Wijaya SriDolahamuna, Carlos Bataller Narbo, Manuel Espinosa Prieto, Miquel Cerezo Gandıaand Jose Marıa Blasco Igual, who worked on different aspects of our control model.The contributions of all of them have been essential to the development of the projectand this paper. The EU FP6 framework provided financial support.


References

1. L. Alboul, J. Saez-Pons, and J. Penders. Mixed human-robot team navigation in the guardiansproject. InInternational Workshop on Safety Security and Rescue Robotics (SSRR 2008),2008.

2. G. Baldassare, S. Nolfi, and D. Parisi. Evolving mobile robots able to display collective be-haviour. In C. Hemerlijk, editor,International Workshop on Self-Organisation and Evolutionof Social Behaviour, pages 11–22. Zurich:ETH, 2002.

3. W. Clark.Firefighting Principles and Practices. 1991.4. M. Dorigo and E. Sahin. Special issue on swarm robotics.Autonomous Robots, 17(2-3),

September 2004.5. Lemay, M. et al. Autonomous initialization of robot formations. InRobotics and Automation,

Proceedings. ICRA ’04., pages 3018–3023, 2004.6. P. V. Fazenda and U. Lima. Non-holonomic robot formations with obstacle compliant ge-

ometry. InProc. of IAV 2007, 2007.7. V. Gazi and K.M. Passino. Stability analysis of social foraging swarms.IEEETSMC : Part

B, 34(1):539–557, February 2004.8. G. J. Pappas H. G. Tanner and V. Kumar. Leader-to-formation stability.IEEE Transactions

on Robotics and Automation, 20:443–455, 2004.9. C. Roast J. Penders, L. Alboul and E. Cervera. Robot swarming in the Guardians project. In

In ECCS’07. European Conference on Complex Systems’07, 2007.10. V. J. Kumar, N. E. Leonard, and A. S. Morse, editors.Cooperative Control: 2003 Block

Island Workshop on Cooperative Control, volume 309 ofLecture Notes in Control and In-formation Sciences. Springer-Verlag, 2005.

11. A. M. Naghsh and C. R. Roast. Designing user interaction with robots swarms in emergencysettings. InProceedings of the 5th Nordic Conference on Human-Computer interaction:Building Bridges, 2008.

12. Gancet J. Tanoto Naghsh, A. M. and C. R. Roast. Analysis and design of human-robot swarminteraction in firefighting. InProc. Of IEEE Conference of Robot-Human Interactions (RO-MAN), 2008.

13. L. Nomdedeu, J. Sales, E. Cervera, J. Alemany, C. Sebastia, M. Ilzkovitz, J. Penders, andV. Gazi. An experiment on squad navigation of human and robots. In Penders et al., editor,Robotics for Risky Interventions and Surveillance of the Environment. Universitat Jaume I,2008.

14. E. FiorelliOgren and N. E. Leonard. Cooperative control of mobile sensor networks: Adap-tive gradient climbing in a distributed environment. volume 49, page 1292.

15. J. H. Reif and H. Wang. Social potential fields: A distributed behavioral control for au-tonomous robots.Robotics and Autonomous Systems, 27(3):171–195, May 1999.

16. Paul Rybski, Amy Larson, Michael Lindahl, and Maria Gini. Performance evaluation ofmultiple robots in a search and retrieval task. InIn Workshop on Artificial Intelligence andManufacturing, pages 153–160. AAAI Press, 1998.

17. E. Sahin. Swarm robotics: From sources of inspiration to domains of application. InSwarmRobotics: SAB 2004 International Workshop, Santa Monica, CA, USA, July 17, 2004, RevisedSelected Papers, pages 10–20. Lecture Notes in Computer Science, Springer Verlag, 2005.

18. E. Sahin and W. M. Spears, editors.Swarm Robotics, A State of the Art Survey. LectureNotes in Computer Science 3342. Springer-Verlag, Berlin Heidelberg, 2005.

Challenges of the Multi-robot Team in the GUARDIANS Project

Documents

Transcript of Challenges of the Multi-robot Team in the GUARDIANS Project