A feature frequently requested is to add support to ArduPlane for using sonar to control the landing flare.The answer, unfortunately, is probably no. Take a look at this graph I obtained yesterday...
This has been on my to-do list for ages as I have never gotten around to getting some real world data to see if this would work. Finally got the real world data yesterday with the Maxbotix XL-EZ1 mounted in a SkyFun.
The graph shows data logged on a flight with 6 low passes using APM2 and the MaxBotix . The standard ArduPlane/ArduCopter sonar library was used, including the 6 element mode filter (as recommended by MaxBotix. The terrain over which the flight was flown was middle of the road in terms of difficulty for the sensor (in my estimation) being open arid prairie, with scattered clumps of low prairie grass Based on the actual low passes the "good" altitude estimates (bottoms of the troughs) by the sonar were probably better than the equivalent altitude estimates by the baro sensor. Unfortunately, as can be seen, when moving over the ground with significant speed the sonar fails to maintain a clean estimate of the altitude, even with the mode filter.
Of particular concern would be occasions such as during the second, fourth, and sixth pass, where the sonar suddenly reports a much higher altitude than actual. If using sonar for flare control, this would likely result in a pitch down, with bad results.
Certainly under good conditions the sonar could be used for flare control, but it does not appear to give a robust enough estimate of altitude to be useful for general use.
Comments
Robert, We have already looked into using the accels. You can't just use Z you use all of them pushed through the DCM to get your vertical acceleration. The real stick of the problem is the double integration and how you go about estimating vertical velocity in the middle. Long story short I think it is doable with our current approach just have to test it in something other than a sim
Doug, good work on the digital filtering. I thought that the sample rate of the sonar is fast enough that some filtering would help a lot without causing phase lag. What I would really like is if somebody could make an algorithm which looks at Z-axis accelerations to throw out implausible altitude returns to help filter and make a more robust altitude estimation system.
maybe a dead stick landing approach would help ,keeping the same AOA and adjusting the throttle and or flaps to dump lift and maybe some IR beacons on the ground so the plane can approach at the correct direction and angle to a known surface like a smooth road instead of bushes on the side ,does this make any sense ?
Hi Doug,
I know I'm getting into this discussion a little late and my comments might appear a little negative (I intend them only in the spirit of trying to improve the experimental procedure), but it seems to me that the experiment is inconsistent with normal flight circumstances under which you'd want to use an auto-landing feature.
If you're ditching in a paddock with uneven ground, cutting throttle and achieving minimum descent rate at a sufficient margin above stall speed is all you need to minimise damage. If you're doing auto-landings at a prepared field, why would you be concerned about data from an experiment over open arid prairie with clumps of grass? It seems to me that you're asking the sensor to tell you how it would behave in a situation in which you're not likely to use it. (At least, I question why you would need it in this situation).
If, on the other hand, the experiment is purely one of "how well does this sensor detect ground variations at speed X and altitude Y", then one would imagine and more controlled experiment involving your car and a set of upturned boxes fixed to the roadway would be more meaningful and give data more amenable to revealing sensor performance.
A final question: is the intention to find an auto-landing solution, or an auto-landing solution using this specific sensor?
Cheers,
Tim
I have a couple of the Optilogic 800s, They cost me over 600 dollars, they are too heavy and large for a quad, but would work on a larger plane. They can do 200 updates per second.... too bad they are not smaller...
Nailed it! Good work!
Doug, nice work again. Thanks for sharing, Pete
Doug, can you respost that image? It didn't show up...
OK - Maybe I was too pessimistic. I did a flight test today with the mode filter removed so that I could try different filters with some post processing. A couple of things that were apparent.
First, without the masking of the mode filter it was very apparent that the drop-out issue is highly correlated with throttle. Still to be determined is if the problem is mechanical vibration or electrical noise. My next step will be to look in to that.
Also, by using a tweaked statistical "offset mode" filter (IE looking at the 3rd largest of 6 samples), things cleaned up dramatically. Check out the plot below. The "double dip" characteristic shown by the sonar at the bottom of the 4th and 5th passes shows there is some work yet to be done, but this is definitely looking more promising...
-
1
-
2
-
3
-
4
-
5
of 5 Next