Plane: add Autoland mode

[Hwurzburg]

Captures ground course when gnd speed reaches 5m/s as takeoff direction in NAV_TAKEOFF and Mode Takeoff (if a reliable way to obtain a takeoff direction in other modes is determined, this can be expanded in the future)

Currently valid only for fixed wing configuration, quadplane wont enter mode...

Upon entry creates a final approach waypoint at parameterized distance and alt from home in the opposite direction of autotakeoff direction, flies to it and does a land exactly like NAV_LAND using full landing code for aborts. (Emulates my UniversalAutoLand LUA script #28591)

If a DO_LAND_START sequence(s) exist, will jump to them instead

If takeoff direction has not been captured then it will just not enter the mode

If not flying it will not enter the mode

Adds it as a long failsafe action (will RTL if no takeoff direction has been captured)...qplane ignores it

Includes an autotest

edit: can now be used in QPlane if fw landing option bit set and is a build option, added landing direction offset parameter for when you want the landing to be different direction than takeoff

PS: once merged I have a PR to add a mode param to allow the direction to be set on arm if a compass is in use instead of autotakeoffs, or to allow setting takeoff direction in FBWA/MANUAL/STABILIZE takeoffs in addition to autotakeoffs

[timtuxworth]

Love this idea - some suggestions.

[robustini]

Very interesting, I would instead have a suggestion for a much more solid approach in my opinion, since yours is great for taxiing takeoffs but not for hand launches, which is often not necessarily the direction of the runway.
The automatism I propose requires a very trivial thing in Mission Planner, then Ardupilot on that can do all the reasoning for a land without doing complex missions.
This a simple emergency LAND mission that I often use with some of my fpv planes.
The operation is simple, the automatic manual launch that gives me time to switch to Loiter or force an RTL once the takeoff has happened correctly (so during the LOITER_TIME), gives me time to put on goggles and then switch to other flight modes and proceed.
I also set an alternate home a short distance away because I don't want it to loiter over our heads in an emergency.
In case of failsafe AUTO intervenes, then the plane goes back to the LOITER_TIME event that I had not let it finish and shortly thereafter executes the circuit for LAND.
During that LOITER_TIME if I have the tx out I have time to decide whether to have it continue or maybe intervene in telemetry in some other way, a system that has been tried hundreds of times before.

Instead, here is what I propose, in my opinion the most logical and hyper simple: if there was the possibility in Ardupilot to fix two points on the runway, to indicate LR of the correct axis would be more than enough to tell Ardupilot to use that line to perform any kind of LAND, so something like this.

In this very simple approach Ardupilot knows of the runway the direction, the center and the correct length, so he knows that that is the runway in all its useful aspects.
Then 2 coordinates (latitude and longitude for each of the two points) that can be entered perhaps from mission planning or with parameters would suffice.
This simple line would be enough to then do any kind of automated LAND developed for this approach, without perhaps having to resort to complex planning on Mission Planner.
This is an aviation approach already known for planes performing ILS or any other instrumental approaches to the runway, and has been using Micropilot for at least a decade.
These two points are enough to allow AUTOLAND to make no mistake.
Certainly your PR is more immediate but in my opinion less secure in many contexts, of course definitely better that than nothing but supplementing it with this would make it infallible imho.

[Hwurzburg]

@robustini many people never use MP after initial setup and arent comfortable with mission planning....I never use missions other than autotakeoff/do-land-start/landing sequence with my mission selector app to select land direction for my field based on wind direction....or my UniversalAutoLand lua when travelling to other locations

this is the C++ implementation of my UniversalAutoLand lua script which I use when traveling and just stop at a location and fly...no laptop used..

[timtuxworth]

Should this be disabling fences (autoenabled, and floor) when doing a landing?

[Hwurzburg]

It does a NAV_LAND....so whatever it does or does not

[Hwurzburg]

this looks 100% correct and matches what master would do if that final waypoint and nav_land waypoint were the content of a do_land_start sequence....verified that in master in SITL

[IamPete1]

New mode needs adding to this array for the available modes message.

ardupilot/ArduPlane/GCS_Mavlink.cpp

Line 1592 in 5a8bc16

};

Sorry, this was added after you started your PR. I can push a commit for it if you prefer.

[Hwurzburg]

@IamPete1 if you could, it would help...I tried adding it and get an error message that MODE_AUTOLAND_ENABLED is not defined around the addition

[IamPete1]

@IamPete1 if you could, it would help...I tried adding it and get an error message that MODE_AUTOLAND_ENABLED is not defined around the addition

@Hwurzburg Fix here: https://github.com/IamPete1/ardupilot/tree/autoland I also rebased.

[Hwurzburg]

@IamPete1 fix added...thanks....can you approve now?

[IamPete1]

Looks good.

[tridge]

I think this needs a base leg of 1/4 of the approach distance, like this:

the base leg will keep the aircraft in the part of the field the pilot is flying in, otherwise we end up with a path like the black line above which is what we got with the bixler

[tridge]

@Hwurzburg I've added a base leg to the PR. This is with the base leg:

[IamPete1]

I think this needs a base leg of 1/4 of the approach distance, like this: the base leg will keep the aircraft in the part of the field the pilot is flying in, otherwise we end up with a path like the black line above which is what we got with the bixler

I don't understand how the shown path related to the red(?) line which I guess was the points this added as it was when it was flown? If it was no where near the set path then how does adding the extra leg help?

[Hwurzburg]

@IamPete1 the base leg addition was to minimize the overshoot of the final approach waypoint by forcing the approach to it to be no more than 90 degs before the turn onto final....otherwise the approach to the final approach waypoint could have been from 180degs to landing direction resulting in larger overshoot and more track error to correct as it lined back up on final leg...
depending on plane config, roll max, and wp-rad you can get a large overshoot otherwise without base leg and Tridge has fences to the south of the landing approach that could breach....adding a base leg minimizes the overshoot amounts which can be further tunedd with wp_rad,max bank, etc.

@trdige SITL looks good....will test fly this weekend

[tridge]

@Hwurzburg tested on Peters plane, worked well:

[tridge]

I don't understand how the shown path related to the red(?) line which I guess was the points this added as it was when it was flown? If it was no where near the set path then how does adding the extra leg help?

there were a few reasons it didn't do what it should do without the base leg:

• the up to 180 degree turnaround as Henry mentioned
• it wasn't flying all the way to the autoland start point as it was using WP_RADIUS, and as there is no mission it can't know the turn angle for the next wp, so can't judge when to turn
• it uses a lot (sometimes nearly all) of the autoland distance getting back onto the landing track
• the geometry meant it always did the landing from the opposite side of the field that the pilot was flying in (as it guaranteed an overshoot due to the above reasons)

A normal fixed wing landing has a base leg for all size aircraft. The only time you can really avoid it is if you happen to start the landing sequence when already lined up for the landing. We could add a special case for that if we think it is important

[Hwurzburg]

During testing I found a corner case bug.....multiple mode takeoffs in a row sometimes triggers the clearing of takeoff_state structure...before I added the bearing into that structure I had accounted for this...but when we went to a substructure including the bearing, it was not included in code that prevents its clearing....fixed now....I did not squash (or Tridges commit), but I will clean the commit tree once we agree to add @tridge base leg....(which I do)

[LupusTheCanine]

I personally use LOITER_TO_ALT with tangent exit with great success for landing entry with great success. It handles various approach directions and provides reliable entry altitude regardless of initial altitude.

I did a bit more SITL testing and it has ugly entry for approaches that are 90° to the wrong side. but it can be fixed by preceding it with LOITER_TURNS set to 0.125 (45°).

Here is example waypoint list for EPWA.

3	DO_LAND_START	0	0	0	0	0	0	50	Relative	X			0	0	0	0
4	LOITER_TURNS	0.125	0	50	1	52.1719446	20.9432673	35	Relative	X			0.0	0.0	273.3	154
5	LOITER_TO_ALT	0	50	0	1	52.1719446	20.9432673	35	Relative	X			NaN	NaN	0.0	180
6	LAND	0	0	0	1	52.1697995	20.9527194	0	Relative	X			-5.1	-2.9	688.2	110