Robotics Project

Robotics Project Teachers: Prof. Rouvinez and Prof. Hirsbrunner University of Fribourg Ivan-Asen Myurvedov Rue de Lausanne 74 CH-1700 Fribourg http://www.freempq.com E-Mail∗ January 14, 2014

∗

mailto:[email protected]

Contents 1 Introduction

1

2 Conditions 2.1 The Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 The Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 The Playground . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 3

3 The 3.1 3.2 3.3

challange The challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . Approach and ideas and issues . . . . . . . . . . . . . . . . . . The solution . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 4 4

4 The 4.1 4.2 4.3

code Variables, constants and global events . . . . . . . . . . . . . . Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . Camera and irsensors event . . . . . . . . . . . . . . . . . . .

5 5 7 9

5 Testing the code 12 5.1 In a simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 In real environment . . . . . . . . . . . . . . . . . . . . . . . . 13 6 Conclusion

13

Bibliography

14

i

1 INTRODUCTION

1

1

Introduction

Robotics has been a part of science-fiction for a very long time. With the evolution of the computer power the concept of artificial intelligence has left the fiction and has become reality. Even though the robots still have to be guided and the surrounding environment has to be updated so they can function properly, huge progrees is being made. As a first year IT student at the University of Fribourg, I got to work with applied informatics in the ”Robotics Project” class. The goal was to create a code and then apply it to small robots called ”e-pucks”. The work was to be done in groups of two but I decided to work on my own. The final project is to contain this documentation, the code, a video and a presentation. In this document I’ll go through the conditions and the challenge, the code and its testing.

2 2.1

Conditions The Software

1. The UI The softwere used for programming, complying and testing the code is called ASEBA Studio. Its interface is pretty simple, easy to learn and has everything needed for the project (debbuging commands, powerfull editor, instant compilation and data inspection). Moreover there are tabs for each robot where code can be written. The softwere comes with a playground simulator which makes testing the code very easy. In addition ASEBA can run on the most popular OSs and it’s open-source.

Figure 1: ASEBA UI

2 CONDITIONS

2

2. The Language The programming language is a simple imperative language and ressembles to Pascal or Mathlab. It supports 16-bit signed integers, arrays variables, events and subroutines. However it does not support booleans which may be minor problem in some cases, even thogh there’s a simple work-around that I’ll explain in the code section.

2.2

The Hardware

Figure 2: E-puck robots Created as an open tool at EPFLl 1 , the e-puck is specially build for educational purposes. Its hardware is very simple: It has a microcontroller (dsPIC with DSP core), 8 Kb of RAM, 144 Kb of Flash memory, it weights 200g and has 2 motors, 8 Ir proximity sensors, camera and Leds. In addition, the e-puck has a microphone, a speaker and several other modules. Additional hardwere can be added if needed. The e-puck connects to a PC via Bluetooth and it is powered by a rechargeable Lilon battery. For this particular challange the camera will be used for color detection. It provides a horizontal array of sixty pixels each of them returning a specific value of red, green and blue. The motors will be used for forward and backward acceleration aswell as rotation or curved mouvements. The IR sensors will be used to determine the distance between an object and the robot. 1

Ecole polytechnique federale de Lausanne.

3 THE CHALLANGE

2.3

3

The Playground

Figure 3: The Playground The playground is a square of four walls divided in two parts. There are two blue doors that can be opened by two red blocks each positioned in one of the parts of the playground. If a robot stands to one of the red blocks, both of the doors open. There are two green blocks used for the energy distribution.

3 3.1

The challange The challenge

The challenge starts with four robots in one side of the playground. First they have to find a red block. The robot that finds it first becomes a master and remains near it. The other robots now start to look for the blue doors. Once a robot finds a door it approaches it and asks the master to open the door. Once the door is opened the robot passes in the second part of the playground. After all the robots but the master are on the other side, they start looking for the other red block. When found a new robot becomes the master and the old one have to join the other robots in the second part. Finally when all the robots are in the second part the challenge resetes and everything starts from the begining. In addition the robots have to manage their energy with the help of the two green blocks.

3 THE CHALLANGE

3.2

4

Approach and ideas and issues

The task seems simple but the limited memory of the robots and the nature of the programming language make it more difficult to complete. So I decided to write a code as simple as possible. My idea is to divide the whole task in small parts, each for every action an e-puck has to do. Each part would be defined by a specific behavior. To avoid mixing the different behaviors I would use booleans or other tricks. And most importantly when a e-puck is approaching a door or a block, the other e-pucks will have to wait for it and would not interfere. For the color detection I will use a front pixel and two side pixels (left and right). To make sure optimal area of the playground is explored a mixture of exploring behavior and rotations is one option. The second possible option is the robots to find first a wal, approach it and follow it at a certain angle so the red block and the doors can be detetected. While working on the challenge I faced two main problems: The first was to write a code short enough to fit in the small memory avaliable and yet to accomplish the whole task without any issues. By dividing the challenge in many parts I will be using more code. As the amount of code was limited, I often had to remove parts of the code and make use of subroutines or limit the variables used. The second big problem was to test the code in the physical arena. This time the memory wasn’t an issue because in the physical arena the memory available is twice as big. The main difficulty here was to make the environment friendly and to calibrate the e-puck’s sensors, which would occasionally bug and provide inaccurate values.

3.3

The solution

Finally I decided to keep the simple and yet long code. This way when debugging it it would be easyer to fix any issues and follow the task progression step by step. For the arena exploration I choosed a simple explorer and rotating behavior ( the robots would go forward and when they approach an obstacle they will go the other way). This behavior will be timer based and the robot will switch between exploring and rotating. The robots will have to communicate with each other to coordinate their behaviors. When the code is executed the robots will rotate. No matter where they start this seems a good idea because if the red block is nearby there’s chance for one of them to find it. If it’s not the case they will start exploring. When one robot finds the red block, it will tell the others and they will become idle.The energy is managed separatly and is needed only for the simulation. The robots check constantly their energy and take if needed from the green blocks.

4 THE CODE

4 4.1

5

The code Variables, constants and global events

A. Constants The constants are integers named with capital letters and do not change. I am using many of them to define the different behaviors. As I mentioned before, ASEBA doesn not support booleans so two constants (TRUE and FALSE) would act as such. The other constants I’ll be using are to limit the speed and the distance. I use a constant to reset a timer aswell. 1

3

5

7

9

11

13

15

17

19

FALSE = 0 TRUE = 1 MAX PROX=1500 MAX SPEED = 800 TIMER = 1200 SEARCHR=10 SEARCHB =11 WAIT=12 MASTER=13 CONTROL=14 APPROACHDOOR=15 GETIN=16 OPENDOOR=17 WAITIN=18 WAITFINAL=19 CHECKBLUE=21 WAITTOENTER=22 ROTATE=99

B. Variables The variables are integers, declared at the begining of the code. Their value can be assigned at the begining or later on in the code. Moreover their value can be changed whenever needed. They start with lower case letters and the new words start with a capital letter. Several of them act like booleans and use the TRUE and FALSE constants. 1

3

5

7

var var var var var var var

energyA energy e n e r g y P o o l =FALSE proxLeft proxRight proxFront normalizedSpeed

4 THE CODE

9

11

13

15

var var var var var var var

6

b e h a v i o r = SEARCHR robots = 4 t i m e r = 200 newORDER =FALSE f o u n d B l u e L e f t=FALSE foundBlueRight=FALSE foundRed=FALSE

C. Global Events The global events are executed once when called. They can transmit a value to the robots. If a global event’s value is two, for instance, the global event would transmit two values. The global events are useful for example when a robot has reached a blue doorand needs to ask the master to open the door for him. However I found no need to transmit values so that’s why their values are equal to zero. They are declared in a seperate container made for them in the UI. Once declared there, their code can be written. The first event ROTATE makes the robots switch to rotate behavior, the second to search for the blue doors, the third is for the master to open the doors, the fourth, the fifth and the sixth are feedbacks so the whole process of getting in works as it should. The WAIT event is used when the robots have to wait and the last two events are used for the challenge to reset. 2

4

6

8

OPEN = 0 WAIT = 0 SEARCH B=0 isOPEN=0 i s I N=0 RESET=0 waitENTER=0 newOrder=0 ROTATE=0

10

12

14

16

18

20

22

24

onevent ROTATE b e h a v i o r=ROTATE onevent SEARCH B i f newORDER==FALSE then b e h a v i o r=SEARCHB end onevent OPEN i f b e h a v i o r==MASTER then b e h a v i o r=OPENDOOR end onevent isOPEN if b e h a v i o r==WAIT then b e h a v i o r= getIN end

4 THE CODE

26

28

30

32

34

36

38

40

42

44

46

7

onevent waitENTER i f b e h a v i o r==SEARCHB then b e h a v i o r=waitTOENTER end onevent i s I N r o b o t s −=1 i f b e h a v i o r==waitIN then b e h a v i o r=MASTER end i f b e h a v i o r==waitTOENTER then b e h a v i o r=SEARCHB end onevent WAIT b e h a v i o r=WAIT onevent RESET robots = 4 t i m e r = TIMER newORDER=FALSE b e h a v i o r = SEARCHR f o u n d B l u e L e f t=FALSE foundBlueRight=FALSE foundRed=FALSE e n e r g y P o o l=FALSE

48

50

52

onevent newOrder newORDER=TRUE t i m e r = 100 b e h a v i o r=SEARCHR

4.2

Subroutines

The subroutines are small pieces of code that may be called at any given moment from an event. They are very usefull when the same code is called more than once. I am using five of them: sub stop which makes a robot stop completely, sub rotate which makes the robot rotate anticlockwise, sub approach which makes the robot go forward and stop when it reaches an obstacle, sub explore which makes the robot explore the area and sub lookaround which switches between explore and rotate subroutines based on a timer. 2

4

6

sub s t o p s p e e d . l e f t =0 s p e e d . r i g h t =0 sub r o t a t e s p e e d . l e f t =0 s p e e d . r i g h t=MAX SPEED

4 THE CODE

8

10

12

14

16

18

8

sub approach c a l l math . muldiv ( normalizedSpeed , MAX SPEED, proxFront , MAX PROX) s p e e d . l e f t = MAX SPEED − n o r m a l i z e d S p e e d s p e e d . r i g h t = MAX SPEED − n o r m a l i z e d S p e e d sub e x p l o r e i f p r o x L e f t 200 then callsub explore else callsub rotate end i f timer 35 then c a l l e n e r g y . send ( 1 5 )

4 THE CODE

12

9

end

4.3

Camera and irsensors event

Those events act like loops. The Camera event is used to constantly check for blue and red colors. If a color is found the event changes a boolean variable so the reset of the code could ”react” properly. 1

3

5

7

9

11

13

15

onevent camera i f cam . b l u e [41]==61 then f o u n d B l u e L e f t=TRUE else f o u n d B l u e L e f t=FALSE end i f cam . b l u e [17]==61 then foundBlueRight=TRUE else foundBlueRight=FALSE end i f cam . r e d [29]==77 then foundRed=TRUE else foundRed=FALSE end

The irsensors event is where I put all the code logic, which is based on if and else steatments. First it updates constantly the proximity values. Then based them and on the booleans provided by the camera event, as well as the global events the robots change their behavior accordingly. 2

4

6

onevent i r s e n s o r s #check t h e p r o x i m i t y and e n e r g y c a l l s u b manageEnergy proxFront = ( prox [ 0 ] + prox [ 7 ] ) /2 p r o x L e f t = ( 5 ∗ prox [ 0 ] + 3 ∗ prox [ 1 ] + prox [ 2 ] ) /8 proxRight = ( 5 ∗ prox [ 7 ] + 3 ∗ prox [ 6 ] + prox [ 5 ] ) /8

If the behahavior is look for red then call subroutine lookaround. When found, tell the other robots to wait and switch to CONTROL behavior. On the control behavior, the robot will apprach the red block and stop. Then it switches to MASTER behavior and tells the other robots to look for the blue doors. In addition if this happens after all ther robots have passed in the other part of the playground, it resets the robot count:

4 THE CODE

2

4

6

8

10

12

14

16

18

10

i f b e h a v i o r==SEARCHR then i f foundRed==TRUE then b e h a v i o r=CONTROL emit WAIT else c a l l s u b lookaround end end i f b e h a v i o r==CONTROL then c a l l s u b approach i f proxFront >300 and foundRed==TRUE then b e h a v i o r=MASTER emit SEARCH B i f r o b o t s==0 then r o b o t s=4 end end end

If the behavior is MASTER then the robot will try to keep distance from the red block but remain near it. If it is the only one remaining in a part of the playground it will start to look for blue, provided a boolean is TRUE. If the behavior is SEARCHB, the robot will call sub ”lookaround” and if it finds it will tell the others to wait then it will switch to CHECKBLUE which is basicly an approach behavior that checks constantly if the color is in front of the robot (if not it will turn so it is). The waitTOENTER behavior is a simple wait behavior. 2

4

6

8

10

12

14

16

18

i f b e h a v i o r==MASTER then i f proxFront 50 then s p e e d . l e f t =−MAX SPEED s p e e d . r i g h t=−MAX SPEED end i f r o b o t s==1 and newORDER==FALSE then emit newOrder b e h a v i o r = SEARCHB end i f foundRed==FALSE then callsub rotate end end i f b e h a v i o r==SEARCHB then c a l l s u b lookaround i f f o u n d B l u e L e f t==TRUE o r foundBlueRight==TRUE then b e h a v i o r=CHECKBLUE

4 THE CODE

20

22

24

26

28

30

32

34

36

38

40

42

44

11

emit waitENTER end end i f b e h a v i o r==CHECKBLUE then i f f o u n d B l u e L e f t==TRUE and foundBlueRight==TRUE then i f proxFront >30 then b e h a v i o r=WAIT emit OPEN end end i f f o u n d B l u e L e f t==FALSE and foundBlueRight==TRUE then s p e e d . r i g h t=MAX SPEED/4 s p e e d . l e f t =MAX SPEED/3 end i f f o u n d B l u e L e f t==TRUE and foundBlueRight==FALSE then s p e e d . l e f t =MAX SPEED/4 s p e e d . r i g h t=MAX SPEED/3 end i f f o u n d B l u e L e f t==FALSE and foundBlueRight==FALSE then b e h a v i o r=SEARCHB end end i f b e h a v i o r==waitTOENTER then c a l l s u b stop end

The OPENDOOR behavior is used by the master. It approaches the red block and will provide the waiting robot feedback. waitIN is another wait behavior used by the master when a robot is crossing over. waitFINAL is used by the robots that have crossed over the other side of the playground. 2

4

6

8

10

12

14

16

i f b e h a v i o r==OPENDOOR then c a l l s u b approach i f proxFront >900 then b e h a v i o r=waitIN emit isOPEN end end i f b e h a v i o r==waitIN then c a l l s u b stop end i f b e h a v i o r==waitFINAL then newORDER=TRUE c a l l s u b stop end i f b e h a v i o r==getIN then

5 TESTING THE CODE

12

c a l l s u b approach i f proxFront >1200 then i f r o b o t s >1 then b e h a v i o r=waitFINAL emit i s I N else c a l l s u b approach e n e r g y P o o l=TRUE end end end

18

20

22

24

26

28

WAIT is yet another wait behavior. If energyPool is TRUE the reseting is initialized. And finally the ROTATE behavior is used to reset the challenge. 1

i f b e h a v i o r==WAIT then c a l l s u b stop end i f e n e r g y P o o l==TRUE then emit ROTATE b e h a v i o r=ROTATE end i f b e h a v i o r==ROTATE then callsub rotate emit RESET robots = 4 t i m e r = TIMER newORDER=FALSE f o u n d B l u e L e f t=FALSE foundBlueRight=FALSE foundRed=FALSE e n e r g y P o o l=FALSE b e h a v i o r = SEARCHR end

3

5

7

9

11

13

15

17

19

5 5.1

Testing the code In a simulation

Testing the code in the simulation provided by ASEBA is pretty smooth. This is because the conditions are perfect. The robot’s sensors work as charm, there are no interferences and the playground is perfect.

6 CONCLUSION

5.2

13

In real environment

Testing the code in the physical arean is something else. First establishing connection with the robots is a big challange: the ports needed for the connection may not work, the batteries of the robots may not be fully charged (no battery level indicator) and other softwere issues. After a connection is finally established more problems occur: the sensors return negative or false values, light may change the color’s appearance and the physical playground’s ground isn’t as smooth and perfect as the one in the simulation. What is more, even if four or more robots are connected, ASEBA would provide with only one or two tabs for code to be written and occasionally would lose the connection. In order to solve some of the issues I had to use more pixels and more sensors. I had to write code that would limit the negative values of the sensors aswell. However in the end I ended up spending more time trying to connect the robots and trying to find a working one than actually testing the code. Another issue was the amount of people trying to write their code in the lab instead of writing their code somewhere else and then just testing it in the lab.

6

Conclusion

Even though some of the elements of the project were a bit frustrating (for instance the testing in the real environment), the project was very interesting and provided me with a small glimpse of what robotics is all about. Although this project is nothing compared to IBM’s Watson, it may be a very good introduction to the logic hidden behind the ArtificialIintelligence. And for a first year IT student this seems a fair start. Further exploration of the AI is the goal of many scientists and may be crutial for the future of the human kind. Our world is already filled with robots and the way it is going soon they may be better than us in almost everything.

REFERENCES

14

References 1. The code and the lectures provided during the classes. 2. The LaTeX support pages for building the document. http://www.personal.ceu.hu/tex/breaking.htm and Stackoverflow. 3. The official page of the e-puck robot: http://www.e-puck.org/