PROJECT ULTRASONIC RANGE FINDER

INDEX
1) ABSTRACT 2) BLOCK DIAGRAM 3) WORKING 4) ADVANTAGE 5) LIMITATION
6)

2 3 4 5 5 5 5

SAFETY CONSIDERATION AND USABILITY

7) PROJECT PLANNING

ABSTRACT
Our ultrasonic rangefinder is capable of allowing the user to determine his or her distance from an object orwall.When deciding on what type of project to design and construct, we decided that we wanted to create somethingthat would have some practical use in life. Many groups in the past created video games, but we wanted to bedifferent. We considered issues such as safety, user interface, and ease of use, and came up with the idea ofmaking an ultrasonic rangefinder. A rangefinder can be used in various applications such as a measuring deviceor an obstacle detection device. The basic principal of the rangefinder is based on the simple concepts of SONAR (Sound Navigation andRanging). First, an ultrasonic pulse is transmitted by a transducer (a device that converts a voltage signal into a sound wave and vice versa). This pulse then reflects off an object and is received by another transducer. Using the known speed of sound (340.29 m/s) and the time between the transmitted pulse (the ping) and the received pulse (the pong), one can simply calculate the distance traveled by the pulse. In addition to determining the distance between the device and an object using the known speed of sound, our initial design included two additional modes of operation. One mode was a calibration mode while the other was a speed detection mode. Since the speed of sound varies with altitude and atmospheric conditions, a calibration mode is quite useful. Our program is designed such that if in calibrate mode, the user can place the device a known distance 5 centimeters and send a pulse. The device then uses the time necessary for the pulse to reflect off the object and calculates a new value for the speed of sound. This new value is then used for all future distance calculations until the device is powered off. The original speed detection mode was used to indicate to the user how quickly he or she is moving towards or away from an object. Since speed is determined by the change in distance divided by the change in time (dx/dt), speed can be determined quite simply using two pulse transmissions. When initiated, a first pulse is sent and received by the device. The distance is calculated and stored by the device. A second pulse is then sent and received by the device 0.25 seconds later and the results stored by the device. The MCU can now take the difference in distance, divide that by 0.25 seconds, and display the speed to the user on the LCD. We had initially considered using Doppler shifts in frequency to calculate speed, but we decided against it since measuring frequency is a completely new task we would have to program (compared to just detecting a pulse) and would have required much more complicated and CPU intensive math. We also felt that the velocity of a handheld device would not be fast enough to actually incur significant Doppler shifts that would make calculations doable. Due to noise issues while testing our original program, the method of calculating distance was changed. We are now taking multiple distance samples and calculating the average. This enables more accurate readings. Obviously, the larger the number of samples, the higher the accuracy. Since we are now taking multiple samples, it is possible to measure the speed of the device in the same operating mode. Replacing the original speed detection mode is a mode in which the user can change the number of samples to use for the distance calculation. The user can increase or decrease the number of samples by multiples of 50, with 50 being the minimum. Our calibration mode was still implemented.

BLOCK DIAGRAM

WORKING
The program for the rangefinder essentially does two things: 1) transmit a 40 kHz pulse, and 2) detect when the pulse is received. All that was needed to be done was to count the time that passed between the time of transmission of the ping and the reception of the pong. There were also 3 modes of operation: normal mode, change sample number mode, and calibration mode. In order to generate the ping and count the time between ping and pong, we used two of the MCUs timers. Timer1 was running at 40 kHz in PWM mode to generate a square wave for transmission using PortD.5. Timer0 was running at 250 kHz. Timer0s purpose is to calculate time between the send pulse and the receive pulse. In normal operation, the user pushes a button to send out the ping. The MCU then counts the number of ticks it takes before the receiver detects the pong. The number of ticks is then divided by a factor of two to represent the number of millimeters between the device and the object. As stated earlier, multiple distance samples are taken and then averaged to create more accurate readings. We noticed during testing that using one sample (or only a few) gave erroneous measurements due to picking up random noise spikes. By increasing the number of samples to a minimum of 50, we obtained pretty accurate measurements. The average of all the measurements is then displayed on the LCD. In addition, normal mode also displays the speed of the device relative to a stationary object. The speed is determined by using the distance values of the middle sample and the last sample using the dx/dt formula mentioned earlier. The LCD diplays the measured distance in millimeters and the speed in millimeters/second. In the sample number changing mode you can change how many samples you want to take with a minimum number of samples being 50. This is to allow you to get a more precise measurement taking more measurements and eliminating randomness. Calibration mode is used in cases when the speed of sound may differ from that at sea level. Factors such as altitude and humidity can affect the speed of sound. To maintain correct measurements, the user places the device exactly 5 centimeters from a flat wall or object. By pressing the pulse button, a pulse is sent out and received by the device. The MCU then uses the time between ping and pong to calculate the new number of ticks per meter. The MCU uses this value for all future measurements until the device is powered off. The code was very straight forward in theory. The transducers that we used operate at 40 kHz. We first attempted to use a clock running at 80 kHz to toggle a port pin to generate a 40 kHz square wave. This did not work as well as expected. When we hooked up the port pin to the oscilloscope for testing, we noticed that the output was not an ideal 40 kHz square wave. To get around this we decided to use the PWM mode of Timer1. We configured the timer to toggle OC1A on compare match so we could pull a 40 kHz square wave off PortD.5. This seemed to solve the problem of producing a 40 kHz square wave from a port pin. To change the number of pulses in each pulse sequence for transmission we just turned on and off the toggle at certain times. Another tricky part of the program was the timing and accuracy. As mentioned earlier, we programmed a timer tick to be 250 kHz. This translates roughly to 1.36 millimeters per second. To get the right distances required some floating point arithmetic. Finally knowing where to start and stop the counter clock was a bit tricky. We did not want to count any useless ticks that did not represent when the pulse was actually sent. These useless ticks are a result of the MCU performing other operations such as floating point calculation and conditionals. It was tricky to figure out where in the code to actually start the counter.

ADVANTAGE
Since a basic principal of our project is based on the SONAR (sound navigation and ranging) i.e on ultrasonic, therefore it covers a greater distance than infrared based sensor. The rangefinder does not radiate any RF frequencies and only radiates inaudible pulses, our design did not affect other peoples designs in the lab (as far as we know). It is possible that our 40 kHz pulses could have caused interference with any other group using similar transducers, but we received no complaints.

LIMITATIONS
Due to ultrasonic sensor used in it , therefore it covers a distance smaller than the Laser sensor, hence it can only be used for small distance ranging.

SAFETY CONSIDERATION AND USABILITY

Because the frequency of the transducers is beyond the range of hearing for humans, there is no safety concern regarding the transducers. The 40 kHz frequency may, however, affect the hearing of other animals. Another safety concern has to do with the usability of the device in dark conditions. Initially, we had purchased a backlit LCD so the device could be used in the dark. Even though the LCD had a controller that was in the same family as the LCDs that we used in the past (along with an almost identical spec sheet), the LCD did not work. Instead of spending time trying to debug our LCD, we just used one provided by the lab. Alternatively, we could have implemented an audible sound that would indicate to the user how far away he or she was from an object.

PROJECT PLANNING
Since the basic principle of a rangefinder is rather straight forward (send pulse, receive pulse, calculate distance based on time difference) we decided to stick with the Atmel Mega32 MCU that we have been using the entire semester. This MCU can easily handle the software needed for the rangefinder and there was no reason not to use it. Using a different MCU would require learning all the intricacies associated with it and was not practical. Initially, we wanted to try an infrared or laser rangefinder. However, since we were going to use a Mega32 with a 16 MHz crystal, this wouldnt be possible. The speed of light is 3e8 m/s, meaning the time to travel one meter is 3.33 nanoseconds. With a 16 MHz crystal, the time resolution of the Mega32 is 62.5 nanoseconds. This means that a rangefinder based on a light wave would be accurate to only 18.75 meters. Definitely not practical! The alternative we chose was to use a 40 kHz ultrasound transducer pair. Ultrasonic transducers are relatively cheap (the ones we bought cost less than $7 for the pair) and easy to acquire. At 40 kHz, the human user would not be able to hear the pulse (human hearing is limited to approximately 20 Hz to 20 kHz) so irritancy is not an issue. As stated earlier, the time resolution of sound is only about 3 microseconds, so speed and fast execution time of code was not of great importance (compared with some other application like NTSC video signals). This made ultrasound an easy decision. Another

hardware tradeoff that was taken into account when designing and construction the rangefinder was a matter of gain. When testing the transducers with a signal generator, we noticed that the effective range was proportional to the input voltage of the transmitting transducer. Simply put, the higher the input voltage, the farther its signal could travel. Since the transmitter was being fed a signal from an MCU port pin, it would only receive 5 volts. This resulted in a poor range using the signal generator while testing (a range of only a few centimeters). By increasing the voltage to around 20 volts using the signal generator, we were able to get a range in excess of 1.5 meters. The tradeoff here comes down to the power supply used when making the device completely portable. We could have used a single 9 volt battery, but the gain on the transducer would be less than 2 to 1. Using two 9 volt batteries in series (giving a total of 18 volts) would give us a gain of slightly more than 3 to 1 (18 to 5, more specifically). Unfortunately, this makes the device heavier and cost more to operate. Initially, we decided that increased range was more of a pro than the con of one more battery. Unfortunately, using 18 volts for the gain ended up not working as desired. More on this later. The main software tradeoff was using dx/dt to calculate distance rather than using Doppler shifts. Doppler shifts would have required measuring the frequencies of the square waves as well as determining frequency shifts. This would have required code almost as difficult to write as our whole project so we just decided to measure speed using dx/dt from elementary physics. Another tradeoff was the decision to use CodeVision C instead of assembly to program the MCU. Assembly most likely would have resulted in more accurate timing and thus distance measurements, however using C had the benefit of being more user friendly in regards to programming. Using C enabled us to save time while programming and allowed us to find bugs in the code more easily.