Rover 4.0 + Ardusimple = GPS Yaw debugging

Thanks for all the support on this forum.
I have gotten the yaw messages from two ardusimple boards with wires connecting Uarts and transferring RTCM corrections.
I now see yaw numbers below 65535 all the time in inspector.
Only thing weird now is that the heading is 90 degrees off, I’ve tried correcting in many of the parameters but haven’t been successful in aligning it. In fact it doesn’t matter if I set the dimensions from x to y. I think this is because the GPS configs send the yaw and position to GPS2. but there is no way to correct for the yaw.

1 Like

I got my GPS for yaw working just now.
I am using my Autopiot board (Navio2) with a 180deg yaw offset on my zeroturn rover and got the gps4yaw working only after typing in the correct numbers for GPS_POS_XYZ relative to the board without the 180deg offset!!! Before I had it relative to the “forward” direction of the rover and never got the GPS2_RAW yaw number away from 65535.
Maybe that helps somebody.

1 Like

Hello again, I’m 95% there…
Still having an issue with yaw constantly drifting. Looking at Inspector, the GPS yaw looks correct in that it only changes with yaw rotation, however the AHRS2 Yaw has a constant turn left without any movement of the board or GPS’s. I’m using Cube orange on a mini carrier board. I can only calibrate the compass before the EK3 gets a lock, also only one external compass shows up, the Cube internal compass does not show up I get a constant Compass Variance error with any movement of the Rover. I can barely complete any missions as the rover is constantly adapting to a false rotation.
I tried reinstalling firmware and Rover 4.1, also moved all sensor to default position with the base (GPS1) in front about 30cm and the Rover back about 70cm from the board.
Any ideas? Seems I should be seeing to compasses in the setup page, but only one shows.

@blacknose2010
@jimovonz
@Yuri_Rage
Can you guys depict how your GPS antennas are setup on the frame? Seems the defauls expected orientation of the base and rover is not clear. I’ve tried having them left and right half a meter away from the centerline on each side, and also forward and back,
I’ve now gone back to the cube purple given it doesn’t have an internal compass to confuse things, not trying to get back to GPS2 yaw figures under 65000

@francismolloy The location of your antennas should not matter with regard to obtaining heading - as long as you have some reasonable separation (base line distance) and have the GPS_POSXXX params set correctly. We have large rovers and set up the primary GPS on the intersection of the longitudinal axis of the vehicle and the line that connects the fixed wheels with the centre of rotation. The second antenna can be placed anywhere convenient. In our experience the location of the primary GPS is important for correctly dealing with the accelerations reported to the EKF

If you can see appropriate heading information coming from the GPS but the system heading does not follow it then I would be checking that you are using EKF3 and have MAG_CAL set correctly

Hi all, this is Josep from Ardusimple.

I found out this thread thanks to one of our customers and I would like to share the configuration that got my simpleRTK2B+heading - Basic Starter Kit working with Ardurover v4.1.0-dev + Pixhawk 4.
Just to clarify, the heading kit is built with a simpleRTK2B and a simpleRTK2Blite boards (piggyback connection).
We will prepare a step by step tutorial at our site but I would like to get your feedback first to know if you could make it work also.

Important things before start (already mentioned in this thread):

  • You need RTK fix, so place both antennas in a good location (outdoors, no trees, no high buildings around)
  • Place both antennas 1m away of each other (I will use this distance later, you can change it but should be >30cm and <5m).
    Place the antennas in the X axis of your rover (forward direction). You can change this later.
  • Place both antennas in a plane parallel to your autopilot plane (i.e. if your autopilot is horizontal, place both antennas at the same height above ground)
  • Do not connect the GNSS receivers with the autpilot yet, we will configure everything independently and connect everything afterwards
  • simpleRTK2B (big board) acts as a rover in the moving base configuration
  • simpleRTK2Blite (small board) acts as a base in the moving base configuration

Step 1: load simpleRTK2B configuration

  • Connect the simpleRTK2B to your PC via the POWER+GPS microUSB connector
  • Run u-center and connect to the receivers
  • Go to Tools > Receiver Configuration … > Select configuration file simpleRTK2B_FW113_HeadingKit_Rover_10Hz_Ardurover-00.txt (20.9 KB)
  • Click Transfer file -> GNSS
  • Go to View > Messages View > UBX > CFG > CFG > Select Save current configuration and click Send button

Step 2: load simpleRTK2Blite configuration

  • Make sure the simpleRTK2Blite board is mounted on top of the simpleRTK2B board
  • Connect the simpleRTK2Blite to your PC via the POWER+XBEE microUSB connector
  • Run u-center and connect to the receivers
  • Go to Tools > Receiver Configuration … > Select configuration file
    simpleRTK2B_FW113_HeadingKit_MovingBase_10Hz_Ardurover-00.txt (20.9 KB)
  • Click Transfer file -> GNSS
  • Go to View > Messages View > UBX > CFG > CFG > Select Save current configuration and click Send button

Step 3: load Pixhawk 4 configuration file for ArduRover 4.1.0-dev
parameters.param (14.5 KB)
Since the hardware and firmware versions may be different to yours, here is a list of all the parameters modified wrt the default configuration:
COMPASS_ENABLE,0
COMPASS_USE,0
COMPASS_USE2,0
COMPASS_USE3,0
EK3_MAG_CAL,5
EK3_SRC1_YAW,2
GPS_AUTO_CONFIG,0
GPS_AUTO_SWITCH,0
GPS_POS1_X,-1.25 *This value must contain the distance between antennas. Change sign if heading has a 180deg offset.
GPS_PRIMARY,1
GPS_TYPE,0
GPS_TYPE2,18
SERIAL1_BAUD,115
SERIAL1_OPTIONS,0
SERIAL1_PROTOCOL,5
SERIAL2_BAUD,115
SERIAL2_OPTIONS,0
SERIAL2_PROTOCOL,5
SERIAL3_BAUD,115
SERIAL3_OPTIONS,0
SERIAL3_PROTOCOL,-1
SERIAL4_BAUD,115
SERIAL4_OPTIONS,0
SERIAL4_PROTOCOL,5
SERIAL5_BAUD,115
SERIAL5_OPTIONS,0
SERIAL5_PROTOCOL,5
SERIAL6_BAUD,115
SERIAL6_OPTIONS,0
SERIAL6_PROTOCOL,5
SERIAL7_BAUD,115
SERIAL7_OPTIONS,0
SERIAL7_PROTOCOL,5

Step 4: connect the heading kit to the Pixhawk 4

  • Use the “Pixhawk” connector on the simpleRTK2B (big board) and connect it to the Telem1 port.
  • Power Pixhawk 4 and check heading value
  • As an additional check to see if it is working, the heading value of the AHRS should be the same as the one in CTRL+F > MAVlink inspector > GPS2_RAW > yaw

Remember, if fix type is not RTK fix, or antenna distance is not within 20% of the GPS1_POS_X parameter or autopilot attitude does not match antenna ehight difference, the GNSS based yaw will not work properly.

4 Likes

Finally!!! I will try this and let you know.

2 Likes

Hello, anyone that used this last configuration, what were the results? Did it work for you @Christopher_Milner?

Hi everyone, one of the configuration files posted in my early reply is not 100% correct.
Since I can’t edit the reply, please refer to this post for the correct version:

1 Like

@jolivart, your configuration is somewhat curious, disabling GPS1 and connecting only GPS2 (the rover) for RELPOSNED messages. RTCM3 injects would then have to be provided via a source external to the flight controller. That specific configuration (disabling GPS1) is not documented by the Dev Team, though it seems you have achieved good results that way.

It seems that @GRS26 wants to connect both the rover and moving base to his flight controller and provide RTCM3 injects via MAVLink and the flight controller to the moving base. Using the simpleRTK2B + simpleRTK2BLite piggyback physical configuration, is that possible? I’m unclear as to the pinout/connections between the piggyback board and rover, and whether such a setup will result in serial traffic collisions.

From my experience, where I use 2 SimpleRTK2B boards (not piggyback lite), I can see how this configuration should work. The only thing that I would worry about is that it seems odd that Ardupilot will still calculate heading using the GPS Yaw calculations from NAV-RELPOSNED when the parameters would indicate that there is no moving base GPS (GPS_TYPE=0). But I guess at least the beta version still does the calculation. If that remains in the stable release, then this seems very usable.

With 2 independent boards as I am using, however, I can connect both GPSes to the Flight Controller via their UART1 ports and then Ardupilot can configure them. Right now, however, Ardupilot 4.1.0-DEV or BETA doesn’t do a few things to make it completely plug and play without having to do a little configuration in UCenter. If interested, see this post and the following for comments on what I had to change manually in Ucenter: KevinG’s Autonomous zero-point turn Lawn Mower - Blog - ArduPilot Discourse

Hi all, in the piggyback connection, the tutorial is meant only to provide high precision heading.

If you also need to get high precision position, you should:

  1. Connect the simpleRTK2Blite (the small board that acts as a moving base ) JST-GH connector to another free port in your flight controller
  2. Setup your flight controller to forward RTCM corrections to the simpleRTK2Blite.
    Make sure that the baudrate is set at 460’800bps.

As an alternative method, you can also plug a Bluetooth, WiFi, MR, LR separate radio link at the top of the simpleRTK2Blite and send the corrections via a fixed base station. This will help your telemetry radiolink if it is already close to its limits.

Just fyi, the advantage of using the “piggyback” connection is that the moving base RTCM corrections, which are long messages sent at a high rate (10Hz) are done outside the flight controller by directly connecting the proper pins of the ZED-F9P receivers. These forwarding task is pretty heavy if it needs to be done by the flight controller and it seems that it is not stable at high rates.

Best regards,
Josep

2 Likes

Makes sense @jolivart. Thank you for clarifying!

Like @ktrussell, I use two simpleRTK2B boards onboard (along with a third as the fixed base).

Kenny uses a dedicated radio link for RTCM3 messages, and I use MAVLink injection.

So far, we are both mimicking the piggyback configuration by connecting the simpleRTK2B UART2 ports together for RTCM3 corrections from the moving base to rover, thus avoiding that heavy lifting task by the flight controller. I will be testing message forwarding via the flight controller under 4.1.0-beta1 later this week.

1 Like

Thanks for all the information in this thread, I finally got it working.
Does anyone know what happens if yaw is lost in the middle of a mission? My vehicle has no backup compass and only gets yaw from the GPS. None of the compasses I have installed have worked so far and calibration is not simple on such a large vehicle either.

3 Likes

I do not know what happens when yaw is lost, but I just wanted to comment on that impressive vehicle! Congratulations!

Very cool indeed!

@tridge might have a better answer, but I think in the case of a GPS yaw error state with no magnetometer compass source, the flight controller will revert to an inertial reference, possibly filtered/corrected with GPS track (heading) information.

I’ve experienced brief GPS yaw dropouts with no ill effects, but I’ve not tested any extended period with a lack of heading source.

Do you have wheel encoders on your robot?

I did a test a while back on my rover with RTK GNSS and wheel encoders with all magnetometers disabled. I gave it an auto mission and intentionally positioned the robot such that its actual heading mismatched the reported heading.

The robot heading starts off in the wrong direction but after a few feet it corrected itself and was rock solid thereafter. It’s been a few months since the test but I think I was running 4.0.

My guess is it must have been using GNSS information to figure the heading. That or one of my magnetometers wasn’t actually disabled. But the heading was much more accurate with the magnetometers disabled.

Just my two cents. I’ve contemplated completely eliminating the magnetometer from my robot because of this test, a few seconds of wrong heading for no bad compass health warnings during the mission is a good trade off on my book.

I’ve seen the same thing with magnetometers disabled but my pivot turns were awful without a heading when the vehicle was not translating, just pivoting. I did not have wheel encoders, however. Perhaps that can help with the pivot turns.

Thank you.
It was raining a bit the other day and with the sky so cloudy, it took forever to get RTK and yaw, but once achieved, it didn’t lose it at any point.
I’ll have to try disabling RTCM corrections in the middle of the mission and see what happens. I’m injecting them using 4G and it is likely that in the middle of the field (it is an agricultural vehicle) there won’t be good enough coverage, hence my concern.

Unfortunately, no.
The autopilot is almost independent of the vehicle itself. The only data it outputs is desired speed and turn angle through a serial port, and it receives no input or feedback from the vehicle.
It is more of a proof of concept than a finished product.

Parameters such as AHRS_GPS_GAIN, AHRS_GPS_USE, AHRS_YAW_P (and probably others I don’t know) affect how the heading is determined from the various inputs.