ArduPilot has supported Dual GPS for quite some time but it has always only been using one or the other GPS (whichever had higher number of satellites). Also for Copter users we recommended against using two GPSs because when we switched from one to the other, the EKF and controllers weren’t notified and we could end up with a sudden position jump.
In the upcoming Copter-3.5-rc2 (beta release) the sudden jump issues are resolved and we will also include GPS Blending meaning that the output from both GPSs will be combined together. The weighting of the two GPSs is determined by their reported accuracies (horizontal position, horizontal speed and (optionally) vertical position accuracy).
We recommend using two GPSs from the same manufacturer because the reported accuracies from different manufacturers might not be compatible leading to a non-optimal blend.
Setting up dual GPSs is fairly easy. Connect a second GPS to an available Serial port (like Serial 4/5) and then set these parameters:
SERIAL4_PROTOCOL = 5 (replace the “4” with “1” or “2” if the 2nd GPS is connected to Telem1 or 2)
GPS_TYPE2 = 1 (to enable automatic detection of the 2nd GPS)
GPS_AUTO_SWITCH = 2 (to enable Blending) or 1 to use the existing logic which uses only one GPS at a time
After your flights, if you want to see how it’s performed, you can open the DataFlash log in the Mission Planner and click the “Show Map” button and it shows the paths of the GPSs, the EKF’s estimated position and in the next beta it will even show the blended GPS’s output. If you’re using a different GCS you may be able to plot the GPS, GP2 and GPB (for Blended) messages.
This feature is compatible with RTK GPSs as well. Here’s a flight from Michael Oborne using a Here+ RTK GPS and a Tersus (note we recommend using two GPSs from the same manufacturer normally).
Here’s a related video from our recent developer un-conference in Canberra Australia. This is Paul Riseborough’s heavily loaded IRIS using Blended GPS, optical flow and a lidar range finder.
This feature was definitely a team effort with the GPS blending implemented by Paul, intensively peer reviewed by Michael duBreuil (our GPS maintainer) and Francisco Ferreira (our “bug master”), MP work by MichaelOborne and finally heavily tested by me and others… and the GPSs came from proficnc and mRobotics.
Yes, it’s in our shared AP_GPS library so it will go out with the next release of each vehicle. The only thing that’s extra special about Copter (and Sub) is that the position controllers have an extra handler to deal with the sudden position jump. Still, that’s less of an issue especially for Plane I think. Certainly all vehicles will benefit from the averaging and robustness improvements of having blended GPS.
In our case we’re primarily using quadplanes, so the position controller issues might present themselves in hover? I would have thought that position change in plane would result in a somewhat erratic flight path as well. What sort of position variance is typically observed in flight between the GPS? In our use case the main reason for having two GPS units is for redundancy, so will there be a configurable parameter for setup?
Without knowing quadplane code very well, I think you are covered in that case. It’s the flying wing code that doesn’t check if EKF have done a position reset.
I’ve just checked and the quadplane doesn indeed include the position reset code. Quadplanes make use of the multicopter attitude and position controllers so there was no extra effort required.
One related thing that appears to be missing from quadplane is the yaw reset code. I would imagine this would mean that quadplanes yaw would turn after once or twice after takeoff as they climb past 2m in altitude. https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/ekf_check.cpp#L171
This is unrelated to the Dual GPS changes though.
Jeff,
There’s no config to force it to favour one over the other but the weighting is based on the reported accuracy from the GPSs. Normally that’ll mean it’ll use the RTK more than the non-RTK GPS. By the way, if you’re just looking to use it as a fallback you could stick with the existing “UseBest” logic by leaving GPS_AUTO_SWITCH to 1. Even this method is improved in AC3.5-rc2 because the position jumps should be handled properly now (you’ll probably still see a slight twitch but hopefully nothing significant).
This is awesome! Thanks for implementing this. When blending the GPS there is of course the benefit of redundancy can we expect more accurate position with this method as well or some other benefits?
I doubt weather averaging two GPS positions will result in better accuracy, for that you’d need to know which one is actually the one with the most error. I think the main benefit beyond redundancy is that it is possible to use both GPS modules at the same time, without the position jumping from one to the other in flight. (at least in copter for now)
Actually the additional GPS, when blended, does improve accuracy a bit. I can’t give the mathematical proof of why that is but it’s a real and expected improvement.
Hmm I wonder why that is. Is it because there’s a higher liklihood that the aircraft location is between the two GPS positions rather than outside of them? What was the accuracy verified with? Also what is the typical variance between the two GPS units? I’m assuming that is typically only within a few meters of eachother to start with? Would be interesting to know if that effect could be intentionally improved.
sorry, I don’t know the answers. Here’s Paul’s original PR which may provide some clues: https://github.com/ArduPilot/ardupilot/pull/5642. It’s also possible that I have misunderstood things. Maybe it’s because it weights the solution towards the better of the two GPSs so because one is likely always better than the other, overall we get a better result.
Paul Riseborough would know best.
