Developer

GPS Glitch detection in AC3.1

3689562960?profile=originalAC3.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.

3689563012?profile=originalAll 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.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • 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.

  • Developer

    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.

  • Are there any plans for something similar for height measurements using the baro etc ?

  • Developer

    This will be very useful to the guys doing the NASA UAV Challenge.

  • Great work!  Looking forward to flight testing to see this code in action.

  • 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.

  • Are,

    You really do know what you are talking about. I hope the software eventualy goes in that direction.

  • Developer

    @Swift,

         We specifically designed this protection so that it could be integrated with Plane (and Rover) so it's very possible.

  • Developer

    @Michael,

         Someone actually volunteered to do something similar for the baro which can also be glitchy.  I'm pretty sure that'll get done before AC3.2 goes out.

         Safety certainly is top priority.  The other big safety issues we will be looking at will be:

            a) adding checks that the Inertial nav vs baro don't diverge too much.  this should help the copter catch cases where it's vibrating too much so it can take corrective action instead of the pilot having to retake control.

            b) barometer glitch detection

            c) detect bad compass headings.  <-- this is actually the next biggest problem

This reply was deleted.