29
Project Technical Report City of Glasgow College HND Electronics Graded Unit Project SARRRO SEARCH & RESCUE RECONNAISSANCE ROVER Gavin Hannah N10161454 2012/13

City of Glasgow College HND Electronics Graded Unit … of Glasgow College HND Electronics Graded Unit Project ... Project Research & Development ... During the course of the projects

Embed Size (px)

Citation preview

Project Technical Report

City of Glasgow College

HND Electronics Graded Unit Project

SARRRO

SEARCH & RESCUE RECONNAISSANCE ROVER

Gavin Hannah

N10161454

2012/13

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Abstract

This report is a technical presentation of the process undertaken to take project SARRRO from

concept to delivery for the HND Electronic Engineering Graded Unit.

Each stage of the project and its’ process is set out in detail within this document to provide the

reader an in depth view of how the student fulfilled the requirements of the Graded Unit

specifications.

SARRRO is an embedded systems autonomous robot designed for hazardous environment

exploration and real time data relay.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Table of Contents Abstract ............................................................................................................................................ 2

Project Proposals .............................................................................................................................. 4

Project Requirements ....................................................................................................................... 4

Project Objectives ............................................................................................................................. 4

Communication................................................................................................................................. 4

Project Solutions ............................................................................................................................... 5

Project Research & Development ..................................................................................................... 5

Design Software ................................................................................................................................ 7

Project Testing .................................................................................................................................. 7

Project Construction ......................................................................................................................... 8

Presentation ..................................................................................................................................... 8

Project Technical Issues .................................................................................................................... 9

Personal Reflection ......................................................................................................................... 11

APPENDICES ............................................................................................................................. 12 - 20

[ i ] - PROJECT PROPOSALS .............................................................................................................. 13

[ ii ] – PROJECT REQUIREMENTS QUESTIONNAIRE .......................................................................... 14

[ iii ] – CUSTOMER MEETING MINUTES ........................................................................................... 15

[ iv ] – PROJECT OBJECTIVES ............................................................................................................ 17

[v] – PROJECT BRIEF ........................................................................................................................ 18

[vi] – PROJECT SOLUTIONS .............................................................................................................. 20

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Project Proposals

To begin the Graded Unit project, the student was required to present three project proposals to the

project administrator, John Woods, for discussion and analysis. See Appendix i

Following these discussions, it was decided that the student would undertake the project referenced

in this report.

John Woods would oversee the project as Project Supervisor, while fellow lecturer Christian

Hammond would represent the project customer.

Project Requirements

The next stage of the project was to find out what the project requirements were. This involved

communicating with both John Woods and Christian Hammond, and the use of a questionnaire to

help identify what criteria SARRRO would be required to fulfil. See Appendix ii.

Following this, a project meeting was setup between the student and both John Woods and

Christian Hammond. The purpose of the meeting was to allow the student to create a list of

requirements that would then be brought together the form a project brief.

The minutes of this project meeting can be found at Appendix iii.

Project Objectives

The student was required to submit a list of objectives that they would attempt to complete during

the course of the Graded Unit project. These objectives would be set to establish a sort of ‘yard stick’

that the student could use to try and gauge how well the student has performed throughout the

course of the project. The project objectives can be located at Appendix iv.

Project Brief

Once the project was decided upon and the customers’ requirements were identified, the student

produced a project brief which would be a reflection of the project task and the requirements that

would have to be met. Once agreed upon, this brief was signed by all parties.

The project brief can be found at Appendix V.

Communication

During the course of the projects development, the student had regular project meetings with John

Woods and maintained communication with Christian Hammond to keep both informed of the

projects’ progress.

These regular meetings were accompanied by progress reports whereby John Woods could provide

feedback regarding the project and the progress made. They also served to allow the student to

refine areas of the project documentation that could have contained more detail.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

These reports can be found within the project folder along with all the customer communication in

the form of emails, which can also be found within the project folder.

The student also maintained a log book throughout the project which was for the purposes of

keeping track of what processes the student had undergone during the projects’ development. It

was also used for note taking while experimenting with circuit designs and for keeping track of odd

bits of research.

During the course of the project, the student maintained an online portfolio/ blog, which can be

viewed at http://ghannahgradedunit.wordpress.com.

This was primarily for the students own personal record but also to try and advertise the project to a

wide audience.

Project Solutions

As the student researched methods of designing a solution, the student was required to submit a

solution matrix. This matrix outlined particular methods of fulfilling the customers’ requirements.

Each solution was scored in a grid table to identify which was the most economical in terms of time,

cost and difficulty. The solution matrix can be found at Appendix vi.

Project Research & Development

Once the requirements for this project were established, the student was then able to research

these requirements. The student made use of the Internet where a wealth of information was

obtained. This research can be located in the research section of the project folder.

The student had to conduct thorough research so that they could design a solution that would meet

the requirements of the customer.

Areas of research included:

- Embedded Systems. The student had to decide what type of embedded system would be used to

build this project around. In the end, the student elected to use the PIC18F4550 microcontroller.

This was due in large part to the familiarity of the student had developed with using this particular

MCU through attending college. The student was therefore extremely confident that this MCU

would be more than capable of providing the necessary computational power.

- Drive System. The student had to develop a solution for two different aspects, electronic and

mechanical. The student had to consider how the rover would be propelled and how it could be give

manoeuvrability.

For ease of design, the student elected to use a two motor system whereby each side of the rover

would have an independent motor. This would allow the rover to move forwards and backwards and

allow the rover to turn on the spot through the use of opposite drive turning, much in the same way

a tracked vehicle manoeuvres.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

To control the two motors, the student elected to use a H-Bridge setup for each motor. Having

already become familiar with this type of circuit, the student theorised, that there might be an IC

solution that could accomplish this. This solution came in the form of an L298 H-Bridge chip.

- Radio Communication. This particular feature presented an interesting challenge to the student.

Following consultation with the customer, it was clear that the customer wanted SARRRO to be

equipped with Bluetooth capability. This would allow SARRRO to relay live data to a remote

operator.

The decision to use Bluetooth was also because the customer wished to use SARRRO as a

demonstration tool in the future and the customer would provide the particular Bluetooth module

to be used. However, to begin with, the specific type of Bluetooth module was unknown by the

customer. It was decided however that it would be Bluetooth version 4. This part of SARRROs design

would not be tackled for a number of weeks.

Eventually, the customer contacted the student to inform them that the version of Bluetooth being

used had changed to version 2.1 for technical reasons. The Bluetooth module the student would be

asked to use would be the Roving Networks RN-41 Bluetooth module.

Once this information was known, the student was able to design a solution for SARRRO that would

allow the customer to integrate their Bluetooth module into SARRRO.

- Navigation. SARRRO would be required to operate in an autonomous mode. This meant that the

rover would have to have some form of navigation and software capable of allowing it operate

without collision and causing potential damage to itself and/or its surroundings.

Having never worked with any form of navigation system previously, the student elected to

approach this problem by using a common form of navigation used widely in the field of robotics.

This was Ultrasonic Distance Ranging.

Ultrasonic Distance Ranging works on the same principle that bats employ to navigate. High

frequency sound waves, high above the human auditory range, are pulsed in short bursts away from

the rover and the echo from these sound waves is detected by an ultrasonic transmitter / receiver

transducer pair.

Using simply time and distance formula, the distance to objects in front of the rover can be

calculated. These calculations could easily be carried out by the MCU allowing the rover to operate

with a collision avoidance system.

- Sensors. SARRRO would have to be equipped with atmospheric sensors to provide real world data

that would then be communicated back to a remote operator. For time and cost reasons, these

sensors were limited to Temperature and Humidity.

Initially, the student elected to attempt to use a thermistor configured with differential op-amp for

the temperature sensor. However, the circuit design proved to be flawed and the student had to

return to the drawing board. Eventually however, the student decided to use a simple potential

divider circuit. This would prove to be relatively easier to design.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

For the humidity sensor, the student had to research how humidity sensors worked. In particular,

there are two distinct types. Resistive, and Capacitive. The student, following consultation with the

online community, chose to use a capacitive sensor as a capacitor within an Astable Schmitt trigger

oscillator circuit.

All the research carried out by the student was published in the form of links available on the

students’ blog and within the research section of the project folder.

During the R&D phase of the project, the student would be able to identify a complete list of the

required components needed to complete the project. This bill of materials was sent to the college

Lab Tech, Gary Murray so that a procurement order could be placed.

Design Software

The student used the following software to aide in the design of the circuits for SARRRO:

- Proteus (ISIS Circuit Lab, ARES PCB Editor)

- MPLAB

Proteus has two parts. The first, ISIS, is a circuit lab editor and the second; ARES is a PCB design

editor.

MPLAB is software developed by Microchip. Microchip manufactures the PIC microcontroller range

and the software can be used in conjunction with Proteus to simulate code developed for the

Microcontroller.

Using the two above software packages, the student was able to design circuits and test them using

the built in simulation tools to verify that the circuit solution designed worked as intended, or that

the solution did not work.

Project Testing

Once the student was confident in the designs generated for SARRRO, they were able to move onto

testing and verifying. To begin with, this was in the form of simulation only. This would provide the

student a base line of results that could be expected once testing was moved onto breadboard.

This also allowed the student to test the MCU source code as it was being developed to ensure that

during breadboard testing, the MCU would operate as required.

During the simulation, the student was able to verify that the Motors, Temperature Sensor and

Humidity Sensor were operating as expected.

The Bluetooth capability was unable to be simulated, however, the student was able to verify the

UART code would function as expected and allow successful integration of the Bluetooth module.

The breadboard testing phase allowed the student to test one of the most important parts of

SARRRO; the Ultrasonic Sensors. To begin with, the student was unable to get the ultrasonics’ to

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

work as expected from the simulation. The student combined the simulation and breadboard

testing to try and pinpoint a root cause for the failure in the ultrasonic sensors.

In the end, while the Ultrasonic Emitters appeared to work as planned, the receiver circuit was

proving troublesome. Following consultation with John Woods, it was decided that as the circuit

designed worked in the simulator, it would be prudent to move ahead with the construction of

SARRRO and try to troubleshoot the Ultrasonics’ once they were built. This was agreed partly due to

the fact that deadline was drawing near.

In the end, the student was able to breadboard and test the temperature sensor and ultrasonic

sensors before running out of time to test any other circuit designs.

The student produced the following test documentation which is located within the project folder:

+ Simulation Results

+ Breadboard Test Data – Ultrasonics

+ Test Specification

The Test Specification is technical report that allows any electronic engineer to diagnose and find

any faults that may appear within the rover while being operated.

Project Construction

To begin with, the student attempted to generate the circuit boards for SARRRO at home using a

thermal transfer process. This process involves using heat to transfer PCB artwork onto a copper

clad PCB. The tonner applied protects the copper traces during the etching process of the PCB

development.

However, after two unsuccessful attempts, the student decided that with the project deadline

approaching, it would be best to simply have the PCBs generated within the college.

Once the student obtained the PCBs for SARRRO, they were able to start populating the boards. This

process took the student a couple of days to complete.

Following this, the student began construction of the rovers’ chassis. The student utilized and old toy

car and other scrap resources to construct a mobile platform for mounting SARRROs’ circuitry.

Presentation

At this point, the student had completed construction of SARRRO and all that remained was to

successfully demonstrate the working SARRRO. This took place in the form of a 10 minute

presentation to the HND Electronics class followed by a general Q&A session.

The final process undertaken by the student was to submit the completed project along with all the

corresponding documentation and paperwork before the end of the 31st May 2013.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Project Technical Issues

A project such as this one presented a number of challenges to the student. It could easily have been

broken down into two or three individual projects due to the scope of the requirements. The

student spent the vast majority of the project timeframe conducting research into how each feature

of SARRRO would work before attempting to bring it all together.

- Bluetooth

The first technical challenge the student was presented with was the ambiguity surrounding the

Bluetooth feature. The specific type of Bluetooth module was unknown to the student due to

reasons out with their control. The project customer, Christian Hammond, would decide which

module was going to be used and the student would then design SARRROs circuitry around the

information from the datasheet before field testing the Bluetooth once construction was complete.

Once the construction of SARRRO was complete, the student contacted the customer to arrange a

field test of the Bluetooth feature only to learn that the customer had taken paternity leave and

would not be able to assist in this matter. As the customer personally owned the Bluetooth module,

and it was not possible to acquire one due to time and cost prohibiting this, it was not possible to

test the compatibility of SARRROs hardware interface.

Despite this unforeseen circumstance, the student was able to successfully utilize the UART feature

of the PIC18F4550, within the MCU code, to demonstrate that had the Bluetooth interface proven

successful, then in theory Bluetooth communication should have been successful also.

- Ultrasonics

The ultrasonics presented a major challenge to the student. During breadboard testing, the student

was able to produce the required frequency of 40kHz required to drive the ultrasonic emitters, but

was unable to see a successful response with the receiver amplifier circuit.

There was also a conflict between what the simulation results were producing and what was being

produced during the breadboard testing. Despite several attempts the student was unable to get the

ultrasonic circuit to work. It was therefore decided upon that, due to the approach of the project

deadline, it would be prudent to proceed with the construction of SARRRO and attempt to get the

Ultrasonics working once complete.

- SARRRO Construction

The design of SARRRO underwent many revisions during the course of the project and despite the

students attempts to ensure that the finalised circuit design contained no flaws, it emerged post

construction, that there were several errors that would prevent SARRRO from working properly, or

at all.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

These were:

+ Incorrect values of capacitor C1 & C2. The student had elected to use 1nF capacitors which were

too high a value. These stopped the MCU working as they prevented either the crystal from

operating at the correct frequency or stopped it altogether.

After referencing the CityBytes development board, these capacitors were swapped for a 15pF &

12pF. Ideally they should both have 15pF but the student was only able to acquire one of each.

+ H-Bridge pin Vs connected to VDD instead of Vsrc. The student learned after assembling the

SARRRO motherboard that this pin had incorrectly been assigned to VDD (5V) instead of Vsrc (7.2V).

This could possibly have compromised the drive system and prevented the motors from working.

The student changed this by scratching out the track making the VDD – Vs connection and using a

length of wire to make the connection between Vsrc and Vs.

+ Incorrectly designed ICSP (In-circuit serial programmer). Once again, following construction of

SARRRO and making an attempt to program the MCU, it was evident that the ICSP was not working.

The student used his experience of the ICSP and the MCU datasheet to identify the problem. Two of

the PINS used (RB7 and RB6) are required to be dedicated during programming.

The student was using these two pins as sensor inputs and had inadvertently missed this before

finalizing the PCB design. This was due the fact that the ICSP was a last minute addition to the

design.

One of the PINS (RB6) was easily disconnected without issue while programming, however, the other

(RB7) had to be physically destroyed by scratching the track. A separate connection was made with a

length of wire and the track connecting RB7 to the humidity sensor output was modified by placing a

jumper header between RB7 and the output of the humidity sensor.

Disconnecting RB6 and RB7 from sensor circuitry by removing the jumper headers allows a user to

program the MCU with the use of the ICSP.

+ Soldering was another challenge the student encounter. During construction, it became apparent

that soldering chip holders and header strips onto top side copper tracks was very difficult to

accomplish without destroying the component or creating short circuits between pins.

This was evidenced when attempting to program the MCU and when running the MCU. Some of the

soldering on the MCU chip holder was either dry jointed or failed to make a proper contact. This

created instances of the ICSP failing to connect and the right motor only working sporadically.

By re-soldering these joints the student was able to resolve these issues.

+ Flawed power supply design. The student utilized knowledge obtained from Analogue Principles to

design a simple Zener stabiliser circuit for the MCU power supply. It would provide a stable 5V

supply from a 7.2V source.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

However, once constructed, the student discovered that the stabilising circuit was only producing

3.5V due to the design of the circuit.

The student learned that this was due to the fact that voltage drops across the on/off LED and the

subsequent Resistor meant that the resultant VDD was only 3.5V.

To overcome this, and as the resistor was needed to prevent damage to the LED, the student

reduced the value of the resistor by adding a second resistor of a lower value in parallel to the initial

resistor.

Personal Reflection

During the course of the HND project, I feel I learned a great deal about electronics and the design of

electronic circuits. I acknowledge the fact that at times I was perhaps guilty of poor circuit analysis.

This is reflected in the number of alterations I had to make post construction.

Overall though, my understanding of basic electronics has improved greatly.

Also, through the research I carried out, I expanded my knowledge of Micro-controllers, Bluetooth

modules, MCU programming, H-Bridge and motor control as well as the proficiency with which I can

analyse a datasheet.

Understanding the importance of datasheet analysis allows the design of electronic circuits to

become a great deal easier and this is probably the most important thing I have come to appreciate.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

APPENDICES

i – Project Proposals

ii – Project Requirements Questionnaire

iii – Customer Meeting Minutes

iv – Project Objectives

v – Project Brief

vi – Project Solutions

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

[ i ] - PROJECT PROPOSALS

This document proposes three different projects for my HND Graded Unit. Upon consultation with

my project supervisor, one of these projects will be selected.

Project Proposal 1

The project task is to create a robot rover. It will be a 4 wheeled rover which will be used for the

purpose of search & rescue and reconnaissance within locations that are hazardous to emergency

personnel.

The rover will be autonomous and free from operator control but will have the option of remote

control.

It will be equipped with a video camera and wireless connectivity to relay live video back to an

operator who can maintain an overlord position from a safe distance.

Project Proposal 2

The task will be to create an effects pedal for a guitar capable of producing feedback, reverb and

distortion effects.

The unit will be portable and battery powered. It will also have adjustable gain controls.

The unit will be built using discreet logic and analogue components only.

Project Proposal 3

The task will be to create a laser tag system. The idea is that it is a game for multiple players similar

to paintball. Each player is equipped with “Armour” and a “Gun” and the objective is to tag

opponent players with the gun.

The system works by utilizing infra-red diodes in the same way a TV remote works. The players’

armour is used to house the battery pack and all the electronics.

Chosen Project

After consultation with my project supervisor, it was decided that I will undertake project one for my

HND Graded Unit.

Christian Hammond, Lecturer at City of Glasgow College, will be my customer.

John Woods, Lecturer at City of Glasgow College, will be my supervisor.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

01 December 2012

[ ii ] – PROJECT REQUIREMENTS QUESTIONNAIRE

The project task is to create an autonomous wheeled robot rover for the purpose of search & rescue and reconnaissance within locations that are hazardous to emergency personnel. The purpose of this document is to identify and clarify what specifications SARRRO will be required to meet. + How big or small is SARRRO required to be? + How many wheels is it required to have? + What voltage of motors are required? + Do you want one motor per wheel or one motor per two wheels? + What size of battery(s)do you want SARRRO to be equipped with? + How many ultrasonic sensors are required for navigation and obstacle avoidance? + Where are the ultrasonic sensors required to be mounted? + What on board sensors are required? Temperature? Humidity? Oxygen? CO2? Etc. + Do you want a camera for visual feedback? If so, what resolution? + Do you want a microphone for audio feedback? Yes + Do you wish to be able to control SARRRO from a Bluetooth enabled computer?

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

18 January 2013

[ iii ] – CUSTOMER MEETING MINUTES

Date of Meeting: 31 January 2013

Time of Meeting: 10:30am

Location: City of Glasgow College, Riverside, 5/2

Persons in attendance: Gavin Hannah, Christian Hammond, John Woods

Chair: Gavin Hannah

Topic of Meeting: To agree project specifications with customer.

1) The meeting began by discussing the number of wheels and motors required by the customer for

SARRRO. It was resolved that SARRRO will have 4 wheels and two motors to drive these wheels. Each

motor will drive two wheels, one for the left, and one for the right. This will also provide a steering

capability. It was resolved that the engineer will have discretion regarding the physical layout and

drive linkage.

2) The next topic of discussion was power requirements. The customer indicated that a

7.2V 3000mAh battery was a very common and cheap battery used among robotics and hobbyists. It

would provide around 10 to 15 minutes of power for the motors. It was resolved that the engineer

would design SARRRO to accommodate as many of these batteries as possible, whilst taking into

consideration the weight limitations of the robot.

3) Discussion then moved onto the robots’ sensor arrangement. Again, taking into consideration

weight and space, it was resolved that the robot will have a minimum of one ultrasonic sensor front

mounted for navigation, with the option of having two on the front. As the robot will have a “turn on

the spot” turning circle, it may not require an ultrasonic sensor on the rear. It was resolved that the

engineer would have discretion regarding the position and number of ultrasonic sensors required,

other than the required one to be front mounted.

The robot will be equipped with a temperature sensor to measure ambient temperature. It was

resolved that the following sensors are subject to space and weight considerations: An infra red

sensor, Co2 sensor, carbon monoxide sensor.

4) It was resolved that a plug and play camera (USB) and microphone would not be required by the

customer. The customers’ requirements regarding Bluetooth meant that adding a camera and

microphone would be redundant as the customers’ choice of

Bluetooth would not handle large data applications. See Section (5).

It was resolved however, that data from the Ultrasonic sensors could be sent to a computer device

as raw data. This raw data could be used by the customer to create visual feedback.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

5) The customer requested the use of Bluetooth 4.0. This is the latest version of

Bluetooth and is referred to as Bluetooth Smart or Low Energy. It is capable of handling low amounts

of data only, but, as the customer plans to use Bluetooth 4.0 in future applications, it was resolved

that the customer would provide the Bluetooth hardware.

31st January 2013

6) It was resolved that the engineer will use the PIC18F4550 for this project for compatibility with

the customers’ future applications / projects. The engineer expressed his confidence in the ability of

this chosen hardware to be capable of fulfilling the customers’ requirements.

7) It was resolved that the engineer will have discretion regarding the robots external peripheral

layout, size of wheels and chassis. It was also agreed that the robot will be built in stages to minimise

hardware and or software problems.

8) The chair opened the meeting to any other business. There was none.

The meeting was adjourned at 10:55am. No further meetings are scheduled at this stage.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

31st January 2013

[ iv ] – PROJECT OBJECTIVES

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

[v] – PROJECT BRIEF

This is a revision of my draft project brief / proposal. It takes into account the customers’

requirements. The project task is to create an autonomous robotic rover. It will be a 4 wheeled

rover which will be used for the purpose of search & rescue and reconnaissance (SARRRO)

within locations that are hazardous to emergency personnel. The rover will be autonomous and

free from operator control but will have the option of remote control from an enabled remote

device such as a laptop.

The robot is required to be compact enough, so it can be easily transported and ruggedized, so

that it can operate within hazardous locations. It is required to have wireless connectivity so it

can communicate with an enabled device and relay real-time data to that device.

The robot will require programmable hardware in order to operate autonomously. It will be to

the engineers’ discretion what form of hardware or platform is used. Remote operating

software will be generated to allow a suitable device to interact with the robot wirelessly. The

engineer will be responsible for choosing a suitable programming language and identifying

what type of devices it will be targeted to run on.

Minimum Customer Requirements

1. Minimum physical size of approx. 300mm X 300mm X 300mm.

2. Autonomous operation with option of remote control operation.

3. Collision avoidance with the use of Ultrasonic Sensors.

4. Programmable hardware. (Microcontroller)

5. Collision avoidance through the use of ultrasonic sensors. Minimum of 1 X front mounted.

6. Wireless connectivity: Bluetooth. 4.0. (Provided by customer)

7. Atmosphere sensors: Temperature. (IR, CO2, Carbon Monoxide)

8. Two 5 -10V motors for drive and steering. The speed of each motor will control the robots’

steering.

9. 1 x 7.2V 3000mAh Battery (approx)

10. Maximum budget of £30.00

The engineer will design and build the project to the customers’ specifications in stages. This is

to minimise the possibility of hardware and or software problems.

Stage One: Design and simulate all the electronic circuits required.

Stage Two: Build the robots motherboard, comprising of the programmable hardware, port I/O

connectors. This is then attached to the robot chassis. Motors and wheels will also be assembled

to chassis.

31st January 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Stage Three: Build the robots sensor arrangement and connect the sensors to the motherboard.

Calibrate the sensors for autonomous operation.

Stage Four: Build the robots wireless module and attach to the motherboard. Calibrate

Bluetooth for communication with Bluetooth enabled laptop. Throughout each stage, the

engineer will design and program the robot and a user application for use on a computer. This

user application will enable an operator to communicate with the robot and exchange data and

commands.

Project Deliverables

The deadline for this project will be 5pm on 31st May 2013, at which point the project becomes

the property of the customer. Items to be delivered include:

All Project Hardware and Software

Project Technical Report

Project Folio

Project Diary

10 Min Audio Visual Presentation

Project Brief Agreement

Accepted By: Christian Hammond

Signed: Date:

Accepted By: John Woods

Signed: Date:

Accepted By: Gavin Hannah

Signed: Date:

A signed copy of this brief can be found within the project folder.

31st January 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

[vi] – PROJECT SOLUTIONS

To meet the customers’ requirements, the following solutions have been considered:

1) Buying an existing design which meets the customer requirements and is within the

customers’ budget.

2) Use an existing and similar project created in past HND graded unit projects and

then modifying as required.

3) Use off-the-shelf components and products to build the project to the customers’

specifications, using readymade circuits and hardware where possible.

4) A combined solution of Solution 3, and making use of hardware available within the

college and from the customer, as well as acquiring sample (cost free) components

where possible and using hardware already owned by me.

14th February 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Solution 1

Solution 1 is to buy a pre-existing design that meets the customers’ requirements. In the field of

robotics, there is a vast array purchasing options ranging from toys through to advanced robotic

systems.

The customer specifications mean that any pre-existing robotic design will have to meet the

following requirements:

Programmable hardware (Microcontroller, PLD..)

Autonomous Operation

Wireless connectivity – Bluetooth Ver 4.0. (With option to operate robot from

Bluetooth enabled laptop)

Ultrasonic Sensors for Navigation (minimum of one front mounted)

7.2V 3000mAh Battery

Atmosphere sensors: Temperature, humidity etc...

Minimum physical size of approx. 300mm X 300mm X 300mm.

Four Wheels and two 5-10V motors to drive them.

While purchasing a robotic system equipped with all the above features will most likely

prove to be too expensive, it will give me an idea of what the competitor products are

like, how much they cost, and what their capabilities are. Below are some of the options that

have been looked at.

From - www.robotshop.com

Dr. Robot Jaguar 4x4 Mobile Platform - Product code : RB-Drr-24 €7064.92

• Designed for indoor and outdoor operation requiring higher

ground clearance and faster manoeuvrability

• Managing max 155mm (6”) vertical step (obstacle)

• All 802.11G (optional 802.11N) wirelessly connected

• Light weight (< 20Kg) with excellent payload capacity

• Autonomous navigation with outdoor GPS and 9 DOF IMU

• Climbing up low rise stairs (up to 110mm step)

• Speed: 0 – 15Km/hr

The integrated high resolution video/audio and laser scanner

(optional) provide remote operator detail information of the

surrounding. Besides the ready to use control and navigation

software, a full development kit including SDK, data protocol

and sample codes, is also available.

The above robot comes close to meeting the customer requirements. While it boasts impressive

features, it doesn’t exactly meet the customers’ requirements.

www.robotshop.com has a varied inventory of robots and development kits. Most are, as

in the example above, beyond the customers’ budget requirements and there are none present

that fully match the customers’ specifications.

14th February 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

They also sell mobile platforms. These can be built onto to create a custom designed robot. An

example of these platforms is listed below.

Dagu Mr. Basic Mobile Robotic Platform Product code : RB-Dag-07 €26.90

The mobile platform is ideal for mounting custom

built hardware without having to build a mobile unit

from scratch. This is one of the more basic mobile

platforms and one of the cheapest in terms of price.

Prices for mobile platforms can reach €250+

It’s clear that obtaining a pre built robot that meets

the customers’ requirements will prove difficult to

find and will most likely vastly exceed the customers

maximum budget.

Obtaining a mobile platform however may be desirable. It would account for a significant

proportion of the budget, but would save a lot of development time and allow me to focus on

designing and building the programmable hardware and sensors. I’ve therefore decided to

incorporate this into solution 3. See below.

Other resources investigated for Solution 1 include:

http://www.active-robots.com/

http://robosavvy.com/site/

http://www.lynxmotion.com/

http://www.robotsdirect.co.uk/

All of the above sites specialise in robots and robot kits as well as robot components. As is the

case with robotshop.com, all these sites sell robots that are out with the customer budget,

and/or do not meet the customer requirements. They may however, prove to be useful for

acquiring components and hardware.

14th February 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Solution 2

Solution 2 makes use of previous HND Graded Unit projects. This may draw upon various

projects from previous years to identify prospective circuits and designs. The starting point for

this solution will be to find projects, similar in nature, and to then analyse the project.

The following projects will be analysed:

+ Line Following Robot from 2011/12 Class

I may also be able to draw upon individual projects that use similar sub systems that are going

to be used in my project. This would be particularly useful for saving development time.

The following projects will be analysed:

+ Ultrasonic Rangefinder from 2011/12 Class

While there are a couple of projects which I can examine for purposes of research, it will be

more likely that I will use these previous HND projects merely as a starting point for my project.

They may be able to provide useful information towards avoiding potential hardware /

software technical issues.

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

14th February 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Solution 3

Solution 3 is one of the more flexible solutions. While I will aim to build upon existing designs as

much as possible, the tight budget means that I will find very little in the market place that will

come in under budget in terms of pre-existing robotic solutions.

The principle behind this solution will be to use a remote control car or mobile platform as the

starting point. It will provide a blank canvas around which the robots’ sub systems can be

mounted on to.

Where possible, and depending on cost, sub-systems such as the ultrasonic sensor array will be

bought as a module rather than built from scratch.

This solution will be more cost effective than solution 1 as it will use off-the-shelf components

and in-house circuit design/adaptation, but will take longer to deliver.

The pros for this solution include:

Complete control over robot design

Able to meet the customers’ requirements

More cost effective

Can utilise past HND projects’ designs

Can use readily available hardware.

The cons are:

Will take longer to complete

May require more in-house/custom design

Higher chance for hardware / software problems

Potential Components I have researched for use in this project:

+ Dagu Mr. Basic Mobile Robotic Platform

+ Ultrasonic Sensor Module

Figure 1 - Mobile Platform Figure 2 - Ultrasonic Sensor

14th February 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Solution 4

This is an extension of solution 3. With this solution, I’m aiming to reduce the cost of production

even further by utilizing not just off-the-shelf components, but also free-of-cost components.

The City of Glasgow College is stocked with basic electronic components, development boards

and basic PCB manufacturing equipment. I also maintain a stock of basic electronic components

which can be used for this project, further reducing the need for purchasing components.

I will also attempt to source free-of-cost (Samples) components where possible.

www.microchip.com provides such a service and may be possible to acquire components as

samples which will further reduce the cost. The customer has stated they will provide the

hardware for the wireless requirement which again, reduces overall cost.

The starting point will again be a remote control car or mobile platform as it provides a

readymade chassis and starting point for designing the robot. It can be adapted and modified to

suit the project requirements. Cheap remote control cars can be easily acquired and their parts

such as wheels, motors etc (if suitable) can be reused and applied to my project.

The pros for this solution include:

Complete control over robot design

Able to meet the customers’ requirements

Even More cost effective (Compared to solution 3)

Can utilise past HND projects’ designs

Can use readily available hardware

Figure 3 - City Bytes MCU development board

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

14th February 2013

The cons are:

Will take longer to complete

Will require more in-house/custom design

Higher chance for hardware / software problems

Each solution will be graded against each other in a matrix to identify which solution is the most

economic and cost effective, and best meets the customers’ requirements.

The next section of this document will examine all of the above proposed solutions in a grading

matrix. This will help me identify which solution I will employ during this project.

14th February 2013

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

Solution Grading Matrix

Justification

Solution 1:

This would have saved a huge amount of time which is why it scored 10 out of 10 here;

however, existing robotic designs available on the internet vastly exceed the maximum budget

which rules this option out altogether. It therefore scored 0 out of 10.

I only scored it 5 out of 10 across all the remaining matrix criteria. This is because while there is

a huge array of robotic designs available, finding one the exactly matches the customer

requirements will prove to be very difficult.

Solution 2:

There have been similar projects to this one in past HND graded units. A previous project of

similarity could potentially have saved some design process time and allowed me a head start

which is why it scored 8 here. It would also have been possible to meet the budget requirements

with this option as I would still be required to build my project from the ground up and to the

customers’ budget.

There are previous HND projects which may be related to some of the sub-systems in my

project and so may be of some use during development. This is why, across the matrix criteria, it

scores variably. Nearly all the robot sub systems have been attempted as past individual

14th February 2013

Criteria Solution 1 Solution 2 Solution 3 Solution 4 Autonomous operation

5 8 10 10

Bluetooth Ver 4.0 5 0 10 10 Controllable via Bluetooth

5 0 10 10

4 Wheels + 2 DC Motors

5 8 10 10

Overall Size 5 8 10 10 Programmable Hardware

5 8 10 10

Battery Specs 5 5 10 10 Ultrasonic Sensors for Anti-Collision

5 10 10 10

Atmosphere Sensors Temp, Humidity, Co2 etc...

5 0 10 10

Availability 5 8 8 10 Cost Effectiveness 0 5 6 8 Expected Time Requirements

10 8 8 6

Score 60 68 112 114

Gavin Hannah – HND Graded Unit – SARRRO Technical Report

26 May 2013

projects which would again, save development and design time by allowing me to, potentially,

adapt and implement previous project designs.

As this is a graded unit project, I can’t simply copy someone else’s work. However, by analysing

past projects, I can draw inspiration from others’ work. So while not a viable solution, I can look

to past projects for guidance during development and for avoiding potential hardware /

software problems.

Solution 3 & Solution 4:

Solution 3 came close to being the winner, however was piped by solution 4, while very similar,

it was important to make a clear distinction between a solution making use of cost free

components and one that does not. In that regard, solution 4 emerged as the most viable option,

for the reasons outlined in the solution description above.

Both solutions graded 10 across the majority of the matrix criteria for the fact that they both

give me total control over the design and development of the robot, allowing me to fulfil the

customers’ requirements. Solution 4 scored slightly higher on cost effectiveness as it makes use

of hardware that is already available as well as off the shelf components. It scored slightly less

on Time requirements however as it will require more design time.

Having considered the solutions and graded each one, solution 4 presents the best option both

in terms of economics and customer requirements. It is the most flexible, readily available in

terms of components, and can be accomplished without exceeding the customers’ budget.

It is likely that I will draw on both Solution 3 and 4 when developing this project.

Some features will be need to be developed from scratch while it will be more economical in

terms of development time and cost to buy off the shelf components. The research into past

HND projects may also be of benefit during development.

There are also a couple of projects that I can use to advance the development of this project.

For instance, the Line Following Robot I examined contained similar features such as motors,

power sources and I/O while the Ultrasonic Range Finder uses the same principles for sensing

distance that this project uses.

Obviously, I cannot simply copy past work, but these projects can provide useful information

about potential hardware and or software problems that I would then be able to take into

consideration when developing SARRRO.

In summary, I will be utilising Solution 4 as much as possible to meet the customers ’ budget

requirements while at the same time I will be drawing inspiration from past HND projects. I will

also attempt to use Solution 3 to strike a balance between cost and development time.

14th February 2013