Hi folks, I’m setting up a UTV for waypoint navigation and am completely stumped on how to get decent heading data for it. I have a Cube Orange, a u-Blox Zed F9P Sparkfun GPS breakout, and a LIS3MDL external magnetometer. The magnetometer is unreliable and I can’t seem to get an RTK fix out of the F9P, or else I would be tempted to try setting up GPS yaw. Using the mag or GSF for yaw, the vehicle can find its way slowly but accurately along a waypoint mission if given an initial heading that’s close to accurate, but over time, the yaw drifts until the vehicle icon is crabbing sideways on the ground station map and the PID integrator terms wind up to max. Is this a lost cause? It seems like if the vehicle can find its way from point to point, it must sort of ‘know’ its heading just from the GPS path… so why does it keep drifting? Any advice appreciated.
Test first the GPS with u-center. Do you get RTK float/fixed? Try to test with low HDOP.
Note here that the car finds its way correctly (simply compasses, no GPS yaw) even oriented initially the opposite way. The trajectory is followed reasonably well with RTK float almost all the time (surrounding trees, podium shadowing).
I don’t know… Which of the RCTM3 messages should it send? And how do I tell what messages it is actually sending? I’m telling u-Center to write the config I want to flash memory, but if I unplug and replug the board, the values in the configuration view are all back on the default settings. I’m not sure if that’s just what the config view does, or if it’s not saving. Thus far, looking at the module directly with u-Center outside, 3D fix has been the best I’ve got.
I’ve tried to load the 5Hz rover/moving base configs from here: Configuration Files - ArduSimple Should that in theory provide the appropriate messages for RTK fix and GPS yaw with Ardupilot? And on the Ardupilot configuration, should I leave the ‘autoconfigure GPS’ parameter on or off after writing the config through u-Center and setting the GPS type params to 17/18?
Also, I don’t have two F9Ps, but I have got an F9R lying around - would that work (without serious additional headaches)?
Are you connecting to an NTRIP server? The F9P is RTK capable, but it needs a source for corrective data, which is sent to the module by way of RTCM3 messages. It won’t get an RTK fix by itself.
Do yourself a huge favor and get out of uCenter. Connect your GPS to the autopilot, use GPS_AUTO_CONFIG=1, and leave it that way.
I’ve never used an F9R, but I don’t see why it won’t work as one of the modules in a moving base configuration.
Having an RTK fix on the moving base is not a prerequisite for GPS yaw. With two modules, the moving base will generate its own RTCM3 messages to send to the rover, and the rover will then pick up an RTK fix relative to the moving base and begin sending heading information.
As it turns out, the local NTRIP server was down yesterday and I never thought to check that! Explains a lot. Today, both modules get an RTK fix no problem, as reported by u-center and mission planner. I’ll get another F9P on order but in the meantime, I’ll try setting up the F9R as the rover.
Good to know on the RTK fix. I only have one nice GPS antenna at the moment - so I should configure the GPS with this antenna as the moving base, and the other one as the rover?
You need two antennas. Do not power the module without an antenna connected. But if you are suggesting that you have another “not nice” antenna, then use it for the rover for now.
So I put everything back on the vehicle and I’m back to a 3D fix on both GPS’s (yes, they both have antennas, one is fancy) even with NTRIP connected. I’ve tried setting GPS_INJECT_TO to the base or to both and it doesn’t make a difference. Both GPS’s are mounted on top of the vehicle and have a clear view of the sky. Each one can see 18-20 satellites as I’m driving around – should that be enough? (This is with GPS_AUTO_CONFIG =1, if it’s zero the Pixhawk can’t find the GPS’s at all.) I’m getting an EKF error (below) so GPS yaw is definitely not even trying to work… But I’ve got no idea why not!
Maybe also worth noting that the F9R is spamming Mavlink with weird error messages: “Unexpected state 33” or 35, once a second. Annoying at best. But the F9P doesn’t get an RTK fix if the F9R is disabled or disconnected.
Edit: I think the issue IS the location on the vehicle. I had them bolted to the sides of the UTV’s little pickup truck bed, and when I moved them to the top of the roll cage, at least in U-center they got a fix. Time to break out the duct tape and zip ties…
Edit 2: Well, with the GPS’s zip-tied to the roll cage, I’m up to 25 satellites, and I can get an RTK fix when connected directly to the modules via USB in u-center, but not through the Pixhawk to mission planner. Now I’m completely stumped. This is what u-center is seeing for the status of the F9R in its new location:
Please just leave GPS_AUTO_CONFIG=1. I promise it will save you a ton of headaches.
Let’s solve one thing at a time and get the moving base configuration correct first. Your parameters look reasonable, although you have the GPS types backwards from the usual configuration (usually the moving base is the first GPS available). I recommend using the F9P as the moving base (type 17) since the F9R is causing some errors anyway.
When you say the F9P won’t get an RTK fix if the F9R is disconnected, that’s a good thing. It likely means that RTCM3 is being successfully passed through the autopilot for the moving base configuration.
Are you certain that the GPS_POS* measurements are correct, particularly after moving the antennas around?
Also, take a screenshot of the MAVLink inspector (Ctrl-F in Mission Planner, right column, 5th button down). Expand the selections to get the full output of GPS2_RAW.
Yep, I updated the positions - at least the Y axis positions, and left the rest zero. The F9P is GPS2 and the moving base… I think. It comes up as GPS2 even when it’s the only GPS, maybe just the physical port its plugged into? I don’t think this has changed, although anything is possible. I’m not sure this is a useful test, but neither GPS is getting an RTK fix reported by Mission Planner when both the GPS_TYPEs are set to ‘auto’ or ‘ublox’ either.
Also, something about moving the F9R to the roll cage resolved its constant spamming of vague errors.
Well, you’ve got GPSs assigned to SERIAL2, SERIAL3, SERIAL4, SERIAL5, and SERIAL6 - that might be part of your problem. Set SERIALx_PROTOCOL=0 for any unused ports.
Also, you have non-zero X and Y positions defined for your GPSs where it seems your intent was only to use Y position offsets.
GPS2_RAW.yaw = 0 means that your moving base configuration is not quite configured correctly. Re-check your position offsets and eliminate those serial protocol errors.
Okay, I set the unused ports to protocol 0. The F9P is plugged into the port labeled GPS1 but it comes up as GPS2 for some reason. The F9R is plugged into Telem 2 and comes up as GPS1. Does the baud rate setting matter for these ports? I see in the message log ‘GPS1/2 detected as u-blox at 460800 baud’ so I’m guessing it doesn’t if the GPS autoconfig setting is enabled?
I had to take the system off the vehicle to verify the ports, so I put it all in a cardboard box and carried it into the parking lot. The F9P (GPS2, nice GPS antenna, base) was reporting RTK fixed, but the F9R (GPS1, random antenna from supply closet, rover) was still saying 3D fix. This was the case both with GPS_INJECT_TO set to GPS2 or all. Is that to be expected?
I stopped getting an EKF warning on the Mission Planner GUI, and the gps_yaw value reported by Mavlink changed from 0 to 65535. I did change the GPS position values to reflect their positions on either end of my cardboard box, but the box is small, so I wouldn’t be surprised if the position is causing an error.
That said, it was getting yaw values from something, even though I set all my COMPASS_USE and COMPASS_ENABLE params to zero and EK3_YAW_SRC to GPS. Does it automatically fall back to the compass or GSF if the GPS yaw is bad?
I’ll reinstall the system on the vehicle, re-measure, and report back.
I’m as confused as you by the way the GPSs are ordered, but that’s of no real concern
SERIALn_BAUD is inconsequential with GPS_AUTO_CONFIG=1
The fact that the rover GPS is reporting RTK Fixed regardless of your NTRIP data is a GOOD thing! The F9R is sending corrections to it successfully.
For your present configuration, use GPS_INJECT_TO=1
65535 is a step in the right direction. That effectively means you have a configuration that the autopilot accepts as correct, but it isn’t reporting yaw (yet)
What you’ll likely see with no functioning yaw source is that the autopilot will initialize assuming it’s facing north (yaw=0). GSF will provide updates from there if the vehicle is moved/turned.
Fix up your measurements, install on the vehicle, and allow plenty of time to initialize. Sometimes it takes a minute or two for everything to align. Watch for EKF3 IMUx yaw aligned and EKF3 IMUx is using GPS in the messages.
Installed everything on the vehicle, drove it into the middle of a big field, and I’m back to a 3D fix on the F9P and 3D dgps on the F9R, and gps_yaw = -1. I don’t understand this at all…the F9P was just reporting RTK float inside a building! They’ve got 20 and 28 satellites with the NTRIP injection going to the base/F9P, which is better than they were doing in the office - but no RTK fix. Is it possible that this is a Mavlink/radio problem? Annoyingly, I can’t plug directly into the Pixhawk via USB when it’s on the vehicle because it’s in an enclosure, so I’m stuck ‘talking’ to it over the data radio. It really should have adequate range and throughput for this, but still–that’s the biggest difference I can think of between my setup right now and the one that I carried outside in a cardboard box.
Disconnecting from the NTRIP server on Mission Planner doesn’t appear to make any difference out here in the number of satellites or any other value that I can see in the Mavlink data graphs. Is there any way of verifying that it’s actually working?
Again, one thing at a time. Let’s get the moving base correct first, then add NTRIP. Make sure SERIALx_PROTOCOL=2 for your telemetry port, stop trying to inject NTRIP, and see if you can at least get GPS yaw to report correctly.
The F9P was reporting RTK float because the corrections on the rover GPS come from the moving base. That is separate and distinct from the NTRIP injection problem you’re having. And I would like to isolate the problems. So disconnect from the NTRIP server for now.
Once you’ve done that, provide a .bin log of the results.
Sorry, I should’ve specified to set LOG_DISARMED=1 before asking for that log. Still, things aren’t quite adding up. Are you sure the GPS position offsets are correct? It almost appears as if they might be oriented on the X axis rather than the Y because of the way they swap positions as you drive.
Also, I think you are arming the vehicle too soon. You get an AHRS active message after disarming, which tells me that it wasn’t functioning during your drive.
Also, your GPS_INJECT_TO parameter is set to 127. Again, it should be 1 for this config, and you should not be trying to use NTRIP while troubleshooting for now.
Today, both modules get an RTK fix no problem, as reported by u-center and mission planner. I’ll get another F9P on order but in the meantime, I’ll try setting up the F9R as the rover.
