Kinematic solution with RTKPOST

Kinematic solution with RTKPOST

RTKPOST is the GUI tool in RTKLIB to calculate position solutions. Most of the time I find the CUI version (RNX2RTKP) better fits my needs, but just to check everything is working, it is probably easier to use RTKPOST the first time.

For a demonstration of using RTKPOST to find a kinematic position solution, I will use the ZDV1 (COREX station data) for base station data and the “EBAY” (Ublox M8N receiver data) for rover data. Zipped versions of this data is available here.  Since the exact location of ZDV1 is known and is in the observation file header, the kinematic solution will give us an absolute position by solving for the relative distance between the rover and the base, and then adding that to the base location. I set up the GUI inputs as shown below to point the program to the correct observation and navigation files. If you use my data, be sure to change the paths to match where you saved the data to.

rtkpost

For this first run, to keep things as simple as possible, we will make just two changes from the default setup. Use the “Options” button to get to the options menu. Under the “Setting 1” tab, change “Positioning mode” from “Single” to “Kinematic”. This will give us a differential solution using carrier phase info instead of an absolute solution using only pseudorange. Next, under the “Positions” tab, change the first field under “Base Station” from “Lat/Lon/Height” to RINEX Header Position. This will tell RTKPOST to get the base station location from the header of the observation file.

While you are in the options menu, click the “Save” button, and save the options setup to a location you will remember later. We will use this file as the configuration input file for the CUI version. Then click OK to exit the Options menu.

Click the “Execute” button to calculate position and then “Plot” to see the solution. Select “Gnd Trk” and zoom in and it should look like this. The two rectangles are parking lots. The yellow represents a float solution, the green a fixed solution. The fact that we were able to get a fixed solution at least part of the time is a sign things are working reasonably well.

sol1

 

Zooming into the initial time period when the car was stationary we see the plot below. Since the receiver is not moving during this time, any movement in the solution represents error. During the initial convergence of the kalman filter we see quite a lot of error, but once it does converge, we do get a fixed solution for 5 of the 20 minutes which appears as green in the plot below. During this time you can see the error is roughly +/- 1cm in the xy direction which again is a good sign things are working.

sol2

Note about restoring RTKPOST default options:  There is no button in RTKPOST to reset the options to defaults and it remembers the options from the previous session when restarted, so there is no obvious way to put it back to defaults.  The best way I have found to do this is to delete the “rtkpost.ini” file saved in the rtklib\bin folder before starting RTKPOST.

 

Advertisements

13 thoughts on “Kinematic solution with RTKPOST”

  1. Hello @rtklibexplorer
    thank uu again for your answer,
    For the transformation of the coordinates, I calculate the points of trajectography, ie more than 29000 points, and from what you told me, I understood that RTKLIB gives that the coordinates in WGS84, the site That you gave me it makes that transformation of a single point .. so there is no way to have a transformation of a file points?

    For the question of FORWARD / REVERSE, please, if there is a discriptive algorithm of this method and how does it work without using the inertial data ??

    Like

    1. Hi Saidgnss. I don’t know of any easy way to convert a whole file of coordinates. However, if you convert your base station to the desired coordinate system and your baselines are reasonably short, I believe the resulting rover measurements, which are relative to the base, will effectively be in the desired coordinate system with only very small errors.

      A description of the forward and reverse solution modes used by RTKLIB can be found in the RTKLIB 2.4.2 user manual in Appendix E

      Like

  2. Excellent blog, rtklibexplorer! I’ve been tying to do something similar and am glad to have found someone in the same boat, as it were. Unfortunately, I haven’t been able to get my setup to work yet. I am using the same eBay module as you (mine includes the magnetometer) and the stock antenna. I have the module working with rtknavi and am streaming base station data from a local (~10km away) NTRIP server. I have a clear view of the sky with no tall buildings or trees and am holding the rover in a fixed location. The problem is the RTK solution is almost always float and is not precise at all. Only rarely does it enter the fix state and only very briefly. I have tried a few other base stations, with the same results. My instinct is to blame the antenna, but the reported SNRs are in the mid-high 40s, which I understand to be good enough. Is there something obvious I’m missing?

    Like

    1. Hi Janame. Glad you enjoyed the blog! Given your conditions you should be getting good fixes. Are you using a decent ground plane for the antenna? Ublox recommends a 50 to 75 mm square centimeter ground plane, but larger should be OK too. There are more good suggestions for improving your data collection environment in this document from Ublox.

      If that doesn’t help I would suggest downloading the code/configuration files/data from my Github repository and running your data with my code/configuration and vice-versa to determine if the problem is in the data, code, or input configuration.

      Like

  3. I made some test with my current setup: 2 Tallysman TW3040 connected to the M8T base receiver (1hz) and to the LEA6T for rover position set at 5 Hz output rate.
    I found some improvements changing the errratio1 from 100 to 300 (even if I don’t completely understand the meaning of this parameter)
    While I found very bad results adding rows:”pos2-arthres1 =0.9999; pos2-arthres2=0.25; pos2-arthres3 =0.1;
    pos2-arthres4 =0.05; since my starting conf file didn’t have them. Very short fix time and very poor ratio value.
    Even for these parameters I don’t know exactly what are affecting. Have you some info about this?

    In the next days I will apply changes to fix the “pos2-arlockcount” bug then recompile for the Raspberry model 2.

    From my experience I noticed that better results exist when low number of satellites are taking into account for ambiguity resolution and then fix-and-hold. Around 6 satellites (good results also with 7 or 8 max).
    Instead to cut down satellites with SNRmask filter could it be possible to process only the best 6-7 satellites with best SNR? May I’m wrong?
    I’m an electronic engineer but I’m not an expert about GNSS.

    Like

    1. Hi generaldin. Eratio1 is a user estimate of the ratio of standard deviations of pseudorange errors to carrier‐phase errors. My understanding is that increasing this number causes RTKLIB to increase emphasis on the carrier phase measurements over the pseudorange measurements in its updates to the kalman filter.

      arthres1-5 were new with the default config file for 2.4.3 release. None of them are used by the code however and it should not make any difference what these values are set to.

      In general, the more high quality satellite signals used for ambiguity resolution the better since it increases the confidence in the solution, but I agree that excluding lower quality signals can be important since a single bad satellite can prevent a fix no matter how many good satellites you have. The SNRmask filter can help with this with the existing code.

      I have also had some success with experimental code I have been playing with that qualifies each new satellite before adding it to the fixed solution set. Satellites are not qualified if they break or severely degrade the AR ratio and are re-qualified at specified intervals to catch satellites that have degraded. I hope to write a post on this once I’ve had a little more time to work out the details.

      Like

    1. Sorry … I don’t know why the link isn’t working, it’s supposed to be shared for anyone. You can find all the raw data at my github page in the demo1/data in the demo1/data/demo1 folder. The complete .conf config file is there as well.

      Like

      1. Hello @rtklibexplorer,
        i’m new in RTKLIB, I calculated the trajectography of an embedded 3D scanner, I used several software in order to compare the results of calculations for each software, I started with two commercial software, after I calculated by RTKLIB, but j I noticed that we can not know the antenna heights, nor the type of antenna (because it requires delta (e / n / h), and after the calculations I had 1cm in Y, and 8- 9 cm in X, Z? I do not understand why these differences? Please help to fix this problem..

        Like

        1. Hi Saidgnss. Exact matches to an absolute point or solution are tricky because of different coordinate systems and antenna offsets. I do not have access to a geodetic grade receiver and also do not have PCV to ARP calibration values for most of my antennas so I have focused more on verifying relative measurements and not absolute measurements.

          Liked by 1 person

          1. Hello @rtklibexplorer
            Thank you for the repense,
            I calculate the trajectogram of a scanner in PPK mode (relative mode) with an embedded GPS and a base station 1km of project,
            1 / in RTKLIB I had the same results either with the braodcaste or with the precise ephemerides (if we use this equation of [(or error + datum shift error) * (baseline / dist to satellites) A baseline 50km one will see 5mm of error)
            2 / for antennas: when I used Delta (e / n / h) = 0.00 / 0.00 / 1.47 for the ROVER and 0.00 / 0.00 / 1.28 for the base station, then I had results close to My calculations of commercial software (1cm in E, 8mm in N, and 1 cm in Z)
            Knowing that I noticed that: when I change the method of correction iono and tropo its not changing the results? !!!!
            3 / the coordinates are still in WGS84 there is no average to make them out in RGF93 ??
            4 / if you can please explain to me how it uses the forward / reverse method (KALMAN filtering) without the inertial data?
            I wait for your repentance with patience
            thank you

            Like

          2. Hi Saidgnss. I use this site for converting from one coordinate system to another but I don’t know if it includes RGF93.

            With only a 1 km baseline I would not expect significant changes when using precise or broadcast ephemerides or by changing the tropo or iono correction since with such a short baseline, the errors will mostly cancel out between rover and base and will not need correction.

            The forward/reverse processing modes in RTKLIB only refer to which direction the kalman filter processes the measurement data in post-processing mode (begin->end or end->begin), so no need for inertial data in either direction.

            Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s