Heading informations via moving baseline configuration (GNSS-antenna setup)

Hello everyone.

I have a Pixhawk 6C with ArduRover 4.4.0 installed, and I want to receive RTK float/fixed informations provided by
u-Blox antennas. I get the positions, the coordinates, but I don’t really see how the autopilot receives the heading information from the GNSS-modules (I have to fetch heading in the relation of the 2 antennas, heading and base).

Since we have no custom GNSS base station, we are connecting the modules to an NTRIP server to fetch RTK correction information from there.

What I have done so far:

  1. upgraded the firmware of u-blox modules to version 1.32

  2. uploaded configuration files & saved configuration to the flash (5Hz simpleRTK2Blite (Moving Base) and 5Hz simpleRTK2B (Rover) accordingly) that can be found on this URL: u-blox configuration files 1

  3. Changed & written parameters in the Mission Planner by following the ArduSimple guide: How to connect simpleRTK2B Heading - Step 12

You can reach my currently applied parameter list here:
config-current.param (14.5 KB)

GPS_RATE_MS and GPS_RATE_MS2 values are also set to 200 milliseconds to align with the 5 Hz configuration files loaded into GNSS-modules.

Right now, SERIAL1_BAUD and SERIAL2_BAUD are also set to 115, but I am unsure whether it is considered a good setting for the simpleRTK2B + Lite modules. How should I check my baud rates are good?

My question is, what else do I need to set in order to fetch heading information from the u-blox?

If you could help, I would be very grateful.
If you need me to provide more information in order to resolve this issue, please feel free let me know.

Thank you.

You’re further along than me - tried all of the above, but can only see my fixed base. I’m pretty clueless/confused about how the physical serial wiring from the RealSimpleRTK (big boards) make it to showing something other than “No GPS” on my HUD.

I’ll hang on to your thread and hopefully at Mowstock this weekend I’ll have something to contribute.

Screens I’ve monkey’d with are the DroneID tab below the HUD - set up my Fixed Base there and that’s working; Full Parameters per the SimpleRTK instructions; and the Setup::Serial Ports page - tried every port and several baud rates to no avail.

All this said, I have my Moving Base plugged into the GPS physical port on a Pixhawk 6 rpi (not using the rpi yet); and the the Rover plugged into Telem3 (Yuri mentioned something about it not mattering, but will build a cable for the GPS2 port and see if that does some goodness.

Hang in there - there are some really knowledgeable folks here that jump in and help!

Just noticed your GPS_AUTO_CONFIG is set to 1, simpleRTK recommends 0…

1 Like

This thread is another example of why I never recommend the SimpleRTK2B+Heading kit for ArduPilot. It’s a giant PITA to set up. My frank opinion is that we should move this specific hardware combination to the UnSupported category, as it causes more problems than it solves!

Additionally, as of the last time I checked, it’s cheaper to just buy two SimpleRTK2B boards in the first place! Using two SimpleRTK2B boards allows ArduPilot to autoconfigure everything, and it works first time, every time.

Your problem appears to be several fold:

First, GPS_AUTO_CONFIG is possibly ruining all of that hard work you did in u-Center. Set it to zero and then load the configurations from ArduSimple via u-Center again.

Second, the config from ArduSimple specifies 460800 baud. You need to use that.

Third, you probably have the wrong serial ports specified. ArduSimple uses SERIAL1 and SERIAL2 by way of example. You need to configure the serial ports where your GPS modules are actually connected.

For example, if you are using a Cube Orange, and the GPS modules are plugged into the ports labeled Telem1 and Telem2, then SERIAL1 and SERIAL2 are correct. However, the ports labeled GPS and GPS2 are SERIAL3 and SERIAL4, respectively. For the Cube Orange, serial mapping can be found here: Pixhawk FMUv2 / Cube FMU v3 Serial Mapping — Copter documentation (ardupilot.org). Similar documentation exists for other autopilots.

2 Likes

Dear Yuri_Rage.

Sorry for the latency in my reply. Yes, you are absolutely correct about the baud rate and the GPS_AUTO_CONFIG parameter. Sorry, that was my fault. I forgot to mentioned that I am connecting the GNSS modules, 2B (base, big board) to Telem1 and 2BLite (rover, heading, small board) to Telem2 ports, so I think it can be already accepted as SERIAL1 and SERIAL2.

Actually this way I can connect the Pixhawk only to my PC, and the Pixhawk is providing the GNSS modules power as well, which is super cool.

I think it’s not such a PITA to configure this, I’m just rather new to this field, and I really miss some clear, direct guidance on which tutorials to follow.

(Actually I’m making my thesis work with this goal, to provide a straightforward description about how these stuffs should be configured to make them work correctly.)

Another question that I am using this moving baseline configuration, I should still solve how to solve the RTK Injection, to connect to NTRIP caster automatically, right? So when the companion computer inside the rover connects to the Wi-Fi, it should connect/reconnect to the NTRIP server so external corrections can be injected to the ArduPilot (with the use of GNSS-modules).

Yes, thank you. I reconfigured it using the ArduSimple’s guide ArduSimple. Yes, I thought it would solve the problem just to set GPS_AUTO_CONFIG to 1 but it actually made things works, the GNSS modules’ moving base-rover configurations might have been overwritten.

Wait, you actually see “No GPS” on the HUD? That means the ArduPilot “sees” NO (zero) GPS module as connected. Is your GPS_TYPE set correctly?

I mean I see “No GPS” in the SITL when I set GPS_TYPE to 0 actually. When I set this to its default value, to 1, the RTK Fixed is there because it uses a simulated u-blox module for RTK simulation.

Based on what you’ve written, are you connecting the modules to GPS1 (which is SERIAL3 in case of the autopilot) and Telem3 (which is SERIAL5)? If so, then I think you should explicitly set autopilot’s parameters SERIAL3_PROTOCOL and SERIAL5_PROTOCOL parameters to GPS (which is 5). I did the same but with SERIAL1 and SERIAL2 because I am connecting my ArduSimple GNSS modules on Telem1 and Telem2 ports.

Again, you must follow ArduSimple’s guide for this hardware. I don’t really know what else to tell you.

1 Like

Alright, thank you very much for your help. Have a nice day!

I do hope you get it sorted out. ArduSimple makes high quality hardware, including the +Heading kit. It’s just that ArduPilot plays a lot nicer with a pair of their basic SimpleRTK2B boards rather than the kit with the sandwiched daughterboard.

1 Like

Yes. Another thing that I’m not really sure about is that in a moving baseline configuration, which we are aiming for right now, we have one receiver acting as base (simpleRTK2B) and another receiver acting as rover (simpleRTK2B). Both of them are on the vehicle, moving, this makes them moving base and moving rover, that is for sure.
But we still need RTK corrections from NTRIP since RTK needs a base that is stationary, right? So in our case we have 3 actors: moving base, moving rover and a CORS (Continuously Operating Reference Station) from NTRIP, right?
Could you please clarify that for me or just reassure me that I’m correct? Confirmation is a great answer, I think.

This is how I understand the scenario. I have a fixed base tho…

Can confirm.

Without an external NTRIP/CORS source, the rover GPS should show RTK Fixed when the moving baseline config is correct, and GPS yaw should be present.

When the external correction data is present, both units should show an RTK fix.

1 Like

Alright, thank you very much for the fast reply.

We took the rover outside of the building, and the results were the same as inside. Mission Planner showed us GPS: RTK Fix and GPS2: 3d DGPS. The heading difference was 180 degree, so the front of the vehicle was swapped with the back of the vehicle.

For me it was a failed test.

I also tried to change the sign of the GPS_POS1_X parameter, which was set to 1 at the first time because there is 1 meter difference between the antennas. GPS_POS1_Z was set to 0.05 because the antennas are 10 centimeters above the SimpleRTK2B + Lite modules.

I also connected to the NTRIP-server successfully from the Mission Planner’s Optional Hardware > RTK/GPS inject tab.

I used the following parameter list for the ArduRover
config-2024-04-04.param (14.5 KB)

What could still cause the issue?

Perhaps SERIAL3_PROTOCOL and SERIAL4_PROTOCOL should be changed to -1, because SERIAL1 and SERIAL2 (Telem1 and Telem2) ports are used for GNSS modules.

I also noticed that according to the ArduSimple guide EK3_MAG_CAL is being set to 5 which is “Use external yaw sensor” which is a deprecated stuff from ArduRover 4.1+. The guide for GPS For Yaw states that it is not used, so I should leave the default value for rover which is 2 (Never)

2B and 2BLite are connected like this, then 2B is connected to Telem1 and 2Blite is connected to Telem2, therefore both of them gets power by the Ardupilot. Is it good like this?

Last time I checked, Ardurover’s GPS_INJECT_TO param is set to 127 (meaning send to both modules), so RTK injection can work, right? Is the GCS able to send the fetched RTK corrections to the GNSS-modules from NTRIP base? This is what I’m a little bit skeptic about.

Sorry for the multiple replies, I just keep thinking and giving ideas on what could cause this issue.

GPS_GNSS_MODE,0
GPS_GNSS_MODE2,0

Should these params be changed perhaps?

Okay, today’s test was much more smooth. I tried injecting RTK from NTRIP via Mission Planner and u-center (directly connecting to GNSS big board), I felt no difference between the two methods. The signals outside were changing between rtk Fixed, rtk Float and 3D dgps, but I consider it to the fact that we were between large buildings. Hopefully it will be better (I think we should have more time in rtk Fixed) on flat areas. The heading was okay, so the front of the vehicle was really the front of the vehicle, so it was aligned, but still there is a 45 degree offset to the left as far as I can tell from the UI of Mission Planner. But the yaw degree in relation with the North pole was correct.

I mean the rover faced parallel to the wall (white object to the right)

So based on these results, all I need to do is change some offset related to the yaw, correct?
Is there a way to tune up the GNSS receivers? Should I even bother with that?