Howdy devs,

I've been working on this for a few months now and I think it is finally ready for evaluation for a possible merge into master. My team has been wanting to simplify planning for autonomous landings so that mission planning for autonomous landing is less complex. Our motivation is that if we need to change a planned landing approach in flight all we have to do is change one waypoint.  In this proposal, we just change a Rally Point.  I have made 3 patches to ardupilot, mavlink, and MAVProxy:

What these "ral_landing" branches do is introduce a new DO command (MAV_CMD_DO_RALLY_LAND) to mavlink, and then support that command in MAVProxy by allowing a user to type "rally land" at the prompt (the mission must have been setup properly for this to work ... keep reading).  The ardupilot patch introduces an AP_Land library that is designed to allow a landing to be performed from a Rally Point.  The L1 controller is used to get the plane to find the line between a rally point and the nearest landing point in the mission, providing sufficient path planning to reliably arrive at the landing point at the desired heading.  To ensure the plane does not do a 180 degree turn should it fly past the waypoint (unlikely considering the LAND_FLARE_SEC parameter ... but possible if somebody disables flaring), the L1 controller uses a Location extrapolated out 1km beyond the landing waypoint (similar to what is done continuously in CRUISE mode).

What happens during a Rally Landing is that the plane transits to the Rally Point at its loiter altitude. When it begins loitering it will then begin slowing and descending.  Three conditions must be met before the plane will break out of the loiter and head for the landing point.

  1. The plane is within 5 meters of a desired "break" altitude (for "breaking out" of loiter).
  2. The plane is within 2 m/s of the desired landing speed.
  3. The plane's heading is within 3 degrees of the heading required to transit towards the landing waypoint.

Note that if the plane should reach the break altitude and either of the other two conditions are not yet met then it will continue to loiter until they are (plane will not continue descending).  Also, if the plane reaches the target landing speed it will not continue slowing.

I have tested this extensively in SITL and a bit in the field and it appears to function as desired.  To setup a SITL or field test you need to be aware of the following parameters:

  1. TECS_LAND_ARSPD -- the speed that the plane will seek during landing approach.  I use 15 in SITL and for my airframe at the field.
  2. TECS_LAND_SPDWGT -- this can be tweaked to favor height or speed error as you desired for your airframe (gliders might not care so much about height and may want to favor speed).  For my setup 1.0 (use height and speed error equally) works fine.
  3. TECS_LAND_THR -- throttle to seek during landing approach if the plane doesn't have an airspeed sensor.  For now, if doing a Rally Landing then use an airspeed sensor. I haven't tested without one. :)
  4. LAND_FLARE_ALT -- Altitude at which the plane will flare; meaning: hold heading and pitch (see LAND_PITCH_CD) and kill throttle.  I've used 10 in my tests.
  5. LAND_FLARE_SEC -- When the plane is this number of seconds before reaching the landing waypoint the plane will flare.  Note that this is an either/or situation with LAND_FLARE_ALT.  If the plane reaches LAND_FLARE_ALT before reaching the point defined by this parameter it will flare.  Conversely, if the plane reaches this point before reaching LAND_FLARE_ALT it will flare.  Either way, it only flares once.  I'm using 2 for this value.
  6. LAND_PITCH_CD -- Pitch angle the plane will hold in centidegrees after flaring.  I'm using -500 for my plane.
  7. LEVEL_ROLL_LIMIT -- During the flare phase of landing, the plane is constrained to roll only a bit (to keep from scraping wings on the ground).  I'm using 5.

If need be, see the Parameters Page for more detail on those parameters. There is also a new parameter introduced by the patch:

  • LAND_WING_LEVEL -- If set to 0: During final phase (flare phase) of landing allow ailerons to control heading.  If set to 1: Only the rudder controls heading.  I added this parameter after field testing; my plane (flying wing) has no rudder and even after flare I want those elevons to continue to navigate (on one test the plane was landing beautifully and after flare it started drifting away from the runway -- haven't had that problem since introducing this parameter).  The default value is 1, but I set it to 0.

When setting up a mission to utilize a Rally Landing with MAVProxy, setup the above parameters as desired.  Then create a mission with a landing waypoint in it.  Then add a rally point as follows:

"rally add <loiter_alt> <break_alt>"

I usually set as follows:

"rally add 100 40"

The loiter_alt sets the altitude at which the plane will transit to the Rally Point and loiter in RTL.  The break_alt sets the altitude at which the plane will break out of the loiter.

The approach that the plane will take is completely user-defined.  You're completely free to setup a rally point that is going to give the plane a difficult approach to the landing point, but I wouldn't recommend it (e.g., don't put the rally point right on top of the landing point -- give your plane a nice gentle glide slope). :) With flexibility comes responsibility.  I've added a GUI element to MAVProxy that will hopefully help you line up your plane with a runway.  If a mission with a landing waypoint has been loaded into MAVProxy ("wp load" or "wp list" commands), then a line will be drawn between each rally point and the nearest landing point after rally points are loaded ("rally list").  See this figure:

This initial patch proposal does not support flaps or any other kind of air braking.  Maybe in the future.... :)

I hope you all find this proposed change to your liking.  Please let me know if you have comments / questions / concerns.



Views: 2773

Comment by Andrew Tridgell on April 23, 2014 at 10:11pm

Very nice work Michael!

I'll do a review of the code soon. I'd like to get this in master.

Cheers, Tridge

Comment by Mark on April 24, 2014 at 12:37am

looks really good

Comment by Not Sure on April 24, 2014 at 1:49am

make it a tangential exit from the rally point and you'll at least start the glide path to touchdown with level wings.

Comment by Bojan Verce on April 24, 2014 at 2:07am

This is brilliant work, Michael. That is how some of the autopilots in the big leagues do it.

I don't know if the airspeed check is a safe option. Try without it. What could happen, is that in the event of strong thermals, the airspeed overshoot could be significantly big, and this check wouldn't be established. Would the airplane make a death spiral into the ground in that scenario?

With tangential exit, it is harder to aim if you are using parachute landing.

Comment by Michael Day on April 24, 2014 at 8:54am

Thanks for the comments all.

Tangential exit is a good idea; I'll look at putting a parameter for that in for a version 2. Just have to set the first point on the line for the L1 controller differently.  The GUI change is a bit more challenging for tangential exit, actually -- have to known which direction the plane is loitering and do a bit of geometry calculations to draw the line (gets a bit more complex if you want to auto-update the GUI if somebody changes the loiter direction mid-mission).  I was in a bit of a hurry to get version 1 done so I ended up leaving out tangential break out.  I'll look at adding that after the beta testing is done on v1.

The next section of my comment must be begun with the disclaimer: IANAAE (I am not an aeronautical engineer). I'm a programmer who sometimes flies planes around. :)

Try without the airspeed check? I don't understand that comment, but I could be missing something.  I assumed the plane slowing down for landing would be safer than landing at typical cruising speed.  If not, just set TECS_LAND_ARSPD to what you want.

As far as thermals go: note that the same problem exists for how auto landing currently works (before I made this patch).  Seems like improved sensing _might_ improve that scenario? That would be one magic sensor.  Still, it's a good point. Another thing to think about: in a stiff headwind or thermal when ground speed is low, but airspeed is high -- isn't the wind is helping with lift?  Also, risk is necessarily higher when close to the ground: if you get hit by a bad enough cross wind or tail wind you're probably dead anyway (it is very hard to reduce risk to 0).  If flying in significant winds, I'd either not fly at all or I'd land manually.

Thanks again for great comments guys,


Comment by Bojan Verce on April 24, 2014 at 11:43am

I meant, you should remove airspeed loiter break condition from the algorithm. It will work much better with low drag airplanes such as flying wings.

For example, let's imagine we get the Rally Point somewhere in the middle of a nice Wichita field on a sunny noon. What you would experience if you lower the airspeed below cruise speed is that you would be much more susceptible to a thermal/cloud updraft because the airplane won't be able to maintain descent. That's why I think, if you want to prevent that, the algorithm should hold something closer to ARSPD_FBWA_MAX and THR_MIN.

Yeah, wind helps with lift but ground speed should never be lower than stall speed of the airframe during approach. Always maintain at least Vstall * 1,3. Because if wind stops for just a little bit, there will be a sudden loss of altitude and you could crash your UAV.

Comment by Michael Day on April 24, 2014 at 11:56am


Thanks for the clarification.  Perhaps another parameter then -- LAND_BREAK_SLOWDOWN or something.  If 1, use TECS_LAND_ARSPD during loiter prior to breaking, if not, then wait until after breaking before slowing down.

If the aero experts agree, I could add that param as part of v2. :)


Comment by iskess on April 24, 2014 at 12:09pm

I think the FBW_Min speed should already account for the slowest safe maneuvering speed. It should be set so that the plane can safely fly at max bank angle and still have a stall buffer. This should be adequate for loitering. The plane should not slow down to LAND_ARSPD until after the breakout. The speed condition for breakout should be =/+2m/s of FBW_Min.

Great work. Looking forward to the drag feature in v2 to maintain glide path.

Comment by Bojan Verce on April 24, 2014 at 12:52pm

Michael, that would work, to have that as an option and see if it works. The airplane should enter into the loiter between cruise speed and ARSPD_FBW_MAX and exit at TECS_LAND_ARSPD.

How is the LAND_FLARE_SEC time referenced, with ground Speed?

Comment by Michael Day on April 24, 2014 at 1:23pm


Yep, ground speed.  See the commands_logic.pde file in ArduPlane (search for g.land_flare_sec ).



You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service