Plane: Implement DO_LAND_CFG

[magicrub]

proposal by @WickedShell and I have to make a new command DO_LAND_CFG that is to be called directly after a DO_LAND_START. Ideas of what this could configure:

• generate new approach heading via wind with various possible restrictions
• change airspeeds depending on wind conditions
• enable/disable fly-over land pt before approach (to detect baro drift via rangefinder)
• ????

[geofrancis]

This sounds good, auto landing works ok when there is very little wind but when the wind can change direction 90 degrees between take off and mission end so I find landing in FBWA more reliable.

Fly over landing site on the approch vector so it can measure the ground level with lidar and there are no obstructions like trees before it goes around to land. currently all it says is ALT VARIANCE if you have a near miss with tree tops on approach.

forward looking LIDAR for detecting things in the way.

Airspeed sensor logic could be better I found that when flying a large draggy airframe in high wind the airspeed sensor would cause it to stall especially on landing. when a gust hit the plane it read that as high airspeed throttled back and due to the high drag airframe it lost almost all its ground speed in a very short time, this lead to a stall as soon as the gust of wind subsided that could not be recovered from at such a low altitude almost like a small scale microburst I found this was not an issue when the airspeed was disabled, I currently have it set to reject airspeed data if it diverges from ground speed by too much, so it should get disabled if wind speeds get too high. Varying the throttle slew rate would probably work so it doesn't throttle down too fast in high winds, another way would be some kind of gust detection, if the airspeed was compared to the accelerometers it could tweak the slew rate based off the G load, if the plane is suddenly slowing down but the airspeed is increasing you could delay slewing the throttle down for a few seconds.

Now that differential spoilers are supported, crow airbrakes would be very useful for shorter landings. by putting the inner elevons down and the outer ones up it would shorten a landing significantly.

Precision loiter for VTOL being able to use optical flow or IR becon for landing and hovering.

retracting the camera before landing.

all my testing is done in the hills of scotland so high winds are the normal.

[WickedShell]

My initial proposal for the MAVLink side is on the wickedshell/land-cfg-proposal branch here.

What it outlines is the start to a system where multiple parameters for a landing can be outlined after a DO_LAND_START command. This is done by with mission items of MAV_CMD_DO_LAND_CFG where param1 indicates what sub type of landing configuration this is. The examples outlined so far all have to do with aligning the flight path with the wind, or avoiding certain angles. For example a MAV_LAND_CFG_INTO_WIND_DEG would tell the aircraft to rotate the landing up to so many degrees to be perfectly into the wind. If the user wanted to it could then be followed with a series of MAV_LAND_CFG_KEEPOUT_ARC items to indicate what angles the aircraft may not fly a landing through. (This could be used to avoid overflight of an area, or to ensure the aircraft is aligned with a runway).

Internally the autopilot would process the landing configuration and fly the resultant path. If no path can be arrived at due to excessive restrictions (IE all headings are marked keepout, or the aircraft can't rotate the path far enough to avoid a keepout zone) the aircraft would refuse to land and would execute an RTL. If in a failsafe condition we should simply fly the planned landing pattern as it's better then falling out of the air.

Because slope and deepstall landings interpret the outcome of a rotation command differently it would be up to each landing backend to determine what to do with the output of the configuration, but the actual landing configuration processor would be common to all backends. Internally there will have to be a limit to the number of MAV_LAND_CFG commands the autopilot can process due to memory and processing complaints, but it should be quite feasible to allow at least 5 commands to be processed.

Ideally this system should allow us to specify a number of different additional configuration parameters in the future, but the main use case I had in mind and have thought through thus far is related to wind directions and the handling of them.

For this to be less painful for the user I imagine a GCS will play a large role in hiding the internal use of the various MAV_LAND_CFG values and will present a single landing item where it generates the appropriate commands when uploading the mission much the way GCS's can hide the commands used for a survey mission. @DonLakeFlyer @meee1 do you for see any problems with this from a GCS side?

[pompecukor]

Please please please: Deploy landing gear (happy with just a simple servo set command or override servo command. Pity it is limited to 1-8 ch, but we take what we get). This as you can guess can be useful for multiple stuff, like close camera cover or close belly bay for landing protections and so on. This would be of course better if set independently with auto deploy based on altitude for example, like it is on copter. But 3.9 seems so far away. I know it is a mile stone for that.

[Naterater]

Still interested in this moving forward.

[pompecukor]

Definitely Please. This would be killer feature. especially flyover to detect drift. Would make all landing 100% precise :)

[magicrub]

I have a feeling this will be better implemented using scripts.