If you follow my pages on social media (Look for SGEyeUKLtd on Facebook, Instagram, LinkedIn and X), then you may have read my post from 27 October, where I carried out some testing with the DRTK3. In that test, I wanted to see how accurate it was when compared with Networked Transport of RTCM via Internet Protocol (NTRIP) RTK. The data was processed using Ground Control Points (GCPs), and the results were very good, giving me confidence in using the DRTK3.

​

However, when I processed the same dataset again—this time without the GCPs—I saw a difference in ground level of about 1.7 m, which corresponded to the height of the tripod and antenna for the DRTK3. This raised more questions in my mind.

​

Most of you will understand how RTK works, so I won’t go into that here. What is important to know is that when a base station broadcasts its signal, the reference point is the Antenna Reference Point (ARP)—typically the centreline of the antenna at the mounting surface. The GNSS signals, along with the timing differences between those satellite signals received by the drone (rover) and the same satellite signals received by the base, are used to calculate corrections.

​

When using the DRTK3 as a base, there is no way to specify the pole or tripod height in the mobile app. Assuming it uses GNSS to calculate its own X, Y, and Z position, those coordinates will correspond to the antenna height—not the ground level—because there is no ARP offset applied. Let’s call this the calculated point.

​

This may not cause an issue if processing with GCPs but what happens if you cannot use GCPs—for example, if you cannot safely access the area to lay out ground control point? (Not that a competent drone pilot would willingly choose to omit GCPs!)

For more information on the use of GCP’s please see my other pages.

​

Note: For this test, I’m only referring to GCP’s and not Check Point (CP’s). Physically they are the same, a marker on the ground. But only GCP’s are used in the processing of the raw data and so only they will have any effect on the processed data. CPs are used to check the accuracy of the finished data at specific points.

​

DJI does offer a work around for this. If you set the DRTK3 up over a known point and enter those coordinates for that point into the Pilot 2 as the DRTK3 location, they will correspond to the ground level, because the rover that originally surveyed the point accounted for the pole and antenna height.

​

What I wanted to know was how much of a difference it would makes in practice. Would setting the DRTK3 over a known point and manually entering the coordinates result in better accuracy compared with letting the DRTK3 calculate its own position? If so, would the results be comparable to traditional NTRIP RTK, even without processing the dataset with GCPs?

​

Time for Another Test.

This test consisted of creating a known point and three flights over the same area using the same drone/camera set up and the same flight plan in Pilot2. Before flying, I created my known point.

Creating a Known Point

This was not a traditional surveying method—letting my GNSS receiver collect 24 hours of data was not an option—so I worked with what I had.

I secured a GCP on the ground and set my tripod over it with the Emlid RS2+ mounted on top. Using the optical plummet on the tribrach, I centred it precisely over the GCP and using the circular bubble I ensured the unit was vertical. I then measured the height from the GCP to the base of the RS2+ and recorded this in the Emlid Flow app as the pole height. I logged observations for 30 minutes.

I then removed the RS2+ and replaced it with the DRTK3, again checking both the optical plummet and circular bubble to ensure nothing had shifted.

​

The Drone

​

All three flights were carried out using my trusted M300 RTK fitted with a DJI P1 and 35 mm lens. The flight plan was created in Pilot 2 and not changed between flights, except for the RTK correction source or base-station location (coordinates when the DRTK3 was allowed to set up on its own and those imputed as the known point).

All datasets were processed in Pix4Dmapper, with no changes to processing settings except whether GCPs were used.

​

The Three Flights

Flight 1 – Control (Yellow ground model in N4ce)

This flight used my standard workflow: GCPs placed across the site, RTK via NTRIP during flight, and post-processing using the GCP data. This dataset served as the control.

​

Flight 2 – DRTK3 Calculated Point (Red ground model in N4ce)

This flight used the exact same mission plan, but corrections were provided by the DRTK3 operating as a base station using its self-calculated GNSS position.

​

Flight 3 – DRTK3 Over Known Point (Blue ground model in N4ce)

For this flight, the DRTK3 was again used for base corrections, but I manually entered the coordinates of the known point created earlier, as the DRTK3 location.

​

Flight 1 was processed with GCP’s and both Flights 2 and 3 were processed without GCPs, as the goal was to understand how the base-station setup—particularly height—impacted accuracy.

 

What I Expected to See

I’m told that when you are testing/ evaluating equipment, you should not have expectations, but my hope was that the data from Flight 3 (blue)—where the DRTK3 was set over a known point—would more closely match the ground levels of the control dataset. If so, it would show that the DRTK3 can be a useful tool in situations where placing GCPs is difficult or unsafe.

​

What I Wanted to Demonstrate

There is always debate about the use of GCPs, How many you need and where they should be placed etc. While it was not my intention to answer all those questions, I wanted to reinforce how important GCPs are even when using the DRTK3 and show that selecting the right number and placing them correctly is just as critical as planning the flight itself.

​

The Results

To assess how the DRTK3’s base-location method affected the final data sets, I used N4ce. I imported all three point clouds, generated a ground model from each, and combined them in a single environment—yellow for the control, red for the DRTK3’s calculated point, and blue for the DRTK3 set over a known point.

​

The first thing I noticed was that both the red and blue models showed horizontal misalignment compared with the control—up to 6 m on the X axis and 2 m on the Y axis in some areas. However, the blue model (Flight 3) aligned more closely with the control than the red model did. This suggests that setting the DRTK3 over a known point does improve the result.

​

Vertical alignment also varied. Depending on the location, height differences ranged from a few millimetres to a few metres. Again, Flight 3 (blue) generally performed better than Flight 2 (red), though still not perfectly.

​

But does that mean the data is unusable or the test failed?

The simple answer is no. The test demonstrated that setting the DRTK3 over a known point does provide slightly improved results compared with allowing it to self-calculate its position. However, the improvement is not enough to eliminate the need for GCPs. In fact, these results highlight just how important GCPs really are in processing drone data.

​

Without them, there is no reliable way to verify your dataset—or identify where cumulative errors begin to creep in.

If you'd lick to see the full document the please download it via the link.