a lego mindstorms maze solving robot - · pdf filethe following report into a lego mindstorms...
TRANSCRIPT
A Lego Mindstorms Maze Solving Robot
Paul Kevan
BSc Computer ScienceSession (2002/2003)
The candidate confirms that the work submitted is their own and the appropriate credit hasbeen given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may beconsidered as plagiarism.
(Signature of student)
Summary
Mazes date back many hundreds of years and originate from an idea by the Romans. Manymazes exist throughout the world of different size and type but the object of any maze is thesame, to find the exit or to go from start to finish.
This project looks at the use of Lego Mindstorms to solve Orthogonal mazes. It gives an insightinto the most suitable language to use for solving the maze, it details software and hardwaredesign and discusses several possible extensions.
i
Acknowledgements
I would like to thank Tony Cohn, my project supervisor for all of his help, support and timethroughout the project and also to my fellow group of Lego Mindstormers for their contribu-tions during the weekly project meeting.
A special thanks goes to Joanne Rudsdale for her patience and time when proof-reading thisreport and to all my housemates for keeping it real during the past year.
ii
Contents
Summary i
Acknowledgements ii
1 Introduction, Main Aims and Requirements 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.1 Initial Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5.2 Revised Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Mazes: Types and Solving 6
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Hardware: Limitations and Reliability 9
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 RCX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 Overloading Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5 Programming Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Robot Design 13
4.1 Basic Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.1 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
iii
4.1.2 Turning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.3 Supporting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Wall Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.1 Wall Detection Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4 Motors and Gearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Software Design 19
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Robot Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 Robot Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.4 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4.1 Situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4.1.1 Starting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.4.1.2 Following a wall . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.4.1.3 Turning round an outside corner . . . . . . . . . . . . . . . . . . 235.4.1.4 Turning round an inside corner . . . . . . . . . . . . . . . . . . . 24
6 Construction and Design Evaluation 26
6.1 First Attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 Final Robot Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.2 Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.3 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Assumptions and Limitations 30
7.1 Robot and Maze Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.2 Detection of the End Point of the Maze . . . . . . . . . . . . . . . . . . . . . . . 317.3 Initially Finding the Wall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8 Evaluation 32
8.1 Solving the Mazes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.1.1 Test1: Following a Wall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.1.2 Test2: Navigating round an inside corner . . . . . . . . . . . . . . . . . . 358.1.3 Test3: Navigating round an outside corner . . . . . . . . . . . . . . . . . . 368.1.4 Test4: Exiting a dead end . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.3 Comparison to Similar Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
iv
8.4 Further Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Bibliography 41
Appendix A 43
Appendix B 45
v
Chapter 1
Introduction, Main Aims and
Requirements
1.1 Introduction
The main inspiration for this project came from the summer of 2002 when one visited Dorsetwith a few friends on a camping trip. Whilst we were there we visited the worlds biggest MaizeMaze [6]. It was unbelievably annoying trying to solve the maze using only our intelligence andrandom guess work. Eventually, several hours later, we emerged triumphant, we had finishedthe maze and one soon realised on the way back to the campsite that there must be a simplerway to solve mazes rather than just our feeble attempts.
This project makes use of the Lego Mindstorms kit using sensors and motors supplied with thekit to program the robot to make decisions based on the input from the sensors. The programsare beamed to the robot via infra red and are stored within it to produce a fully portable robot.
Due to the nature of the project the relevance of it to one’s degree program is somewhat upfor debate. The contributing modules that could be said to be valid would mainly be theprogramming modules, SO11 (Intro. to Programming (1)), SO12 (Intro. to Programming(2)), SO21 (Object-Oriented Programming), and as for the robotics this could possibly be at-tributed to artificial intelligence modules, AR11 (Introduction to Artificial Intelligence) andAR23 (Bio-inspired Computing). Since the module AR23 is only being undertaken currentlyits contribution to the project has come somewhat later than required. If the module had been
1
available when one was in the second year it could have contributed more to the relevance anddevelopment of the project because the module content dealt with basic robotic intelligenceand genetic algorithms which would have been useful for the project.
The following report into a Lego Mindstorms maze solving robot discusses the history of mazes,the background of Lego Mindstorms, suitable programming environments for tackling the mazesolving problem, extensive robot and program design and also limitations to the final robot’sdesign.
Hopefully this insight into the world of maze solving with Lego Mindstorms will give futurestudents the opportunity to take this further and expand on the findings and progress made inthis area.
1.2 Objectives
1. Produce a robot that can successfully navigate its way from inside a maze to the exit.
1.3 Minimum Requirements
1. Build a working robot that can perform basic operations; sensing dead ends, basic walldetection methods, basic turning, forwards and backwards motion
2. Research into the best possible techniques for wall detection, both front and at the sideof the robot
3. Research into basic maze solving techniques and suitable algorithms to solve these mazesusing the robot
4. Program the robot to get out of a simple maze (starting inside the maze)
1.4 Deliverables
1. A Lego Mindstorms robot that can find its way successfully through a maze
2. Final project report
3. A website documenting achievements : hosted at http://pkevan.co.uk/lego/lego.html
4. Demonstration of progress meeting
2
1.5 Project Schedule
The project schedule was constructed before any of the development took place and was there-fore only an initial one. Due to unseen circumstances the schedule was changed for the reasonsshown below.
1.5.1 Initial Project Schedule
Activity Start Finish
Background research Present 13/12/02
Initial robot design (basic structure, no sensors) and learn the basics of theLego Mindstorms kit
13/12/02 7/01/02
Revision time for January exams 13/12/02 24/01/03
Exam Period 13/01/03 24/01/03
Investigation into the best sensors for detecting gaps in the walls 24/01/03 31/01/03
Implement robot code and test using simple mazes 31/01/03 21/02/03
Meet with project supervisor to discuss best possible extension to the projectand discuss how well one achieved the minimum requirements
21/02/03 21/02/03
Start investigating how best to implement the extensions of the project 21/02/03 24/02/03
Implement and test the extensions decided from the meeting with supervisor 24/02/03 17/03/03
Prepare for the demonstration of progress meeting 17/03/03 21/03/03
Progress meeting 21/03/03 21/03/03
Continue with extensions to project if incomplete 21/03/03 28/03/03
Easter Break 28/03/03 28/04/03
Write up final project report 28/03/03 25/04/03
Proof read report and make final adjustment to report 25/04/03 02/05/03
3
1.5.2 Revised Schedule
Activity Start Finish Reason for change
Background research Present 13/12/02 No change
Initial robot design (basic structure, no sen-sors) and learn the basics of the Lego Mind-storms kit
13/12/02 31/01/02 Mindstorms kit took longer toget familiar with and also revi-sion took more priority at thisearly stage
Revision time for January exams 13/12/02 24/01/03 No change
Exam Period 13/01/03 24/01/03 No change
Investigation into the best sensors for detect-ing gaps in the walls
31/01/03 07/02/03 Moved due to initial design notfinishing on time
Implement robot code and test using simplemazes
07/02/03 06/04/03 Several method of followingwalls detecting dead ends wereimplemented and tested due tosensors being not very accu-rate and reliable
Meet with project supervisor to discuss bestpossible extension to the project and discusshow well one achieved the minimum require-ments
n/a n/a Due to complication with theprogramming not extensionswere discussed
Start investigating how best to implement theextensions of the project
n/a n/a As above
Implement and test the extensions decidedfrom the meeting with supervisor
n/a n/a As above
Prepare for the demonstration of progressmeeting
17/03/03 18/03/03 Change due to rescheduling ofthe demonstration
Progress meeting 18/03/03 18/03/03 Rescheduled in accordancewith supervisor and assessor
Continue with extensions to project if incom-plete
n/a n/a As above
Easter Break 28/03/03 28/04/03 No change
Write up final project report 06/04/03 30/04/03 Started write up after finish-ing the implementation finish-ing later that originally sched-uled
Proof read report and make final adjustmentto report
30/04/03 01/05/03 Finished slightly earlier thanplanned
4
The main changes to the original initial schedule were mainly due to the problems that wereencountered when programming the robot and the fact that the sensors used with the Mind-storms kit are not very accurate and provide the programmer with some frustrating times whentrying to find suitable alternative methods to otherwise simple programming tasks.
5
Chapter 2
Mazes: Types and Solving
2.1 Introduction
A maze is the English equivalent of a labyrinth. According to [16] a labyrinth was a namegiven by Romans to a type of pattern which had a path which went around the whole of thepattern and ended in either the centre or at an exit. Most of these labyrinths were made using a“pattern-making trick” [16] which could make many different routes and this became the basisof, what we today call, mazes. It is also believed that these patterns were solved using a clewof twine (ball of string).
Mazes, or labyrinths, are many hundreds of years old but the actual date when they were firstinvented is still unclear. The basis of maze solving is based mainly on geometry, meaningground measurement [16].
2.2 Types
There are many types of mazes that appear all over the world. Many of the mazes are seasonaland make use of a crop for the walls. A popular crop to use is maize, due to its size andcheapness to plant and cultivate. A list of maize mazes around the world can be found here [5].
Other maze types exist where hedges are used, these are a lot more expensive in terms of labournecessary to maintain the hedges and are therefore less common.
6
Although these physical mazes generally do not conform to any sort of pattern there are clas-sifiers of maze types which can be used to group similar mazes. The main reason that some ofthe groups are not very common is due to their complexity and the fact that they are almostimpossible to build. [13] discusses the various types of maze that exist, many as complex aseach other but, the one that could be replicated is the ’Orthogonal Maze’. An Orthogonal mazehas uniform path widths and all its walls meet at right angles to one another, as illustrated infigure 2.1.
Figure 2.1: An Orthogonal Maze
2.3 Solving
The obvious aim of a maze is to solve it and therefore many techniques exist to help makesolving these mazes easier. Some techniques require the use of a storage space in order to keeptrack of previous routes whereas others simply rely on the same method being used until thegoal is achieved, either reaching the centre of the maze or exiting it.
2.3.1 Techniques
According to [13] there are two classes of maze solving techniques, depending on whether youare interested in solving the maze from start to finish or solving it by looking at the maze asa whole and filling in invalid routes. The last technique would in theory take a longer time tofind a route as it fills in all invalid routes before tracing a successful one.
Below are a few techniques that exist:
• Dead-end filler - very fast, no extra memory needed, searches the maze and fills in alldead ends until a junction is reached and finally the solutions will be found.
7
• Wall following - very fast, will follow either left or right wall from the start to the end.Will only succeed on mazes that have no loops and will not necessarily find the shortestroute to the goal.
• Shortest path finder - finds the shortest path to the goal. Takes multiple routes andcalculates the shortest one.
• Blind alley filler - finds all solutions to the maze and then backtracks by looking for routeswhich return to a position it was previously in. It can be very slow since all solutions arefound.
Further techniques exist and a more detailed description of these techniques can be found at[13]
2.3.2 Algorithms
As such algorithms for solving mazes are not very common, techniques such as breadth firstsearch and depth first search exist but are computationally quite expensive for solving maze orlabyrinth structures.
There are, on the other hand, a few algorithms discussed in [4] which are maze creation al-gorithms. Kruskal’s algorithm, p568-570, makes sure that all sections are connected to oneanother but there are no loops within the structure of the maze.
[4] shows Kruskal’s algorithm being used to find a minimum spanning tree of a circuit whereunits are used to indicate length, a route would be constructed that was of minimal distance.This is achieved by firstly joining the smallest paths and then continuing with paths of increas-ing size until there is a route from start to finish, making sure that there are no loops withinits structure.
Prim’s algorithm, p570-573, operates on a similar basis to Kruskal’s but instead of growingby connecting the smallest paths first it starts at a single position and creates a path wherethe smallest route exists from that position, then from this new position or any other previousposition the smallest path is connected. This continues until all of the paths are connected andno loops are present.
8
Chapter 3
Hardware: Limitations and
Reliability
3.1 Introduction
Lego Mindstorms is a robotics invention kit that allows the user to build and program a robotto react to programmed situations. The kit is a starting block for people who are interestedin getting into the world of robotics and since it is relatively cheap it is an ideal kit for peoplenew to the area.
There is an extremely large following of Mindstorms with plenty of forums and challenges beingset all the time, [10] gives a more in depth insight into the world of Lego Mindstorms and thevarious activities that go on within it.
3.2 RCX
The brain behind the RCX is a small computer based on a Hitachi H8 series microprocessor.The 8 bit processor provides timers, serial I/O and also analogue to digital conversions neededto analyse the input sensors. It also contains 32k of memory mainly used for the storing of thefirmware, 6k of this is reserved for programs that are used to control the robot.
IR is used for communicating between the RCX and the IR tower which is linked to a computer.
9
The IR tower is connected to the computer via a USB port but a serial based IR tower is alsoavailable. Programs are then beamed from the IR tower to the RCX and stored on the internalmemory.
Powered by 6AA batteries the RCX can therefore be used without restriction of a power sup-ply, but an optional AC adaptor is available and extremely handy when downloading programswhere portability is not an issue. This allows the batteries to be preserved and not wasted onthe download of firmware and programs.
One of the limitations of the RCX is that when the batteries are removed the firmware needs tobe uploaded every time. This can become rather frustrating when you are in the testing stageand the batteries need replacing. The firmware takes approximately 5 minutes to upload, but,as an upside to this if you want to change the programming environment you do not need toremove the old firmware and can simply upload it when you replace the batteries.
There are in total 6 ports on the RCX; 3 input ports and three output ports. Each are separatefrom each other but a port can be used to control more than one device depending on what isrequired by the program.
3.3 Motors
There are two 9v motors supplied with the Lego Mindstorms kit, but, if required, there is anextra output port on the RCX to enable a third motor to be used.
As mentioned in section 3.2 more than one motor can be put on a single output port, when thishappens the motors behave identically. This can be an advantage if you only want the motorsto react at the same time. With both motors connected to the same port a rotational robotwould not be possible due to the fact that for it to rotate the motors would need to be turningin opposite directions.
All motors connected to the RCX have two directions, forwards and reverse. The direction thatthe motors turn is also dependant on how the wires are connected from motor to RCX.
10
3.4 Sensors
There are several sensors which come with the Mindstorms kit, including touch and light. Othersensors are available such as rotation, temperature, and also a camera for use with computervision based techniques, but these are not provided in the standard kit.
The input devices are set up to give digital readings and their ranges differ depending on whattype of sensor they are and also in what mode the sensor is set. The table below shows theranges of sensors when they are set to their most suitable mode.
Sensor Type Range Increment Level Comment
Light Sensor 0 - 100 +/– 1 Lighter light values repre-sented as high numbers
Touch Sensor 0 - 100 +/– 100 Boolean : 100 is on, 0 is off
Rotation Sensor -999 - 999 +/– 1 One click = 22.5 ◦ both for-ward and backwards. Keepscount until the sensor is reset
Temperature Sensor −20 ◦C - 70 ◦C +/– 1 Temperatures outside thisrange are displayed as 999.9
3.4.1 Overloading Sensors
Due to the limitation that there are only three input ports it is sometimes necessary to use twodifferent input devices on the same port. The only way that this is possible is if they are twocompletely different devices for example a touch sensor, which is a boolean device, and a lightsensor which has a range from 0 to 100.
When the port receives a sudden jump from its current value to the top of its range it can thenrecognise that the touch sensor has been pressed and it is not a light reading at the maximumof its range. When the touch sensor is released the reading from the port will return to thelight sensors reading. This sort of behaviour enables the two input devices to be distinctivefrom each other. If two touch sensors were attached to the same port they would be indistin-guishable from each other since they output the same reading and therefore this would not work.
3.5 Programming Environment
There are many programming languages available in the Lego Mindstorms world some betterthan others depending on what sort of project you are thinking of tackling.
11
Below is a table which summarises the main programming languages available and highlightstheir strengths and weaknesses.
Programming Language Graphical Variables Comments
RCX Code Yes No Uses the Robotics Invention System suppliedwith the Mindstorms kit
RoboLab Yes No Purchased separately, aimed at classroombased learning
NQC No Yes C like programming language
LegOS Yes No Similar to RCX Code but with support formore complex task, see [11] for more details
leJOS and TinyVM No Yes Java based programming language that usesreplacement firmware. LeJOS is a replace-ment for TinyVM
Visual Basic Yes Yes Uses Visual Basic code
pbForth No Yes Forth based language that uses replacementfirmware
All of the programming languages mentioned above are freely available from the internet, apartfrom RoboLab[8]. There are a few others not mentioned but these are less popular.
RCX Code, RoboLab, NQC, Visual Basic and LegOS all take advantage of the RCX code thatis the standard firmware used by the RCX. The only main disadvantage of using this standardfirmware is the lack of support for floating point numbers. Apart from this slight weaknessNQC and Visual Basic take advantage of storage locations by making use of variables. Theonly difference between these two is that, according to Wozniak on page 10 of [17], Visual Basic“uses less efficient (as well as longer) code compared to NQC” therefore making programs runslower.
The other languages, pbForth[7] and leJOS[15], require the use of different firmware from thestandard one. This means that the language is not restricted by the standard firmware and isgenerally more powerful and flexible. Although these languages are free from the restraints ofthe standard firmware they are still limited by the fixed size of memory within the RCX.
12
Chapter 4
Robot Design
4.1 Basic Design
4.1.1 Size
The main reason behind the robot’s design was its need to be sufficiently small so that it couldbe modelled in an environment which is easy to replicate and test within.
For this reason the robot’s size was the main design issue that needed to be tackled in order toproduce an effective solution to the maze solving problem.
One major contributor to the size of the robot was the size and weight of the RCX unit. Sincethis is the heaviest and bulkiest component of the robot itself the layout of all other parts ofthe robot needed to be in such a way that the robot remained balanced in all situations.
4.1.2 Turning
There are three styles of turning that could be used; fully rotational about the centre of therobot’s axis, a double differential system or using a rack and pinion system similar to those usedon automobiles. For all methods there are certain advantages and disadvantages that come intothe decision when considering the appropriate style for the maze solving robot.
Using a fully rotational robot, figure 4.1, the main advantage is that precise measurements of
13
turning can be made through the use of the rotation sensors (the rotation sensors keep track ofhow far the robot has turned in relation to the wheels). This means that one can program therobot so that it will make movements of right angles only. This would conform to the layoutof the maze and would also reduce the amount of correction needed so that the robot does notcrash into walls unexpectedly.
Figure 4.1: Fully rotational robot
The only disadvantage would be that the two wheels would be completely independent of eachother, this could cause problems with simple forwards motion. If one motor was to either moveat a different speed or have a lag on it, it would mean that the robot could veer to a certainside and big adjustments would inevitably be needed.
A double differential system would exhibit the same characteristics as the fully rotational sys-tem.
Using a rack and pinion, figure 4.2, the main advantages of this system is that the drive iscontrolled by only one motor and therefore reduces the unforeseen change in direction from themotors not working exactly in time with each other.
The only problem with this system is that it restricts the robot’s turning circle. This is becauseonly the front wheels will be controlling the direction of the robot. Therefore to complete aright-angled turn from its current position would require the robot to know that the turn wascoming up and start turning so that it can make the passage without having to reverse. Thismethod is not completely impossible but it would require a large sensor in front of the robotthat would in turn restrict the movement of the robot thereby making it rather impractical.
For the reasons stated above I feel that it would be the best option to use a robot that has full
14
Figure 4.2: Using a rack and pinion system
rotation about its axis to give the robot the maximum amount of manoeuvrability. Also forsimplicity the double differential system will not be used due to there being no constructioninvolved when using the fully rotational robot.
4.1.3 Supporting Features
Since the robot needs the ability to rotate there is a need for a support for the front section ofthe robot so that it does not fall forwards and can maintain forwards motion without draggingon the floor.
For this support, the best method which was found was based on an idea by Baum used inhis example of Tribot, Chapter 11 [1]. This robot uses what he calls a “swivel wheel”. Theswivel wheel is basically a wheel connected on a rod which has the ability to swivel throughout360 ◦ and also move forwards and backwards. Figure 4.3 shows what the swivel wheel looks like.
Figure 4.3: Supporting front wheel
15
4.2 Wall Detection
There are a couple of options that could be implemented to detect walls on all sides of therobot. Front, side and rear parts of the robot need the ability to detect when a collision hasoccurred, which section of the robot has just had that collision and then appropriate action canbe taken to enable the robot to continue with its task of finding the exit of the maze.
The options that were available were as follows:
• Light Sensors
• Touch Sensors
Using light sensors only would mean that a sensor would have to be positioned on each ofthe sides that could come into contact with a wall. The light sensors themselves can pick upchanges in light intensity when they move in a direct line towards the object, in this case thewall. Only when they are extremely close, less than a centimetre does the light change enoughto allow the robot to detect that it is approaching a wall.
Conversely, when following the wall the light sensor is close to the wall and when a gap occursin the wall that is being followed the light intensity changes quite dramatically and a gap inthe wall is easy to detect.
Using touch sensors only would mean that detection at the front and also for the wall followingcould be achieved by using an arm mechanism that would be shaped in a way that it can followthe wall and also detect a wall which is in front of it. For detection at the back, a simplemechanism could be implemented so that when it touches the wall it touches a sensor which isattached to it.
Both methods of wall detection are good solutions to the problem apart from the fact that lightsensors are not very good at detecting approaching walls which come at an angle to the sensoritself. For this reason and also the fact that the robot could easily break the light sensors offbecause there would be no arm to detect the wall and provide some protection against the sen-sor hitting the wall directly, the best method for detecting walls would be to use touch sensorsand not light sensors.
16
4.2.1 Wall Detection Arms
There will be a total of two detection structures on the robot, at the front and the rear of therobot. The rear sensor will be based on a similar method used by Baum [1] in his example ofa Bumpbot in Chapter 6.
The Bumpbot method of rear wall detection uses the idea that the touch sensor is constantlypressed and when it is released this indicates that a wall has been detected. Baum [1] concludesthat this method where the touch sensor is constantly pressed is better for the sensor sincewhen there is a collision with an object/wall there is no pressure put on the sensor unlike whenthe sensor is triggered by touching it. As well as the reduced pressure on the sensors he alsosuggests that the RCX has more time to respond rather than when the touch sensor is hit andmore pressure is applied to the sensor whilst the RCX gets round to responding to the sensorbeing pressed. The structure is pivoted along two beams which allow sufficient movement ofthe structure so that it does not break when hit, even at reasonably force.
For detection of the wall and also at the front of the robot, a joint arm was created to max-imise the use of the touch sensor. The arm can then detect both bumps from the side andalso when the robot hits a wall head on. It is held away from the touch sensor via an elasticband so that as soon as the wall is not longer in contact with the wall the touch sensor is released.
This arm contributes considerably to the size of the robot and thus is a conflict of the designgoal of constructing a small robot. Due to the limitation of the robot kit and the fact that onlya limited number of sensors can be used it was considered a worthwhile conflict because thearm was providing detection at the front and the side at the same time.
Wheels are attached to the arm so that the robot can follow the wall smoothly and can alsostill rotate when in contact with the wall see figure 4.4.
Figure 4.4: Wall Detection Arm
17
4.3 Sensors
In addition to the touch sensors used for the detection of walls there will be a light sensor whichcan detect when the robot has found the end of the maze. This sensor will be positioned sothat it is close to the floor and can pick up a change in colour when the robot exits the maze.
Along with this light sensor there will be a rotation sensor whose use is discussed further in thesection 4.5. This sensor will be attached to one of the sides of the robot and is used to measurethe distance which the wheels travel, be it forwards or reverse.
4.4 Motors and Gearing
In accordance with the turning method there will be two motors, one attached to each wheelof the robot. This will give the robot the freedom of movement needed to navigate its waysuccessfully through the maze.
Gearing of the motor was considered to be less important and so to keep size to a minimumthe gearing of the motor was kept direct and the wheels are driven directly from the motors.This decision was made due to the fact that if the robot was over powered by the motors NQChas an option whereby the power levels can be reduced in suitable steps.
4.5 Motion
Forwards and backwards motion can be achieved using both motors at the same time in thesame direction. This is dependent on both motors working at the same speed and starting andstopping at the same time. Variance in the motors can make the robot drift from side to sidebut this should only be minimal movement from a straight line.
By using the rotation sensor the motors can be used so that they are on for a fixed distance.This can be useful for searching in the case of finding the wall it is following. Further discussionon this is in the chapter 5.
Another use of the rotation sensor is to turn at angles enabling the robot to turn round cornersor complete a full turn to change its direction of motion.
18
Chapter 5
Software Design
5.1 Introduction
In section 3.5 the choice of programming languages was discussed. From all of the languagesshown in this section one of them had to be chosen in order to program the robot.
The decision was taken to program in NQC. The main reasons for this choice are due to the factthat the language supports variables, which is very important when counting various measureddistances with the rotation sensor and also when the rotation sensor is used for turning. Notonly does NQC support variables but it also runs with the standard firmware so there is noneed to change to a different firmware.
When using the language NQC it is also possible to run a program called BricxCC [3]. BricxCCallows the user to compile programs using a graphical interface and also to edit their compiledprograms. This makes downloading and editing programs easier since NQC is a command linebased language and does not have a graphical interface.
5.2 Robot Navigation
Within the programming environment of NQC each of the sensors used to aid the robot in find-ing its way to the exit of the maze are represented as an output which is read as an integer value.
19
For the sensors used, light sensor, touch sensor and rotation sensor, they each have their thresh-olds and limits that are used to trigger certain events within the program.
In the case of the light sensor, that is connected also to the touch sensor at the front of therobot, it will send a signal when it receives a light value below the threshold set, which, in thiscase, will indicate that the end of the maze has been reached and to turn off all motors. Therange of this light sensor, within NQC is between 0 and 100, dependant on the amount of lightthat the sensor receives.
A touch sensor on the other hand will always show either a value of 100 or 0 only, dependingon whether it is pressed or released, respectively.
The rotation sensor displays a value relative to how many times it has turned since the last timeit was reset and distinguishes between forwards and backwards motion by a negative or positivenumber being added to the current total. The sign of the forwards or backwards reading isdependant on how the sensor is connected to the RCX.
5.3 Robot Control
5.3.1 Power
Since there is no gearing built into the robot to limit the speed, as per section 4.4, it will belimited within the program using a pre-defined function, SetPower. The set power functionlimits the power in steps ranging from 0 to 7, although within NQC this is changed to 1 to 8.
To enable the robot to move at a reasonable speed and also in an effort to make sure that all ofthe sensors, arms and wheels remain fixed in their respective positions the power will be limitedto half, or in terms of NQC, power level 4. This should give the robot sufficient speed so thatis does not become underpowered when rotating and moving forwards and backwards.
5.4 Programming
Within the Lego Mindstorms Robotic Invention Kit all the necessary tools are provided tocontrol a robot in most environments. As discussed previously the language which will be usedto develop the software will be NQC [2].
20
The overall programming task is to find a wall of the maze and then follow this wall, on theleft hand side, until the exit of the maze is found upon which the robot will stop.
5.4.1 Situations
When considering the various situations which would arise when locating the exit out of a mazeit became obvious that this rather complex task could be split up into a number of smallertasks that would make finding the route out of the maze far simpler than previously thought.
Since the mazes that were being considered were all going to be orthogonal mazes the layoutof the maze meant that the software could exploit this uniformity.
In breaking up the tasks the following situations were devised:
• Starting from within the maze and locating the wall
• Following a wall
• Turning 90 ◦ to the left, either to find the wall or turn a corner which appears from eithera gap in the maze or a wall turning left
• Turning 90 ◦ to the right, either turning a right hand corner or exiting out of a dead end
• Stopping motion when the end of the maze is reached
Although this structure breaks up the program into various parts the final program will be onethat continuously checks for all the situations apart from the starting situation.
Several other functions were also implemented to reduce the size of the code and improve thereadability of it. These functions include ones that enable the robot to move certain distancesboth backwards and forwards since these are the most common movements that the robot hasto make.
The main program is based mainly on a continuous loop which will only terminate when theend of the maze is reached indicated by a change in light sensor value. This method works wellbut needs to be implemented in such a way so the robot can detect the end of the maze, seesection 7.2 for more details.
21
5.4.1.1 Starting
When the robot is initially placed inside the maze it should, in theory, be approximately in thecentre of the maze. Its main objective from this point onwards is to find the exit or one of theavailable exits from the maze using the technique of following a wall.
To begin with, so that the wall following technique can be used, the robot needs to locate thewall. For this task it was decided that the easiest way to do this would be for the robot toreverse until it hits the wall, move forwards slightly so that the robot does not get stuck tryingto turn with its rear sensor against the wall and then rotate around 90 ◦. The robot would thenbe in contact with the wall or in close proximity of it so that it can then continue searching forthe exit.
The basic algorithm for this task is as follows:
while rear sensor is still pressed {
reverse;
}
move forwards slightly;
rotate 90 degrees left;
5.4.1.2 Following a wall
Since the tasks have been split up so as to isolate each individual situation that might occurwhilst navigating the maze it makes the following the wall algorithm appear to be the easiestimplementation. This is not the case as will become apparent when all of the situations are puttogether to form the final solution to the maze problem.
The basic algorithm for this task is as follows:
while {
if front sensor is pressed {
move forwards;
}
else {
rotate left until the front sensor is pressed;
}
}
22
5.4.1.3 Turning round an outside corner
By definition turning round an outside corner is merely taking the route around the outsideof a corner so in this instance it would be turning left round a corner, since the method beingimplemented to solve the maze is to follow left hand walls. This is illustrated in figure 5.1.
Figure 5.1: Showing two instances of going round an outside corner
By using the rotation sensor and a bit of mathematics it is possible to make an estimation onhow many clicks of the rotation sensor it will take to turn the robot 90 ◦ to the left. Taking intoaccount the robots width and the circumference of the two wheels it is possible to calculate thedistance that the wheels move when rotating the robot through 90 ◦.
The robot’s turning circumference, taken from the width of the robot where the tyres are incontact with the ground and then multiplied by π. Robot’s radius = 146mm. Thus the turningcircumference will be 146 * π = 459mm(to the nearest mm).The radius of the tyres is 83mm.Therefore the circumference is 83 * π = 261mm (to the nearest mm).
For the robot to turn 90 ◦ both tyres need to travel a quarter of the robot’s circumference.Making the distance travelled to be: ((0.25 * 459) / 261) = 0.44 times or in terms of degrees,158 ◦. This means that in terms of rotations this would make this approximately 7 clicks of therotation sensor.
This use of the rotation sensors can then be used to turn the robot 90 ◦ to the left. As well asthe amount of rotation being measured the movement will finish if the front sensor is touched,thus indicating that a wall has been encountered. The algorithm for this is shown below:
function Rotate_90_Left() {
clear rotation sensor;
while rotation sensor >= -7 and front sensor is not pressed {
right motor on forwards;
left motor on reverse;
23
}
Off both motors;
Also when considering the problem of turning around an outside corner it is important to re-member that in order to get round the corner the robot needs to move forwards so that therobots wheels will make it round the corner because of the distance between the wall sensingarm and the centre of the robot. This distance is approximately 130mm, which equates toabout half a turn of the tyres ((130 / 261) = 0.5), this therefore equals 8 clicks on the rotationsensor.
Using the data obtained above it is then possible to incorporate this into the algorithm shownbelow:
clear rotation sensor;
move forward 8 clicks;
rotate 90 degree left;
5.4.1.4 Turning round an inside corner
Turning round an inside corner is very similar to that of an outside corner. The wall which isbeing followed on the left hand side changes direction by 90 ◦ to the right. This is illustratedin Figure 5.2.
Although it would seem that the method would be nearly identical to that of the outside cornerthe implementation is somewhat more difficult since the arm which is used to detect the wallon the left hand side is now stuck because it is both following the wall and also detecting thatthe robot has reached an end wall. A suitable method is therefore needed to manoeuvre it outof the situation and make it continue following the wall.
Figure 5.2: Showing two instances of going round an inside corner
The mathematics used in section 5.4.1.3 to determine the correct number of clicks on the rota-tion sensor can be used once again to move the robot through 90 ◦, but this time to the right
24
instead of the left.
Implementing a method so the robot does not get stuck constantly in the corner involved usingthe rotation sensor to measure the distance travelled in a certain amount of time, achieved byusing global variable. Then if the robot has not moved sufficiently in this period it is assumedthat it is stuck and then the method of moving out of the corner can be used.
After attempting to move 3 times if not enough distance has been moved then the robot willmove out of the corner or dead end, depending on which it has encountered.
The basic algorithm for this task is as follows:
variables declared globally
count=0;
distance_count=0;
if (count = 3) {
if (distance_count <= 3) {
Rotate_90_Right();
count=0;
distance_count=0;
}
else {
count=0;
distance_count=0;
}
}
function Rotate_90_Right() {
reverse slightly;
clear rotation sensor;
while (rotation sensor <= 7) {
left motor forwards;
right motor reverse;
}
off both motors;
}
25
Chapter 6
Construction and Design Evaluation
6.1 First Attempt
Whilst experimenting with the Lego Mindstorms kit, before the design stage, one attemptedsomething that did not work but in the end improved my design.
The main design fault was due to the positioning of the RCX and also the gearing of themotors. Originally it was perceived that the robot would simply find the wall and sprint tothe end of the maze following the wall so every effort was made to increase the speed of the robot.
From this original perception a robot was constructed that would, in theory, be fast and alsosmall enough to find its way through the maze. The wall detection arms were not attached dueto the objective being to get the robot to move.
Figure 6.1 illustrates the original positioning of the RCX, on top of the motors. This gave therobot a height of 162mm, thus providing the robot with similar dimensions to the RCX butslightly wider where the wheels attached to the chassis and longer where the supporting wheelis connected to the front.
The gearing of the robot is shown in figure 6.2. There are two 24-tooth gears that connecttogether, with the bottom gear providing the driving force for the wheels. Although you wouldthink that due to the gears being present the gearing would actually change, but since the gearsare identical the same final power ratio is not changed. This sort of gearing can be handy when
26
Figure 6.1: First Attempt Design
you need to have the driving wheels slightly further back from the motors. Thus the originalidea of gearing the motors to make the robot move faster was wrong.
Figure 6.2: Gearing
In conclusion, the main problem with this initial design was the fact that when the motorsbegan driving the wheel, the power behind them made the robot tip backwards. This was dueto the positioning of the RCX and the motors. To fix this problem the motors need to be movedbehind the RCX so that balancing would be easier to achieve.
6.2 Final Robot Design
After the faults of the first attempt, discussed in the section above the final robot design wasreduced in height and with the additional arms and rear sensors it was more suited to followingwalls and managed to move steadily without tipping backwards.
6.2.1 Dimensions
Figure 6.3 shows the length and width of the robot. The arm at the front and also the rearbumper add to the length of the robot but these are an essential part of the wall detectionmethod. The height of the robot, not illustrated in figure 6.3 is 109mm, significantly lower
27
than the first attempt, this is due to the RCX sitting directly on top of the main chassis andthe motors being positioned behind the RCX.
Figure 6.3: Final Robot’s Dimensions
6.2.2 Motors
As previously found in section 6.1 the position of the motors makes a difference as to where thepower to the robot is placed. If they are too far forward then the robot tips up, for this reasonthe motors have been placed directly behind and under the RCX. With the motors being underthe RCX it allows them to power the wheels directly without the use of cogs.
Each of the motors are connected to an individual port on the RCX allowing them to be oper-ated independently as described in section 4.1.2.
6.2.3 Sensors
The sensors that are attached to the robot are as follows:
• Rear Touch Sensor
• Front Touch Sensor
• Rotation Sensor, attached to right wheel
28
• Light Sensor
The rear touch sensor is used for detection of a wall behind at the start of the program. Oncethe rear sensor has been released the robot knows that it has found a wall and can then beginto follow it.
At the front of the robot there is a wall detection arm which triggers a touch sensor when itcomes into contact with a wall either at the side or in front. This sensor is attached to the sameport as the light sensor that is used for detecting the end of the maze.
On the right side of the robot the rotation sensor is attached via an extension rod that is at-tached directly to the motor. The sensor is then supported by two pieces of lego that is attachedto the top of motor to provide extra support.
Underneath the robot the light sensor detects the end of the maze, as mentioned above, thislight sensor shares a port on the RCX with the front touch sensor.
29
Chapter 7
Assumptions and Limitations
7.1 Robot and Maze Size
Section 6.2.1 shows the dimensions of the robot. Due to the robot’s size the mazes that it cansolve are restricted to a certain size as well, mainly so that the robot does not get stuck when itattempts to rotate. If there is not enough room to manoeuvre then the robot will become stuck.
Figure 7.1: Rotating Circumference
30
The space needed within a maze to ensure the robot does not become stuck is the diameter ofthe rotational circumference, i.e. the distance between the central turning point and the endof the wall following arm. This space means the robot is able to rotate without getting stuck.
This distance, as illustrated in figure 7.1 shows that the minimum width of the passages in themaze will be limited to 520mm.
7.2 Detection of the End Point of the Maze
Using a light sensor to detect the end point of the maze only limits the robot by the fact thatin order to find the end of the maze and stop there needs to be a significant change in thebrightness of the floor.
This can be achieved in a number of ways but one of the best methods is to have a maze with awhite floor. The change in floor colour will signify that the end of the maze has been reached,this is assuming that the colour of the floor at the end is darker than the floor within the maze.
Since the light sensor is used to detect the end of the maze it can be programmed for differentlight intensities by changing the lowest light variable in the program, . As soon as the readingfrom the light sensor drops below this variable’s value the end of the maze is assumed to havebeen reached. Therefore to program the robot for a different maze colour the light readinginside the maze needs to be taken and also the end of the maze needs to be darker than withinthe maze (to produce a lower light reading), this will then signify the end.
7.3 Initially Finding the Wall
The initial wall detection method is limited by the fact that to detect a wall the robot has toreverse to find it. This limits the robot in the case where the robot is not positioned so that itcan reverse to find the wall.
Although this may not seem like a major limitation there is a chance that the motors could berunning at different speeds meaning that if the robot is far enough away from the wall it wantsto find, it will circle and thus never find the wall.
31
Chapter 8
Evaluation
8.1 Solving the Mazes
Since the technique for solving the maze was using ’wall following’ one realised that duringthe testing phase this could be simulated by splitting into several tasks. These tasks wouldshow that the robot can navigate around a maze structure. The main reason for this type oftesting was the fact that building a maze that would test the robots ability would have takena considerable amount of time.
The resulting test area was constructed using bricks and several pieces of wood, acting as thewalls of the maze. Figure 8.1 illustrates the test area and shows its approximate dimensions.
Figure 8.1: Test Area
Due to the robot following the wall on its left side the test area was completed in a clockwisedirection, starting at the position marked start on figure 8.1.
32
All of the tests that followed were completed at the same time and the results were separatedto give a more structured evaluation. The numbers in figure 8.2 refer to the walls within thetest structure and therefore when citing the inside corner between sections 1 and 2 this willrefer to the first corner from the starting position.
Figure 8.2: Test Area, section map
The test area was had a brick based surface because it was set up outside on a patio area. AnAC adaptor was also used with an extension cable running above and when the robot moved thelead was also moved. Using a constant power supplied enabled the robot to have the maximumability and not be limited by the batteries running low therefore giving uniform test conditionsthroughout the three test runs.
When starting the ’wall following’ process the robot initially finds the wall by reversing untilit hits the wall.
In total there were three test runs, because during the first run the spring loaded ’wall following’arm became jammed and was unable to return to its original position. A brick was added tostop the arm from jamming again. After the second run was completed successfully the testwas taken again to make sure that the run was not a stroke of luck.
8.1.1 Test1: Following a Wall
’Wall following’ is by far the easiest of the tasks that the robot does. Due to the wheels at theend and the mid section of the arm it allows the robot to follow a wall smoothly.
33
Test Run 1
Section Successfully Completed Comment
1 Yes After finding the wall the robot follows thewall to the end of the section
2 No Reached the end of the section and the wallfollowing arm sprung out and would not re-turn, run ended
The brick used for stopping the ’wall following’ arm moving past the point where it will notreturn was added to prevent further in complete runs.
Test Run 2
Section Successfully Completed Comment
1 Yes Ok
2 Yes Ok
3 Yes Ok
4 Yes Ok
5 Yes After turning the corner the wall was missedon the first attempt and got stuck on the endbut returned to the wall after a second at-tempt.
6 Yes Overshot the end of the wall slightly
7 Yes Ok
8 Yes Ok
9 Yes Ok
10 Yes All walls followed successfully
34
Test Run 3
Section Successfully Completed Comment
1 Yes Reverse to wall not quite straight, started fol-lowing wall slightly further up the wall thanthe start
2 Yes Ok
3 Yes Ok
4 Yes Ok
5 Yes Ok
6 Yes Ok
7 Yes Ok
8 Yes Ok
9 Yes Ok
10 Yes Over shot the end of the wall, but all sectionscompleted successfully
As expected the robot only encountered a few minor problems during the wall following, mainlydue to the other more complicated manoeuvres and also the problem with the wall followingarm in test 1.
8.1.2 Test2: Navigating round an inside corner
Navigating around an inside corner is the most difficult task that the robot has to complete.During testing, the corners that the robot encounters will be indicated by the sections wherethey meet for example the first inside corner will be the one between sections 1 and 2. All othercorners, that are inside corners, will be referred to in this way. For a more detailed explanationof an inside corner refer to section 5.4.1.4.
Test Run 1
Corner Successfully Completed Comment
1 - 2 Yes Corner navigated successfully
n/a n/a Run ended, as before
35
Test Run 2
Corner Successfully Completed Comment
1 - 2 Yes Did not turn 90 ◦ but since the wall followingarm was in contact with the wall it straight-ened up to continue following the wall
4 - 5 Yes Ok
Test Run 3
Corner Successfully Completed Comment
1 - 2 Yes Ok
4 - 5 Yes Ok
8.1.3 Test3: Navigating round an outside corner
Navigation round an outside corner is one of the tasks that the robot does instinctively due tothe method that it follows the wall. Whenever there is no wall present on the left side it turns90 ◦ to the left. This means that every time the robot passes the end of the wall is should lookfor the wall by turning left and finding it.
Within this section of testing, the manoeuvre where the robot follows the wall and changesdirection will be tested as well, this is shown where the sections 5 and 6 meet. The robot hasto navigate around these sections and continue following the same wall on the other side.
Test Run 1
Corner Successfully Completed Comment
2 - 3 No Wall detection arm sprung out, run ended
36
Test Run 2
Corner Successfully Completed Comment
2 - 3 Yes Ok
3 - 4 Yes Ok
5 - 6 Yes Missed going all the way round on the firstattempt and hit the end of the wall but thisenabled it to go past the edge and find wall 6
6 - 7 Yes Ok
9 - 10 Yes Ok
10 - 1 Yes Over ran wall 10 and turned round success-fully onto wall 1 first time
Test Run 3
Corner Successfully Completed Comment
2 - 3 Yes Ok
3 - 4 Yes Ok
5 - 6 Yes Navigated round successfully
6 - 7 Yes Ok
9 - 10 Yes Ok
10 - 1 Yes Ok
8.1.4 Test4: Exiting a dead end
The dead end testing was set up to enable the robot to show its ability at returning back upthe same passage, but on the other side. Dead ends will be indicated by the sections whichthey are made up of, as in the other previous sections.
Test Run 1 was not completed due to the failing of the wall detection arm so the dead end wasnot reached and there was no data to report.
37
Test Run 2
Dead End Successfully Completed Comment
7 - 8 - 9 Yes Took three attempts to move around to theright in the corner of 7 and 8 due to the armgetting slightly stuck on the wall, section 8 to9 was completed with no such problems
Test Run 3
Dead End Successfully Completed Comment
7 - 8 - 9 Yes Section 7 and 8 were more successful this timebut between 8 and 9 the robot took two at-tempts to get round the corner
8.2 Conclusion
Generally, after all of the testing, the robot could be said to be performing well. It can suc-cessfully navigate a set of walls using a wall following technique and finish the course with onlyminor problems that are rectified upon another attempt at the problem.
Due to the nature of the testing the lack of actual maze solving could suggest that the robotmight not have the ability to solve a maze but because of the simulated wall following testarea one believes that a maze would produce similar results and would encounter only minorproblems whilst solving it.
In relation to the minimum requirement of the project, the stated goals were achieved. Therobot can successfully perform the basic operations, although these basic operations are not allof the same level of difficulty for example forwards motion is far simpler than sensing dead ends.
In conclusion, the project achieved its main objective of producing a robot that can find theexit of a maze from starting within it.
38
8.3 Comparison to Similar Projects
Several similar projects exist all providing slightly different solutions to the problem. Someuse more complicated methods of solving than others and a few use different hardware (i.e.notLego Mindstorms) but the common similarity is the use of sensors to navigate through a mazestructure.
A project exists [9] in which different hardware from the Lego Mindstorms kit is used. It isbased on a microcontroller board with motors and a memory store for the programs similar tothe memory store of the RCX. It uses its own style of solving using a sensor at the front andat both sides of the robot. If the front sensor is not hit then it moves forward. If the front andleft sensors are hit it turns right and if front and right are hit it turns left. If all the sensorsare hit it turns round completely, this is explained in more depth at [9].
Another set of projects exist which are more similar in the sense that they use Lego Mind-storms and are also based on the wall following method. The goal for these robots is to finda light source at the end of the maze. There are two different project types, the first usingan extremely primitive method of turning to the first clear path when the front sensor is hit,this proves to be somewhat unsuccessful on several occasions. The second, more complex,project involves building a map of the maze and on the second attempt it uses this map to findthe light source via the shortest route. More information and several videos are available at [12].
Many other projects exist on the Internet, with a simple search producing hundreds of results.The main other site of interest in this area is a competition based at Royal Holloway, Uni-versity of London. This competition is “an annual robotics competition in which autonomousrobot ’mice’ compete against each other to solve a 16 by 16 maze in the shortest time” [14].The competition is free entry and enables robots to compete on a level with other Mindstormsrobots and other more complex robots.
8.4 Further Enhancements
As far as further enhancements go there are several which would be possible and several thatare a good idea but less practical than the others, depending on the hardware available.
The list of possible enhancements is as follows:
• Attempt to program the robot to find its way from within a maze to the exit within a
39
structure that contains loops. The left side wall following technique would be redundantin this case and a new, more sophisticated method would be needed. There are severalways to solve this problem, [9] describes a method called Lee’s algorithm where a mapof the maze is created labelling each block with a number. The goal is set as the lowestnumber and then every block that connects to it directly with no wall in between receivesa number one higher than it. This continues until all the blocks of the maze have beenvisited and they are all numbered. The fastest route that the robot can take will start atthe start position and every block that it moves to is a number that is one less that thecurrent block.
• Instead of using standard wall detection methods using touch or light sensors a cameracould be used. The wall tracking could then use Image Processing techniques via a cameramounted on top of the robot which checks for gaps in the wall indicating a new route totake. The camera would be best placed at the top of the robot giving it a good view of itssurroundings. Using the camera the robot would process the images and evaluate themto make decisions on its next movements. These images could be taken at suitable timeintervals depending on the speed of the programmed robot. The camera would rotate tolook for other routes to the left, right and also ahead. The camera could be used to makesure that the robot is going straight ahead by constantly taking images whilst movingforwards and analysing them to check that the wall is still at the same angle and if notadjust its position accordingly.
• One of the main problems with testing a robot within a maze is the construction of themaze. To overcome this problem the maze could be laid out using lines on a piece ofpaper to represent walls. The robot would then use light sensors to follow the lines onthe paper and a variety of different sorts of mazes could be constructed easily.
40
Bibliography
[1] D. Baum. Definitive Guide to Lego Mindstorms Second Edition. Apress, 2002.
[2] D Baum. NQC - Not Quite C, 2002. http://www.baumfamily.org/nqc/ [2nd May].
[3] John Binder. Bricx Command Center 3.3, 2003.http://members.aol.com/johnbinder/bricxcc.htm [2nd May].
[4] Cormen, Leiserson, Rivest, and Stein. Introduction to Algorithms Second Edition. The MitPress, 2001.
[5] Adrian Fisher Maze Design. Maize Maze Locations, 2003.http://www.maizemaze.com/maize mazes01.html [2nd May].
[6] Stewarts GardenLands. Maize Maze.info, 2002. http://www.maizemaze.info/ [2nd May].
[7] Ralph Hempel. pbForth Home Page, 2002. http://www.hempeldesigngroup.com/lego/pbForth/homePage.html[2nd May].
[8] National Instruments. LEGO ROBOLAB - Education Initiatives - National Instruments,2002. http://www.ni.com/robolab [2nd May].
[9] Kallahar. The Micropanzer - An Autonomous Tactical Maze Solution Vehicle, 2000.http://quickwired.com/kallahar/robots micropanzer design.php [2nd May].
[10] Lego. LEGO Mindstorms, 2003. http://mindstorms.lego.com [2nd May].
[11] Markus L. Noga. legOS, 2003. http://www.noga.de/legOS/ [2nd May].
[12] University of Hertfordshire. Lego Robot Projects, 2000.http://dragon.herts.ac.uk/eleqdcl/lego.html [2nd May].
[13] Walter D. Pullen. Think Labyrinth, Maze Algorithms, 2002.http://www.astrolog.org/labyrnth/algrithm.htm [2nd May].
[14] University of London Royal Holloway. Micromouse UK, 2003.http://micromouse.cs.rhul.ac.uk/ [2nd May].
41
[15] Jose Solorzano. leJOS, 2003. http://lejos.sourceforge.net/ [2nd May].
[16] The Amazing Hedge Puzzle. Mazes - a brief history, 1999.http://www.mazes.co.uk/history.htm [2nd May].
[17] Simon Wozniak. An investigation into robotics for applica-tion in hazardous environments using Lego Mindstorms, 3rd YearProject, University of Leeds, 2002. http://www.leeds.ac.uk/cgi-bin/library/compst.pl?CAT=BSC&FILE=200203/wozniak.pdf [2nd May].
42
Appendix A
The project, as a whole, has been an enjoyable one. Ever since the day that I saw there was aproject which involved ’playing’ with Lego I relished the uniqueness that it was going to offerto me which would otherwise have been missing in an ordinary final year project involvingsoftware engineering.
Not only has the project been a challenging one but also it has given myself an invaluableexperience of producing a project of this size. Even during my year in industry nothing of thissize was actually set as a task for me to do, so the lessons learned from it have prepared me forany other large scale projects in my future career.
Even though the project was a success in terms of the findings it produced it was not withoutareas in which I feel other projects would benefit.
The Lego Mindstorms kit, no matter what your experience of any other sort of Lego or LegoTechnics is, will inevitably frustrate you when getting acquainted with it. It is unbelievable thesort of basic programming errors you will make when trying to program it. Things occur thatwould normally not happen in a software only environment but the real world certainly doesnot help the inaccurate sensors provided with the kit.
When it came to writing this report taking the time to learn Latex was an invaluable exer-cise and I would highly recommend this to anyone thinking of writing a report of this size.Its use of citation tags, the automatic bibliography and page numbering are highly useful. Aswell as this, converting to PDF or postscript was far easier than if one was using Microsoft Word.
Hopefully this project will allow future students the opportunity to build on my findings and
43
continue it where I have left off.
44
Appendix B
Final Program Code
// input sensors
#define LIGHT_FRONT_SENSOR SENSOR_1
#define REAR_SENSOR SENSOR_2
#define ROTATION_SENSOR SENSOR_3
// output motors
#define LEFT_MOTOR OUT_A
#define RIGHT_MOTOR OUT_C
// handy output commands
#define BOTH LEFT_MOTOR + RIGHT_MOTOR
// constants
// lowest light will detect when the robot has exited the maze
#define lowest_light 20
#define distance_small -7
#define EVENT_FOUND_EXIT 1
// Global Variables for checking if robot is in a dead end.
int distance_count=0;
45
int count=0;
task main() {
// Setting up of each sensor
SetSensor(REAR_SENSOR, SENSOR_TOUCH);
SetSensorType(REAR_SENSOR, SENSOR_MODE_BOOL);
SetSensor(LIGHT_FRONT_SENSOR, SENSOR_LIGHT);
SetSensorType(LIGHT_FRONT_SENSOR, SENSOR_TYPE_LIGHT);
SetSensor(ROTATION_SENSOR, SENSOR_ROTATION);
SetSensorType(ROTATION_SENSOR, SENSOR_TYPE_ROTATION);
Find_Wall();
Move_Distance_Fwd(distance_small / 2 + 1);
Rotate_90_Left();
Search_For_Exit();
}
// Reverses until it hits a wall from behind
void Find_Wall() {
SetPower(BOTH, 4);
while (REAR_SENSOR < 100) {
OnRev(BOTH);
}
Off(BOTH);
}
// Searches for the exit, although will not stop since command is commented out
void Search_For_Exit() {
SetEvent (EVENT_FOUND_EXIT, LIGHT_FRONT_SENSOR, EVENT_TYPE_LOW);
SetLowerLimit (EVENT_FOUND_EXIT, lowest_light);
while(true) {
monitor EVENT_MASK (EVENT_FOUND_EXIT) {
46
while(true) {
Follow_Wall();
}
}
catch {
// StopAllTasks ();
}
}
}
// function for following wall and also getting out of corners |_
void Follow_Wall() {
if (count == 2) { // changed from 3 since the actions are below
if ((distance_count) <= 3) {
Rotate_90_Right();
count=0;
distance_count=0;
}
else {
distance_count=0;
count=0;
}
}
else {
if (LIGHT_FRONT_SENSOR == 100) {
Move_Distance_Fwd(distance_small);
distance_count = distance_count + (ROTATION_SENSOR * -1);
count++;
}
else {
Move_Distance_Fwd(distance_small / 2);
distance_count = distance_count + (ROTATION_SENSOR * -1);
count++;
Rotate_90_Left();
}
}
47
}
// moves for a certain number of clicks of the rotation sensor or for half a second if stuck
void Move_Distance_Fwd(const int distance) {
SetPower(BOTH, 4);
ClearSensor(ROTATION_SENSOR);
ClearTimer(0);
while ((ROTATION_SENSOR > distance) && (Timer(0) < 5)) {
OnFwd(BOTH);
}
Off(BOTH);
}
// moves reverse for a certain distance or half a second if stuck
void Move_Distance_Rev(const int distance) {
SetPower(BOTH, 4);
ClearSensor(ROTATION_SENSOR);
ClearTimer(0);
while ((distance > ROTATION_SENSOR) && (Timer(0) < 5)) {
OnRev(BOTH);
}
Off(BOTH);
}
// rotates the robot 90 degrees left or until the front sensor is pressed
void Rotate_90_Left() {
SetPower(BOTH, 4);
ClearSensor(ROTATION_SENSOR);
while ((ROTATION_SENSOR > -7) && (LIGHT_FRONT_SENSOR != 100)) {
OnFwd(RIGHT_MOTOR);
OnRev(LEFT_MOTOR);
}
Off(BOTH);
}
48
// rotates to the right 90 degrees or until the front sensor is released
void Rotate_90_Right() {
Move_Distance_Rev(distance_small / 2 + 1);
SetPower(BOTH, 4);
ClearSensor(ROTATION_SENSOR);
while (ROTATION_SENSOR < 5) {
OnFwd(LEFT_MOTOR);
OnRev(RIGHT_MOTOR);
}
Off(BOTH);
}
49