Lego Mindstorms Robotic Football John Russell Dowson Computer Science 2002/2003

Transcription

1 Lego Mindstorms Robotic Football John Russell Dowson Computer Science 2002/2003 The candidate confirms that the work submitted is their own and the appropriate credit has been 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 be considered as plagiarism. (Signature of student)

2 Summary This report covers the process of my final year project. The aim was to design and build a robot capable of demonstrating a number of key footballing skills, which would eventually allow it to compete in a game of RoboCup Junior. A set of minimum requirements was laid out at the start of the project. Unfortunately, due to hardware restrictions, the first minimum requirement had to be slightly altered. The updated list follows: Design and build a mobile robot using the Lego Mindstorms kit, able to sense the presence of an infrared ball. Program the robot so to be able to participate in a game of Robocup Junior by performing a reasonable number (at least three) of the following: o Identify its location on the pitch o Identify its present heading with respect to pitch orientation o Travel to a specified location on the pitch o Locate an infra-red football o Identify contact with the edge of the pitch o Identify contact with the corner of the pitch o Is able to detect and signal if stuck (not moving for a set period) o Identify the opponents goal o Is able to travel to the ball (having already located it) o Is able to kick the ball o Dribble the ball (i.e. move with it) o Dribble the ball into the opponents goal o Shoot the ball towards the opposing goal o Investigate message passing between robots & possibly a central computer o Identify presence of another robot o Identify location of another robot o Calibrate light sensors to ambient lighting conditions Evaluate success of chosen tasks under different environmental conditions. All of these minimum requirements were met. Several other extended requirements were set, two of which were achieved. These were as follows: Modify and program the robot so it is able to play in a wider variety of environmental conditions. Program the robot to use a wider variety of tactics for use in the Robocup game i

3 Acknowledgements I would like to thank Tony Cohn for all his help and sound advice throughout this project. The weekly group meetings have been invaluable both in terms of helping me stay on track and increasing my self-confidence. ii

4 Table of Contents Summary... i Acknowledgements... ii Table of Contents...iii Table of Figures... vi Chapter 1 Introduction The Problem Motivation Project Aim and Objectives Organisation of Report... 2 Chapter 2 Background RoboCup RoboCup Junior Lego Mindstorms RCX Sensors Programming RCX Code NQC ROBOLAB BrickOS Preferred Choice Robot Locomotion and Turning Similar Projects Datalog... 9 Chapter 3 Task Design The Robotic Footballer Development Process Chapter 4 Robot Design Programming Limitations of NQC iii

5 4.1.2 Movement Footballing Tasks Locating the Ball Making for the Ball Collecting the Ball Scoring a Goal Robot Navigation Dead Reckoning Distance Travelled and Orientation Calibration Mathematics of Dead-Reckoning Mathematics of Moving to another Point NQC Maths Mechanical Chassis Sensors The Grabber Chapter 5 Implementation of Design Straight Line Driving Ball Scanning Successful Collection Improved Turning Sine, Cosine and Inverse Tangent Functions Navigation Technique Wall Avoiding Mechanical Rotation Sensor Ball Sensor The Grabber Chapter 6 Evaluation The Project Dead-Reckoning Navigation RoboCup Junior Tactics Different Environmental Conditions Lighting Conditions Different Surfaces iv

6 Chapter 7 Conclusion and Further Work Mechanical Construction Dual-Differential Drive Ambient Light Calibration Better Navigation Competing in RoboCup Junior Teaming up Bibliography Appendix A Appendix B Appendix C v

7 Table of Figures Figure 1 - RoboCup Junior pitch for one versus one game... 4 Figure 2 - Table of Lego Mindstorms Sensors... 6 Figure 3 - Dual-Differential Drive... 8 Figure 4 - Robot shooting method Figure 5 - Measurement of Orientation Figure 6 - Pitch represented in 2D coordinates Figure 7 - Dead-Reckoning Diagram Figure 8 - Inverse Tangent Diagrams Figure 9 - Sine wave in four quadrants Figure 10 - Sine and Cosine Wave Figure 11 - Gathering ball with Pincer-like Grabber Figure 12 - Ball Scanning Test Figure 13 - Ball scanning results using no ball (ambient light) Figure 14 - Ball scanning results using position Figure 15 - Ball scanning results using position Figure 16 - Ball scanning positions Figure 17 - Turning clockwise is not always the shortest way to turn Figure 18 - Dividing up the Sine function Figure 19 - Sine Function Lookup Table...33 Figure 20 - Inverse Tangent Lookup Table Figure 21 - Wall avoiding technique Figure 22 - NQC Code: Definitions Figure 23 - NQC Code: Task Main Figure 24 - NQC Code: Set-up Function Figure 25 - NQC Code: Function that makes the robot drive forwards in a straight line Figure 26 - NQC Code: Function that makes the robot perform an anti-clockwise turn Figure 27 - NQC Code: Function that makes robot travel to a specific point on the pitch Figure 28 - NQC Code: Function that begins locating the ball Figure 29 - NQC Code: Function that makes the robot rotate whilst scanning for the ball Figure 30 - NQC Code: Task that reads the light sensor every 5ms, recording the brightest reading. 54 Figure 31 - NQC Code: Function that turns robot to face the ball Figure 32 - NQC Code: Function that drives robot forward until the ball is detected Figure 33 - NQC Code: Goal Scoring Function Figure 34 - NQC Code: Sine/Cosine Function vi

8 Figure 35 - NQC Code: Square Root Function Figure 36 - NQC Code: Inverse Tangent Function Figure 37 - View from above the robot Figure 38 - Side view of the robot Figure 39 - Front view of the robot Figure 40 - Bottom view of the robot Figure 41 - Top-down view of the robot with the ball vii

9 Chapter 1 Introduction 1.1 The Problem The problem that this project shall cover is to create a robot, which will not only model the actions of a real footballer, but will be able to compete against another robot in a game of RoboCup Junior. The robot is to be built using the Lego Mindstorms set of bricks, which includes motors, sensors, and a programmable brick, the RCX. 1.2 Motivation This project was my first choice. Football is one of my favourite sports and the opportunity to work in this area as well as artificial intelligence was too good to waste. Having taken many artificial intelligence modules here in Leeds University, I felt that my background in this area and in programming was ideal experience to undertake such a project. 1.3 Project Aim and Objectives The aim of this project is to design and build a robot out of Lego, which models the actions of a real footballer. It must be able to demonstrate a number of key footballing skills, which will enable it to compete in a game of RoboCup Junior. To help reach this aim some achievable objectives to target throughout the project: Investigate capabilities and limitations of Lego Mindstorms Choose environment/platform to be used when programming the robot Design, build and program a robot capable of performing a specific football-related task Modify the robot (if necessary) and program it to carry out three or more of the footballing tasks listed in the minimum requirements. Evaluate the robot under different environmental conditions Modify the robot (if necessary) and program it to be able to compete against another robot in a game of RoboCup Junior. 1

10 1.4 Organisation of Report This report has been structured to reflect the way it was covered throughout the last year. The next chapter, Background, gives the relevant background research covered for this project and used in later sections. Then, the tasks that I wish the robot to perform, before the design and implementation chapters, will be designed. 2

11 Chapter 2 Background This chapter gives a summary of the relevant background research covered for this project. It includes information regarding RoboCup Junior, the Lego Mindstorms set from which the robot shall be built, ways in which the robot can be programmed and lessons learnt from similar work covered in this area. 2.1 RoboCup The Robot World Cup initiative (Robocup) is an attempt to foster AI and intelligent robotics research by providing a uniform task, the game of soccer [8]. The first Robocup was held in 1998 and has been an annual event ever since, the most recent being RoboCup-2002 held in Fukuoka, Japan. There are many different leagues to enter depending on the type and size of the robot. The league that is most relevant to this project is the small size robot league [11] due to the size restrictions. A game in this league involves two teams of five robots competing against one another. The emphasis is more on high-level design i.e. multi-agent cooperation. The winning team of the small-size league CMUnited used a simple passing system involving one of the robots moving behind the ball and knocking it towards the target [11]. Since many teams entering this small-size competition used an overhead camera attached to an off-field PC then they adopted the approach of predicting where the ball was going. This enabled passing to a robot, which could time its run in order to intercept the ball [17]. Small-size Team TPOTs [16] built their robot well balanced and to the physical limit in order to be more effective in controlling the ball [16] RoboCup Junior The smaller version of Robocup is Robocup Junior. This is aimed at the educational end for younger students. It involves building much smaller robots than those used in the Robocup competition. There are several competitions in which robots can compete. One of these is soccer. There are two variations, one versus one and two versus two. The latter is more challenging due to the requirement of the robots to behave as a team unit rather than individually. The robots are built out of Lego and usually given simple designs such as the three-wheeled robot. The most recent Robocup Junior event was RoboCup Junior As the robot will be designed and built to compete in RoboCup Junior then its rules and restrictions shall be taken into account. A notable rule states The robot height must be 22cm or less. [12]. Therefore it is essential that these rules be taken into account prior to the design and building of the robot. 3

12 The pitch used in the Robocup junior competition is based on that of a real soccer pitch. Two halves, two goals et cetra. However, the pitch in RoboCup Junior 2002 is designed to aid the robots navigation. The sidewalls are painted black whilst the goals are painted light grey. Robots can then be programmed to distinguish between the two using a light sensor. In order to help robots know what direction they are pointing in (i.e. what goal they are facing) the floor is covered with a printed greyscale that has a perfect gradient from black to white. In terms of size, there are two variations depending on which type of game is being played. For a one versus one game, the size is approximately 87cm by 119cm (see Figure 1), whilst a two versus two is about 122cm by 183cm [12]. At each corner of the pitch are corner pieces. These prevent robots getting stuck at a right-angled corner. Figure 1 shows five neutral spots at certain positions on the pitch. These were used in RoboCup Junior 2002 as points at which the referee can place the bots in case of interrupt. Figure 1 - RoboCup Junior pitch for one versus one game Each robot in a game of RoboCup Junior scores goals by placing an 8cm diameter ball into the opposition s goal. The ball aids the robots in locate it by emitting infrared light. The outer shell is transparent plastic, inside are many infrared diodes lit by an internal rechargeable battery. RoboCup Junior entrants tend to employ the use of a light sensor. These can detect light in the infrared spectrum and therefore enable the robot to sense the presence of the ball. 2.2 Lego Mindstorms The Lego Mindstorms set is similar to previous Lego sets. It contains simple pieces that connect easily to each other. What sets it apart is the programmable RCX brick. This allows you to construct a Lego model that not only moves but also senses its environment. This is achieved by connecting motors and various sensors to the RCX input ports. 4

13 2.2.1 RCX The RCX is the brain of any Lego Mindstorms model. It is programmable from a PC using an IR interface (via either serial or USB) allowing a user to customise how their model behaves. The RCX has three output ports (A, B and C) which can be connected to motors, lights et cetra. It also has three sensor ports, each of which can accommodate a sensor. It has a small LCD screen from which you can see real time inputs from the sensors. The RCX is actually a tiny computer. It contains a CPU and 16K of internal ROM, which is pre-programmed with some low-level operating system software [1, pp18-19]. It also contains 32K of static RAM that is occupied by the firmware. This firmware is downloaded to the RCX the first time it is turned on. Its purpose is to interpret the byte codes of a program for the CPU to execute. Some programming environments require their own custom firmware to be downloaded to the RCX in order to enhance its capabilities e.g. brickos. Only 6K in the RCX s RAM is reserved for programs. Although this does not sound much it is more than adequate since programs are thousands of times of smaller than desktop programs [1, pp18-19] Sensors There are four types of sensor that can be connected to the RCX: touch, light, rotation and temperature. Since each of these is unique, the RCX must configure each port before it can be used properly. The RCX is able to interpret a raw value from a sensor by reading its voltage level. It then converts this to both a Boolean value and a processed value [1, pp22]. This gives the intensity at the sensor. For example, if a bright light is shone at the light sensor, the intensity will be high. Sensor ports can also be overloaded with a Boolean sensor and analogue sensor. For example, a light sensor is overloaded with a touch sensor. When the touch sensor is pressed, the RCX reads a one hundred percent light intensity reading. Figure 2 describes each of the main features of the sensors included with the Lego Mindstorms kit. 5

14 Sensor Type Touch Light Rotation Features detects when pressed used in Boolean mode 1 is pressed, 0 otherwise easy to overload with other touch sensors responds to incoming light typically used in percentage mode range is 0-100, are typical values placement of sensor is important so to avoid shadows and small nearby light measures relative rotation starts in base position 0 and increments for every revolution can be reset to make current position into the base position increases value in one direction and decreases in the other Figure 2 - Table of Lego Mindstorms Sensors 2.3 Programming To make the robot perform any desired operations, it must be programmed how to behave and act. There exist a number of different tools that can be used to program the RCX. This section looks at some of the more popular ones and concludes by choosing which one will be adopted for this project RCX Code The Lego Mindstorms kit includes software to develop programs for the RCX. This uses a graphical user interface, which runs under Windows, called RCX Code. It uses a simple drag and drop system where the user places bits of code under each sensor or output device. This is sufficient for a novice programmer to implement their designs however it can be a bit tedious and restrictive for a more experienced one NQC NQC (which stands for Not Quite C ) is a simple language that has similar syntax to C and C++. It is available on Windows, Linux and other platforms. What makes this so powerful is the fact it is not restricted like RCX Code, as it has no GUI. During my two and a half years at university I have learnt 6

15 to program at a proficient level in C++, therefore NQC would be an ideal choice. NQC was created by David Baum and has its own homepage full of updates and links to other Lego Mindstorms sites [2]. Programs can be created in any text editor (e.g. notepad in Windows) then downloaded into the RCX brick using commands in MS-DOS. A recommended environment in which to write, compile and download programs is the wrapper BricxCC [4]. This uses a very simple user-interface with syntax highlighting, similar to Gvim. It also allows the user to download the program to the RCX, rather than having to use the command-line approach ROBOLAB Like RCX Code, ROBOLAB adopts a graphical user interface. Developed by Lego, it is aimed at the classroom rather than the home [14]. In ROBOLAB this powerful, real life professional software is made accessible for children [9]. Compared to RCX Code it is much more desirable as it contains more features including a full set of tools for capturing and analyzing the datalog. Again though, due mainly to the GUI, it is much more restrictive when compared to NQC BrickOS BrickOS is an alternative operating system for the Lego Mindstorms RCX Controller [5]. It completely replaces the firmware with its own custom version, making the RCX a new operating system. It then becomes a very powerful tool as the user has complete control over the RCX. Programs can be in either C or C++. However the most recent versions of the software are only test releases and even the installation procedure warns of potential PC crashes Preferred Choice After some brief experience with all the above programming languages/environments, it was decided to use NQC along with the BricxCC wrapper through the project. As already stated NQC is very similar to C++ and therefore is most suitable. Learning some new commands for controlling sensors and motors should be relatively easy. The BricxCC wrapper is excellent for writing and managing programs. It also allows you to control the RCX directly so testing certain features can be done without the need for a new program to be downloaded. The speed at which programs can be written and downloaded will mean the process is much quicker and frees up more time to develop new ideas. 7

16 2.4 Robot Locomotion and Turning There are several approaches to making the robot move. The common ones used in Robocup Junior entries are wheeled, tracked and legged, of which the former two are most popular. The legged robot will not be considered due to its complex nature and engineering skills required. Compared to wheeled robots, the tracked robots have a few disadvantages. Two of these are: the track supplied with the Lego kit restricts the size of the robot, and, the process of the treads moving around the hubs involves a significant amount of friction; hence some of the motor s energy is wasted [1, pp197]. Of course there are two variations of the wheeled robot, the three-wheeler and the four-wheeler. The most popular and simple one is the three-wheeled approach. The basic design is two drive wheels at the rear, each powered by a separate motor, and a single swivel wheel for balance. Steering is accomplished by varying the speeds of the drive wheels, Very tight turns can be made by running wheels in opposite directions [1, pp197]. This would enable the robot to almost turn on the spot, which will be important when scanning for the ball, The scanning behaviour can be achieved by getting the robot to turn, ideally on the spot, [13]. The four-wheeled approach would use a rack and pinion steering mechanism, used in virtually all automobiles. The drawback is that the robot would not be unable to turn on the spot, rather more in an arc. Instead of using independent motors, one driving each side of the robot, a dual-differential drive could be built. This again uses two motors but in a much different way. One motor controls forwards and backwards movement whilst the other controls turning movements. The main advantages of using such a technique are that it does very well holding a straight line [7] and easily supports a single rotation sensor for more accurate position measurement [7]. To build the drive two special Lego gears called differentials are required. The problem is only one of these pieces is included within each Lego Mindstorms set so a dual-differential drive can only be built if another one can be obtained. The drive is somewhat complex to build (see Figure 3) and will therefore constrain the physical design of the robot if implemented. Figure 3 - Dual-Differential Drive 8

17 2.5 Similar Projects Last year, some students conducted similar robotic football projects to this one. Their reports contain useful experience and advice that should be taken on board. In one project, the robot calculated where it was on the pitch by calculating how far it had moved since it started. However, a problem with this estimation was the NQC programming language, The main problem with this approach is that NCQ does not have a maths file, and therefore does not have functions for evaluating sine and cosine [6, pp19]. This student managed overcome this be implementing his own trigonometry functions but found them to be inaccurate. Since the robot shall run on a greyscale pitch, this can be used to help determine which goal is which rather than just implementing the trigonometry functions. From the same project, the student used a clever control arm at the front of his robot. This arm helped the robot when controlling the ball whilst turning [6, pp24]. Although there is no initial design, it is likely that a similar approach will be required in this project to collect the ball and turn without loosing it. Finally, it is interesting to note that this student based their design on one in the Lego Mindstorms example book. He built the basic chassis with slight modifications and added the control arm and sensors. A similar method shall be adopted due to the time and hardware constraints in the project and Lego Mindstorms kit respectively. In order to get the robot to perform the basic task of searching for the ball, Matthew Goddard found a simple search technique in which the robot would rotate clockwise on the spot with a light sensor attached. This light sensor is given a threshold value which, when breached, means the robot is facing the ball. On their website, RoboCup Junior Australia provides a series of instructions for building a robot designed for participating in a game of RoboCup Junior [15]. This design could be used as a starting point when building the robot in order to save time on the engineering side of the project. The design also includes a light sensor on the robot for the purposes of sensing the infrared ball. It will be very likely the robot will require the same skill and therefore will be a good idea if the robot used the same placement for its light sensor. 2.6 Datalog The RCX has an in-built feature called a datalog. The datalog allows the RCX to record data (from sensors) which can later be uploaded to a computer [1, pp295]. The ability to record data will be especially useful for debugging and experimenting with the robot. Programming the RCX using NQC is the only way to perform data logging. In terms of syntax, the instruction to record a sensor reading is very short and therefore can be easily added to existing programs. BricxCC, the NQC wrapper mention in section 2.3.3, provides a useful tool for downloading and analysing the datalog. Data can 9

18 be graphically displayed either in a bar, line or pie chart. Furthermore, theses graphical representations can be easily saved as a bitmap image and stored for later use. 10

19 Chapter 3 Task Design Before designing the robot in terms of its mechanics and programming, there needs to be a description of what it should do. This chapter gives a clear definition of the project s targets, relating them back to the minimum requirements. 3.1 The Robotic Footballer If the robot is to eventually compete in a game of RoboCup Junior then it must be able to carry out some key footballing skills. The minimum requirements contain a list of tasks that the robot can perform. Rather than just attempt them individually, a more general task has been defined involving several of these. The aim for any robot in a game of RoboCup Junior is to score a goal. This would involve: Locating the ball Making for the ball Collecting the ball Scoring a goal The next four sections discuss each of these skills, giving them a clearer definition. Although the aim is to have the robot competing against another, for these tasks it will be assumed it is alone on the pitch with a stationary infrared ball. This will allow the perfection of the basic operations of the robot. These can then be built upon later, taking into account the repercussions of an opposing robot. Locating the ball The robot must be able to locate the ball on the field of play. The end result of this task should be the robot pointing towards the ball. In the minimum requirements, this would accomplish: locate an infrared ball. Making for the ball Assumes the robot is pointing at the ball. The robot must be able to travel to the ball and stop once it is reached. The end result should be the robot adjacent to the ball. This would accomplish: is able to travel to the ball. Collecting the ball 11

20 Assuming the robot is adjacent to the ball. The robot must be able to collect the ball, bring it under control therefore allowing the robot to move freely without loosing it. This would accomplish: dribble with the ball. Scoring a goal Assuming the robot has the ball under control. The robot must place the ball into the opposition s goal. The robot must dribble the ball into a position in front of goal then shoot. This would accomplish: identify its location on the pitch, travel to a specified location on the pitch, identify opponent s goal, and shoot the ball towards the opposing goal. Since the first three phases will accomplish three tasks, the fourth phase can be regarded as an enhancement of the minimum requirements if completed. 3.2 Development Process The advantage of dividing the process of scoring into four sub-tasks is that the project becomes easier to manage. They can be set as milestones within the project and hence giving a clearer idea of what stage has been reached. Each task will be concentrated on in turn, thoroughly testing them, both in terms of reliability and under different environmental conditions, so that the final program will result in a competitive robot. Once this has been completed I then intend to move on to cover the extended requirements such as developing tactics to be used in a game of RoboCup Junior. 12

21 Chapter 4 Robot Design This chapter details my initial design for the robot. The design is based on the tasks defined in chapter 3 Task Design. 4.1 Programming In chapter 2 Background, it is stated that NQC will be used to program the robot throughout this project. When programming, the same techniques learnt when working with C++ should be applied. Programs written in C++ are ideally constructed from functions. Functions are small sections of code, the fundamental building blocks of any program. In NQC, functions are especially useful because of the need to repeatedly perform certain actions. For example, turning the motors on would require several lines of code each time the action is necessary. By placing the code in a function, the main program would just need to call it several times. The result is a shorter and easier to follow program. Another advantage of function based coding is the ability to reuse functions in similar programs. This is particularly good for my project as basic functions shall be programmed to start with and obviously reused at a later, more advanced stage. The basic functions will be things like the code for turning the robot and moving it forward. These can then be used in larger functions such as making the robot drive to a specific point on the pitch Limitations of NQC Before designing any programs, the limitations of the NQC programming language must be considered. As its name suggests, Not Quite C is not quite C. It cannot use real numbers or Boolean variables. The latter is easy to overcome using an integer assigned as either 0 or 1. The former presents are more difficult problem such as calculations involving fractions or small numbers. For example, a calculation such as the following would yield a wrong answer in NQC: = 1 10 = 10 Wrong! The inaccuracy comes from the fraction in the equation. The fraction should be equivalent to one fifth but NQC rounds it up to one, the nearest whole number. To prevent or minimise this type of problem occurring, the nominator could be scaled up, then the final answer scaled down. The answer should then be close or equal to the real one. 13

22 E.g. a = 10 ( a 20) 100 a 10 Where a is the scaling value. ( 10 20) ( 2 10) = 2 Correct! Movement The most fundamental, low-level actions that the robot is to perform are its movement tasks. In section 2.4 Robot Locomotion and Steering the basic ways of implementing movement into the physical design were discussed. From that research it was decided that the three wheeled approach, using a drive wheel connected to a motor on each side of the robot and a free moving pulley wheel for balance shall be implemented. Each motor is attached to an output on the RCX and can therefore be controlled from within a program. To drive forwards is fairly simple. Both left and right motors are turned on for the same amount of time. To turn, the motors are turned on in opposing directions. For example, a clockwise turn is done by turning the left motor forwards and the right one backwards. The operations are fairly simple but do not take into account the distance travelled by the robot, just the time it has been moving. We could estimate the distance from the time but this would not be very accurate as we could not be sure how fast the robot is moving. On one of the wheels will be a rotation sensor. This will enable the robot to measure how far the robot has travelled from the distance the wheel has turned. Although a good estimate, this method would still not be always accurate, Even using our rotation sensor feedback, we have no way of knowing whether the robot wheels are actually driving or just slipping [10]. Instead of just driving forwards the robot can move for a set number of rotations. Once the rotation sensor exceeds a specified number, the robot turns the motors off. The rotation sensor can also be used to measure turns since both the wheels are turning in equal but opposite directions. If the rotation sensor read α after a random rotation, the robot could just turn in the opposite direction until the rotation sensor is reduced by α, resulting in the robot being in its original orientation. 14

23 4.2 Footballing Tasks Chapter 3 Task Design divided the task of scoring a goal into four phases. This section details how each shall be implemented into a program Locating the Ball The first thing a robot must do is to find the ball within the field of play. Solving this problem requires a method by which the robot can detect the ball using the sensors provided in the Lego kit. The ball in this context is an 8cm diameter sphere that emits infrared light. This infrared light will allow the robot to distinguish the ball from that of its surroundings. The light sensor makes this possible as it can sense incoming light in the infrared spectrum as well as the visible spectrum. The robot will use the light sensor feedback to determine whether or not it is directly facing the ball. It would rotate through 360 degrees and use a pre-determined threshold that, when breached, means it is likely to be facing the correct angle. Although only the direction of the ball can be computed, rather than its exact location, this should not be a problem since the next phase, making for the ball, only requires this information. The scanning behaviour can be achieved by getting the robot to turn, ideally on the spot [13]. The procedure would involve the RCX continually polling the light sensor reading whilst it is turning on the spot. Once the light sensor reading breaches the threshold, the robot will stop turning and should be facing the ball Making for the Ball Once the robot has completed the scanning procedure, we can assume it is facing the ball. The robot must now drive to the ball and stop once adjacent to it, ready for collection. Since the robot will drive forwards to the ball then it is likely the first point of contact with it will be at the front. A touch sensor will be mounted at the front of the robot that will detect this contact. The robot will drive forwards continually polling the touch sensor waiting for a reading change, indicating the ball has been reached, and stop the motors Collecting the Ball Now the ball has been reached, the robot must collect it. The mechanism used is rather more important than the programming here. With a good grabbing claw at the front, the robot needs only to close it around the ball. In order to grip it, the grabbing mechanism will be on for a few seconds to make sure the claws have had chance to close. 15

24 4.2.4 Scoring a Goal At this point the robot will have control of the ball. Now all that is needed is the robot to travel to a position in front of the goal then shoot. To travel to a specific location on the pitch the robot needs to know where this position is in relation to itself. This can be achieved using movement tracking that is described in great detail in section 4.3 Robot Navigation. Shooting is to be performed by propelling the ball forward. This is achieved by opening the grabber, driving the robot forwards a short distance, then stopping sharply. The ball will continue to roll because of the momentum transferred to it from the robot (see Figure 4). The alternative is to use a kicking mechanism but this will require another motor and hence constrain the physical design of the robot somewhat. Robot Goal Ball 1 - The robot is in front of goal. Robot Goal Ball 2 The robot drives forward with the ball Robot Goal Ball 3 The robot stops after short distance. Ball continues rolling forwards toward goal Figure 4 - Robot shooting method 16

25 4.3 Robot Navigation Navigation is necessary for the task of scoring as the robot will have to travel to a position in front of goal. Navigation can also be used for more advanced tasks such as wall avoiding and tactical play. This section shows how a navigation technique, using the robot s sensor feedback, shall be implemented into the program Dead Reckoning When considering the task of scoring a goal the robot needs the following information: Robot s position on the pitch Robot s orientation Goal position on the pitch Using these, the robot can calculate the distance and angle to goal (see section Mathematics of Moving to another Point). The last item on the list, goal position is already known in advance as the pitch layout will always be the same (see Figure 1 - RoboCup Junior pitch for one versus one game). However the former two require the robot to track its own movements and constantly re-calculate its position and orientation. This can be done using a well known navigational technique known as deadreckoning. In dead-reckoning, you start from a known point. Then you move in a certain direction, and, based on how fast you are moving and in what direction, you can calculate a new location. [10]. Dead-reckoning is most suited to the robot as the information described in the last quote can be obtained using the single rotation sensor mounted on the left drive wheel. The known point in this case is the starting position, near the centre of the pitch. The problem with dead-reckoning is it becomes impractical over time because there are so many things that can go wrong. All the calculations are based on sensor feedback that is not always reliable. For example, if the robot was stuck in a corner the wheel may still turn but the robot would not be moving anywhere. Small errors become large errors over time. Therefore it is important that the navigation is implemented as accurately as possible so to minimise errors Distance Travelled and Orientation Calibration The robot has two basic movements: move forwards and turn. Each requires a small calculation to convert them into measurements to be used in dead-reckoning. The measurements of the pitch (see Figure 1) are in centimetres; therefore forward movement shall be converted into centimetres. When the robot moves forwards, the rotation sensor reading will increase by a certain amount depending on 17

26 the distance travelled. Let σ be the change in rotation sensor reading and d be the actual distance the robot has moved through: σ d σ = k d (Where k is a constant) To calculate k the robot is programmed to travel a certain number of rotations σ. The distance d travelled by the robot is then measured allowing k to be calculated using the equation: σ k = (k is then the number of rotations per cm) d This process shall be repeated several times and take a mean k value to gain an accurate result. Once k is hard-coded into the program d is calculated using the equation below: d σ = k The robot s orientation will of course be measured in degrees so the dead-reckoning calculations can be done using trigonometry (see section 4.3). The angle of orientation is measured in a clockwise direction from the y-axis. Figure 5 shows this more clearly Figure 5 - Measurement of Orientation When the robot turns clockwise or anti-clockwise there will be a change at the rotation sensor. If we know the change in rotation sensor reading for a full 360-degree turn then we can work out the angle turned for any rotation sensor reading. Let σ be the change in rotation sensor reading, ω is the change in rotation sensor reading for a 360 degree turn and θ be the actual angle turned by the robot: 18

27 σ θ = 360 ω To perform this calculation ω must be calculated. This is to be done using basic trial and error. The robot is programmed to turn until a specific target is reached at the rotation sensor. If the robot turns more than 360 degrees then reduce the target otherwise increase it until an optimal value is reached. This will be repeated several times and the mean result assigned to ω Mathematics of Dead-Reckoning The robot is a single coordinate on a two dimensional plane. This plane represents the pitch that the robot is on. The bottom left hand corner of the pitch is coordinate (0, 0). From the measurements given in Figure 1, the diagram below shows how the pitch is represented in polar coordinates. (0, 87) (119, 87) (0, 58) goal centre (59, 43) goal (119, 58) (0, 29) (119, 29) (0, 0) (119, 0) Figure 6 - Pitch represented in 2D coordinates Dead-reckoning is applied after the robot has moved forwards. This is because moving forwards is the only movement that will cause the robot to change position. When turning, the only attribute which changes is the angle of orientation. Suppose the robot moves forwards from a known point and at a given angle. Let: Robot s initial position (x1, y1) Robot s orientation θ Distance travelled d 19

28 From dead-reckoning the robot needs to calculate its new position (x2, y2). The situation is shown more clearly in the diagram below: x (x 2, y 2 ) y θ d (x 1, y 1 ) Figure 7 - Dead-Reckoning Diagram In Figure 7 x and y denote the change on the x-axis and y-axis respectively: x y 2 2 = x 1 = y 1 + x + y Using trigonometry on the right-angled triangle: opposite x sin θ = = x = d sinθ hypotenuse d adjacent y cos θ = = y = d cosθ hypotenuse d Substituting into the equations for x2 and y2: x y 2 = x1 + d 2 = y1 + d sinθ cosθ The above equations are applied each time the robot moves forwards using the initial coordinates, orientation and distance travelled to give the robot s new position Mathematics of Moving to another Point From dead-reckoning we have a good estimate as to where the robot is on the pitch. The task of scoring a goal requires the robot to either shoot towards the goal or dribble the ball into it. Therefore it 20

29 needs to know the angle of the goal in relation to itself and how far away it is. Consider the situation in Figure 7 again. This time we know the following information: Robot s Position (x1, y1) Goal Position (x2, y2) We want to calculate: Angle to goal Distance to goal θ d As we know the coordinates of the robot and the goal we also therefore know x and y. This means we have a right-angled triangle. To calculate θ we need to use trigonometry again. We know the opposite side s length ( x) and the adjacent side s length ( y). Therefore: tan θ = opposite adjacent = x y θ = tan 1 x y Using inverse tangent does not always work however. It will only produce angles in the range -90 to 90. This is due to the nature of the inverse tangent function since it is being applied on the ratio of x to y. Consider the situation in Figure 7. In diagram one both x and y are positive values. When applying the inverse tangent function (see above) we get the correct angle θ1. In diagram 2 both x and y are negative. Applying the inverse tangent function here gives the angle α rather than the desired θ2. This occurs as we are dividing two negative values hence producing a positive value. For example: x x y y 1 x 1 2 θ 1 y - y α θ 2 - x Figure 8 - Inverse Tangent Diagrams 21

30 There also exists the possibility of y being 0 resulting in an attempt to divide by zero. This and the above problem must be taken into account before the inverse tangent function is applied. Defined below are some rules that show how this will be done. Diagrams have been included to make it clearer. if y = 0 and x 0 then θ = 90 if y = 0 and x < 0 then θ = 270 y θ x 1 x if y > 0 and x 0 then θ = tan y y if y < 0 and x 0 then θ = 180 α θ α x α = tan 1 x y y α θ x if y < 0 and x < 0 then θ = α α = tan 1 x y y α if y > 0 and x < 0 then θ = 360 α θ x α = tan 1 x y To calculate d we use Pythagoras theorem. Pythagoras' theorem states that if you square the two shorter sides in a right-angled triangle and add them together, you get the same as when you square the longest side (the hypotenuse). 22

31 d 2 = x 2 + y 2 2 Therefore: d = ( x + y ) 2 As x and y are squared in the equation then d will always be a positive value. This is ideal since x and y could be negative representing the target position is below or behind the robot. The value d just represents the distance from the points. It is the same as the magnitude of a vector NQC Maths NQC does not contain any maths functions such as those required for dead-reckoning and moving to another point. Sine, cosine and inverse tangent will all have to be written as functions into the program. Before the use of calculators, mathematicians used lookup tables for trigonometry. A short lookup table shall be used for each function using simple if and else statements. This does not entirely solve the problem since a lookup table still will not be accurate most of the time due to its entries being over a range of values. However it should give a decent estimate of the value, good enough to track its position on the pitch. As mention in section Dead Reckoning, small errors become large over time. The use of lookup tables will surely increase the margin for error so they must be fairly large to minimise this. The sine function must take into account angles in the range of 0 to 360 degrees. A sine wave can be split into four quadrants. Each quadrant is the same except either negative, in reverse or both Figure 9 - Sine wave in four quadrants 23

32 In Figure 9 each quadrant can be compared to quadrant 1. For example, 2 is the reverse of 1, 3 is the negative of 1 and 4 is reverse and negative of 1. This means that the lookup table needs only to contain values for 0 and 90 degrees. If the angle is above 90 degrees then the following rules are applied: if 90 < angle 180 (i.e. in quadrant 2) then lookup (180 angle) if 180 < angle 270 (i.e. in quadrant 3) then lookup (angle 180) and make negative if 270 < angle 360 (i.e. in quadrant 4) then lookup (360 angle) and make negative A cosine wave is the same as a sine wave but 90 degrees out of phase (see Figure 10). All that is needed to implement a cosine function will be adding 90 to the angle. If the angle was above 270 degrees then be subtracting by 270 keeps angle in the range 0 to 360 degrees. 90 sin cos Figure 10 - Sine and Cosine Wave The lookup tables must be equally spread so that their effect is maximised. The sine function returns a value between 0 and 1. Because NQC cannot use real numbers (i.e. decimals) then the output from the table shall be scaled up so the output is between 0 and 100. Any calculations using the sine/cosine function must therefore end by dividing by

33 4.4 Mechanical Some of the mechanical design decisions have already been made earlier in this chapter. It was decided that implementing different tasks in the program should be considered first before moving on to the mechanical construction Chassis As described in section Movement, the most appropriate wheel configuration is having two drive wheels at each side and a rear pulley wheel for balance. This way, turns and moves forward are simple to program and give fairly accurate results. Accuracy is the key to the success of deadreckoning which is why the dual-differential drive (see section 2.4) would be most suitable. However, due to the hardware limitations, this idea was abolished and instead uses an independent motor for each drive wheel. The likelihood of errors must be minimised if the robot is to continue running over a long period of time, which will be the case if the robot participates in full game of RoboCup Junior. Therefore, before driving forwards, the motors must be configured so that they run at equal speeds. This configuration can be done within the program by reducing or increasing the power that is sent to each motor. The base of chassis will be a modified version of the introductory robot from RoboCup Junior Australia [15]. This way less time will be spent building the robot, leaving more for programming Sensors Having designed how all the footballing tasks will be programmed, the required sensor feedback is known. For the first task, locating the ball, the robot will use a light sensor to detect when it is facing the ball. The light sensor must therefore be positioned so that it has a clear, unobstructed view of the pitch in front of the robot. Taking the idea from the SoccerRobot instructions [15], the light sensor will be mounted at the front of the robot. The second phase, making fort the ball, requires a touch sensor to detect the ball. Rather than just having the touch sensor on the front of the robot, it must have its range and sensitivity increased if it is to detect contact with a large ball at low speed. To do this, a similar method to that used by David Baum in the bumper design of a Tribot [1, pp ] will be employed. Baum uses a pair of angled beams that pivot when pressed. At the far end of the beams is a touch sensor that is placed so that when the beams pivot, it presses the touch sensor hence detects a collision. The beams fall back into their original position as an elastic band causes them to spring back. The sensitivity is increased because only a small adjustment at the front of the beam causes the back end to press the sensor. For movement tracking in navigation, the robot requires a rotation sensor to be mounted on one of the wheels. This should be relatively easy by using a gear and rod on the rotation sensor that connects to the left wheel axle. 25

34 4.4.3 The Grabber For the task of collecting the ball and dribbling the robot requires a mechanism which both can collect the ball and keep hold of it whilst moving. The obvious design would be a pincer-like structure where two claws would close around the ball and stay closed during dribbling hence allowing the robot to move easily whilst in control of the ball. The claws, when opened, would also serve as a way of gathering the ball when the robot is making travelling to it (see Figure 11). Robot Ball 1 The robot makes for the ball., slightly offline with it though. Robot Ball 2 The ball is reached and makes contact with the right pincer. Robot Ball 3 The angle of the pincer coupled with the forward movement of the robot cause the ball to roll into the jaws. Robot Ball 4 The robot detects ball and closes grabber around the ball Figure 11 - Gathering ball with Pincer-like Grabber 26

35 The grabber will require a third motor so it can perform its close and open operations. The pincers will be connected to each other using two gears. The effect is that moving one pincer moves the other by the same distance. 27

36 Chapter 5 Implementation of Design When implementing the design many modifications were made. This includes both programming and mechanical changes but mainly the former. This chapter details these alterations as well as how they were implemented. It also contains some features, not in the original design, which were added following testing. The NQC code can be seen in Appendix B whilst final images of the robot are shown within Appendix C 5.1 Straight Line Driving As mentioned in section Chassis, the robot must move straight in order minimise errors occurring in dead-reckoning. When the robot drove forwards for the first time it did not succeed in maintaining a straight line, instead it tended to drift to the right. This suggested that the left wheel must be turning faster than the right. To correct this problem the power of the left motor was reduced again and again until the robot achieved straight-line travel. These values were then hard-coded into the program. The power levels were restored for turning since no problem was encountered. 5.2 Ball Scanning One of the major improvements made was to the ball scanning. After implementing the technique (see section 4.2.1) it was found that the robot, although turning in the direction of the ball, failed to point directly at it. To improve the method, tests using the datalog feature (see section 2.6 Datalog) were carried out on the light sensor. The robot was programmed to perform a turn (approximately two and a half revolutions) whilst logging the light sensor reading every 10ms. Using tasks in NQC enabled this. The RCX can handle up to ten tasks running at the same time, although only two are required for the ball scanning. The first is the standard main task (always must exist) containing the instructions to perform a turn; the second contained an infinite loop that added the light sensor reading to the datalog then paused for 10ms. The test was repeated three times. The first without the ball on the pitch, the second with ball close to the robot and the third with the ball far away from the robot (see Figure 12). 28

37 Pitch Position 2 Position 1 Figure 12 - Ball Scanning Test Figure 13 shows the results when no ball was on the pitch, Figure 14 shows the results for when the ball was at position 1 and Figure 15 shows the results for the when the ball was at position 2. These graphs were produced in BricxCC. Figure 13 - Ball scanning results using no ball (ambient light) Figure 14 - Ball scanning results using position 1 29

38 Figure 15 - Ball scanning results using position 2 Note: The results shown in Figure 13 are scaled up on the y-axis. No notable peaks are observed in comparison to those when the ball is it both positions 1 and 2. Looking at the results from tests two and three, there are clear peaks occurring when the robot points at the ball. Even when the ball is placed farthest away, peaks can still be clearly seen. The infrared ball can be considered a light source, emitting light waves in all directions. The intensity of peaks decreases as the distance from the robot increases. This happens because light waves tend to spread out as they move away from their source. As a result, intensity decreases quickly as distance increases. [3]. In the initial ball scanning method the robot would just wait for a certain threshold to be breached and then stop. For example, if the threshold were set to 39 then the robot, in test 3, would be pointing more or less at the ball. However, in test 2, the robot would stop before reaching the peak value of 50 and therefore will not face the ball. The maximum value of a peak is reached when the robot is directly facing the centre of the ball. Incoming light waves will be perpendicular to the light sensor and therefore have maximum intensity. A successful ball scanning method should therefore turn the robot until the peak value is found. To achieve this, the robot was programmed to perform a full 360 degree turn, recording the largest light sensor reading found. After this preliminary scan, the robot will know the maximum value and can turn again until the light sensor reading equals this. With no ball on the pitch, test 1 produced a maximum ambient light sensor reading of 31. Compare this to when the ball is furthest away from the robot in test 3. This time the maximum light sensor reading is 40. Using this information, the robot can deduce if the ball is not on the pitch or out of view. Another threshold of 35 was set then the robot was programmed to assume the ball is not there if the maximum light sensor reading recorded after the initial 360-degree turn did not exceed this. In the event of this occurring, the robot was programmed to move to another point on the pitch before scanning again. The theory is that the ball is hidden, perhaps by another robot, so we move somewhere else to find it. These ball-scanning positions are in the centres of each half of the pitch 30

39 (see Figure 16). The robot scans for the ball and, if not found, moves to the other position before scanning again. This process continues until the ball is found. (0, 87) (119, 87) (0, 58) Scanning position 1 Scanning position 2 (119, 58) (29, 43) (89, 43) (0, 29) Goal Goal (119, 29) (0, 0) (119, 0) Figure 16 - Ball scanning positions 5.3 Successful Collection The ball detection mechanism on the front of the robot allows it to sense when the ball is between the claws of the grabber. Once contact has been made, the robot immediately closes the grabber around the ball. If the grabber makes a successful collection, the ball will remain in constant contact with the ball detection mechanism. Knowing this, the robot was programmed to perform a check once the grabber has closed. If the robot failed to collect the ball it moves back to its scanning position and starts the ball scanning operation again. Although this does not improve the ability of the robot to complete its scoring task, it does improve its efficiency, as the time taken from the point of collection to shooting would be wasted if the ball slipped away to start with. This should help the robot perform in a competitive match of RoboCup Junior, as it will not be just driving around, thinking it has the ball when it actually has not. 5.4 Improved Turning When the robot needs to turn to a specific angle it does so by turning clockwise. Although this does not create a problem, it can mean the robot turns through a bigger angle to that if it turned anticlockwise (see Figure 17). To correct this flaw an if else statement was added, which calculated the angle required to turn through when turning clockwise. If the angle is less than 180 degrees the robot turns clockwise otherwise turn anticlockwise. This again improves the efficiency of the robot. 31

40 Current direction Target direction Figure 17 - Turning clockwise is not always the shortest way to turn 5.5 Sine, Cosine and Inverse Tangent Functions The trigonometry functions used in dead-reckoning were implemented as lookup tables using if else statements. To decide how each function would be divided into table entries the range of output was analysed. The sine function outputs a value between 0 and 1. In the program, this would be 0 to 100 since values are scaled up by 100 for calculations (see section NQC Maths). The corresponding angles were deduced by dividing the output evenly and working backwards (see Figure 18). 100 Output 0 0 Angle 90 Figure 18 - Dividing up the Sine function 32

41 I divided the sine function into ten. The actual output was the mid value of each range. For example, the output range of 0 to 10 corresponds to the angle range of sine 0 and sine 10 i.e. 0 to 6 degrees. Therefore, when the angle is in this range the output is the midpoint of 5. The full table is shown below: Angle Range Output Range Midpoint (output) 0 to 6 0 to to to to to to to to to to to to to to to to to to to Figure 19 - Sine Function Lookup Table Inverse tangent takes a ratio as input and outputs an angle. This time the function was split into 15. It originally split into 30 but the size of the program increased to such an extent that it failed to download to the RCX. As the angle was the output it was divided up evenly. Because ratios can be less than one, they were scaled up by ten. For example, the angle range of 0 to 6 degrees corresponds to the input ratios between 10 * tan 0 and 10 * tan 6 i.e. 0 and 1. Therefore, when the ratio multiplied by 10 is 0 or 1 then the angle output will be 3 degrees (again the midpoint of the output range). The full table is shown below: 33

42 Ratio Range 10 Ratio Range Output Angle Range Midpoint (output) 0 to to 1 0 to to to 2 7 to to to 3 13 to to to 4 19 to to to 6 25 to to to 7 31 to to to 9 37 to to to to to to to to to to to to to to to to to to to to to to to infinite 95 to infinite 85 to Figure 20 - Inverse Tangent Lookup Table 5.6 Navigation Technique The navigation was split into two parts; movement tracking using dead-reckoning and moving to another point using inverse tangent. It was decided that the tracking functions would only be needed when moving forwards since this is the only occasion when the robot s coordinates will change. Suppose the robot wanted to move to a specific coordinate on the pitch. It would first use the mathematics (as described in section Mathematics of Moving to another Point) to calculate the angle to turn to and distance to travel. The robot then turns to the angle and moves forward by that distance. After completing the move the robot would then update its position using the movement tracking mathematics (as described in section Mathematics of Dead-Reckoning). Since both set of calculations are only approximations, this will surely increase the likelihood of errors. It would be much easier to assume the robot did reach its desired coordinates and therefore just update them to these rather than perform any dead-reckoning. In fact, the only time dead-reckoning is required is when it is in the making for the ball phase. See next section for more details. 34

43 5.7 Wall Avoiding When the robot makes for the ball it does so blindly. It is just driving forwards until the ball detector senses the ball. If the ball fails to be detected the robot will continue forwards, hitting the wall. To avoid this problem the robot must never travel beyond a defined boundary. The task of making for the ball should be changed to continually update its position, checking there is a safe distance between itself and the sides of the pitch. Since the robot s navigation tracks itself as a single point on a 2D plane we can assume this coordinate is that of the centre of the robot, between the drive wheels. The distance from the front of the robot to the centre is approximately half the total length of the robot. Therefore, so long as the coordinate of the robot stays clear of the walls by at least this distance then the robot should be able to move freely, avoiding any contact (see Figure 21). l/2 Pitch l/2 Robot Goal The robot s coordinate is constrained to this area. l/2 l/2 Goal l Figure 21 - Wall avoiding technique The problem encountered was the difficulty in updating the position continually whilst checking if the ball has been detected. Fortunately, NQC includes the ability to monitor for sensor events whilst executing other instructions. Events are defined at the beginning of each program and can be monitored for in a block of code. Should an event be detected, the program will immediately leave the monitored code and a specified task will be performed. In this case, the monitored code was an infinite while loop which continually updated the robot s position using dead-reckoning with the distance travelled since the robot started making for the ball. This distance is updated by reading the increase in rotation sensor clicks since the move was started. If the robot reaches the boundary it returns to a scanning position and resumes looking for the ball. Wall avoiding is not required when the robot is alone on the pitch. However it will be useful when competing in a game of RoboCup Junior. For example, suppose the robot locates the ball on the pitch and begins to move towards it. If a competing robot were to somehow move the ball then nothing 35

44 would be detected. The robot needs to prevent itself from crashing into the sides and severely disrupting the dead-reckoning. Such an event would be catastrophic in terms of navigation accuracy. 5.8 Mechanical No major changes were made when implementing the design. However, several problems occurred and which were eventually solved. These are detailed in this section Rotation Sensor Adding the rotation sensor to a single wheel on the chassis proved a difficult task. Since the rotation sensor was used to measure the angle of turns then it had to be quite sensitive. In the initial implementation, the number of clicks read in the rotation sensor for a 360 degree turn was just 60. This means the robot can only estimate to the nearest sixth degree. In practice this was not an issue when the robot performed a single navigation task. However, as the robot is to compete in a game of RoboCup Junior then dead-reckoning errors must be minimised. Using a gear reduction the rotation sensor was added so it required 110 clicks for a full turn. Turns can now be measured to the nearest three degrees, twice as accurate as before Ball Sensor The most advanced engineering feature of the robot is the ball sensor. This is built around a touch sensor and is sensitive enough to detect a small amount of contact with the ball. It was built using a pivoting arm extending into the area between the claws of the grabber. When pressed, the arm causes a lever attached to a rubber band to move off a touch sensor. In an initial implementation, the lever moved on to the sensor but due to the shape of the button, this required more energy hence producing a less sensitive mechanism. One of the main difficulties when building this was the strength of the elastic energy provided by the rubber band. Too strong means less sensitive, too weak means the lever does not return on to the touch sensor button once the arm is released. The only way to overcome this problem was to build, test and rebuild until it worked sufficiently The Grabber Before building the grabbing mechanism into the robot, it was built separately to find a working design. The grabber consists of two connected pincers, one of which is connect to a motor via a rubber band. This enables slippage and prevents strain on the gears. In my first implementation the pincers were found to be not big enough. The ball could be easily collected but was often lost due to 36

45 the lack of grip. After extending the pincers it was found that they were not as strong as before due to their extra weight. Fortunately, they did work fine for collecting the ball and maintaining grip. When the grabber was built into the robot slight modifications had to be made, to ensure the pincers were at half the height of the ball. This ensures the ball is controlled around its centre resulting in better control and effective collection. 37

46 Chapter 6 Evaluation To evaluate this report, the final outcome shall be compared to the aim. Problems and difficulties encountered during the building and programming stages will be discussed as well as the success of the dead-reckoning navigation system. The aim of this project was to create a robotic footballer that demonstrated a number of key skills and eventually compete in a game of RoboCup Junior. These key skills were later defined in the minimum requirements as a list of tasks of which at least three were to be implemented. Since the robot was to compete against another robot, tasks were chosen which would allow it to score a goal, the standard aim in any game of football. Instead of attempting to program the entire procedure, goal scoring was divided into four phases: locating the ball, making for the ball, collecting the ball, and scoring a goal. After studying these phases, the following tasks were identified which would be achieved: locating an infra-red ball, able to travel to the ball, able to dribble with the ball, can identify opponent s goal, and shoot the ball towards the opposing goal. By selecting four, a single task could be abandoned without failing the minimum requirements. In the end all of these were accomplished. 6.1 The Project Four other students, all of whom and myself attended a weekly group meeting, undertook this project and its aim. In the beginning we were confident that we could not only build and program robotic footballers, but also we could also team them up in pairs in a two versus two game of RoboCup Junior. This never materialised because we underestimated the time and effort required for creating our robots. However, because of some of the advanced features being added, such as wall avoiding, the robot should be capable of competing against another robot, even though there was no opportunity to test it in a game. It could be argued that the project was not a success because of the failure to compete in a game; however, it could be equally argued that there was no way anyone could have envisaged the time required to build the robots. As a whole the project went smoothly with the only major problem being the mechanical construction of the robot. Many variations of the robot were built, each improving on the previous design. I am a computer scientist not a mechanical engineer, so it took time to construct a robot specifically built to perform the footballing skills. The programming side of the project was much more productive. The implementation of goal scoring was an early success. This enabled the improvement of the efficiency of the robot and as well as the addition new features which could be used in a game of RoboCup Junior. It was a pity no game could be set up since theses additions were never fully utilised. 38

47 6.2 Dead-Reckoning Navigation The biggest and most challenging part of the project was the design and implementation of the robot s navigation technique, dead-reckoning. This provided the robot with the ability to track its own movements on the pitch. The robot was then able to use this information to calculate the distance and angle to a specific coordinate. In the final program, movement tracking is only used in one situation, making for the ball. This is the only time when the robot does not know where it will stop and therefore its position must be estimated using distance and angle of travel. During other movements, such as drive to a specific position, the robot just assumes it reached the location and updates accordingly. This significantly reduced the size of the program, as it did not need to constantly perform dead-reckoning calculations after each move. At one stage, the program with dead-reckoning throughout was too large to download to the RCX. The sine, cosine and inverse tangent functions were always going to be approximations due to there being no such maths functions existing in NQC. The best way to do such an approximation was to use lookup tables. The ranges of inputs were split so that the output of a value in each range was a good approximation of the real one. Equally dividing the range of possible outputs and then working backwards to find the ranges of inputs achieved this. If an input was in a particular range then the midpoint output of that range was the output of the function. One aspect of the RCX that affected the dead-reckoning was its inability to handle real numbers. This posed a difficult problem when using sine and cosine values which range from 0 to 1. This was overcome by scaling the values up, so they were between 0 and 100. Any calculation using a sine or cosine function would then just divide by 100 at the end to get the answer to the nearest whole number. Testing the calculations revealed the results were accurate even though the sine and cosine functions used a lookup table. Dead-reckoning and the inverse tangent function produced very accurate results for navigation. The robot, although not perfect, gave impressive results when performing the goal-scoring task. However, over time the robot showed how the accuracy of dead-reckoning degenerates. Initially the robot was able to score on the first few attempts. After a while it was noticed how, when the robot returned to the centre after scoring, it was getting further and further from the centre of the pitch and pointing at different angles. 39

48 6.3 RoboCup Junior Tactics One of the extended requirements was to use a wider variety of tactics in a game of RoboCup Junior. The wall avoiding technique was implemented where, the robot, based on its position, will only travel in an area away from the sides of the pitch. Testing the robot was carried out by allowing it to see the ball first then removing it from the pitch. The robot travelled forwards thinking it would make contact with the ball in its grabber. Just before it collides with the wall it stopped, rotated by 180 degrees and returned to the scanning position to resume looking for the ball. Obviously this is just a single tactic but it would be extremely useful when playing against another robot. For example, a competing robot may take the ball out of the robot s path whilst it is driving towards it. Hitting the wall would be catastrophic for the dead-reckoning since the robot, although stuck against the wall, thinks it is still moving forwards. Because of the progress from other students taking this project, no more work could be put into tactical development for the simple reason that no tests of the robot could be carried out in a competitive game. Instead, work was put into improving the basic functions of the robot. Improvements such as increasing the efficiency of the robot during turns, better sine, cosine and inverse tangent functions have all helped the robot become very effective at scoring goals. 6.4 Different Environmental Conditions The final minimum requirement was to evaluate the robot under a variety of environmental conditions. There are two types of environmental condition that will affect the performance of the robot: lighting conditions and surface type Lighting Conditions The robot performs the ball scanning using the light sensor mounted at the front. As seen from experiments (see section 5.2 Ball Scanning) the robot turns through 360 degrees recording the maximum light sensor reading observed. If this value is above the ambient threshold then the ball must be in view. The robot then turns until it faces the maximum value. The ambient light causes the low light levels observed with no ball. When the ambient light is greater than that recorded in section 5.2, the threshold used to decide whether the ball is in view must also be increased. However, since the maximum light sensor reading is only around 40 when the ball is furthest away, if the threshold is above this then the robot will not always see it. Taking this possibility into account, the ball scanning procedure was changed so that the robot, failing to see the ball, will move to the other half of the pitch to repeat the scanning. This way the robot has more chance of seeing the ball, as it should be closer to it than previously. 40

49 The ball scanning procedure was very successful. When the ambient light level was increased, the robot did fail to see the ball when far away, but did see it after moving to the second scanning position. When the ball was seen from a large distance the robot still managed to point straight at it. On rare occasions the robot would be slightly off line, but, thanks to the wide grabber, the ball could be collected easily enough. As an extended piece of work to this project, the ambient light levels could be recorded, enabling the robot to calibrate itself and decide a threshold value. Similar to the way in which the threshold was calculated in section 5.2 Ball Scanning, from studying the ambient light level graph (see Figure 13) Different Surfaces The majority of testing was done when the robot was on the RoboCup Junior pitch. Obviously this is to be expected since the robot is designed to play a game of RoboCup Junior and therefore would not be expected to compete on any other surfaces. However should the robot have to adapt to another surface type, it was decided to see how the program could be changed to overcome this. The robot is contact with the floor via its wheels. The wheels will have different grip depending on the surface. For example, if the robot is on a polished surface, the wheels may slip a little. To measure how well the wheels gripped, the change in rotation sensor reading was analysed. To perform a 360 degree turn on a carpet the rotation sensor reading showed an increase by 140, whereas, on the smooth RoboCup Junior pitch, only 110 was required. So to overcome this variance in surface types, another calibration process could be programmed making the robot perform a 360 turn, measuring the change in rotation sensor reading. The robot could identify it has turned through 360 degrees by using the ball as a marker. When the light sensor reading reaches a maximum for the second time, the robot must have completed a full turn. Likewise, the distance travelled forward using the rotation sensor reading would need to be calibrated. An easy way to do this would be placing the ball about 10 centimetres in front of the robot that drives forwards waiting for ball to be detected in the grabber. Once this happens, the robot knows the change in rotation sensor reading. 41

50 Chapter 7 Conclusion and Further Work Although not all the extended requirements were met, the project was successful. A robot was built which could not only find the ball but also go to it, collect it and score a goal with a high degree of accuracy. The robot could also exhibited tactics such as wall avoiding and improved scanning which would be very useful if competing in a game of RoboCup Junior. This chapter contains what conclusions can be made from the project as well as what further work could be carried out, building on what has already done. 7.1 Mechanical Construction One of the easiest conclusions to draw from this project is that the mechanical construction of the robot should not be underestimated. Before beginning work on the building it was decided that it would be best to use designs and ideas from similar projects. The problem was that no robot could be found that was designed to perform the specific tasks set out in chapter 3 Task Design. Instead, ideas from various designs were combined; this was made difficult because the majority did not include building instructions, just pictures. In my opinion, future projects should not just come with a Lego Mindstorms kit; they should have a ready-made robot or instructions to build one. This way, students could start work on the programs very early on and not have to worry about mechanical engineering problems. 7.2 Dual-Differential Drive During the background reading, a useful drive mechanism called a dual-differential drive (see section 2.4 Robot Locomotion and Turning) was discovered. This gives the robot perfect straight-line driving and very accurate turning. Unfortunately, this was not added to the design due to hardware restrictions. Instead, a basic differential drive was used. This consisted of an independent drive wheel on each side if the robot. However this caused the robot to drift off line when driving forwards. Even though it was countered acted by reducing power to the left motor, it was still apparent over long distances. From my experience of this, it is recommended that students undertaking this project in the future use the dual-differential drive. This will not only save time from the hassle endured in this project, but to increase dead-reckoning accuracy. 42

51 7.3 Ambient Light Calibration As mentioned in section Lighting Conditions, the light level of ambient light may not always be the same. The robot s ball scanning procedure requires a threshold value that is slightly above the ambient light intensity of the room. This can be calculated by an automatic calibration procedure where the robot would perform a full turn, recording the maximum light sensor reading. The threshold will be slightly above this value to cope with any slight increases later on. 7.4 Better Navigation As discussed in section Dead Reckoning, the effectiveness and accuracy of the robot s ability to navigate will decrease because small errors will increase. The robot only used dead-reckoning based on the rotation sensor feedback. To improve the navigation, the robot could use a secondary method that can be used to correct for dead-reckoning errors. Such methods could include using a downward light sensor to detect the orientation of the robot or a front bumper to detect a collision with the wall. Once the dead-reckoning information conflicts with the secondary method, it gets updated accordingly. This would allow the robot to run for longer and therefore compete better in a game of RoboCup Junior. 7.5 Competing in RoboCup Junior As mentioned in the Evaluation chapter, there was no chance to see the robot compete in a game of RoboCup Junior. Future projects will also struggle to reach the stage where they can compete as there is no way to guarantee other students have their robot at that stage too. It has already been recommended that future projects be accompanied with a sort of template robot, allowing the student to work on the program earlier on. This way they will have more time to program basic footballing skills and can move on to competing in games of RoboCup Junior sooner. 7.6 Teaming up One of the more ambitious extended requirements set was to investigate the possibility of message passing between robots or a central computer. This would enable robots to work as a team. This stage was not reached but could be in future projects, with enough time. Working in a team would be really fascinating. The chance to see robots passing the ball, working in attack and defence is something that initially made this project so attractive. Although no first hand experience of the robot competing in a game of RoboCup Junior was gained, it is believed that an effective technique would be having the defending robot guarding the goal and preventing an opposition robot from shooting directly at it. 43

52 Meanwhile the attacking robot could carry out the goal scoring. If the defender had the ball it could notify the attacker to prepare for a pass et cetra. 44

53 Bibliography [1] Baum, David (2002), Definitive Guide To Lego Mindstorms Second Edition, Apress [2] Baum, David, Not Quite C, URL: [28 th April 2003] [3] Boast, Steve (2000), Light Intensity Lab, URL: [21 st April 2003] [4] Bricx Command Center 3.3, Homepage, URL: [28 th April 2003] [5] BrickOS, Official Website, URL: [28 th April 2003] [6] Goddard, Matthew (2002), Lego Mindstorms Robotics, University of Leeds School of Computing Final Year Undergraduate Projects 2001/2002 [7] Hacienda Robotics Program, Drivetrains, part 2 Dual Differential, URL: [20 th April 2003] [8] Hunter, Matthew; Kostiadis, Kostas; Hu, Huosheng (2001), A Behaviour-based Approach to Position Selection for Simulated Soccer Agents, pp. 1, Department of Computer Science, University of Essex [9] LEGO Mindstorms Official Website, The ROBOLAB Software, URL: [12 th April 2003] 45

54 [10] O Reilly Network, The Straight and Narrow, URL: [28 th April 2003] [11] RoboCup-2002, Smallsize RoboCup 2002, URL: [28 th April 2003] [12] Robocup Junior, RoboCupJunior 2002 Soccer Rules, URL: [28 th April 2003] [13] RoboFesta-MK (2002), RoboCup Junior Football Programming Checklist, pp. 2-4, The Open University. URL: [28 th April 2002] [14] ROBOLAB Official Site, Homepage, URL: [28 th April 2003] [15] Brian Thomas, Building a Soccerbot, URL: [20 th April 2003] [16] TPOTs, TBOTs Robots, URL: [28 th April 2003] [17] Veloso, Manuela; Stone, Peter; Han, Kwun and Achim, Sorin; CMUnited-97: RoboCup-97 Small-Robot World Champion Team, AI Magazine, issue (19.3), Summer,

55 Appendix A A Reflection on the Project Process My motivation for undertaking such an unusual project was the chance to work in artificial intelligence. Indeed, in the beginning I was very confident and enthusiastic about this opportunity. Unfortunately the project did not quite live up to my expectations. The mechanical phase was slow and painstaking, leaving the time for programming and development disappointingly short. I do not regret choosing the project; I am just left with the feeling of what could have been. Having said all this, I did actually enjoy many aspects of the project. Personally I have gained a wealth of information on robotics and artificial intelligence. My only regret is not being able to develop a more advanced robot than that which was produced. This was by far the largest piece of work I have ever done. Before starting, I never envisaged the work load or the impact it would have on my life over the course of the following seven months. Although on completion my immediate feeling was one of relief, I can also feel proud of what has been achieved, as what was seemed impossible at one point. The lowest time was during the mechanical phase. Building and rebuilding robots out of Lego may sound like fun, but for me it almost became a never ending cycle of events. Eventually, through perseverance, a final robot was constructed. I actually benefited from the many implementations as this robot was both reliable and functional. I quickly learnt not to worry about falling behind schedule and instead, concentrate on the current task in hand. I began to enjoy the challenges that faced me, no longer viewing them as a daunting uphill task. Managing a project on this scale was always going to be difficult. It was really a question of can I manage myself? Making a nice-looking chart featuring target dates and objectives is all well and good but useless if not followed. Early on I found myself using silly excuses to avoid doing work knowing full well that I should be getting on with it. After falling behind on my first two deadlines I decided to be much more self-disciplined. Starting work early in the mornings whilst avoiding any distractions was not the most enjoyable task but it paid dividends. The project did not need to be rushed near the deadline and the outcome was better than I had expected. The more time, effort and commitment you put in, the greater the rewards at the end. The weekly project meetings with my supervisor where done in groups rather than individually. This provided me with many opportunities to listen and learn from what the other students were doing as well as bouncing my ideas off them. Being criticised was not nice but really helped in the development and direction of my project. My advice to future students would be not to be scared of speaking up in these situations. Sitting back and keeping your ideas to yourself won t benefit you in any way. Also, if you have a problem talk to your supervisor, never continue regardless. The final year project is conducted over a lengthy period, going it alone will do you no good. 47

56 48

57 Appendix B /*** sensors ***/ #define EYE SENSOR_1 #define BALL_DETECT SENSOR_2 #define ROTATION SENSOR_3 /*** motors ***/ #define LEFT #define RIGHT #define GRABBER OUT_C OUT_A OUT_B /*** events ***/ #define BALL_IN_GRABBER 1 /*** macros ***/ #define sin(n, m) sincos(n, m) #define cos(n, m) sincos(n+90, m) #define topositive(n, m) squareroot(n*n, m) #define turnclockwiseto(alpha) turnclockwisefor(alpha - angle) #define turnanticlockwiseto(alpha) turnanticlockwisefor(angle - alpha) /*** constants ***/ #define rots_per_ten_cm 31 #define complete_turn_clock 108 #define complete_turn_anti 109 #define left_power 3 #define right_power 7 #define ballthreshold 35 task main() { // configure sensors etc. setup(); // close grabber closegrabber(); // find the ball findball(); // go to the ball gotoball(); Figure 22 - NQC Code: Definitions // if the ball is in the grabber then attempt to score a goal if(ball_detect == 0) { scoregoal(); closegrabber(); straightalongx(59); // to center - better for 270 angle travel } else { closegrabber(); travelto(59, 43); // back to center } // turn to face opposition goal at 90 degree angle turnanticlockwiseto(90); } Figure 23 - NQC Code: Task Main 49

58 void setup() // // configures sensors and setup anything else // { // configure sensors SetSensor(EYE, SENSOR_LIGHT); SetSensor(BALL_DETECT, SENSOR_TOUCH); SetSensor(ROTATION, SENSOR_ROTATION); ClearSensor(ROTATION); // configure the event of the ball entering grabber jaws SetEvent(BALL_IN_GRABBER, BALL_DETECT, EVENT_TYPE_RELEASED); } Figure 24 - NQC Code: Set-up Function void driveforwardsfor(int distance) // // Drives robot forward in a straight line for specified distance (cm) // { // convert cm into rotations int rotations = (distance * rots_per_ten_cm) / 10; // configure motor power levels to eliminate drift SetPower(LEFT, left_power); SetPower(RIGHT, right_power); ClearSensor(ROTATION); // reset rotation sensor // drive forwards until target reached Fwd(LEFT); Fwd(RIGHT); On(LEFT+RIGHT); until(rotation <= -rotations); // forwards = -ve on rotation sensor Off(LEFT+RIGHT); // reset motor power levels SetPower(LEFT, 7); SetPower(RIGHT, 7); } Figure 25 - NQC Code: Function that makes the robot drive forwards in a straight line 50

59 void turnclockwisefor(int alpha) // // turn clockwise for 'alpha' degress // { // convert alpha into rotation between 0 and 360 while (alpha > 360) {alpha = alpha - 360;} while (alpha < 0) {alpha = alpha;} // converting the angle into rotations. This scales the calculation up by 75 // then divides by it at the end int rotations = (((75 * alpha) / 360) * complete_turn_clock) / 75; // reset rotation sensor ClearSensor(ROTATION); // perform turn Fwd(LEFT); Rev(RIGHT); On(LEFT+RIGHT); until(rotation <= -rotations); // clockwise is a -ve rotation on sensor Off(LEFT+RIGHT); // update angle for dead-reckoning calculations angle = angle + alpha; // add alpha because its a clockwise turn while (angle > 360) angle = angle - 360; // always have angle between 0 and 360 degrees } Figure 26 - NQC Code: Function that makes the robot perform an anti-clockwise turn 51

60 void travelto(int xto, int yto) // // Performs navigation calculations, turns to face xto and yto then travels // forward to that point. // { // calculate the change in coordinates int xdiff = xto - x; int ydiff = yto - y; // work out distance to coordinate using pythag int distance; squareroot((xdiff*xdiff + ydiff*ydiff), distance); // work out angle to coordinates int alpha; invtan(xdiff, ydiff, alpha); // work out whether to turn clockwise or anti-clockwise int temp = alpha - angle; // convert temp into rotation between 0 and 360 while (temp > 360) {temp = temp - 360;} while (temp < 0) {temp = temp;} // if rotation clockwise is larger than 180 degrees then turn anti-clock, // else turn clockwise if (temp > 180) {turnanticlockwiseto(alpha);} else {turnclockwiseto(alpha);} // drive forwards for calculated distance driveforwardsfor(distance); // update coordinates for dead-reckoning (assuming reached target) x = xto; y = yto; } Figure 27 - NQC Code: Function that makes robot travel to a specific point on the pitch 52

61 void findball() // // Searches for the ball using a scanning technique then points towards it if // found. If ball is not detected first time the robot will move to the other // half of the pitch and scan that area. // { // Perform intial scan to decide whether ball is in view. scanforball(); // If the ballthreshold value was not breached then move to other half of // pitch and scan again. while (brightest < ballthreshold) { PlayTone(200, 40); // play a low beep to indicate unsuccessful scan } if (x < 59) { straightalongx(89); // center of second half scanforball(); } else { straightalongx(29); // center of first half scanforball(); } // Now ball is known to be in view turn to face it faceball(); } Figure 28 - NQC Code: Function that begins locating the ball void scanforball() // // performs ball scanning operation // { // This is done by rotating through 360 deg, recording the brightest light sensor // reading using a task. start lightsearch; turnanticlockwisefor(360); // NOTE: don't update angle since turn was 360 stop lightsearch; } Figure 29 - NQC Code: Function that makes the robot rotate whilst scanning for the ball 53

62 task lightsearch() // // task which looks at the light sensor reading every 5ms // brightest reading is recorded // { brightest = EYE; while(true) { if(eye >= brightest) brightest = EYE; Wait(5); } } Figure 30 - NQC Code: Task that reads the light sensor every 5ms, recording the brightest reading void faceball() // // Using the variable 'brightest' this function rotates untill the light sensor // exceeds or equals this value. // { // clear rotation sensor reading ClearSensor(ROTATION); // turn robot anti-clockwise Rev(LEFT); Fwd(RIGHT); On(LEFT+RIGHT); // If brightest not found then look for the next value down after a // complete rotation. until(eye >= brightest (EYE >= brightest - 1 && ROTATION > complete_turn_anti)); PlayTone(880, 20); Off(LEFT+RIGHT); // update angle for dead-reckoning (scaling up by 75 first then dividing at end) int alpha = (((75 * ROTATION) / complete_turn_anti) * 360) / 75; while (alpha > 360) alpha = alpha - 360; // in case the robot completed 2 or more turns angle = angle - alpha; // update angle (minus as turning anti-clockwise) } while (angle < 0) angle = angle; // always have angle between 0 and 360 degrees Figure 31 - NQC Code: Function that turns robot to face the ball 54

63 void gotoball() // // Drives robot forwards until touch sensor detects ball. After which it calls // the function grabball which does just that // { // clear rotation sensor ClearSensor(ROTATION); opengrabber(); // drive robot forwards (setting power levels to elimate drift first) SetPower(LEFT, left_power); SetPower(RIGHT, right_power); Fwd(LEFT); Fwd(RIGHT); On(LEFT+RIGHT); // the monitor command is used to wait for the ball being detected. Here also // I have included a tracking technique whereby the robot is constrained to // its SAFE ZONE inorder to avoid hitting any walls. This may be neccesary // if the ball is moved whilst the robot is moving blindy toward it. int distance, temp; int x2 = x; int y2 = y; monitor(event_mask(ball_in_grabber)) { // keep moving so long as the robot is within the SAFE ZONE while (x2 >= 20 && x2 <= 99 && y2 >= 20 && y2 <= 67) { distance = (10 * -ROTATION) / rots_per_ten_cm; // -ve going fwds } sin(angle, temp); x2 = x + ((distance * temp) / 100); // remember to divide by 100 cos(angle, temp); y2 = y + ((distance * temp) / 100); // again divide by 100 // play low beep indicating limit reached PlayTone(200, 20); } catch { // play high pitch tone to signal robot has detected the ball PlayTone(800, 20); // close grabber to collect ball (grabber stays on to grip ball) Rev(GRABBER); On(GRABBER); } // update the coordinates of the robot x = x2; y = y2; // turn off motors and reset power levels Off(LEFT+RIGHT); SetPower(LEFT, 7); SetPower(RIGHT, 7); // give grabber chance to get ball Wait(100); } Figure 32 - NQC Code: Function that drives robot forward until the ball is detected 55

64 void scoregoal() // // This function assumes robot has got hold of the ball. The robot travels to // a position in front of the opposition goal then shoots by moving forward // 10cm whilst releasing the ball // { // travel to position in front of goal then turn to face it travelto(90, 43); // rotate to 90 degrees either clockwise or anti-clockwise depending a shortest // route int alpha = angle - 90; while (alpha < 0) alpha; // convert angle between 0 and 360 if (alpha > 180) {turnclockwiseto(90);} else {turnanticlockwiseto(90);} /*** SHOOT - move forwards 10cm whilst releasing ball ***/ // Move first 5cm keeping hold of ball ClearSensor(ROTATION); SetPower(LEFT, left_power); SetPower(RIGHT, right_power); Fwd(LEFT); Fwd(RIGHT); On(LEFT+RIGHT); // After 5cm release ball but keep moving forwards until(rotation <= -(rots_per_ten_cm/2)); Fwd(GRABBER); On(GRABBER); // After 10 cm stop motors until(rotation <= -rots_per_ten_cm); Off(GRABBER); Off(LEFT+RIGHT); SetPower(LEFT, 7); SetPower(RIGHT, 7); // after shooting update postion x = x + 10; } Figure 33 - NQC Code: Goal Scoring Function 56

65 void sincos (int n, int &m) // // Simple lookup method for sine/cosine rules. Essentially the same as a sine // function. // // NOTE: This returns 100 times the value. A calculation using the output must // divide by 100 at the end. // { // convert angle to be within 0 and 360 range. This may be needed in cosine // when phase 90 added (see macros) while (n > 360) n = n - 360; // pos variable used to generate a negative value int pos = 1; // converts n to equivelent value of between 0 and 90 and changes the pos if (n <= 90) {} else if (n <= 180) {n = n;} else if (n <= 270) {n = n - 180; pos = -1;} else /* n<= 360 */ {n = n; pos = -1;} // final step by assigning the value of m if (n <= 6) {m = 5 * pos;} else if (n <= 12) {m = 15 * pos;} else if (n <= 18) {m = 25 * pos;} else if (n <= 24) {m = 35 * pos;} else if (n <= 30) {m = 45 * pos;} else if (n <= 37) {m = 55 * pos;} else if (n <= 45) {m = 65 * pos;} else if (n <= 54) {m = 75 * pos;} else if (n <= 65) {m = 85 * pos;} else {m = 95 * pos;} } Figure 34 - NQC Code: Sine/Cosine Function void squareroot(int n, int &m) // // calculates square root of number to nearest integer // { int d = 0; while (d*d < n) d = d + 1; m = d; } Figure 35 - NQC Code: Square Root Function 57

66 void invtan(int x, int y, int &angle) // // This function isn't exactly like inverse tan as it also takes into account // the pos/neg of the values // // NOTE: does not work for large distances. This is thought to be due to the // RCX's inability to deal with large integers. Limit seems to be x,y = 180. // { int tempx = x; // using these temp variables so pos/neg of x and y unchanged int tempy = y; // convert both x and y to positive values int temp; topositive(x, temp); x = temp; topositive(y, temp); y = temp; // check for obvious angles first and to avoid dividing by 0 if (tempx == 0 && tempy >= 0) {angle = 0; return;} else if (tempy == 0 && tempx < 0) {angle = 270; return;} else if (tempy == 0 && tempx >= 0) {angle = 90; return;} else if (tempx == 0 && tempy < 0) {angle = 180; return;} // perform division x/y but ten times larger temp = (10 * x) / y; // now lookup value if (temp <= 1) {angle = 3;} else if (temp <= 2) {angle = 9;} else if (temp <= 3) {angle = 15;} else if (temp <= 4) {angle = 21;} else if (temp <= 6) {angle = 27;} else if (temp <= 7) {angle = 33;} else if (temp <= 9) {angle = 39;} else if (temp <= 11) {angle = 45;} else if (temp <= 14) {angle = 51;} else if (temp <= 17) {angle = 57;} else if (temp <= 22) {angle = 63;} else if (temp <= 31) {angle = 69;} else if (temp <= 47) {angle = 75;} else if (temp <= 95) {angle = 81;} else {angle = 87;} // now account for the pos/neg value of x and y if (tempx >= 0 && tempy < 0) {angle = angle;} else if (tempx < 0 && tempy < 0) {angle = angle;} else if (tempx < 0 && tempy >= 0) {angle = angle;} } Figure 36 - NQC Code: Inverse Tangent Function 58

67 Appendix C Pictures of the Robot Figure 37 - View from above the robot Figure 38 - Side view of the robot 59

68 Figure 39 - Front view of the robot Figure 40 - Bottom view of the robot 60

69 Figure 41 - Top-down view of the robot with the ball 61