Support Website Contact Support Blog

DJI Phantom 4 RTK and Pix 4D Georeferencing Error

I recently performed a test flight with the new DJI Phantom 4 RTK, along with the DJI basestation. The flight itself was great, and the images are georeferenced, but the cloud created in Pix 4D is not georeferenced correctly. The X and Y are around 5 feet off, while the Z is closer to 110 feet. Has anyone else experienced this? Is there a specific setting inside of the processing options that needs to be changed to use the corrected RTK data?

Hi,

More on the optimal workflow when processing DJI Phantom 4 RTK datasets can be found in this community post:
[Desktop] Processing DJI Phantom 4 RTK datasets with Pix4D

I would recommend checking the FAQ section in that post for more information. 

Best,

Thanks Blaz. I followed the provided workflow and still experienced a similar error. (see photo, sorry about the photo quality)

This quality report was generated after entering my GCPs as check shots and re optimizing. If I change the check points to gcps and re optimize the average rms error for Z is 0.404ft.

For comparison, I also flew the site with a standard Phantom 4 pro WITHOUT RTK and using GCPs my average rms error for Z is 0.159ft.

I was hoping the P4RTK would have better results if not much better with out without GCPs. Is there a mistake I could have made in initial processing or camera setup?

Thanks

Indeed, the error you get is higher than expected. Especially the Error Z value is high.

Could you provide the following information:

  • The horizontal coordinate system used for GCP measurements.
  • The vertical coordinate system used for GCP measurements, for example, the name of the geoid model. 
  • What was the speed of the drone during the image acquisition?

Please also upload the .p4d file and the quality report here.

Thank you.

The relevant information has been uploaded. 

Thank you for uploading the files.

After processing the dataset I also get the offset in all three directions. 

When it comes to the vertical offset (Z) it is most probably caused by the fact that the GCPs are measured in the respect to Geoid12B that is not directly implemented in Pix4D. More in the FAQ of the [Desktop] Processing DJI Phantom 4 RTK datasets with Pix4D community post.

Do you by any chance have the GCPs also in the WGS84 coordinate system (latitude, longitude)? I would like to check if the same offset appears when using the coordinates that are not yet transformed into a projected coordinate system.

Hallo Blaz

wir haben das gleiche Problem wie @CEC_UAV_Nashville
gibt es nun nach 9 Monaten schon eine Lösung für das Problem?

Wir hier in Bayern wählen als Ausgabe Koordinatensystem EPSG Code 31468 (DHHN, GK3 Zone 4)
Auch bei uns wird in Schritt 1 eine Verknüpfungs Punktwolke generiert die korrekt zu sein scheint.

Wenn wir dann GCP`s, (2-fach gemessen mit Trimble R8 GPS) verwenden, liegen die Positionen zwischen 10-20cm in x,y und 50-150cm in z entfernt. Nachdem die Bildmessungen erfolgt sind und reoptimiert wurde, erhalten wir im Qualitätsbericht einen RMS von 0,549 (rot)
Es wurde bereits 3 mal geflogen und verschiedene Kamera Neigungen ausprobiert, ohne Erfolg.
Wir haben auf die Phantom4 RTK gesetzt, da wir ein Vermessungsbüro mit Pix4D Lizenz sind und genauere Ergebnisse als mit der herkömmlichen Mavic2Pro erzielen wollten, die bei 90% unserer Projekte ein linear rolling Shutter Problem hatte, auf das wir in einem älteren Post erst aufgrund Ihrer Hilfe lösen konnten. Um mit der drohnenbasierten Vermessung genauere und zuverlässigere Daten mit Pix4D erzeugen zu können, benötigen wir dringen Lösungen.
Wir bitten um Ihre Hilfe.

from google translater

Hello Blaz

we have the same problem as @CEC_UAV_Nashville
Is there a solution to the problem after 9 months?

We here in Bavaria choose as output coordinate system EPSG Code 31468 (DHHN, GK3 Zone 4)
Also in our case a link point cloud is generated in step 1 which seems to be correct.

If we then use GCP`s (2 times measured with Trimble R8 GPS), the positions are between 10-20cm in x, y and 50-150cm in z. After the image measurements have been done and reoptimized, we get in the quality report an RMS of 0.549 (red)
It has been flown 3 times and tried different camera inclinations, without success.
We chose the Phantom4 RTK because we are a Pix4D licensed survey office and wanted to get more accurate results than the traditional Mavic2Pro, which had a linear rolling shutter problem in 90% of our projects, which we only post in an older post Could solve help. In order to be able to produce more accurate and reliable data with Pix4D using drone-based surveying, we need solutions.
We ask for your help.

Hallo Chris,

(DE) Zur Info haben wir auch ein Online-Forum für Deutschsprachige: https://community.pix4d.com/c/pix4d-international/pix4d-auf-deutsch. Wir würden Dir herzlich empfehlen, dieses Forum zu benutzen, da es relativ neu ist und ein bisschen mehr Inhalt von den Benutzern braucht :slight_smile: .

In Bezug auf dieses Problem musst Du erstmal überprüfen, ob die GCPs in demselben Koordinatensystem (KS) wie das Ausgabe-Koordinatensystem vermessen sind. Es ist sehr wichtig, dass die GCPs mit dem richtigen KS in Pix4Dmapper definiert sind. Wie Blaz erwähnt hat, gibt es in Pix4Dmapper nur die folgenden vertikalen Koordinatensysteme: EGM 84, EGM 96, EGM 2008 Geoid und die Geoidhöhe über dem Ellipsoid. Leider haben wir noch keine anderen Geoidmodelle implementiert. Es kann sein, dass dieses Problem gar nicht an den GCPs liegt. Könntest Du vielleicht das Modell ohne GCPs berechnen, um die Qualität der Ergebnisse zu vergleichen?

(EN) For you information, we do offer an online platform for German speakers, please check it out, we would be very happy if you can contribute to its growth: https://community.pix4d.com/c/pix4d-international/pix4d-auf-deutsch

Regarding the technical problem, you first need to examine if the GCPs were measured in the same coordinate system as the output coordinate system. It is crucial that the GCPs are defined in the correct CS in Pix4Dmapper. As Blaz mentioned, we only offer the following vertical CS: EGM 84, EGM 96, EGM 2008 Geoids and the height offset above the ellipsoid. Unfortunately, we have not implemented any new vertical models yet. It can also be that this problem is not connected to the GCPs. Could you maybe reprocess the project without GCPs and compare the quality of the results?

Cheers,
Teodora

Hallo Teodora,

erst einmal vielen Dank für Ihre Antwort.
Schön zu hören, dass es Support nun auch auf deutscher Ebene gibt.

Wir haben in der Vergangenheit mit der Mavic 2 Pro gearbeitet und als Ausgabekoordinatensystem immer in DHHN, GK3 Zone 4 (EPSG 31468) verwendet. Dies funktionierte immer gut und ist das gleiche System, wie das unserer GCP`s (Passpunkte).
Seit zirka 1 Monat arbeiten wir mit der Phantom 4 RTK mit Basisstation und erhalten zumindest bei trassenförmigen Projekten, welche wir selbstverständlich kreuzweise sowie mit einer Überlappung 80/80 fliegen, die erwähnten Abweichungen nach der Implementierung der GCPs und anschließender Reoptimierung.
Im ersten Schritt berechnen wir nur die Kameraorientierungen und die Verknüpfungspunktpunktwolke.
Anschließend importieren wir die Passpunkte und führen die Bildmessungen durch und reoptimieren dann. Eigentlich ist die Abweichung zu um weiter zu arbeiten , aber gut.
Die anschließend berechnete dichte Punktwolke zeigt stellenweise doppelte bis dreifache Abbildungen in Z und scheint in sich leicht verkippt und dreht zu sein. Die Passpunkte wurden mit Trimble R8 über 30 Messungen pro Punkt bestimmt und an einem anderen Tag erneut gemessen und passen auch.

Vielleicht können Sie ja dieses Thema auch auf der deutschen Supportseite teilen.

Mit freundlichen Grüßen

C.Herrmann