Proposal Report for Autonomous Line Following Buggy

1

Embedded Systems Project

PROPOSAL 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: 11/12/2014

School of Electrical and Electronic Engineering

2

Table of Contents 1.0 Introduction ................................................................................................................................... 1

1.1 Aims .................................................................................................................................................... 1

1.2 Objectives ........................................................................................................................................... 1

2.0 Software Specification .................................................................................................................... 1

2.1 Functional Summary ........................................................................................................................... 2

2.2 A list of constraints ............................................................................................................................. 2

2.3 System Context ................................................................................................................................... 2

2.4 Use Case Diagram ............................................................................................................................... 4

2.5 X-‐Y PLOT ............................................................................................................................................. 5

2.6 Pictures of simulation ......................................................................................................................... 5

2.7 Object/Block Diagram ......................................................................................................................... 6

3.0 Hardware Overview ........................................................................................................................ 7

3.1 Justification of chassis material choice ............................................................................................... 7

3.2 Drawing showing the layout of the main components with discussion ............................................. 8

3.3 Overview of main design choices from design reports #1 and #2 ...................................................... 9

3.4 Circuit Diagram for proposed line sensor ........................................................................................... 9

4.0 Team Organisation ....................................................................................................................... 13

5.0 Planning and Budget ..................................................................................................................... 13

5.1 Gantt Chart ....................................................................................................................................... 13

5.2 Costing of Parts for Buggy ................................................................................................................ 14

6.0 Conclusion/ Summary of Specification .......................................................................................... 15

6.1 Winning Features .............................................................................................................................. 15

7.0 References .................................................................................................................................... 15

8.0 Appendix ............................................................................................................................................... 16

8.1 Drawings of the Chassis Base Plate and Gearbox Plates .................................................................. 16

8.2 Details of Each Use Case ................................................................................................................... 17

8.3 Prototypes of the Functions of Each Object/Block (Defined in C) .................................................... 19

8.4 Evidence of Record-‐Keeping ............................................................................................................. 21

8.5 Risk Assessment ................................................................................................................................ 23

1

1.0 Introduction The Embedded Systems Project requires the design and implementation of an autonomous buggy that is able to navigate a course by following a white line. The proposal report is an important part of the embedded systems project that defines the working aims and objectives for the second semester. This report deals with identifying software requirements; hardware specifications; system requirements; integration of hardware & software and execution of the design.

Figure 1 shows the 3-‐D model of the line following buggy. The 3-‐D model shows the placement of all the components (Drive Board, Microboard, battery pack, breakout interface) on the buggy. The model also shows the design of the chassis and the gearbox plates which are an integral part of this report.

1.1 Aims -‐ To develop a buggy that can follow a white line -‐ To complete the course in the quickest time -‐ To complete the course without collisions

1.2 Objectives -‐ Create a C program that will navigate the buggy -‐ Successful implementation of the proposed navigation strategy -‐ To obtain a chassis that will withstand the necessary amount of stress -‐ Design of the chassis and gearbox -‐ Assembling the body of the buggy -‐ Following the organised tasks and time allotment from the Gantt chart -‐ Budgetary planning

2.0 Software Specification

Figure 1: 3-‐D model of the buggy

2.2cm 2.2cm 1.8cm 1.8cm

Edge digital Line Sensor

Edge digital Line Sensor

Centre digital Line Sensor

Centre digital Line Sensor

Analogue Line Sensor

Analogue Line Sensor

Figure 2: Sensor Layout

2

For implementation of the software it is important to derive every system specification involved. This involves a three step process beginning with the context diagram and ending with block diagram. This process for the buggy has been shown below:

2.1 Functional Summary A functional summary is the first step towards determining all the functional requirements of the system. Functional summary is written in a high level language that can be understood by a non-‐specialist. The functional summary of the line following buggy is described as follows:

1. When switched on the line following buggy detects a white line. It uses this to position itself according to the direction of the line and starts moving.

2. The speed of the buggy is to be maintained during the whole track. This is achieved by using a

speed sensing circuit that utilises a closed loop control circuit. This will store information that is exchanged between the speed sensor, the microcontroller and the motor. Upon reaching an upslope/downslope, the speed of the buggy reduces/increases due to gravity. This information is sent to the microcontroller, which then increases/decreases the torque on the motor accordingly to maintain the speed.

3. Following a turn on the white line, the buggy will use an array of light sensors. When the left/right

sensor detects the white line, the information is sent to the microcontroller which then reduces the speed of the left/right motor causing the buggy to turn accordingly. When the array of the light sensor circuit is not able to detect any white line for 1 or more seconds the buggy will halt. However, if a white line is detected before 1 second, the buggy continues on its path.

4. Upon encountering a turn, the light sensor circuit will decrease the speed of one of the wheels.

This may interfere with the speed sensing circuit. Hence, it is ensured that when the light sensor circuit is used for turning the buggy, the speed sensing circuit is switched off

2.2 A list of constraints Constraints are anything that can limit the system performance of the functions. Consideration of all the constraints is an important step in working of the system. The constraints for the line following buggy has been given as follows:

1. The digital I/O board has only one ADC 2. A budget of only £50 has been allocated for this project 3. A maximum of 6 line following sensors has been permitted

It is vital to ensure that all constrains are met by the system.

2.3 System Context A system context diagram shows how the system (a black box) interacts with the external devices. Context diagram is a way to understand the external details and the input output messages before jumping in to the internal details of the system. The context diagram of the line following buggy:

Figure 1

Figure 1

3

Centre Digital Light Sensor 1

Speed Sensing Sensors

Edge Digital Light Sensor 1

Left Motor

Angular Speed

Analogue Light Sensor

1

Right Motor


Analogue Light Sensor

2


Turn Detection 1

Distance from line 1

Distance from line 2

Wall Collision

Detection 1

Wall Collision

Detection 2

The System Context Diagram shows the buggy as a black box and the external devices that will be attached to the buggy. The input devices include all the sensors that will be used for following the white line and maintaining the speed on the track while the output devices are the two motors. The centre digital sensors(see in figure 2) are used to detect a turn and send a signal to the black box to implement the necessary changes in PWM to the two motors. When the centre digital light sensors are not able to detect a line, the analogue sensors(see in figure 2) will specify how far the buggy is on the edge of the line and hence will be able to turn the buggy accordingly. The two edge track sensors(see in figure 2) are used as backup. When either detects a white line, the buggy turns accordingly. It is important to note that at a particular time, all 6 light sensors will be detecting the line. The speed sensors are able to determine an upslope or downslope due to the change in speed of the wheels and hence can give signals to change the torque. All these input signals are then sent to the black box that then outputs a DC pulse signal to the two DC motors. The two motors change their speed in accordance with the inputs given by the sensors.

For table of message description, refer to the appendix 8.2.

Figure 3: Context Diagram

Buggy

Turn Detection 2

4

2.4 Use Case Diagram A use case diagram is similar to a system context diagram however system performances are included in the case diagram. The black box is zoomed into and the different case structures are observed. The use case diagram of the line following buggy has been shown below.

In this diagram, the major functions are shown in ellipses while the external devices are shown outside the box.

The use case diagram shows the system performances of the black box in more detail. The use case diagram of the line following buggy shows 4 major functions: ‘take line measurements’, ‘take speed measurements’, ‘turn to’ and ‘torque to’.

The ‘take line measurements’ reads the data obtained from all light sensors and detects a white line. The ‘take speed measurements’ reads the data obtained by the speed sensing circuit. The speed sensing circuit looks for changes in the speed of the wheels and detects an upslope or downslope. During a turn, the speed of one of the wheels will decrease. This may give a false positive and change the output torque of the buggy when undesired. To ensure that the speed circuit does not work during a turn, the data from the centre digital line sensors are also observed.

The ‘turn to’ and ‘torque to’ functions help in changing the PWM on the motors in accordance to the data obtained from the input sensor. The ‘turn to’ function decreases the speed of either of the wheels to make a turn while the ‘torque to’ function increases/decreases the torque across both the motors to maintain a constant speed on a slope. When none of the light sensors are able to detect a white line for 1 or more seconds, the ‘turn to’ function stops the buggy by cutting off the torque at both the motors.

For Use Case Descriptions refer to Appendix 8.2.

The use case description, given in the appendix, provides the basic understanding of the program that will be downloaded onto the buggy. To ensure that the sensor layout and the programming will be able to accomplish the task of following the line and climbing up the ramp, a simulation was undertaken. The sensor layout parameters and the MATLAB coding were used to simulate the buggy across a track.

Take Speed measurements

Speed Sensing Sensor

Turn to Torque to

Left Motor Left Motor Right Motor



Take Line measurements


Analogue Light Sensor 1



Analogue Light Sensor 2


Figure 4: Use case Diagram

5

2.5 X-‐Y PLOT The x-‐y plot shows that buggy is able to turn, rise up a ramp and stop in the end perfectly. Hence this proves that our sensor layout is perfect and the basic understanding behind the programming is also right.

2.6 Pictures of simulation

Figure 5: X-‐Y Plot X-‐Axis

Figure 6: Buggy Simulation climbing slope

Figure 7: Buggy simulation on a turn

The two simulation snapshots show the working of the buggy on the simulated track

Y-‐Ax

is

6

2.7 Object/Block Diagram The object/block diagram shows all the system objects and their connection to the external devices. The object/block diagram for the line following buggy is given below:

2. White line detected

STOP

1. execute


1. getposition

Obtain Data from Light sensors

Initialization of the buggy

Take data from analogue sensors

Motion Controller

Take data from Edge digital light sensors

Wait for 1 sec

Data Processing

Config. ADC

Config. Timer

Config. Ports

Read ADC

Convert ADC

Obtain Data from Speed Sensors

Centre Digital Light sensor 1


Analogue Light sensor 1

Analogue Light sensor 2

Edge Digital Light sensor 1

Edge Digital Light sensor 2



Speed Sensing Sensor

Left Motor Right Motor Left Motor

Timer

1. execute

1. execute

1. execute

1. execute 1. execute 1. getdata

1. getspeed

1. getdata

1. getline

1. getline

1. getposition

1. execute

1. execute

6.setPWM 6.setPWM 6.setPWM 6.setPWM

1. getdata

1. getdata

2. No white line detected





5. Transport of data

5.Still no white line detected

Figure 8: Object/Block Diagram

7

The object/block diagram is a composite diagram that shows the connection from external devices and also the behaviours of the internal system. In the line following buggy, the first step involves setting up the buggy by initialising all the important functions. The buggy instantly starts detecting line through its array of light sensors and slope through the speed-‐sensing sensor. The light sensors, if do not detect a line for 1 second, sends command to stop the buggy. This is done to ensure that a false positive from light sensors does not stop the buggy. Data obtained from these sensors is processed in the microcontroller that then changes the PWM across the Left Motor and Right Motor accordingly. This block diagram has been tested in the simulation and has been proved to be very promising.

Block/Object specification in terms of function is included in appendix 8.3.

3.0 Hardware Overview

3.1 Justification of chassis material choice Chassis will form an integral part of the buggy as it will provide the base for all the component connection. The materials available for the construction of the chassis are:

-‐ Acetal -‐ Glass-‐reinforced laminate -‐ Aluminium -‐ Mild Steel

There are three main criteria for selection of the chassis:

-‐ Ease of Manufacturing -‐ Low density for reduced weight -‐ Not significant buckling or bending due to the weight of processor board

After calculation and analysis, each chassis material was simulated on the basis of the defined criteria: Mild Steel: This is of the densest and strongest materials available for construction because of its high density. Cutting steel is very tedious consequentially making manufacturing difficult. Furthermore, it is very heavy as a result of its high density, an undesired characteristic for the buggy. The calculation for bending and buckling of the chassis due to other components has been done below. Aluminium: A strong and dense material as a result of high density. However, manufacture is difficult and weight large. Furthermore, aluminium is very expensive. Glass reinforced laminate: This material has a low density and high flexural strength which makes it one of the contenders for construction of the chassis. However, there is no laser cutting option available for glass reinforced laminate which will raise the difficulty of its manufacture. Acetal: This has the lowest density and flexural strength out of all the available chassis material. However, acetal might prove to be strong enough for a light weight buggy. An advantage of acetal is that it can be manufactured using a laser cutting machine. This makes it the easiest to manufacture. Following, is the calculation for the bending and buckling of different chassis materials due to other components. From the first design report it was observed that the maximum weight of all the components (processor board, battery pack, wheels) is: 1.1 kg Hence the maximum bending steel can be:

𝑊𝐿!

48𝐸𝐼

The deflection is taken with a concentrated load to assume the worst case scenerio.

8

‘W’ stands for the weight, ‘L’ stands for the length which is equal to 20cm, ‘E’ stands for Young’s Modulus and ‘I’ stand for moment of Inertia. The moment of Inertia can be calculated as follows:

𝑏ℎ!

12

‘b’ stands for breadth which is equal to 16cm while ’h’ stands for height which is equal to 3mm.

Acetal Glass-‐reinforced Laminate

Aluminium Mild Steel

Density (Mg/m3) 1.8 1.9 2.7 7.8 Flexural strength (MPa) 91 255 310 414 Ultimate Tensile Strength (MPa)

67 175 310 414

Young’s Modulus (GPa) 2.8 11.5 69 207 Moment of Inertia (kg.m2) 3.6*10-‐10 3.6*10-‐10 3.6*10-‐10 3.6*10-‐10 Deflection(mm) 1.78 0.43 0.072 0.024

From the analysis, it was found out that mild steel and aluminium are not the optimum chassis material because of large weight and difficult process of manufacturing. Acetal and glass-‐reinforced laminate appear to be characteristically similar, with acetal being strong enough to carry the light weight buggy. However one major advantage that acetal has over glass-‐reinforced laminate is the ease of manufacture. Hence after thorough analysis acetal is chosen as our chassis material.

Figure 9: Stress simulation of Acetal

3.2 Drawing showing the layout of the main components with discussion The layout of the buggy relies on the following criteria: The centre of gravity

-‐ Stability of the buggy -‐ Close connection of wires -‐ Height Clearance

The centre of gravity is an important parameter of any moving object, its optimum position being close to the source of torque to ensure enough friction. In the line following buggy, most of the controller board and the buggy has been placed at the back for optimum friction and smooth movement.

Table 1: Table showing different properties of chassis materials

Figure 9 shows the stress analysis of the acetal chassis material. The simulation shows the overall stress across the chassis due to other components. It can be seen that the stress is not high and hence acetal is a strong material for the chassis.

9

The stability of the buggy is another important parameter of the buggy. A high stability is desired to complete a track with changing altitude. To ensure stability, the buggy has been fitted with two castor wheels instead of one, providing stability at the front of the buggy where the sensors are positioned.

Many controller boards will be connected to the buggy (breakout board, motor drive board, veriboard, microcontroller), which will be exchanging data using wires. To ensure that the movement of the buggy is not hindered, it is important to position the components so that the wires are as short as possible. This will be implemented by positioning the microboard, motor drive board, interface board and the battery pack closely to each other on the top of the buggy.

The height of the chassis has been decided while keeping in mind an optimum height clearance and low centre of gravity that will overcome encountered obstacles. The sensors have also been placed between the castor wheels to ensure that the sensors aren’t affected by an upslope or downslope.

3.3 Overview of main design choices from design reports #1 and #2 The first design report was primarily focused on the characterisation of the motors to be used in the buggy. Two motor configurations were considered, one geared and one ungeared. From the characterisation Experiments, KE and KT were determined and the torque benefits of an attached gearbox were observed. Tests were also carried out to determine the required force and therefore torque to ensure the buggy would be capable of climbing a slope. From these experiments a torque of 0.102Nm on each of the rear wheels and a gear ratio of (1:16) was calculated. The following list of gears was compiled:

• 12 tooth pinions (motor shaft only) • 48/12 free running gear (green) • 48/12 press fit gear (orange)

However, when drawing the buggy in Solidworks, it was discovered that the shaft of the middle free running gear was colliding with the motor. So, instead, the following list of gears will be implemented:

• 16 tooth pinions (motor shaft only) • 50/10 free running gear (green) • 50/10 press fit gear (orange)

In summary, the proposed navigation strategy will consist of implementing PID control of the buggy, and the utilisation of 6 sensors. Two of these sensors will be calibrated as analogue sensors, and the remaining 4 will be digital sensors.

With the accurate measurement of the position of the line from the analogue sensors, the PID will measure how much correction is needed to the course of the buggy. It will then increase and decrease the current to the motors to enforce this change in position, however it will never

Figure 11: 3-‐D Model of gearbox

Figure 10: Back view of the chassis

10

completely stop one motor. Therefore, this will give the buggy smoother manoeuvring.

Sensors 3 and 4 will be configured as analogue. The reasoning being that the analogue sensors will accurately sense the position of the buggy on the line when turning. Therefore, along with proportional control, this will smoothen the manoeuvres of the buggy, eliminating the possibilities of the buggy going off course and crashing.

Sensors 1, 2, 5 and 6 will be configured digitally. The purpose of sensors 1 and 2 is to detect breaks in the line and the end of the track. Sensors 5 and 6 will act as back up sensors that will cause the buggy to steer heavily in the opposite direction. For instance, in the scenario that sensor 5 detects the line, the buggy will steer heavily to the right, bringing it back onto the line and preventing collisions.

When the track is straight and uninterrupted, sensors 1 and 2 will be on the line, and none of the other sensors will detect the line. Therefore, the buggy will continue to go forward. Upon encountering a turn to the right, sensor 1 will be off the line and sensor 4 will be on the line, so the buggy will steer to the right. Similarly for a turn to the left, sensor 1 will be off the line and sensor 3 will sense the line, so the buggy will steer to the left. When encountering a pinch, because all six sensors will sense the line, the buggy will remain in its initial direction. Furthermore, the layout will allow the buggy to differentiate between a break and the end of the track. This is because during a break, at least one of sensors 1 and 2 will sense the line. However, at the end of the track, no sensors will sense the line, and there will be delay of 1 second before the buggy will halt, to make absolutely sure that it is the end of the track.

During the simulation of the sensor layout on MATLAB(as seen in figure 5, 6 and 7), it can be found that the sensor layout and the navigation strategy used in the buggy is optimum and can complete the track without any major problems. Hence the sensor layout and navigation strategy has been verified.

A fully dimensioned engineering drawing for the chassis base plate and gearbox plates has been given in appendix 8.1.

Figure 12: PID Control

Figure 13: Navigation Strategy 1 Figure 14: Navigation Strategy 2

11

3.4 Circuit Diagram for proposed line sensors

PIC Breakout Interface Board 2.2cm 2.2cm 1.8cm 1.8cm

J12 Pin 7

J12 Pin 8

J18 Pin 1

J18 Pin 6

J13 Pin 5

J13 Pin 8

Microcontroller (PIC 18F8722)

RJ0 RJ1 RA0 RA5 RB0 RB0

Motor Drive Board

J3 Pin 1

J3 Pin 3

Battery Pack

Power 0V (Bat-‐)

Power 10V (Bat+)

JP4 Pin 1

JP5 Pin 1

+5V Power Supply

P2A GND P2A

Motor 2

JP8 Pin 1

JP8 Pin 2

JP8 Pin 3

JP8 Pin 4

Left Bridge

Left Bridge

Right Bridge

JP1a Pin 3

JP1a Pin 6

RC1

RC2

1

2

3 5 4 6

Right Bridge

Motor 1

Figure 15: Interconnections between PIC, drive board, interface board and sensors

*The numbers beside each sensor in sensor layout specify sensor number

*

12

Figure 16 shows the circuit configuration for analogue sensors while figure 17 shows the circuit configuration for the digital sensors. These have not been combined with figure 15 to improve clarity of the overall circuit implementation.

Figure 15 shows the proposed sensor layout and their connections with the PIC breakout board. The sensor layout for the buggy in design report #2 has been modified. This modification has been implemented having simulated the layout in MATLAB Simulink. Previously the sensors were laid out in a “diamond” shape whereas now the sensors are laid out in an “inverse T” shape. Furthermore, the central digital sensors are now positioned at a distance of 1 cm rather than 2 cm apart. The distance of analogue sensors 3 and 4 from the centre has been increased from 1.5cm to 1.8cm. Moreover, the distance of digital sensors 5 and 6 has been increased from 2.5 cm to 4 cm from the centre.

4 digital sensors and 2 analogue sensors will be utilised. Figure 16 shows the analogue circuit that will be used for sensors 3 and 4. These will be primarily used for sensing a turn. Both have been connected to port A on the PIC because it is configured as an analogue input. The schematic for the breakout interface board shows that pins RA1, RA2 and RA3 are not in use. Further research shows that pin RA4 is a digital input. Hence the pins that will be connected to the analogue sensors are RA0 and RA5. Figure 17 shows the configuration that will be used for digital sensors 1, 2, 5 and 6. Sensors 1 and 2 are the primary sensors for the detection of a turn in the track. They will be connected to pins RJ0 and RJ1 on the PIC through the port J12 on the breakout board. This is because they are regular inputs that will be polling information about the white line. Sensors 5 and 6 will be used as backup sensors in case the buggy veers far off the line. Sensors 5 and 6 are attached to RB0 and RB3 on the PIC through the J13 port on breakout board. The motor drive board is the main source of power across different components of the buggy. The drive board is deriving power from the battery pack through port J3 pins 1 and 3. Furthermore, the drive board is giving power to the PIC through pin 1 of ports JP4 and JP5. The drive board is also giving power to the motors using pin 1 of port JP8. It should also be noted that the height of the sensors from the ground has been specified to be 1.5 cm as this height produced the best result during the sensor characterisation of TCRT5000L.

R1100Ω

R24.7kΩ

TCRT5000L

VSS5V

Output

Figure 16: Circuit configuration for analogue sensors

Going to Breakout Interface board Board

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

Figure 17: Circuit configuration for digital sensors

Going to Breakout Interface board Board

13

4.0 Team Organisation It was agreed upon by the group that during meetings, each member would have equal authority. Any suggestion put forward would be discussed and resulting decisions would be agreed upon unanimously. If there wasn’t a unanimous agreement, a group discussion would take place. By doing this, everyone’s voice is heard, and any errors noticed would be brought to attention. All members expressed their wants of accomplishment from the project, and this was effective in orientating the group’s perspective on how to collectively achieve them. In the case where differences of opinion were to hinder the group’s progress and overall efficiency, the appointed team leader would make a final decision and overrule all conflicts. To date, this has not been required because the group has collectively contributed and carefully considered developing each-‐other’s ideas, maintaining a common courtesy, direction and set of goals. Communication between group members has primarily been through the WhatsApp messaging service. This has been a platform for the organisation of meetings, personal qualms to be addressed, discussions of ideas to be ongoing and rapid notification of any issues faced. In addition, the group has made extensive use of the dropbox cloud system making the process of sharing files between members easier. By these means, everyone is kept updated and the files relevant to the project are backed up, creating a record keeping method by proxy. At least one weekly meeting is held each week, which usually lasts an entire afternoon. Any extra meetings are organised when necessary. Organisation of meetings has been made simple by the identical timetable shared by the group members. This has increased the work efficiency and made large tasks such as design reports highly manageable. Each member has declared their areas of interest concerning the overall project. Design report #1 allowed for members to find their most suited general roles of contribution. Similar roles were delegated for the writing of design report #2 and the proposal report. Furthermore, a belief that everyone actively reads and audits sections written by other members to scour for errors is held. The evidence of record keeping has been shown in appendix 8.4

5.0 Planning and Budget

5.1 Gantt Chart

Figure 18: Gantt chart and description of Gantt chart

14

Gantt chart has been developed according to the role given to each member. The Gantt chart specifies a definite time period for a task, however sufficient redundancy and flexibility was also kept in mind while making the chart. A table describing each task also accompanies the table. We have decided the respective activities for every member of the group in a way to put each member in their preferable activity, thus we have the most beneficial use of each integrant. In this case, Hani and Maggie (Manyu) are going to work mainly on the design of PCBs, while Cai, Eric and Vishisht are working on the construction and software of the buggy. Finally everyone will be participating on the finalisation of the buggy and writing the final report.

5.2 Costing of Parts for Buggy

Table 2: Table showing costing for different parts of the buggy

15

Table 2 shows the costing of all the possible parts that can be used for the construction of buggy. All the prices have been kept at maximum limit and a contingency price of 10 £has also been kept incase a new item has to be purchased. After consideration of maximum possible price for each component, it can be seen that overall price is less than 50£. This satisfies one of the major objective of this project.

Risk Assessment has been shown in appendix 8.5.

6.0 Conclusion/ Summary of Specification Through the writing of the proposal report a plan for the second semester was drafted. This report has provided a detailed evaluation of the necessary system requirements; the technical specification of the buggy; the design of the main components & the overall buggy and the integration of the hardware & software specification. The report has helped to provide an overall review of the aims and the objectives that needs to be accomplished for the working of a successful buggy.

The budget of the buggy was calculated out to be 44.84£ which is less than the specified limit and hence meets one of the major constraint of this project.

6.1 Winning Features Semi-‐circle front: The semi-‐circle front of the buggy provides a way to manoeuver successfully around a narrow turn. The semi-‐circle reduces the area on the edge, without losing the stability and strength of the buggy. Figure 19 on

describes this particular feature in a buggy outline schematic.

Backup Sensors: The buggy will have two backup sensors in case the usual turning sensors miss the white line. This provides an additional mitigation from collision of the wall and gives a greater trust in the turning of the buggy.

Two Castor Wheels: The buggy has been provided with two castor wheels in front to achieve greater stability. This stability is important in the case of the buggy coming down a slope and going through a seesaw obstacle. The figure 20 shows the two castor wheels of the buggy.

7.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. Last accessed 11th Dec 2014. [3] Vishay. (2009). TCRT5000L Datasheet. Available: http://www.vishay.com/docs/83760/tcrt5000.pdf.

Last accessed 11th Dec 2014. [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] Apsley, J, Motor Drive board connections, School of Electrical and Electronic Engineering (2012),

The University of Manchester, Sept 2014. [7] Farnell. electronic components. Available: http://uk.farnell.com/. Last accessed 11th Dec 2014.

Figure 20: photo showing two castor wheels

Figure 19: semi-‐circle front

16

8.0 Appendix

8.1 Drawings of the Chassis Base Plate and Gearbox Plates

Figure A is a dimensioned diagram for the gearbox plate on the inside of the motor.

Figure B is a dimensioned drawing for the gearbox plate on the output of the gear.

Figure A

Figure B

17

8.2 Details of Each Use Case Take Line Measurements

• Main flow of events o Read Centre Digital Sensors o IF both the centre digital sensors detect white line

§ GOTO selected ‘Turn to’ use case • Alternative flow 1

o IF only one or no centre digital sensor detect white line § Read Analogue Light Sensors § GOTO selected ‘Turn to’ use case

• Alternative flow 2 o IF both centre digital sensor do not detect white line

§ Read Analogue Light Sensors § IF both Analogue sensors do not detect white line

• Read Edge digital sensors • IF one of the edge digital sensors detect white line

o GOTO selected ‘Turn to’ use case • IF none of the edge digital sensors detect line

o GOTO selected ‘Turn to’ use case Take Speed Measurements

Figure C: Dimension for chassis

18

• Main flow of events o Read Centre Digital Sensors o IF both the centre digital sensors detect line

§ Read Speed Sensing Sensors § IF speed sensing sensors detect slope

• GOTO selected ‘Torque to’ use case • Alternative flow 1

o Read Centre Digital Sensors o IF both the centre digital sensors detect line

§ Read Speed Sensing Sensors § IF speed sensing sensors do not detect slope

• GOTO selected ‘Torque to’ use case • Alternative flow 2

o Read Centre Digital Sensors o IF only one or none of the centre digital sensors detect line

§ Do not read Speed Sensing Sensors Turn To

• Main flow of events o IF one or more than one light sensors detect a straight line

§ Equal torque at both motors

• Alternative flow 1 o IF one or more than one light sensors detect a turn

§ IF buggy has to turn left • Decrease torque across left motor

§ IF buggy has to turn right • Decrease torque across right motor

• Alternative flow 2 o IF none of the light sensors detect white line

§ Detect all the light sensors for 1 more second § IF still none of the light sensors detect white line

• Torque cut off from both the motors § IF white line is detected

• Change torque according to turn

19

System Messages

Table A: System Messages

8.3 Prototypes of the Functions of Each Object/Block (Defined in C) ***************************************************************************************Block: Initialisation *************************************************************************************** Functions void OpenTimer1 (..); //Microchip Function for Capture mode (CCP module) void WriteTimer1 (..); //Microchip Function, may not be needed void OpenADC (..); //Microchip Function void OpenCapture1 (..); //Microchip Function void Config_Ports (void); //Configures ports for digital I/O, analogue input etc. Data None ***************************************************************************************Block: Obtain Data From Light Sensors *************************************************************************************** Functions unsigned char get_line (void); //returns reading from front and rear digital sensors //Simply reads port and masks off irrelevant values Data unsigned char line_detected; //takes data from get_line, to be used as: if 0 line not detected.

Name Description Source Destination Interface Size in bits

Comments

Angular Speed

Speed of the wheels

Speed Sensing Sensors

System Digital I/O 8 TEKS5400S and TEKT5400S is used

Turn Detection

On/Off Line Centre Digital Light Sensors

System Digital I/O 8 TCRT5000L is used

Distance from Line

How far on the edge of line

Analogue Light Sensors


Wall Collision Detection

Close to wall Edge Digital Light Sensors


Motors Increase/ decrease speed of wheel

System Motors Digital I/O 8 None

20

*************************************************************************************** Block: Obtain Data From Speed Sensors *************************************************************************************** Functions unsigned int ReadCapture1 (void); //Reads CCP unit to determine current speed unsigned char capture_to_char (unsigned int); //Converts capture to char Data unsigned char duty_cycle_adjust; //contains value to adjust duty cycle of motors. ***************************************************************************************Block: Take Data from analogue sensors *************************************************************************************** Functions void get_position (char *l, char*r); //Reads analogue inputs from both sensors int read_ADC (void); // Microchip Function, to be used within get_position char BusyADC (void); //Microchip Function, to be used within get_position void ConvertADC (void); //Microchip Function, to be used within get_position void int_to_char (int *a, int *b); //Converts adc readings to chars, within get_position Data unsigned int adc_l; //Raw reading of ADC left sensor reading for int_to_char unsigned int adc_r; //Raw reading of ADC right sensor reading for // int_to_char unsigned char left; //holds final left analog sensor reading. Used in // get_position function call unsigned char right; //holds final right analog sensor reading. Used in // get_position function call ***************************************************************************************Block: Take Data from Edge Digital Sensors *************************************************************************************** Functions unsigned char get_edge (void); //returns reading from edge digital sensors //Simply reads port and masks off irrelevant values Data unsigned char edge_detected; //takes data from get_edge, to be used as: if 0 edge not detected. ***************************************************************************************Block: Motion Control *************************************************************************************** Functions void compare (char *l, char *r); //Take analogue measurements and compare them, if zero, both motors same, if non zero increase duty cycle (add to“on” delay and subtract from “off” delay?) Data None

21

***************************************************************************************

8.4 Evidence of Record-‐Keeping The following figures were taken from our Dropbox account and WhatsApp group. This shows our commitment in keeping record of our groups activities accessible to all group members and the effectiveness of the communications by our WhatsApp group.

Figure D: Dropbox snapshot 1

Figure E: Dropbox snapshot 2

22

Figure F: Dropbox snapshot 3

Figure G: WhatsApp snapshot 1 Figure H: WhatsApp snapshot 2

23

24