As stated earlier, we wanted to create something that would be of practical use to people of various walks of life. For instance, our rangefinder could be used in the case of a blackout where a person needs to find his way through a dark building and cannot see where the walls are. Alternatively, it could be used by surveyors that are preparing a site for construction.
One group from a previous year had done a project using an ultrasonic rangefinder, but their project involved a pre-manufactured system. The bulk of their project was using AM transmission to communicate with the rangefinder module.
Our project is different in the fact that we built the rangefinder from the ground up.
The basic principal of the rangefinder is based on the simple concepts of SONAR (Sound Navigation and Ranging). 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.
The math required for our project is very simple. The speed of sound is 340.29 m/s at sea level. This equates to 340,290 millimeters per second. Taking the inverse of this, the time necessary for a sound wave to travel one millimeter is 2.9387 microseconds. By counting the time between the ping and pong, the distance traveled by the pulse can be determined. One has to keep in mind however, that the distance traveled is actually twice the distance between the device and the object (since the pulse travels in one direction, is reflected, and travels back in the other direction).
The speed calculation is simply the first derivative with respect to time of the position (dx/dt). Two pulses are sent and received at a known time interval and the difference in distances is used to determine the speed of the device relative to the object. More specifically, (x2 – x1)/(t2 – t1) = speed.
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 wouldn’t 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.
Since our project is a ground-up portable device that does not interact with any other devices, there are no such design standards (IEEE, ISO, ANSI, etc.) that were considered when designing our rangefinder. Since the program for the MCU was written in the CodeVision C programming language, that could be considered the only standard used in the development of the rangefinder.
Rangefinders are nothing new and can be purchased off the shelf for various applications. However, since we designed our rangefinder using only the basic principles of SONAR without using any existing product as a basis, we do not believe we are in violation of any existing patents, copyrights, or trademarks. We did, however, receive assistance from Prof. Land and the TAs in regards to circuit design and software structure, and for that we are appreciative.