Pathfinder

A handheld device for detecting obstructions in the path of the blind and visually impaired

Project Report

Kyle Boyce 04324935 Adam Patten 04294629 Kerry Mayall 02130807

Contents:
1 Introduction.............................................................................................3 2 Scope and Product Specs........................................................................4 3 Interfacing...............................................................................................6 4 Power Supply..........................................................................................9 5 Microcontroller Selection......................................................................10 6 Printed Circuit Board............................................................................11 7 Programming.........................................................................................14 8 Housing.................................................................................................16 9 Expenses................................................................................................17 10 Encountered Problems........................................................................18 11 Conclusion...........................................................................................20 12 Appendices 12.1 Project Log.................................................................................22 21.2 Sensing Cane Code....................................................................28

1 Introduction
Worldwide there are more than 161million visually impaired people with 37million of them blind (Source: World Health Organisation, 2006). Currently the market for assistive devices for the visually impaired is limited to products that are relatively basic and considering there is such a large market for assistive devices there are many more approaches that could be investigated. The main requirements of an assistive device include: Light weight/portable Cost effective Reliable

The aim of this project is to design and build a prototype of a portable electronic device that will aid the visually impaired and improve their mobility. It must sense objects in front of the user and in real-time alert them of the obstructions.

2 Project Scope and Device Specifications

At the very early stages of conception we were contemplating the idea of using a fulllength cane to house the sensors. However, after a couple of weeks of research we decided this was not the route we should take to fully meet the gap in the market, as canes are already available so this would not have been much of a step up. We then decided to try and design a handheld device of much shorter length that extends not far from the hand of the user. If we were able to meet our conceptual designs the prototype would have 5 sensors from a handheld housing (such as a torch casing) with two sensing for objects around head-height, one sensing around midlevel of the user and two sensing towards the ground. We chose this 2-1-2 configuration because obstructions on the ground would be more likely and head-height obstructions are a greater danger than ones at midlevel, also the crossing over of the sensors detection beams would be around the centre sensor increasing the amount of sensing at this level. For interfacing some sort of vibration was decided upon, as it seemed the most logical choice of alerting the user without hindering their sense of hearing. Methods of vibration were investigated online and through previous students projects. These would require some sort of interfacing to a microcontroller. A microcontroller is required to trigger sensors and receive the sensors distancing signal to the closest object, and then alert the user of this obstruction when it is close enough by switching the vibrators on, we decided to produce our own printed circuit board for a microcontroller rather than using a development board.

Sensors SRF05 Ultrasonic Range Finder:

The Devantech SRF05 Ultrasonic Range Finder is a single unit that combines both an ultrasonic The
SRF05 Sensor

transmitter and receiver.

ranger works by transmitting a sound with a frequency of 40kHz, which is outside human range of hearing (approx 20Hz-20kHz), and this reflects back to the ranger from any object obstructing the path of the sonic wave. The time it takes for the wave to return to the unit can be used to calculate the distance to the nearest object in the waves path. It is designed so that if the signal is not received back within 36ms it times out and sets the echo pin to low. These units have a range of 3cm 400cm, and a beam pattern of about 45. The units are connected in a configuration that requires only one line to go to the controller. The signal to the controller is a single digital line that is used to trigger the sensor to transmit a signal, the sensor then sets the echo pin high until it receives the ultrasonic wave back, this echo is sent back through the same line to the controller so the controller must change the port pin to an input immediately after sending the trigger. The controller has 700s after the end of the trigger signal to turn the trigger pin into an input and have the pulse measuring code ready. The other two pins to be connected are simply a positive 5V signal and a ground.

3 - Interfacing
The use of audible signals for instructing the user is not used because hearing should be left unobstructed for other purposes (hearing car horns etc). Therefore we decided to use vibrators to instruct the user where an obstruction has occurred. Five vibrators are used which are taken from vibrating toothbrushes, which we found from previous students research to be an effective and cheap method. Colgate MicroSonic toothbrushes were decided upon because they were readily available in stores so any breakages could be replaced easily, and they were relatively cheap compared to other possible methods. In the toothbrushes these vibrators were powered using a single AAA battery therefore it could be assumed 1.5V was their optimum operating voltage, therefore we aimed to power them with a similar level. The five vibrators were put in a sock bandage, which is double layered (vibrators between layers) and goes on the users arm. Each vibrator is essentially connected to one of the ultrasonic sensors with the micro controller circuitry as the middleman. We required somewhere around 1.5V and 300mA to power each vibrator therefore some DC motor control had to be implemented to control them using the micro controller while powering them directly from the voltage regulator. Because the voltage regulator is supplying 5V we used a resistor as a voltage divider to supply a lower voltage to each of the vibrators. We measured the resistance of the vibrators to be around 6, which means a resistance of around 12 for R1 would give a voltage of around 1.67V over the vibrators, which is suitable. 12 resistors were commonly available so these were used. The zener diode across the motor (vibrator) is to protect the circuit from back emf spikes and the commonly available 1N4733 diodes were used.

The MOSFET driver in this case for each vibrator consisted of a BC337 transistor and a resistor on the base pin. This configuration is a common emitter setup for the BJT. The value of the resistor on the base pin needed to be calculated using standard formulas and some graphs from the datasheet for the BC337. With the collector current already determined as 300mA (how much current each vibrator requires) we can figure out our base current, IB, using the value for the BC337. From the graph we can see that when IC = 300mA at the ambient temperature = 25C the DC current gain (hFE) 170. Therefore: IB = IC / = 300/170 = 1.8mA V=IR for the base pin therefore the value of the resistor = 5/0.0018 = 2778. The closest commonly available resistor value is 2.7k so these were used.

The final interfacing circuitry for the vibrators to the PIC18f2520 is:

Below is an image of the vibrator as removed from one of the MircoSonic toothbrushes.

Pictured above is one of the vibrators as prepared for inserting into our interface sleeve. Heat shrink is used for rigidity and strength. 8

4 - Power Supply
With the microcontroller and sensors requiring 5V for effective operation this was decided as the +V we would run our circuit board at. Because 5V is not easily obtainable by commonly available batteries we decided to run off either 6V (4 AA 1.5V batteries connected in series) or a single 9V battery and use a voltage regulator to step the voltage down to 5V. Both voltage sources have advantages and disadvantages, with the 9V requiring a more common voltage regulator that were readily available to us but tending to dissipate a large amount of heat relative to the 6V supply, and the 6V requiring a low voltage drop-out regulator and taking up more space. With further consideration we deciding upon the 9V supply. The voltage regulator we used was an L7805ACV, which could only supply a current of up to 1A, which meant if more than 3 of our vibrators ran at a time it would quite likely fry the regulator, therefore either the programming of the PIC controller had to be smart enough to not run more vibrators than this at a time or we would have to use more than one voltage regulator. Because of time limitations we didnt manage to implement the smart programming therefore two voltage regulators were used instead, increasing our maximum current to 2A. A switch was connected between the battery and the circuit board to turn off power to the board when the device was not being used. This was made external to the circuit board in case the housing used made accessing the board too difficult.

5 - Microcontroller Selection
All the groups we talked to had decided upon using an OOPic or the likes to control their canes, therefore we decided to differ from the norm and create our own printed circuit board with a PIC microcontroller in it. This would reduce the overall size of our circuitry by getting rid of all the unnecessary electronic components that an OOPic has and allowing us to mount the interfacing circuitry on the same board. This would increase the complexity of our project and require more time but would improve our groups knowledge on PCBs for future projects. The microcontroller we decided upon was a PIC18f2520, one reason for choosing this particular one was because group members were more familiar with it than other options. There were many alternatives that could have been explored but this microcontroller included everything we required (i.e. various timers and ports).

10

6 - Printed Circuit Board

We decided to use EAGLE (Easily Applicable Graphical Layout Editor) to design our printed circuit board (PCB), this was chosen simply because the software was available to us. The original PCB was designed to include our circuitry for: Microcontroller Voltage regulator Transistor switching networks for control of the vibrators Pin headers for: o Programming the microcontroller o Interfacing the ultrasonic sensors o Connecting power supply o Connecting the vibrators o Connecting a switch

11

Above is the schematic for our first printed circuit board, and below is the layout of the PCB, with all the tracks, pads and drill holes layout as they were printed.

This board was changed because we were having problems with the code and decided to simplify the rest of our cane design to house only 3 vibrators and 3 sensors, we also took out the voltage regulator and placed it on a separate piece of Vero Board because we decided two voltage regulators were needed and they were likely to create a lot of heat on our board. On the next page is the schematic and PCB layout of the final board we used. When designing a PCB there are a few key point to take into consideration. Most important is to avoid sharp corners, that is 90, in the track layouts. This is due to two reasons, firstly, a smoother bend in the tracks helps maintain the even flow of electrons and keeps the board cooler than if there were sharp corners and secondly for the actual printing of the board, the tool used to etch out the tracks has much more difficulty in cutting sharp corners and produce messy results, not to mention wearing out the tool faster.

12

After some initial trouble with the board the entire circuit was constructed on a bread board and correct resistor values and operation was verified before printing the second, newly designed board.

13

7 - Programming:
Intro: Originally written in CCS the cane software has seen multiple revamps. The result programmed using MICROCHIPs MPLAB and C18 compiler, is a relatively simple, fast and ultimately user friendly system for the sensing cane user. When compared with previous canes projects that utilise the OOPIC or similar the use of the PIC allows for more efficient code and faster without the unnecessary clutter of these simpler microcontrollers. Input: The PIC 18F2520 microcontroller is responsible for the successful operation and interpretation of three ultrasonic sensors. The code, written in the high level C18 language, a C variant specific to PIC 18 series microcontrollers, analyses and processes the echo received. Based on an echos time of flight the microcontroller calculates an appropriate output signal for the user. Initially a single transmit signal was to be sent to all the SRF05 Ultrasonic sensors, and then each of their echos were to be read. However the issue of interference between sensors did no allow for this setup to be furthered. The current design allows for each sensor to be operated in sequential order. Doing so prevents any interference between sensors and allows each sensor to complete operation successfully. If the five sensor design had been implemented the opportunity for sensors that did not utilise the same transmit zone to be operated simultaneously would have been investigated to ensure maximum efficiency of the system. Output: The Pathfinder Canes human interface utilises 3 brushed DC motors in a vibrator configuration. To allow the user to understand the environment around the user the vibrators must provide an intelligible signal to the user. The software completes this by generating a pseudo Pulse Width Modulation (PWM) with varying levels defining varying distances. The PWM signal provided by the microcontroller was not used as the lowest frequency this could successfully be implemented is ~30Hz. A 30Hz signal

14

is too fast to provide separate and distinct intelligible signals for the user. To alleviate this two of the PICs 16bit timers were used in conjunction with the interrupt service routine to generate a variable PWM signal. This signal is modified at compile time to generate an approximate 0.5 1Hz signal. PWM signals in this range are individually identifiable allowing the cane to warn of hazards at varying ranges.

Trigger sensor: A specialised mode was intended to allow the user to pinpointing obstructions particularly in areas where multiple obstructions may generate a confusing output. When in confusing and/or cluttered areas the user can confirm exactly where impediments may be. By pressing the trigger button located on top of the housing only the central sensor is operational, and focuses on the area directly in front of the unit. The output PWM ranges would have been altered in this mode to provide direct output for the user. This operation was wired in the hardware successfully but the programming for it to be implemented was never perfected enough to keep the trigger working, therefore in the final code used the trigger section was commented out. With further time and testing the trigger operation could be implemented and would give the unit another very useful mode of operation. The full version of the code can be viewed in section 12.2 on page 28 at the rear of this report.

15

8 - Product Housing:
The main housing for the design was constructed from an Eveready torch, shown on the left. The torch was emptied of any unnecessary parts, and some of it was also painted black. The plastic cover of the torch was used to mount the sensors and the hollow casing contained all of the circuitry. As can be seen in the final image of the casing below a part of the side of the torch was cut out to allow access to the circuitry and the battery for when it needs changing. The switch on the original torch was removed, and its location was used to mount a push-button momentary switch that we used as a trigger to make only the top sensor run, this was intended so that the scope of the Pathfinder is reduced and objects can be located more specifically.

The vibrators were housed in a wrist brace. From the original brace we removed the metal brace and used the pocket it was in to hold two of the vibrators (one at the palm end of the brace and the other at the opposite end. The third vibrator was placed on the top side of the brace and was held in by another pocket. The final layout of the our vibrator wrist configuration is shown in the picture above with the rest of the housing. This wrist strap can be modified for left or right hand use by simply switching between the two pockets in which the vibrators are mounted.

16

9 Expenses:
Below is a breakdown, component by component, of the expenses for the Pathfinder project. Expense UltraSonic Sensors Microsonic Toothbrushes Eveready Torch Voltage Regulator Pin headers Switches Heatshrink Batteries Batteries Insulation Tape Nuts & Bolts Hinge Spray Paint Wrist Splint Sand Paper Micro PIC18F2520 TOTAL QTY 5 3 1 2 1 1 1 2 2 1 1 1 1 1 1 1 Ea US$29.50 $7.78 $14.09 $1.50 $7.43 $1.46 $2.19 $1.35 $1.88 $0.82 $3.89 $1.49 $5.99 $14.95 $1.49 $18.60 Total ($NZ) $189.00 $23.34 $14.09 $3.00 $7.43 $1.46 $2.19 $2.70 $3.75 $0.82 $3.89 $1.49 $5.99 $14.95 $1.49 $18.60 $294.19

17

10 - Encountered Problems:
Our initial design of the circuit board was good however it was designed with circuitry for five vibrators and we decided to go down to three, and it also had one voltage regulator on it, which we upgraded to two voltage regulators and decided to keep separate from the rest of the circuitry. The first printed board was also quite damaged after all the testing we did on it therefore re-printing seemed like a much cleaner alternative for the final prototype. The biggest problem we encountered was getting programming onto our microchip; most of the issues came from insufficient access privileges on the computers, which meant we could not install updates that we needed to support our chip in the language we originally chose. Our first programming package we were using was CCS and we were informed that this was easy to link into MPLAB and then use the ICD2 to program the code onto our chip; therefore we had designed our PCB with the wiring for ICD2. We investigated many methods to get our code onto the chip including changing the PCB circuit to use ICD-U40 and program using CCS still but this didnt work either. In the end we had to re-write our code into C-18 compatible code and this took considerable amounts of time that we really didnt have and After the initial problems with programming we decreased our number of sensors to only three to ensure more problems werent encountered further into development and likewise we decreased the number of vibrators to three, this meant when our final circuit board was printed there was less chance of problems occurring that we essentially wouldnt have had time to fix. As mentioned earlier the code for the trigger could not be implemented in our final design. For the final working prototype the trigger code was removed and the unit operated with the sensors simply pinging cyclically and returning the modulated signal at various strengths depending on how close the object that had been detected was. On the day of prototype testing we had two faults, one minor and one major. The first fault was in the power on and off switch. It seems that if switched slowly the

18

microcontroller does not initialize correctly and the sensors do not activate. We have come to the conclusion that this is due to the switch bouncing when activated slowly and was overcome by making sure to flick the power switch firmly and quickly. This could be overcome with revision by placing a small capacitor across the main power terminals. The second issue we had was that one of our vibrating motors failed. This occurred due to the fact that the stranded wire leads into the vibrator are very fragile and actually severed from the base of the motor during testing. This meant that while we were running three sensors we only had two vibrators in the interface running. We modified the interface so that the running vibrators accounted for left, right and straight ahead and head high objects would need to be detected with minimal scanning until a replacement vibrator could be found. As this is a prototype we concluded that were this device to be taken into production, vibrator motors that were more durable would need to be used.

19

11 - Conclusion:
Overall our project went as planned. We ended up managing to retain our original idea of having a cane-less cane, keeping our entire unit hand held and without a long shaft or the need to rest in on the ground. Although this presented issues for stability of the sensors and therefore the accuracy of readings obtained from them, we have written our code to compensate of the handheld nature of our device and have found it to operate soundly. We encountered much difficulty with the programming of the microcontroller, with programs first writing to the chip but then not operating then writing to the chip but operating in an unexpected fashion. This was eventually overcome and in the process we learnt a great deal about the various C language varieties for programming PIC microcontrollers and their compilers. We also learnt a great deal about Printed Circuit Board and Microcontroller design as for this project we designed our own microcontroller after deciding that the generic ooPIC controller that was available had unacceptably slow scan times and we also integrated the transistor switching network for our interface onto the same circuit board. For this project we were given a budget of $300. Due to the cost of the sensors we used for our design being so high we thought at first that keeping within this budget was going to be very difficult. However at the end of the project, once all expenses were calculated we were pleased to find that we had in fact come in under budget. Overall, this project was extremely time-consuming, much more so than we had anticipated. Too much time was spent in the design phase which left us stretched for time to actually implement our designs and work all the kinks out of the system. Given the relatively small budget for this project, some areas had to be put together a little bit roughly, meaning the finished product lacked some of the finesse and style that a ready-for-production model might have. Things such as the vibrators sourced for the interface would have been preferably replaced with more sophisticated motors

20

or vibrators had our budget allowed for it. This project has taught us a very great deal about PCB design, microcontroller design and integration and the design of peripheral circuits for microcontrollers. We now have far more experience in the C18 PIC C language for programming and implementing the PIC series of microcontrollers. In the end we have produced a product which for the most part meets our original hopes and design specifications. We have managed to avoid the use of a full length cane, which had been one of our key design goals as we felt that producing a simple handheld unit was more in the innovative spirit of this project. We have produced a device which is functional whilst also being a little innovative and we hope we have provided a platform which can be taken further in the future.

21

12 - Appendices: 12. 1 - Project Timeline:

29/02: Project plan and proposal produced, possible ideas for construction, methods and functionality brainstormed and discussed. Much debate over length of cane, whether to use a cane at all handheld, head mounted, neck mounted etc. 03/03: Project proposal revised, extra considerations and technical aspects considered and added. Revised CAD model of prototype cane produced 04/03: 2D drawings of CAD model produced, more technical aspects added to project proposal, decided on 3 sets of 3 ultrasonic sensors for better range measurement and better performance with the microprocessor we are currently considering; the ooPIC. Considering the ooPIC as we have heard it is simplistic to program, has the required inputs/outputs and the entire board is relatively small, will fit into a range of housings that we may consider. Have picked up an ooPIC for experimentation. Housings we are currently considering; torch, either larger dolphin torch or smaller cylindrical torch, this would allow for a handheld device more portable, lighter to carry, less risk of sensor damage. Otherwise a full cane model would be considered with wheels for the cane to roll on. Currently leaning more towards the handheld model although considerations have to be made for the fact that the way the device is held will affect its performance, have to find a way to make the user hold it the way we want them too. Initial project proposal presented in interview 07/03: Contemplating ditching the ooPIC or any other pre-built microcontroller board and selecting our own microcontroller and building a custom board. This allows us to choose how we power the chip and all components and allows us to dictate exactly what the circuit can do and build it to a physical size convenient to us for fitting inside a handheld devise without other large cumbersome boxes or otherwise to deal with. Have decided to go with a completely handheld device, most likely using a torch housing, or something similar. Intend to do research on how to interface right now looking at a sleeve or glove configuration to both interface with the user through vibrators and keep the device held at an angle optimal for sensing objects. Decided to use ultrasonic sensors only, not to use any infra red as the range on infrared sensors is not sufficient and they have a curve to them, the sensor is not linear and as such code would have to be written to compensate for this, an entirely unnecessary practice when all of this can be avoided by only using ultrasonic sensors.

22

12/03: More discussion over the suitability of the ooPIC for this application, came to the decision that we would definitely be creating our own micro controller for the sensing cane. We decided to split the project up into three parts, one for each group member, the parts being: Select a PIC and build a microcontroller, writing up pseudo code for the entire cane project and designing the circuitry other than that of the microcontroller. Also decided that work on producing a physical prototype needed to begin soon. 20/03: We decided upon the method of interfacing with the user. Simple small vibrators will be used, sourced from vibrating toothbrushes. We are currently discussing how to convey information through these vibrators. I.e. they vibrate slowly at first then faster and faster as objects get closer, vibrators positioned for left, right, up, down and straight ahead, emergency all vibrators on for large drop and so on. 27/03: Today we had group meeting for the project. During this meeting the PIC18F2520 was decided on as our PIC as it is a suitable physical size for cutting the size of our microcontroller down to make it as compact as possible, had an ideal number of input/output pins - 15 in total, a suitable number of pins overall - 28, 3 timers two 8-bit one 16-bit, we needed a 8MIPS or more PIC and the 2520 is 10MIPS and the 18F2520 also has its own 8MHz internal oscillator, although we are as of yet undecided as to whether or not this is going to be idea and if not we will use an external oscillator. Learnt how to use the program EAGLE which will be used for designing our microcontroller board and then producing it, spent some time learning how to use the program and import libraries, make connections etc. 31/03: Found the EAGLE library for the PIC18F452 , which included a footprint and schematic for the 18F2520 and spent time becoming familiarized with the libraries and features of the program. 03/04: We began designing our microcontroller board. Much time was spent trying to locate items in the libraries as being new to the program EAGLE meant that everything that is done is a learning curve. Have set up power and ground rails, voltage regulation and a modular input for programming the PIC so far. 06/04: Obtained ultrasonic sensors. Fellow group member began testing of sensors and project report on the sensor design, control and interface.

23

10/04: The initial layout of microcontroller board containing the architecture for programming ports, input, voltage regulator, power and ground shown to fellow group members for discussion. Transistor network design decided upon for controlling output to the 5 vibrator motors. First pseudo code draft finished and discussed. All agreed was heading in the right direction. 13/04: Finished designing microcontroller board and managed to lay the tracks out in a way such that there was no need for any jumpers. Final design will need to be checked to see that all connections are on the board and going where they should be. Now we just need to decide on component values etc. 15/04: More of the final report for the project was completed, mostly focusing on the ultrasonic sensors which we have been analyzing and testing. 16/04: Showed the PCB board design to the lab technician for advice on the layout and track widths, component spacing and so on. Given tip that 5pin header could be used instead of RJ12 jack for programming as this is lest costly and takes up less space on the board. Otherwise design was said to be fine and should be good for printing. 22/04: Wrote progress report. Made an RJ12 to 5-pin socket cable for interfacing with our microcontroller and programming it. 25/04: Hooked up the ultrasonic sensors in the configuration we had decided open with simple power and ground and manually sent triggers to the sensor, viewing the output obtained from the sensor on an oscilloscope. In doing this we were able to get a feel for the range of the sensors and see the digital output of the sensors in real time. This was useful for helping us become familiar with the operation of the ultrasonic sensors and the type of signal we were going o be handling. 30/04: Today was spent calculating values for the resistances in our transistor network control circuit. This was done using transistor logic to bring the voltage out of the microcontroller down from 5V to 1.5V, the operating voltage of the vibrator motors. The vibrators can be operated at higher voltages however they already vibrate hard enough at 1.5V and we believe that operating them at a higher voltage could damage them or wear them out too quickly.

24

02/05: Microcontroller board submitted for printing. More code was completed and the transistor network portion of the final circuit was tested on a breadboard using the resistors of our calculated values to test it. A fixed 5V power supply into the prototype circuit and one of the vibrator motors hooked up accordingly. The circuit was found to operate perfectly, feeding an almost exact 1.5V to the motors using the values we had obtained theoretically. 07/05: Received printed circuit board and the components were soldered on. Discovered many of the component pads for soldering to were extremely small, almost unworkable, and the spacing for the resistors had come out wrong, meaning the resistors did not properly fit on to the board. Decided a revision of the board was needed and a reprint necessary, however continued on with current board for testing and debugging phase, a new board will be produced mostly for aesthetic reasons. 12/05: Realized that our circuit was going to be pulling much more power than we had realized, With each motor pulling around 300mA the circuit overall was going to be pulling close to 2A and our current circuit only contains one voltage regulator, a 1A regulator which will not cope. This was added to consideration for the circuit redesign. 14/05: Discussion held over exactly what kind of housing was to be finally decided upon and newer version of the code for the cane was presented and analyzed, looking for improvements and unnecessary segments.. 16/05: First fully completed code presented and programming of the board has commenced. 19/05: Facing serious issues with programming the code to the microcontroller. Microcontroller and circuit board rigorously tested for faults however none can be found. 21/05: Having serious difficulty with the code, can not get any of the programming suits to compile code properly and when we do, we are able to identify and connect to our microcontroller and even program it however nothing happens thereafter, the PIC seems to remain idle not actually running through the code. It was decided that the voltage regulator would be taken out of the main microcontroller and added to another second circuit containing two of the 1A voltage regulators. While this is not strictly

25

recommended application, our device is a relatively low power, low voltage circuit and as such we believe that this system will work fine. All of the vibrators were sourced and wired to 2 pin sockets for easy plug and play interfacing with our microcontroller. 26/05: There are still serious issues with the code not running on our microcontroller. Have been running through process of elimination, testing our programming cable for connectivity, correct wiring configuration for programming, correct pull down resistor for the MCLR and even created a replicate of the circuit board on a breadboard for programming incase the printed board had been damaged.. Went and obtained a second 2520 in case of a faulty or blown chip, the replacement made no difference however. Decided due to power requirements and to simplify things since not even basic code was working to cut down to 3 sensors and 3 vibrators. The new board was redesigned for this consideration, working out extremely well as it meant we could make the board even smaller whilst spacing out components for easy assembly and access. 27/05: As there are still issues with the code all other parts of the cane that could be completed were set onto whilst one group member worked on rectifying the code problem. All vibrators and sensors were wired and had sockets attached ready for plug in connection, new board was submitted for printing after learning how to edit Eagle component libraries to make the pads for components bigger and more secure for soldering to. Went out and obtained housing; large Eveready torch which was gutted and cleared out for our components. 28/05: Programming the microcontroller continues to be a problem as we are certain that the code is workable just for no explainable reason the chip will not run programs written to it. One group member worked on this again today whilst the remaining members worked on mountings for the sensors and the layout of the board, battery and other items within the housing. A wrist protection strap was purchased and the metal plate within it removed. This was decided upon for our interface, the vibrators inserted within it as it can be strapped tightly to the arm, meaning for a definite contact between the arm and vibrators and due to the fact that the arm strap has to be put on the same way every time. This means that the wearer can not put it on incorrectly and as such the correct vibrator will be associated to each direction. 29/05: Excellent day as programming finally succeeded. Problem was found to be that originally CCS was used for programming and after this had failed the programmer had moved to MPLab and the C18 compiler but had continued to use CCS code which differs from how the C code for microcontrollers is written in C18. A very simple basic program for setting the output pins high was written, programmed and run and found to work. Basic working code was begun and more of the project report was

26

worked on. Newly printed board was obtained and all the components soldered to it, providing a compact and finished board for easy testing and programming, 30/05: Simple version of the code for running the cane was completed and programmed to he controller. Using the entire circuit outside of the housing this code was tested and determined to be working as we had desired. Testing the code in this way we fine tuned the distance to which the sensors would return a warning. More work completed on the final report and work started on the more technical code containing interrupts and PWM for our more comprehensible interface, the vibrators will vibrate softly at first when something comes into range, vibrating harder as the operator of the cane comes closer to the obstacle. Work begun on webpage, theme and style were decided upon. 01/06: Group meeting held for analyzing and programming of final version of code. Web page reviewed and worked upon and the project report completed. General assembly tasks competed with modification of housing for mounting circuit, getting battery in and out. Housing parts spray painted for more aesthetically pleasing finish and wires shortened and so on to keep internals of the housing tidy and easy to assemble. Name decided upon for product and spray painted parts left to dry over night. 02/06: All finished and painted parts were collected and complete cane assembly put together and finished. Performed testing of cane and minor tweaks made to the code for ensuring the device is configured to the correct range sensing. Web page completed and finalized, work report reviewed and finalized, all parts of the project are now finished.

27

12.2 - Sensing Cane Program:

#include "p18f2520.h" #include "delays.h" #include "timers.h" #define ON #define OFF #define INPUT #define OUTPUT #define B_level #define C_level #define D_level #define Timer1_Value #define Timer3_Value #define PWM_Period #define TIMEOUT struct ping { int ping1; int ping2; int ping3; } ping; int t33_percent_flag=0; void init (void ) { INTCONbits.GIE = 1; INTCONbits.PEIE = 1; RCONbits.IPEN = 1; ADCON1 = 0b00001111; //to set port A as digital I/O TRISB = 0x00; //sets all of port B to outputs TRISAbits.TRISA3 = INPUT; //sets pin to input for trigger PORTAbits.RA3 = 0; //sets input trigger to zero until it's pressed PORTB = 0x00; //sets all vibrator pins to off PORTA = 0x00; //sets all sensors to off OpenTimer0(TIMER_INT_OFF & T0_16BIT & T0_SOURCE_INT & T0_PS_1_1); //enables timer0, disables interrupts, sets at 16bit timer, uses internal clock source, prescaler 1:1) OpenTimer1(TIMER_INT_ON & T1_16BIT_RW & T1_SOURCE_INT & T1_PS_1_1 & T1_OSC1EN_OFF & T1_SYNC_EXT_OFF); OpenTimer3(TIMER_INT_ON & T3_16BIT_RW & T3_SOURCE_INT & T3_PS_1_1 & T3_OSC1EN_OFF & T3_SYNC_EXT_OFF); WriteTimer1(Timer1_Value); WriteTimer3(Timer3_Value); PIE1bits.TMR1IE = 1; // enables TMR 1 interrupt IPR1bits.TMR1IP = 0; // make TMR 1 Interrupt low priority PIE2bits.TMR3IE = 1; // enables TMR 3 interrupt IPR2bits.TMR3IP = 0; // make TMR 3 Interrupt low priority } void timer_isr (void); #pragma code low_vector=0x18 void low_interrupt (void){ _asm GOTO timer_isr _endasm } #pragma code #pragma interruptlow timer_isr save=PROD void timer_isr (void){ if(PIR1bits.TMR1IF==ON){ 1 0 1 0 0b111000111 / 0b111000111 0b1110001111 0 0b1010101010101010 4 20000

/time to edge of second range //time to edge of third range //timeout range //=2^16 - 1/3*(2^16-Timer1_Value)

//a structure to hold the timer results for each sensor

28

PIR1bits.TMR1IF = OFF; //reset timer 1 IF PIR2bits.TMR3IF = OFF; //reset timer 3 IF WriteTimer1(Timer1_Value); WriteTimer3(Timer3_Value); if(ping.ping1<D_level){ PORTBbits.RB0=ON; }else{ PORTBbits.RB0=OFF; } if(ping.ping2<D_level){ PORTBbits.RB1=ON; }else{ PORTBbits.RB1=OFF; } if(ping.ping3<D_level){ PORTBbits.RB2=ON; }else{ PORTBbits.RB2=OFF; } t33_percent_flag=0; } if(PIR2bits.TMR3IF==ON){ PIR2bits.TMR3IF = OFF; WriteTimer3(Timer3_Value); if(t33_percent_flag==0){ //33% TIMEOUT if(ping.ping1<C_level){ PORTBbits.RB0=ON; }else{ PORTBbits.RB0=OFF; } if(ping.ping2<C_level){ PORTBbits.RB1=ON; }else{ PORTBbits.RB1=OFF; } if(ping.ping3<C_level){ PORTBbits.RB2=ON; }else{ PORTBbits.RB2=OFF; } }else{ // 66% timeout if(ping.ping1<B_level){ PORTBbits.RB0=ON; }else{ PORTBbits.RB0=OFF; } if(ping.ping2<B_level){ PORTBbits.RB1=ON; }else{ PORTBbits.RB1=OFF; } if(ping.ping3<B_level){ PORTBbits.RB2=ON; }else{ PORTBbits.RB2=OFF; } } t33_percent_flag=1; } } //END ISR void main () { //needs to be one after either interrupt

29

init(); //call initialisation routine while (1) { // ---- Sensor I --TRISAbits.TRISA0 = OUTPUT; PORTAbits.RA0 = ON; Delay10TCYx(30); PORTAbits.RA0 = OFF; TRISAbits.TRISA0 = INPUT; Nop(); WriteTimer0(0); while (PORTAbits.RA0 == OFF) { if ( ReadTimer0() > TIMEOUT) { break; } } WriteTimer0(0); Nop(); Nop(); Nop(); while (PORTAbits.RA0 == ON); ping.ping1 = ReadTimer0(); Delay10KTCYx(2); // ---- Sensor II --TRISAbits.TRISA1 = OUTPUT; PORTAbits.RA1 = ON; Delay10TCYx(30); PORTAbits.RA1 = OFF; TRISAbits.TRISA1 = INPUT; Nop(); WriteTimer0(0); while (PORTAbits.RA1 == OFF) { if ( ReadTimer0() > TIMEOUT) { break; } } WriteTimer0(0); //sets timer to 0 Nop(); Nop(); Nop(); while (PORTAbits.RA1 == ON); ping.ping2 = ReadTimer0(); Delay10KTCYx(2); // ---- Sensor III --TRISAbits.TRISA2 = OUTPUT; PORTAbits.RA2 = ON; Delay10TCYx(30); PORTAbits.RA2 = OFF; TRISAbits.TRISA2 = INPUT; Nop(); WriteTimer0(0); while (PORTAbits.RA2 == 0) { if ( ReadTimer0() > TIMEOUT) { break; } } WriteTimer0(0); Nop(); Nop(); Nop();

//sets port A pin 0 for output //sets port A pin 0 high //delays for trigger high //sets port A pin 0 low, end of trigger pulse //sets port A pin 0 to input

//resets timer to 0

//waits to until the echo finishes by returning to 0 //copies the timer value into a register that represents the time taken for echo

//sets port A pin 0 for output //sets port A pin 0 high //delays for trigger high //sets port A pin 0 low, end of trigger pulse //sets port A pin 0 to input

//waits to until the echo finishes by returning to 0 //copies the timer value into a register that represents the time taken for echo

//sets port A pin 0 for output //sets port A pin 0 high //delay for trigger high //sets port A pin 0 low, end of trigger pulse //sets port A pin 0 to input

//sets timer to 0

30

while (PORTAbits.RA2 == 1); ping.ping3 = ReadTimer0(); Delay10KTCYx(2);

//waits to until the echo finishes by returning to 0 //copies the timer value into a register that represents the time taken for echo

/*//--- Trigger Sensor --if(PORTAbits.RA3==1){ while(PORTAbits.RA3==1){ ping.ping2=C_level; ping.ping3=C_level; TRISAbits.TRISA1 = OUTPUT; //sets port A pin 0 for output PORTAbits.RA1 = ON; //sets port A pin 0 high Delay10TCYx(30); //delays for 20 instruction cycles (each instr cycle = (8MHz/4), instr period = 1/2000000 = 0.5us, 10us delay = 20 instr cycles) PORTAbits.RA1 = OFF; //sets port A pin 0 low, end of trigger pulse TRISAbits.TRISA1 = INPUT; //sets port A pin 0 to input Nop(); WriteTimer0(0); while (PORTAbits.RA1 == OFF) { if (ReadTimer0() > TIMEOUT) { break; } } WriteTimer0(0); //sets timer to 0 Nop(); Nop(); Nop(); while (PORTAbits.RA1 == ON); //waits to until the echo finishes by returning to 0 ping.ping1 = ReadTimer0(); //copies the timer value into a register that represents the time taken for echo Delay10KTCYx(2); } }*/ } }

31