Yep, GPS2 is up higher. gps_yaw_bed1_rollcage2_portnumsfixed.param (15.2 KB)
…Ha! As soon as I wrote that I realized positive Z is down. So there is a height difference, but it’s wrong.
That’s probably the problem. The measurements need to be within about 10% or you will never see an RTK fix on the rover.
Fixed the sign, saved, rebooted, status unchanged. That would have been far too easy, I guess! 
Let’s try this for debugging’s sake:
- Move the lower antenna up to the level of the other so there is no Z difference.
- Measure the raw distance between the antennas (diagonal across the frame).
- Set the parameters as follows:
- GPS_POS1_X: 0
- GPS_POS1_Y: (negative half the raw distance)
- GPS_POS1_Z: 0
- GPS_POS2_X: 0
- GPS_POS2_Y: (positive half the raw distance)
- GPS_POS2_Z: 0
Again, reducing the variables and just trying to see if we can get something to happen! I know you had good communication through the autopilot before, when the antennas were not on the vehicle, NTRIP was not active, and you saw RTK values on the rover.
Confirm also that the F9P module is connected to GPS1 with the F9R as GPS2?
And do you have the datasheets for the antennas you’re using? Since they are different, the phase centers may vary, further complicating your Z axis measurements.
Unfortunately I know nothing about the antennas–currently. I’ll see if I can track down any info.
I changed the mounting and the config as you suggested, but same old, same old on the status.
Based on my general level of cluelessness with regard to the NTRIP stuff and also my longtime confusion about the GPS ordering, I am doubtful that I ever did see an RTK fix on the rover GPS relative to the base GPS. I certainly haven’t in recent memory.
I’m not ready to give up yet. If you’re willing to get back into u-Center, let’s revert both modules to default and save that.
On the right side of the toolbar, you’ll see these three icons.
Click the far right one with the red dot. Then click the left one to save.
Then reconnect them to the autopilot and see if that makes a difference.
@tridge, are you aware of any reason why an F9P moving base and F9R rover combination would fail?
They should be in their respective default configs already, annoyingly! I reset them to the defaults when I updated the firmware last week.
Bad news is I’m out of time on this project and really should just write it up as-is; good news is that with the configuration changes @Yuri_Rage suggested, the GSF yaw estimation is now pretty darn good. I don’t have any more AHRS or EKF warnings, and as long as I briefly drive it around in manual mode first so it can ‘get its bearings’, the vehicle can go thru a longish waypoint mission without wandering or starting to believe that it’s crabbing sideways. I’m hopeful that I’ll get to revisit GPS yaw for an upcoming project, using two F9Ps and identical antennas. I’d love to see it work!
2 Likes
@rmackay9, Yuri’s comments did trigger my thoughts about one area that I think would be worth mentioning in the docs:
When GPS for Yaw is “selected” by setting GPS_TYPE=17 and GPS_TYPE2=18, the serial baud rate parameters are ignored and instead the baud rate for the serial ports on the flight controller and the F9P serial ports are set to 230400. It just might be helpful to note that.
And @Yuri_Rage, one (or more) of my YouTube videos fits in the category of presenting more complexity than necessary to get the F9P GPSes set up. For a long time, I thought I had to configure my GPSes in Ucenter because the serial port on my RTCM3 telemetry radio could not run at the 460800 baud at which Ardupilot configures the UART2 ports on the GPSes. But, it turns out it can run at that rate, so full auto config from Ardupilot works a treat. I need to make a note in the video descriptions to that effect.
1 Like
@Yuri_Rage , do you think it would make sense connecting:
- Moving Base to Telem1 (serial1)
- Rover to Telem2 (serial2)
- SiK to GPS2 (serial3)
My current connections are
- Moving Base to GPS2 (serial3)
- Rover to Telem1 (as suggested by Josep, not sure why though) (serial1)
- SiK to Telem2 (serial2)
but on bootup FirstGPS and SecondGPS seem to be swapped and Rover ends up on the FirstGPS.
And for GPS1 I simply have no cable, d’oh…
I’d do:
Moving Base: Telem1
SiK: Telem2
Rover: GPS2
There was a DMA sharing issue between SERIAL1 and SERIAL2 a bit ago, and I’m not entirely sure of the resolution, but this will avoid it for your more critical connections.
Also, JST-GH connector kits are pretty easy to buy on Amazon or from any of the other “usual suspects.” It’s worth having some so you can make cables.
Well, after a few months break, I am back with the same problems. When I try to use GPS yaw, it falls back to the internal compass, and I see gpsyaw status = 0 and gpsyaw1 status = 655.35. The GPS’s can each see 20+ satellites and fix type has been 3D dgps or RTK Float. This is basically the same behavior I was seeing back when I was testing with an F9R and an F9P on the actual vehicle. I had hoped that switching to identical receivers would help, but it looks like no such luck! Any thoughts?
This is the setup I am testing:
- Pixhawk Cube Orange with Rover 4.1.5 firmware
- Two u-blox ZED-F9P GPS’s with firmware version 1.13
- A plastic lab cart with a GPS receiver taped to its “bow” and “stern”, 1m apart, and the Pixhawk in between them, facing forward. GPS1 is in front, GPS2 is in back.
Here’s the current parameter file and a log of a recent test, pushing the cart and my laptop connected to the Pixhawk via USB around the parking lot.
cart_config_2.param (14.6 KB)
https://drive.google.com/file/d/1sgxMYqyXnifXigAA4QPXEYKo2PaDlLcs/view?usp=sharing
You are using EKF2, but you need to use EKF3 for a moving baseline configuration.
Set parameters as described here:
GPS for Yaw (aka Moving Baseline) — Rover documentation (ardupilot.org)
Thanks! Enabled EKF3 per the docs, but results are the same. Looking at the GPS tracks from the log, the two GPS’s don’t track each other very well. What antennas are folks using?
If you’re using ArduSimple hardware, the square magnetic mount antennas they ship with their kits work perfectly fine. I prefer the survey grade antennas (usually round with a white dome top, about 15mm in diameter) and get slightly improved reception with them.
20+ satellites in view should be more than enough to get results.
Hmm, I definitely am able to see 20+ satellites with the random antennas I have (this attached to GPS1 GPS15MGSMA Laird Connectivity | Mouser and GPS2 has the GPS antenna off a Persistent Systems MPU5) but even so, and even with NTRIP, the offset between the tracks seems wrong and the GPS yaw value never updates.
Latest log and params:
https://drive.google.com/file/d/1Hp6DDTXB_Hhf7JyaL8t_OJLHR-Nbcfu-/view?usp=sharing
cart_config_3.param (15.0 KB)
The mismatched antennas might be causing some issues.
It was the same deal with two of the MPU5 antennas… but I know nothing about them so I figured I’d see if the other one got a better fix. It doesn’t noticeably, so I’ll swap it out again.
For GPS yaw, does it matter whether the antennas are mounted left/right of the origin vs fore/aft? They are fore/aft at the moment.
Also, I’m not seeing the rover module ever get an RTK fix. Why might that be? Rover is connected to the GPS2 port while the moving base is on GPS1.
Edit - major progress. I connected UART2 Tx on the base to UART2 Rx on the rover, set GPS_DRV_OPTIONS =5, and managed to do a lap of the parking lot with gpsyaw2 reflecting the actual heading. Hurray!
Still not sure why my GPS’s are so reluctant to get a good fix even when they can see 20-30 satellites, but that’s a problem for tomorrow. Also, what is gpsyaw vs gpsyaw2? Thus far gpsyaw has always been 0.
Ok, there’s some progress!
Antenna orientation doesn’t matter as long as there is enough distance between them, and the positions are correctly set.
On a dual F9P config, GPS2 is the rover, so yaw is reported by it, thus the gps2yaw moniker. With other modules, yaw can be reported by GPS1.
You should just be able to set GPS_DRV_OPTIONS=1 rather than 5 if UART2 is in use. You may get better results than forcing a slower baud rate.
Also, you might try connecting both to uCenter, reverting to default, and saving that config to each F9P’s non-volatile memory. That way you know the auto-config routine from the autopilot is starting fresh, which is sometimes helpful.
I have no idea why you are having so much trouble without using UART2.
(I have not reviewed your logs and can look at the rest of the parameters later - I don’t have access to my usual development machine at the moment).
1 Like
Thanks Yuri! I loaded the default configs on the F9Ps (they were probably like that anyway as they were brand new, but now I’m sure) and switched to GPS_DRV_OPTIONS=1. Performance was about the same. I did manage to rustle up some better antennas and those made a big difference - they also came with long cables, which let me put the two F9Ps right next to each other and shorten up the UART cables, which might have helped as well.
At this point, I’m going to graduate my setup from the lab cart and experiment with some different mounting locations on the actual vehicle. If the antennas are above the minimum distance spacing–I believe 30cm was listed in the docs–is it best to place them as far apart as possible, or does it not make any difference?
Edit - vehicle having some issues, so I ended up testing with the antennas zip tied to the roof rails of my hatchback (1m apart), driving around the neighborhood. It’s rock solid. GPS yaw looks to be active 95% of the time and when it does drop out (briefly, under tree cover), the yaw doesn’t go haywire even if I turn a corner. Guess the EKF is doing its job! I’d like to test the limits of that eventually - if I were to go down a winding, tree-lined b-road at low speed, would it get confused? But I couldn’t find anywhere to test this - or at least, nowhere my car could be expected to return from under its own power.
After further testing, the GPS yaw is great most of the time, but there have been some minor issues - sometimes on startup the rover doesn’t get an ‘RTK Fixed’ status even when the base has one. Ditto for when the vehicle emerges from tree cover - the base will get its RTK fix back almost immediately, but it takes the rover much longer. Shouldn’t the rover be reporting RTK Fixed whenever corrections are being sent successfully by the base?
I also tried setting GPS_DRV_OPTIONS = 0 again, which works now that the receivers are right next to each other and the UART cables are short, but it wasn’t an improvement over using UART2. Any ideas on how to debug this?