Mobile Robotic JChoc DisSolver

A Distributed Constraints Reasoning Platform for Mobile Multi-robot Problems

Zakarya Erraji

, Mounia Janah

, Imade Benelallam

1,2

and El Houssine Bouyakhf

LIMIARF − FSR, University Mohammed V, Rabat, Morocco

INSEA, Rabat, Morocco

Keywords:

Constraint Programming (CP), Mobile Robots, Multi-robot Systems, Distributed Problem Solving, Agent

Models and Architectures, Distributed Constraints Reasoning, Realistic Use, Constraint Satisfaction Problem

(CSP), Distributed CSP (DisCSP).

Abstract:

Due to the computational complexity (NP-Complete) of Constraint Programming (CP), several researchers

have abandoned its use in robotic research ﬁeld. In the last decade, as many approaches of real-time constraint

handling have been proposed, constraint programming has proved to be a stand-alone technology that can be

used in several research ﬁelds.

Even if mobile robotics is a complex research area, in this paper, we prove that distributed constraint reasoning

techniques can be utilized as a very elegant formalism for multi-robot decision making. First, we describe

dynamic distributed constraint satisfaction formalism, the new platform architecture ”RoboChoc” and specify

how decision making can be controlled in multi-robots environment using dynamic communication protocols.

Then we provide an example application that illustrates how our platform can be used to solve multi-robot

problems using constraint programming techniques.

1 INTRODUCTION

With increasing deployment of applications involv-

ing multiple robots and unmanned air vehicles, there

is growing need for programming platform with re-

alistic use context. Coordination between robots to

solve a combinatorial problem, is one of the most

complex research area in mobile robotics. In the

last decade, as many approaches of real-time con-

straint handling have been proposed, constraint pro-

gramming has proved to be a stand-alone technology

that can be used in several research ﬁelds. This pa-

per presents a new multi-robot platform named Mo-

bile Robotic JChoc DisSolver (RoboChoc), based on

constraint programming to solve multi-robot combi-

natorial problems in dynamically changing environ-

ments. The resolution of such problem is impacted

by the tools that are used. The RoboChoc platform is

based on a powerful constraint solver, named Choco

(Jussien et al., 2008), a multi-agent platform JADE

(JADE, 2013) that insures best management and com-

munication between agents, and a Robot Operation

System (ROS) (Quigley et al., 2009) that provides

libraries and tools to help software developers cre-

ate robot applications. RoboChoc uses a ROS Layer

that beneﬁts from the ROS community contributions

(e.g. navigation (Zaman et al., 2011), localization

(Thomas and Ros, 2005), etc). Since a problem is

modeled using constraint programming techniques,

users can implement the application and solve it eas-

ily.

The paper is organized as follows. Section 2

presents related works. Section 3 shows a brief def-

inition of Distributed and Dynamic Constraint Satis-

faction Problems (DisCSPs and DDisCSPs). Section

4 presents the RoboChoc platform architecture. Sec-

tion 5 describes an example of application. Finally,

Section 6 presents our conclusions and perspectives.

2 RELATED WORKS

Many research focus upon the application of con-

straint programming in the robotic ﬁeld. ThingLab

(Borning, 1981) proposed a software package that al-

lows users to graphically design and simulate a sys-

tem which can use constraints to deﬁne the properties

of the system and guided simulation of circuits, me-

chanical linkages, and other geometries.

304

Erraji, Z., Janah, M., Benelallam, I. and Bouyakhf, E.

Mobile Robotic JChoc DisSolver - A Distributed Constraints Reasoning Platform for Mobile Multi-robot Problems.

DOI: 10.5220/0005833003040310

In Proceedings of the 8th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2016) - Volume 1, pages 304-310

ISBN: 978-989-758-172-4

The research of D. K. Pai (Pai, 1989; Pai, 1991)

describes a new framework for robot programming

using constraint satisfaction techniques. Pai deﬁned

two special classes of CSP variable. Input variables

were used to capture current state and output variables

were deﬁned such that their values can be taken from

the solution and translated to vehicle actuator com-

mands. For each iteration, the previous solutions were

fed into the solver, and then the input variables were

updated. A repair algorithm then ﬁxed the solution

given the changes and the constraints.

Zhang and Mackworth (Mackworth, 1997; Zhang

and Mackworth, 1994; Zhang and Mackworth, 2002)

proposed a constraint-based system for the design of

intelligent and hybrid agents. The hybrid agents are

those which can interact continuously and discretely

with their environments. A controller based on con-

straint satisfaction drives the system toward satisfy-

ing all constraints. During the task, system detects

the dissatisfaction of any constraint, the controller can

initiate a backtrack.

Other contributions were recently proposed. the

researches of Richard S. Stansbury and Arvin Agah

(Stansbury and Agah, 2012) presents a decision mak-

ing framework that help robots to perform the best

decision at any given moment. The selected task

must satisfy all constraints. The framework models

this decision as a Constraint Satisfaction Problems

(CSPs). Where the contribution of Doru Panescu and

Carlos Pascal (Panescu and Pascal, 2014) presents a

multi-robot system planning based on a combination

between a multiagent system and a constraint satis-

faction problem approach. They make some simula-

tion tests with a multi-robot system presented by four

robots to solve an assembly goals. They use in these

simulations the coloured Petri net models, speciﬁcally

developed for a distributed constraint satisfaction al-

gorithm.

To date, no researchers have proposed a con-

straint programming platform to practically imple-

ment multi-robot application. DisCSP has been used

as a formalism for diagnosing coordination failures in

multi-robot systems (Meir et al., 2006). This work

shows that, in general, a trade-off exists between the

computational requirements of the algorithms, and

their diagnosis results. In contrast, we use sophis-

ticated APIs (JADE, ROS and Choco) to model the

ideal coordination relationships between robots. We

present results from experiments conducted in realis-

tic usage conditions. In addition, previous contribu-

tion doesn’t use standard and distributed platform, in

contrast to our work.

3 BACKGROUND

3.1 Distributed Constraint Satisfaction

Problems

Constraint Programming distinguishes between the

description of the constraints involved in a problem

on the one side, and the algorithms and heuristics

used to solve the problem on the other side. Modeling

and solving problems is through a very elegant math-

ematical formalism, called the Constraint Satisfaction

Problems CSPs.

The Distributed Constraint Satisfaction Problem

(DisCSP) is represented by a constraint network

where variables and constraints are distributed among

multiple automated agents.

Deﬁnition: A DisCSP (or a distributed constraint net-

work) has been formalized as a tuple(A, X, D, C, ψ),

where:

• A = {A

, ..., A

} is a set of p agents.

• X = {x

, ..., x

} is a set of n variables such that

each variable x

is controlled by one agent in A.

• D = {D(x

), ..., D(x

)} is a set of current do-

mains, where D(x

) is a ﬁnite set of possible

values for variable x

• C = {c

, ..., c

} is a set of m constraints that

specify the combinations of values allowed for

the variables they involve. We note that the

constraints are distributed among the automated

agents. Hence, constraints divide into two broad

classes: inter-agent and intra-agent.

• ψ : X 7−→ A is a function that maps each variable

to its agent.

A solution to a DisCSP is an assignment of a value

from its domain to every variable of the distributed

constraint network, in such a way that everyconstraint

is satisﬁed. Solutions to DisCSPs can be found by

searching through the possible assignments of values

to variables such as ABT algorithm (Yokoo et al.,

1992).

3.2 Dynamic and Distributed

Constraint Satisfaction Problems

Many hard practical multi-robot problems can be seen

as DisCSPs. Most Distributed Reasoning platform as-

sume that problems are static. This is a limitation for

Mobile Robotic JChoc DisSolver - A Distributed Constraints Reasoning Platform for Mobile Multi-robot Problems

305

dynamic problems that change over time and espe-

cially in dynamically changed environments. For ex-

ample, any robot belonging to a set of robots that ex-

plore the moon in a cooperative mission can be lost if

hit by a meteor. Thus the problem will change. Hence

in a dynamic environment a DisCSP may change over

time, these changes could be due to addition/dele-

tion of variables, constraints, or agents. The Dis-

tributed and Dynamic Constraint Satisfaction Prob-

lems (DDisCSPs) can be described as a tuple (A, X,

D, C, δ) where:

• A, X, D and C remain as described in DisCSPs.

• δ is the function that introduce changes.

Many DDisCSPs approaches (e.i : DynABT

(Omomowo et al., 2008)) are proposed to solve such

problem, and can be easily implemented in RoboChoc

platform.

4 PLATFORM ARCHITECTURE

4.1 RoboChoc Description

RoboChoc is a JADE-based platform. This platform

is a distributed constraint multi-robot system, pro-

posed for mobile robotic applications. It can also

be used to analyze and test algorithms proposed by

constraints programming community. This platform

is presented in the form of programming environ-

ment (API) and applications to help different types

of robotic users. Hence, RoboChoc can be easily

adopted by two main actors:

• Developers to design and develop multi-robot ap-

plications.

• Non-expert user can interact directly with appli-

cations based on distributed constraint program-

ming.

This proposed platform has several advantages:

• A multi-robot problem modeled as distributed

constraint problem, can be easily addressed and

solved in a realistic environment by non-expert

users;

• The performance of the proposed protocols (e.g.

ABT, AFC, Adopt, etc) can be actually tested and

proved in a realistic robot cordination, using com-

munication channel (i.e. WLAN WPAN WMAN

WWAN);

• It offers a modular software architecture which

accepts extensions easily (e.g. security, conﬁden-

tiality, cryptography, etc);

• Thanks to the extensibility of JADE communi-

cation model (JADE, 2013), RoboChoc allows

the development of multiagent systems and appli-

cations consistent with Foundation for Intelligent

Physical Agents (FIPA)

standards and speciﬁca-

tions;

• Thanks to the the robustness of Choco plat-

form (Jussien et al., 2008), complex agent (i.e.

multiple variables per agent) can easily address

and solve its local sub-problem and use solutions

as a compiled domain.

• Thanks to the the Robot Operation System

ROS (Quigley et al., 2009), The distributed nature

of ROS also fosters a large community of user-

contributed packages that add a lot of value on top

of the core ROS system.

This platform consists of several modules pre-

sented as services. The main constraint programming

services offered are based Distributed Constraint Rea-

soning Protocols (DCRP) and Choco Solver (CS).

Choco is a platform for research in centralized con-

straint programming and combinatorial optimization.

This choice of Choco enabled us to beneﬁt from the

modules already implemented in it. In the next sec-

tion, we will study the different elements of Robo-

Choc platform.

4.2 RoboChoc Architecture

RoboChoc architecture allows FIPA speciﬁcations. It

is implemented in JAVA and provides classes that im-

plement and inherit from JADE and Choco platforms

to deﬁne the behavior of speciﬁc agents. Figure 1

represents the main RoboChoc architectural elements.

This platform has ﬁve main modules.

• Distributed Constraint Reasoning Protocols unit:

provides distributed constraints protocols as ser-

vice. This element deﬁnes new types of messages

and implements the behavior of the agent when

receiving and sending a speciﬁc type of informa-

tion (e.g. ABT, AFC, Adopt, etc...);

• Constraint Solver Unit: provides the ability to ad-

dress and resolve local CSP sub-problem by using

the Choco Solver;

• Services Management Unit: manages services in

the platform. It’s based on the Director Facilitator

(DF) agent of JADE;

• Communication Management Unit: manages the

communication in the platform. It’s based on the

Agent Communication Channel (ACC) of JADE;

http://www.ﬁpa.org/

ICAART 2016 - 8th International Conference on Agents and Artiﬁcial Intelligence

306

• Authority Unit: oversees the registration of

robots, their authentication, their access and the

use of the system.

• ROS Layer Unit : provides a set of tools to apply

a decision or to read the robot situation (e.g. scan

sensor state, moving the robot, etc.).

These six modules are activated at each time the

platform is started.

Figure 1: RoboChoc Architecture.

The JADE agent is also a key player in our plat-

form. Thanks to JADE an Agent Identiﬁer (AID)

identiﬁes an agent uniquely.

RoboChoc uses extensively a snifﬁng tool for de-

bugging, or simply documenting conversations be-

tween robots. The sniffer subscribes to Authority

Unit to be notiﬁed of all platform events and of all

message exchanges between a set of speciﬁed robots.

When the user decides to monitor a robot or a group

of robots, every message directed to, or coming from,

that robot/group is tracked and displayed in the sniffer

GUI. The user can select and view the details of every

individual message, save the message or serialize an

entire conversation as a binary ﬁle.

The platform can be used with all robots that use

ROS as an operating system, and no additional con-

ﬁguration is needed. The user has to choose the ap-

propriate robots for its application.

5 EXAMPLE APPLICATION

5.1 Description of 3D N

Queens

Problem

The n-queens problem is a classical combinatorial

problem that can be formalized and solved by con-

straint satisfaction problem. In the n-queens problem,

the goal is to put n queens on an n×n chessboard so

that none of them is able to attack (capture) any other.

Two queens attack each other if they are located on

the same row, column, or diagonal on the chessboard.

This problem is called a constraint satisfaction prob-

lem because the purpose is to ﬁnd a conﬁguration that

satisﬁes the given conditions (constraints).

Three Dimensional Queens Problems is an exten-

sion of the well known n-queens problem in 3D di-

mensional space. The goal in this problem is to place

queens in an N × N × N cube such that none of

them is able to attack any other. A queen can attack

another if they exist in the same row, column, or di-

agonal formed by the division of the tree dimensional

space. We mention that the space is divided into n

position which the n

queens will take place.

This problem was treated, modeled and solved in

the following paper, using linear programing: Three

Dimensional Queens Problems (Allison et al., 1989).

In this research they found that there is no solution for

the n less than 11, n=12, n=14. They found exactly

for n=11, 528 solutions using an other formalism far

from constraint programming.

In our work, we propose for the ﬁrst time, a DisC-

SPs modeling for the same problem. The DisCSP that

model the problem is formalized as a tuple (X, D, C,

A, ψ) where:

• X = { X

1,1

, ..., X

n,n

} is a set of n× n variables.

• D = {D

1,1

={1..n}, ..., D

n,n

={1..n}} is a set of do-

mains, where D

i, j

is a ﬁnite set of possible values

for the variable X

i, j

• C = {

C1={(X

i, j1

6= X

i, j2

)and(



i, j1

− X

i, j2



| j1 − j2|) / (i, j1, j2) ∈ [1, 4]} where X

i, j1

and X

i, j2

designate queens existing in the same

row.

C2={(X

i1, j

6= X

i2, j

)and(



i1, j

− X

i2, j



6= |i1− i2|)

/ (i1, i2, j) ∈ [1, 4]} where X

i1, j

and X

i2, j

design

queens existing in the same column.

C3={if i1 6= i2 and j1 6= j2 and |i1− i2| 6=

| j1 − j2| then X

i1, j1

6= X

i2, j2

/ (i1, i2, j1, j2) ∈

[1, 4]}

} is the set of constraints.

• A = { A

1,1

, ..., A

n,n

} is a set of n× n agents.

• ψ is the function that assign the variable X

i, j

the agent A

i, j

In this modeling, each queen Q

i, j

is represented

by a variable X

i, j

Mobile Robotic JChoc DisSolver - A Distributed Constraints Reasoning Platform for Mobile Multi-robot Problems

307

5.2 Using RoboChoc to Solve the 3D N

Queens Problem

The problem can be solved by using RoboChoc.

Hence, each agent is presented as a robot. We use

XML ﬁles to describe the sub-problems for each

robot. The ﬁgure 2 shows an example of the XML ﬁle

used to describe the sub-problem for the robot named

Robot3.1.

Each variable has a unique ID, which is the ID

of its owner robot. This is necessary when deﬁning

constraints (scope of constraints). For constraints, we

used two types: TKC for Totally Known Constraint

and PKC for Partially Known Constraint. Constraints

can be deﬁned in extension or as a Boolean function.

Different types of constraints are predeﬁned: equal

to eq(V

, V

), different from ne(V

, V

), greater than or

equal ge(V

, V

), greater than gt(V

), etc. In this

sub-problem the constraints presented in the DisCSPs

modeling are deﬁned by the predicate p1. In the tag

topics we indicate the topics to be created and used by

the ROS Layer Unit. these topics will be used to con-

trol the robot motion in this application. After deﬁn-

ing our sub-problem we can conﬁgure our solver.

The problem can be solved using the ABT algo-

rithm assuming that no perturbation will occur during

the resolution, because we will use the Modular Open

Robots Simulation Engine(Morse) ( (Echeverriaet al.,

2011)) with ROS as a middle ware. The adequate type

of robot that can represent queens for this application

is the drone Quadrotor

Dynamic.

We solved the modeled problem with the Con-

straint Solver Unit in the platform, and we have found

exactly the same results presented in the research of

(Allison et al., 1989). To simplify the problem in this

application, we will use just n=4 as the ﬁgure 5 shows.

For the reason that there is not any solution for n=4,

the robots who can’t belonging to the solution will be

taken from the operational scene. Thus only robots

that will satisfy all constraints will ﬂy to take their

positions. We can test the functioning of the platform

in a physically distributed environment. So we chose

machines that simulate the different robot of the prob-

lem, and ﬁled each sub-problem in a machine, before

launching it.

Figure 3 shows how the master launches its com-

munication interface listening on the network. We be-

gin by instantiating the AgentsContainer object (line

7), This class models the distributed problem when

RoboChoc is used to solve a problem in a real dis-

tributed environment. All information on distributed

problem is encapsulated in this object (identities of

agents, inter-agent constraints, protocol, etc.). Then,

we deﬁne the type of master (line 8) (ABT in this

1 <?xml v ersion =” 1.0 ” encoding =”UTF−8” ?>

2

3

4 <domains nbDomains=”1 ”>

5 <domain name=”D1” nbValues=”4”>1 . . 4</

domain>

6 </ domains>

7 <v ar i a b l e s nbVar iables =”1 ”>

8 <v a r i a bl e name=”V3. 1 ” domain=”D1” />

9 </ v ar i a b l e s>

10 <t op ic s nbTopics=”1”>

11 <t op i c name=” / drone3 . 1 / waypoint3 .1 ” />

12 </ to p i c s>

13

14

15 <param eters>i nt X in t Y i nt i i nt j</

param eters>

16 <ex p r e ss i o n>

17 <f u n c t i on a l>and ( neq (X, Y) , neq ( abs ( minus (X

, Y) ) , abs ( minus ( i−j ) ) ) )</ f un c t i o na l>

18 </ ex p re ss io n>

19

20 </ pr e d i c a t e s>

21 <a g e nt s n ei g hb ou r s>

22 <a g en t s p a r e nt>

23 <ag e n t name=” Robot1 .1 ”>

24 <c o ns tr a in t s n bC on s t r ai n ts =”1”>

25 <c on s tr a in t model=”TKC” name=”C5”

r e f e re n c e=”p1” scope=”V1.1 V3

.1 1 3”>

26 <pa r amete r s>V1.1 V3.1 1 3</

param eters>

27 </ c o ns t r ai nt>

28 </ c o ns t r ai nt s>

29 </ a g ent>

30 <ag e n t name=” Robot2 .1 ”>

31 <c o ns tr a in t s n bC on s t r ai n ts =”1”>

32 <c on s tr a in t model=”TKC” name=”C5”

r e f e re n c e=”p1” scope=”V2.1 V3

.1 2 3”>

33 <pa r amete r s>V2.1 V3.1 2 3</

param eters>

34 </ c o ns t r ai nt>

35 </ c o ns t r ai nt s>

36 </ a g ent>

37 <ag e n t name=” Robot1 .3 ”>

38 <c o ns tr a in t s n bC on s t r ai n ts =”1”>

39 <c on s tr a in t model=”TKC” name=”C5”

r e f e re n c e=” neq ” scope=”V1.3

V3.1 ”>

40 <pa r amete r s>V1.3 V3.1</

param eters>

41 </ c o ns t r ai nt>

42 </ c o ns t r ai nt s>

43 </ a g ent>

44 <ag e n t name=” Robot2 .2 ”>

45 <c o ns tr a in t s n bC on s t r ai n ts =”1”>

46 <c on s tr a in t model=”TKC” name=”C5”

r e f e re n c e=” neq ” scope=”V2.2

V3.1 ”>

47 <pa r amete r s>V2.2 V3.1</

param eters>

48 </ c o ns t r ai nt>

49 </ c o ns t r ai nt s>

50 </ a g ent>

51 </ a g en ts p a re nt>

52 <a g e n t s c hi l d r e n>

53 <ag e n t name=” Robot4 .1 ” v ar i ab l e=”V3. 1 ” /

54 <ag e n t name=” Robot3 .2 ” v ar i ab l e=”V3. 1 ” /

55 <ag e n t name=” Robot3 .3 ” v ar i ab l e=”V3. 1 ” /

56 <ag e n t name=” Robot3 .4 ” v ar i ab l e=”V3. 1 ” /

57 <ag e n t name=” Robot4 .2 ” v ar i ab l e=”V3. 1 ” /

58 </ a ge nt s c hi l d r e n>

59 </ a ge n t s n e i g hb o ur s>

60

Figure 2: Example of a sub-problem for the robot3.1.

case). Finally, we trigger the container and we launch

the master (lines 10).

ICAART 2016 - 8th International Conference on Agents and Artiﬁcial Intelligence

308

1 import JChoc . DisSo l ver ;

3 p u bli c c l a ss Master

4 {

5 publ ic s t at ic void main ( S t r i n g [ ] arg s )

6 {

7 Agent s C o ntai n er m a inCon s t ainer = new

Agent s C o ntai n er ( ) ;

8 main C o nstain e r . setAgentType ( ”MasterABT ” ) ;

9 main C o nstain e r . addAgent ( ”MASTER” , f a ls e ) ;

10 main C o nstain e r . run ( ) ;

11 }

Figure 3: How the master launches its communication in-

terface.

1 package jchoc . run ;

2 import jchoc . t o ol s . Ag e ntsCont ainer ;

4 p u bli c c l a ss RunDrone

5 {

6 publ ic s t at ic void main ( S t r i n g [ ] arg s ) {

8 Agent s C o ntai n er a g e n tC on t a i ne r = new

Agent s C o ntai n er ( ) ;

9 a ge nt C o n ta i n e r . setAgentType ( ”AgentABT” ) ;

10 a ge n t C o n ta i n e r . addAgent ( ” Robot3 .1 ” , ”Robot3

. 1 . xml” , true ) ;

11 a ge n t C o n ta i n e r . s e tMainC o ntain e r ( ”

192.16 8 .1.14 ” ) ;

12 a ge n t C o n ta i n e r . run ( ) ;

13 }

14 }

Figure 4: Run drone.

Figures 4 shows how to launch robots as agents.

We start with instantiate the AgentsContainer object

(line 8), followed by the agent and distributed sub-

problem declaration which speciﬁes the resolution al-

gorithm to be used (line 9-10). Next, the declara-

tion of the container containing the master with its

IP address (line 11). Eventually, we launch the agent

(line12).

The master waits for the conﬁrmation of creation

all agents before ordering the start of the search.

Thus, the problem can be solved using a speciﬁed im-

plemented protocol (ABT for this example). Figures

5 and 6 show the initial and ﬁnal state of resolution

of the problem. Between these two states, the solving

phase was performed to satisfy all constraints.

Figures 7 shows the exchanged messages in the

resolution phase sniffed by the Sniffer Agent in the

platform. ABT algorithm is executed autonomously

by each robot. Robots do not have to wait for deci-

sions of others but they are subject to a total(priority)

order. Each robot tries to ﬁnd an assignment satisfy-

ing the constraints with what is currently known from

higher priority neighbors. When an robot assigns a

solution to its local problem, the selected value is sent

to lower priority neighbors. When no solution is pos-

sible for a local problem, the inconsistency is reported

to higher robots in the form of a nogood. ABT com-

putes a solution (or detects that no solution exists) in

a ﬁnite time. The total ordering on robots is static.

Figure 5: Initial state.

Figure 6: Final state.

6 CONCLUSIONS

The goal of this work was to propose a Distributed

Constraints Reasoning (DCR) platform, which can be

easily used to solve robotic application in a realistic

use.RoboChoc platform presented in this paper has

been designed to solve any multi-robot problems de-

Mobile Robotic JChoc DisSolver - A Distributed Constraints Reasoning Platform for Mobile Multi-robot Problems

309

Figure 7: Sniffed messages in the solving phase.

signed as a DisCSP and to support security and

cryptography extensions (thanks to JADE API).

In this work we have modeled the 3D N

queens

problems as a DisCSP problem. We have used the

MORSE Simulator to run drone-robots, where each

queen is presented by a drone. Each drone performs

as an ABT agent that applies the decision made by

the algorithm or reads his actual situation using the

ROS Layer Unit, which is independent of the solving

protocol. Users can contribute in the ROS Layer Unit

by adding new ROS applications to simplify the use

of new destined robotic task.

Future works are focusing on enhancing the plat-

form by the implementation of other necessary API

in ROS layer, and by diagnosing and proposing new

techniques for coordination failures between mobile

robots.

REFERENCES

Allison, L., Yee, C., and McGaughey, M. (1989). Three-

dimensional queens problems. Monash University,

Department of Computer Science.

Borning, A. (1981). The programming language aspects of

thinglab, a constraint-oriented simulation laboratory.

volume 3, pages 353–387. ACM.

Echeverria, G., Lassabe, N., Degroote, A., and Lemaignan,

S. (2011). Modular openrobots simulation engine:

Morse. In Proceedings of the IEEE ICRA.

JADE (2013). Java agent developpement framework. In

URL http://jade.tilab.com/.

Jussien, N., Rochart, G., and Lorcal, X. (2008). Choco:

an open source java constraint programming library.

In CPAIOR’08 Workshop on Open-Source Software

for Integer and Contraint Programming(OSSICP’08).

France, Paris.

Mackworth, A. K. (1997). Constraint-based design of em-

bedded intelligent systems. volume 2, pages 83–86.

Springer.

Meir, K., Gal, A. K., Amnon, M., and Yehuda, E. (2006).

Diagnosis of multi-robot coordination failures using

distributed csp algorithms. In American Association

for Artiﬁcial Intelligence, 970-975.

Omomowo, B., Arana, I., and Ahriz, H. (2008). Dyn-

abt: Dynamic asynchronous backtracking for dynamic

discsps. In Artiﬁcial Intelligence: Methodology, Sys-

tems, and Applications, pages 285–296. Springer.

Pai, D. K. (1989). Programming parallel distributed con-

trol for complex systems. In Intelligent Control,

1989. Proceedings., IEEE International Symposium

on, pages 426–432.

Pai, D. K. (1991). Least constraint: A framework for the

control of complex mechanical systems. In American

Control Conference, 1991, pages 1615–1621.

Panescu, D. and Pascal, C. (2014). A constraint satisfaction

approach for planning of multi-robot systems. In Sys-

tem Theory, Control and Computing (ICSTCC), 2014

18th International Conference, pages 157–162.

Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T.,

Leibs, J., Wheeler, R., and Ng, A. Y. (2009). Ros: an

open-source robot operating system. In ICRA work-

shop on open source software, volume 3, page 5.

Stansbury, R. S. and Agah, A. (2012). A robot deci-

sion making framework using constraint program-

ming. volume 38, pages 67–83. Springer.

Thomas, F. and Ros, L. (2005). Revisiting trilateration for

robot localization. volume 21, pages 93–101. IEEE.

Yokoo, M., Durfee, E., Ishida, T., and Kuwabara, K. (1992).

Distributed constraint satisfaction for formalizing dis-

tributed problem solving. In International Conference

on Distributed Computing Systems, 614-621.

Zaman, S., Slany, W., and Steinbauer, G. (2011). Ros-based

mapping, localization and autonomous navigation us-

ing a pioneer 3-dx robot and their relevant issues. In

Electronics, Communications and Photonics Confer-

ence (SIECPC), 2011 Saudi International, pages 1–5.

Zhang, Y. and Mackworth, A. K. (1994). Speciﬁcation and

veriﬁcation of constraint-based dynamic systems. In

Principles and Practice of Constraint Programming,

pages 229–242.

Zhang, Y. and Mackworth, A. K. (2002). A constraint-based

robotic soccer team. volume 7, pages 7–28. Springer.

ICAART 2016 - 8th International Conference on Agents and Artiﬁcial Intelligence

310