ekf2: GNSS checks relax pos/vel req once passing

[dagar]

Starting with something crude and simple to get the conversation going this PR proposes that we relax the ekf2 GNSS checks for position and velocity accuracy once GNSS is active (passed initial checks) .

@dakejahl @bresch @haumarco

Related to #24355, but not a full solution.

[dagar]

Alternatives

• splitting GNSS position and velocity with more granular checks
• respecting the checks (or a subset) conditionally on other aiding sources being active (isOtherSourceOfHorizontalAidingThan(_control_status.flags.gps))

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-feb-26-2025/43951/1

[AlexKlimaj]

Here's a log from today on the Teseo GPS. The speed accuracy goes above 0.5m/s for brief periods. In this case, everything is functioning normally and this shouldn't be a check failure.

https://review.px4.io/plot_app?log=8863bef0-17e4-4315-b386-e1818d7d24f8#Nav-GPS-Uncertainty

[bresch]

The speed accuracy goes above 0.5m/s for brief periods

Yes, but you can say this because you see what happened after those spikes. The autopilot only sees what's happening "now and in the past" and needs to take a decision immediately. The problem is that "you can't unscramble the eggs"; it's usually safer to stop immediately and restart if it gets better than continuing to use data if it gets bad.

The nav can do inertial dead-reckoning for a couple of seconds, maybe we could just be faster at restarting the GNSS fusion (without state reset) after a speed accuracy (an other metrics) spike? This way the user wouldn't notice it but we're still sure to stop early enough in case the data is truly bad.

[haumarco]

Agree with @bresch.
Having a hysteresis is IMO the correct approach to handle spikes, but adjusting the time-delay could be an option.
I like the alternative solution of separating the gnss position and velocity fusion and have independent checks for both...

[dakejahl]

The nav can do inertial dead-reckoning for a couple of seconds

I was going to ask about this on the call. Would it be possible to add a grace period when local position is deemed invalid to dead reckon for a few seconds before kicking out of position mode? Could make the delay configurable, or disabled.

[AlexKlimaj]

One thing I've noticed on ublox vs septentrio vs teseo is that ublox lies until things get really bad. Septentrio and teseo seem to report more accurate up to date metrics.

You can test this on units that use an external antenna. Disconnect the antenna on a ublox based GPS, and it will continue to report like nothing is wrong for many seconds. Teseo and Septentrio will drop out immediately.

[dagar]

maybe we could just be faster at restarting the GNSS fusion (without state reset) after a speed accuracy (an other metrics) spike

I like that idea, I'll take a look.