We have a number of 5Hz Reach RINEX files (firmware image v2.3, ReachView 2.5.3-r0) recording during UAV flights that we’re looking to postprocess using RTKPOST. We’re processing them against a 5Hz base station record from a known position – actually a Trimble basestation rather than another Emlid unit – using Emlid’s RTKPOST (ver 2.4.3 Emlid b27), largely according to Emlid documentation with some additional influence from the Tuffwing Reach PPK guide.
However, I’ve noticed that the output was surprisingly poor (large sections of flight were float rather than fix) compared to what we were expecting. Motivated by the fact that we weren’t using solely Emlid data, I redid the processing using identical settings (loading the same .conf file) on the ‘vanilla’ RTKPOST software from http://www.rtklib.com/ (ver 2.4.2).
I was quite surprised to see dramatic differences between the two outputs. An example is here as follows, using identical input files and settings:
I’d be interested to know what might be behind this significant difference, and whether we can replicate the quality of the vanilla RTKLIB in the Emlid RTKLIB? I’d rather use the Emlid version as it comes with a nicely edited _events.pos file for our camera triggers, but I’d like to be sure it’s trustworthy first!
A few more observations that might be of use:
I have tested the two different software on 19 flights so far. For all of our flights, the Emlid RTKPOST provides consistently similar but different results to the vanilla RTKPOST.
In a few cases, the Emlid version provided a better output, but more often the Emlid output is worse (i.e. less periods of fix than the vanilla version).
There are multiple examples of the Emlid RTKPOST providing ‘patchy’ coverage where the vanilla RTKPOST provided near-perfect coverage (e.g. the images above). There no examples of the reverse.
Even on examples where both results are ‘patchy’, the results are still different: periods of fix and float differ between software outputs.
The Emlid version processes notably quicker.
The only additional option I can see in the Emlid version of RTKPOST is the option for an AR filter, which when turned on/off changes, but does not eliminate, the float solution regions.
For a very poor dataset we have, the Emlid version tends drops poor datapoints entirely, whereas the vanilla version tends to classify Q=5.
(I hope no one minds but I’m looking to keep our files confidential – I will email examples to support@emlid. However, I’d be equally interested to see if anyone can reproduce this using their own data).
Fantastic post.
Interesting to see that your flight controller looks like it still has a simple PID controller, with no memory or estimate of environmental factors. Do you know any flight controllers that use environmental conditions memory? We used them for AUV’s 10 years ago and they reduced the recovery time after the turn.
You could use time info only from _events.pos file and interpolate positions from vanilla RTKPOST pos file. You would get the best of the two worlds.
Following your discussion. I noticed already seeing a vast majority of Q5 displayed during the Emlid version of RTKPOST calculation phase, and get finally a deceiving 65% fixed at the end with RTKPLOT.
Hi Simon, glad to see you’re interested. We’re using a Pixhawk setup for our fixed-wing UAV and connecting to the Emlid (and the camera) with a Tuffwing cable as per Reach Setup for PPK Processing on a UAV The Pixhawk does supply flightlog that records pitch, yaw, roll, and camera triggers etc. (if that’s what you mean by memory of environmental factors), however of course the GPS records are not kinematic!
Hi Ivan, I shared the relevant files to support@emlid.com alongside submission of this post. I’m sure it is just something in the settings too. Cheers.
Hi Pascal, yes integrating the two datasets like that is our second option – however we’re an academic group so would have to able to justify why we’re doing that in our methods section Better that we know for sure if something’s going wrong!
Sorry I wasn’t too clear. If you have a model of the flight characteristics of the uav then based on the difference between how fast and in what direction you the air craft is going through the air vs ground speed and direction you can estimate wind speed and direction. If these are remembered onboard then they can be applied to the inputs calculated for a turn. When it works well there is little relearning when you change direction ( ie better line following) without those little bows in the line your track shows.
Thanks a lot Igor. I’ve messed around with my settings and was able to replicate something very close to this. The major jump in quality occurred when I switched to a forward-only kalman filter from a combined filter, and this appears to be true across a variety of the datasets I’ve tested it on. Again comparing to the standard RTKPOST output (with an identical .conf file), it appears that the Emlid fork doesn’t appear to handle combined filtering as well as the vanilla option – at least, for the datasets I have available to me.
Devs found out more about this. RTKLIB marks positions as float on backwards pass if the fix differs significantly from the one on the forward pass. In this particular log file the fix could have been false and it was propagated by the fix-and-hold strategy through the solution. Going backwards RTKLIB detected that and flagged all solutions as false. When choosing “continuos” AR, which is less prone to holding erroneous solutions I was able to get a proper solution with combined filter.
Better that we know for sure if something’s going wrong!