case study - path planning for rescue in indoor environment

8/9/2019 Case Study - Path Planning for Rescue in Indoor Environment

1/15

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.]


2/15

2

DECENTRALIZED CONTROL OF MULTIPLE E-PUCK ROBOTS

1. INTRODUCTION

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 inachieving 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 THE SCENARIO

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


3/15

3

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.

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 containmultiple 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

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.2 Modeling of the environment conditionalcases

Figure 2.3 Modeling of the environment conditional

cases after conditions are met

Figure 2.4 Vertices should be doors

Figure 2.5 Edges are Wall length


4/15

4

Once they enter the rooms their position will no longer need these initial values to define their

state. (Figure 2.6)

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. SIMULATING THE ENVIRONMENT AND ALGORITHMS

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. Its 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 dont 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

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


5/15

5

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 isnt any means to acquire global position of the E-Pucks.

Since it supports the accelerometer, camera and proximity sensors only, there isnt any means for

localization either.

I have attempted to compile the source code to make modification to the simulator. However I

havent 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.

3.2.1.1 Documenting *.playground Map files

Description

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

Figure 3.1 ASEBA Playground


6/15

6

Parameters

Description

World tag defined the dimension/size of the environment

Parameters

Description

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

Parameters

Description

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

Parameters


7/15

7

h=""

moveDuration = ""

name=""

color=""/>

Description

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

rooted to the ground

Parameters

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

Description

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

Parameters

3.2.2 Visual Map Creator for ASEBA

X1,Y1 X2,Y2

X3,Y3 X4,Y4

Figure 3.2 Area parameter


8/15

8

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

wont be a duplicate of doors. The program willprevent this. (Figure 3.3 and Figure 3.4)

To insert E-Pucks, simply draw ellipses to where

E-Pucks will be placed.

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 editable2. Create weighted directed graph of the environment and save it to a file.

Figure 3.3 Visual Map Creator for ASEBA

Figure 3.4 Map created by Visual Map creator


9/15

9

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 its open first. It is capable of programming E -Pucks

individually. (Figure 3.5)

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 Camera3. Skip Door4. 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 and 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.

Figure 3.5 ASEBA studio


10/15

10

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

elseleftSpeed = -100

rightSpeed = 100

end

if (prox[0]


11/15

11

######################## Wall follow #############################

for i in 0:7 do

temp_prox[i] = prox[i]

end

if selector == 1 then #follow right

j=0for 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*ktemp_prox[2] = temp_prox[2]-600*k

temp_prox[3] = temp_prox[3]-100*k

end





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





end if temp_prox[5]>500 then




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


12/15

12

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 thencallsub 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)

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.

Figure 4.1 MTSP Problem


13/15

13

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.

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.

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 usingthe MTSP algorithm and break the task into two. As they come into contact with more E-Pucks they

will split the task further.

Figure 4.2 MATLAB MTSP solution

Figure 4.3 Broadcasting GA Best chromosomes Globally


14/15

14

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.

5. GANTT CHART

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


15/15

15

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 thecourse of this project.

case study - path planning for rescue in indoor environment

Documents