WP Mission RTH Change

[breadoven]

Implements #6502.

Tested on a fixed wing but but only up to loiter around home not up to point of landing. Landing should trigger if option selected but still needs test to confirm.

If there is a particular reason to maintain a separate RTH method for WP missions rather than using the normal RTH method then this PR can be cancelled or perhaps it could be made an option.

[breadoven]

I noticed in https://github.com/iNavFlight/inav/wiki/MSP-Navigation-Messages#waypoint-and-action-attributes it states:

"4. If a mission contains multiple RTH stanzas, then for MultiWii, the mission terminates at the first RTH. For inav, the mission will continue if RTH-LAND is not set, and valid waypoints follow."

This would explain why WP RTH doesn't use the standard RTH method. However, #6050 would appear to break the ability to continue the mission after RTH by removing the call to move to the next WP in function navOnEnteringState_NAV_STATE_WAYPOINT_REACHED. It seems now that when reaching home during a WP mission RTH you can only land or hover above home until the WP mission is cancelled,. Is this deliberate or an oversight ?

[stronnag]

I've been meaning to add some historical perspective to this for a while now ....

That INAV could have multiple RTH events in a mission has been a feature since pretty much day one. I have some tests that it worked in 2016 / 2017. However , none of the mission planners have ever supported it well (or at all in some cases).

I suspect that the change in #6050 preventing this behaviour was an oversight, due to fact that a mission could continue through RTH not being well known or expected -- must admit I was surprised to discover its existence from a conversation with @digitalentity many, many years ago and hence the wiki comment.

I rather like the idea of just having one RTH implementation, even if it means losing the "multiple non-land RTH" function

[breadoven]

Thanks for reviewing this. I always assumed WP RTH just used the normal RTH method until I changed to climb first for RTH to discover it didn't affect WP RTH , then looked at the code and realised why.

I guess if you wanted to fly over home multiple times during a mission you could just set normal WPs there ... assuming you knew where home was likely to be of course.

I deleted the code mentioned in #6682. See if anyone complains.

[breadoven]

Managed to finally fully test this including landing with a multirotor and it works as expected so ready for review.

[Jetrell]

@breadoven it works well. I like the system message and mode WRTH, to explain that phase of the mission 👍
Quad also lands and disarms at the end of the mission. Obviously provided P1 is > 0.

[breadoven]

Thanks for testing. The only test outstanding is to check if landing is triggered independently for the setting in the mission and the setting specific to RTH. So RTH might be no land and the mission set to land. It should land at the end of the mission but not if you do a RTH by itself. I'll test it myself anyway. Need to see if the quad does a RTH without flying off in the wrong direction as it did last time. Almost certainly caused by the magnetometer flipping 90 degrees out of calibration, but still don't understand why. Seems OK after another calibration but a bit wary now ... when they go wrong in Nav modes it all happens very quickly.

[breadoven]

Tested independent selection of landing between mission RTH and normal RTH and works as expected.