While looking at this I realized a possible mistake with emlid’s post processing event interpolation routine:
Firmware image and ReachView version:
rtkpost_emlid_b27
Detailed problem description. How does observed behavior differ from the expected one?
I started to look at the RINEX file event times vs. the PPK processed position event times. Even though the RINEX measurements have the corresponding receiver time while the solution should have GPST (which differs by the receiver clock bias) the solution given by rtkpost_emlid_b27.exe has EXACTLY the same timestamps for .obs and .pos files for the events.
Step by step actions.
I developed my own algorithm in Matlab to calculate the clock bias and interpolate the event measurements based on a consistent time vector. After that I run pix4d with the same setting but using the emlid interpolation vs. my own interpolation routine. It turned out that 3 sigma relative geolocation error (accuracy) in Z went up from 95.58% to 99.71% when using my routine. This indicates to me that my suspicion is correct and the interpolation is not correct in rtkpost_emlid_b27.exe.
Emlid geolocation report: 170826F10_emlid_report.pdf (355.4 KB)
Report using the custom interpolation routine: 170826F10_interpolate_report.pdf (355.6 KB)
Matlab results for clock bias calculated at every epoch, not only at events:
Attached are the pix4d report with emlid event calculation, and with the interpolation routine made from scratch. Also the figure about clock bias. It seems rather high, on the order of 0.0135 s, which is 10 higher than what ublox advertises about clock bias https://forum.u-blox.com/index.php?qa=2675&qa_1=bias-clock-and-doppler. If you fly 20 m/s this means 27 cm of error!!!
Very very interesting. While I dont have the data to prove it, I often see on our calibration site that those flights that are down with a fast cruise speed (>19m/s) tend to have a fair bit of wobble when it comes to comparing resultant ortho/DTM with control in the QC part.
I did a comparison between the RTKlib interpolated positions for my camera events and then interpolated them myself from the raw events output using python pandas linear interpolation. Because of the surprisingly big differences I am now checking my own math/code before making any bold statements. Attached is a (picture of a) list of differences. If the errors are real then there needs to be a fix. in the interim I will inject my coordinates into the EXIFs and see what comes out of Photoscan.
If we look into reach through ssh, there is python class for cameratrigger but it’s not here (this class is for camera triggering). It’s inside rtklib.
I have a flight with 683 pictures (1 on ground and 682 in air). I got the exif info about time of each picture taken (denoted ‘sony’ on the figure), I have the time values from the Emlid rinex .obs file (‘emlid’) and I have my own implementation (‘ventus’) .
There are 686 events in the Emlid log and 682 in my own version. What I plot on the figure is the difference between time of pictures. Of course sony is integer, but the big delays between flight lines are perfectly matched between sony and my own, while it seems there are some extra entries in the Emlid version and it grows by time.
What do you mean by buffer problem? The time of sony is just a random one, no synchronization, but the time difference between pictures does not depend on the clock offset of any device.
Oh ok, you compare difference between picture not between real time.
To write event in ubx file, I think there is a delay that what I mean about buffer
But I don’t understand one thing, with your previous post : you plot camera exif information. Correct me if I’m wrong but exif time are in seconds, not in milliseconds, how could it be compared ?
I just converted everything into seconds. What makes it even worse, event timemarks are partially in miliseconds (1e-3) partially in nanoseconds (1e-9) in the raw .ubx file.
In ebee process, time of camera is syncing to gps time during preflight connection. So events are in seconds not milli or nano seconds and it’s working !
We just got back from the fair. We are currently looking into the issues introduced in the last update. As soon as we fix those, we putting our RTKLIB team on this issue.
Inertial Exploerer output.pdf → a default report
output-Inertial-Explorer-8.6.txt → output/exporting from IE
output_Rtklib-rover_raw_201709211753_events.pos → output from processing from rtkpost (b27)
output_Rtklib-rover_raw_201709211753_events.pos-UTM-Zone22.txt → The fields lat/lon from original file, converted to UTM (zone 22).
differences.xlsx → a simple excel file, with a dispersion graphich of differences.
We can notice that E component is more affected by differences… and make sense due the flight was executed in W-E directions… or … the maximum variation of velocity is in directions West and East.
It’s possible to you share your remote and base files, and the base coordinates to check it in IE?
Hi Thiago! I put them together in a zip file: https://drive.google.com/file/d/0BzzUBqpwxqRCSndRU1FXdEhnQ2M/view?usp=sharing . It contains the reach base, the reach rover files and also virtual reference station rinex files, so it is possible to do direct VRS+Rover processing or also VRS+Base → Base+Rover workflow.
I am really curious about the large errors, usually I have similar results when I have low ratio - also I can see that the solution is “jumping” at some points within the processing since forward and backward do not match. I suggest to use continuous AR instead of fix and hold.
What makes it even worse, event timemarks are partially in miliseconds (1e-3) partially in nanoseconds (1e-9) in the raw .ubx file.