Project Technical Report

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

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.

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

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.

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.

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.

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

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 31 st 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.

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.

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.

APPENDICES i Project Proposals ii Project Requirements Questionnaire iii Customer Meeting Minutes iv Project Objectives v Project Brief vi Project Solutions

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

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?

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.

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. 31 st 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.

31 st January 2013 [ iv ] PROJECT OBJECTIVES

[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. 31 st January 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 31 st 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. 31 st January 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. 14 th February 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. 14 th February 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. 14 th February 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.

14 th February 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 14 th February 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

The cons are: Will take longer to complete Will require more in-house/custom design Higher chance for hardware / software problems 14 th February 2013 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. 14 th February 2013

Solution Grading Matrix Criteria Solution 1 Solution 2 Solution 3 Solution 4 Autonomous 5 8 10 10 operation Bluetooth Ver 4.0 5 0 10 10 Controllable via 5 0 10 10 Bluetooth 4 Wheels + 2 DC 5 8 10 10 Motors Overall Size 5 8 10 10 Programmable 5 8 10 10 Hardware Battery Specs 5 5 10 10 Ultrasonic Sensors 5 10 10 10 for Anti-Collision Atmosphere Sensors 5 0 10 10 Temp, Humidity, Co2 etc... Availability 5 8 8 10 Cost Effectiveness 0 5 6 8 Expected Time Requirements 10 8 8 6 Score 60 68 112 114 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 14 th February 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. 14 th February 2013