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
FDC: Yes, ArduPilot supports the MaxSonar range: http://code.google.com/p/arducopter/wiki/AC2_Sonar
Here is an Optical Flow sensor. Keep it simple.
https://store.diydrones.com/Optical_Flow_Sensor_p/br-0016-01.htm
How about a simple 360 degree, or at least 180 degrees side looking optical light sensors that would provide a value of 100% on the ground, 90% 1 feet above, 80% 2 feet above etc. Similar to the old horizon sensing CoPilot system.
You would have to have couple of slightly downward facing port holes 180 degrees on both sides (ideally 360 degrees), as the plan gets closer to the (flat) ground regardless of the grounds texture (grass, asphalt, etc) the ground component of the horizon would get larger and sensor value increases.
To account for mountains, have more sensors in a circle, or account for the mountains on one side by tuning out that side using a feedback from the gyros ensuring that the plane is level.
I know you think 50Hz is slow :)
Not to keep arguing, but what do you see as a fundamental difference between having sensors at 10Hz or having control of servos at 10Hz. I land fine with pass-through through Picollo with 10Hz control of the servos, and certainly wouldn't call the landings "controlled crashes". Certainly I would land "better" with 50Hz control, but I can land with 10Hz.
Now, the latency is another issue entirely....
"A proper flare is a fully controlled pitch up that diminishes sink rate to zero in sync with altitude." <== That is not a "proper flare". Pilots refer to that as a "greaser", which is highly desirable but rarely achieved - LOL. You'd think it is common if you only fly commercially, but airliners have a lot of mass and good landing gear. If they had spring steel gear like a lot of GA planes, you'd feel a lot more landings.
Doug - thanks for providing a little more background and your goals/requirements in your earlier post. Being a new member to this community I'm not aware of all of the contextual information that underlies current discussions. I appreciate you filling me in.
Justin - you are addicted to high loop rate controllers ;)
I would disagree that you can't do something reasonable at 10Hz. My intention would be to modulate target airspeed based on height over ground, with the airspeed/pitch loop running at 50Hz and the airspeed target/sonar loop running at 10Hz. Airspeed would be reduced as a function of height so that the plane reaches the ground just above stall speed. As far as precision, all flare precision is a matter of the pilot/control system having a reasonable expectation of the amount of float to expect based on wing loading and headwind, and planning accordingly. You can either fly it on to the ground to get the most precise touchdown, or you can plan ahead to touch down at more or less where you want at minimum airspeed. You can't really do both.
As far as it can't be done at 10Hz, I disagree. I was flying yesterday - doing takeoff and landing duty for a university UAV program- and only had manual control as a pass-through through the piccolo autopilot at 10Hz. The flight control was not "pleasant", but was certainly manageable. I had no significant trouble landing their heavy and fast (and expensive) UAV in gusting winds... HIgher rates are better, but not necessary.
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
-
1
-
2
-
3
-
4
-
5
of 5 Next