Provide alternative to use of GSF for initial yaw alignment for fixed wing and rovers

[priseborough]

This provides a work around for the problems with incorrect yaw alignment that some planes with no compass have encountered which have been reported here #23224

By default the first yaw alignment after launch will be performed using the GPS ground course. Some additional protection against accidental yaw alignment during shake to arm and due to GPs glitches has been added.

This has been tested on replay of a log from a Matek F765-Wing flight controller fitted to a Strix Nano Goblin airframe, however this setup has not previously encountered the issue reported. The following figure shows the yaw alignment to GPS ground course after launch which is the behaviour with EK3_SRC1_YAW set to 1 (compass) or 0 (none) with no compass enabled. GPS ground course will only be used for vehicle operating in a 'fly forward' mode which is planes in fixed wing flight and rovers that are unambiguously driving forward.

Alternatively if the Plane or Rover user wants to use the GSF to do the initial yaw alignment, they still have the option, but will have to set EK3_SRC1_YAW to 8 (GSF). This option has also been tested on replay.

There are some further refinements I would like to do which include:

1. Checking GPS velocity innovations after alignment and a change in ground course of at least 30 degrees to check if the yaw alignment was valid before declaring the EKF nav solution valid
2. Retuning the GSF for fly-forward vehicles so that it takes longer to align, but is less susceptible to sensor errors
3. Pulling in the changes from https://github.com/priseborough/ardupilot/commits/pr-ekf3-gps-velpos-igate-mod and modifying them to be active for a period after an in flight yaw alignment so that the EKF gets a chance to fix it's yaw during the first turn without rejecting GPS.

The likelihood that the GSF yaw estimator will develop a bad estimate later in flight for planes can also be reduced by

4. Adding a resampling step for the GSF component yaw states so that they are spread out as yaw uncertainty increases
5. Turning of GSF updates when the assumption of mainly horizontal motion inherent in the 3-state formulation is invalidated, eg turn off if aircraft pitches outside +-60 degrees or pulls significant vertical g

However these will take longer and the patches submitted in this PR should be regarded as a 'hot fix.

Replayable logs from other non-compass planes are requested.

[Hwurzburg]

so do compassless planes need to set the EK3_SRC1_YAW to 0 with this? (default is 1 I think).... right now they only need set COMPASS_ENABLE = 0 and GSF takes over after launch.....
also I tink we have seen logs where GSF converged and EK3 yaw aligned normally after takeoff, but soon after it diverged, and EKF fell back to DCM, but the attitude estimate was very different and the plane rolled inverted on the EKF to DCM switch...does this address that also?

[tridge]

thanks Paul!

[Hwurzburg]

@priseborough per your request...some replay logs using this today...two small planes...moderate wind....several takeoffs in each log (all looked good)...one was a cruiser the other a speedster with a bit of vibration...
https://www.dropbox.com/s/rszu421eycqkttj/2023-04-17%2013-49-00.bin?dl=0
https://www.dropbox.com/s/obelnbnrsx06jfd/2023-04-17%2014-02-08.bin?dl=0

[priseborough]

@Hwurzburg Unless EK3_SRC1_YAW is set to 8, planes in forward flight or rovers driving forward will no tuse the GSF to do either an in-flight or emergency yaw reset, so it should look after the issue you raise.

The GSF was originally developed as a computationally light method of allowing copter to align yaw if they had bad compass immediately after takeoff after a flyaway commenced, but has limitations when used with planes that do more aggressive manoeuvres, particularly those that involve vertical acceleration.

I have some improvements that will reduce that likelihood of the GSF getting confused with more aggressive flight to be submitted as a separate PR. One turns the GSF off and resets it if the plane goes into a climb with a pitch angle steeper than TBD [60] degrees, the other moves the 5 individual 3-state EKF yaw states away from each other as the GSF becomes less confident, eliminated the likelihood that all 5 solutions will develop the same bad heading estimate.

[rmackay9]

By the way, this PR has come up in a discussion of issues with GSF in Rover-4.4. The discussion is here. https://discuss.ardupilot.org/t/yaw-not-aligning-to-gsf-anymore-after-updating-from-4-2-3-to-4-4-0-beta1/101844

I still need to confirm there is a problem.