GPS Inconsistent behavior

[stronnag]

Spoiler : Somedays, adequate humber of satellites and reasonable HDOP doesn't meant nav functions will work as expected.

Today I flew 85fe245 and f440ead on my usually utterly reliable quad. This machine has not failed to execute PH, RTH or missions since we fixed SBAS months ago ---- until today.

Result. Completely random PH behaviour (if PH fails, then I don't even try any other nav function). Randomly, on hard reset, nav functions will either work or fail. Some log files at
http://seyrsnys.myzen.co.uk/inav_ph_woes/. All the log files were created in a short time frame with good satellite coverage (16-19) and good HDOP (1.1 - 1.3).

• LOG00279.TXT: 85fe245. PH fails miserably, repeated.
• LOG00280.TXT: f440ead (having persistent mag/acc makes checkout / build / flash / apply config in the field so easy:). Works OK.

... does some betaflight stuff on the minis for 30 minutes

• LOG00281.TXT: f440ead: nav functions fail miserably, repeatedly (multiple arm / disarms)
• LOG00282.TXT: f440ead: powercycle nav functions work again !!!!
• LOG00283.TXT: f440ead: powercycle nav functions still work. Out of lipos, otherwise I'd have tried 43eaf10 (which behaved perfectly across multiple lipos earlier in the week).

Note 0. LOG00281 Index 1, PH attempt 4 is a good example of 'fly off'

Note 1. 281-283 were executed in quick succession, it is unlikely that there was some environmental change that affected the results.
Note 2. If PH is not (obviously, visually working), it is rapidly aborted.

Exec Summary : nav post 43eaf10 seems pretty random to me at the moment. Other experiences solicited.

[digitalentity]

Seems like a GPS-related problem. GPS (and estimated navVel) velocity doesn't seem to be correlated with UAV attitude and stick input:

It might also be a compass issue:
At log 281 there is a moment when UAV is flying at only forward pitch - this is usually flying straight forward and GPS heading should be roughly equal to magnetic heading, however they are opposite:

However, I doubt it's compass - UAV heading strongly correlates with yaw stick input. I'd blame GPS reception that reported invalid coordinates/velocities/course for some reason.

@stronnag was there strong wind that day, if so - what direction?

[stronnag]

@digitalentity, thanks for the analysis.

There was less than 8 m/s wind; I often fly in more. My initial thought (from the field) was that it was just a bad GPS day. I guess that happens from time to time. I did not suspect the compass, much of random flying / drifting around was manually correlating the observed heading with the LTM reported heading (which seemed consistent), whereas the mwp calculated 'range from home' often seemed incongruous.

It was an object lesson in 'try PH before engaging more advanced nav functions'.

I'll do some more missions today before closing.

[digitalentity]

@stronnag
Interestingly GPS glitch detection did fire an alarm a few times. We definitely need better glitch detection logic.

[stronnag]

A day later .... updated the firmware to abf1015 (so no significant change). Starts with similarly less than stellar sat statistics (13-15 sats, 1.3-1.5 HDOP); couple of hours later its back to normal, 19-20 sats and 1.1 HDOP.

PH and other nav functions back to their awesome performance and consistency, even at the lower than normal end of the sat coverage range. Someone in the DoD really didn't like me yesterday.

Maybe we should use some of those spare X-FRAME bits for a glitch detection alert or counter?

[digitalentity]

@stronnag thanks for your report, indeed something must be wrong with GPS reception. We can use a byte in X-Frame to indicate INAV internal status flags, however we still don't have a good logic of detecting GPS failures...

[Linjieqiang]

The solution to the problem is using EKF algorithm although it looks messy and complex.

[digitalentity]

EKF is nothing close to a glitch detection and protection, it's merely an algorithm to blend data from available sensors.

[Linjieqiang]

If large difference between receiving from gps and predicting form EKF,program will move the data from gps.Maybe I'm wrong.

[digitalentity]

It's not the EKF itself, it's a supporting code logic that does the detection.

[Linjieqiang]

Oh.Sorry.It's my wrong.

[xdigyx]

Today I had a situation when at pos hold mode my hexacopter rapidly started to fly away. Not sure whether it was caused by loosing some sats or... Anyway maybe it would be a good idea either to take an average of 2-3 readings or ignore for pos hold mode position change grater than... (say 10cm/sample depending on model speed from the previous cycle/ significant sat.num loss)?

[stronnag]

GPS glitches are very rare, my report was a once a year occurrence, for a frequent flyer. Your problem is more likely symptomatic of mag interference. Have you verified that the mag works perfectly at all throttle settings?