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
Peter, the general problem with our accels is that the zero g value tends to "wander". We sample and average at a high rate, and the integration itself seems to pose no problem. The problem is that the zero g point will move a bit and then we start double-integrating a small constant value. If this offset was stable then drift compensation would not be a problem. However it is not stable, and its movement distribution is pretty difficult to deal with...
Doug, we are sampling the accelerometers 200 times for each "frame", integrating (or adding up) all the values, and then averaging the summation (dividing by 200). This is all timed to complete, just before the averaged accelerometer value is used in the dead reckoning calculations. Each frame (A frame is a set of calculations in the IMU, control calculations, all resulting in a single PWM pulse to each servo) happens 40 times / second. So in fact we are taking approx 8000 accelerometer samples / second. Are you sampling at similar frequencies ?
Or is our sampling rate much higher, and therefore giving us a better ability to pursue high bandwidth dead reckoning.
Because of noise, and the fast way that errors in acclerations are compounded when integrated into distance, the MatrixPilot system can only provide a valuable dead reckoning (DR) position for short time intervals in the region of a few seconds. We still have quite a high relative input to the IMU position from the GPS. DR is however, very useful for fast control between GPS fixes (1HZ on the EM406A), or other slower samples from devices like the ultrasonic sonar (10Hz), or for the audible variometer.
@Tim - We already have auto-land functionality that works pretty well for belly landing based on just flying a constant airspeed to the ground. I get frequent requests to implement some more advanced "flare" technique for rolling landings. Certainly I'll take your point about the relevance, but my opinion is that if we are going to implement a feature it should be robust to conditions, or at least if it has difficulty it should not put the plane at risk. EG - lets not build a feature that will cause crashes if users are not careful. If the noise/failure mode of the sonar is to overestimate altitude occasionally, then during the final phase of a landing approach that is risky as it will likely cause pitch down. And, while it may work well enough over pavement, you have to also allow for people flying off different runway surfaces such as grass and petro-mat. Also, the flare functionality would reduce touchdown energy for belly landers as well, so is not necessarily irrelevant in other cases.
@Robert and Pete,
Ryan and I have done a fair amount of experimentation with inertial dead reckoning, and for APM1/2, we just cannot get it to work. Perhaps UAVDevBoard has better accels, but although we can do some pretty reasonable velocity estimation we have never been able to get inertial based position estimation to work. It is easy to do on paper, but as soon as you start to see the actual error characteristics of the accels (which look nothing like Gaussian noise) and how bad they affect the double integration, it becomes very difficult. Every attempt I have made needed drift correction that was so "strong" that basically the output followed the drift correction and the accels had little contribution to the solution. For MSL altitude I think our new baro sensor is a better alternative than trying inertial estimation with our accels - based on my comment on drift correction you an imagine that the inertial estimation would be mostly the baro anyway.
Finally, for a robust landing solution you also need to consider that (1) you might like the touchdown point altitude to vary from the takeoff or home altitude without a lot of user compensation for that fact and (2) All of the MSL sensors we have at present are prone to drift. So, an AGL (height above ground) sensor is desirable and from price, range, and usability perspectives the sonar is pretty attractive compared to other options. That will change, I'm sure, but that is where I see things right now.
The UDB / MatrixPilot does the double integration to create what we call High Bandwidth Dead Reckoning (HBDR) using DCM++ (Bill Premerlani's original DCM algorithm much improved by Bill). The print out of location is called IMULocation and the print out of Velocity is called IMUVelocity (see same link).
BTW: The Z velocity, because it is produced every 1/40th of a second, seems to be a good starting point for driving a variometer algorithm. One of our team have produced software using MAVLink as the communication platform to drive a PC that creates the classic audible variometer sounds driven from IMUVelocity / IMUlocation. At the moment it does not use total energy calculations, although that is now a simple change to make, if needed.
If the Ultrasoic sonar could inform the absolute position (IMULocation) more accurately (and by the way probably switch from absolute position flight control (height), to relative position flight control (Height above immediate surface e/g 0.5.m) , then IMUVelocity can also calculate change of trend every 1/40th of a second, and we will be starting to get closer to having the foundations of an accurate landing control system.
It has not been my personal priority to code the total landing solution. But I am following this discussion with great intrest, and want to thank Doug, once again, for sharing his learning journey of the issues as they are discovered. Best wishes, Pete
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...
-
1
-
2
-
3
-
4
-
5
of 6 Next