Dual GNSS Performance and Failover

coby · March 2, 2017, 6:08pm

We will be testing dual GNSS on a copter for the next couple months - Navio2 M8N and one Reach. Adding this so people can share their experience and because there are open issue over on ArduCopter that can use our help.

Running single GPS you should see this behavior if you loose GPS…

http://ardupilot.org/copter/docs/gps-failsafe-glitch-protection.html

As of 3.3 we should now see a possible drift of about 1m/s and a message in the HUD.

However, this post - suggest issues with single GPS be posted there - seems to indicate that things might not be behaving as planned.

For dual GPS there are still open issues…

github.com/ArduPilot/ardupilot

Copter: failover to 2nd GPS can cause sudden movement

opened 05:44PM - 13 Feb 15 UTC

closed 06:00AM - 10 May 17 UTC

andrea25

Enhancement Copter

Few day ago I had a crash. Unfortunately no log and no video. I was using doubl…e GPS on PixHawk. 2 Ublox LEA-6H. I was flying with DCM, no EKF. I was using arducopter 3.2. I deliberately created some interference with one of the two Ublox. I had to do this for testing purposes. What happened is this: Copter switch to the GPS with high HDOP. During the switch PixHawk emit some melodic tones. And the this is all right. Then I started the interferences tests. At a certain point PixHawk switch the GPS and the copter sudden move itself forward. The copter repeat some strange movements every time I go to "create interference" with one of the two GPS. But it not do immeditaly, it to it after the gps switch (I can hear the tones). So, practically: the copter siwtch to the GPS with high HDOP but do not check if the position is too differnt from the starting position, and if the position reported by the GPS with high HDOP is too far away, you can have a little fly away. By the way this is what I think. I'am not sure at 100%. This is what I think. Can anyone go to check this? I had a crash on a tree after hearing the GPS switching tones.

Leads over here…

Leads to this being considered for ArduCopter 3.5+…

github.com/ArduPilot/ardupilot

Add EKF support for multiple GPS receivers

ArduPilot:master ← priseborough:pr-gpsBlending

opened 04:02AM - 30 Jan 17 UTC

priseborough

+723 -79

**Problem** The existing logic used to switch between GPS receivers can cause… large unpredictable jumps in EKF position if dual GPs receivers are fitted and GPS_AUTO_SWITCH is set to 1. **Solution** Extend the GPS_AUTO_SWITCH to type 2 which is a soft switching/blending method using a weighted average of physical receivers to create a third 'virtual' GPS where: 1) The method is scaleable to more than 2 GPS receivers 2) A 'blended' location and velocity is calculated using a weighted average of the two receivers 3) Weights are calculated using the ratio of reported error variances. 4) A filtered location offset correction is calculated for each receiver relative to the 'blended' location and used to correct the output from each receiver. 5) If less than 2 GPS units are available the first GPS instance detected will be used. 6) If there is not enough error reporting to support calculation of the blending weights, the first receiver with the equal highest solution status value will be used . This can happen if one of the two receivers does not provide a position or speed accuracy. The existing hard switch logic has been left untouched and is selected with GPS_AUTO_SWITCH = 1 the same as before. Logging has been updated to to log the blended GPS instance if it is being calculated. **Status** This is a draft for comment. it has had limited flight and bench testing. **TODO** Improve the legacy hard switch logic to use solution status and reported accuracy (if available) rather than number of satellites. Using the number of satellites doesn't work as a metric where there are mixed receiver models (eg GPS+GLONASS and GPS only). Bench testing of various GPS failure modes - signal fade, loss of physical connection.

I like the idea but I am concerned this new blended mode could have unintended consequences for RTK - EXIF metadata logging precision? Or??? PPK post processing would be still done from Reach raw logs so no change there, so perhaps not a big deal? Seems like it might be a problem if you wanted very precise (RTK) absolute position during flight?

UPDATE 3/9/16

This is latest PR

github.com/ArduPilot/ardupilot

GPS Blending (attempt2)

ArduPilot:master ← rmackay9:prise-gpsblending3

opened 04:37AM - 09 Mar 17 UTC

rmackay9

+980 -245

This is an updated version of @priseborough's earlier PR: https://github.com/Ard…uPilot/ardupilot/pull/5642 This PR adds the following: - GPS_AUTO_SWITCH parameter has new Blend ("2") option which blends the input from 2 GPSs into a 3rd "virtual" GPS. The blending is performed within the AP_GPS library. If successful the "primary_gps" is changed to the 3rd GPS (aka the virtual GPS). The existing options "0" and "1" are not functionally changed by this PR. - EKF2/EKF3 resets the horizontal and vertical height estimates if the primary GPS is changed. - DataFlash logging of 3rd GPS (GPS3, GPA3 messages) - Pre-arm check that GPSs (if present) are within 50m of each other (3 dimensional distance is used) - Pre-arm check that blending is healthy (if GPS_AUTO_SWITCH is set to 2) - SITL receives a new SIM_GP2_GLITCH vector for easier testing. One downside is that the glitch only applies to the virtual Ublox GPS. These commits can be removed from the PR if they're unacceptable. - a few unrelated commits to the AP_GPS and AP_NavEKF2/3 libraries to remove unused methods, fix comments. These can be moved to a separate PR if that would help with the review. Previous explanation of the blending method from Paul: GPS_AUTO_SWITCH type 2 is a soft switching/blending method using a weighted average of physical receivers to create a third 'virtual' GPS where: - The method is scaleable to more than 2 GPS receivers - A 'blended' location and velocity is calculated using a weighted average of the two receivers - Weights are calculated using the ratio of reported error variances. - A filtered location offset correction is calculated for each receiver relative to the 'blended' location and used to correct the output from each receiver. - If less than 2 GPS units are available the first GPS instance detected will be used. - If there is not enough error reporting to support calculation of the blending weights, the first receiver with the equal highest solution status value will be used . This can happen if one of the two receivers does not provide a position or speed accuracy. - The existing hard switch logic has been left untouched and is selected with GPS_AUTO_SWITCH = 1 the same as before. This has been tested in SITL and flight tested.

coby · March 9, 2017, 2:22pm

So with the next Navio distro around the corner just curious to know what is considered best practice for parameter settings regarding failover when using dual GPS with current Copter 3.4.x?

These will likely change with 3.5 given new blended mode, but that is still a ways off and I would like to help establish a baseline for the correct parameter settings for 3.4.x so it will be easier to migrate.

And with these settings, what is the expected behavior? And are people seeing something other than expected behavior?

george.staroselskiy · March 13, 2017, 2:22pm

Blending GNSS mode has just been merged to master but it hadn’t gone through excessive tests. In a future (we’re nearly there) release we’ll make it easy to switch between different ArduPilot binaries, so it’s going to be pretty easy to migrate from one to another.

You’re right.

As I said above, we’ll need more tests to be make more assertive assumptions but I suppose this PR will make precise absolute positioning code more robust without degrading the overall picture. So you’ll kinda have the best of the two worlds. The logs that Paul has shared seem to be reassuring as well.

We have conducted tests with Reach and Navio and GPS_AUTOSWITCH set to AUTO which selects a receiver with a “bigger” fix value, i.e. once Reach acquired RTK fix the autopilot will fail over to it. It’s happened without serious twitching.

coby · March 16, 2017, 1:45pm

thanks @george.staroselskiy will look forward to the update and testing. for our latest project, we decided to leave the Reach on but disable auto switch until the different code bases get to next stable. way too much churn from too many directions - ReachView, RTKLib, Emlid Raspbian, Raspbian, and ArduCopter 3.5 - so we will wait for next releases to see if it is really usable together as a flying RTK solution.