Thanks G, great write-up! I’m going to cross-reference this for the folks that use the Emlid or like GNSS systems. With systems like these and the emlid version of rtklib you will receive a POS file that has event time works in it. This allows you to perfectly match up any given image to its specific event instead of looking at the entire track. I currently use it both ways. My Phantom 4 Pro with the Emlid kit creates events, but my Yuneec H520 kit does not and I use the full track to retag.
Thanks, yeah I’m trying to write these How To’s for the masses vs the one off’ers. I need to revisit the RTKLIB post I did and clean it up to be more generic if I can. I reference the P4RTK because the website I used referenced it, ok ok I fly a P4RTK geee lol.
I think I can use your input from the drones you fly as well as others (Non DJI types) and come up with a generic enough write-up to where you have to provide these files (anyway you can get them) and then use these steps to process the PPK to get this output.
In the RTKLIB I went in to detail on how to use the Excel spreadsheet, which is good to have but GeoSetter is much easier and using RTKPOST with a few clicks and your done is much easier way.
Honestly, I think what you have is great. The only variables are the different drones, but mostly because of gnss hardware. The terms for raw log and needing to get them into the Rinex format in order to get the POS file is universal to RTKLIB so it just depends on the beginning file format and whether you are using a base of your own or a CORS site, but that is for the other thread. Once you get to Geosetter it’s all the same.
I am using a Phantom four RTK and cannot get geosetter to work for me. I am using RTKLib to generate a .gpx file from my static data then attempting to geotag my photos in geosetter. When I update my photos and compare them to my ground control targets they are off about 3 meters horizontally and 10 meters vertically. I am doing something wrong wondering if someone could help me.
So to make sure I understand you fully you are extract the logs from the Phantom 4 RTK in PPK mode and trying to post-process them with RTKLIB convert and post? Then exporting the GPX in post and loading it into Geosetter?
I am not using RTKLIB convert as my base files are already in a Rinex format. I am using the post to post process to the raw files from the phantom 4 RTK. I then generate my .GPX file and use that for geosetter. I am then running the images from geosetter through a photogrammetry software called 3dsurvey and generating a pointcloud. The pointcloud compared to my ground control targets set with GPS are where I am seeing a large error. This is my first time using the PPK function of the phantom four RTK and have never had a problem flying with an RTK fix. I hope I explained it well enough let me know if you would like more information or a look at the data set.
Goal:
Base data from CORS or u-blox ZED-F9P.
WGS84 LAT,LON,Ellipsoid Height replaced by NAD83(2011) LAT, LON, Ellipsoid Height when post processed. This will make the drone position NAD83(2011) like it is flying with a fix. We currently use PPK for our LiDAR sensor.
We need the positions of the images to be NAD83(2011) with the ellipsoid height.
Once the images are adjusted in this way we insert them into 3dSurvey which allows us to stitch them together and convert them to the correct state plane coordinates and apply the proper geoid separation file for NAVD88 elevations in the point cloud. This works if the drone was flown with an RTK fix.
As for your question, my plot in RTKLIB is 100% fixed. We are also converting to a coordinate system as stated above.
So your photogrammetry processing is being done on images with NAD83 (2011) geotags?
How are you transforming from WGS84 to NAD83?
How were the GCP’s set? Off of what datum?
Are your base corrections live or are you using posted historical data?
Everyone that reads this should be aware that the tolerances on what a P4RTK considers a fix are very low in surveying standards and elsewhere would have several float conditions. You can see this for yourself if you actually PPK the logs. The SnR values and the PDOP allowance is higher than survey grade equipment and is exactly why we see a 100% fix in this graph from DJI’s perspective. In PPK there is no way this will happen.
Doesn’t 3D Survey have a geotagging function. Maybe you can convert you files to a LOG?
Does your GPX include the events? Can you share it?
I wish I could help more. All of our surveying is done off of SPCS localizations so I am not too familiar with using transformed data with a third coordinate system in the mix like WGS84 > NAD83 and GCP’s from an SPCS. The transformation from one to the other to the other is not a simple conversion and it needs to happen before the GPX is created.
In our environment we integrate the drone data back to CAD softwares so it is a direct transformation from WGS84 to our EPSG through DroneDeploy because our base point for our drones are always control points from the localized network.
When you grab coordinates from NTRIP/CORS to establish a base point different from what was used when the control was setup you will see shifts unless you observe the point for at least 60 minutes. It also needs to be verified that the GNSS coordinate from how the base for the drone was set matches the coordinates a rover from the ground survey would shoot. It’s usually best to get their coordinate and manually enter it into the base.
Here is part of my .gpx file. 3d Survey has a geotagging workflow through MissionPlanner. This software does not seem to accept a binary log file from the phantom four RTK. I am entering the base stations NAD83(2011) coordinates into RTKLIB and then generating a .pos file. This should match the drone as the drone is flying on NAD83(2011). 3dSurvey handles the conversion to state plane coordinates.
Everything that I have learned about the system up to this point says that the P4RTK is WGS84. Looking for similar configurations, for my education. I will never buy a P4RTK, but maybe the next version…
“So it turns out the issue was the post processing software we were using was assuming the data was in WGS84, even though the CRS was being set to NAD83. There was simply no way to define the coordinate system of the exif input. While using the local base stations, our lat/lon values were stored as NAD83. This caused a datum shift of around 2-3 feet. Once I switched to a post processing platform that supported alternate input datums, our RMS went to around 3cm horizontal and 5cm vertical.”
This is fantastic. Just what I’ve been looking for. I’m going to try it out with my M300. I cut and pasted this entire process into a word doc…cause I’ll forget where I found this.
Thanks GregO
