EKF: improve handling of primary GPS switch

[rmackay9]

The EKF2 (and probably EKF3) do not try to handle a change in the primary GPS which is almost guaranteed to cause a change in position. From what I can see, the EKFs simply handle the sudden change in position as a glitch. I think they should instead trigger a position reset and report this to position controllers.

Here are some other related issues:

• Report of violent vehicle movements after GPS glitches here (see item 4): https://github.com/ArduPilot/ardupilot/issues/11156
• Report of violent vehicle movements while in ZigZag mode: https://github.com/ArduPilot/ardupilot/issues/13472
• Improve reporting of GPS glitches: https://github.com/ArduPilot/ardupilot/issues/6650

FYI @priseborough

[auturgy]

Isn’t this what GPS_AUTO_SWITCH handles? I’d check whether the users reporting issues had it set to 2, which should smooth out transitions, or 1, which will use the best gps, resulting in jumps like described.

Regards,

James

On 6 Feb 2020, at 3:43 pm, Randy Mackay notifications@github.com wrote:

 The EKF2 (and probably EKF3) do not try to handle a change in the primary GPS which is almost guaranteed to cause a change in position. From what I can see, the EKFs simply handle the sudden change in position as a glitch. I think they should instead trigger a position reset and report this to position controllers.

Here are some other related issues:

Report of violent vehicle movements after GPS glitches here (see item 4): #11156 Report of violent vehicle movements while in ZigZag mode: #13472 Improve reporting of GPS glitches: #6650 FYI @priseborough

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[rmackay9]

@auturgy,

I've suggested to the user that they try out blending (GPS_AUTO_SWITCH = 2) but even when using "Best" (1) the EKF should be able to warn the position controllers that a position reset has happened. The EKF has access to extra information (the source GPS has changed) which will definitely lead to a position jump, I think it can do a better job of providing a warning to the downstream position controllers like it does for GPS glitches.

[WickedShell]

GPS_AUTO_SWITCH 2 can be a bad fit if the user doesn't have identical modules, so it's not a catch all. For a lot of people there is a desire for a backup unit which ideally actually would be from a different vendor and different to their other GPS which would be better, which is an entirely different type of swapping we don't really do right now. But this kind of swapping definitely benefits from the EKF doing a reset if we do that, so I'd support the EKF doing better.

Also if one of your units drops out and we can't do blending then you'd still fall back to the GPS_AUTO_SWITCH 1 strategy which would still need EKF support.

[rmackay9]

@lthall, Tridge tells me that you've found an issue in the position controller where it wasn't consuming the reset provided by the EKF?

[mgodmere]

@rmackay9 . Wondering if I could revive this old issue and get some advice.

I am in the process of developing an outdoor GPS-denied navigation solution with Copter-4.3.0. The goal was to have a standard primary GPS (UBLOX) and a "fake" GPS (MAV) using GPS_INPUT mavlink messages from an external visual odometry SLAM system (not optical flow). In the event of losing GPS signal, the autopilot would switch lanes to the backup GPS messages and the vehicle would be able to stay in guided mode and output a reliable GPS position using odometry and the last "real" GPS fix.

In my testing, the anomaly detailed above also happens for me whenever the EKF Pos Source is changed. I verified all parameters and even though the VO GPS messages are extremely close to the primary GPS, EKF3 sees the small positional change as a glitch, enters failsafe, and lands. When FS_EKF_THRESH is set to 0.0 to ignore variance, the vehicle still loses position and reports IMUs as stopped aiding. I imagine since the vehicle is hundreds of meters in the air, a small VO discrepancy can cause a large positional change in a small timescale compared to an indoor environment with a drone or rover.

Is this setup possible without glitching and I am just doing something wrong, or is this not supported? It would be nice if there is a way to have the autopilot simply transition to the other positional source gracefully even if the position is off by hundreds of meters. This would also be useful for having different backup GPS modules while also handle GPS jamming/spoofing.

Thanks