Questions on drone/ppk workflow

Reach Module / M+ / M2 RTK / PPK configuration
1

Hello, everybody.

we are trying to integrate reach to our drones to minimize gcps work in our mapping projects.

In this case we proposed a test zone in which we would take a matrix of verification points with a reach in survey mode connected to NTRIP (basemount at 18km).
reach at fix and mark 6 ground control points in the flight zone.

gcps

Then we would use the same reach of the verification points and we mount it on a tripod in an unknown point, we connect it again to NTRIP until it achieves fix and we activate base mode in AVERAGE FIX (5 min) reach establishes known point and in that moment we activate the logs.

We prepare the drone, Quadcopter with sony nex 5 and 16mm fixed mount lens, carries a reach on board antenna placed in the center of the sensor and captures perfectly the events of the camera, I forget to say that both units have the same configuration: GPS+GLONASS+QZSS 5HZ.

We turn on the quadcopter and plan the flight,

waypoints

and the reach of the drone also acquires data.

The flight is performed in the planned area with success, we verify images and events in the field and everything perfect 82 images obtained and 82 events captured, is a success!

Start the office work, postprocess the base logs and the drone in postprocess options we use the emlid tutorial for PPK postprocess, in base options we select RINEX HEADER POSITION.
and we get fix on the whole flight! Sounds good.

PPk

We extract the events from the camera and begin to process the images in Pix4D, we also adjust the accuracy of the labels to 0.02m.

pix4d-ppk

We imported the verification points and here begins our surprise, apparently the position of the GCPS differs a lot compared to other projects that other emlid users have published here.

gcps-mal

we don’t like the results, so we keep researching, downloading rinex data from our reference station and processing everything omitting the logs from our own database,
surprise! The results are much better and taking into account that our base is 18km away.

gcps-bien

Finally we have been “happy” because we have obtained
results-PPK
very good results taking into account that our base is 18km, but we would like to get better results with our own base.

Any idea what we’re doing wrong?

I’ve put all the files in the cloud, in case someone wants to experiment with them and give us a hand.

https://drive.google.com/drive/folders/1gFisnAPu6Qyi-XvQO2beJgUcrJzMRkmO?usp=sharing

2

Hm, your errors on the GCP’s are quite excessive, I would say.
They should be low 1-digit centimeter, down to sub-centimeter using the Reach systems.

1 Like
3

0.5m Z error? How did you collect the GCPs?

4

Collected with reach in survey mode, connetion to a static base with Ntrip corrections

5

OK. The baseline was 18km via NTRIP to your own RS(+) base. How long was each observation; what constellations; what RTCM3 messages; what sample frequency?

Across all the points collected, do you remember if your age of differential was abnormal? Do you remember if your AR ratio was low?

1 Like
6

That seems like a long distance for centimeter accuracy? I’ve never used a service so I am still learning. What is recommended?

7

The observation was about 35 min (base) constellations are gps+glonass+qzss to 5hz

The age of difference I don’t remember, sorry. Neither does the Ar ratio.

9

Today we went back to the field to check the GCPS taken last day, fortunately they were marked with spray and are still visible.
We have made a new capture of GCPS, this time connected to a closer station (13Km) Fix, ar-ratio at 999.9 the results differ around 1.5 - 2cm in all points, so we believe that GCPS are good, in the image you can see an example once imported into our GIS software.
gcps-comparison

we believe that our problem lies in the collection of PPK data between the own Drone-base, we will continue testing after the entry of the new year.

2 Likes
10

This seems like a Pix4d processing issue. What version are your running?

11

Hi, version 3.1.18
Do you think it could be that?

12

Well, I was able to try the latest version of Pix4D and the result is the same, so it’s not a software problem.

13

This sounds like the same thing I went through, and it turned out to be the camera calibration. X and Y were good, but the Z was way off.

14

Can you upload Pix4D processing report? Sounds like what @kineo said and what I was going to suggest was camera calibration. Are you able to reoptimize project and is your camera model in the Pix4D database? Rolling or global shutter? Your errors in GCPs suggest this.

Other suggestion on Emlid side was a possibility in introducing a shift in coordinate systems when pulling from Rinex header from reference stations, are your coordinate systems consistent all around?

15

Was the GCP collection a constant fix all-around? Any post-processing? With the system I have I have been told to run GPS only @ 14hz.

17

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.