This software is Emlid’s biggest contribution to moving forward so far in my opinion. I finally had the opportunity to test Beta 7 last night, and it just works! The days of using RTKConv, RTKPost, and RTKPlot are OVER! I use this primarily for post-processing airborne trajectories for photogrammetry. A few notes are as follows:
I ran into a small installation error that could be skipped. I didn’t screenshot it, but nothing appears to be running out of the ordinary.
Following conversion to Lat/Long, MANY people need to adjust the Z values to Orthometric (Geoid). Every country is different, but in the states, I use https://geodesy.noaa.gov/GEOID/GEOID18/computation.html. Formatting is a royal pain, so some preprogrammed outputs would be GREAT!
The next HUGE step is converting Lat/Long to projected coordinates using EPSG codes. I currently use QGIS for this, but there’s other tools too. It’s really as easy as selecting an EPSG code, and ReachView already does this. Let’s get Emlid Studio to as well!
A synthetic heading would be really useful by averaging the ground track azimuth of the event based on the previous and next epochs. This can give Photogrammetry software some more context to make pixel matches in difficult-to-map areas.
Finally, making the _events.pos output into a standardized photogrammetric output format would be helpful. This really has to happen after the conversion to EPSG codes, but normally that would be X Y Z Roll Pitch Yaw, all of the rest. Roll and pitch would need to be zeroed or input from other inertial software. Most photogrammetric software can accept a .csv or .txt file with the highly accurate EO (external orientation) coordinates, so geotagging is unnecessary, HOWEVER…
Geotagging photos would really make this software competitive with about any other UAV post-processing software out there.
Would you mind sharing the data with us? It’s hard to say why Emlid Studio couldn’t process some tests without checking the data. You can PM me with the data if you don’t want to post them in public.
In this link you will find all the data.
As i understand, if i uncheck GALILEO Constellation everything is OK. Otherwise just Test 2 will be corrected.
Hello Svetlana,
thank you for your answer.
indeed if I don’t get a FIX in STOP & GO, I might be difficult sometimes to recompute in PPK a fix solution.
But here my issue is upside down
for a given timestamp I’ve got fix solution in STOP & GO, but when I compute my log in EMLID STUDIO for that same timestamp the pos returns -NAN value. quite surprising , isn’t it ?
To make Emlid Studio work, Microsoft Visual C++ Redistributable package is installed. Installation of this package usually requires restarting the PC.
Installer of Emlid Studio 1-beta-7 suppresses the requested reboot, that’s why the error appears.
Basically, this error means that Microsoft Visual C++ Redistributable was installed successfully
Accurate offset for drones would be a nice feature indeed. Does it requires inertial information (pitch, roll & yaw) from flight controller, or only the GNSS information is enough?
I tried to collect some points (REACH RS) on stop&go (15 sec of each acquisition) now I would like to post process using a rinex from base station but no result
where am I wrong ?
When load the rinex of base station in Studio how can understand the time start and end (I can only download rinex per hour)
Post-processing software can hardly calculate offset between antenna and camera. For this, it should know the precise coordinates of a camera’s center. To be honest, I don’t know cameras that can provide this info. It’s usually the drones manufacturers’ responsibility.
However, we definitely can add fields to enter these values
So, do you download base RINEX from the NTRIP service? If so, you can just open rover RINEX in Emlid Studio first. You’ll see the time span below the plot.
