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

Image: 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-w...

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.

Views: 19163

Comment by me on April 21, 2015 at 9:00pm

Nice summary, which antennas do you use and can you post a picture of your control point rig in the field and close up?

Comment by Sobido on April 22, 2015 at 1:18am

Gerard

Nice summary indeed. Thanks.

i do the same type of thing for GCP for Uav photogrammetry . I use M8N Gps with built in antenna (54 € withL1) + a datalogger + 3V Step up/down alimentation + 3 AAA batteries. Each equipment ( I build 5 box )  is positionned on my GCPs ( a color blanket) before the flight . The revevue price of the all "box" is less than 150$. After about 30min , like you, I treat the raw signal with RTKLIB in static mode  with a IGS file or a RGP file ( in France) as Base .

The other option is to position one box on a knowed XYZ point and use this signal as base.

The good news is that I obtained a average value of less that 10cm in XYZ in absolute position , compared with with a true professionnal RTK equipment . I have had some with 3cm precison but the worst at 17cm ,so 10 cm  is more representative of type of precision that I have.

Comment by Gerard Toonstra on April 22, 2015 at 2:46am

EMLID has more info about how to create this setup: http://docs.emlid.com/RTKLIB/rtklib-base-setup/ , also listing a range of antennas. I use their USB GPS module (u-blox NEO-6T).

This is my antenna, which can be considered a bit more expensive than necessary. Slighly cheaper antennas work good already: http://www.digikey.com/product-detail/en/33-2410-00-5000/1526-1011-...

Comment by Sobido on April 22, 2015 at 3:22am

Curious of what will be the Emlid REACH also to help with. sounds good.

Comment by RPM on April 22, 2015 at 7:42am

Very interesting set ups!

I am curious as to specifically what dataloggers you guys are using? I would like to set up similar units and test the accuracy against the high end survey GPS units.

Thanks!

Comment by Victor Toth on April 22, 2015 at 9:48am

This is quite interesting indeed. I might try to experiment with this.

I have a Neo-M8N and an arduino, and an SD card reader/writer. 

Would obtaining the files for RTKLib be as simple as just logging the gps output similar to what is described here?

http://www.toptechboy.com/arduino/lesson-23-arduino-gps-with-data-l...

Comment by Sobido on April 22, 2015 at 10:13am

I use tthe following for each box :

M8N : http://www.drotek.fr/shop/en/home/613-ublox-neo-m8n-gps-hmc5983-comp...

Datalogger : Ardulog (RTC) :http://www.hobbytronics.co.uk/ardulog-rtc?keyword=ardulog

regulator : Pololu 3.3V Step-Up/Step-Down Voltage Regulator

+enclosed  Battery Box 3x AAA + one On-Off Switch.

Note that the datalogger should be configure with Openlog program and not with the standard arduino program.

The worst part is the configuration of the M8N with Ucenter to catch the Raw.

I noticed also some pertubance with the Ardulog on movement ( can't use it in the plane for instance) . A more stable datalogger is use then the :logomatic form Sparkfun. (https://www.sparkfun.com/products/12772

Comment by Gerard Toonstra on April 22, 2015 at 10:33am

The RTC and breakout board are not actually necessary. The most direct way is to solder the SD card using a bunch of wires and talk to it using the SPI bus. The datalogger basically exposes a slightly easier to use serial interface. You can however get SD card breakout boards that have pins to establish a cleaner hardware interface between the arduino and the SD. Time in the log comes from the GPS data itself.

Not all GPS modules have EEPROM, so when you turn the device off you need to repeat any commands for the configuration you wish to set. That means that you need to rerun those commands in your implementation on startup too. Those are "UBX" commands and their actual format differs per module. You need to scour the internet on how to figure out what those commands are. I'd think that u-center should have some feature where you can display the datastream going to the module when you issue reconfiguration commands, or perhaps you can save the config and inspect the generated file afterwards.

Comment by Gary McCray on April 22, 2015 at 11:14am

Really great post Gerard,

Makes high accuracy practical and affordable, lots of applications.

Best regards,

Gary

Comment by Sobido on April 22, 2015 at 12:24pm

@gerard

You are right about the RTC. No need RTC for that application. The Ardulog V3 is enough. I use the RTC because I use also the Datalogger for other purpose where i need RTC .

The configuration of the M8N is possible with Ucenter for the Datalogger . I sent quite a time to find a solution but it is work.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service