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: http://www.rtklib.com/

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.

optional:
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): https://igscb.jpl.nasa.gov/components/prods_cb.html ; (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:

http://blog.latitude51.ca/rtklib-part-3-precise-point-positioning-with-igs-products/

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

Comments

  • Looks like I didn't have the Cycle Slip markers on for those last obs plots, but I've been reading the rtklibexplorer blog and there's some good info on there.

    I re-did the test this afternoon but powered the units on for 5 minutes before starting the logging, and also set the elevation mask to 15 deg up from 10, and managed to get a workable result out of this setup.

    Is there an easy way to cut the first 5 minutes off a log before processing, if logging is on from startup?

  • I can't see any cycle slips (red lines) in any of them by viewing the obs data for each GPS in RTKlib.

    In all of them there seems to be some sats which the receiver sees intermittently, with the Drotek XXL with the big antenna picking up more satellites for a shorter period since I guess it's that much more sensitive.

    I thought maybe the problem was due to me converting to RINEX 2.1 with my previous tests, so I changed to 3.02, but that didn't change anything.

    Here are the observation plots: 

    GPS1

    GPS2

    GPS3

    GPS4

    GPS5

    And a link to the data set I'm working with, where GPS5 is the one giving me the bad position.

    Data set zip

  • look in RTKLib to see if you are getting more cycle slips in the ones that arent getting a good result?

  • Thanks for looking at this. Is there an easy way to see if one receiver lost sats that the others didn't, or do I just play the log in u-center and see if I can spot sats dropping out?

    I'm using a Drotek XXL M8N for my PPP-Static receiver, it's very fast to get lots of sats - https://drotek.com/shop/en/drotek-parts/680-ublox-neo-m8n-gps-hmc59...

    and am using these smaller M8N units for the other 4 - https://drotek.com/shop/en/drotek-parts/820-ublox-neo-m8n-gps-hmc59...

  • @ Glenn M

    Can you tell if all of the units were seeing the same set of sats for the entire test? Better yet, did the two with the fuzzy positions lose sats that the others saw the entire time? It has been a while since I messed with these units but I seem to recall trimming data to only the periods where all of my rovers were getting strong signals from the same set of sats and I got improved results.

    The M8Ns never gave me the consistent results that I wanted so I ended up switching over to the M8Ts. The M8Ts have much higher frequency capabilities and they have the "real" raw data output functionality. It is amazing how quickly you get a "fix" solution when using the M8Ts vs. the M8Ns. Moreover, the M8Ns would never work for me in dynamic modes (and intermittently in static modes).

  • I'm having trouble getting reliable results using this method. Can someone who's had success with this see where I might be going wrong?

    I have 5 x M8N units on tripods (with TRK-MEAS turned on), connected to openlogs, and I space them out in a line so the receivers are approx 0.8m apart. Out of several times running the test with them logging for 30-40 minutes, after post processing using one as the REF using PPP-Static, generally 3 or 4 will give me the positions that they should, but one or two will be a few metres off. It seems to be different receivers each time in which the positions are off. I'm not quite sure where it's going wrong, but out of 6 or 7 tests have only managed to get one where all 5 were lined up as they should have been (by looking at the exported kml positions for each). Help please!

  • The 3.01 firmware does not disable raw output, it changes the parameters and obfuscates things slightly.

    The 2.01 (ROM/EXT) continues to function, so unless you have some compelling reason to use the unvalidated Galileo constellation you can flash back to the older release.

    Imagery in Google is highly variable, depending on when it was taken, and the centre-line of the overpass. Here we use post-processing against local CORS data to establish known reference points.

  • Newest M8N firmware update disables raw output, hence commands are no longer available for newest rtklib version. 

    Does anyone know a reasonable priced geomap service to verify coordinates? Google maps provides rather volatile accuracy (0.4m - 22m) according to this survey from 2008.

    https://www.google.at/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjmu9Glz-bK…
  • ALL current uBlox offerings can output 'raw' measurements, the M8N via TRK-MEAS, only the M8T has the RXM-RAWX which is the officially blessed manner to get RINEX polished data.

  • Sorry I should have read earlier posts, covert the data in rtconv.

This reply was deleted.