RTK YAW-heading and Position - Fix Status

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.

Unhealthy GPS for Yaw

MB and Static

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.

Tom,
Welcome to the forum!

I believe you have captured everything perfectly (as far as my understanding goes,at least)! Great documentation, well presented. You certainly have done your homework.

I can answer, to some degree, your question about detecting the loss of RTK Fixed status on the MB. If you connect the MB GPS to the Flight Controller, you can read its status. You will see the status of both GPSes in the HUD and you can also see the status on the Status tab as gpsstatus2. So, you should be able to write a script to do whatever you wish when the status drops below 6. Or you could use a companion computer as you suggest monitoring this parameter over MAVLink.

From what I have gathered from others, using the Ardusimple Lite board piggypacked on the Ardusimple RTK2B presents a problem in that the UART1 port is not available to connect to the controller. I have used 2 Ardusimple RTK2B boards with good success. I made a video a while back documenting some experiments with the F9P GPSes. My setup on my autonomous mower is similar to yours in that I have the RTCM3 comm from a fixed base coming from a Raspberry Pi via the internet, but I am transmitting it from the Raspberry Pi to the moving base via a LoRa module. So, my raspberry Pi relay station is fixed for a given mission, but can be anywhere that the Pi can get to the internet.

The autoconfig in ArduPilot is now capable of setting up both GPSes perfectly so that you do not have to set them up in Ucenter. The only thing currently that might be a problem is that it hard codes the baud rate from both GPSes (UART1) to the flight controller at 230400 (this is no problem) and the baud rate for the UART2 on both GPSes to 460800. That is a problem for me because I am feeding the RTCM3 from the LoRa module in at 115200 on the input pin of the MB GPS UART2. The output pin of the UART2 on the MB is connected to the input pin of the Rover GPS UART2. So, I need them set up at 115200. I don’t think my LoRa module will support 460800. So, I compiled my own version with this one small change in the code so that it sets up the GPSes perfectly for me. Hopefully, a future release will allow these baud rates to be configured by the user.

In case you are interested in the video (rather long), it is here: https://www.youtube.com/watch?v=7r__F-nyKUA&t=2s. This was done before I modified the code so that autoconfig would work. I was using Ucenter to set everything up at that time.

Kenny

Thank you for the kind words, Kenny, I’ve been reading and re-reading your adventures. :slight_smile:

I mostly agree.

My understanding, however, is the FC wants to pull the Position and Heading from the Rover, which will show FIXED as the best GPS position.

Even with the second GPS attached to the FC from the MB, the FIXED Rover GPS will “win” and when the MB goes to Float (or 3D) I believe all of those status changes are ignored.

I thought about switching the MB to be the primary GPS, but I fear the Rover heading won’t be used from the “secondary” GPS.

If I opt to use the “best” GPS in that scenario, but use the MB as the primary, then when the MB goes to Float, I move to the Rover as Fixed and jump about 24" (in my case).

It’s icky. :smiley:

Using only the MB would solve that, but from statements I’ve read the FC only gets Yaw from the same GPS it gets the position from - so no yaw in that case.

Right now, it’s Yaw + Fix with no clue how good the absolute position is, OR you get position with 3D/Float/Fix with no yaw (use a compass)

UART1 can be connected to the controller via the Pixhawk connector on the Lite. It will monitor the RTCM stream to the Rover. 460k baud.

The other way to get this is via the secondary “XBee” USB connector on the main ArduSimple board - it’s UART2 on the big board, which connects to UART1 on the Lite.

Aside from the obvious weight advantage, there might be a cleaner signal using the piggy back, but for the size of vehicle we’re talking about, your dual RTK2B approach is the cheaper and just-as-good answer.

When I do this over, I’ll use two RTK2B boards. I’ll use some male-male breadboard jumpers to connect the Xbee/UART2 of both boards together.

Then you can, if desired, run the Pixhawk connectors to the FC.

And you can still use USB on both to the companion computer to feed RTCM or monitor statuses separately.

While auto-configure is nice, I do like the ability to tweak the RTK settings by using UCenter - I can change the minimum signal strengths and elevation angles to improve the RTK fix quality.

I started this project with a pair of LEA-6T boards and having the on-board Raspberry Pi 3B+ run RTKlib and feed the secondary GPS port with the output of RTKLib.

I found it very difficult to get a fix.
I moved up to M8Ts and things got better, but still frustrating (some of which might be challenges in getting a definitive fix on my base)
Finally, I bought two, and then a third F9P - after logging 24 hours of base station observations and getting a good fix for it, I now get RTKfix on the rover in seconds.

The multi-constellations of the M8Ts helped, but the L1/L2 receiver of the F9P also helped tremendously.

I’d still like to find an “F9T” at half the price that I could let the base-Pi do the RTKLib calculations for the RTCM3 stream, but I’m also at the point where I’m over trying to save $100.

As you might surmise, my goal is similar to yours - my approach is a little different. My rover is a wheelchair base, relatively unmolested.

My mowing solution is to tow a ground-powered old fashioned reel mower.

This also gives me the flexibility of replacing the reel mower with a broadcast spreader.

OTOH, trying to mow successive 14" wide strips is challenging.
(The next generation is to build a 3-gang tow-behind for 30+")

This is a very interesting case and one that I think I may have seen in practice (jumps in position despite fairly tight GPS solutions). In my case (rover mower with GPS-for-yaw), the jump would be nearly 3 feet, which would definitely alter a mowing path by a detrimental amount.

The thing is: the autopilot should be able to account for the antenna offset - it knows the antenna position relative to vehicle center. Without devising a rather difficult test of my own or digging into the code, it’s hard to prove whether the antenna position is indeed accounted for (making your observations anomalous). I know @tridge is very busy, but I’m hoping he can weigh in here.

Your workaround using the piggyback configuration was exactly what I was about to suggest, but you’ve already settled on that. Good work, and I’m looking forward to the resolution here!

thanks for the awesome information.

Thank you. I hadn’t considered that the rover might (even probably) account for the difference in location of the first and second GPS units.

That makes getting the X/Y locations critical when we’re talking about targeting cm-level accuracy with RTK.

I knew getting the short (moving) baseline distance within 10% was important for the YAW calculations, I hadn’t given things much more thought beyond that.

I have now taken a little more care to set the X and Y of the Rover GPS more accurately, and even though the flight controller doesn’t talk to my moving-base, I set the position of the second GPS more accurately as well (53cm instead of 50cm apart)

Beyond identifying that not knowing the MB is RTK Fix is a problem, I haven’t taken any further steps along that path.

I still think I could watch the stream from the MB and send a HOLD mode change command via MavLink (the Pi has a Mavlink connection to the Pixhawk) when it loses Fix.

I just have more pressing things to address first, which some of Yuri’s other threads have been helpful with - getting the turning radius and navigation tuning closer so my rover will rove along the proper path - right now it’s a little annoying to watch Mission Planner and see how accurately the Rover knows it is not on the line. :slight_smile:

(The good news is, it does know where it is - the GPS fix seems good and repeatable day after day and the Yaw is correct, it just doesn’t feel the same way about following the prescribed line that I do)

And i see now that 4.1.0-
Beta6 attempts to address my concern.

Now we can pull the position from the MB, and Yaw from the Rover, removing the additional error introduced by Base–>MB–>Rover- though the error wasn’t (yet) my concern, I think now we can discuss monitoring the MB for Float vs Fix and hopefully ignore the Rover for all but Yaw.

Which means I need to reconfigure so I can supply the flight controller with the moving base output…

Tridge really hit on my concern at the end of this post:

Tom,
You probably are aware of this, but unless something has changed, the precision is limited to around 11cm in Ardupilot. See the conclusion here: RTK and general GNSS inaccuracies

That’s not too much of a problem for most of us, but you mentioned cm…

Thank you, Kenny.

I found it interesting that while I gathered data (L1 & L2, GPS & GLONASS raws for 24 hours) and did post processing to fix my Base to 5 decimal points of Lat and Long, the F9P firmware only takes 4.

I had seen those references to the limits on precision - thank you for the reminder.

My current goal is overlapping tracks that would be covered by a 14" wide mower.

Knowing the limit is ~5-6" I may need to plan for a 50% overlap for good measure - but as long as I’m not doing the pushing, I don’t need to be too worried about how many passes it takes. :slight_smile:

I understand what you mean by “as long as I’m not doing the pushing.” I like to say, about my mower when it is meandering a bit, but getting the job done: “It ain’t pretty, but I ain’t sweating.”

I hope you achieve your goal. I think you have a substantial challenge to track within a few inches. I look forward to hearing more about it.

@ktrussell,

Thanks very much for pointing me at that discussion. I’m quite certain that AP can do 1cm accuracy or better.

@rmackay9, Oh really! That is great to hear. I hope that is right, just to eliminate one source of imprecision.

1 Like

thanks for the awesome information.