Regarding the problem that ROVER4.1.0beta of MovingBase method does not keep RTK-Fix

[SpreadKnowledge]

Hello.

How can I keep RTK-Fix on a MovingBase ROVER that uses two ZED-F9Ps?

I installed the Rover-4.1.0beta firmware on my Pixhawk CUBE Orange and set up MovingBase using the documentation here as a reference.
This ROVER can estimate its orientation with high accuracy, but for some reason it does not become RTK-Fix.
To be precise, for a few seconds after connecting Rover and MissionPlanner, ROVER will be in RTK-Fix. However, after that, ROVER will remain in 3D-Fix for the rest of the time.

I used u-center to install the latest firmware on the ZED-F9P and configured it as a mobile station.
Then I used NTRIP to communicate with the RTK-GNSS reference station.
When I connected the same ZED-F9P to another ROVER without the MovingBase setting, that other ROVER keep RTK-Fix.

I set up two RTK-GNSS antennas at least 30 cm apart from each other on my ROVER, and also set up a ground plane.

Is there a parameter to keep RTK-Fix that I’m missing?

[ktrussell (Kenny Trussell)]

I am working on a similar system, although I am not using MP to inject the RTCM3 from the fixed base to the Moving Base as I believe you are. I am using telemetry directly from the fixed base into the moving base.

So, I may not be able to help much, but one thing I will mention is that if you have your connections and parameters as described in the documentation you referenced, then GPS is your MOVING BASE GPS and GPS2 is your ROVER GPS, so the screen shot you included would indicate that your problem is not between the moving base and the rover, but between the fixed base and the moving base.

[Yuri_Rage]

Your results seem to indicate that you have GPS-for-yaw correctly configured, but the fixed base RTCM3 injects are not consistent enough to provide an RTK fix for the moving base.

How far away is the NTRIP station? When connected, can you see good, consistent message traffic from it?

If you are using MAVLink RTCM3 injection, try setting GPS_AUTO_CONFIG=1 rather than using uCenter to configure the GPS modules. So far, that’s the only way I’ve been able to reliably eliminate ‘Unhealthy GPS Signal’ messages (which I assume is what’s displayed in Japanese(?)). However, I’m not 100% certain that’s your problem, since I can still achieve RTK Fixed solutions without auto-configuration.

[SpreadKnowledge]

Thank you, both of you.

I set up my RTK-GNSS base station approximately 100 meters away from the test field.
Also, I think the situation of RTK-GNSS reference stations is good.
The following figure shows that MissionPlanner is receiving the base station information via the NTRIP server.

I have already changed the “GPS_AUTO_CONFIG” parameter to 1, referring to this document.

（The Japanese error shown in the HUD is “Error compass variance”. This error was resolved after I took this screenshot.）

[SpreadKnowledge]

I’ve been checking various parameters for about a month, and the GNSS conditions are still hard to RTK-Fix.
There are times when the GNSS condition is RTK-Fix, but most of the time it is 3D-Fix.
I have installed Rover4.1.0-beta4 and Rover4.1.0beta5 firmware on PixhawkCUBE Orange, but the situation has not improved.

By the way, another robot I have that is not a MovingBase type almost always become RTK-Fix when using the same ZED-F9P.

[ktrussell (Kenny Trussell)]

This is probably not going to help, but I do note that you are using the MSM7 messages:1005,1077,1087,1097,1127,1230. My fixed base is sending the MSM4 messages: 1005,1074,1084,1094,1124,1230. I do not know if the MSM7 messages, with extended resolution, somehow take more bandwidth and can cause any issue or not. I doubt it, but if you are at your wits end, you could try the messages I am using.

The fact that you have another rover achieving RTK-Fix is puzzling. I guess it might be enlightening to know if you change your GPS1 to just be a standard GPS and not a moving base, will it hold RTK-Fix.

Could the F9P be overloaded with communication? Do you have unused ports’ Protocol-Out set to “none” so that the F9P isn’t using resources to send unnecessary packets. Do you have the ports you ARE using only sending the UBX and/or RTCM3 protocols (no NMEA)?

I would ask whether you have a wiring or connector issue, but that seems unlikely.

For me personally, I need to explore the MSM7 messages. I do not know if they make a noticeable improvement in accuracy or not.

[tsm1mt (Tom Mandera)]

I’m curious why your choices are 3D or RTK Fix.

Why is it not going into RTK Float?

I have three F9Ps one base, one moving base, one rover. The MB and Rover are on the rover.

I get consistent RTK FIX out of the Rover, along with YAW.

This works all of the time.

I supply my MB with RTCM from my base. I do this via wifi with a pair of Raspberry Pis and str2str from RTKLib on both ends.

When I monitor the Moving Base’s position, it can be 3D and the Rover is RTK-Fix.

When I supply any RTCM data to the MB, the Fix goes to FLOAT or RTK-FIX.

(With the base F9P < 100 meters away, it is almost exclusively RTK-Fix)

If I sever the RTCM stream, the Moving Base drops out of RTK-Fix and will show 3D, but the rover remains RTK-FIx based on the data coming from the MB.

I believe you have a problem with your NTRIP feed to your Moving Base.

[ktrussell (Kenny Trussell)]

I’m not sure what I said to imply I don’t get RTK Float, but I did not intend to. I see exactly the same statuses you do.

I will say, though, that my fixed base is 26 miles away at the moment and I have Fixed 99% or more of the time.

[SpreadKnowledge]

I apologize for not being able to give a clear reply as I do not have any expertise in GNSS.
First of all, the wiring of my ZED-F9P is as shown in the following diagram.
The two ZED-F9Ps are connected to the PixhawkCUBE’s GPS1 and GPS2 via UART1.
The full parameter list was set according to the official documentation.

I installed Rover 4.1.0-beta6 on Pixhawk, but still the GNSS status rarely went to RTK-Fix.
Now I think that I’m setting up the ZED-F9P incorrectly in u-center.
If you have a reference URL for the ZED-F9P setup, could you please let me know (note that I did the setup based on the reference book for the ZED-F9P released in Japan)?

[tsm1mt (Tom Mandera)]

I’m not sure what I said to imply I don’t get RTK Float, but I did not intend to. I see exactly the same statuses you do.

I will say, though, that my fixed base is 26 miles away at the moment and I have Fixed 99% or more of the time.

Sorry, Kenny, I was intending to reply to SpreadKnowledge, who - as I read it - was only getting a 3D fix.

@SpreadKnowledge I’m using three ArduSimple boards, so I started with their default configuration files for U-Center -

Configuration Files

These files assume that your Moving Base is hooked to your Rover via UART1 (MB) to UART2 (Rover) and that the Rover (UART1) is connected to the Flight Controller.

I use a TTL level USB-Serial device to connect to UART2, which is the XBEE connector on the Lite board, and use my onboard computer to supply the RTCM stream. (You could use a LoRa device instead)

As I said earlier, if you’re only seeing 3D on your Moving Base, then you’re most likely not getting ANY RTCM correction data supplied to it.

Your Rover shows RTK-Fix because it is receiving good information from the Moving Base, but this Fix is only relative to the Moving Base, not absolute.

So the RTK-Fix is against the fairly inaccurate 3D fix of the MB.

To fix that, you need RTCM data to be supplied to the MB.

If you’re doing that via MavLink then you need to configure such that the RTCM corrections go to the Moving Base GPS and probably not to the Rover (the RTCM corrections from the MB to the Rover should happen, but we don’t want to confuse the rover by supplying RTCM data from two sources)

I don’t supply the RTCM via MavLink, I use UART2 and the serial connection.

Either way, when you supply ANY RTCM stream to the Moving Base, you should be getting a FLOAT status not a 3D.

If you’re stuck in 3D, I think you’re not getting the NTRIP/RTCM streams to your Moving Base.

That narrows down the problem.

[ktrussell (Kenny Trussell)]

Sorry about that! I just misread!

[Yuri_Rage]

First, I think you should revert both the moving base and rover to their default configurations in uCenter. Let the FC take care of the configuration by setting (or keeping) GPS_AUTO_CONFIG=1. There is no reason to do otherwise, and you will likely frustrate yourself by continuing to manipulate the settings directly in uCenter.

Next, and I’m not sure this will solve it, try taking the FC out of the loop between the F9P boards. It takes valuable processing time to pass RTCM3 from the moving base through the FC to the rover. It’s very easy to connect a pair of crossover data lines between the UART2 ports of the F9P boards, assuming you’re using breakout boards that have pins for that. Just connect the TX2 pin of one to the RX2 pin of the other, and vice versa. Then set GPS_DRV_OPTIONS=1.

[SpreadKnowledge]

Thank you very much for your advice!
Finally, the GNSS status of my Rover has become stable RTK-Fix.
I was outdoors today checking GNSS status and Rover stayed in RTK-Fix status for most of the day.

I finally understood the meaning of “GPS_AUTO_CONFIG=1”, which means that if I only plug the initialized ZED-F9P into Pixhawk GPS1 and GPS2, Pixhawk will automatically configure them for me.
I have been set my original settings in u-center and that seems to have been the main reason for not RTK-Fixing.

I’ll continue to keep an eye on it for a while.
Thanks to everyone who’s given me advice so far!

[ktrussell (Kenny Trussell)]

Man, that is awesome. And you know now that you have revealed a picture of your rover, we MUST know all about it! Seriously, I would be very interested. I need to build a relatively small rover to use to patrol for wild hogs on my property. I’m not sure when I will get to it, but I am soaking in whatever I can from others who are paving the way!

[SpreadKnowledge]

Thank you for your interest!

I originally created this Rover for the purpose of transporting goods in farmland.
This Rover is capable of carrying more than 20 kg of cargo in a container and can drive over weedy, uneven terrain without problems.
This Rover can be lifted up, but it is very difficult to perform compass calibration.
That’s why I was trying the MovingBase method, which does not use an electronic compass.

I believe that being able to realize Moving Base has greatly helped us with the hurdle of creating an autonomous Rover of medium size or larger.
I can’t thank the ArduPilot development team and supporters enough!

[ktrussell (Kenny Trussell)]

A man after my own heart! I am on a small hay farm and most of what I do with Ardupilot is related to automation on the farm. You are talking about my place when you say “weedy, uneven terrain!”

[SpreadKnowledge]

Thank you all for your advice and help.
I have been running my Rover in various locations since the other day and have confirmed that the GNSS status is always a stable RTK-Fix.

I will review again how to set up when I try the Moving Base method with two ZED-F9Ps.

Install the latest firmware for the ZED-F9P using the u-center application and restore all settings of the ZED-F9P to their default state. Then select the satellite to receive.

Connect the ZED-F9P, wired as shown in the following figure, to the Pixhawk GPS1 and GPS2.

Configure Pixhawk’s full parameter list based on “GPS for Yaw” documentation.

I learned that I don’t need to do any extra configuration in u-center because Pixhawk automatically configures the ZED-F9P by setting “GPS_AUTO_CONFIG = 1” in the full parameter list.

If you are interested in my MovingBase method Rover, please refer to my YouTube channel.
Thank you very much！

[ktrussell (Kenny Trussell)]

That should work! As an alternate you can connect the two GPSes together via a crossover cable using their UART2 ports (the comm really only goes from MB to Rover). Set GPS_DRV_OPTIONS=1 and Ardupilot will configure the GPSes to work this way.