Reading the Sonar works for your altitude for <10 feet right?  After that the baro takes over.  

In the APM I see that when I lift the quad over my head I still read like 1m or 0m.  Any thoughts on that?



In CLI mode it reads like 20cm to 80cm... However its noticeably off.  Do I need to calibrate this thing?  This is the LAST thing I need working before we get into missions.  I am so stoked!



Views: 1029

Reply to This

Replies to This Discussion

You know, I have been meaning to look at this again, but I keep getting distracted. There is a discussion you might be intererested in here


Read the whole thread and you will have the means, if not the answer, to solve this. 

I'm not sure why the sonar readings are not always accurate; I half-suspect that different models work differently in their output. I have been meaning to setup some tests with different models, and create a better algorithm, or even a calibration routine, but I haven't gotten to it.

Jason, is there a way you could implement a modification that woudl read a parameter in mission planner for this? I also need a scaling factor on my sonar MB 1200 but it's not the same 1.4 as other found.... 

Would be nice to be able to "calibrate" manually this for maximum accuracy!


------------------- Copied from Farooq post on Mike's tread (above) ------------------ 

Ok so here are the results and modifications that I did With the code given AP_RangeFinder_MaxsonarXL.h I tested using CLI test for sonar. Since MB1260 can measure upto 1068 cm so I used a wall to measure the distance horizontally rather than vertically. I used a measuring tape laid on the ground and held the MB1260 and my laptop in hand. Tried to maintain it vertically over the exact reading I read the distance from CLI and here are the results.



Actual Distance Measured Distance Ratio
30 23 1.304348
40 30 1.333333
50 39 1.282051
100 75 1.333333
150 111 1.351351
200 145 1.37931
250 194 1.28866
350 263 1.330798
500 377 1.32626
750 560 1.339286
800 699 1.144492





So from here it seem that except the last value the rest of the line is pretty straight. So I did some math and used an average value of 1.33 as scaling factor. Measured the distance again found some more error and changed the scaling value to 1.4. So now finally
100cm == 100 cm meaning the sonar correctly measures the 1 meter distance. Tried it on 500m it had an error of 5 cm. But this is pretty accurate with this rough method of measurement. Now I have changed the code to following in AP_RangeFinder_MaxsonarXL.h



class AP_RangeFinder_MaxsonarXL : public RangeFinder
 // public:
    //AP_GPS_MTK(Stream *s);
    AP_RangeFinder_MaxsonarXL(AP_ADC *adc, ModeFilter *filter);

    int convert_raw_to_distance(int _raw_value) 
        if(_raw_value!= 20)
         return (_raw_value*1.4);     //Added scaling to compensate the error
    }   // read value from analog port and return distance in cm

 This code is works quite accurately in range of 30 to 200 cm then I encountered a few cm different.


Would it be possible to include displaying sonar output value in the Mission Planner.

This would be a great help to all as a check on whether it is working OK.

I guess a step further is to include an offset multiplication factor for calibration.

Great work guys - Very impressive


Our findings were off by a factor of 1.4 as well.  Perhaps a drop down in the APM that lets you select your model.

yes! Jason, if you read this please comment if it is something you can add... I really think it will be quite useful for most users! 


I've done some analysis that may show why this compensation is needed

Read more here


There is no doubt that the sonar's absolute accuracy varies quite a bit - but on my quad I'm not too worried about it since it's only used for transmitter switch triggered alt hold. In this model you only care that the sonar's value is repeatable to the value set when the alt hold mode switch is set. In this role it doesn't matter that it isn't exactly 1 meter - but that it hovers at the same height over time that happens to read 1 meter. If you are using the sonar for "exact" navigation at low altitude then compensation would be needed. However, it does burn cpu cycles on the AVR that I personally would rather have keeping the update rate high until we transition to ARM processors.  So my suggestion is that any compensation be a compile time switch if it is implemented.

Agree, but sonar accuracy is needed for optical flow stabilization (in the future)

I am having the exact same issues with my mb1200. It sometimes even causes for the quad to drop in hight. Pls fix this issue. It has been driving me nuts for the past week. The sonar should be accurate by 7,5m according to the spec sheet. If you use the sonar for more then 15 minutes it will also start to give false readings and cause the alt hold to drop to max 30cm or less. I have replicated this problem with 2 mb1200 ers.

I noticed one other strange problem. If you go in Cli test mode and lift your copter it wil go letś say to 1.56m and then ik wil jump baci to 80cm and will climb again from that value. That also happens in flight. YOu alt hold ond lets say 1.80m then it wil fly for 2m and will al of the sudden lower to 80 cm. Again i noticed this behaviour on both mb1200. So clearly something is not going right.


The sonar seems to be one of the hardest things to get working. Many issues are related to the fact that it is a a tricky sensor to get a clean signal from. I spent 3 months trying to get mine working and it is a real challenge. The current software should work pretty well with alt hold if you have a good signal from the sonar. Watch out for field of view problems (landing gear or other objects in the the very wide view of the mb1200). Also all the things related to interference in the manual - such as too close to an ESC, wiring running near and ESC, poor power.  Having your sonar jumping to  a fixed value of 80cm or so is the problem I had for a month or more (mine displayed 90 cm continuously independent of the actual value) and was due to motor interference. If you plot the log of the sonar output you will see spikes going to 80 cm. 


Jason spent a bunch of time trying to code around noisy sonars but ultimately the fix for many was moving the sonar away from the ESCs. Unfortunately there are builders - even with shielding and moving the senor away still can't get it working. The logs will show spikes, and the software will cause the sudden drops or rises. Using the logs to look at the sonar output is critical and can point to what may be going on with placement or electrical/acoustic issues.

I had the same thoughts (that it was ok to have uncalibrated sonar) until I checked the alt hold code. It uses the absolute value of sonar range and blends it with barometer data. If the sonar data is off then the blend point can be quite low - loosing the benefit of the sonar, or to high - above the limits of the aonar and possibly triggering a fly away scenario.
This is all independant of the problems with noise in the sonar data which is a separate issue.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service