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

  • Great info John, thanks! I will have to try this out sometime this summer.

  • In case anyone is interested I figured out how to turn on raw data on the Ublox M8N.  This document explains it.  I was having problems as the exact settings shown in the document and the examples which came with RTKLIB didn't work for me.

    http://gpspp.sakura.ne.jp/paper2005/gpssymp_2014_ttaka.pdf

    RTKLIB uses the unsupported Ublox messages TRK-MEAS and TRK-SFRBX for raw data.  To turn them on with RTKNAVI I used the initialization strings:

    !UBX CFG-MSG 3 15 0 1 0 1 0 0
    !UBX CFG-MSG 3 16 0 1 0 1 0 0
    !UBX CFG-MSG 1 32 0 1 0 1 0 0

    The module I purchased cost $33 and it has a U.FL antenna connector so it's easy to add a better antenna if you want.  Combine it with a cheap knockoff of a Sparkfun OpenLog, a 5 volt regulator and battery and you have a GPS and Glonass single frequency raw data recorder for about $60.

    http://www.readytoflyquads.com/ublox-m8n-gps-w-55x45mm-mounting-bac...
    http://www.readytoflyquads.com/gps-sd-data-logger  (I've only used the Sparkfun version)


    I haven't bothered to figure out the custom, unsupported Ublox commands within u-center to turn on the raw data strings.  I just set up my receiver to output raw data this way:

    1) Connect to the receiver in u-center and from the Message View window select UBX-CFG-CFG
        revert to default configuration and (send) then save and (send)
    2) Power cycle
       < You have a clean slate now though steps 1) and 2) aren't strictly necessary >
    3) reconnect in u-center (NOTE: default baud is 9600)
       In the Message View window disable all the default NMEA messages which are on
       < they just clog up the serial port >
    4) From the Message View window go to UBX-CFG-PRT
        change the baud rate to 38400 and (send)
    5) Reconfigure u-center itself for 38400 baud (Receiver -> baudrate at top of u-center window)
    6) From the Message View window select UBX-CFG-CFG
       select save the current configuration and (send)
       < You now have a default receiver configuration, but changed to 38400 baud with no output strings >
    7) Exit u-center
    8) start the RTKNAVI program
        configure the Input Rover string for the serial port the Ublox receiver is on and add the commands listed above
        to the Commands at startup box.  IMPORTANT: Do Not have any shutdown commands enabled
    9) Start RTKNAVI processing
       The commands to enable raw data are sent.  RTKNAVI if setup for a Single position solution should show valid data assuming you are tracking satellites.
    10) Stop RTKNAVI
    11) Start u-center and connect to the receiver
        In a Message View window go to UBX-CFG-CFG and save the current config and (send)
    12) You are done.  At any future power up raw data will automatically be sent at 38400 baud.

    The above seems to work.  I haven't done any extensive testing, but the data seems to process well.  Emlid's Reach (RTK product) was developed with the M8N so it should provide good data even for Kinematic work.

    http://gpspp.sakura.ne.jp/paper2005/gpssymp_2014_ttaka.pdf
  • Hi John,

    The antenna thing is certainly true. A car roof would be ideal for a base station at least and other natural objects that are at least 20cmx20cm are suitable too for raising the antenna. The reason for that is that smaller, raised surfaces do not necessarily come out that well in photogrammetry results and this may then impact precision results. The tripod of course is just an offset antenna from the ground.

    I did a kinematic test myself too and it's tricky in the sense that you need to have the antenna in good view of the sky all the time. Probably the best is to just put it on your head and walk around like a clown. When you walk with the antenna in front, your body may block the signals from the back.

    Sounds like a great idea to collect points this way. Also, I noticed that in this mode extra files like sp3 and clk files from IGS can help to increase precision, more specifically the altitude to dampen out certain oscillations.

  • @Sobido


    Thanks for the continued help.  I managed to get raw SBS and NAV data, but no OBS yet from a message u-center doesn't recognize, but RTKLIB does.  I'll keep working at it as I recently bought the $33 Ublox M8N for precisely the reason of Gerard's post.  If I can get raw GPS and Glonass out of it that would be very cost effective.  If not, it has other uses.


    To add some comments to Gerard's nice writeup:

    Static work is much more forgiving than Kinematic.  Sometimes you can get away with laying an antenna on top of an object, but it is best to get it up away from the ground.  To do this relatively inexpensively I use cheap (< $20) camera tripods.  They are very lightweight and can usually get the antenna at least 1.5 meters above the ground.  With a plumb line and a little practice you can accurately position the antenna.  Adding a bubble level can help.  For heights I also bring along a tape measure.

    Another method to speed up the collection of cm-level control points is to process in Kinematic mode.  With cheap L1 only receivers this can be a bit tricky, but if some of your control points have relatively open sky between them you can carry the cm accuracy from one to another as long as you maintain carrier lock on 4+ sats.  That way you only have to spend a few seconds at a control point.  Later how do you know when you were at the control point?  You can sync a watch to GPS time and note that or you can always stay at the control point for, say, 15 seconds and when you move away do it moderately quickly.  Then when reviewing your tracklog and the clusters of positions around your control points, the correct coordinates will have time stamps just a few seconds (epochs) before those of positions leaving the control point area.

    Everybody's situation is different, but for me it's not uncommon to get half or more of my CPs with kinematic work.  All the equipment can be attached to the tripod which makes it easy to move around.  Traces of linear objects like fence lines or road edges can also be gathered this way and their tracklogs compared to photogrammetric output.

  • Hi Jesus,

    So these antennas and GPS's are statically located on the ground to get ground control points, they're not on the vehicle. I do configure the GPS to emit 1Hz readings, 5Hz is unnecessary.

    I don't really rely on the positions in EXIF and in my script I'm only interpolating using the vehicle's GPS if I do use it. Then the position is mostly used for making the process more efficient, so that the software can figure out which photos to compare with which.

  • @Gerard

    When you post process with RTKLIB Postprocess, what rate do you get? 1 position per second?

    I think that RAW messages were coming at 1Hz, isn't it?

    Assuming you have a postprocessed "good" GPS location per second, how do you do to timestamp the pictures? I imagine you need to interpolate?

    Very nice article

  • sorry sign "#"before mean "Comments". I only use the line for the TIM-FCHG .you can use all to insure:

    !UBX CFG-GNSS 0 72 32 1 0 8 16 0 1 #Switch on GPS

    !UBX CFG-GNSS 0 72 32 1 6 8 16 0 1 #Switch on Glonass

    !UBX CFG-GNSS 0 72 32 1 3 8 16 0 1 #Switch on Beidou

    !UBX CFG-GNSS 0 32 32 1 2 4 4 0 1 #Switch on Galileo

    !UBX CFG-MSG 3 16 0 1 0 1 0 0  # TIM-FCHG?

    !UBX CFG-MSG 3 15 0 1 0 1 0 0  # RXM-RAWX?

  • I use the version 8.13 of Ucenter. 

    If you want to use RTKNavi  first an before to try to fix it in Ucenter , you can use a serial CMD line at startup like this :

    #!UBX CFG-GNSS 0 72 32 1 0 8 16 0 1 #Switch on GPS
    #!UBX CFG-GNSS 0 72 32 1 6 8 16 0 1 #Switch on Glonass
    #!UBX CFG-GNSS 0 72 32 1 3 8 16 0 1 #Switch on Beidou
    #!UBX CFG-GNSS 0 32 32 1 2 4 4 0 1 #Switch on Galileo

    !UBX CFG-MSG 3 16 0 1 0 1 0 0 # TIM-FCHG?
    #!UBX CFG-MSG 3 15 0 1 0 1 0 0 # RXM-RAWX?

    it should work.

  • Just a note: you can get real time centimeter level accuracy with a single rover if the university or town you live in have permanent base stations set up and provide that service. Utilities may provide it as well. There are also commercial subscriptions available for the service. The Coast and Geodetic Survey have ground based beacons that broadcast correction for free. I use their beacons for real time correction with a sub-meter GPS.

  • Thank you for such a detailed response.  Unfortunately no matter what I try I can't get the required messages (RAW or RAWX and SFRB or SFRBX) from my M8N.  Through u-center UBX-CFG-MSG doesn't allow the selection of 02-15-RXM-RAWX and more directly the send option of UBX-RXM-RAWX is disabled.  A custom hex message is ignored.

    RTKLIB has setup strings for the M8N in its /data directory, but those do not work with my M8N.

    I expect there are different versions of the M8N out there.  Ublox doesn't officially support raw data on the M8N so perhaps some vendors have hacked the firmware or Ublox may have release some with raw enabled.  This may not show up in the UBX-MON-VER message, but out of curiosity does the response from yours look like this?

    Software Version
    2.01 (75350)

    Hardware Version
    00080000

    Extension(s)
    2.01 (75331)
    PROTVER 15.00
    FIS 0xEF4015(73171)
    MOD NEO-M8N-0
    GPS;SBAS;GLO;BDS;QZSS

This reply was deleted.