CA1 Report

Decentralized Control of E-Pucks

Mohamed Isa Bin Mohamed Nasser

U076183A

with help from

Mr. Mohammad Karimadini

[Abstract: This report presents the progress of the FYP project on decentralized control of E-Puck robots.
Modeling of environment, assessment of simulators, derivation of algorithms, development of a map editor
for the ASEBA simulator and ASEBA scripts are among the issues covered.]
 DECENTRALIZED CONTROL OF MULTIPLE E-PUCK ROBOTS
1 . I N TR O D U C TI O N

This project presents us with a scenario and demands a solution with decentralized control of the
robots. This project is useful in two ways. Firstly, it allows conceptual exploration in algorithms in
achieving decentralized control of wheeled robots with a typical set of sensors. Secondly, it lets us
contribute to this popular commercial robot which is often used in swarm robot research.
1 . 1 T HE S C E N A R I O

N robots will be within an environment made up of rooms and doors. They will search the rooms
for fire. When Fire is detected by any of the robots, M robots (where M<N) will be required to
travel to the room where fire has been detected.

There is no central control to coordinate these movements. It is important to distinguish this from
achieving the task using parallel processing of a solution for the global task. Each robot only
supervises execution of local tasks without the knowledge of the global task. The fusion of this local
supervision accomplishes the desired global control.
2 M O D E L L I N G T HE E N V I R O N M E N T

Although the E-Puck is capable of relative localization, the accumulated odometric error is
inescapable unless they utilize landmarks from the environment. Even then, navigation on the full
2d plane is not easily realizable since landmark based localization will require the robot to focus its
camera on the landmark itself.

This slows movement since the robot will periodically have to update its pose by focusing on the
door. This also increases overhead since the robot has to calculate the azimuth of the landmark
after moving a distance. The resolution of the CMOS camera on the E-Puck is 640 by 480 pixels and
it has low fidelity. Since the camera resolution is a factor that determines the amount of error in the
landmark-based localization, such an approach will not work well.

To tackle this localization problem, I reduce the dimension of the environment by modelling it as
directional weighted graphs. This reduces it to a different 2d problem with one dimension being
continuous and another discrete.

A vertex represents a room in the

environment while the accessibility of the
door determines the direction of the edges.
This is clearly illustrated in figure 2.1. The
semicircle in the figure denotes the footprint
of the swinging area of the door. Hence these
doors are single way doors.

2.1 Conditional Cases

In figure 2.2 we model conditional cases in

accessibility. In this case the blue edges
denote edges that can’t be used
Figure 2.1 Modeling of the environment
unconditionally. Only when at least one
robot is present in each of the two nodes linked by the double lines can these edges be used. Figure
2.3 illustrates the edges being available when the condition is met. The logic behind this condition
2
in this case is that the double door is too heavy for any one robot to turn. Therefore they need to
position themselves to push simultaneously to acquire access.

Figure 2.3 Modeling of the environment conditional

Figure 2.2 Modeling of the environment conditional
cases after conditions are met
cases

We will not deal with conditional cases in our solution consequently since it is not necessary in
demonstrating decentralize control. Furthermore, the path planning algorithms are far too
complex to be implemented on the dsPIC32F6014A microcontroller.

2.2 Vertices as Doors

Although we previously stated that vertices

should represent rooms, it is not a
generalization since rooms can contain
multiple doors. Doors should be the actual
vertices. These doors are grouped as members
of rooms. (Figure 2.4)

2.3 Weighting the Edges

The weight of an edge is proportional to the

Figure 2.4 Vertices should be doors
distance between the vertices or doors linked
by the edge. This is of course the wall distance.
Since moving from one door to another has two
routes namely the left or the right route, an
edge connecting to doors automatically holds
two values. (Figure 2.5)

2.4 Weighting the Edges

Since “outside” is in full 2D space, we need to

initialize the position of the robot before they
enter the environment to define their state.
(Figure 2.5)

Figure 2.5 Edges are Wall length

3
Once they enter the rooms their position will no longer need these initial values to define their
state. (Figure 2.6)

Figure 2.6 “Outside” state require initial conditions Figure 2.7 No initial condition required once in in the vertices

2.5 Advantages of Model

This model carries many advantages. A wall following algorithm can be used to traverse along the
edges of the graph since they are wall to wall. Detection of doors from anywhere in the room is
simplified to simply detection of doors from side of the wall. This is simpler since the door is same
in size and therefore a fixed visual pattern is expected when approaching the door from a side of
the wall.

Also using graph which is a fundamental data structure is useful due to the algorithms already
developed for use.
3 . S I M U L A TI N G T H E E N V I R O N M E N T A N D A L G O R I T HM S

3.1 Available Simulators

3.1.1 Player/Stage - http://playerstage.sourceforge.net/

Player/Stage is a popular open source 2D simulator running on Linux. It’s computationally light
and is able to conduct large swarm robots simulation. Player is a server to control robots and it
supports E-Puck. In short, it requires a driver (which is written by users) to support the robot and
its sensor and actuators so that the programming can be done on the PC.

The obvious downside to this is that we don’t actually program directly into the E-Puck. However
one advantage is the ability to add virtual sensors and environments by using Stage. Stage is a
special driver which “tricks” Player into treating the simulation as real robots and environment.
Since we can run both Stage and real E-Pucks together, the possibilities in the usage of the E-Puck
are opened up.

It is however hard to install (many dependencies that has to be manually downloaded and added)
and it is not use friendly with no GUI. Everything has to be done via the terminal.

3.1.2 Webot - http://www.cyberbotics.com/

Webot is impressive commercial simulator software which supports E-Puck. It controls the E-Puck
via drivers and the robots are programmed in the C language. It is very realistic with accurate
4
simulation of the CMOS camera. However it comes in a 30-days trial version with expensive
licenses making it not ideal for research given the current development on alternatives.

3.1.3 ASEBA - http://mobots.epfl.ch/aseba.html

ASEBA is an open source 3D simulator running on ENKI simulator. It is developed by graduate

students in EPFL where the E-Puck itself was created.

It is a very user friendly simulator that uses a simple event-based scripting language for rapid
prototyping. It is able to program multiple E-Pucks separately and running them asynchronously.
One large downside however is that there isn’t any means to acquire global position of the E-Pucks.
Since it supports the accelerometer, camera and proximity sensors only, there isn’t any means for
localization either.

I have attempted to compile the source code to make modification to the simulator. However I
haven’t been successful. It uses Nokia QT libraries which itself has bugs in relative paths when
installed. I have fixed this by rebuilding QT using its source with static paths however compilation
of ASEBA is still not successful using the Microsoft Visual Studio 2008 compiler.

I have chosen to use ASEBA for simulation due to the ease in creating the environment, checking
the sensor values for debugging, the camera plug-in to check the camera view and simply the ease
in creating the algorithms.

3.2 Components of ASEBA

3.2.1 asebaplayground.exe

This is the renderer for the environment as well as holding all the dynamics of the E-Puck. It opens
an XML file with .playground extension which contains information of a few objects which is not
documented yet. I will therefore cover it briefly in this section.

Figure 3.1 ASEBA Playground

3.2.1.1 Documenting *.playground Map files

Description

Color tag is used to define colours used in RGB to assign it to objects.

5
Parameters

<color name="<ID for use to assign objects this colour As String>"

r="<value of Red Component float>"

g="<value of Red Component float>" "

b="<value of Red Component float>" " />

Description

World tag defined the dimension/size of the environment

Parameters

<world w="<width of environment float>"

h="<height of environment float>"

color="<ID of color tag with desired colour for this world >"/>

Description

Wall tag used to create a single cuboid which is rooted to the ground or a wall

Parameters

<wall x="<this is the center of the x coordinate of the wall. float>"

y="<this is the center of the ycoordinate of the wall. float>"

l1="<absolute width of the wall in the x axis float>"

l2="<absolute length of the wall in y axis float>"

h="<absolute height of the wall in z axis float>" color="<ID of color tag with desired colour
>" />

Description

Door tag used to create a door that moves when the corresponding activation tag which
points to it using its name is activated (see the activation tag)

Parameters

<door closedX="<center of x component of the closed door position>"

closedY=" <center of y component of the closed door position>"

openedX=" <center of x component of the opened door position>"

openedY="<center of y component of the opened door position>"

l1="< absolute width of the door in the x axis float>"

l2="<absolute length of the wall in the y axis float>"

6
 h="<absolute height of the wall in the z axis float>"

moveDuration = "<how long it takes for the door to move typically 3 Int>"

name="<ID for activation tag to open door String>"

color="<ID of color tag with desired colour String>"/>

Description

Activation tag is used to define the activation beacon which is a cuboid with fixed height
rooted to the ground

Parameters

<activation x=="<x component of center of cuboid float>"

y="<y component of center of cuboid float>"

l1="<width of cuboid in x-axis float>"

l2="<length of cuboid in y-axis float>"

area="< ID of the area tag which define the rectangular area around the beacon which,
when stepped on, will open up the door string"

door="<ID of the door that will be opened string> " />

Description

Area tag defines the trapezoidal area relative to an activation tag beacon coordinate which,
when stepped on, will open up the corresponding door

Parameters

<area name="<ID to be used by activation tag string>">

<point x3="<float>" y3="<float>" />

<point x4="< float >" y4="< float >" /> X1,Y1 X2,Y2

<point x2="< float >" y2="< float >" />

<point x1="< float >" y1="< float >" /> X3,Y3 X4,Y4
</area>
Figure 3.2 Area parameter
Description

E-Puck tag defines where to place 1 E-Puck. Multiple tags means multiple E-Pucks

Parameters

<e-puck x="<center of e-puck x-axis float>"

y="<center of e-puck y-axis float>" />

3.2.2 Visual Map Creator for ASEBA

7
Creating environments manually using the tags is laborious. A Visual Map Creator for this
simulator is not available. Creating one will be very useful especially for swarm simulations and for
testing in large environments.

Using an open source VB.net drawing program sample, I have created a Visual Map creator for E-
Puck. The file extension of this program which can be “opened” and edited is *.pic. When saving a
*.pic file, a *.playground file will be generated automatically with the same filename as the *.pic file.

Rectangles are the rooms itself with 4 walls

automatically made. (Figure 3.3)

Lines are doors. One will have to draw it over

one of the 4 sides of the rectangles which are the
walls of the rooms. That side of the wall will be
“cleared” and opening for the door. (Figure 3.3)

If there is 1 door over 2 walls, both walls will be

“cleared” and opening for the door. And there
won’t be a duplicate of doors. The program will
prevent this. (Figure 3.3 and Figure 3.4)

To insert E-Pucks, simply draw ellipses to where

Figure 3.3 Visual Map Creator for ASEBA E-Pucks will be placed.

Figure 3.4 Map created by Visual Map creator

After the desired map is drawn, save as *.pic and a .playground file will be automatically created.
Open the file in asebaplayground.exe. The map would be made. (Figure 3.4)

3.2.2.1 Further Developments

1. Make *.playground file itself editable

2. Create weighted directed graph of the environment and save it to a file.

8
3.3 asebastudio.exe

ASEBA studio is an IDE to program the E-Pucks. ASEBA studio connects to either real E-Pucks
through a switch program or to playground if it’s open first. It is capable of programming E-Pucks
individually. (Figure 3.5)

Figure 3.5 ASEBA studio

3.3.1 Traversing Algorithm Written

I have written an algorithm that can traverse through the map in the form of the graph.

This algorithm consists of:

1. Wall Following (right and left)

2. Door Detection using Camera
3. Skip Door
4. Go through Door

Once a path planning algorithm is made, the E-Puck can follow a path by wall following the edges,
detect a vertex by detecting the door and choosing vertices to travel to by wall climbing left or right
and choosing whether to skip door or go through it.

The input required to move through the graph is therefore simply <left wall climb or right wall
climb> and <go through door or skip door> for every vertex/door detected.

3.3.2 Code Written

Notice openDoor and selector (right or left) can be arrays instead of single variables. It will then
follow a path defined by the array.
9
var i
var cornerCount = 0
var totalturn = 0
var gostraight
var selector = 1 #right wall follow is 1. Left wall follow is 0. this can be fed an array
var follow_weightleft[8] = -10,-10,-5,0,0,5,10,10
var follow_weightright[8] = 10,10,5,0,0,-5,-10,-10
var temp_prox[8]
var j
var y=0
var switch1=0
var errorThres = 0
var openDoor = #1 for open 0 for skipping door. this can be fed an array
var counter1 = 0

######################## Door Entering and skipping #####################

sub wall_detected # run when wall is detected
if openDoor==1 then
if selector ==1 then
leftSpeed = 100
rightSpeed = -100
else
leftSpeed = -100
rightSpeed = 100
end
if (prox[0]<1000 or prox[7]<1000) and errorThres < 70 then
switch1 = 1
else
switch1 = 0
y=0
errorThres = 0
end
else

switch1 = 2
if counter1 >= 780 then
y=0
counter1=0
switch1 = 0
else
counter1 = counter1 + 1
leftSpeed = 100
rightSpeed = 100
end
end
################## End of Door Entering and skipping ####################

onevent ir_sensors
if switch1==1 then
if selector ==1 then
leftSpeed = 100
rightSpeed = -100
else
leftSpeed = -100
rightSpeed = 100
end
errorThres = errorThres + 1
callsub wall_detected
else
if switch1==2 then
counter1 = counter1 + 1
callsub wall_detected

else

10
######################## Wall follow #############################

for i in 0:7 do
temp_prox[i] = prox[i]
end

if selector == 1 then #follow right

j=0
for i in 0:7 do
if temp_prox[i]>50 then j=j+1 end

end
if j==0 then
gostraight=1
else
gostraight = 0
follow_weightleft[0]=-10 #set weights to follow right
follow_weightleft[7]=-10
follow_weightright[0]=10
follow_weightright[7]=10
if temp_prox[2]>300 then
temp_prox[1] = temp_prox[1]-200*k
temp_prox[2] = temp_prox[2]-600*k
temp_prox[3] = temp_prox[3]-100*k
end
if temp_prox[2]>500 then
temp_prox[1] = temp_prox[1]-50*k
temp_prox[2] = temp_prox[2]-150*k
temp_prox[3] = temp_prox[3]-25*k
end
end
else #follow left
j=0
for i in 0:7 do
if temp_prox[i]>50 then j=j+1 end

end
if j==0 then
gostraight=1
else
gostraight = 0
follow_weightleft[0]=10 #set weights to follow left
follow_weightleft[7]=10
follow_weightright[0]=-10
follow_weightright[7]=-10
if temp_prox[5]>300 then
temp_prox[4] = temp_prox[4]-200*k
temp_prox[5] = temp_prox[5]-600*k
temp_prox[6] = temp_prox[6]-100*k
end
if temp_prox[5]>500 then
temp_prox[4] = temp_prox[4]-50*k
temp_prox[5] = temp_prox[5]-150*k
temp_prox[6] = temp_prox[6]-25*k
end
end
end

leftSpeed=BIAS_SPEED
rightSpeed=BIAS_SPEED
if gostraight==0 then
for i in 0:7 do
leftSpeed = leftSpeed + follow_weightleft[i]*(temp_prox[i]>>4)
rightSpeed = rightSpeed + follow_weightright[i]*(temp_prox[i]>>4)

end

11
 end
end

end
######################## End of wall follow ###########################

onevent camera

######################## Door detection #############################

if camB[15]==color1 and y==0 then
y=1

else
if camB[10]==color1 and y==1 then
y=2
else
if camB[5]==color1 and y==1 then
y=2
else
if camB[0] == color1 and camB[4] == 90 and y==2 then
y=3
else
if camB[0] != color1 and y==3 then
callsub wall_detected
end
end
end
end
end

######################## End of door detection #######################

4. PATH PLANNING

4.1 Multiple Traveling Salesman Problem (MTSP)

Remember that in a fire we would want the robots to search all rooms in the map to extinguish the
fire. This is simply a matter of visiting all the vertices or to be accurate, visiting enough vertices to
cover all the rooms. To simplify the algorithm, for now, we will achieve visiting all the vertices first.
Either way this is a multiple traveling salesman problem since we converted the environment into
a graph. (Figure 4.1)

Figure 4.1 MTSP Problem

4.1.1MATLAB Code for MTSP using Genetic Algorithm (GA)

There is an implementation of a solution to this problem using GA (figure 4.2). I have made a small
change to the fitness function to minimize the distance of the robot which has to travel the longest
path instead of achieving shortest total path of all the robots.

12
This is important since we want the time taken for the last robot to finish searching to be short due
to evacuate the last victim as fast as possible. After finding a modified MTSP solution for the graph,
the multiple E-Pucks can then traverse following these routes.

Figure 4.2 MATLAB MTSP solution

4.2 Djikstra Algorithm (Or any other greedy algorithm for shortest path)

In the event any of the E-Pucks detects fire in any of the room, a help signal is broadcasted via
Bluetooth. E-Pucks receiving this message will perform a Djikstra Algorithm to find the shortest
path to the room which is on fire and broadcast the length. Depending on the number of E-Pucks
requested, the M shortest length broadcasted will traverse through the planned path to the room
which is on fire.

4.3 Improvements

We can try to implement the GA algorithm in the E-Pucks itself. The E-Puck will broadcast their
fittest chromosomes to crossover with the chromosomes on the other E-Pucks’ gene pool.

Figure 4.3 Broadcasting GA Best chromosomes Globally

4.4 Achieving True Decentralized Control

Even after implementing GA directly in the E-Puck itself, the control is not truly decentralized. This
is because the E-Pucks need to be aware of the global task and break it down using algorithms in
parallel.

In order to achieve true decentralized control, we can make the E-Pucks solve the whole SMP
individually first. When they come into contact with each other, they will genetically solve it using
the MTSP algorithm and break the task into two. As they come into contact with more E-Pucks they
will split the task further.
13
They will also report vertices that they have traveled (and thus not in the MTSP problem anymore)
and ones that they know (from pass contacts) others have traveled. E-Pucks are not required to be
in contact with each other. They simply do so upon contact (Bluetooth).

In this manner they can conquer large environments which are beyond the range of Bluetooth and
thus not having global communications. If implementable, this control will truly be decentralized.

Figure 4.4 Decentralization by local broadcasting of chromosomes. E-Pucks will

initially be set to traverse whole map initially and split it up as they interact

5 . G A N T T C HA R T

14
 6. CONCLUSION

I have presented the progress of the project thus far. This project is very interesting with so many
possibilities in the implementation. I will expect problems in implementing them in the real E-Puck
since these algorithms are rather ambitious.

I will keep in mind to create useful tools and codes in the area of decentralized control and other
general functions that the community can use to conduct research using E-Pucks throughout the
course of this project.

15