Developer

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...

3689443157?profile=original

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.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Thank you Mr. Anderson.. 

  • 3D Robotics

    FDC: Yes, ArduPilot supports the MaxSonar range: http://code.google.com/p/arducopter/wiki/AC2_Sonar

  • Heey guys I am new on this field and I am working on an Autonomous Heli. I want to mount a MaxSonar EZ1 with the Ardupilot. Do you think this is possible? I really do not want to work with a regular Arduino since I am running out of space and weight capability on my 180-EFL Heli. Any Ideas. Any converter that I can use for these TTL and PWM signals.. 

  • 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.

  • Developer

    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.

  • I'm not saying you can't do landing and takeoff and control, at 10hz, and the "something reasonable" I agree you can do: it was my last scenario: just start pitching up at 1m AGL and pray, with some escapes for unexpected events.

    I just believe that you can't _control_ a *flare* in any meaningful manner, when the numbers are coming at 10hz. In fact they are not coming at 10hz. The key numbers: height AGL and sink rate, are coming, lagged, at much less. You can't tell me that the barometer or the sonar is giving accurate small sink rates at 10hz. Is your 5 sample averaging stuff at 50hz or 10hz? is it to smooth voltage noise, or to average readings (that are done by the XL at a mere 10hz)? even if the sonar gave 10 perfect readings a second, therefore fewer accurate rates of change, I doubt that could pilot a 2 second flare safely.

    A proper flare is a fully controlled pitch up that diminishes sink rate to zero in sync with altitude. You do need a high rate controller and a high rate range finder, otherwise you are not controlling the flare, you're just pulling the stick back slowly. Not saying that won't do. Just calling it a "flare" is misleading. Its more of a slow crash into terrain.

    Mind you, is 50hz "high rate"? hardly! 500hz is high rate.

  • 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.

  • Developer

    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.

  • A textbook flare is very difficult especially combined with a defined touch down point. You need to change from nose down trimmed condition in a glideslope at a pre-calculated height over ground that coincides with the right distance prior to the glideslope localizer, transition into an exponential flare that reduces sink rate to zero but absolutely does not change to an ascent, and if all the cards fall right, the touchdown point is about right and matched with almost no sink rate.

    The problem with this is the altitude measurement both barometer and Sonar is too slow and discrete. The barometer resolution is low so it is basically useless for fine control of the sink rate, at small sink rates it outputs the same value for 10 samples then a new value for 10 samples, thus heavy smoothing is needed to get an exact idea of sink rate, by which time it is outdated.

    The Sonar clicks at just 10hz, the analog voltage must also be sampled to avoid noise, and further smoothed and sampled to generate an decent idea of distance to the ground, then changes from one of these synthesized values to the next taken to generate a sink rate. It is therefore not really any better than the barometer -- but at least can determine whether the plane should abort landing as it does not feel any ground beneath it, or abort if it feels ground unexpectedly appearing where there should be none.

    During a flare tuning pitch attitude with sink rate and distance to ground is vital. You want the sink rate to reach ~zero as the altitude of the wheels gets to ~zero. in the 2 second interval a flare might last there is only going to be about 5 correct ground distance and sink rate numbers, and they will be un-matched (with each other) and stale, too.

    Even if you use the vertical accelerometer to generate a dead reckoned sink rate (and the chip is at the CG not in the nose) you still don't have the accurate altitudes above ground from which to dead reckon. if the dead reckoning is based on lagged altitudes everything gets unstable.

    A full sized flare control system uses a proper range finder, is going to be touching down on a flat runway, has a slower pitch rate to manage and a 5 second flare. A lot easier for a 747 than a Cessna, where even a good pilot gets it wrong and bounces or balloons. on UAV scale everything happens more quickly still.

    50hz with a 10hz ultrasonic click is not enough to 'control' (in any meaningful way) the flare IMO.

    All that can be done is a facsimile: when the range finder sees 1m AGL, it cuts throttle and pulls pitch slowly to a limit of, say, 5 degrees. If the approach speed was just above stall, and with luck, and no wind gusts, the plane will touch the ground and stall before the increasing pitch causes it to balloon. All one can do is ensure the landing is harder than a proper flare, to avoid the risk of a pitch up stall. This isn't so bad as there are no little people sitting in the UAV to complain about the luggage falling on their heads :)

This reply was deleted.