I’ve been searching about for a while on the “right” answer to both yaw and position.
I believe I’ve found the current answer.
So the “Rover” GPS is providing both YAW and POSITION under ideal circumstances.
When the Rover loses fix, the Moving-Base position is used.
This would cause a jump in position - in my case, of about 2’
It would allow an RTK fix to remain.
In practice, and per the F9P documentation, we can also get a good position fix (plus yaw) on the Rover by feeding RTCM from a fixed base to the moving base, which then passes better information on to the Rover.
[quote]Additionally, while an MB receiver operates as a base, it is able to simultaneously:
•
Apply RTCM 3.3 corrections and reach RTK fixed mode.
•
Generate an MB correction stream for accompanying MB rover(s).[/quote]
So taking position and heading from the Rover looks like a good choice.
In my case, it also means I can run a single GPS input to the Pixhawk from the Rover.
I can feed the Rover GPS RTCM data from the moving base via the Rover UART and Moving Base. I can then supply the Moving Base with RTCM data from my fixed base. There is a slight concern with compounded variances in position introduced by “fixing” the moving-base (against the fixed base) and then fixing the Rover against the (fixed) moving base.
The flight controller (Pixhwk) just sees a single GPS with RTK Fix and heading. Nice and simple.
I have this working.
What bothers me slightly is it is difficult to determine just how good the “fix” is on the Rover.
Before YAW, we could indicate that a drop from Fixed to Float will stop a mission - I might want to do this when the precision of my route is important.
But to use YAW, we need to have FIX on the Rover.
This indicates a FIX against the Moving baseline.
There is no indication that the Moving Base is itself FIXed against the stationary base. We are guaranteed good relative position against the MB, but not good absolute position.
(I can see the status of my MB by peeking at the output of the Moving Base)
Ardupilot, per above even in the default configuration, is only looking at the Rover unless it loses fix at which point the MB comes into play (and we “jump” 2’).
So, my post is partly documentation - yes, you can:
Run a fixed base, feeding RTCM over “some channel” to your Moving Base, which feeds the Rover, which supplies Ardupilot with both an accurate position AND yaw.
It’s also partly a feature request:
If you were to use the auto-configure and put both the Rover and Moving base on as GPS1 and GPS2, can GPS2 be monitored for FIX and an additional status be derived to distinguish between “GPS1 has FIX and is giving good YAW” versus “GPS2 has FIX, GPS1 has FIX and is giving good YAW AND a better (absolute) FIX position”?
The work around that comes to mind is to have the companion computer monitor the moving-base and send a MAVLINK command to change to HOLD when the MB is not FIXed, and then go back to AUTO when the FIX is restored.
(Short form problem statement: Delivering the RTCM stream from the fixed base can occasionally be disrupted - how do we account for that when we have a constant relative stream from the MB?)
(All of this, because the Large Vehicle Mag Cal hasn’t worked for me so I gave up on the compass - otherwise the RTK position-only was doing well)
My current setup that appears to be working:
GPS AutoConfig is disabled. I started with the ArduSimple published configurations for the Base, Moving Base, and Rover.
ArduSimple F9P base (24 hour samples calculated into a fix, set up as TMODE fixed with defined coordinates - interestingly the F9P setup in Ucenter supports one less decimal place than my calculated fix from post-processed CORS data) using RTKLIB’s str2str to broadcast the RTCM3 stream.
ArduSimple Lite F9P piggybacked on an ArduSimple board.
The Lite (Moving Base) is fed RTCM corrections via the top-side XBee header to a USB/TTL serial chip. 115,200bps UART2
The Lite feeds the main board (Rover) via the piggyback (UART1 from the Lite, 2 on the larger board) at 921.2k (change from 460k)
Then the main F9P feeds the Pixhawk via the Pixhawk connector (UART1).
I set it up so I can monitor the Moving Base’s fix via UART2, and I can monitor (externally) the Rover via the USB port.
A Raspberry Pi runs the rtklib str2str to both feed RTCM into the MB, and to let me monitor the output of both without involving the Pixhawk.
Wifi is used for the backhaul to the fixed base.