I'm curious to learn what other's experience has been with drone PPK processing.
I've been flying a DJI drone for about 5 years, until recenlty without RTK module, always setting GCPs on site and then processing with Agisoft. Earlier this year I got one of the new Matrice 4E drones with RTK module and am currently proofing workflows to sort out the optimal flight plan for different sites. I'm pretty happy with the RTK method, results agree well with ground truthing and checks. At the office we have a reference station with a NTRIP data stream which is the quickest and easiest if we're close to the office. I've also set up a GS18 with a static SIM card to be able to stream corrections from it via NTRIP in the field. All good so far, but what about sites where either a) I don't have exisitng control, or b) there is no cellular service. PPK of course, but that's where I'm running into some hiccups that I'm wondering if anyone could comment on their experience.
Case in point, I flew a small site recently where I was able to use RTK corrections but wanted to try PPK to see how things compared. I used Emlid Studio, which has a pretty straight forward workflow to update the EXIF tags in the photos and then process with Agisoft as per usual. What I found was the results were not great. Heights were off by ~8cm on average and 2D was a couple of cm's off too. Weird, using the original RTK tagged photos instead, everything looks good when checking to ground control. So, then I thought it's probably because I was logging data at 5s interval at the base while the drone logs at 5Hz. Went on another site today and again had RTK, but this time made sure to set the data logging interval to 0.2s / 5Hz on the GS18 to match what the drone is recording to try PPK again. Results were similar to before, vertical differences between RTK tags and PPK tags is in the 10cm range this time. This also happens to be the phase center offset for the GS18, but the software claims it's using the antenna file to account for this so I'm not sure if this is the issue or just a coincidence.
Next, I tried using a different PPK processing software, KlauPPK, to see if it was something with Emlid Studio. Oddly I get pretty much identical results with both PPK drone processing software.
Both times I was flying at around 30-40m flying height at 3-4 m/s flight speed.
For the first flight I was logging static at the base at 5s interval, while the RTK corrections received for that flight were at 1s interval.
For the second flight I was logging static at the base at 0.2s interval, and RTK corrections also 0.2s interval.
In both cases the PPK heights were mostly higher than RTK, although there was some inconsistency where some photos had PPK positions slightly lower than RTK positions.
I was under the impression that PPK was supposed to provide "better" results than RTK. Is this not the case? Or am I missing something?
I read this morning on two websites (DJI and DroneDeploy) that they recommend at least 10 minutes of flight observation data to get accurate PPK results. Both of the test flights completed were only about 2 minutes in duration.
When asking ChatGPT, which is what it is, I got the response below. Looks like I need to design a better test case with a longer flight to really compare PPK with RTK. Early conclusion is that for short flights, RTK will get the better results than PPK. Time to read up more on PPK processing, I had incorrectly assumed it would work similar to RTK, just done with stored observations instead of in real time.
So, while PPK can technically run with less than 10 minutes, accuracy and reliability dramatically improve with at least 10+ minutes of good-quality, continuous data — especially if you're aiming for centimeter-level precision.
PPK mode is highly advantageous in areas with poor mobile communication signal coverage.
You can deploy a DJI D-RTK 2 Mobile Station on-site.
Determine its precise position using static measurements or RTK corrections (even partial/intermittent ones).
Calculate the base’s coordinates and transmit corrections to the drone locally
@land_odse Emlid Studio is free software, it uses kinematic processing to solve flight trajectory and is able to update tags of photos. I think this software is working fine and is easy to use. My next test will involve a longer flight of at least 10 minutes with a nearby base set up on existing control and logging at high rate while transmitting RTK corrections so that I can do a better direct comparison between PPK, RTK and ground control points.
One of my first flights with the M4E was on a larger site where I captured ~3000 photos, and since the M4E came with a 1 year license for DJI Terra, I did try it out but I think it was too much data for it because it was running into reconstruction errors during processing, which according to quick Google search appeared to be a memory-related problem due to the large number of photos. Agisoft Metashape worked just fine for that job, no memory issues at all so I've just kept using that software since I already had a license for it. The PC I'm using for the processing has 96GB of RAM, NVIDIA RTX 4070 graphics card with 12GB of memory, a 20 core i7 processor, and large SSD drive, so the problem with DJI Terra I don't think was due to hardware used for the processing.
For that longer flight, approx 2 hours total in 3 sessions, I was using RTK corrections from my office reference station which was ~11km away. The logging rate for this reference station is 15s. I did run a quick test this morning with some of the data from that mission, and differences between RTK and PPK there are in the ~4cm range vertically. But, we have other variables there like distance from reference station and logging rate, that I want to eliminate for a proper test.
I have completed additional testing to satisfy my curiosity and to ensure our workflows deliver optimal results.
Two tests were completed with the DJI Mavic 4E, both were ~18 minutes of flight time:
- Test 1 - RTK corrections were received from a reference station ~300m from the project site. This reference station has a Leica AS11 antenna and a Leica GR30 receiver. NTRIP rate is 1s, and static logging rate is 15s. The reference station has a well established known position.
- Test 2 - RTK corrections were received from a reference station on site. This was a Leica GS18 receiver, NTRIP rate was 0.2s as was the static logging rate. The receiver was set up over a known point that was established with a combination of RTK and static observations to the reference stations.
Both test flights captured 328 photos, the flights speed was pretty slow at 2m/s.
Nine GCPs were set at the site, which had a gentle slope but was mostly clear of vegetation. Two control points were set in hard surfaces, three in gravel pathways, and four were set in grassy field locations with some cleaning around the GCP to flatten the area. Coordinates were established using a combination of static, RTK, and total station observations (Leica TS16). Relative confidence at 95% was sub-10mm for the positions of these GCPs.
The first point of interest was simply to perform PPK processing of both test flights and compare the PPK position of each photo to the RTK position tagged during the flight. After completing the PPK processing initially with Emlid Studio, it became apparent that Emlid Studio was not correctly applying the phase center offsets for the antennas (which I have reported to Emlid). The correlation of the discrepancies vs. APC values for the different antennas was remarkable. So, then I decided to switch to DJI Terra to complete the testing, with results that aligned with expectations. The results of the EXIF comparisons can be summarized as:
- Test 1 - Horizontal differences were minimal, a few mm at the most. The altitude, which was the primary concern, also quite minimal. On average the difference between RTK and PPK for the 328 photos was 2mm, with a standard deviation of 3.6mm. This was 1s RTK and 15s logging rate at the base for the PPK.
- Test 2 - Again, horizontal was minimal, and on average the difference between RTK and PPK for the 328 photos was 6.5mm, with a standard deviation of 7.8mm.
Great, we have good agreement between the two positioning methods, under mostly ideal conditions. So, what about comparisons to GCP coordinates, which is what ultimately really matters. The methods used to determine this was not rigorous or sophisticated but representative of practical use. Horizontal comparisons were made by importing the orthophoto into CAD and simply creating points manually at target locations and comparing those to the GCP coordinates. For vertical comparisons, the point cloud was imported into Leica Infinity and averaging the surrounding point elevations at each target and comparing to the GCP elevation. The results can be summarized as:
- Test 1, RTK at 1s - Average 2D delta was 17mm with a standard deviation of 7mm. Average vertical delta was -40mm with a standard deviation of 27mm.
- Test 1, PPK with 15s logging rate at base - Average 2D delta was 16mm with a standard deviation of 9mm. Average vertical delta was -40mm with a standard deviation of 24mm.
- Test 2, RTK at 0.2s - Average 2D delta was 15mm with a standard deviation of 10mm. Average vertical delta was +26mm with a standard deviation of 27mm.
- Test 2, PPK with 0.2s logging rate at base - Average 2D delta was 15mm with a standard deviation of 5mm. Average vertical delta was +18mm with a standard deviation of 26mm.
Again, methodology was not perfect but it served the purpose. Sharing in case anyone finds this of interest.