Autonomous Line Following Buggy

I

Embedded Systems Project

FINAL REPORT

Group Number: 6

GROUP MEMBERS:

Manyu Dang 9566467

Eric Mesquita 9568669

Hani Qadiri 9066907

Vishisht Tiwari 9109605

Cai Willis 8473412

Tutor: Dr Judith Apsley

Date: 08/05/2014

School of Electrical and Electronic Engineering

II

Table of Contents Embedded Systems Project ................................................................................................................ I 1.0 Introduction .................................................................................................................................... 1

1.1 Executive Summary ............................................................................................................................. 1 1.2 Introduction ......................................................................................................................................... 1 1.3 Aims and Objectives ............................................................................................................................ 2

2.0 Final System Components Summary ................................................................................................ 3 2.1 Mechanical .......................................................................................................................................... 3

2.1.1 Restructured Components/Features ........................................................................................... 3 2.1.2 Non-‐Restructured Components/Features (Successfully Working Components/Features) .......... 3

2.2 Electronic ............................................................................................................................................. 4 2.2.1 Line Sensing Circuit ...................................................................................................................... 4 2.2.2 Speed Sensing Circuit .................................................................................................................. 5 2.2.3 Ultrasound Sensor ....................................................................................................................... 5 2.2.4 RF link(Radio-‐Frequency Link) ..................................................................................................... 5

2.3 Navigation and Control ....................................................................................................................... 6 2.4 Software .............................................................................................................................................. 7

2.2.4 Programming features ................................................................................................................ 7 2.2.4 Challenges of programming ........................................................................................................ 8

3.0 Team Organisation and Planning ..................................................................................................... 9 4.0 Budget vs. Outturn ........................................................................................................................ 10

4.1 Proposed Budget v/s Final Cost ......................................................................................................... 10 4.2 Total costt of Buggy .......................................................................................................................... 11

5.0 Race Analysis ................................................................................................................................ 12 5.1 Testing ............................................................................................................................................... 12

5.1.1 Challenges during testing .......................................................................................................... 12 5.2 Preparation for first heat .................................................................................................................. 12 5.3 First Heat ........................................................................................................................................... 13 5.4 Preparation for second heat .............................................................................................................. 13 5.5 Second Heat ...................................................................................................................................... 13

6.0 Critical Analysis ............................................................................................................................. 14 7.0 Successful Innovative Feature ........................................................................................................ 14 8.0 Conclusion ..................................................................................................................................... 15 9.0 References .................................................................................................................................... 15 10.0 Appendix ..................................................................................................................................... 16

10.1 Updated Engineering drawing for Acetal chassis ............................................................................ 16 10.2 Updated Engineering drawing for Upper Plate of the chassis ......................................................... 17 10.3 Updated Line Sensor Board Diagram .............................................................................................. 18 10.4 Updated Line Sensing Circuit Board Diagram ................................................................................. 18 10.5 UpdatedSpeed Sensing Board Diagram .......................................................................................... 19 10.6 UpdatedSpeed Sensing Layout Diagram ......................................................................................... 19 10.7 Updated Line Sensing Circuit Layout Diagram ................................................................................ 20 10.8 Updated Line Sensor Layout Diagram ............................................................................................. 20 10.9 Updated Wiring Diagram ................................................................................................................ 21 10.10 Pseudo code .................................................................................................................................. 21

1

1.0 Introduction 1.1 Executive Summary

Using innovative techniques such as the inclusion of an ultrasonic sensor, an RF-‐link and by creating an overall efficiently compact design, Group 6 has accomplished the given task of building a line following autonomous buggy. This documentation is an in depth evaluation of the methods used to complete this given primary task. Included are detailed sections of how this was accomplished from the mechanical, electrical, navigational strategy and software aspects of the buggy. The successes and the failures of the chosen strategies faced during the design and assembling processes are discussed and the solutions conceived to solve them. By comparing the group’s project plan as proposed in the proposal and the final outcome of the buggy, the effectiveness of the overall group work is demonstrated. Furthermore, a detailed report is given on the budget, how much the buggy was proposed to cost, the difference in the outcome price and the reasons for the increase in price. Finally, there is a detailed analysis on how the buggy was prepared for the race and exploring the possible reasons for its performance. Overall, the buggy was ranked at fifth place with two times at 8.3 and 7.1 seconds, when a faster time was expected. During the first semester, the group worked towards the completion of the overall mechanical design and planning for the manufacture of the buggy. The main obstacles were extracted from the handbook and the group used these to determine the design of the buggy. An example of this would be the vital information of the allocated distance at the end of the track within which the buggy had to come to a stop. An ultrasonic sensor was used to give the buggy sufficient means of stopping within the desired space. The properties of the gearbox were determined to obtain the desired torque. Research was undertaken to determine the sensors required for the optimum race performance from the buggy. The first half of the second semester was used to fully manufacture the buggy. Separately assembling the different aspects of the buggy – mechanical, electronic and even software – and then combing together to create a fully functioning system, that meet the requirements of the project deliverables. From week 7, full concentration was given to the completion of the buggy’s software to implement an effective PID control that would navigate the buggy around the course in the quickest possible time. Overall, the group was able to achieve all aims; except reaching the finals.

1.2 Introduction

During semester 2, group 6 has been working towards fully completing the manufacturing and software for the buggy, so that it is sufficiently ready to give an excellent performance on the day of the heats. Unfortunately, despite the hard work and dedication shown by the group members, group 6’s buggy – The Flying Duchess – did not qualify for the final race. The buggy was designed to be compact, with a slick, neat design that distributes the weight sufficiently to keep the buggy well balanced with a low centre of gravity. PID control was used to navigate the buggy

around the track, which will be discussed in further detail in the software aspect of the Final Components Summary. Having efficiently used the allocated time in the lab per week, personal time and the supervisors’ help to overcome certain problems with the RF-‐Link, a buggy was built that met the criteria set by the group and the project’s demands.

Fig. 1. Overview photo of the buggy

2

1.3 Aims and Objectives

The group was given the initial task to build a line following autonomous buggy able to manoeuvre obstacles of a constructed course. Following are the projects demands for the specifications of the desired buggy:

• Driven by batteries • Navigate by identification of a white line • Capable of turning, going up the slope, going over the small line gap • Successful navigation of a full track by overcoming obstacles by using six sensors only • Stopping within the allocated distance • Remaining within a budget of £50

With the project demands in mind, an overall of four primary aims were set by the group:

1. Build a line following buggy 2. Competitively complete a given course in order to reach the finals 3. Use only 6 line sensors or less, abiding to the given constraint 4. Use innovative solutions to decrease the overall buggy size and number of line sensors used,

whilst maintaining a highly efficient product able to meet the specifications of the given task

The following deadlines were set as part of the overall embedded systems project:

1. Tech demo #1 -‐ Demonstration of a functional speed sensing circuit 2. Design report #1 -‐ a technical report discussing the required combination of gears, based on test

results and calculations from the motor characterisation lab 3. Design report #2 – a technical report discussing the given choice and arrangement of sensors,

the design of the sensor interface circuits and the chosen strategy track navigation 4. Proposal report – An official documentation proposing the buggy as a solution to meet the

desired specifications, intending to receive funding for the project 5. Tech demo #2 – Demonstration of functioning motor control 6. Tech demo #3 – Demonstration of line sensing, by visually presenting the reactions of the line

sensors used 7. Tech demo #4 – Demonstration of the buggy following a white line against a dark surface, not as

demanding as the heats or the final race, however, just a simple demonstration that the buggy is able to follow a line

8. Tech demo #5 – The Heats, a three part course determining the buggies sufficient to compete in the final race on the harder race track

9. The Final Race – competing for the fastest time of completion around a given course containing several obstacles such as a see-‐saw ramp and a windy slope

These soft deliverables were at the core of the group’s project plan. They were used as a rough guideline to set goals, objectives and helped determine deadlines for the completion of different aspects of the buggy. Using the list of aims, the project demands and the required deliverables, the following objectives were set:

-‐ Designing and building an accurate speed sensing circuit to be implemented in the buggy -‐ Designing a chassis that is well within the track width decreasing the risk of impact with the

boundaries -‐ Designing a battery box that encloses the batteries safely ensuring they will not fall out during

either the heats or the race -‐ Designing the necessary PCBs for the speed sensing and line sensing circuit, that will be efficient

in practical use and space -‐ Assembling the buggy – putting together each complete aspect of the buggy (the mechanical

and the electronic)

3

-‐ Writing a C program implementing PID control that will sufficiently navigate the buggy around the course following the white line

-‐ Using the allocated time in labs to the highest degree of efficiency to meet the deadlines set both personally for the group, and the overall deadlines set for the project (as stated above)

-‐ Budgetary planning to ensure that the group does not spend over the give budget of £50

2.0 Final Systems Components Summary 2.1 Mechanical

The mechanical aspect of the buggy went through a major overhaul during the second semester of the project. The buggy now consisted of two levels of acetal plates carrying different components. The first level(bottom plate) was fitted with the motor drive board and the battery box while the second level(upper plate) was fitted with the RF link, microcontroller board and breakout board. Battery Box is another innovative feature that was introduced in the second semester of the buggy to carry and replace batteries in an easy yet safe way. However, few features of the buggy such as placement of line sensing circuit board between the two front wheels and gear-‐ratio worked well for the purpose of line following, climbing up the slope and descending down the slope and hence was continued to be used in the buggy.

2.1.1 Restructured Components/Features

Components that did not work as planned and have gone through restructuring during the second semester have been discussed below in detail:

Chassis:

The chassis width size was decreased in order to improve the maneuverability and reduce the probability of the buggy crashing into pinch-‐points. Also, the modified shape of the chassis is symmetrical which provided a better balance to the buggy.

Front Wheels

Initially, the group planned to use a caster wheel for the front wheel, believing it to easily adapt to a change in direction. After comparing with the other components provided in the workshop, it was decided instead to use 0.5” ball bearing as the front wheel. This was due to two main reasons; first, the weight of ball bearing is lighter than the caster wheel, reducing the overall load of the buggy. Secondly, after testing, it was found that the ball bearing could provide smoother turning than the caster wheel.

Battery Box:

According to the proposal report, the battery pack was supposed to be on the upper plate of the buggy. However, having decided to add an RF link board, there was no longer enough space on the upper plate. The group sat down together to discuss how to overcome the problem at hand, which was where to place the batteries. It was concluded by agreeing to place the batteries inside a box that would be sturdy enough to not open in the middle of a race and that could be easily opened when needs be to recharge the batteries. The battery box was placed at the bottom of the chassis, and since its weight was quite large, this change also lowered the centre of gravity of the buggy, making it more stable in a dynamic system.

2.1.2 Non-‐Restructured Components/Features (Successfully Working Components/Features)

Few components in the buggy worked the way they were expected. These provided an added advantage to the buggy and hence were continued to be used in the buggy:

4

Gears:

In the proposal report, it was determined that the gear ratio of 1:15.6 would be the optimum in gear ratio for providing enough torque to go up the slope and enough speed on the straights. Gears to be used for the construction of the gearbox were: 16 tooth pinions (motor shaft only); 50/10 free running gear (grey); 50/10 press fit gear (red). This gear combination provided the right balance between torque and speed and hence was continued to be used in the buggy.

Sensor Board Placement:

Placement for the sensor board, in the proposal report, was decided to be between the two front wheels. This feature was expected to provide greater accuracy of line sensing, as the sensors would be able to detect any slope changes in the course without losing the track. This feature also worked as expected and was continued to be used in the buggy. The board however was divided into two different PCBs. One contained the sensors while the other contained the circuit for the sensors.

2.2 Electronic

The electronic circuits used in the buggy did not see such a drastic overhaul like the mechanical components of the buggy did. However, one change from the proposal report was the use of PCBs instead of stripboard. All the circuits used in the buggy including line sensor board, speed sensor board and circuit board were all designed on Altium software and then constructed on PCBs. This decision was taken after analysing the reliability, clean and easy arrangement, and quality of the PCBs. Each electronic component of the buggy has been discussed in detail as follows:

2.2.1 Line Sensing Circuit

As discussed in the proposal report, the TCRT5000L, a Reflective Optical Sensor with Transistor Output, remained as the line sensor in use for the line sensing circuit. This choice was made having tested all other potential sensors. This sensor proved to be the most sensitive to reflective differences in track surfaces i.e. it was the most effective at detecting the white line. Furthermore, it was self-‐illuminating, containing an IR emitter as well as receiver, in a compact case reducing the space needed for the circuit. 5 of these sensors were used for the purpose of line following and were arranged as shown in figure 6. The circuit for all the sensors was unchanged from proposal report. A 100Ω resistor was used to convert the maximum amount of light intensity so that the maximum forward current is 60mA. A 4.7kΩ-‐resistor was used in series with the phototransistor, configured as a potential divider to work out the maximum difference in output values obtained when sensing white and black surfaces. For digital sensors, comparator LM311 was used to convert the output from sensors to logic level 0 or 1 where 0 logic level means black surface while 1 logic level means white surface. The circuit diagram for Digital sensors has been shown in figure 3. A full circuit diagram for all line sensors can be found in appendix10.3 and 10.4.

Fig. 3. Circuit Diagram for Digital Sensors

Fig. 2. Gearbox

R1100Ω

R24.7kΩ

TCRT5000L

VSS5V

LM311N-14

B/STBVS+

GND

BAL

VS-

3

4

6

11

9

2

7 839kΩ

100kΩKey=A 10 %

300kΩ

Output

5

The sensors were connected to the breakout interface (PORTA &PORTJ) as shown in the wiring diagram in appendix 10.9. The analogue sensors were used as analogue inputs(PORTA) to implement the PID control while the digital sensors were used as digital inputs(PORTJ). When designing the PCB for the line sensor circuit, it was separated into two boards where one contained five sensors section while the other contained the rest of the circuit. This change increased the space efficiency on the buggy and also meant there was enough space for the ultrasonic

sensor. The two PCBs were connected using Molex connector. An image of the line sensing circuit has been shown in figure 4.

2.2.2 Speed Sensing Circuit

The circuit for the speed sensing from the proposal report has been unchanged. For the speed sensing circuit, the IR emitter TEKT5400s and IR receiver TEKS5200s was used. The emitter is connected 100Ω resistor and receiver is connected to 4.7kΩ resistor. The output is connected to PORTB in the breakout interface board. The left wheel speed sensor circuit and right wheel speed sensor circuit were integrated into one PCB to save space. The circuit diagram for speed sensing circuit can be found in appendix 10.5.

2.2.3 Ultrasonic Sensor

The new electronic innovation that has been introduced in the buggy in second semester is the introduction of the ultrasound sensor. This was a new idea and was never discussed in the proposal report. The high mass and hence high momentum at high speed was proving it to be difficult for the buggy to stop within the defined range of 20cms. The ultrasonic sensor was used to allow the buggy to go at a higher duty cycle whilst still having the capability to stop at the end of the track. It works by transmitting an ultrasound wave, which is then reflected directly back from the barrier at the end of the track. Since the speed of the sonic wave is known it can be used to calculate the distance to the barrier, assisting the line and speed sensors to provide a higher level of precisions and navigational control.

2.2.4 RF-‐Link (Radio-‐frequency link)

An RF-‐link (Radio-‐frequency Link) was also implemented allowing for wireless control under a specific frequency. The RF-‐link contains the microchip MRF24J40MB module, which uses the microchip MIWI protocol. The SPI port is used to transfer data between the PIC and the MRF24J40MB; as a result the position information can be identified and manipulated. The controller for the buggy was made using the I/O board used in the microcontroller project in 1st year. The potentiometer in the I/O board was used for varying straight-‐line speed while two push buttons were used for turning the buggy. Another toggle switch was used to change the buggy from line following mode to remote control mode in case it needed to be used for the final race. The 8 LEDs and 7-‐segment display on the I/O board were used as a debugging tool. Important information such as speed of both the motors, the sensitivity of the sensors etc. was obtained easily using RF. Values of integral and derivative helped to get the PID control of the buggy better and made the programming process much easier.

Fig. 4. Two different PCBs for line sensors

5

Fig. 5. Ultrasonic Sensors HC-SR04

6

2.3 Navigation and Control

The final navigation system implemented on the buggy is demonstrated by figure 6. Navigation is executed via five TCRT5000L optical sensors used to determine the buggy’s position on the line and aid in tackling obstacles of the course. The sensor bank consists of a central digital sensor, two analogue sensors

and two outer digital sensors positioned less than a line width away from each analogue sensor to aid in regaining a lost line.

Requirements for the navigation system were determined by a list of likely and worst case scenarios that the buggy might encounter such as sharp turns, line breaks, long fast straightways and the end of the track.

The analogue sensors either side of the line are capable of providing readings sufficient to determine relative position of the line and provide a basis to implement some variation of PID control. These sensors are read by the PIC18F8722’s analog to digital converter, compared and used in calculations to maintain a steady path along curves and increase speed along straight sections of the track.

The outputs of the digital sensors are fed into comparators in order to create a digital signal to be read by the microcontroller. The sensitivity of the

comparators can be adjusted via a potentiometer. The central digital sensor is therefore sensitive enough to maintain a perception of the line across the maximum line-‐break distance. This sensor is also used in deducing the true end of the line. The outer digital sensors are intended for situations in which the buggy has strayed too far either side of the line or even left the line completely. In the case of either of the outer digital sensors being the last sensor to give a reading, the buggy will continue turning until the line has been found again.

The initial design for the layout of the sensors given in the proposal report is shown in figure 7. Some subtle changes have been made to the layout of the sensors and very little has been altered in terms of overall navigation strategy. The first change made was to remove the second digital line sensor as it was discovered that the cone of light emitted by a single TCRT5000L sensor was sufficiently large to maintain a signal across the biggest gap when the sensitivity of the comparator circuit was adjusted. The second central digital sensor was rendered obsolete and could thus be omitted, simplifying the control program somewhat with no effect on performance. The positioning of the sensors was also adjusted, bringing the analogue sensors closer towards the center and adjusting the outer digital sensors accordingly so that they too were closer to the center and, crucially, less than the line’s width away from the analog sensors. The analogue sensors are now 12mm from the center and the outer digital sensors are 18mm from the respective analogue sensors. The original design had a sensing dead zone physically built in to

Fig. 6. Present Sensor arrangement

Fig. 7. Past Sensor arrangement

7

the sensor array, and the adjustment was made to allow a dead zone to be implemented or adjusted as required in software. The outer digital sensors were originally intended only to provide an increased response in the case of the analogue sensors using the line, but are also now used in regaining the position of the line once it is lost.

In addition to the sensor bank, the buggy uses a HC-‐SR04 ultrasound sensor placed at the front of the chassis which is intended to inform the microcontroller that a barrier is close in front and that the buggy should slow down. This ensures that the buggy is able to stop within the required 20cm, and is potentially also useful in slowing the buggy for sharp corners.

2.4 Software

Software programming was one of the most integral and important part of the project. Using the sensor outputs to make the buggy follow the line was accomplished with the help of software programming. The main aim of the buggy was to follow the line without the unnecessary oscillations, take the turn smoothly and use speed sensing to be able to go up a slope. As an extra feature, the buggy also had an RF link board fitted to it and could be controlled using a remote control.

2.4.1 Programming Features

The main features of programming of the buggy has been discussed below:

Line Following:

All the line sensors were used for the purpose of following line. As seen from figure 6, the middle digital sensor was used to detection of the end of the line. The analogue sensors main objective was to reduce the oscillations in a straight line and provide a smooth turning at curves. The last digital sensors were programmed to be used as a overshooting sequence. In case the looses the line at a corner, the buggy was programmed to come back to the line but middle sensor still helped it to stop in the end of the line. For reducing the oscillations PD(Proportional-‐Derivative) controller was used. The PD controller obtained error from the middle two analogue sensors and controlled the duty-‐cycle to the motor to obtain oscillation free and fast movement of the buggy. The proportional was used for turning while the derivative was used for reducing the oscillations. The proportional part of the control systems worked by multiplying the error by a certain value to be able to make a turn. The derivative on the other hand finds the difference between last error and present error and tries to minimize this difference. PD control instead of PID control was decided to use as it was observed that I(integral) control did not contribute towards either reducing oscillations or improving buggy control and hence was not used.

Speed Sensing:

Maintaining a constant speed up and down the slope was an important requirement for the buggy to be able to complete the track. Losing or gaining speed on a slope could result in increased oscillations of the buggy and hence losing the line. For this purpose speed sensing was an important part of the buggy. Speed sensing was implemented by using interrupts. Every rising edge caused an interrupt and incremented the counting. After every half a second this value was obtained, RPM was calculated and speed was changed accordingly. The error obtained used a P(Proportional) controller to control the speed.

RF link:

Another extra feature of remote control was added in the buggy in case it was not able to complete any specific part of the final track. The controller for the buggy was made using the I/O board used in the microcontroller project in 1st year. The potentiometer in the I/O board was used for varying straight-‐line speed while two push buttons were used for turning the buggy. Another toggle switch was used to change the buggy from line following mode to remote control mode in case it needed to be used for the final race.

8

2.4.2 Challenges of Programming

Achieving the right values for Kp(proportional constant), Ki(Integral Constant) and Kd(derivative constant) in PID(Proportional-‐Integral-‐Derivative) control for line following:

Achieving right values of Kp, Ki and Kd in PID control was important in implementation of oscillation less and fast movement of the buggy. Calculating Kp, Ki and Kd using trial and error was one of the most difficult part of the programming and needed many iterations before achieving the right values. It is important to note that the values in table has been deduced for 70% straight-‐line duty-‐cycle of the buggy. The values have to be tweaked for changing duty-‐cycle.

During the initial tests, very high oscillations and large turning radius were observed. The oscillations were reduced by increasing the values of Kd. It was observed that increasing Ki or Kd to a very high value increased oscillations as well. Increasing Kp values reduced the turning radius and helped the buggy take sharper turns with ease and speed. It was also observed that Ki did not contribute towards reducing turning radius and in some cases, worsened the oscillations. Hence it was decided to not use integral control and manoeuvre the buggy using just PD control with Kp value as 21 and Kd value as 132. It is important to note the values of Kd was tweaked according to changing duty-‐cycle. Increasing duty-‐cycle led to increased Kd value to maintain the low oscillations

Implementing RF link and speed sensing simultaneously:

Both, RF link and speed-‐sensing used interrupts and implementing both the features without interfering with the movement of buggy was proving difficult to achieve. The buggy seemed to get stuck in a loop of RF and would not come out of the loop unless the programme is reset. It was found that the loop involved transmitting data from the buggy. It was deduced that ‘if speed-‐sensing is used then the buggy would not be able to send data to remote control and hence the remote control would not be able to used as a debugging tool’. This problem could not be solved and a decision was taken to use remote-‐control as a debugging tool only when needed. At all other times the speed sensing would work in which the remote control will still be able to control the buggy but would not be able to receive any data from the buggy.

Implementing overshooting sequence:

Another challenge for the buggy was to take very sharp turns at high speeds. This was normally the case of an s-‐bend after a long straight. To be able to overcome this problem, an overshooting tool was used in the buggy. According to this feature, if the buggy left the white line at a corner then the end digital

Kp Ki Kd Oscillation Turning Radius 2 0.4 0.1 Very High Oscillations Large Radius 5 0.4 0.5 Very High Oscillations Large Radius 10 0.8 2 Very High Oscillations Medium Radius 15 0.8 10 High Oscillations Medium Radius 18 0.8 30 Medium Oscillations Small Radius 20 0.8 50 Medium Oscillations Small Radius 20 2 50 High Oscillations Small Radius 20 0.8 90 Medium-‐Low Oscillations Small Radius 20 0.8 120 Low oscillations Small Radius 20 0.8 130 Very Low Oscillations Small Radius 20 0.8 140 Medium Oscillations Small Radius 20 0.8 132 Almost No Oscillations Small Radius 21 0 132 Almost No Oscillations Small Radius

Table. 1. Different values of PID constants and their effects

5

9

sensors would be the last sensor to have sensed the line. In this case, the buggy would try to re-‐join the line. However, if any of the middle 3 sensors were the last sensors to sense the white line, then the buggy would consider that as the end of the line and would stop.

3.0 Team Organisation and Planning

In terms of requirements, it was quickly determined that the project could be divided into mechanical, hardware and software components. Each component could be further subdivided into specific tasks such as assembly of the battery box and gearbox for the mechanical aspect, design and soldering of PCBs as hardware tasks, and so on. Collective decision of dividing the work among the group members was taken. Each group member discussed the aspect they were interested in and accordingly work was divided among the members. During all times, 2 group members were focused on the software programming of the buggy while other 3 members worked on mechanical and electronic aspects if the buggy. The group had set different goals for completing all the mechanical, electronic and software requirements. The mechanical aspect of the buggy such as the gearbox, the chassis etc. was aimed to be finished by the 3rd week while the electronic parts such as the sensor PCB, speed sensing PCB etc. was aimed to be finished by 6th week of the second semester. Software, on the other hand, was worked on during the whole semester.

Fig. 8. Gantt Chart

5

10

Each member was shared into sub-‐groups to tackle each component while interacting regularly and reporting to the others. Communication was conducted via WhatsApp, thus quick meetings could be called at short notice, which proved to be a very efficient process. All the data including PCB files, software codes, solidworks file were at all times uploaded to the common Dropbox account and was updated as soon as any changes were made. The available laboratory sessions were used to full affect with the group split between each of the three laboratories depending on their specific tasks. Meetings were often held outside laboratory sessions to consolidate the work done in each component and for each group member to gain and provide insight in every aspect of the buggy. Due to regular communication and the enthusiasm of the group in general, it was possible for every group member to be involved in design decisions such as PCB placement and chassis construction.

Towards the end of the semester, when the buggy’s construction was complete and only software testing remained, very few construction and design modifications were required, which meant that some group members were left with little to do during laboratory sessions. This was resolved by the decision to start the writing of the final report early so that all group members could contribute to the project when the hardware and design aspects of the project were completed. Regular meetings were still held to discuss the buggy’s progress and make alterations as required.

The Gantt chart constructed in semester 1 shown in figure 8 remained largely accurate in terms of its overall scope. Work in the laboratory sessions was always geared towards completing the next technical demonstration and each of the deadlines was successfully achieved on or before the specific date. The group’s achievement of consistently high marks in all technical demonstrations supports this. The only major difference in the proposed organisation shown in the Gantt chart and its realisation is the number of hours spent on each task. The group consistently went above and beyond what was merely “required” by the task in order to perfect everything from the construction of a battery box to drilling holes and using cable ties to keep the wiring looking neat. Another difference was that the buggy’s control software was started from the very beginning of the project and was developed alongside the software required for technical demonstrations.

4.0 Budget vs. Outturn 4.1 Proposed Budget v/s Final Cost

Comparing changing item price table Proposal report Final report

Item Quantity Individual price (£)

Total cost (£)

Item Quantity Individual price (£)

Total cost (3)

Acetal board

3 (total 200mm*200mm)

0.575 (per m!)

2.3 Acetal board

11 (total 350mm*300mm)

0.575 (per m!)

6.1

Strip board

2 2 4 PCB board

4 3 12

Caster wheel

2 2 4 Ball bearing

2 1 2

Line sensor TCRT500

0

6 0.5 3 Line sensor

TCRT5000

5 0.6 3

RF-‐link board

1 4 4

Ultrasonic sensor

1 2.5 2.5

Total £13.3 Total £29.6 Table.2. Comparing changing item price table

5

11

The reason for the difference between the outturn and proposal cost is mainly due to the increase in the mechanical cost. This is because a lot of acetal was used for creative designs to solve some of the design problems faced. One example being the battery box; an enclosure that could withstand stress and protect the batteries during the course of the track effectively whilst still being easily accessible was needed, and so a boxed compartment was made for them out of acetal. Replacing strip board with PCB also increased the overall cost. The addition of the RF link and the ultrasonic sensor was decided later in the design process, and so increased the outturn cost. Despite these changes resulting in a higher overall cost, it resulted in a buggy that is believed to be more effective and efficient at meeting the aims set at the beginning of the project.

4.2 Total cost of the buggy

Outturn final report Item Quantity Individual price (£) Total cost (£)

Acetal board 11 (totally 350mm*300mm)

57.5 (per m!) 6.1

PCB board 4 3 12 Ball bearing 2 1 2

Line sensor TCRT5000 5 0.6 3 IR emitter sensor

TSKT5400S 2 0.5 1

RF-‐link board 1 4 4 Ultrasonic sensor 1 2.5 2.5

Resisters & Capacitors (various value)

50 0.03 1.5

Comparator 6 0.02 1.2

Molex pin header 5 0.02 0.1 Screw 30 0.02 0.6 Nut 30 0.02 0.6

Washer 10 0.03 0.3 Gear 2 sets Workshop item

Drive board, breakout interface, micro-‐control

board

1 Workshop item

Batteries and battery pack

1 Workshop item

Motor 2 Workshop item Total £34.9 £32

Because the budget is strictly limited £50, other methods were found to make sure the budget does not exceed. This included using recycled items available in the labs such as nuts, screws, washers etc. Assuming the items mentioned above are recyclable, the overall final outturn is approximately £32 and not £34.9

For manufacturing 100 buggies, it will be assumed that no recyclable items will be used. Hence cost of 100 buggies would be 100 x £34.9 = £3490

Table.3. Total Budget table

5

12

5.0 Race Analysis 5.1 Testing Testing of the buggy mainly involved achieving the right values of Kp and Kd for achieving minimum oscillations and fast movement. As discussed in table 1, many iterations of trial and errors were done to achieve the Kp value of 21 and Kd value of 132. With these values, the buggy was able to achieve smooth turns and high speed in straight lines in different rooms with different ambient light. Another important testing criteria was to decide the use of speed-‐sensing circuit and achieve the right speed that would be followed through out the track. This was done using the innovative debugging tool that the team had developed-‐RF link. After achieving the right values and testing on small tracks, the buggy was tested on longer tracks(track in C34). On its first few trials, the buggy achieved good speed and was able to take all turns smoothly. However, few challenges surfaced during this test. The problems have been discussed below in detail

5.1.1 Challenges during testing

S-‐bends:

During testing on tracks in C34 workshop, it was observed that the buggy was not able to complete the s-‐bends. The buggy was programmed with overshooting sequence for such turns but the turning radius was not small enough for the buggy to take the turn. After decreasing the turning radius by changing the duty-‐cycle of the motors, the buggy was successfully able to take s-‐bend turns and all other turns.

Stopping in 20cms:

Another challenge that was uncovered during testing was the buggy’s incapability to stop within 20cms at high speeds. At its highest possible straight-‐line speed the buggy was not able to stop within 20cms.

Many different programming ways were tried to tackle the problem such as turning the buggy or reversing the buggy at the end. All these ways were either not reliable or started disturbing buggy’s movement in the middle of the course. To tackle this problem the team came up with the idea of using an ultrasonic sensor. The ultrasonic sensor slowed the buggy down if any wall was sensed within 30cms of the front of the buggy. It is important to note that the ultrasonic sensor did not stop the buggy but only slowed the buggy down; the stopping sequence was still achieved using the line sensors. This feature successfully worked as the ultrasound sensor slowed the buggy down before the end of the track and line sensors were able to

stop the within the defined space of 20cms.

5.2 Preparation for first heat As a group, it was decided to use the first heat to complete the track and not concentrate on setting a fast time. The following changes were made to the programme of the buggy to make sure the buggy completes the track:

• The straight-‐line duty-‐cycle was reduced to 50% and turning duty-‐cycle was also reduced accordingly to ensure smooth moving buggy.

• The value of constant Kd was also decreased to ensure oscillation free movement of the buggy.

Fig. 9. Buggy taking the S-bends

Fig. 10. Buggy going up the slope

13

• For the first heat, the function of ultrasound sensor of slowing down the buggy was not used. Because it was decided that the buggy would not be running at high speed, there was no need for the ultrasound sensor to unnecessarily slow the buggy down. The line sensors would be able to stop the buggy without any help.

5.3 First Heat The buggy was able to overcome every obstacle and stop in the end without any difficulty. Buggy’s performance through each obstacle has been discussed below:

• Straight section of the track: The buggy showed decent speed and very little oscillations on the straight section of the track.

• Pinch-‐Points: The sleek body shape of the buggy and its dexterity in following line proved the pinch-‐points to be of no danger and the buggy was successfully able to manoeuvre its way through the pinch-‐points.

• Turns: The turns on the track also proved to be of no problem for the buggy. All the turns were easily taken by the PD controller of the buggy.

• Slope: The speed sensing worked well during the up-‐slope section of the track and increased the speed of the buggy accordingly. The change in the speed of the motor was almost instantaneous showing the working of P(proportional) controller in speed control. This helped the buggy in maintaining the speed without oscillating and hence was able to complete the track.

• Stop: The buggy stopped well before the 20cms mark. This was due to the slow speed of the buggy on straight line.

The buggy was successfully able to complete the track in a respectable time of 8.3 seconds. With this time the buggy was 5th fastest among all the buggies in stream A. The next step was to make the buggy faster.

5.4 Preparation for second heat For the second stream, the group decided to make the buggy faster to confirm a place in the final race. The following changes were made to the programme of the buggy to make the buggy faster and still able to complete the track:

• The straight-‐line duty-‐cycle was increased to 90% and turning duty-‐cycle was also increased accordingly to ensure smooth moving buggy.

• The value of constant Kd was also increased to ensure oscillation free movement of the buggy. • For the second heat, the function of the ultrasound sensor was decided to be used and hence

was included in the program.

5.5 Second Heat In the second heat, the buggy was able to complete the track and stop in the end with a faster lap-‐time. The buggy over-‐all looked faster in the turns and slope but took greater time to achieve top speed on straight line. Buggy’s performance through each obstacle has been discussed below:

• Straight section of the track: The main problem for the buggy during the whole course was the oscillation on straight line. Buggy’s settling time, compared to heat 1, was more this time and hence made the buggy slower on the straight line.

• Pinch-‐Points and Turns: Pinch-‐points and turns again did not prove to be any problem for the buggy and was able to manoeuvre its way through with much more speed this time.

• Slope: Comparatively much less oscillations were observed on straight line of the slope than the straight line on the flat surface. On the slope the buggy was much faster than in first heat and made up for the time lost on straight line.

14

• Stop: Ultrasound sensor worked well for the stopping, as the buggy was able to stop almost 5cms before the end of the wall. The stop was almost perfected and proved that the decision of using ultrasound sensor was the right one.

The buggy was successfully able to complete the track in a fast time of 7.1 seconds. Unfortunately the time was again 5th fastest in stream A and hence was not fast enough to be qualified for the final race.

6.0 Critical Analysis The buggy was able to complete the track with ease; however, not reaching the final race was a disappointment. Thorough analysis of the heats has been done below:

The buggy was fast everywhere on the track, except on the straights paths. The buggy oscillated more than expected costing time and place in the finals. The possible reasons for this behaviour might be the reflected infra-‐red from the sunlight. The race was the first time the buggy was tested in a room with sunlight. Because the two analogue sensors were used for keeping the buggy on a straight line, additional reflected infrared from the sunlight might have affected the PD control systems. An alternative that could have led to a faster time may have been to run the buggy at a lower duty-‐cycle. The buggy would have lost time at the turns and slope but would have made up for it on the straights and might have posted a faster time.

The buggy, on the turns, was reasonable fast and was able to overcome almost any kind of turns using the overshooting sequence as discussed before. Buggy, with the help of the speed sensing, was also very fast on the up slope and it would have been very difficult to make the buggy even faster on the turns and slopes.

Another big challenge the buggy faced was the stopping of the buggy. The buggy was comparatively a little bit heavier than expected and this greater mass resulted in difficulty to stop the buggy down. This greater mass could have been the result of the RF link board and the battery box. The buggy could have been made lighter but group 6 found another innovative feature to tackle this problem using the ultrasound sensor as discussed above. The sensor worked perfectly in stopping the buggy within the required distance and was one of the best feature of the buggy.

7.0 Successful Innovative Feature Group 6 introduced many innovative features in the buggy that helped the buggy more reliably complete the track at a faster speed. The innovative features have been discussed below:

RF link used as debugging tool: Group 6 has been able to ease down the process of debugging which otherwise is very difficult with MPLAB. Group 6 has used the RF board along with the microcontroller board and I/O board to obtain important information about the buggy which made the programming process very easy. Important information such as speed of both the motors, the sensitivity of the sensors etc. can be obtained easily. Values of integral and derivative have helped to improve the PID control of the buggy. Obtaining timer information from the microcontroller of the buggy has made the programming process much easier. After all this, the RF link can simultaneously, change the speed of the buggy, make it go left right or go back with varying speed. The line following mode and the remote control mode can be changed with just 1 switch. Ultrasonic Sensor as a means for stopping within 20cms: Stopping the buggy in the limited amount of space was one of the main challenges of the buggy. Group 6 has tackled this using an ultrasonic sensor. The ultrasonic sensor is able to measure the distance between the buggy and the front wall in every 10𝜇𝑠. The sensor slows the buggy down if it senses a wall in 30cms from the buggy. It is important to note that the sensor does not stop the buggy but only slows it down. The stopping feature is still done by the line sensors.

15

Overshooting sequence: Group 6 had developed a feature to make the buggy complete the track in a more reliable way. Overshooting sequece is a programming feature that helps the buggy to take sharp turns at high speeds. This feature relies on the fact that if a buggy overshoots a line at the corner, the last sensor sensing the line would have been one of the end sensors. If such is the case, the buggy would try to rejoing the track by taking a sharp turn in the direction depending in the sensor that sensed the line. If ,however, any of the middle 3 sensors were the last sensors to detect the line, the buggy would understand that it has reached the end of the line and hence would stop.

8.0 Conclusion The buggy was able to achieve most of its aim except reaching the final race. It was capable of taking turns in a smooth and fast way, go up or down the slope while maintaining the speed and stop on reaching the end of the course. The total cost of the buggy was calculted to be £32 including recycable items which is underr the allocated budget. All aims were accompilshed while abiding by the regulations of maximum 6 sensors and budget of £50. Many new innovative features such as RF link debugging tool and ultrasound sensor not only eased the process of programming but also improved the manoeuvrability of the buggy through the track.

During the two heats, group 6 had mixed fortunes. For the first heat, the group concentrated on completing the track in respectable time. The buggy was able to complete the track without any difficulty in 8.3 seconds. In the second heat, the group concentrated on posting a faster time to qualify for the final race. However the buggy had more oscillations than before which resulted in more time to settle down on a straight line. This costed time and place in the final race as the best time posted by group 6 was only 7.1 seconds, 5th fastest in the stream. After critical analysis of the race, the following steps were noted which, if implemented, could have improved the fastest time for the buggy:

• The buggy was heavier than expected which compromised not only the stopping distance but also the manoeuvrability of the buggy

• One reason for increased oscillation was pointed towards the sunlight in the room of race. The buggy should have been tested in sunlight before coming to race.

• Better PID control should have been implemented to improve oscillations that were observed in a straight line.

In conclusion, even though the buggy was not able to reach the finals, it was able to complete the track in fast time and hence can be declared as a success.

9.0 References [1] Apsley, J, Green PN, Embedded Systems Project: Project Handbook, School of Electrical and Electronic Engineering (2014), the University of Manchester, Sept 2014. [2] Microchip. (2008) PIC18F8722 Family Data Sheet. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/39646c.pdf. [3] Vishay. (2009). TCRT5000L Datasheet. Available: http://www.vishay.com/docs/83760/tcrt5000.pdf. [4] Foster, DA, Breakout Interface Schematic, School of Electrical and Electronic Engineering (2014), the University of Manchester, Sept 2014. [5] Apsley, J, Drive Board Circuit Diagram, School of Electrical and Electronic Engineering (2014), The University of Manchester, Sept 2014 [6] Farnell. electronic components. Available: http://uk.farnell.com/ [7] Chen, CW, Embedded System Project-‐Wireless Link Documentation, School of Electrical and Electronic Engineering (2014), The University of Manchester, Sept 2014 [8] ITead Studio. (2010). Ultrasonic ranging module : HC-‐SR04 (Data Sheet). Available: http://www.electroschematics.com/wp-‐content/uploads/2013/07/HC-‐SR04-‐datasheet-‐version-‐2.pdf

16

10.0 Appendix 10.1 Updated Engineering drawing for Acetal chassis

Fig. A. Acetal Chassis Plate

17

10.2 Updated Engineering drawing for Upper Plate of the chassis

Fig. B. Upper Acetal Plate

18

10.3 Updated Line Sensor Board Diagram

10.4 Updated Line Sensing Circuit Board Diagram

Fig. C. Circuit Diagram for line sensor board

Fig. D. Circuit Diagram for line sensing circuit board

19

10.5 Updated Speed Sensing Board Diagram

10.6 Updated Speed Sensing Layout Diagram

Fig. E. Circuit Diagram for speed sensing circuit board

Fig. F. Layout Diagram for speed sensing circuit board

20

10.7 Updated Line sensing Circuit Layout Diagram

10.8 Updated Line sensor Layout Diagram

The line sensor board was designed for six sensors, however, only 5 bottom sensors are being fitted and used.

Fig. G. Layout Diagram for line sensing circuit board

Fig. H. Layout Diagram for line sensor board

21

10.9 Updated Wiring Diagram

10.10 Pseudo code

ConfigureADC() while(1){ if(Remote control mode is switched on)

{ if(pushbutton 1 is pressed) { Turn_right() }

RF board

Ultrasonic Sensor

Line Sensors

Speed Sensors

Motors

Fig. I. Wiring Diagram

22

else if(pushbutton 2 is pressed) { Turn_left() } else { go straight according to potentiometer

} else if(Line following mode is switched on) { Read Sensors() if(no sensor senses line)

{ stop } else if(analogue sensors detect error) { Send the error to PD line controller Turn buggy accordingly } else if(end digital sensors detect line)

{ Turn buggy accordingly } else

{ Go straight if(speed is less than it is suppose to be)

{ Send the error to P speed controller

Increase speed accordingly; } else if(speed is more than it is suppose to be)

{ Send the error to P speed controller

Decrease speed; } }

} }