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
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