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:
https://github.com/mday299/ardupilot/tree/ral_landing
https://github.com/mday299/mavlink/tree/ral_landing
https://github.com/mday299/MAVProxy/tree/ral_landing
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.
- The plane is within 5 meters of a desired "break" altitude (for "breaking out" of loiter).
- The plane is within 2 m/s of the desired landing speed.
- 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:
- 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.
- 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.
- 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. :)
- 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.
- 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.
- LAND_PITCH_CD -- Pitch angle the plane will hold in centidegrees after flaring. I'm using -500 for my plane.
- 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.
Thanks,
Michael
Comments
@iskess
Sorry for the belated reply. I haven't done Go Around using what's in master (I've been limping along on my fork far too long!) so I don't have the answer to your question.
Tom, the code in github is a bit dated, so buyer beware.
I'm trying to scrape together some time to get this style landing merge into master (been pretty swamped for a few months). After some talking with Tridge, it will likely no longer include the rally point, rather it will be built from mission commands. So instead of what I currently have forked the functionality would be something like a list of waypoints:
1. NAV_CMD_DO_START_LAND
2. Proceed to a loiter point.
3. Drop speed a bit.
4. DO_ALT_CHANGE down to 40 meters (while loitering) -- I think I might need to develop a DO_ALT_CHANGE command first. :)
5. WAIT to break out of the loiter until on a heading that is facing the landing waypoint.
6. Proceed to landing point.
Sound good? Again, I'm trying to get time to do this but haven't been able to yet.
Ahh, I just realized that you posted your github fork/branches there. I'll dive in!
Hi @Michael Day, I'm very interested in working/improving on this. Do you have a pull request submitted?I know @Tridge is super busy these days with the Embedded Linux Conf coming up and all so I don't think we're getting any pull-requests approved any time soon. Is your fork public? I'd be willing to give it a try on my fork.
How do I order the GoAround on the GCS to take advantage of the new DO_CONTINUE_AND_CHANGE_ALT?
Thank you for the autoland work you are doing!
Howdy ausdroid,
I've got rally landing working on a fork for our group and I've slowly been working on pushing it into master. Over the last 4-5 months I've been focusing on other priorities and haven't had time to finish pushing up the modifications necessary to complete rally landing. I anticipate I should be able to do that next month...
Hi Michael. Where is this up to? We have been testing autoland a lot and have it working well. The next thing we need is a landing rally. I was doing a check to make sure it wasn't already somewhere out there when I cam across your post. Have you done any more work on it?
hence my comment on making it tangential exit, the early procerus stuff wasn't tangential and whilst it landed quite well, the difference in the performance of how UAV with tangential exit landed was much better.
Since the landing approach must be made as slowly as possible, but yet with a safe margin of speed, the stall speed plays a big role in determining landing performance. The FAA mandates large airplanes must use an approach speed of not less than 30 percent above stall speed or 1.3 Vs. For lighter airplanes there is really no restriction on approach speed other than that it enables the pilot to make a safe landing. In any case, an approach speed of 1.3 Vs is a reasonable minimum approach speed.
Much of our autopilot decision making could be derived from a few automated performance measurements, like stall speed, in preference to the several speed parameter settings some of us are guessing at. Knowing straight and level stall speed allows the accelerated stall speeds and banked turn stall speeds to be calculated by the autopilot illustrated below.
Test Procedure
The actual flight testing of stall speed is relatively simple. Since the test depends on weight, it is necessary to determine the gross weight rather accurately. The airplane should then be flown to a safe altitude and area in which to perform stalls. Since indicated airspeed for stall does not vary with altitude, the exact altitude at which the tests are conducted does not matter. The stall should be performed power off and entered very gradually. Abrupt entry will result in an accelerated condition and will not yield accurate results. It is best to keep the airplane in fairly level attitude (nose on or slightly above the horizon) and definitely keep the wings level. Very slowly pull back on the stick and watch the airspeed indicator. The needle should slowly and smoothly move down and stop just at the break of the stall. Record this velocity. The procedure should then be repeated at various flap settings. For a retractable gear airplane, you should also measure stall speed in both gear-up and gear-down configurations and flaps in landing configuration.
However, once the stall speed is known for one weight, it can be calculated for other weights by the following equation:
V2 =V1* sqrt(Weight2/Weight1)
This equation says that if you know the stall speed V1 for one gross weight W1, then the stall speed for another weight V2 can be determined by multiplying V1 by the square root of the new gross weight W2 divided by the original gross weight. This same situation holds true for the various flap settings.
Bank Effects on Stall
When the airplane is flying straight and level, the lift being generated by the wing is equal to the weight. The lift force is perpendicular to the plane of the wing and, in this case, this plane is parallel to the horizon. However, when the airplane is banked, the lift is still perpendicular to the plane of the wing, but now the wing is tilted with respect to the horizon. The lift force is, therefore, tilted. Weight is still the same and always tends to pull vertically downward. Thus, more lift must be generated so that the vertical component of the lift vector equals the weight. In addition, the airplane banking in a coordinated turn is experiencing a centrifugal force along the radius of the turn. Part of the lift must be utilized to overcome this centrifugal force. The Horizontal component of the lift provides this force.
For these reasons you can see that additional lift is required to maintain level flight in a banked turn. Stall speed is proportional to the square root of lift, so that greater lift results in higher stall speed. Remember that in level flight, higher gross weight results in higher stall speed for the same reason. Whatever the reason, when more lift than normal exists, stall speed will be higher. Therefore when banking is done (while maintaining altitude) the stall speed goes up. Steeper bank requires more lift. The amount of increase with bank angle is the same for all airplanes. Therefore, the stall speed for any bank angle can easily be calculated by use of the formula:
Stall speed (banked) = (Stall Speed [level])/sqrt(cos bank angle)
For example, turning at 60 degrees (cos 60 = 0.5) results in 2 Gs.
Once you know your level stall speed, you can calculate it for a turn by doing the inverse: Multiplying it by the square root of the acceleration you must endure. Hence at 60 degrees bank, your stall speed increase by your level stall speed times the square root of 2, or 1.41. Say your stall speed at level is 40 knots. Maintaining altitude at 60 degrees banking, it would then be 56 knots.
Fortunately, different altitudes do not affect stall speed if we consider only calibrated airspeed (CAS) which is approximately equal to Indicated Air Speed (IAS). The true airspeed at which an airplane stalls is different at different altitudes for the same weight and flap setting. However, the density change with altitude affects the airspeed indicator proportionally to the way it affects stall speed. If stall speed were measured at sea level, for example, and then several thousand feet above sea level, the lower density at the higher altitude would cause the airplane to stall at a higher TAS. However, the lower density would also reduce the dynamic pressure in the pitot tube and the IAS would read no higher than at sea level.
Much of this information is found in: "Understanding Performance Flight Testing Kitplanes and Production Aircraft" by Hubert C. “Skip” Smith Second Edition
The Procerus Autopilots have been running the same algorithm as you've described and it works quite well.
-
1
-
2
of 2 Next