Piksi RTK Issues

Ground Control Software Mission Planner
1

Hi I have finally manged to get RTK Fixed solution into my drone using a Piksi Multi board. I am running dual GPS with a Here GPS as my GPS1 and heading and the Piksi as GPS 2. They are set to switch automatically based on quality of position.

I am now have three further issues:

1, I cannot arm the drone due to pre arm failure “AHRS differs from GPS” this is saying by approx 40 metres. Have worked around this by switching Alt source to GPS from Baro but would like to understand why this is.

2, I cannot arm the drone due to pre arm failure "GPS positions vary by a ~50 metres. I think this is mainly in altitude. Only work around for this is to switch off GPS 1 which isn’t ideal when I am also have the below issue and would rather have both GPS running all the time.

3, The Piksi does give GPS status 3 but quite often is displaying GPS status 1 (No GPS fix) and only when I activate GPS Inject to give it corrections does it jump to 5 and then 6. The lights on the Piksi itself say it has a fixed position the whole time.

Any advice would be very welcome.

Many Thanks

Dave

2

Dave,

I had a similar issue with the Piksi multi and after discussing some with Swift Nav, tracked down an error in the driver for the SBP2 protocol. See this link -

Hopefully this will help. I’d be interested in hearing more about your setup - what radios are you using? are you using a local base station or NTRIP server? I used SiK radios from mRobotics and had to change some of the settings in the Piksi base receiver and radio settings before I got an RTK fix.

3

Hi Jade,

We are using RFD radios to send the RTK data string up to the drone via GPS inject in Mission Planner.

Our RTK corrections come directly from an NTRIP client that provides corrections from its nearest Cors station.

So where you seeing the same issue with the GPS’s varying and not being able to arm to drone due to the AHRS variance?

Thanks for the link but I am not very up to speed with code so I am not sure what the link is showing me.

Thanks again for your reply and if not want anymore info on our setup let me know.

Thanks

Dave

4

Dave,

That code change would mainly affect your third point from your previous email. The code change adds a case for when the Piksi reports a status of 6 - or an RTK solution. Below are the added lines of code:

case 6:
state.status = AP_GPS::GPS_OK_FIX_3D_DGPS;
break;

Without this, the code doesn’t recognize the case for the when the Piksi reports an RTK fix and Mission Planner defaults to a status of 1. I have noticed that the altitude reported by GPS1 (Piksi in my setup) and a ublox unit (GPS2 in my setup) vary widely in reported altitude. I haven’t seen the pre-arm failure but this could be because I set GPS_AUTO_SWITCH = 0 (disable, uses GPS1) or 3 (use GPS2).