Rover 4.0 + Ardusimple = GPS Yaw debugging

ArduRover Rover 4.0
66

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
67

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

2 Likes
68

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

69

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
70

@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.

71

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

72

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
73

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
74

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.

800×450

3 Likes
75

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

76

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.

77

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.

78

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.

79

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.

80

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.

81

Is there an issue with traction when relying on wheel encoders? In other words, if a wheel slips in the mud or dirt, will that cause the encoders to produce some erroneous output to the flight controller?

82

I’m sure it will, but I think the EKF can detect and correct the error between GNSS position and wheel odometry. @rmackay9 or one of the other developers can correct me if I’m wrong on that. I want to say there are parameters that govern how much weight is given to one or the other, but I’m not sure.

My rover weighs ~200lb and so slipping isn’t a huge issue for me. If you encounter a situation where the rover stopped moving but the wheels kept spinning you’d probably get warnings of some kind.

83

Hi everyone, I’m not sure this is the right place for posting this, but we recently launched a new GNSS receiver based on Septentrio Mosaic-H and compatible with ArduPilot GPS Yaw estimation.
We have prepared a brief tutorial explaining how to connect and configure it:
SimpleRTK3B Tutorial

84

I think its better if you made a new topic for that

85

Hi Folks,
simpleRTK2B+heading - Basic Starter Kit is supposed to provide correct heading even without ardurover connected, isn’t? Connected simpleRTK2B (with Lite on top) via USB+GPS to the PC, but U-Center is not displaying any heading info. Antennas are 1m in between, config updated as per @jolivart instructions above. Fix mode is always 3D Fix and never RTK fix, even though antennas in an open area outside.

U-Center_RELPOSNED
U-Center_RELPOSNED1514×1073 138 KB

U-Center-PVT
U-Center-PVT1523×1084 155 KB