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
@Are,
txs for the feedback. yes, the low processing is really attractive especially for the APM2.
There's no Kalman filter in AC3.1 but there's an active discussion going on on the drones-discuss list about incorporating one for the Pixhawk. I don't think we will ever have enough processing power to do it on the APM2.
I believe the Ublox that's one level up from the 6H-LEA we use allows sending the raw observations. Tridge and MichaelO have spent a good deal of time trying to get RTK working with it to give us more accurate GPS position and velocity but they haven't been completely successful yet. I'm pretty sure that nobody has tried to incorporate this level of detail into a kalman filter.
Great work. Ideally a "glitch detection" would be performed on all sensor readings before they are used and the process would be integrated into a set of policies on when to use or discard backup sensor data if available. Expensive flying lawnmowers deserve no less than professional data scrubbing. :)
Cool feature, I used an almost identical approach in my master thesis to years ago, easy to implement, and low processing requirements.
@Randy, is there any kalman filter in the 3.1 code, or is kalman a possible "Pixhawk feature", and this gps glitch detection an APM feature? Is Ublox or similar receivers able to send real-time pseudo-range (raw) observations to autopilot, not only coordinates, velocity and DOP-values?
If you are able to run a kalman filter with pseudo-ranges from GNSS, tight coupled with the IMU/INS you should get a way better position estimate and at the same time an outlier detection (glitch detection) from the kalman innovation matrix.
If you only get the coordinates, velocity, and DOP-values from the GNSS-reciever you should be aware of what velocity you use to project the position in the next epoch. Because if the GNSS position is wrong (glitch), and you use the velocity from the same GNSS epoc you will end up with a wrong projected path. (I guess this is taken care of with velocity from INS or velocity from epoch-1).
The most interesting post in a while. Hope some day to make a contribution like this. Way to go Randy!
Link to GPS/Glonass discussion: http://diydrones.com/profiles/blogs/gps-glonass, seemed like it might help with multipath, spotty coverage and short term signal loss.
This project is really going in the right direction, I already experienced issues with GPS glitches were suddenly the copter changed direction. It would also be interesting if we could detect GPS-Spoofing, as GPS-Spoofing becomes more and more feasible with the recent progress on SDR (Software Defined Radio), as in particular pricing for powerful hardware transceiver becomes accessible.
Good work, you finally are moving to sensor fusion and are not just following the gps dumbly. Multipath errors (glitches) cannot be detected by the user using DOP values. Your method is sound. I can comment from years of designing round them ,that GPS cannot be trusted....
That's a really cool feature. Do you have any data on what fraction of samples end up being treated as a glitch under different conditions (e.g. number of satellites, general PDOP of the flight).
This is really great Randy, and should certainly mitigate some of the problems with GPS.
GPS inadequacies especially at the high resolution we require are probably our main limit on precision or even reliable automatic operation.
Eventually local environment relative (vision and sensor) based solutions will come to the rescue, but for now we are stuck with the limitations of GPS.
I did notice in one of our blogs recently a small and inexpensive combination GPS/GLONASS receiver and wonder if that could be integrated to good effect.
This is awesome. It should go a long way to reducing one of the last causes of unpredictable behavior in GPS-guided modes due to degraded GPS signal, which is something that plagues all small UAVs.
-
1
-
2
-
3
of 3 Next