MAS2CAR ARCHITECTURE

Multi-agent System to Control and Coordinate teAmworking Robots

Mehdi Mouad

, Lounis Adouane

, Pierre Schmitt

, Djamel Khadraoui

and Philippe Martinet

Centre de Rechere Public Henri Tudor, Luxembourg, Luxembourg

Laboratoire des Sciences et Mat´eriaux pour l’Electronique et d’Automatique, Universit´e Blaise Pascal

Clermont-Ferrand, France

Keywords:

Multi-robots system, Multi-agent system, Organizational model, Robots cooperation, Robots control archi-

tectures, Hybrid control.

Abstract:

This paper aims to present the Multi-Agent System to Control and Coordinate teAmworking Robots

(MAS2CAR), a new architecture to control a group of coordinated autonomous robots in unstructured en-

vironments. MAS2CAR covers two main layers: (i) the Control Layer and we focus on (ii) the Coordination

Layer. The control module is responsible for a part of the decision making process while taking into account

robot’s structural constraints. Despite this autonomy possibility, the Coordination Layer manages the robots in

order to bring cooperative behavior and to allow team-work. In this paper we present a scenario validating our

approach based upon the multi-agent systems (MAS). Thanks to its reliability we have chosen the M OISE

Inst

organizational model and we will present how it can be used for this use-case. Moreover, regarding to the

implementation part, we have retained U TOPIA, a framework which automatically build a MAS thanks to a

M OISE

Inst

speciﬁcation.

1 INTRODUCTION

A multi-robot system can be deﬁned as a set of

robots operating in the same work space. Given

some robotics task speciﬁed by a designer, a multiple-

robot system can beneﬁt from cooperativebehavior if,

due to some cooperation or coordination mechanism,

there is an increase in the total utility of the system.

In the case of mobile robotics, the need to oper-

ate in increasingly complex and unstructured environ-

ments, and at the same time reduce costs to a mini-

mum in terms of time, power, etc.), raise the develop-

ment of autonomous robots. The ultimate goal is the

capability of achieving coordinated movements and

of carrying out tasks that usually require human as-

sistance. This need for autonomy requires from the

robot a certain capacity of being able at any moment

to assess both its state and its environment that are

usually combined with different other robots states as

well as with its mission requirements in order to make

coherent control decisions. If we consider navigation

aspects, autonomous mobile robots are usually em-

bedded with sensors/actuators according to the mis-

sion to be performed. This complexity induces major

challenges both at the development of robotics con-

trol architecture system but also at the design of navi-

gation software.

Indeed, an autonomous mobile robot has to carry

out a set of sensors/actuators dedicated to its own nav-

igation and another sensors set that can change ac-

cording to the mission to be performed. Therefore the

navigation software developed for these vehicles be-

come complex and requires a design methodology.

This paper aims at presenting MAS2CAR

, an

architecture model for multi-mobile robots based on

Multi-Agent System (MAS) coordination. This pa-

per is organized as follow: in section 2 we make an

overview of the related works in the areas of multi-

robots and MAS, in 3 we introduce our architec-

ture model focusing on the tree main layers of our

model: Physical Layer, Control Layer and Coordina-

tion Layer. Subsequently, we focus on the Coordina-

tion Layer and we explain how the MAS have been

used. More particularly, and we describe the Organi-

zation Speciﬁcation (OS) in section 4.

Multi-Agent System to Control and Coordinate teAm-

working Robots (MAS2CAR).

451

Mouad M., Adouane L., Schmitt P., Khadraoui D. and Martinet P..

MAS2CAR ARCHITECTURE - Multi-agent System to Control and Coordinate teAmworking Robots.

DOI: 10.5220/0003649904510456

In Proceedings of the 8th International Conference on Informatics in Control, Automation and Robotics (MORAS-2011), pages 451-456

ISBN: 978-989-8425-75-1

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

2 STATE OF THE ART

Robotics software is now one of essential part of

robotics system development. Therefore, software ar-

chitectures design methods and concepts, are mainly

made to enhance evolutionary, modularity... and to

avoid redesign costs. The last years have seen active

research in the ﬁeld of distributed robotics, and in the

development of architectures for multi-robot coordi-

nation. These architectures have focused on providing

different capabilities to the group of robots. For in-

stance, ALLIANCE (Parker, 1998), a behavior-based

software architecture, has focused on fault tolerant

cooperative control. In Morrow and Khosla (Morrow

et al., 1997), robot skills are expressed as ﬁnite state

machines (FSM).

The coordination of robots for large-scale assem-

bly has been considered in Simmons et al. (Simmons

et al., 2000). Klavins and Koditschek (Klavins et al.,

2000) have presented tools for composing hybrid con-

trol programs for a class of distributed robotics sys-

tems. This approach assumes that a palette of con-

trollers, each one implements a bihavior. These con-

trollers, i.e, robot behaviors, are sequentially com-

posed using the techniques introduced in Burridge,

Rizzi, and Koditschek (Burridge et al., 1999). These

ideas are applied to the design of assembly tasks as

found in automated factories.

Control software architecture design approaches

are usually classiﬁed into three main categories:

• Reactive v.s. Cognitive (deliberative) architec-

tures, many modules connects several inputs sen-

sors/actuators, each module implements a behav-

ior. These behaviors are called “reactive” be-

cause they provide an immediate output of an in-

put value, and cognitive otherwise.

• Hierarchical v.s. Non-Hierarchical architectures,

the hierarchical architectures are built in several

levels, usually three. Decisions are taken in the

higher level; the intermediate level is dedicated

to control and supervision. The low level deals

with all periodical treatment related to the instru-

mentation, such as actuator control or measuring

instrument management (Lumia et al., 1990).

• Hybrid architectures are a mix of the two previous

ones. Usually these are structured in three layers:

the deliberative layer, based on planning, the con-

trol executionlayer and a functional reactive layer.

It’s in the same time reactive with a cognitive level

(planning for example).

To bring coordination into a multi robotics system

we can distinguish centralized approaches from dis-

tributed ones.

• A centralized system has a robot (leader) in charge

of organizing the work of the other robots. The

leader is involved in the decision process for the

whole team, while the other members can act only

according to the leader’s directions.

• In contrast, a distributed system is composed of

robots that are completely autonomous in the de-

cision process with respect to each other; there is

no leader in such cases.

Among multi-agent based Robotics Development

Environments (RDE), OROCOS architecture (Bruyn-

inckx, 2001) is a modular framework capable of con-

troling multi-robot systems providing an environment

for implementation of real-time control systems with

various abstraction levels for hardware device drivers.

ARTIS architecture (Botti et al., 1999) allows de-

veloping agents working in hard real-time environ-

ments. Using an off-line analysis of the speciﬁca-

tion, the architecture performs the execution of the

entire system. The Agents allows the self-adaptation

in the changing environments, by executing tasks au-

tonomously.

IDEA architecture (Intelligent Distributed Execu-

tion Architecture) (Muscettola et al., 2002) based on

a multi-agent system to control multi-robot systems.

Where each agent can be a functional module, a plan-

ner, a diagnostic system, ... The operation of agents

is based on the “procedure” and “token”. IDEA

agents can communicate and monitor each other. The

database is partitioned online of time (timelines), each

representing the temporal evolution of a sub-system

property.

ARTIS and IDEA architectures are a very inter-

esting architectures, and both describes one agent ar-

chitecture. When an ARTIS agent is applied to robot,

it contains sensor/actuator modules, control modules

for real time execution and a reﬂex layer for criti-

cal events, its in-agents are dedicated to the different

behaviors such as localization, trajectory planner, ra-

dio communication, obstacle avoidance... And IDEA

is a multi agent framework for planning and execu-

tion for agents, it’s composed of three layers: Token

and procedures, communication wrapper, and a vir-

tual machine which integrates planning as the reason-

ing module at the core of the execution engine, the in-

terplaying of its different modules (the domain model,

the plan database, the plan runner and the reactive

planner) provides the basis for agents autonomy. both

have a good coordination level if we consider them in

a multi-robot context, but it does not rely on organi-

zational rules to build agents, which is the case of our

architecture, our agents are built through an organiza-

tion, the organizational model takes into account all

the tasks and constraints, and on this basis we build

ICINCO 2011 - 8th International Conference on Informatics in Control, Automation and Robotics

452

our agents thanks to U TOPIA .

There is an other multi-agent Hybrid architecture

(Fierro and Das, 2002) which describe a high-level

language with formal semantics, to describe multi-

agent networked robotics systems. This architecture

allows the development of complex multi-robot be-

havior via: hierarchical and sequential composition

of control; estimation modes, and parallel composi-

tion of agents.

This architecture is the closest given into our

model. Infact it’s organized at the highest level of

the hierarchy, in two interacting agents: a coordina-

tion agent and a robot-group agent, which approxi-

mately represent in our architecture: M OISE

Inst

the

organizational model and U TOPIA the MAS instanti-

ation middelware. The coordination agent reduces to

the speciﬁcation of communication channels between

robot agents, and the speciﬁcation of parameters for

transitions and the instantiation of each agent within

the robot-group agent.

A MAS particularlymeet the underlaying needs of

supervision and coordination of multiple and mobile

robots. For that, we have to associate an agent to each

physical robot and model each robot as an agent in the

MAS model.

Among the MAS models we have chosen the

Electronic Institution (Esteva, 2003). Indeed, this

organizational model allows to express coopera-

tion schemes deﬁned by the user with an Orga-

nization Modeling Language such as for instance

M OISE

(H¨ubner et al., 2002), and OMNI (Dignum

et al., 2004). The aim of these services is to constraint

and supervise agent’s actions and interactions in order

to achieve some global goals. We call those explicit

cooperation schemes OS.

To summarize our different ideas, we state to de-

velop a hybrid architecture which takes into account:

the advantages of Reactive and Hierarchical architec-

tures, to obtain more efﬁcient reaction in different

aspects, such as having good level of data process-

ing while minimizing the reaction time, allows co-

ordination and permits hybrid distributed / central-

ized aspect. This architecture is dedicated to multi-

robot systems with a high degree of coordination be-

tween autonomous robots. The main originality of

MAS2CAR is the used coordination method and the

challenge is to implement an organizational model for

robotic agent with all the physical and automatical

constraints to obtain a more powerful multi-robot co-

ordination, and apply it on real robots.

3 MAS2CAR’S GLOBAL MODEL

In our architecture model:

• We focus on nonholonomic homogeneous

robots;

• The environment in which robots evolve is par-

tially known but we also consider the possibility

of encounter unexpected obstacles.

3.1 Overview

Elaborating an innovative architecture to control a

group of coordinated autonomous vehicles in unstruc-

tured environments, have to take into account differ-

ent aspects. That is why our model is composed by

three main layers for every robot (cf. Figure 1):

1. The Physical Layer is composed of multiple sen-

sors/actuators existing on the robot.

2. The Control Layer allows us the “basic” goals

modules such as planning, re-planning, reactive-

mode and the sensors/actuators management.

3. The Coordination Layer is dedicated to more

complex abstract or social goals. Basically, this

level is represented by an agent.

The originality of this architecture is to use Elec-

tronic Institution MAS model to bring cooperation,

coordination and intelligence at both individual and

social levels.

As shown in Figure 1, the Control Layer makes

the link between the Physical Layer and the Coordi-

nation Layer (agent). It manages the sensors and ac-

tuators in order to serve abstract commands for every

actuator and events from every sensor.

For instance, if the Coordination Layer decide

to reach a target, the Control Layer have to exactly

calculate the best trajectory to reach this objective,

taking into account the robot’s structural constraints:

the non-holonomy,avoiding the set points discontinu-

ities, the limitation of the rotational torques, etc. The

robot must avoid also the known obstacles on the path.

We have choosen the Potential Fields method to plan

the robot trajectory, and the Orbital Obstacle Avoid-

ance Algorithm (Adouane, 2009) for unexpected ob-

stacles.

3.2 Properties

3.2.1 Communication

One of the main objects of study in multi-robot sys-

tems research is the communication or interaction be-

A robot set is homogeneous if the capabilities of the

individual robots are identical and heterogeneous otherwise.

MAS2CAR ARCHITECTURE - Multi-agent System to Control and Coordinate teAmworking Robots

453

tween the robots. Three main communication struc-

tures are often used (Werfel and Nagpal, 2006).

• First is communication or interaction via environ-

ment: this occurs when the environment itself is

the communication medium.

• Another typical structure is the interaction via

sensing: this refers to local interactions that oc-

cur between agents as a result of them sensing one

another.

• Last is interaction via communications: this in-

volves explicit communication with other agents,

by either directed or broadcast intentional mes-

sages.

The most appropriate in the MAS environments

is this last one, thanks to its directed and broadcast

intentional messages, in our model we use it with

a communication interface listening on every robots.

Thanks to this, an agent of the Coordination Layer

can connect to its associated Control Layer in two dif-

ferent ways: (i) Locally if the robot has the required

characteristics to embed the agent directly; (ii) Re-

motely through a robot wireless interface.

3.2.2 Abstraction

Every agent connected to the Control Layer’s inter-

face can send and receive messages. The Control

Layer behave as a middleware which receive com-

mands for actuators and send events from sensors.

As an abstract layer for the hardware, this Control

Layer design permits multi-heterogeneous robots, as

the Control Layer can be adapted to different hard-

ware while serving the same middleware.

For these reasons, this architecture allows (i)

Robot-independent Coordination Layer implemen-

tation (ii) platform-independent programming lan-

guages to implement the MAS and ﬁnally (iii) more

powerful and reactive Coordination Layer.

The Control Layer (cf. Figure 1) take basic deci-

sions such as determining a trajectory or avoiding an

unexpected object allowing the Coordination Layer to

focus on more complex tasks or social behaviors.

This paper focus on the Coordination Layer pre-

sented in the next sections.

4 MAS2CAR’S ORGANIZATION

SPECIFICATION

In this part we will describe an Institution-oriented

approach to model our MAS. We will focus on giving

the possibility for agents to reach a targeted point (ob-

jective) according to a partially known environmentin

Figure 1: Architecture of a robot at the individual scope

(Mouad et al., 2009).

a planning-based mode, we also model a possible re-

active mode to face unexpected events.

Figure 2: M OISE

Inst

, a normative Organization Speciﬁca-

tion model, and its different speciﬁcations.

4.1 Structural Speciﬁcation

Deﬁne a role (r) per robot: rRobot{i} with i = {1..n}

and n the total number of robots. All these roles have

a cardinality of 1. By this way one and only one agent

is associated to each robot. In addition of the robot’s

roles, we have deﬁned a role for a Supervisor, rSuper-

visor, which have the duty to manage the others agent

with a global point of view.

Thus our architecture is a distributed architecture,

and the MAS (Coordination Layer of our architecture,

ICINCO 2011 - 8th International Conference on Informatics in Control, Automation and Robotics

454

cf. ﬁgure 1) is mainly composed by the agents repre-

senting an associated agent’s Control Layer and by a

supervisor, in each robot. In consequence we obtain

a high level of coordination and cooperation for our

group of robots due to the connection between super-

visors in each robot.

4.2 Contextual Speciﬁcation

A contextual speciﬁcation can be seen as a recursive

transition-graph where states are called contexts and

set of contexts are called scenes (s). We have one

scene for the supervisor, sSupervisor, and one for

each robot: sRobot{i} (cf. table 1). Theses scenes

includes speciﬁc contexts inﬂuencing the behavior of

the robots:

• Planning mode associated to the initial context

planningMode, used as often as possible by the

robots to compute their trajectories and reach their

goals.

• Reactive mode associated to the context reactive-

Mode, triggered when an unexpected obstacle is

detected in order to avoid it.

Thanks to transitions, we can switch the mode

of each robots. Indeed, the organization is n + 1

different contexts at the same time (n agents and

1 supervisor). At the beginning, we have: sSu-

pervisor/Active and sRobot{i}/planningMode/Active

(the agent i activate the Planning Mode) i = {1..n}.

If due to unexpected obstacle, the supervisor send

the transition AO5 (which means “Avoid Obsta-

cle” into the scene sRobot{5}), the contexts turn to

be sSupervisor/Active, sRobot5/reactiveMode/Active

and sRobot{i}/planningMode with i = {1..n},

i 6= 5.

4.3 Functional Speciﬁcation

Here, we have speciﬁed goals and set of goals (mis-

sions) for the robots and the supervisor (cf. table 1).

The goals are executed in a speciﬁc order according

to three modalities:

• Sequence (→): g

→ g

→ ... → g

p−1

→ g

the

goal g

have to be realized before g

p−1

, ... , g

have to be realized before g

• Parallelism (k): r k {g

, g

, ..., g

}: the goals g

, ... , g

have to be realized in parallel after

realizing r.

• Choice (⋔): r ⋔ {g

, g

, ..., g

} one and only one

i∈[1.. p]

have to be realized after realizing r.

We have three missions:

mSupervisor = gRoot k

{gSupervisor, gCollisionSolver}

The supervisor have to do three set of actions in

parallel: management of the messages and requests

from the robots within gSupervisor, and detection /

resolution of conﬂicts between robots within the goal

gCollisionSolver.

mPlan = gWaitSupervisor →

gComputeTrajectory → gAskForPermission →

gReachTarget

First we execute gWaitForSupervisor (is the super-

visor here and ready?) when done, we execute gCom-

puteTrajectory wherein we ask Control Layer for a

planning in order to reach a targeted point of the en-

vironment.

Then we execute gAskForPermission wherein we

ask supervisor if the computed planning implies con-

ﬂicts with other robots. As a result, we obtain con-

straints to avoid conﬂicts and we modify the planning

to respect these constraints and robot characteristics.

Finally, the goal gReachTarget is executed and we

send messages to the Control Layer in order to move

according to the plan.

This goal run until the objective is reached or un-

til it is interupted by messages coming from sensors

(unexpected obstacle). In this case a transition (AOi

where i is the identiﬁcation of the robot) is sent to

switch the robot into reactive mode.

mReact = gAvoidObstacle →

gReturnOnTrajectory

mReact Is used to manage an unexpected obstacle

detected by sensors. In gAvoidObstacle we move the

robot according to data coming from sensors in order

to avoid the obstacle. As soon as the obstacle is far

enough we run gReturnOnTrajectory wherein we try

to get back to the trajectory planiﬁed before. When it

is done, we can leavethe reactive mode and go back to

the planning mode by sending a transition to change

the context.

4.4 Normative Speciﬁcation

In the normative speciﬁcation (cf. table 1), we have

a Norm for the supervisor NSupervisor, which forces

the agent playing the role rSupervisor when the In-

stitution is in the context sSupervisor/Active to do the

mission mSupervisor described before.

For the n robots, we have two norms:

• N{i}planningMode forces the agent playing the

role rRobot{i} when the Institution is in the

context sRobot{i}/planningMode/Activeto do the

mission mPlan.

• N{i}reactiveMode the same for role rRobot{i}

when the Institution is in the context

MAS2CAR ARCHITECTURE - Multi-agent System to Control and Coordinate teAmworking Robots

455

Table 1: Normative Speciﬁcation glueing all three other speciﬁcations.

Normative Speciﬁcation Contextual Speciﬁcation Structural Speciﬁcation Functional Speciﬁcation

NSupervisor sSupervisor/Active rSupervisor mSupervisor: - Supervisor (recieve plans...).

- Collision Solver (conﬂicts detection/resolution).

N{i}PlanningMode sRobot{i}/PlanningMode/Active rRobot{i} mPlan: - Ask for Permission (from supervisor).

- Compute Trajectory (plan trajectory using

the potential ﬁelds method).

- Wait Supervisor (permission given after the

trajectory analysing).

- Reach Target.

N{i}ReactiveMode sRobot{i}/ReactiveMode/Active rRobot{i} mReact: - Avoid Obstacle.

- Return to Trajectory.

sRobot{i}/reactiveMode/Active to do the mission

mReact.

5 CONCLUSIONS

This paper describes the proposed control architecture

with its three layers, while focusing on the Coordina-

tion Layer and have shown how a multi-agent system

can be helpful to bring coordination and cooperation

into a multiple heterogeneous robots set. To this end,

the key point is twofold:

• Using an Organizational Model (M OISE

Inst

) in

order to describe the structure, goals and contexts

in a normative Multi-Agent System.

• Taking the beneﬁt of U TOPIA framework to han-

dle the organization speciﬁcation (OS) and trans-

late it into a concrete MAS corresponding to the

Coordination Layer throught our goal implemen-

tations executed by the robots.

This centralized / decentralized possibility is a key

characteristic of MAS2CAR architecture as it allows

to face every events while keeping a speciﬁcation of

global goals.

Future works will adress more sophesticated col-

laborativetasks, behaviors and team-work, such as the

hierarchical ﬂeet organization and dynamic changing

environments...

REFERENCES

Adouane, L. (2009). Orbital obstacle avoidance algorithm

for reliable and on-line mobile robot navigation. In9th

Conference on Autonomous Robot Systems and Com-

petitions.

Botti, V., Carrascosa, C., Julian, V., and Soler, J.

(1999). Modelling agents in hard real-time environ-

ments. In Lecture Notes in Computer Science, volume

1847/1999, pages 83–78.

Bruyninckx, H. (2001). Open robot control software: The

orocos project. In Proceedings of the IEEE Interna-

tional Conference on Robotics and Automation (ICRA

2001), volume 3, pages 2523–2528.

Burridge, Rizzi, R., A., Koditschek, and D. (1999). Se-

quential composition of dynamically dexterous robot

behaviors. In International Journal of Robotics Re-

search, volume 18(6), pages 534–555.

Dignum, V., Vazquez-Salceda, J., and Dignum, F. (2004).

Omni: Introducing social structure, norms and on-

tologies into agent organizations. In ProMAS Inter-

national Workshop 2004, New York, USA.

Esteva, M. (2003). Electronic institution: from speciﬁcation

to development. In IIIA Ph.D. Monography, v19.

Fierro, R. and Das, A. (2002). A framework and architec-

ture for multi-robot coordination. In The international

Journal of Robotics Research, volume 21, pages 977–

995.

H¨ubner, J. F., Sichman, J. S., and Boissier, O. (2002).

A model for the structural, functional, and deontic

speciﬁcation of organizations in multiagent systems.

In SBIA’02, number 2507 in LNAI, pages 118–128.

Springer.

Klavins, E., Koditschek, and D. (2000). A formalism for the

composition of concurrent robot behaviors. In IEEE

Int. Conf. on Robotics and Automation, volume 4,

pages 3395–3402.

Lumia, R., Fiala, J., and Wavering, A. (1990). The nasrem

robot control system and testbed. In IEEE Journal of

Robotics and Automation, pages 20–26.

Morrow, J., and Khosla (1997). Manipulation task primi-

tives for composing robot skills. In IEEE Int. Conf.

on Robotics and Automation, volume 14, pages 3354–

3359.

Mouad, M., Adouane, L., Khadraoui, D., and Martinet, P.

(2009). Multi-agents system to control and coordinate

teamworking robots (mas2car). In 7eme Journees Na-

tionales de la Recherche en Robotique JNRR’09.

Muscettola, N., Dorais, G., Fry, C., Levinson, R., and

Plaunt, C. (October 2002). Idea: Planning at the core

of autonomous reactive agents. In Proceedings of the

3rd International NASA Workshop on Planning and

Scheduling for Space.

Parker, L. (1998). Alliance: An architecture for fault toler-

ant multi-robot cooperation. In IEEE Transactions on

Robotics and Automation, volume 14, pages 220–240.

Simmons, R., Singh, S., Hershberger, D., Ramos, J., and

Smith (2000). Coordination of heterogeneous robots

for large-scale assembly. In ISER00, 7th Int. Sympo-

sium on Experimental Robotics, pages 311–320.

Werfel, J. and Nagpal, R. (2006). Extended stigmergy in

collective construction. In IEEE Intelligent Systems,

volume 21, pages 20–28.

ICINCO 2011 - 8th International Conference on Informatics in Control, Automation and Robotics

456