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.
Comments
@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.
@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.
@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.
@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.
I'd just like to suggest that perhaps the initial GPS fixing is treated a little better. It's possible you've already done some of this since this thread was created, but I have had slight initialization problems on my IRIS that I think are somewhat related.
One thing that happens is that we (RTF pilots) tend to start flying as soon as we see a 3D fix. We learn (although perhaps not soon enough) that you really need to wait a good 3 minutes or so until the GPS locks in. And it seems that this is even beyond a HDOP < 2 reading.
So, we shouldn't show 3D fix even though the GPS system says it has one, but only after the glitch system has gotten itself properly oriented. Unfortunately this usually needs physical movement. I have found for instance, that if I ARM, then manually move my IRIS away 5 meters or so and then back to home, it comes around much more quickly, and then perhaps a disarm/rearm in between.
Obviously we can't expect users to do this....
The ideal would be not to enable GPS modes until the unit has flown 10 or so meters. I think many of us already do this, take her up manually fly around in stable mode a bit see how she handles, maybe put her in loiter a second or two, then select auto.
I know there are cases where we want or need to start in auto. (I'm one of those in the industrial realm). Perhaps then we can use the GPS for establishing home after a certain time delay. Start off in inertial mode and build a certain confidence. Create a confidence variable with the INS as prime reference at first, as the confidence reaches a certain value then work the GPS into the formula.
I think the inertial nav system is that good.
In any case, whether it be inertial or GPS, there should be glitch protection.
Just some ideas.
mP1,
Yes, there was someone who volunteered to develop the same type of protection for the barometer. I haven't seen anything from him recently though. I'm sure it'll get done for a future release though.
This will be very useful to the guys doing the NASA UAV Challenge.
nice work..... every small improvment helps but this is much bigger than "small"....
Awesome Randi and all other developers who contributed ! This will act as a great counter measure against GPS spoofing as well.
-
1
-
2
of 2 Next