I have a pair of ZED F9P boards from SparkFun that I would like to use for yaw. This is apparently supported by the latest versions of Ardupilot. I found the Ardupilot doc describing the setup and parameter settings, but the description of physical connections is fairly terse and, to me at least, ambiguously written.
What I think is intended is
unit1: UART1 to GPS (Serial3) on the Cube
unit2: UART1 to GPS2 (Serial4) on the Cube
But most discussions of moving base RTK I have seen also describe a separate physical connection (I2C or UART) directly between the two GPS units to pass correction data, but this isn’t mentioned on the aforementioned page. Is RMTC data passed between them through the Cube along the same serial connections? And has anyone here successfully used the ZED F9P with Ardupilot for yaw?
Your first description of the connection is correct and the simplest way to achieve what you want. There is one uart from each module connected to each of the GPS and GPS2 serial ports. In this case, the corrections from the base module are relayed via the Pixhawk to the rover module and there is no requirement to directly connect the GNSS modules.
The other method whereby you connect the two GNSS modules directly for the purpose of transmitting RTCM data is also possible but requires a different configuration on both the Pixhawk and each F9P
Partly with the help of of your reply, I seem to have gotten it working; the end of three-year learning process (there weren’t any quasi-off-the-shelf solutions at all when I started, as far as I know) .
I assume the displayed status (GPS: 3D Fix, GPS2: rtk Fixed) is correct for this mode of use. It’s hard to be completely certain that the yaw info I’m seeing is entirely from the GPS units, because the IMU also sense rotation. I do think I have successfully turned off the magnetic compass, and the orientation is correct.
Looks good. A sure fire way to know that the GNSS heading is being used is to orient your setup approximately south and reboot the Pixhawk. After initialisation you should see the heading jump to ~180 degrees. If the GNSS heading is not being used then it will stay somewhere around zero degrees. This assumes that the magnetometers are disabled.
Yes, I tried that and found that the direction would drift around for a while as long as it said “rtk float”, but when it switched to “rtk fixed” then it would also quickly display the correct direction.
I have successfully implemented moving base RTK yaw, and I have a follow-up question:
The only mag compass is now is the one in the Cube Orange. It’s on a large fixed wing airframe, so it’s hard to calibrate manually. I would like the RTK yaw to be the primary reference, but I would like it to fall back to the one mag compass if the GNSS lock gets lost. I understand that I can do this with EK3_MAG_CAL = 6
My question is whether setting COMPASS_LEARN = 3 will cause Ardupilot to directly use the RTK-determined yaw to learn the compass offsets. This would be the ideal solution if it works.
