Developer

### GPS Glitch detection in AC3.1

AC3.1 is going out very soon and includes a new safety feature called GPS glitch detection.  There's a wiki page about it but I'd like to highlight how it works because it's near the top of the list of safety issues.  The method itself comes from Craig who apparently used something similar on undersea robots.  The way it works is:

Step 0: the very first GPS position received is simply "accepted"

Step 1: when we receive a new message from the GPS we first calculate a "projected position" based on the previously accepted position and velocity assuming that the copter had just flown straight ahead.

Step 2: we compare the new position to this projected position and if it's within 2m (configurable with the GPSGLITCH_RADIUS parameter) then we 'accept' the new position and we move back to Step #1 and wait for the next update.

Step 3: if it's outside 2m then we calculate another circle of acceptability which is an estimate of how far the vehicle could have travelled since that last accepted position.  We assume the vehicle can accelerate at 10m/s/s in any direction (value held in the GPSGLITCH_ACCEL param).  So for example if it's been 1sec since the last accepted position, the radius would be 1/2 * 10m/s/s * 1s * 1s = 5m.  This radius starts out small but grows quickly so after 5sec it's 125m, after 10seconds it's 500m.  If the new position still isn't within this radius then we're officially "glitching".  We throw away the GPS position (so we rely only on the inertial nav estimate), we display "Bad GPS Position" on the Mission Planner's HUD and then go back to Step #1 and hope the next sample is better.

Now after 5 seconds of not having an acceptable GPS position the GPS Failsafe kicks in and the copter Lands or switches to Alt Hold (user configurable using the FS_GPS_ENABLE parameter).

If on the other hand the GPS position corrects itself (i.e. comes back within the radius) we instantly reset the inertial nav position to this new GPS position.  This reset is important because it saves the inertial nav filter from getting confused about it's velocity and acceleration due to the jump which would lead to the copter flying wonkily even after the glitch has cleared.

This doesn't mean that GPS glitches are a thing of the past, we still need to get these two parameters (GPSGLITCH_RADIUS and ACCEL) set so they catch most glitches without causing too many false positives but hopefully it's save some copters and this may grow into better algorithsm.

By the way, before implementating this glitch detection we tried to use the GPSs HDOP values (the GPS's measure of how accurate it's position is) but we found the number trails the actual glitch by up to 2 seconds so by the time the GPS tells you, things have already gone horribly wrong.

All feedback welcome, you can see the code here and a simulated video here which simulates an actual event reported by Garrick Merrill (gps location changed to protect the innocent).  Here's a video showing how quickly the inertial nav position drifts without the GPS.

• Just to report yesterday and today tests.

Without changing anything on both copter yesterday I was able to have 7-9 sats with hdop about 2. No GPS glitches detected in logs (of course with gps glitch detection enabled) and flights without problems in various modes (LOITER, CIRCLE, GUIDED, FOLLOW ME, AUTO, etc.). Today near Milan I've got 9-10 sats with hdop 1.5 - 1.9 and flights perfect.

Loaded on both copters 3.2 rc2 and flown AUTO missions and played FOLLOW ME sessions for the whole afternoon without any trouble.

...I don't know what to say about it...

• Randy, as APMcopter is configuring GPS at power on it seems that the GPS configuration you set with config file is overwritten (but not saved in eeprom). Btw I've tried wth GPS configured as wiki pages and GPS reset to defaul values....with no difference in results and logs. Next days I'll do more tests and I will report but in Italy in these months we have some problems in getting more than 7-8 sats with hdop <2 while in october/dicember 2013 situation was far better.....but I can't understand why Nazas are working great even now!
• Developer

@John, Luciano,

In case it's helpful there's a wiki page here on how to look at the GPS's configuration using u-center.

When lookiing at GPS issues, I'd recommend looking at the update rate.  In the dataflash log's GPS message you should see a long number in the "Time" or "TimeMS" field.  With a 5hz update rate each numbers should be about 200 higher than the previous.  We sometimes see problems when messages are skipped so one message will be 400 higher than the previous.  This happening a couple of times is ok, but if it happens regularly then it's a sign that the GPS messages aren't getting through.

• @John

Thanks John! I've turned OFF glitch control and log is clean now....but I suspect that turning off glitch control we've turned off error detection too.

BTW in this first flight I have not experienced any fly away even if hdop was very high... let's do some other tests!!

• @Luciano I have two copters that had the same issues Neo and Ublox so I turned the glitch detection off and walla no problems.  I have a 2.5 made into the 2.6 ie external compass and such.  Im willing to bet if you load up the latest and turn the glitch off you wont have an issue.

• Thanks Randy for your comment.

I understand your position, but I've done a lot of tests (using different APM, GPS and frames) before posting this strange behaviour that it is hard to understand...that's why I was asking if anybody has the same problems with 3.1 and GPS NEO-6M

In these tests I've used same APM, same GPS, same frame, same telemetry (no FPV), same place... only some minutes time from one test and the other. I've tested it with 3.2, then with 3.1 and eventually with 3.0. With 3.0 I've done several flight without problems, but when I switch to 3.1 the result is awful. I changed APM card, GPS, cables, frames, ecc. but the problems remain on the frame (tricopter/quadcopter) where I loaded 3.2 and 3.1.

Of course if no one is reporting similar problems with GPS NEO-6M and 3.1 then I need to better understand my situation... :)

Thanks again!

Luciano

• Developer

@Luciano,

No, there were no changes between 3.0 and 3.1 that would negatively affect GPS performance.  It's much more likely to be environmental factors and/or changes in the vehicle's set-up that perhaps place the GPS close to other sources of interference.  FPV and telemetry systems are the normal culprits.

Actually with every release we hear reports that the GPS doesn't seem to be working as well as in the previous release.  Here is one such discussion between the AC2.8.1 and AC2.9 release.  If they were all real problems caused by the firmware then by now, the GPS wouldn't work at all.

• Having a lot of GPS problems with APM 2.5 with NEO-6M UBLOX GPS using fw 3.1. GPS errors in logs and GPS BAD HEALTH during flight

Fw 3.0 seems OK

This is 3.0 log

while this is 3.1 log

in the same place, same time, same GPS.

When gps shows errors copter, if it is flying loiter, rtl or auto, goes crazy and flies away...you need to regain control in stab. With 3.0 no problem during manual or auto flight

Has something to do with new gps glitch protection introduced in 3.1 fw?

• Developer

@John,

Despite the timing, it's pretty unlikely that the software upgrade has affected the GPS performance.  Much more likely to be something environmental.

Based on the feedback from this thread, we've changed the GPS failsafe (which is triggered by a glitch) so that if the FS_GPS_ENABLE parameter is set to 3 the vehicle will switch to Alt Hold.

• I have found that with the newest update my hex has lots of false positives. Nothing changed on it except the software upgrade. Before that auto mission was flawless.  So I going to fly a mission with it turned off and see then if thats 100% I will start trying different settings with the glitch back on. I think alt hold is probably the best way to go for what it does if it looses gps but thats just me. I don't fly auto often and when I do its just to make sure everything is working right and I can still see the machine to take over.

This reply was deleted.