"Do not average your Max-Sonar results..ever!" who knew?

Let's Make Robots
, , ,
1

I've apparently been mistreating my MaxSonar EZ-1.   I can't find where i stole.. er... borrowed my idea from for averaging a series of responses to reduce the inconsistencies, but I was looking up some information on the Arduino pulseIN() timeout (Thanks Oddbot!) and came across http://playground.arduino.cc/Main/MaxSonar   ... Yeah... I know it should have been one of my first places to look, but...

Then I came across this article in the forum... http://forum.arduino.cc/index.php/topic,20920.0.html

 

"Filtering in General
For filtering, do not average.  Do not average.  Do not average.  (Did I say, do not average?)  We have a lot of internal filtering in our products and if you receive readings that you feel must be filtered, do not use averaging.  Instead, throwing out the incorrect range values will produce the best results.  Averaging valid and invalid readings together will provide incorrect data.  

Filtering
The filtering that works best, is either a Mode filter or a Median filter.  (Did I forget to say, "Do not average the readings"?)

The Median Filter
The median filter would take the last group of readings and first sort them and then pull out the center reading.  Here one might take three or more readings (up to say about 11 for people sensing) and after sorting the readings in order of range, pull out and use only the middle (median) reading.  Fairly good filtering.

The Mode Filter
The mode filter would take the largest group of the same readings out of a set of even larger readings.  Very robust filtering.
Filtering for most applications, the Very Simple Mode Filter

The simplest mode filter, is simple as this question, "Do the last two readings agree?" (with in a certain distance, and the certain distance depends upon how much variation one expects in the actual use.  Even so most use the logic of "are these readings exactly the same")?  If so, use the readings, otherwise throw away to oldest reading, and compare the next reading with the most current reading and do this again.  Obviously with very noisy data, one might have to sample a larger group of readings, and pull out the most common reading, but for most applications, this simple two reading filter works very well.


Even so, for specific cases, one has to try and find out what works best.

Please let us know if you have any further questions. I request that you email me any questions at [email protected].


Best regards,

Scott Wielenberg"

 

 

 

References:

http://playground.arduino.cc/Main/MaxSonar

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1288290319

http://garagelab.com/profiles/blogs/tutorial-ultrasonic-range-finder-arduino

http://www.maxbotix.com/articles/033.htm

http://howdweknows.blogspot.ca/2011/03/maxsonar-rangefinder.html  <---  This one does averaging...

http://www.danielandrade.net/2009/07/26/ultrasonic-range-finder-with-arduino/  <----  Also uses averaging...

 

 

2

That’s one that should help a lot of people

Thanks for finding this, I was never happy with the averaging method.

3

Some tests with a sonar sensor

Thanks for sharing the data! I was testing a sonar a few days ago, when I found myself in the same situation: strange readings at some points, perfect readings half of the times. What I was thinking is this: let’s say you have a wall at your front, at 2m, and another wall at your right, at 2m too. You start taking readings from a fixed point, and rotate the sensor to the right. The fisrt readings will be very accurate. As you reach 30° or so, the wall bounces back the sound away from the sensor, so eventually you’ll get no echo or a long distance reading from a multiple bounced echo. As you reach 40° you will start hearing  the echo that has bounced twice, first on the wall in front and later in the wall on the side, so the reading will be a bigger distance than expected. At 45° you’ll have an exact reading. And as the sensor goes on rotating you’ll see the same strange pattern. 

So it’s not a matter of filtering, but drawing the walls you can measure in front of you. With that in mid you should be able to predict the measures and compare them to the real data, so you can guess if it’s a multiple bounce echo or a real reading.

A second thing I’m taking into account is that a long pulse can be safely ignored, but a short pulse has to be something close before the wall. This is, you can expect a pulse not to come back (a false negative), but you don’t have false positives. 

So I will continue reading and, if I can develop a simple code to interpret the data, I’ll post it. Good luck!