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
How about the Sharp IR sensor based detector?
Or, Hall effects sensor/magnetic sensor that detects the proximity of the earth below?
Before I may dive in a too complicated topic.
Instead looking at the data sheet analog out is Vcc/512 per inch for a supply of 5V yield 9.8mV/inch at 3.3V 6.4mV/inch (very low for a noisly enviroment); also Maxbotix average (and peak) current draw for 3,3 power supply is 2.1mA (50mA peak!!!) and at 5v power is 3,4 mA (100mA peak)
So there is a trasducer signal of mV range with a burst noise on power supply. Note that there is an analog net of four OA LM341 that filter ,amplify and clipper the signal.
IMO decoupling power of the sensor with a 220 -1000 uF electrolitic condensator soldered with a diode near the input of the sensor power should be very good.
Firmware should only start a burst frame at 42 Khz , waiting after for a trigger of analog net to stop the timer and measuring so the distance of the target. (no dsp work)
IMO, and I've done a lot of work with the sonar, your problem is vibration. I had horrible sonar traces with my helicopter, even after doing all the electronic filters, etc. I solved it with some extreme vibration isolation techniques.
The bad sonar traces correlate 100% with your application of power. Right from the takeoff, until you do the first low pass where it goes smooth, then it gets noisy again when you apply power.
Is it possible that due to the terrain involved with the testing that that may have complicated your tests? Is it possible to try again over a paved, graded, or otherwise more smooth surface than open prairie with grass? I know that a smooth surface would not be as "real world" as one would like but if it could be made to work on a smooth surface, then adjustments could be looked at for the less than ideal situations.
Falvin - the speed itself is not a problem for the sensor. I have tested the sensor up to 80km/hr under more ideal conditions (with my car) without problem. I expect much of the problem is the spread target characteristics when moving over a large patch of uneven ground during a single return interval. If you are moving over a nice flat hard surface like a paved road, then it does OK. Not so well apparently when moving over a more uneven surface.
Yes, there is probably a lot that could be tried with dsp. One of the biggest limitations, though, is that the only output available is a single analog output - no quadrature, no doppler, and with the low pulse repetition frequency not much opportunity to do pulse integration. I have no reason to think that Maxbotix firmware does a poor job with the dsp, so it is unclear how much improvement could be made. I would actually expect that for a single, dominant target (eg the ground) it probably does pretty well wrt dsp.
Hi Doug,
I think you have yourself already solved the problem: it's speed sensor too much.
I dont know landing SkyFun speed but sonar operate a 42 Khz with a sampling rate max 10hz(100ms):
IMHO now just imagine sensor stopped and "land moving" below : we have as a typical performance in clutter,
after sonar transmit burst, the target spread in many targets because its speed is much greater than measurement time.
Now for a radar engineer as you, with a dsp get a solving will be a joke!
bye
P.S. the reason I'm leaning on the motor/prop being the culprit is based on some literature I've read in the past.
Yeah, I would suspect the motor/prop being the issue. Looks like it's working pretty well until you spool up the motor. The approach I'm taking is to use the motor to take me down to the most probable MSL altitude that would put the sonar in range AGL wise and then kill the motor and do a airspeed hold down to some altitude and then switch to altitude hold from pitch for the flare.
Thanks for the info. Will give more thought.
Regards,
Doc
-
2
-
3
-
4
-
5
-
6
of 6 Next