Commander: Remove dynamic position velocity probation period

[MaEtUgR]

Describe problem solved by this pull request
If a multicopter looses GPS position for 10 seconds it needs to have GPS position passing all accuracy checks for over 100 seconds such that the estimate gets accepted as usable again by Commander even though the EKF is already fusing it for a long time. This results in perfectly accurate and used position information with the user not being able to switch to any position controlled mode or position controlled failsafe to be possible.

Describe your solution
I'm investigating on this test branch what impact it has if we omit this to me confusing and unexpected logic and have a fixed configurable probation period for accepting valid position information.

Describe possible alternatives
I discussed with @dagar today that it would be best to capture the original intent of the author @priseborough and make sure it's still intact while hopefully solving unexpected cases. I'm happy to learn more details.

Test data / coverage
Tested this a bit in SITL droping GPS information randomly and flying the drone into the ground to have inconsistent estimation that is falged invalid for navigation.

[MaEtUgR]

I brought this up in call with @priseborough a while ago and he explained that we need to avoid having position validity going off and on too quickly because we're at the border of certain thresholds or realize after takeoff that navigation is not possible but he's open to other solutions than the current one in Commander like e.g. a hysteresis. One way of reproducing a problem is to fly without magnetometer in SITL.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[MaEtUgR]

I'm resurrecting this pr since the issue now as before persists. We just had another instance of the dynamic probation period prohibiting a perfectly accurate position estimate because of a brief GPS drop out until the vehicle reached the ground luckily this time without crashing. I see a pattern where on every single multirotor product I worked on that gets enough testing hours this issue happens at some point. The solution was always me disabling the probation period by adding

param set-default COM_POS_FS_GAIN 0
param set-default COM_POS_FS_PROB 1

to the airframe and then the issue never occurs anymore. That's also why I originally opened this pr and since we have enough cases that speak for this change and enough testing without the probation period I'm bringing it up again.

I talked to @priseborough this morning and he agreed that with the yaw estimator such intermittent navigation failures so far did not happen anymore so he agrees to remove the probation period because it's at the moment more likely to harm than to help. In case any yaw-related navigation failures occur we can solve them in another way.

[bresch]

Suggested change

	const hrt_abstime &data_timestamp_us, hrt_abstime *last_fail_time_us,
	const hrt_abstime &data_timestamp_us, hrt_abstime &last_fail_time_us,

Since you're changing that line already, could you switch last_fail_time_us to a reference instead of pointer?

[MaEtUgR]

Good point, I'll follow up. 👍