Servers by jDrones

ArduPilot with Dual GPS (blended)


(All In) #21

Sorry for asking such a noob question but I’ve tired to set up the second gps on my own and no matter how many times I look for it in mission planner I can only find protocol_4, it’s already set to gps. I cannot find the gps_type2 or gps_auto_switch. Or I’m not looking in the right place in the parameters? I’m on mission planner

Sorry but any guidance on how to correctly install and blend the second gps module would be greatly appreciated.

(rmackay9) #22

Hi All_In,

You’ve seen this wiki page I guess:

Make sure you’re using Copter-3.5-rc7 (or higher). This blending feature is only available in recent versions of ardupilot. It hasn’t been released officially yet… but we’re getting close to officially release Copter-3.5.

(OlliW42) #23

EDIT: It was probably not a smart move to post this question in here, but maybe nevertheless someone could briefly clarify how GPS_AUTO_SWITCH = 0 is supposed to behave in a dual GPS setup. THX :slight_smile:

I would have a question as regards the working of GPS_AUTO_SWITCH.

I’m using AC3.5-rc9, and have a main gps on the uart, as usual, and a second gps on uavcan.

The 2nd gps is a DIY uavcan gps, which I want to first test before I start relying on in it in flights. I thought that a proper strategy would be to set GPS_AUTO_SWITCH = 0, hoping that this way the flight would be totally based on only the main gps, as it usually would be, but that the data of the 2nd gps is logged and thus can be analyzed.

So, as a precursor, I did a simple test today, where I had the system just sitting in the outside for a while. The following was reproducible 4 times.

The main gps took quite longer for finding a fix than the 2nd gps, but the MissionPlanner HUD displayed a 3D-Fix at the moment the 2nd gps went good, even though the main gps still showed a hdop of 99.99!

I could capture that on a log:

I don’t understand this behavior. I would have expected that with GPS_AUTO_SWITCH = 0 the 3D-Fix is based on the main gps. The EKF at least seems to. So, I’m somewhat unsure as regards what that would mean for a real flight. Is it safe to fly, when the 3D-Fix is displayed, even though the main gps is still at hdop 99.99?

Thx, Olli

(Stephen Foster) #24

Has there been any progress on this? I have the same issue, I get a 3D fix, but HDOP is 100.

(Andrés Ábrego) #25

Missed this mention! We are just starting to configure our rover, I asked this because our project was in planning stage. Thank you for your kind reply, will send vids with rover in auto mode, I know you love it! xD

(rmackay9) #26


We’ve just started beta testing Rover-3.2 which includes dual GPS support. It’s available through the mission planner’s Install Firmware screen’s Beta Firmwares link.

(Andrés Ábrego) #27

That’s cool! Will be beta testing the following weeks, we have a pixhawk 2 and a here+rtk to configure and test.
If you are still developing the beta, would be nice to include the parameter described here Skidsteering more “throw”?
, looks like few people (like us) are having issues with it.

(wkf94025) #28

Can anyone in the Arduplane camp advise on what I should do with the following fixed wing configuration with dual GPS?

  • MyTwinDream, twin motor, mapping platform
  • Pixhawk 2.1 Cube
  • M8N GPS as main/default nav GPS and compass
  • Reach RTK GPS as rover, paired with Reach RTK GPS base unit
    No pressing need to integrate the Reach GPS into Arduplane system. Plan A is it’s a semi-standalone system that receives trigger event from Sony RX100 hot shoe to Reach RTK GPS unit for timestamping.

With that backdrop:
Can I fly missions more accurately by blending the two GPS units’ results? Or am I better letting/encouraging the RTK GPS unit to talk to the mother ship with the older M8N results?


(Amilcar Lucas) #29

Blending is better, especially if you use the GPS as a altitude source for the EKF instead of the baro.

(rmackay9) #30

With the GPS blending we recommend against mixing GPSs from different manufacturers so I think you shouldn’t blend them. The reason is that the reported accuracy from each GPS could be scaled differently which could lead to the weighting being less than idea (i.e. it might use more of the less accurate GPS because that GPS reports that it’s more accurate).

(Amilcar Lucas) #31

In other words: we accept pull requests that make your GPS report horizontal accuracy, vertical accuracy and speed accuracy in “one-sigma standard deviation” units.

If all our GPS device drivers get the same normalized units, blending works fine :slight_smile:

(ACPUK) #33

I am going to try Blending, my primary unit is the Here but the second is the Here +.
If I am to use the Here + in RTK mode, should I switch off blending?


(rmackay9) #34

My guess is that because they are both Ublox and their versions are very close that it will be OK to leave blending on. We’ve never tried it but my guess is Ublox is consistent in it’s reporting of accuracy across the two GPSs.

(ACPUK) #35

Thanks Randy, all setup now and I can confirm when I get an RTK solution it still switched to RTK in the HUD. i will go out tomorrow and test.

Slightly off topic though, as the second GPS unit is on I2c2, can we use the second external compass? It would also be nice to have the LEDs on the 2nd unit also working.

(rmackay9) #36

I don’t think the 2nd external compass and LED can be used in Copter-3.5. The issue is that both conflict with the compass and LEDs within the Cube flight controller itself.

(ACPUK) #37

Thanks again, I wonder if I should brake the I2C connection from the 2nd unit in case it causes issues.

(rmackay9) #38

It’s best that it’s not connected. It can’t be good to have the 2nd I2C cable connected.

(ACPUK) #39

Disconnected i2c2 and tested, blend all looks very nice. I will be back at the field later and do a survey and test RTK in Blend mode.

(ACPUK) #40

RTK Works very well with blend.

(rmackay9) #41

Excellent, great to hear!
We should probably update the wiki then to reflect that it seems OK to mix Ublox GPSs (or at least recent version). I’ll take care of that change in the near-ish future.

Indoor Positioning with ArduPilot based on UWB modules