Rover 4.0 + Ardusimple = GPS Yaw debugging

I’m debugging Rover 4.0 + Ardusimple in an attempt to get GPS yaw working. My configuration is Holybro Pixhawk 4 ( plus Ardusimple simpleRTK2B+simpleRTK2Blite ( Companion computer is RPi running mavproxy (using the ntrip module) .

On the Pixhawk4:
• USB port connected to the companion computer
• TELEM1 connected to the sik radio
• TELEM2 connected to the ardusimple bottom board’s Pixhawk plug
• “UART & I2C B” connected to the ardusimple top board’s Pixhawk plug
• “GPS MODULE” connected to the gps/compass module that came with the Pixhawk

I followed instructions here to set params

Mission planner version

Version of ardurover at startup is:
4/30/2020 7:48:24 PM : fmuv5 001C003C 32375118 32363435
4/30/2020 7:48:24 PM : ChibiOS: 0997003f
4/30/2020 7:48:24 PM : ArduRover V4.0.0 (0e52bafa)

On the mission planner screen I see GPS: rtk Float and GPS2: 3D dgps I presume this is because the system is still using the GPS+compass module that came with the pixhawk as GPS2. So as a quick test (see ** below) I unplugged that GPS module from the Pixhawk and restarted with just the 2 Ardusimple GPSs connected in the ports listed above. Upon restart I see “EKF3 waiting for GPS config data” message repeated.

4/30/2020 8:03:21 PM : EKF3 waiting for GPS config data
4/30/2020 8:03:21 PM : EKF3 waiting for GPS config data
4/30/2020 8:03:21 PM : EKF2 IMU1 tilt alignment complete
4/30/2020 8:03:21 PM : EKF2 IMU0 tilt alignment complete
4/30/2020 8:03:15 PM : EKF2 IMU1 initial yaw alignment complete
4/30/2020 8:03:15 PM : EKF2 IMU0 initial yaw alignment complete
4/30/2020 8:03:14 PM : Ready to drive
4/30/2020 8:03:13 PM : Beginning INS calibration. Do not move vehicle
4/30/2020 8:03:13 PM : <startup_ground> Ground start
4/30/2020 8:03:13 PM : Barometer 1 calibration complete

I think the first thing I need to solve is to tell Ardurover to look on Pixhawk port “UART & I2C B” for the second GPS by setting SERIALx_PROTOCOL. This page is helpful to know which ports are which on the Pixhawk 4.

So I tried changing my SERIALn_PROTOCOL to be as follows, thinking that SERIAL3 corresponds to the “GPS Module” plug, and SERIAL4 corresponds to the “UART & I2CB” plug. But I got the same results.


(** Of course I would rather not have to physically unplug the GPS+Compass module from the Pixhawk4 because it also has a failsafe switch on it which I would like to continue to utilize. )

I would very much appreciate any guidance! Thank you


please upload a log with LOG_DISARMED=1 so I can have a look at the setup, thanks!

@tridge FYI…

thanks. That is using Rover 4.0.0 which doesn’t support the new ublox moving baseline config. Please use the latest release from here and try again:
also, it is better to use the specific Pixhawk4 firmware than the generic fmuv5 firmware:

log1.bin (31.4 KB)

@tridge this is the same test with the latest version of Rover. In this test I simply powered up, waited a few seconds, and using MANUAL mode, rotated the rover 360 degrees to the right.

1 Like

I have been using the F9P’s in a moving baseline setup on a number of vehicles for a few months now. The settings required to get this going do not seem to be well documented. If you have not pre-configured your modules to output the correct data (using u-center) then you need to enable GPS_AUTO_CONFIG and all the other parameters it uses to configure the GNSS modules (cheeck out all GPS_XXX params). This will allow Ardupilot to configure the modules to output the required data. Enabling this setting makes the boot process take somewhat longer but you can also set GPS_SAVE_CFG = 1 for the first boot to get the modules configured then set GPS_AUTO_CONFIG = 0. You then need to make sure that all GNSS antennas are precisely located using the GPS_POSXXX params. In my case where I had the moving base ‘rover’ module connected as GPS2, I had to set GPS_AUTO_SWITCH = 3 to force the use of the module that was actually outputting the heading - otherwise I could see the heading being caputured, but not used (‘status GPS*’ command in mavproxy). Hopefully this is some help and maybe we should put some effort into writing up a more comprehensive description of how to set this up…

1 Like

@jimovonz which F9P boards have you been using? Ardusimple?

I have been using this board:
I have ordered 14 in total over the last 6 months and had no issues. I have used them on vehicles, base stations and rover poles.

@tridge bump… in case you have time to look at this. Thanks!

that is an oddly incomplete log. Did you trim it somehow? It has no GPS messages at all, no startup msgs, and only has a small fraction of the parameters (eg. no GPS parameters).

@tridge I believe this logfile should be complete. Configuration as described above.

thanks, and sorry for the slow response. I loaded the latest rover firmware and the parameters from your log onto a Pixhawk4, and connected two F9P GPS modules. I connected one to Telem2 and the other to the “UART & I2C B” port.
The two GPS module antennas are 83cm apart on my roof, which is close enough to the 90cm you had configured in your parameters.
It all worked fine for me with Rover master. I’m seeing yaw from GPS2 (the GPS plugged into the “UART & I2C B” port).
Here is a photo of my setup:
Google Photos
For the wiring shown in my setup the only parameter you had wrong was EK3_MAG_CAL which should be either 5 or 6 to use the GPS yaw.
Here is a log of it working for me:
I can’t be sure why it isn’t working for you, but one guess is that maybe your 2nd GPS is configured with a baudrate ArduPilot doesn’t understand? ArduPilot can change the baudrate, but only if it starts with one it has in its probe list here:

Thank you @tridge. I’ll dig through this. A few questions:

  1. Do you think it matters that in my configuration, I have a 3rd GPS (the basic GPS that comes with the Pixhawk4, which is not an F9P GPS, but which does have the failsafe button and a mag compass) plugged in to the Pixhawk4 “GPS Module” ? As I wrote I would like to retain this GPS, mostly for the failsafe button… Would it be hard for you to plug a 3rd GPS (ideally a non-F9P GPS with a mag compass and a failsafe button…) in to the “GPS Module” plug and test?

  2. The Ardusimple setup has the 2 GPSs physically connected. I assume your config does not. I expect the latest firmware is not compiled to support the 2 GPSs physically connected… Correct?

  3. Does your configuration also include RTK corrections (from an external ntrip source) to provide accurate absolute position (in addition to GPS heading from the RELPOSNED message)?


no, that doesn’t matter.

the master firmware supports sending the RTCMv3 data either back via the autopilot (that is the default) or via UART2 on each GPS, cross-linked between the GPS modules. To enable the latter setup you should set the parameter GPS_DRV_OPTIONS to 1.

it does, although I didn’t have NTRIP data streaming at the time of the log file I included above.

@tridge @jimovonz I think I am getting close. Ardupilot is talking to both GPSs (as evidenced by GPS status on both GPSs). One of the GPSs is in status 5 and/or 6.

Configuration as listed above.

But, I am still getting an error about bad compass, and the vehicle’s heading is 0 degrees.

Would you mind taking a look?

Hi Chris,

It looks like your ‘rover’ GNSS module is getting corrections as it achieves a rtk fix status. The yaw parameter for GPS2 is zero so I would say that the yaw from the rover GNSS is being rejected due to the reported baseline distance being more than 20% different from the actual baseline length as calculated from your GPS_POSXXX params:

I would check these params are set correctly:

You should also disable all compasses and also disable EK2 by setting the following params to zero:



1 Like

@jimovonz thanks for your help. I have updated my GPS_POS settings and still no love. GPS2 is getting rtkFixed status, but, still yaw is not getting picked up by the autopilot.

logfile here:

One thing I notice is that in the mission planner Messages window, there is a “saving config” message for GPS ublox #1, but not for #2. Should have a “saving config” message for GPS #2?

I wonder whether the relposned message is even being output by GPS2. Did you have to configure the GPS (using ucenter) to ensure that UBX-relposned message is output on the correct uart, or, does the ardurover code handle that configuration?

Also, is there any way to know whether the relposned message is being generated by GPS2? Anywhere in the .bin logfile I could look for that?

Thanks again - I think I’m close. fyi @tridge


Actually, @jimovonz I see that GPS2 is in fact configured to produce the relposned message on UART1 (which is the port connected to the pixhawk).

Hi Chris,

I see that you have a relatively large vertical distance between the rover and base modules - I was concerned that the code might be comparing 2D length vs 3D length and still getting a 20%+ error but it appears that the code handles everything correctly in 3D. You can view the live RELPOSNED information being generated by the rover module in u-center under View -> Messages View and selecting UBX -> NAV -> RELPOSNED. This should show you the computed baseline ‘Length’ which has to be within 20% of your configured length of 1.21m to be accepted by the Ardurover code. In my experience, this computed length is accurate to better than 1cm with a RTK FIX

Hi @jimovonz,
I haven’t figured out how to connect my GPS2 to u-Center while it’s also connected to Pixhawk. The Pixhawk JST-GH connector connected to the Pixhawk is connected to UART1. There is access to UART2 on the headers on the board (called the “top xbee socket”)… But I can’t get UART2 to respond to u-Center…

Is there a way from within pixhawk, or mission planner, where I can see the ubx-nav-relposned messages being received by ardupilot?

Or, do you think I’m chasing up the wrong tree?