Finally Spilling the Beans on RTK GNSS


I’ve never seen an article giving actual RTK GNSS system prices and straightforward explanations of what’s important to build a robust RTK system. Hopefully this post saves the beginner some headaches:




For the beginner I would suggest to buy a Ublox M8P

1 Like

I’m excited about M8P too – any word on performance with tree canopies, etc?

Not really since I use it on a multirotor so I always fly over the trees.
In the next weeks I should start to work on a rover .

What is interesting in the Tiny M8P from Drotek is that it is really small and easy to integrate with Ardupilot in Mission Planner, using the Inject method you share the same telemetry you already have to send RTK corrections.

Just connect the Base M8P with a USB cable to your Pc and the Rover M8P to GPS port on the Pixhawk with a cable , Mission Planner 3.5 will configure the M8P .
Really simple.

Yes I wouldn’t be surprised if you get good performance with an M8P up in the air without many obstructions.

All of us building these kinds of robots are wonderfully fortunate that Tomoji Takasu decided to open source an RTK library years ago. The companies that picked up his work put pressure on u-blox to roll their own RTK product, and u-blox working on RTK is very appealing thought.

Here’s something I often think about: Lidar is an amazing technology that several companies are presently racing to solve both for performance, reliability (solid state) and cost of production. RTK GNSS, on the other hand, is effectively a solved technology (via L1/L2 Multi-Constellations systems). When I say “solved”, check out the pictures of my back-yard 60mx30m robot testing grounds this morning:

So, I don’t know how much perspective those pictures give you, but there are trees everywhere.

I run missions with the ComNav k501g day after day, and rarely lose an RTK lock. Have you ever seen an actual RTK user post that kind of claim about an L1 RTK system? Let me push a little more: if any L1 manufacturer reading this would like to compete with the k501g in the environment pictured above, just ship me your product and I’ll be happy to post the results.

If you read forums of guys using L1 RTK, you may pick up on a lot of angst. If you read forums from precision ag farmers and surveyors, they can’t stop raving about L1/L2 RTK. They act like it’s some kind of miracle. After working with the ComNav, I’m with the farmers.

So, RTK is effectively solved, but did you ever see an article pointing that out to the beginner?

You mentioned Mission Planner’s RTK inject – I’ve used it too and it’s a wonderful feature. Michael Oborne, in addition to writing the outstanding Mission Planner, wrote the Novatel/ComNav driver – it works great.

Hey, we should all rejoice – those of us using these technologies are reaping the rewards of amazing companies and amazing teams like the Ardupilot developers.

OK, let me start by saying the L1 RTK (based on the open source rtklib) is probably not perfect But it helps;-) I’m running a setup with two NEO-M8T’s (base station with a RasPi3 and rover with a Odroid U3 which also works as ROS/companion board to a Pixhawk. The M8Ts + two Tallysmann antennas cost me about $300. So it’s still way cheaper than a L1/L2 system.

Three pictures from the weekend:

In the say image, the GPS & GPSB tracks are NEO-M8Ns with good GPS & GLONASS configurations. The GPS2 track is my rtklib + NEO-M8T which tries to do RTK on GPS & GLONASS (It mostly reported a RTK float lock). In addition to the visible trees, there are some power lines overhead and some chain-link fences.

Smaller map of the same run but with the # of reported satellites for each receiver. The RTK setup reports lower numbers because those are the ones seen by both, the base station and the rover (the 0 in the end was actually the U3 turned off already).

The HDOP reporting for all three. The rtklib does not report less than 1.0 in it’s NMEA sentences:-(

I’m just a hobbyist combining things to make them work;-)

And just to answer the question, why would you want to drive a rover in such an environment in the first place, This was the course of the RoboMagellan event @ RoboGames 2017. The link to the onboard video of that run is here:

mw46d – that’s a slick setup – thanks for sharing! Hey, to make sure I understand, are you running RTKLib on a U3 onboard the Rover (and feeding RTKLib’s output from U3 into pixhawk)?

Yes, that’s the current way.

mw46d, from my experience, L1 or L1+L2 depends on what the working scenario is and what kind of result you want. Beside, the baseline length will also affect the rate of fix solution for both single-frequency and dual-frequcny.

For a rover, trees, power lines and buildings are the biggest problem. Since it’s so low on the ground, there is much more in the way than for a normal drone.
I don’t think, the baseline was a big factor for me. The base station was sitting on my car, clear sky, no trees & no power lines and the distance was always << 500m for most of the runs even < 100m.

OK, I see. Single frequency RTK can get fix not so difficult with such a short baseline, but indeed, trees, power lines and buildings are the biggest problem for single frequency.

Even with dual frequencies, tree, building and powerlines are problem. It’s not related to single frequency …

Thanks for the excellent writeup. Where I work, we have Piksi, Piksi Multi, Here+ and TinyRTK.

Piksi mostly works, most of the time but I personally wouldn’t trust it on an aircraft. It occasionally seems to almost get distracted by a shiney object and it stops sending position updates to the flight controller which causes the pixhawk to act as if the Piksi just fell off the aircraft for a few moments until it restarts sending position updates.

Piksi Multi seems to have a lot of difficulty pulling in signal. A M8N will easily outperform the Piksi Multi unless you’re in an open field and then the Multi will probably get RTK Fix. The Multi is HUGE and heavy and thus far we’ve only been able to get it to work with the correction radios included with the dev kit which are also large and akward to install. We briefly tried to get injection working over MAVLink but with no success at all. I actually have a few helical Harxon antennas coming and we may try to put the Multi on an aircraft. Thus far, we’ve only been testing it on a UGV since the pile of boards and cables is just so ridiculously big akward and heavy. It honestly looks more like a prototype than a finished product.

Of the M8p based systems, the TinyRTK is my current favorite but it seems to have some strange characteristics. When operating in GPS + GLONAS mode, it seems to be only able to send RTCM correction messages on a regular interval for one of the two constellations. It also seems to regularly drop GPS and/or GLONAS lock at a regular interval despite very good satellite signal strengths. The M8p goes into RTK Float very quickly but after messing with it for months, I’ve only seen RTK Fix 2 or 3 times for a very short period of time. In my experience, it seems to do better if you set it for a single constellation (GPS or GLONAS) and use SIK (or similar) radios to directly send the correction data. My gut tells me that either the firmware on the M8P needs to be optimized and debugged or the onboard processor is just too slow to do the math. I hope to do some more testing later this week and hopefully, finally figure out just what exactly is going wrong with it.

I don’t care for the Here+ at all as the rover can’t use an external antenna and the inbuilt antenna performs very poorly. A TinyRTK with the small Tallysman antenna will easily pull in 15db-hz more signal with far less noise. Also the lack of easily accessible USB/Serial out on the rover and base makes troubleshooting the system close to impossible. For my testing, I ended up loading the rover firmware on a second base Here+ and soldering in the serial connections myself. I’ll probably end up installing the Here+ rovers I have on aircraft to use them as expensive standard GPS units.

For what it’s worth, I’ve also seen an Applanix APX-15 UAV (Trimble) system work and it is phenomenal however I was able to find out that it is $9k-$18k per system depending on quantity, etc. It produced ~1-2cm results in an area that I seriously doubt the Multi would have been able to get a fix or even GPS lock in.


Been flying with a Septentrio AsteRX for several months. Started out with an antcom G5-1.9 antenna, which requires a 5 inch ground plane. The antenna was a bit heavy and the ground plane was bulky, so we swapped it out with maxtena helical antenna. Much lighter and no ground plane required. Simple to integrate with the pixhawk, virtually plug and play Performance seems to match the ant G5 with ground plane.

I have access to a state wide VRS network, which we use for the correction. Send the correction with Mission Planner through the telemetry radios. Goes to a fixed solution within seconds of getting the RTCM message. Rarely do I lose a fixed soluion once aquired.

This a great product if you need consistent cm level accuracy. I recognize it’s several times more expensive than the L1 solutions mentioned here, but for me it’s a necessary and worthwhile investment.

I wish we had a state wide VRS network here… :-/

Today, I finally saw the M8p going in and out of RTK Fix. I suspect there was very little interference today and probably just a little bit of dumb luck.

All the same, I’m looking into the ComNavTech k501g.

Since writing this article I’ve been able to spend ~50 hours with the M8P (via the version D dev kit). M8P’s performance is very impressive.

At this point, IMO, you’ve got 2 solid RTK options:

L1 GPS/GLONASS 5Hz ~$200/unit USD – u-blox M8P
L1/L2 GPS/GLONASS 10Hz ~$900/unit USD – ComNav K501G

A few years ago, we could have only dreamed of those options at those price points.

It’s likely difficult to overstate the applications and markets that are just now opening up.

1 Like

I too used the piksi and it showed the same symptoms you mentioned. I currently use the emlid reach and it’s serving me quite well without any issues at all. I have used it on an XUAV talon and the RTK status is very consistent.

For what it’s worth, a guy in our lab found a few bugs in the Pixhawk’s Piksi drivers and I think he may have also found a bug somewhere else. Either way, after we can test this some, the Piksi may be slightly closer to working correctly.

The Here Base can be used as a Rover, so any antenna choice can work.