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!
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|
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
#define AP_RANGEFINDER_MAXSONARXL_MIN_DISTANCE 20
#define AP_RANGEFINDER_MAXSONARXL_MAX_DISTANCE 1068
class AP_RangeFinder_MaxsonarXL : public RangeFinder
AP_RangeFinder_MaxsonarXL(AP_ADC *adc, ModeFilter *filter);
int convert_raw_to_distance(int _raw_value)
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.