Theory of Operation
Ultrasound is really easy to use from a microprocessor perspective. You send out a 5v pulse-- but I have found a 3.3v pulse will do-- and then there is a certain minimum waiting period while the pulse is created. If there is an echo, the sensor sends back a 5v pulse. The amount of time it takes to get back the echo pulse gives you the distance. On the microprocessor what you do is set the signal pin high, then low, wait a fixed amount of time, then sample that pin until it goes high again. The amount of time it took for the pin to go high can be converted into distance measurement.
There is a limit to how long you can wait for the pulse to return, which can be thought of as the upper bounds of your range. There is also a limit on how soon you can detect a pulse, but this is less of a limit on your minimum range because I think you will still pick up an echo from an object pressed against your sensor. But if the signal time is counted at zero, or near zero, when an object is very close and zero when there is no reflection signal, you can have a weird errors.
Code Examples
There are lots of code examples for ultrasound. Here is an example for the Arduino, the Basic Stamp, and the Parallax Propeller.
ArduinoThere are probably lots of other examples, if you have any you recommend please send suggestions to backyardrobots@yahoo.com
Sensor Placement
How you place an ultrasound sensor is very important. The first question is will the sensor be placed in a fixed position relative to the robot. A ping sensor can handle motion well enough to be placed on a mount that rotates one or two axises. You don't want to rotate the sensor too fast, because if you move it very quickly you are likely to get poor range readings. Also, ultrasonic sensors are not very expensive, usually ranging between $20-$30. An articulated sensor mount could cost more then that, so if you want to read in many different directions it may be better to just get more sensors. Many robots have lots of ultrasound sensors, like Ziggy, so that they can detect obstacles in different directions simultaneously.
Ziggy has lots of fixed sonar sensors.
Ultrasonic rangefinders are most commonly used as collision detectors. As such, it helps to have them placed low so that they can detect objects that are not very tall, but tall enough for a robot to bump into. The problem is that if you put a sensor too close to the ground it is likely to reflect off the ground as beam widens.
Sensor is too high and misses obstacles.
Sensor is too low and reflects against the ground.
One way to avoid this problem is to place your sensor relatively high and angle it down. Then you know your beam will intersect with the ground at a constant distance Any time that distance decreases you know that an obstacle has passed underneath it.
[diagonal beam going down]If you can place an ultrasound on a rotatable sensor it can be very helpful. The sensor is fast enough to sweep an area quickly. If you detect an object you can stop the sweep, confirm the reading and articulate the sensor around the object to determine its dimensions. In this way an articulated sensor can be more useful then a fixed array.
Filtering
An important way to improve the performance of an ultrasonic rangefinder is with filtering. How much filtering you are going to want to do depends on how fast you are sampling. If you are only checking range every one or two seconds, you probably want to take the data and just use it. I normally use a propeller chip, which means that on robots like Fluffy or the Peanut Tin of Terror I can often check range twenty or thirty times a second. In that circumstance it makes sense to take a lot of samples and then filter. There two simple techniques that will improve the reliability of your range finding: low / high pass filtering and signal averaging.
Low and high pass filtering just means that you throw away values that are too high or too low. When you get high of low values really depends on the way your code handles the sensor. In some code, the sensor never getting an echo can return a zero range. Also, sometimes when a sensor gets jiggled it can return a really short range.
Throwing a way a really high value could matter if your sampling code can return a longer distance then is likely to actually be the case in your normal environment. Clamping the maximum can correct for that and really improve the results when you signal average.
Example:Sampling ever 100ms generates the following data one half of a second.
| Sample # | Range (cm) |
| 0 | 23 |
| 1 | 20 |
| 2 | 31 |
| 3 | 0 |
| 4 | 24 |
If you take each measurement and use it then your robot is going to think it is pressed against an obstacle at sample 3. But based on the adjacent data it is unlikely that the sensor is really that close to an obstacle for such a short time. More likely, the sensor did not pick up the returning signal because of some problem of vibration or a power fluctuation.
If we take the average value of these samples, we get a value of 19.6. This helps us avoid the sample #3, which looks unreliable. But it gives us an average that is probably lower than the actual distance.
Adding low and high pass filtering can make our measurement more accurate. Let's say that we assume that our sensor cannot reliably measure an object that is less than 5 cm away or more 200 cm away. In that case we have to do something with the value from sample 3. You can handle that in a variety of ways. One way to handle it is to clamp the value to the minimum and maximum possible, 5 and 100. In that case sample #3 would now be 5cm, and the average distance would be 20.6, which is probably more reliable. Another technique is discard the outlying measurements and take an average based on the number of 'valid' measurements found. In that case the average would be 24.5 cm, which looks the best fit for the data given.
Range Extenders
It is possible to get special reflectors that can extend the range of your Ping sensors. You can get one of these at Gadget Gangster. I have never tried this, but it looks like it was built for a fixed Ping sensor. I do hope to try one soon and report on how it performs.