Cheap 1-2cm (scale) accuracy for your surveys

3689647403?profile=originalImage: Topcon RTK collecting survey points

High precision GPS systems are getting more known and used and RTK is already becoming a familiar acronym. This post is about the use of RTK for collecting ground control points to be used in high quality survey results, not about RTK for navigation use (that's a lot harder). What I was looking for is a method to collect about 5 control points for surveys in a way that is cost effective, but also doesn't cost me a lot of time. I'm working in the tropics, so standing 30 minutes in the sun and dust is a real chore and not very comfortable. Here I describe how I do this using low-cost L1 GPS modules that cost ~$50 each with an additional ~$150 for a recording device and a good antenna.

If I were to use the above RTK station, I would get really good accuracy (L1+L2), but I would also spend > $20k that I'd have to recover from business income and I'd have to spend 5-10 minutes per point to get an accurate fix, since I only had one station. With many modules you also depend on a proprietary radio link, so you'd eventually have to buy two if you need to set up your own reference station somewhere.

First, let's consider there are two kinds of accuracy:

1 Absolute accuracy; the difference between measured and actual coordinates of the point in world space.
2 Relative accuracy; the difference between measured and actual offset of one point and a reference point in the survey area.

The second characteristic by itself is already extremely useful for high precision volume and distance measurements. All professional surveys have this characteristic, which is essentially the characteristic of correct scale. Absolute precision is only really needed when you want to exchange this data with other systems and/or use different data sets together (now and in the future). The absolute accuracy of a data set can always be improved after the fact by simply applying a unique global offset to all the data or control points in 3D coordinates (meters, inch, whatever).

In this approach, we're going to store the raw observations in a file to be processed together at a later point in time. RTK GPS has a plethora of online discussions and examples where you require some kind of radio or wifi link between modules, but this is not actually a prerequisite of the technology. Having files is much better, because you can work out the exact configuration and settings in the office and so you won't make any configuration mistakes in the field. Also, a radio/wifi link is extra interference for your uav and not to forget the GPS module itself and if those links drop out for a reason, you lose all the data and have to come back again.

What you record is raw GPS output data, straight from the module, so there's little that can go wrong. You get the best results if the frequency for all modules is equal, because sometimes the tools get confused if there's an output frequency mismatch. Since modules are set up as static, I just set this frequency to 1Hz for all modules. I myself purchased some ~$50 modules (NEO-6T from emlid), put them in the field with any device that can read the modules (uart/usb) and record the data to an HD, SD, etc. If all modules were recording in the same time period, you can post-process the raw GPS logs from the comfort of your office.

I use RTKLIB to do all that:

The process is:
1. select the dataset to be used as reference, call it REF
2. convert that to RINEX. Make sure to use the correct data source format.

To get high accuracy absolute positions from the field if you do not have an accurate reference yet, you can use PPP to derive it's position. This will give a higher absolute accuracy than a cellphone:
3. download the "SP3" file from the IGS data repository (available 3hrs-24hrs after the survey): ; (available 3-24hrs later).
4. post-process the reference point REF using "PPP static", "Precise" solution, "Iono estimate" and "ZTD estimate" and select the SP3 file together with the NAV and SBS file using rtkpost.exe. You can also use the CLK file, but in my case it actually hurt results. Some more research there is needed.
5. if you have ~30 mins of data, the processed solution should be accurate to about 70cm (absolute) and probably is better than a meter. If you need better accuracy, the only way to get this better with PPP is to keep the module longer in the field (6-24 hours). After that, it's very much a black art which gives best results, but some people report you should expect ~10cm. That's not 1-2cm for the relative accuracy.

6. Use either the calculated position or the one from your cellphone. Let's call that REF.
7. select the dataset (one of the other modules) to be used as "rover", let's call this ROVER here.
8. convert ROVER dataset to "RINEX" data format using the rtkconv.exe program. Make sure to set the right source data format (of the source file).
9. then use rtkpost.exe to post-process both files, applying the settings you'd use in rtknavi.exe and process away. You should insert the position from REF in the "antenna position" now in the settings dialog and use "static" as the mechanism for post-processing, probably with "continuous" instead of "fix and hold".
10. Eventually there should be a fix for a long period of time. You can then average that out or see how much the variation is and not bother further. It should be 1-2cm when modules were not far apart.
11. Repeat from 2 for the other modules.

This method is cost- and time-effective. With 5 modules, you'd spend $1000 (raspi+GPS+good antenna ~= $200) to be able to measure 5 control points at the same time without waiting 5-10 minutes for each one. You can drop them in the field prior to a mission, turn them on, walk back and execute the uav flight. If that took about 30 minutes to complete, you can already retrieve the modules and go back to the office for post-processing.

Here's a nice tutorial about PPP with rtklib, but some options only make sense when you have L1+L2 data:

I tested the above processing using a couple of well known reference positions of the local university, so the numbers of 1-2cm precision for RTK, 70cm PPP static are from such tests, however all tests were executed in one afternoon, so this doesn't give a lot of variance given the weather, ionosphere and solar activity. Actual results in the field will therefore vary, and vary per day too.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Hi Gerard. Very inspiring work!

    In your post you mention that you put up the stations, fly, then take everything to the office for post-processing. I'm curious about the advantages/disadvantages to having the GCP up on a tripod vs. on the ground. How do you pin your GCPs to the ground? Would it be better to stick the stations out in the field for about 30 minutes. Then, use a plumb line to place a marker directly underneath the stations, remove the stations, fly the route, and then make the necessary adjustments to the elevation observations based on the tripod height?

  • T3

    Has anyone successfully tested an M8T setup to log RAWX data? I finally managed to get some data on the SD card but RTKLIB is only extracting *.obs data - nothing else. So it seems something it not configured properly. Any idea?

  • I'm wondering if I could get better accuracy if I post-processed the log of an airborne (plane) GPS.

  • I consider 25kmˆ2 an ultra-huge project myself :). I was referring to small as 100-400m in both directions and large would start from 1kmˆ2. I classify that based on line of sight requirements, so that anything larger than 1kmˆ2 requires multiple flights to execute, which can be considered a sequence of small projects having their own GCP's.

    It should be possible to establish a rule of thumb to establish the maximum distance between gcp's, where accuracy is considered a variable as some factor X of GSD. There may be some literature somewhere describing that. I think pix4d needs to be read from the context of their regular project size, which doesn't usually go larger than 1.5x1.5km. If you have a 5x5km area, then I reckon you'd get some sizable variation in the middle. If that's acceptable depends on what the data requirements are.

    Also interesting to see how pix4d has these tips for corridor mapping:

    The difference with corridors is that you don't have a lot of measurements tying one GCP to another as you would in a square (based on how images connect 'laterally' to some gcp in the corner), so the danger for corridors is that when you fly over some riverbed, the scale may start to vary a lot, as you only have 2-3 images that connect together on only one axis, so you need to continuously constrain this.

    Number and distribution of ground control points (GCPs) in corridor mapping
    Corridor mapping includes project areas that are significantly larger in one dimension than another, e.g. railways, roads, rivers, etc. For more info…
  • Thanks for the links, Gerard.

    To add to my previous post - I consider 25 sq km a large project. And I'm really wondering if it's possible to only use 10 GCPs on that scale.

  • Hmm, we did a 25 sq km test mapping some time ago with only 9 GCPs. The accuracy was horrible. Afterwards we used around a 100 GCPs and the result was much better.

  • Martin,

    There was a great post some time ago, showing local errors of the mosaic (errors multiplied by x1000!):

    Here's a great explanation from pix4d:

    So there's no true hard science for it. I'd select 5 gcp's for small projects to reduce the amount of work you need to do. I believe photoscan requires 5 gcp's to start processing; 4 at corners and 1 in the middle. For larger projects you can increase to 9 to create an even grid.

    Mounting the gimbal will probably have some good effects on overall accuracy between points, since you remove some obliqueness of the picture, but I reckon the error of removing a gcp is much larger than the error you're removing, so I don't think you could do away with some gcp's because of it.

  • Does anyone have a good method how to estimate the number of ground control points needed?

    Something like 1 GCP every 1k pixels?

    I'm also wondering if I could get away with only a few GCPs if I mounted the camera on a brushless gimbal. Not sure if a gimbal controller's IMU is accurate enough.

  • A thread was started on github if anyone would like to contribute.

This reply was deleted.