Summary. Lego Mindstorms Robotic Football

Transcription

1 Summary This report aims to document the design, creation and testing of a motorised intelligent football player. The idea was inspired not only by the RoboCup tournament, but also previous projects which have covered similar subject matter. The initial aim was to create a robot which was capable of locating a ball within a controlled environment, moving to the ball, collecting the ball in some manner, and moving to a set coordinate (i.e. the goal) with the ball. The specific minimum requirements were as such: A robot which is able to track where it is on the pitch, see and track the movement of the Robocop ball, collect it and take it to the opponent's goal, and attempt to prevent the ball from reaching its own goal, without getting stuck in any part of the pitch. Possible enhancements to the minimum requirements were as such: As well as this, the scope of the project could be widened so that more than one robot may be used on the pitch at once. If this is done, comparisons between versions of the designed behaviour can be directly compared, as well as between the physical designs of the robots themselves. i

2 Acknowledgements I would like to thank (in no particular order) Tony Cohn for his help and advice during this project. Young Master Cohn for very kindly (unknowingly?) allowing his Dad to lend me a Lego camera with a nice long cable. Andy Bulpitt for his feedback on my mid-project report and project demonstration. Drew without whose inspiration I most certainly would still be floundering in a mess of illconceived code and tobacco packets. My Mum whose regular application of boot to posterior meant that the project got finished and I didn t spend too long wallowing in self-pity. Steve, Rick and Chris for making sure that I remained sane and for providing conversation which did not revolve around computing. Lawrie Griffith who created a piece of software that meant this project stopped being a possibility and became a reality. Karim Ladha for his advice on IR transmission ii

3 Table of Contents Chapter 1 Introduction 1.1 Aims 1.2 Objectives 1.3 Relevance to the IS Degree Programme 1.4 Structure of the Report Chapter 2 Background of the Problem 2.1 Literature Review Construction of the Robot Designing and Implementing the Robot Control Software Introducing a Camera to the System 2.2 What is RoboCup? Chapter 3 Construction of the Robot 3.1 The Lego Mindstorms Robotic Invention System The RCX Brick The Sensors The Actuators 3.2 Robotic Requirements 3.3 Locomotion Legs Caterpillar Tracks Wheels 3.4 Wheel Alignment The Car Method The Wheelchair Method 3.5 Drive Considerations Direct Drive Dual Differential Drive iii

4 Chapter 4 Software Design and Implementation 4.1 Programming Languages The RIS Interface Not Quite C (NQC) pbforth LeJOS Which Language was Chosen The LeJOS Vision System 4.2 PC to RCX Communication 4.3 Ball Tracking The LeJOS Vision System Implementation 4.4 Self Localisation Dead Reckoning Navigation by Visual Sensory Input Which Method of Self Localisation was Chosen and Why 4.5 Self Localisation Implementation Chapter 5 Testing 5.1 Testing Methodologies Objective Objective Objective Objective Objective Objective Objective 7 Chapter 6 Evaluation 6.1 Implementing the Testing Methodologies Objective Objective Objective Objective Objective Objective 6 iv

5 6.1.7 Objective 7 Chapter 7 Expanding the Scope 7.1 Increasing the Range 7.2 Improving the Vision 7.3 Inclusion of Further Robots References Appendices v

6 Chapter 1 - Introduction 1.1 -Aims The aim of this project was to produce at least one robot, constructed of Lego which is capable of playing Robocop football Objectives A fully functional robot (without software), built from Lego, which is able to physically fulfil all the requirements which might be placed upon it. A simple system which can be loaded onto the robot s RCX Microprocessor control brick, which instructs the robot to move around and respond to simple stimuli such as a button press. A more complicated system which can be loaded onto the RCX brick, which, does as above, with the addition of the ability to respond to the stimuli of the Robocop ball. If this proves to be unfeasible, the Robocop ball will be replaced with a coloured ball which can be detected in objective 6. A system which is able to control the robot via remote, using the Infra-Red USB tower. A system which is able to track the movements of the robot(s) around the environment and is able to give an (X, Y) coordinate and a heading for the robot. A combination of the objectives 4 and 5, where a personal computer is able to identify the location of the robot and move it accordingly. For example, a system which will cause the robot to always move to the bottom right corner of the pitch. A system which uses all of the above, in addition to a set of programmable behaviours. The system will control the robot so that it collects the ball and delivers it to the goal. 1

7 1.3 - Relevance to the Information Systems Degree Programme Not all the tasks which were part of this project were relevant to the computing degree. Care has been taken to avoid becoming sidetracked in areas which will not be beneficial to the relevance of the project. For example, it would be very easy to spend large amounts of time designing and building the robot, but since the relevance lies elsewhere, once a functional machine was build, there the process ended. The areas which in particular are covered by the scope of the computing degree, are the aspects of programming the robot to respond to commands, programming the computer to analyse sensory input data, and programming artificial intelligence which would govern the robot s behaviour Structure of the Report The layout of the report will follow these guidelines: Chapter 1 introduces the reader to the project, its aims minimum requirements, and objectives. This section also contains information regarding the relevance of the project to an Information Systems degree programme. Chapter 2 covers the literature which has been used and its relevance to the project. Documentation of literature evaluation is also contained within this section. This review also contains information on the RoboCup project and the Lego Mindstorms background. Chapter 3 documents the construction of the robot and the methods and designs which were employed. Chapter 4 documents the designing and implementation of the software which monitors sensory input, and controls the robot s behaviour. Chapter 5 covers the implementation of the software and the problems which were encountered during this process. Chapter 6 records the testing which was performed on the software programs installed on both the computer, the robot and of the overall system. 2

8 Chapter 2 Background to the Problem Literature Review I have studied a number of final year projects from 2004 and 2005, concentrating on those which were directly related to this project, as well as web resources and literary sources Construction of the Robot With regards to the construction of the robot, there were a number of sources of information. In the past projects concerning Mindstorms, there are many lessons which may be learned in the building of the robot. C.Dodds (2005) 1, D.Cadley (2005) 2 and A.Barrett (2004) 3 all produced outstanding projects on this topic, with Barrett s being the most relevant, since it studied the use of Mindstorms robots as football players. The information gleaned from these projects allowed me to identify where I could expect to have problems with sensor configurations, and how I might solve them if those problems occurred. D. Baum s book 4 has been an impressive guide also, providing information on how each sensor works, and possible design solutions Designing And Implementing the Robot Control Software Deitel s 5 book, covering the Java programming languages has been an invaluable reference guide throughout the project. As well as this, a more Mindstorms -centric programming guide was included in Baum s 6 text, which provided detailed example code. Unlike the Deitel books, Baum s does not cover a specific programming language to any depth. It is more a rough guide and a set of examples of what can be done with the robots and their software. As in every aspect of the development, the past projects covering the topics of Lego Mindstorms have been of use, since they roughly followed the same development methodology as I, and, as mentioned earlier, will allowed me to identify possible problems before encountering them. With regards to online resources, there is a great wealth of sites which can help understand the issues involved with programming artificial intelligence, although not all of it is relevant 1 C. Dodds (2005) - Sensory Aided Lego Mindstorms Robotics 2 D. Cadley (2005) - Introducing Planning to Lego Mindstorms Robots 3 A. Barrett (2004) - Lego Mindstorms Robotic Football 4 D. Baum (2000) Extreme Mindstorms An Advanced Guide to Lego Mindstorms 5 Deitel & Deitel C++ How to Program Deitel & Deitel Java How to Program 3

9 to Lego Mindstorms. The homepages for the LeJOS programming language and the vision system have proved indispensable throughout the project, especially their provision of API s which greatly facilitated learning LeJOS specific syntax Introducing a Camera to the System Since the report of C.Dodds 1 specifically concerns these issues, it was of great use as a reference guide, both in the planning and in the implementation of the camera system. As well as this, the primary programming language for said project was LeJOS which greatly aided in researching solutions for the problems encountered What Is RoboCup? RoboCup is an international joint project to promote AI, robotics, and related field. It is an attempt to foster AI and intelligent robotics research by providing a standard problem where wide range of technologies can be integrated and examined. RoboCup chose to use soccer game as a central topic of research, aiming at innovations to be applied for socially significant problems and industries. The ultimate goal of the RoboCup project is By 2050, develop a team of fully autonomous humanoid robots that can win against the human world champion team in soccer (RoboCup Organisation (2005)) The RoboCup league has a number of different classes simulation, small sized, medium sized, 4 legged, humanoid The game itself is governed by a unique set of rules per class. However, to make a robot which can adhere to these rules would exceed the project s scope, so it was decided that the rules should only be used as a rough guideline to plan the robot s behaviour. 4

10 Chapter 3 Construction of the Robot 3.1 The Lego Mindstorms Robotic Invention System The Lego Mindstorms Robotic Invention System is a construction kit, produced by the Lego Corporation, aimed primarily at school age children with features to make it sufficiently high level enough to be used in higher education. It features around 700 pieces of standard and Lego Technics bricks. In addition to this, the kit also contains the RCX brick, the Infra Red communication tower, a collection of motors, IR and light sensors, rotation sensors and pressure switches: The RCX Brick The RCX, or Robotic Command explorer, (See appendix E.1) is a based upon a Hitachi H8/329 microcontroller. It supports: 5 program slots, each of which can manage 10 tasks (i.e. threads) and support 8 subroutines; 32 global variables 16 local variables per task 4 timers at 100ms precision, and 4 at 10ms 3 input ports (configurable for each sensor type (active or passive)) 3 output ports 1 sound output 1 LCD unit (Robotics Outreach Group (2006)) Put simply, the RCX is the key part of the Lego Mindstorms kit without which, it is impossible to create any sort of interactive robot. The RCX acts as the processing centre for the robot, accepting sensory input and effecting outputs via motors, lights, sound or the LCD screen. The RCX also features an Infra Red (IR) port located at the top of the brick. This allows the RCX to send and receive data from either a PC using the IR Tower or other RCX bricks. By programming systems on both the PC and on the RCX, it is possible to create a remote links 5

11 with limited range which allows remote control of the RCX as well as the ability to transmit sensory data to the computer. The RCX has 3 Lego style ports for sensory input from either the rotation sensors, light sensors or pressure switch. This, however, does not limit any one robot to a maximum of three sensors. The varying output data of the sensors (see section 3.1.2) allows the multiplexing of sensors onto the same port. For example, the light sensor returns a value of anywhere between 0 and 100 whereas the touch sensor returns a value of 0 or 100. It is unlikely that the light sensor will register a sustained value of 0 or 100, so the system could be programmed to interpret a data value from a specific port as a light percentage, unless the figure is 100 where it would assume that the pressure switch has been pressed. It is also possible to create an AND gate for the touch sensors. This can be done by connecting the sensors in series instead of the standard parallel type connection used by the Lego Mindstorms kit. This creates a sensor with two or more sensors, which only triggers when all of the sensors in the series are depressed simultaneously. The RCX brick is pre-loaded with Lego s own firmware, which it is possible to replace with a number of alternative systems based on popular programming languages including C (LegOS), Forth (PbForth) and Java (LeJOS). (See section 4.1) The Sensors The Rotation Sensor As suggested by the name, the Rotation Sensor (See appendix E.4) measures the rotation of an axle in either direction to an accuracy of 1/16 th of a turn. The electrical output of a rotation sensor being turned at a constant rate is plotted thus: 6

12 Figure 1 A graph demonstrating the voltage outputs of the Lego rotation sensor From the non-symmetrical nature of the voltage peaks, it can be seen that the graph would not be the same should the direction of spin be reversed, hence the sensor is able to differentiate between clockwise and anti-clockwise turning. (Gasperi, M. (2006)) The Touch Sensor The output of the pressure switch (See Appendix E.3) is Boolean in nature That is, it can be either a value of 0 or 100. As mentioned earlier, the nature of this output allows the sensor to be multiplexed with other sensors. However, if the touch sensor has a faulty connection or is not depressed fully, the output becomes an erratic spiky graph as seen below which shows the output as the pressure is increased on the switch: (Brown University, (2006)) 7

13 Figure 2 - Graph demonstrating the current passing through the circuit, as the pressure on the touch sensor is increased. The Light Sensor The light sensors (See appendix E.2), which come as part of the Lego Mindstorms kit, return a value between 0 and 100 equating to the percentage light which it is sensing. The range of light frequencies, which the sensor is sensitive to, are shown below: (Brown University (2006)) 8

14 Figure 3 Graph demonstrating the sensitivity of the light sensor to varying frequencies of light Infra red radiation is found within the 700nm 1000nm wavelength. The graph therefore demonstrates that the light sensor is sensitive to much of the visible light spectrum, but is most sensitive in the IR range The Actuators There are only a few actuators available to the Lego Mindstorms kit. These include motors, lights and speakers or buzzers. This project does not concern itself with sound so the speakers and buzzers were not investigated to any depth. However, the motor is an integral part of any robot, and hence the research covered this topic to a reasonable depth: The Motor The motors which come as part of the Lego Mindstorms Kit are 5225 type motors with an internal flywheel (See appendix E.5). The benefit of this over standard DC motors is that the flywheel enables the motor to maintain a more constant speed should the power supply fluctuate slightly. The motor is capable of sustaining an unloaded speed of 375 RPM (revolutions per minute) with a stall torque value of 0.9 N-cm (Newton centimetres). (Random Hall Robotics Seminar (2006)) 9

15 3.2 - Robotic Requirements Before any construction of the robot was undertaken, the basic requirements for its movement and behaviour needed to be considered. One of the most important factors which needed to be investigated were the possible methods of moving the robot around the pitch. The robot had to be able to move forwards and backwards at a reasonable speed ideally above 0.2M/s, as well as having the ability to turn sharply enough on the pitch to reach the ball at any position within a relatively short time. Ideally, the robot should be able to pivot on the spot, such that if it was utilising light based sensors for ball localisation, it would be able to scan the entire pitch in one movement. In general, there are three methods of locomotion for a robot this size. These are legs, tracks and wheels Locomotion Legs Legs were discounted from consideration almost immediately due to the complications involved with maintaining bipedal or quadruped movement. In the case of bipedal movement, the robot must have either a method of maintaining balance, which is an amazingly complicated task, as discovered by the engineers at Honda who have been working upon the Asimo bipedal robot for a number of years. An alternative method of bipedal locomotion is that demonstrated by J.P. Brown, who has constructed a walking robot, which relies on the limited movement of the legs, and large feet to maintain balance. Quadrupedal movement poses a different problem. The issue of balance is removed, of course by ensuring that three feet remain on the ground at any one time. However, to enable the robot to move forwards, backwards and for it to execute a turn would require a complex set of protocols governing the lift on each leg, as well as the size of arc which the leg describes. In addition to these problems, the limitations of the Lego Mindstorms kit ultimately eliminated this possibility. For the robot to move at a reasonable speed would require the legs to undergo large amounts of torque which would be likely to cause the components to rip themselves apart. Also, a minimum of two motors per leg would be required one for pivoting the leg forwards and backwards, and another to lift the leg at the critical juncture. This would equate to a minimum of eight motors in a quadrupedal robot, which would require 10

16 at least three RCX bricks to manage. This would equate to an incredibly large and heavy robot with inordinate battery consumption Caterpillar Tracks This method was also briefly considered before being discarded. As can be demonstrated in real-world caterpillar vehicles, the tracks do allow a high degree of mobility, as well as a zero radius turning circle. The Lego Mindstorms kit contains a set of rubber tracks which can be fitted over certain wheels, but unfortunately being rubber, they have a high amount of grip which requires large amounts of force to be imparted into the drive shafts in order to turn the robot. Once again, the limited nature of the Lego bricks would likely cause the drive cogs to shear, or the sprockets to come off the axles. (See appendix E.9) Wheels Ultimately it was decided that the robot should be fitted with wheels for a number of reasons. Firstly, the majority of the robot s operation needed to be performed on carpet, which would cause problems with tracks or walking robots. The Lego Mindstorms kit provides a wide variety of wheels with varying properties (See appendix E.10), one of which is a large wheel similar to that used by off road motorcycles. Its large radius meant that overcoming obstacles in the robots path such as a lump in the carpet, was not a problem. This would, however, require a higher amount of torque needing to be input into the drive system. It is also possible, dependant on the wheel positioning to execute zero radii turning circles with wheels Wheel Alignment There exist a number of different positions and alignments in which the wheels can be used on the robot. The two simplest methods are the car method and the wheelchair method The Car Method As can be assumed from the name, the car method is that which is used on modern motor vehicles. Either the front or rear wheels or both can be driven (but not independently), with the front wheels being pivoted using a rack and pinion system in order to effect steering. The radius of the turning circle of this method is proportional to the maximum angle which the wheels can pivot to. 11

17 Using Lego, the drive is limited to the rear wheels, since the components do not exist to connect a motor to the existing rack and pinion systems. In rear wheel drive systems, the maximum angle (regardless of the rack and pinion systems) can be no greater than approximately 80 degrees in either direction since in that situation the rear wheels are trying to impart a force in the direction off 0 degrees, whilst the tyres will be acting against this only allowing motion at 80 degrees. Hence the majority of the energy will be lost in tyre slippage, gear shearing and friction heat. If a steering of 90 degrees were possible with a Lego steering rack one could expect the wheels to snap off under the pressure The Wheelchair Method The wheelchair method relies on two large drive wheels and two smaller free pivoting wheels similar to castors. The larger wheels are independent from one another. In order to move in a straight line, both wheels are turned in the same direction, to turn to the left or right whilst moving, the left or right wheels are slowed respectively, with the factor of slowing determining the tightness of the turn. By turning the wheels in opposite directions, the vehicle will spin on the centre of the main axle with a zero radius. The second set of wheels are completely passive, and must be free pivoting, similar to the wheels found on shopping trollies. Figure 4 Comparison of the turning circles of the car method (left) and wheelchair method (right) of steering 12

18 3.5 - Drive Considerations The second requirement which was considered once the wheel architecture was decided, was how to impart drive to the wheels. The two main options were direct drive and dual differential drive Direct Drive The obvious solution would be to have two motors, one connected to one wheel, one to the other. These would allow all the degrees of control which would be required, but one major problem was discovered after creating the robot. This was that due to the varying number of revolutions which each motor had performed over its lifetime, the power output of each motor was slightly different. This meant that in trying to drive forwards in a straight line, the robot invariably veered to the left or right (depending upon which way round the motors were placed). One solution would be to record the amount of revolutions performed by each wheel, and ensure that they remained the same whilst driving in a straight line. This could be done using the rotation sensors which come as part of the Lego Mindstorms kit. However, this would utilise two of the sensor ports on the RCX brick, which at such an early stage was undesirable to commit to this method since it was possible that they would be needed for light sensors. In addition to this, a new set of code would have to be implemented to use this system Dual Differential Drive The other alternative was found in the project by C.Dodds (2005). The solution was to implement a dual differential (dualdiff) drive system. The basis of the dual differential uses, as the name suggests, two differentials in parallel to produce independent turning on two axles. Figure 5 A Lego Differential 13

19 The dualdiff system, as mentioned, relies on two differentials axles being connected with an odd number of cogs on one side, and an even number on the other side. One differentials axles are longer than the other in order to attach the driving wheels, whilst the other s are small and only have the connecting cogs attached. A motor is connected using a cog to the outer housing of each of the differentials. (See appendix E.8) Turning the motor connected to the differential with the long axles (motor A) will cause both the wheels to turn in the same direction. Turning the second motor (motor B) on its own will cause the wheels to spin in opposite directions. Turning both together at the same speed will cause one wheel to remain stationary and the other to spin at the combined speeds of both the wheels if they were moving. Hence one motor controls the drive imparted to the wheels, whilst the other determines the steering. The major benefit of such a system is that in when the drive motor is turned, the power is distributed evenly between the wheels, which eliminates the veering to the side which is observed in a direct drive set-up. There is however, a major problem associated with the dualdiff set-up. In a standard direct drive train, the torque generated by one motor is transferred directly to one wheel. In a dualdiff drive train, the torque applied by one motor is split between two motors. In a light robot, this would not prove a problem, but the combined weights of two motors and the RCX brick with batteries proves too much for the motor to move at a reasonable speed. In addition to this, the gears which come as part of the Lego Mindstorms kit do not fit perfectly together (assumedly to aid in construction). The result of this is that when large amounts of pressure are put into a gear system and there is a high amount of resistance (as in the case of a heavy robot), the gears are likely to slip or shear resulting in loss of drive and ultimately, the loss of the gears. 14

20 Chapter 4 Software Design and Implementation 4.1 Programming Languages As mentioned, there are a number of methods of programming the RCX brick as well as than those supplied with the Robotic Inventions System (RIS) The RIS Interface The RIS uses an interface which allows the most basic of commands to be programmed into the computer and then uploaded to the RCX. This method does not allow any sort of interaction on the robot s part, and is not easily integrated with other systems Not Quite C (NQC) The NQC language is based loosely around C. The advantage of this method of programming over other languages is that the NQC language will run upon the existing firmware on the RCX pbforth This is a replacement of the firmware on the RCX brick which is based upon the Forth programming language. One advantages of using PbForth is that it has relatively small memory requirements on the RCX (around 10k) leaving plenty of space for programs and storage (pbforth (2006)). pbforth also interprets and compiles the code on the RCX brick allowing plain text strings to be sent directly to the RCX which simplifies the process of programming. However, the fact that I have no experience with this programming language dictated that this method was not feasible for this project LeJOS LeJOS is another replacement for the firmware on the RCX which uses a simple version of the Java Virtual Machine which uses 16k of memory on the RCX. Although the memory requirements are larger than PbForth, for example, the benefits outweigh the disadvantages. There is a plethora of previous research available on LeJOS as well as a wide variety of 15

21 libraries and classes which allow easier expansion of the system. The major advantage of the LeJOS system is the availability of a pre-made vision system which was developed by Lawrie Griffiths. This package is further discussed in the section Which Language Was Chosen The system which was provided with the Robotic Invention System upon the most cursory investigation was discounted, since the system was nowhere near powerful to allow the degree of functionality required. PbForth was also rejected almost immediately. This was due to the fact that I have no experience whatsoever with the language which it is based upon, and I was unwilling to commit to learning a new language, with all the problems that this entails, on top of the somewhat onerous task of producing a passable report. It was decided initially, to use NQC as the primary method of programming the RCX (since I had previous experience programming in C), but after numerous unsuccessful attempts trying to establish a vision system, this language was abandoned. This left the LeJOS system, which came a close second in the initial deliberations on which language to adopt. The LeJOS system has a number of advantages attributed to its utilisation, not least that I have had some previous experience using it, as well as the fact that it is based upon Java, which in turn is based upon C with which I also have experience. The ultimate factor which precipitated the adoption of LeJOS over the other languages, was the ease at which the system interacts with cameras The LeJOS Vision System As mentioned, the LeJOS programming language is integratable with other systems, notably, Lawrie Griffith s vision system. A number of beneficial functions are available with this package including: A moving video display on your PC of what the robot sees Definition of regions in the field of view Flipping the image horizontally to fit the type of example best Detecting motion Detection of specific colours Light detection Taking snapshots Recording videos, including sound Playing sound files 16

22 Sending commands to the RCX GUI control of color and motion sensitivity, region display, etc. Extensibility of the GUI to allow remote control of the robot, etc. The remote control class can also support speech control of the robot (Griffith, L. (2004)) The vision system, as can be seen, allows the system to be fitted with a camera, which monitors the environment. This is a great advantage to this project since it was found that there were severe limitations to the light/ir sensors provided with the Lego Mindstorms kit. 4.2 PC to RCX Communication LeJOS comes with a package (josx.rcxcomm) allowing for simple and easily implemented communication between a Java program running on a pc and its counterpart running on the RCX brick. By configuring a port and using its input and output streams it was found to be relatively simple to send small packets of data in both directions. A remote control system was set up that used the base10 system to code integers in such a way as to be easily combine both a power settings and the directions desired to be attributed to the motors. I.e was used to represent forward motion of motors A and B at a power setting of five. Similarly 70 was used to represent full power to motor B to induce a left hand turn. Rotation sensors were attached to each wheel s axle and monitored (discussed later) and the resultant data was sent back from the RCX brick to the PC where further calculations to extrapolate the robot s position were made. 4.3 Ball Tracking The ball tracking systems and the self localisation systems were initially planned to be as one. However, events conspired against this plan, and the theory of using a roof mounted camera to spot the ball and identify its location had to be abandoned. However, instead of abandoning the effort invested in the vision system, it was decided to adapt it to be based on the robot instead. 17

23 4.3.1 The LeJOS Vision System Implementation Thankfully instead of having to create not only a robot and its control system but a vision system, there was already a vision system available which could perform all the desired tasks, with relatively few adaptations required. This package was the josx.vision package, which contains a number of pre-written methods for implementing a camera in the system. The system was adapted to have a series of twenty Jpanels, which show the average RGB values of the corresponding region in the camera s field of view. The first to the eighth panels correspond to left, the ninth to the twelfth are the middle, whilst the thirteenth to the twentieth boxes are right. Ultimately the simplicity of this method allowed the brightest region in the field of view to be determined. Not all bright things that the robot sees are the ball, and for this reason a threshold of a 4,000,000 was introduced to the RGB values which meant that only very bright things were selected as a target, not just the brightest in the field of view. Should the robot be unable to find a target in its initial view, it reverts to search mode. This causes the robot to make small steps either to the left or right. It continues to do this until a target above the threshold is acquired. After it has acquired the target, the robot pivots either left or right until the target is in the middle region of its field of view. Once this has been done, the moves forward at a reasonable pace. If the robot does not maintain a straight heading, and veers off to the side, the system records which side it last saw a bright object. Upon losing its target, the robot pivots in whichever direction the ball was seen in last. Once it has re-acquired a target, the robot moves forward to collect the ball Self Localisation There exist a number of methods of self localisation which fall into two main categories calculating via dead reckoning or calculating via visual input of the environment Dead Reckoning A way of figuring your position based upon the influence of such things as currents and wind upon your projected course and anticipated speed ( Originally a nautical term for the type of navigation employed when there are no points of reference (e.g. stars or land) available, dead reckoning can describe a similar method which is possible to implement on the robot. Firstly the circumference of the wheel is measured. The robot then records the number of turns which each wheel has made during the course of a movement with rotation sensors. It 18

24 can then combine the data and calculate the distance covered by each wheel. For example, a wheel with a circumference of 6 cm revolving 20 times will cover a distance of 120cm. However, the system becomes more complex when one wheel turns more than another, in the case of when the robot is following a curved path. In this case, instead of calculating using mathematical functions, it may be simpler to record the turns which the wheels have made and compare this to previous test data which records the number of turns and the resulting course change. This data can be combined with the robot s known original position to extrapolate a new coordinate and heading Navigation By Visual Sensory Input This type of navigation relies on the use of light sensors of varying types feeding information back to the robot. The light sensors may be only monochrome sensors, as in the case of the Lego light sensor, or colour sensors, as in the case of the camera. The way in which these sensors are positioned determines the type of navigation used. Navigation by Mat This method employed a downward facing sensor reading light values from a mat placed on the floor, which would yield different results depending on where on the mat the reading was taken from. A mat with a greyscale graduation from white to black will allow determination of an x coordinate and only requires the use of a Lego light sensor. Figure 6 An example of a monochrome mat 19

25 A mat with a colour graduation allows the identification of both an x and a y coordinate. In order to do this, however, the mat must have a specific colour layout where a particular colour occurs in one region of the mat, and no other. Figure 7 An example of a unique colour mat This method, of course, requires a downward facing extremely colour sensitive camera as well as a downwards facing light source which does not alter in its luminosity. By measuring the RGB value of the mat underneath the robot, and comparing this figure with a table of data attributing coordinates to RGB values, it would be possible for the robot to self localise. As the robot moves around the mat, it records its previous coordinate, and the current coordinate. By comparing these two pieces of data and some simple trigonometry, a heading can be extrapolated as well as the speed of the robot. Plan View This method requires for a good quality colour camera to be mounted above the pitch allowing it to see the whole field. The theory involves mounting differing coloured LEDs on top of each robot. The computer uses the camera to identify the coordinates of each of the different coloured light sources. By combining the knowledge of which colours belong to which robot, and their orientation, along with the moving coordinates of the light sources, it is possible to calculate the speed and headings of the robots and the ball. 20

26 Figure 8 An example of what a roof-mounted camera would see. Figure 9 What the system would interpret from the sensory data. (Arrows indicate robot headings) Which Method of Self Localisation Was Chosen and Why Initially, it was decided to implement the bird s eye view approach to self localisation and ball tracking. This was due to the desire to exceed the requirements of the project, which if any other method was used, would be much more difficult. Early signs were good, a system was developed which split the view from the camera into a grid, from which the system deciphered the location of the ball and robots. The initial system used a 4 x 4 grid, which although producing working results in preliminary tests, was not sufficiently accurate to identify a robot or ball from the distance required to see the whole pitch. The next step was to further divide the grid into smaller regions, which would allow more accuracy. A trial system, using a grid of 10 x 10 squares was produced, and tested. This also worked, but again the problem of insufficient accuracy was noticed. It was decided to use a grid of 20 x 20 regions, which would provide the necessary degree of accuracy. 21

27 However, the panel on the left was overlaid with a red outline of the grid as well as a set of red numbers corresponding to the grid reference of each region. These were being incorporated into the colour averages in the right hand panel, which was responsible for determining the brightest region. This produced a colour panel which was not taking into account all of the pixels of information being taken in by the camera, as well as having a pink hue. An attempt to compensate for this was made by subtracting a constant value from the returned value by the getavgred() method. This did produce the desired result of removing the pink tinge of the colour panel. However, the underlying problem remained. Not all of the pixels recorded by the camera were being used, as some were being overwritten by the grid and numbers. An attempt to trace the code, which produced the grid and numbers was made. The code being called was located in the javax.media package in Effect.java. Unfortunately though, the source code was not available from either The source code was advertised at but clicking on the link produced a web-page with no data. Attempts to access this page from other internet connections proved equally fruitless. An was sent to the webmaster requesting a copy of the source code, or for a repair to be effected upon the page, but no replies were received, nor was the page fixed. It was therefore decided, due to time constraints, to adapt the current system to the extent that the camera would be mounted on the robot, and the number of grid regions be lessened severely since the plane of view was only required to be one dimensional instead of two dimensional. This meant that a high degree of visual acuity could be implemented using less than 50 regions instead of the 400 used for the bird s eye view approach, allowing only the locating of the ball. Another method of self localisation had to be adopted. As the camera was being used for locating the ball (and the system would only support one camera), the next best option for self localisation the colour mat method was also an impossibility. This left the dead reckoning and greyscale mat approaches as feasible options. It was decided to use a combination of the two methods. This was because, although previous projects which have covered dead reckoning have proved it a reasonably accurate self localising system, the accuracy could be further improved by combining the dead reckoning data with real world data gleaned from the light sensor. A study was undertaken to measure the effectiveness of the light sensor at measuring the greyscale on the mat. The results were not inspiring however (See figure 10). Although the light sensor was able to distinguish the dark end from the light end successfully, the difference was nowhere near enough for the robot to accurately decipher its x position. The benefits of using this system were outweighed by the complications involved in integrating 22

28 this data into the dead reckoning calculations. This lead to the eventual rejection of this system in favour of using only dead reckoning for simplicities sake. Using Only Light Sensor Light Source Lowest 1 Notch Up 2 Notches Up 3 Notches Up 4 Notches Up White Black Using Additional Light Source Unmounted Mounted White Black Figure 10 Tables of results showing resultant light readings in varying conditions, on opposite ends of the greyscale mat 4.5 Self Localisation Implementation It was decided that the method of ascertaining a fix on the robot s position would be done by dead reckoning. It was initially thought that this could be done purely by measuring the number of rotations each wheel makes and calculating the distance travelled from that. However, an issue arose during testing which required a re-think on the method. With a 1:1 ratio of turns on the wheel to turns of the rotation sensor, the degree of accuracy in straight lines is within tolerable levels. When the robot made small steps right or left, however, no change was being registered in the rotation sensors, yet a course change of anywhere up to 6 degrees was made. This was an unacceptable degree of error, and it was decided to modify the connection to the rotation sensors so that there was a set of gears between, increasing the number of revolutions on the sensor per revolution of the wheel. This solved the problem of poor accuracy but raised a new problem in turn. Unfortunately, the calculations which extrapolated the number of turns made from the raw data were too CPU intensive, at high speeds, for the RCX to process. To combat this problem, the rotation sensors were reverted back to the 1:1 ratio, which left the question how do we know how much the robot had turned? The only solution left was a fairly brutish one. Work out the average angle made when the robot turns left for a specific period of time. Hard-code this figure into the calculations as a constant, and use it to calculate angles of turn from the number of steps made left or right. An example of the coordination extrapolation calculation are as follows. 23

29 (0,0) Robot moves forward 3 wheel rotations (each known to be say 10cm) 3 x 10 = 30, add this to x coordinate (10,0) Turn robot 2 steps to the right (each known to be say 5 degrees) 2 x 5 = 10 degree turn (10,0) Robot moves forward 4 wheel rotations 4 x 10 = 40, Laws of trigonometry state Add to x coordinate = 40 x sin10 Add to y coordinate = 40 x cos10 However, before this method was implemented, a bug in the code was discovered which explained the lack of accuracy when measuring the turn. Having assumed that the sensor output voltages were constant values, it was discovered that they were variable in nature depending on the strength of the power source. By comparing to a range of values, the code began to perform its desired function and accurate readouts were observed. A series of tests were carried out to assess the average amount by which the robot turned from a step left, and then a further step left, then a step right and a further step right. This data was incorporated into the dead reckoning system to allow vectors to be calculated, and hence distances travelled in terms of x and y. 24

30 Chapter 5 Testing A number of methods were developed for testing the robot, for each of the objectives stated in the initial specification Testing Methodologies Objective 1 A fully functional robot (without software), built from Lego, which is able to physically fulfil all the requirements which might be placed upon it. After a version of the robot had been built, its ability to move around the pitch was tested. This was done by programming the RCX brick with a simple set of instructions telling it to either move forwards, backwards, to spin, to turn and to stop. This program was executed, and the resulting movements were observed. This process was repeated many, many times, with varying results. As mentioned earlier, as little time as possible was spent on the construction of the robot, and once an acceptable robot was built, the process was terminated until such time as the requirements from the robot changed. The criteria for assessment were as follows: Speed The robot must have the ability to traverse the pitch at a good speed. Since at such an early stage, it was relatively difficult to ascertain what speed would be optimal for the robot to move at, it was decided that the robot should be able to move at a high speed at full power, with the option of stepping down the power sent to the motors in order to effect a lower speed. Turning The robot must have the ability to execute turns at a good speed. Once again, the optimal speed was unknown, so it was assumed that the ability to turn and spin fast would be the acid test. A rough time of around one second was required to execute a 90 degree turn. Durability The robot must be robust enough to withstand all forces placed upon it when the motors were run at full power. This included gear slippage, and general pitch worthiness. Pieces of Lego falling off the robot would be unacceptable. Placement of sensors should remain static such that if they were aimed at a particular angle, they should stay at said angle throughout the duration of a test. 25

31 Stability The robot must never topple over or have a loss of ground contact from its drive wheels (or steering wheels if applicable) at any time during the test Objective 2 A simple system which can be loaded onto the robot s RCX Microprocessor control brick, which instructs the robot to move around and respond to simple stimuli such as a button press. To an extent, this was included in the testing scheme for objective one. The testing method for such a simple system was straightforward to the point of being blatantly obvious. If the system moved the robot in the manner in which it was aimed to and responded to the switch presses without any extraneous results, the system passed the test Objective 3 A more complicated system which can be loaded onto the RCX brick, which, does as above, with the addition of the ability to respond to the stimuli of the Robocop ball. If this proves to be unfeasible, the Robocop ball will be replaced with a coloured ball which can be detected in objective 6 This objective was bypassed when it was discovered that the Lego light sensors sensitivity was so poor that the IR ball was not used and this section reverted to objective six Objective 4 A system which is able to control the robot via remote, using the Infra-Red USB tower Initial testing involved sending small amounts of data to the RCX brick which would be interpreted and displayed on the LCD screen. Once this had been achieved, and the next step in the process undertaken, the testing involved sending an instruction to the RCX brick and observing whether it behaved in the manner expected. For example, one of the first tests performed was whether it was possible to send an instruction from the computer via the IR tower, which made motor A turn for a pre-determined period of time. If this outcome did not occur, the system was investigated and appropriate changes were made. Once the robot was behaving in the manner expected, the test was considered to be passed, and the objective fulfilled. A further test was introduced to determine the range at which the data could effectively be sent. The results fluctuated somewhat depending on a number of conditions including the ambient light levels in the room, other IR interference such as television remotes, ambient 26

32 temperature, and the angle at which the RCX was placed from the IR tower. The acid test was the systems ability to transmit the data to all positions on the pitch without the need to move the IR tower. Without this ability there would be little point in trying to develop the IR control mechanism further Objective 5 A system which is able to track the movements of the robot(s) around the environment and is able to give an (X, Y) coordinate and a heading for the robot. A number of aspects of functionality needed to be tested with regards to this objective. Firstly, the robots ability to count wheel rotations was an important consideration. Without accurate data being received from the rotation sensors, positioned on each of the wheel axles, the process of dead reckoning would be impossible. A simple program was written for this purpose. This, when run on the RCX displayed the data being received from a rotation sensor plugged into port A. Each of the two rotation sensors was connected, in turn, and the wheel was revolved slowly through 360 degrees. The data was recorded and the results are shown in Appendix C.1 The next step was to implement a system which was able to count the number of revolutions which were put into a rotational sensor and show the figure on the screen. Once the system was producing results which were accurate, the rotation listener was considered to have passed its test. The next test was more of an enigma. By its very nature, dead reckoning is an inaccurate method of plotting, but a necessary evil in this project. It was therefore decided that a degree of flexibility should be allowed with this system. The method of testing was straightforward. The system which worked out the robots position was installed on the robot. The robot was then moved around the pitch randomly, including straight lines and turns in its path. The resultant dead reckoning coordinate was compared with the robot s actual coordinate. With a path of around a metre, an error of around 5 cm in either direction was accepted, but wildly inaccurate figures were not. Once the system was repeatedly able to produce a reasonable estimate of position, the test was considered passed Objective 6 A combination of the objectives 4 and 5, where a personal computer is able to identify the location of the robot and move it accordingly. For example, a system which will cause the robot to always move to the bottom right corner of the pitch. 27

33 The testing process for this objective was simply an extension of the previous testing methods. Instructions were sent to the robot which would cause it to move in the direction of the target area. As the robot moves, its position should be calculated by the system automatically. The system s instructions should counteract minor deviations in the robots course. The acid test for this objective was simple. Command the robot to move to a specific area on the pitch. Once the robot reports being at the position, measure its true location. A deviation of more than around 5% from the length of the path would be considered undesirable and would precipitate amendments to be made to the dead reckoning calculation system Objective 7 A system which uses all of the above, in addition to a set of programmable behaviours. The system will control the robot so that it collects the ball and delivers it to the goal. The obvious test for this objective, was whether or not the robot was able to perform the assigned task. If it was unable to carry out this behaviour, then the objective was not fulfilled. Should the robot fulfil the objective, then the next stage of testing would be to implement performance measures. The first measure of how the robot fairs, is the time in which it takes to perform this task on average. If the robot seems to be taking an inordinate amount of time to perform this task for example, 10 minutes, then the system should be altered. The second performance measure should be the number of steps the robot takes to perform the task. As was explained in the implementation section, the system was designed such that the robot makes small, calculated steps towards its goal. Therefore, the more efficient the system, the less steps the robot should take to complete the task. 28

34 Chapter 6 Evaluation 6.1 Implementing the Testing Methodologies Objective 1 Speed Acquiring a good speed for the robot caused few problems throughout its development. The motors were powerful enough to accelerate the robot to a top speed of approximately 0.8m/s, and responded as expected to different power levels. A power level of 1 was barely enough to make the robot move, but did so nonetheless. Turning The required turning speed of one revolution every 4 seconds was greatly exceeded, with an observed maximum turning speed of roughly one revolution per second. This was excessive considering the amount of time it took to communicate the stop command from the wireless tower, and so eventually a stepper method was implemented allowing greater control. As such, the stepper method was coded into the RCX brick for greater accuracy in timing, and at full power for 100ms the robot turned through 15 degrees. Durability Lego turned out to be a very successful building material. The few times anything fell off were usually as a result of smashing hard into the leg of a wardrobe or during a rebuild when its structural integrity was compromised. There was very little gear slippage unless the Lego had not been properly compressed after a rebuild, and the only sensors used were embedded so deep in the mechanics of the robot that there was no way in which they could become detached. Stability During testing and general experimentation, the robot was only seen to fall over once, when it negotiated a steep incline at an angle and tipped onto its side. At this point the RCX brick s position caused it to fall over completely. Apart from this obvious flaw, such terrain would not be expected and very rarely encountered on a football pitch (for obvious reasons) and as such was ignored. 29

35 However, the robot s design did have to be altered several times due to lateral instability causing a see-saw effect. This was eventually solved by placing the RCX brick (with a 6- battery payload) at the back of the robot and placing wheels underneath to carry the extra weight. It was also modified slightly on introduction of the camera to counterbalance the extra weight, but this took little time and was quite effective Objective 2 The simple system implemented earlier in the project performed entirely acceptable and was eventually extended to allow for remote control of the robot, utilising the LeJOS infrared tower. This was again very successful, and proved extremely useful in later testing of the CameraSense class and other debugging efforts. This is covered in more detail in section Objective 3 Having bypassed this objective earlier in the project, it was eventually decided that a better method of seeking the ball would be to mount the Lego camera on the front of the robot. Using the Vision class within the josx.vision package it was relatively pain free to devise a method of tracking the ball using regions of the camera window. Vertical panels were laid out horizontally across the vision pane and the average colour and brightness of each pane was used in an algorithm to detect the most likely location of the ball. Luckily the CCDs in the camera pick up infrared light as an extremely high source of energy and, therefore, brightness ultimately allowing for this implementation to perform better and far more efficiently than any other method Objective 4 The remote control aspect of the project relied heavily on the performance of the infrared tower included with the Lego set. Having set the tower to long-range transmission it was found that the encompassing area only allowed for transmission over a radius of approximately 4 metres. This was found to be sufficient for testing but had the robot been 30

36 made to perform on a pitch it would have had difficulty receiving and sending data successfully unless the pitch was scaled down by an excessive amount. The robot managed to receive, send and respond to data appropriately and as mentioned above did well when confronted with problems such as outside interference from other infrared appliances. It was clear that both the tower and the RCX brick had very intelligentlydesigned hardware that could cope with error-checking and missed packets, and it became apparent that the java code on both sides of the transmission would either transmit such data continually until it was acknowledged to have been received, or wait until it had received an appropriate packet. Before this became apparent several hours were lost in debugging efforts as to why the code wasn t working but eventually all transmissions and receiving efforts were correlated and future problems were dealt with appropriately Objective 5 The programs written to detect data from the rotation sensors was initially regarded as successful, although later it became apparent that whilst the output values were initially constant, the actual values depended heavily on the amount of power supplied from the RCX brick. As the batteries drained these values changed, and in some cases oscillated around a value very quickly, meaning that more complicated checks were necessary. Once the sensor listeners in the java code had been amended successfully the results were surprisingly good and further work went into developing a means of measuring the distance travelled and considerable effort was made to find a way of accurately mapping the robot s location from this data. Unfortunately the data gleaned from such sensors proved to be heavily inconsistent with that observed in the real world due to tyres slipping on the floor when too much power was applied and through various other factors, the most apparent being the forces applied through the USB lead which had to be held above the robot. The largest problem seemed to be that one motor was more powerful than the other, and this led to apparent torque differences; although both motors were turning at the same power in the same direction, one wheel provided more power and drove the robot to one side. Experiments were done in an attempt to find a way of correcting for this, and indeed the results eventually led to a method implemented in the final version of the code, but wild inaccuracies proved to remain despite rigorous attempts to dispose of them. 31

37 6.1.6 Objective 6 Due to the failure of all efforts involved with objective 5 and the resultant lack of data pertaining to its purpose, there was very little that could be done to secure a worthwhile evaluation of this objective. The error in the coordinates output from the system meant that after only a matter of seconds the difference in assumed location and the actual location could be anything from 0.2 metres to a metre. As such it was impossible to devise a method of directing the robot back to a starting position, or indeed any position Objective 7 Due to the success of the vision pane method of detecting the ball, the robot was perfectly capable of both finding and retrieving said ball. In the vast majority of tests it managed to find and intercept the ball in an average of 30 seconds, sometimes far less, and as such was deemed to have succeeded in this stage of operation. Depending on the placement of the ball the robot took on average 20 steps to locate and retrieve it, but due to a considerable lag in the time taken to execute and apply each step it would occasionally get lost, turn around completely, and begin again where it left off. This difficulty was assigned to the time taken to transmit commands and receive data from the rotation sensors, as well as a lack of ability to receive commands on the fly and interrupt any erroneous motion. Nonetheless, the robot was considered to perform well. 32

38 Chapter 7 - Expanding the Scope Increasing the Range For the scope of this project, the range of the IR tower was more than sufficient, but if the range were to be increased to use a full sized football pitch, the IR tower would be unable to transmit over this distance. However, It is possible to manufacturer a set of repeater units which can be mounted in various positions over the pitch which can transmit and repeat the Infra-Red data via cabling or further Infra-Red beams (K. Ladha (2006)) Improving the Vision In the initial design of the system, it was planned to use the camera mounted on the ceiling, and use a birds eye view to monitor the location of the ball and robot. This would allow the inclusion of more robots. This method of vision was indeed attempted with somewhat disappointing results. 7.3 Inclusion of Further Robots Another possible area for expansion, as mentioned earlier, was to introduce a number of robots onto the field. This method could be implemented in one of two ways. The first method was the one which was initially planned, using the above mounted camera to monitor the entire field, and everything contained within it. Unfortunately, as has been documented, this attempt proved unsuccessful with the time constraints, so this option was abandoned. The second method, which could be used to introduce further robots to the field, is to simply replicate the robot exactly, along with its onboard camera. Unfortunately, it was discovered that the LeJOS Vision System would only accept one camera at one time, and hence the only method of using two cameras would be to introduce a second computer which ran the same program. The next hurdle to overcome would be in the sending the instructions. Since the robots and the IR towers use identical frequencies, it would be necessary to differentiate the instructions for each robot. The current method of sending instructions, as mentioned, is by sending a four, three or two digit integer which is processed on the RCX to decipher what action is required. This could be 33

39 easily modified to introduce another variable determining the robot number which the instruction is intended for.. 34

40 References Books Baum, D (2000), Extreme Mindstorms An Advanced Guide to Lego Mindstorms, First Edition, Apress, Berkely, CA. Baum, D. (2002) A Definitive Guide to Lego Mindstorms, Second Edition. Apress, Berkely, CA. Deitel, H. & Deitel, P. (2004) Java How to Program (6th Edition) Prentice Hall Past Projects Barrett, A. (2004) Lego Mindstorms Robotic Football Final Year Project School of Computing, University of Leeds Cadley, D. (2005) Introducing Planning Final Year Project School of Computing, University of Leeds Dodds, C. (2005) Sensory Aided Lego Mindstorms Robotics Final Year Project School of Computing, University of Leeds 35

41 Online Resources Gasperi, M., (Publication Date Not Specified) Michael Gasperi s LEGO Mindstorms Sensor Input Page URL: [1 st May 2006] Griffith, L., (Publication Date Unspecified) LeJOS Vision System URL: [2 nd May 2006] Hempel, R., (2004) pbforth overview [27 th April 2006] Random Hall Robotics Seminar, M.I.T., (Publication Date Not Specified) Random Hall Robotics Seminar URL: [2 nd May 2006] RoboCup Organisation, (2006) RoboCup Official Site URL: [2 nd May 2006] Robotics Outreach Group, (Publication Date Not Specified) Embedded Systems and Desktop Robotics URL: [1 st May 2006] 36

42 School of Computing, Brown University, (Publication Date Not Specified) Sensors and Sensing URL: [2 nd May 2006] Soundforge, (2004) LeJOS Java for the RCX URL: [1 st May 2006] 37

43 Appendix A Project Reflections This project has proved to be somewhat erratic. Implementation, and attempts at further expansion have resulted in overwhelming success in some areas, as well as abject failure in others. What Went Well I had always expected this project to be a bumpy ride, with areas of extreme difficulty interlaced with areas of surprising simplicity. One such area was the vision system. From the very beginning, I expected the vision system implementation to be almost impossible for someone with my limited programming experience. I faced the challenge, however, and managed to implement the system with relatively few teething problems. What Went Badly I am acutely disappointed in the result of the bird s eye vision system. To have come so close to meeting the minimum requirements and exceeding them as well is a crushing blow. Without the red-grid problem, I would have not needed to revert to an archaic dead reckoning system for navigation, and could have used the time to introduce more functionality, better artificial intelligence, and more robots on the field at once. At the time of project inception, I did not realise that this system would be so crucial, and its non functionality could not be such a threat to the outcome. Room For Improvement? During the busy period at the beginning of the university year, the project was looked upon as a distant cloud on the horizon. Hence the amount of effort, which went into the planning, was not what I would consider, on reflection, to be adequate. If I had spent a little more time, for example, investigating the various software options, I would have realised that NQC would not have allowed me the same degrees of freedom which were presented by LeJOS. If I had worked with LeJOS from the very beginning, precious weeks worth of work would not have been wasted in a fruitless endeavour. As well as this, in setting up the project schedule, I had every intention of meeting my self imposed deadlines, but I allowed other pieces of coursework to take precedence over the project since they were due within days, and the project was not due for months. As time passed, I fell further and further behind my schedule, resulting in a last ditch scramble to finish the project over the Easter break and the following weeks up to the deadline. 38

44 This brinkmanship, from which I am a chronic sufferer, has plagued me throughout my university career, but until now has not threatened my degree prospects to such a startling level. Undoubtedly, in the last few weeks, I have worked harder than at any other point in my University career. I have also taken time to consider what I would have changed in my methodology if I was given a second opportunity to do this again. I would certainly spend a lot more time researching what other people have to say on the subject rather than what I think should be said. I found that with a little more effort, it is usually possible to find solutions to problems relatively quickly instead of trying to solve the problem on my own. To my dismay, I have found in some cases, what I spent many hours trying to get to work, was discussed already, along with the reasons why that theory was in impossibility. Advice for Students Reading this Project I think, given the chance, I would gladly go through this process again, as I believe that the lessons, which I have learned, would allow me to create not only a passable project, but an outstanding project. However, that is not to say that I have left the project with only negative comments to make. Never before have I been required to create such an in-depth report, and throughout the process, I have learned things which I would never have learned by merely completing and submitting coursework. In a way, this has been the most enjoyable piece of work which I have had the opportunity to do. I had chosen a subject matter which appealed to me, and I was lucky enough to be offered the project. Some of my contemporaries have not been so lucky. Some chose their projects merely from the title, and did not consider the consequences. Subsequently, they forced themselves effectively, to commit hundreds of hours of work time to something which they have little or no interest in. I conclude this reflection with two pieces of advice for students who may read this in the future. Stick to your deadlines! You are asked to make them for a very, very good reason. And also, if it is not too late already, Make sure you choose something that you want to do, and if there isn t anything on the suggestions list that suits you, design your own project. You will be committing an entire year of study to this project, and the work is so much easier if you enjoy it! 39

45 Appendix B Source Code Camerasense.java package LejosFYP; import java.awt.*; import javax.swing.*; import javax.swing.border.*; public class CameraSense implements ColorListener public static final int NUM_BOXES = 20; private static final int x_dimension = 320; private static final int y_dimension = 240; private static double[] multiplier; private static double fwddistance, heading, x, y; private static int[] steps; private static int x_step; private static JPanel targetpanel = new JPanel(); // create a colour panel to display the average colours private static JPanel[] colourpanel; private static JLabel brightest; public CameraSense() // Compute x_step try x_step = x_dimension / NUM_BOXES; catch (Exception e) System.out.println("x_step is not an integer"); multiplier = new double[2]; fwddistance = 0; heading = 0; x = 0; y = 0; // Set up the target panel targetpanel.setbackground(color.black); targetpanel.setlayout(new BorderLayout()); JPanel currentcolours = new JPanel(new GridLayout(1, NUM_BOXES)); // identify the colour regions in the field of view currentcolours.setsize(x_dimension, y_dimension); colourpanel = new JPanel[NUM_BOXES]; for (int i = 0; i < NUM_BOXES; i++) 40

46 colourpanel[i] = colourpanel(); // Set up the average colour regions seen by the camera currentcolours.add(colourpanel[i]); brightest = new JLabel("Brightest Region: "); brightest.setalignmentx(jlabel.center_alignment); brightest.setforeground(color.white); // Put the colour displays on the Panel targetpanel.add(brightest, BorderLayout.NORTH); targetpanel.add(currentcolours, BorderLayout.CENTER); // Create a panel that displays the target colour private JPanel colourpanel() JPanel colourpanel = new JPanel(); Border border = BorderFactory.createLineBorder(Color.white,1); colourpanel.setborder(border); // Set a minimum width for the color panels colourpanel.add(new JLabel(" ")); return colourpanel; public static void changeangle() /* System.out.print(steps[0]); System.out.print(" "); System.out.print(steps[1]); System.out.print(": "); */ heading += steps[0] * multiplier[0]; heading -= steps[1] * multiplier[1]; if (heading < 0) heading += 360; if (heading > 360) heading -= 360; degrees"); System.out.println("Heading: " + String.valueOf(heading).substring(0, 3) + " // Average steps forward * wheel circumference / 16 -> 16ths of a turn fwddistance = ((steps[0] + steps[1]) / 2) * (275 / 16.0); x += fwddistance * Math.sin(heading * (Math.PI / 180)); y += fwddistance * Math.cos(heading * (Math.PI / 180)); System.out.print("Coordinates (roughly in metres): "); System.out.print(String.valueOf(x / 1000).substring(0, 4) + ", "); 41

47 System.out.println(String.valueOf(y / 1000).substring(0, 4)); public void colordetected(int region, int Color) public static void main(string [] args) // Create an instance of this class for listening CameraSense listener = new CameraSense(); Vision.setImageSize(x_dimension, y_dimension); int[][] coords = new int[num_boxes][2]; int counter = 0; for (int x = 0; x < x_dimension; x += x_step) coords[counter][0] = x; //coords[counter][1] = y; counter++; for (int i = 0; i < NUM_BOXES; i++) Vision.addRectRegion(i+1, coords[i][0], 0, x_step, y_dimension); Vision.addColorListener(i+1, listener, 0); // look for target colour // Create the viewer and set its title Vision.startViewer("Camera Viewer"); // Get the frame and add the Target Finder and colour components Frame visionframe = Vision.getFrame(); visionframe.add("east", targetpanel); visionframe.pack(); visionframe.setvisible(true); // Continually update the current colour panels int[] panelval = new int[num_boxes]; int max = 0, region = 0; for(;;) for (int i = 0; i < NUM_BOXES; i++) panelval[i] = Vision.getAvgRGB(i+1); colourpanel[i].setbackground(new Color(panelVal[i])); colourpanel[i].revalidate(); for (int i = 0; i < NUM_BOXES; i++) if (panelval[i] < ) 42

48 continue; if (panelval[i] > max) max = panelval[i]; region = i+1; if (max == 0) PC.stop(); if (region < 11) PC.search(0); if (region > 10) PC.search(1); steps = PC.read(); multiplier[0] = 7.05; multiplier[1] = 5.55; changeangle(); String.valueOf(region)); else brightest.settext("searching..."); continue; brightest.settext("brightest Region: " + max = 0; if (region < 9) steps = PC.lft(7, ((10-region)/4)+1); multiplier[0] = 7.05; multiplier[1] = 5.55; changeangle(); else if (region > 8 && region < 13) steps = PC.fwd(7, 1); multiplier[0] = 5.95; multiplier[1] = 5.55; changeangle(); else if (region > 12) steps = PC.rht(7, ((region-11)/4)+1); multiplier[0] = 7.05; multiplier[1] = 5.55; changeangle(); else PC.stop(); try 43

49 Thread.sleep(100); catch (Exception e) Brick.java import josx.platform.rcx.*; import josx.rcxcomm.*; import java.io.*; public class Brick private static final int START = 100; private static DataInputStream in; private static DataOutputStream out; private static RCXPort port; private static int left, right; public static void main(string[] args) LLC.setRangeLong(); try port = new RCXPort(); catch (IOException e) System.exit(1); in = new DataInputStream(port.getInputStream()); out = new DataOutputStream(port.getOutputStream()); Sensor.S1.activate(); Sensor.S2.activate(); left = START; right = START; Sensor.S1.addSensorListener(new SensorListener() public void statechanged(sensor arg0, int arg1, int arg2) if (arg2 < 5) if (arg1 > 35 && arg1 < 45) left++; else if (arg1 > 70 && arg1 < 85) left--; if (arg2 > 70 && arg2 < 85) 44

50 ); if (arg1 < 5) left++; else if (arg1 == 100) left--; if (arg2 > 90) if (arg1 > 70 && arg1 < 85) left++; else if (arg1 > 35 && arg1 < 45) left--; if (arg2 > 35 && arg2 < 45) if (arg1 > 90) left++; else if (arg1 < 5) left--; Sensor.S2.addSensorListener(new SensorListener() public void statechanged(sensor arg0, int arg1, int arg2) if (arg2 < 5) if (arg1 > 35 && arg1 < 45) right++; else if (arg1 > 70 && arg1 < 85) right--; if (arg2 > 70 && arg2 < 85) if (arg1 < 5) right++; else if (arg1 == 100) right--; if (arg2 > 90) if (arg1 > 70 && arg1 < 85) right++; else if (arg1 > 35 && arg1 < 45) right--; if (arg2 > 35 && arg2 < 45) if (arg1 > 90) right++; else if (arg1 < 5) right--; 45

51 ); recv(); private static void recv() int f, b, l, r; try while (true) int val = in.readint(); f = val / 1000; val -= (val / 1000) * 1000; b = val / 100; val -= (val / 100) * 100; l = val / 10; val -= (val / 10) * 10; r = val; Motor.A.stop(); Motor.B.stop(); Motor.C.stop(); if (f == 0 && b == 0 && l == 0 && r == 0) continue; if (l == 8) search(0); continue; if (r == 8) search(1); continue; left = START; right = START; if (f > 0) Motor.A.setPower(f); Motor.B.setPower(f); Motor.A.forward(); Motor.B.forward(); try Thread.sleep(500); 46

52 catch (InterruptedException e) Motor.A.stop(); Motor.B.stop(); if (b > 0) Motor.A.setPower(b); Motor.B.setPower(b); Motor.A.backward(); Motor.B.backward(); try Thread.sleep(500); catch (InterruptedException e) Motor.A.stop(); Motor.B.stop(); if (l > 0) Motor.B.setPower(r); Motor.B.forward(); try Thread.sleep(50); catch (InterruptedException e) Motor.B.stop(); if (r > 0) Motor.A.setPower(l); Motor.A.forward(); try Thread.sleep(50); catch (InterruptedException e) Motor.A.stop(); out.write(left); out.write(right); catch (java.io.ioexception ioe) LCD.showNumber(8888); try 47

53 Thread.sleep(5000); catch (Exception e) System.exit(0); private static void search(int dir) Motor.A.setPower(7); Motor.B.setPower(7); left = START; right = START; try if (dir == 0) //left Motor.B.forward(); Thread.sleep(100); Motor.B.stop(); else //right Motor.A.forward(); Thread.sleep(100); Motor.A.stop(); out.write(left); out.write(right); catch (Exception ie) RotationTestAdvanced.java import josx.platform.rcx.*; public class RotationTestAdvanced private static int left; public static void main(string[] args) Sensor.S1.activate(); left = 0; arg2) Sensor.S1.addSensorListener(new SensorListener() public void statechanged(sensor arg0, int arg1, int 48

54 ); if (arg2 < 5) if (arg1 > 35 && arg1 < 45) left++; else if (arg1 > 70 && arg1 < 85) left--; if (arg2 > 70 && arg2 < 85) if (arg1 < 5) left++; else if (arg1 == 100) left--; if (arg2 > 90) if (arg1 > 70 && arg1 < 85) left++; else if (arg1 > 35 && arg1 < 45) left--; if (arg2 > 35 && arg2 < 45) if (arg1 > 90) left++; else if (arg1 < 5) left--; while (true) LCD.showNumber(left); 49

55 Appendix C Test Results C.1 Rotation Test Results Fraction of full turn LCD Value

56 C.2 Turning Angle Results and Analysis Left Once Left Again Right Once Right Again Revolution L Revolution LL Revolution R Revolution RR (Degrees) (Degrees) (Degrees) (Degrees) (Sensor Turns) (Sensor Turns) (Sensor Turns) (Sensor Turns) Left Left Again Right Right Again Degrees/Turn Degrees/Turn Degrees/Turn Degrees/Turn B is weak. A is stronger. 51

57 Appendix E Photographs and Images Figure E.1 The Lego Mindstorms RCX Brick Figure E.2 The Lego Mindstorms Light/IR Sensor Figure E.3 The Lego Mindstorms Touch Sensor 52

58 Figure E.4 The Lego Mindstorms Rotation Sensor Figure E.5 The Lego Mindstorms Motor Figure E.6 The Lego Mindstorms Infra Red Tower 53

59 Figure E.7 An example of a Lego differential gearing system Figure E.8 An example of a dual differential gearing system Figure E.9 The Lego Mindstorms caterpillar track and cogs 54

60 Figure E.10 The selection of Lego wheels available Figure E.11 The Infra Red Ball 55

61 Lego Mindstorms Robotic Football Figure E.12 The Vision System with pink-tinge problem. Tracking testing being performed using a bright blue LED Figure E.13 The Vision System with colour correction installed. Tracking testing being performed using a bright blue LED. 56

62 Figure E.14 The Finished Robot (Side View) Figure E.15 The Finished Robot (Front View) 57