Support Website Contact Support Blog

Processing DJI Phantom 4 RTK datasets with Pix4D

For datasets acquired with DJI Phantom 4 RTK (P4RTK) we recommend the following workflow:

Creating a project

1. Configuring the image properties:

  • (RTK) Image geolocation, horizontal and vertical accuracy is automatically recognized when importing the images.
  • (PPK) After PPK postprocessing in a third party software, accurate image geolocation can be imported using the Image geolocation file (.csv, .txt, .dat). If necessary, edit the Accuracy Vert/Horz column to define the actual accuracy values.
  • The optimized camera parameters for P4RTK (FC6310R_8.8_5472x3648) are already included and automatically recognized in the internal camera database.
  1. Configuring the image coordinate system:

In the Image Properties Editor, change the vertical coordinate system to  ellipsoidal heights  instead of automatically detected geoid heights (EGM96). To do so:

Edited on January 24th 2019

With the latest Pix4D Desktop 4.4.9 Preview version, the image vertical coordinate system is correctly detected automatically (WGS 84 Ellipsoid). With the previous versions, the above mentioned workaround needs to be applied.

Processing options

There is no need to change the default processing templates, e.g. 3D Maps, and the following processing options can be kept:

FAQ

Can I process with the accurate geolocation pipeline?

  • Accurate geolocation and orientation pipeline can be used when both, image geolocation and orientation, are precise.
    We recommend using it for large datasets (faster processing) and when the dataset contains homogeneous or complex visual content (forest and dense vegetation, flat terrain with agriculture fields, snow, sand, and water surfaces). 
    More in the FAQ on the accurate geolocation pipeline.

Is it possible to use another vertical datum besides EGM84, EGM96,  EGM2008 or the ellipsoid of the selected horizontal system?

Do I need to enable the linear shutter optimization?

What could cause a big offset when comparing the results with checkpoints?

  • The horizontal offset could be caused by the horizontal grid corrections and transformations.
    In some cases, when flying fast, close to the ground or in high winds, enabling the linear shutter optimization could reduce the offset. 
  • The vertical offset could be present due to wrongly selected vertical coordinates system or custom geoid models
    In case the optimized camera parameters are far from the initial values, e.g. focal length, we recommend using the All Prior processing option. 

Further reading:

11 Likes

Am I supposed to enter a value in the " Geoid Height Above WGS 84 Ellipsoid" box or leave it set to 0?

Hi,

In most cases, the value can be set to 0.

I would recommend using the Geoid Height Above Ellipsoid value when the heights of the results need to be based on a vertical datum that is not defined in Pix4D. 

For example: 

  • Geoid Height Above Ellipsoid = 0 [units], when using the EGM84, EGM96, EGM2008 geoid models (all 3 are already defined in Pix4D) or the automatically detected ellipsoidal models (by default defined in the coordinate system description).
  • Geoid Height Above Ellipsoid = x [units], when using a geoid model that is not defined in Pix4D, for example, GEOID12B (US), OSGM15 (GB).

In the second case, you should know the shift/offset between the current vertical coordinate system and the target coordinate system. This shift can be added in the Geoid Height Above Ellipsoid option.

More in the When to use the  Geoid Height Above the Ellipsoid  Function?  and How to define Pix4D outputs with respect to a Geoid model articles. 

Best,

Hi, I have my own geoid for my country in TIF like original 3 geoids implemented into Pix4D mapper. Can you change TIF file like this to fit into Pix4D? This would help in my work combined wit ph4 RTK.

At the moment it is not possible to import a geoid model (.TIFF) and I would recommend using the offset in order to shift the results (Geoid Height Above Ellipsoid option).

I forwarded the suggestion for importing the geoid models to the product managers in order to consider implementing it in the future releases.

What horizontal and vertical accuracy can be achieved with P4 RTK without GCP’s?

Hi Blaz,

I have used your method with success to shift my ellipsoid heights to the NAVD88 vertical datum using Geoid12B by entering a geoid height in " Geoid Height Above WGS 84 Ellipsoid"  box that best defines my project area.

I have done it by adding the geoid height to the image coordinate system upon image import and then outputting in my desired coordinate system with a 0 value entered for geoid height.  This method allows me to input my GCP’s in NAVD88 orthometric heights.

I have also done it by leaving the image coordinate system geoid height at 0 and then adding the geoid height to the output coordinate system.  Using this method I have to bring in my GCP’s in WGS84 ellipsoid heights.

I see both ways work, but does Pix4d recommend one method over the other?

I ultimately think the best method will be to leave everything in ellipsoid heights and then use NOAA’s VDatum to apply Geoid12B to the .las file and shift the data to NAVD88.  I think this would be more accurate for a large project area.

Blaž, I’ve been using the P4 RTK since release date back in November. I’ve been having a hard time to get this to work because I always get different suggestions from Pix4D. My biggest problem is the elevation in the datasets, is always off by a couple of feet. I was told to use Arbitrary because the elevation was corrected with the photo thru Propeller PPK processing, this is close but when you hover over the GCP the elevation is higher all the time. Its been almost 6 months since the release of the Phantom4 RTK and Pix4D still don’t have a streamlined process for the data coming from this drone. Please, I need help with this process. I’m using NAD83 Florida East (NAVD88 height)

Abe

1 Like

@Andrew, as you mentioned, both options will work and the results should be the same if the same Geoid Height Above Ellipsoid value is used.

Using external tools as NOAA’s VDatum would indeed be better for larger projects where the geoid separation cannot be represented with a single value.
A good workaround would also be to transform the heights of the images to orthometric before processing the dataset Pix4Dmapper. This can be done with a custom file that contains the transformed coordinates and using the “From File…” option in the Image Properties Editor. 

A more detailed workflow on how to import custom values is available in the Phantom 4 RTK - PPK processing community post.

Hi Blaž,

We’ve been doing extensive testing with our P4PRTK and this workflow, and have observed Z error that is correlated with altitude.

Please see this thread on the DJI P4PRTK forum for details:

https://forum.dji.com/forum.php?mod=viewthread&tid=187711&page=1&extra=#pid1854446

And this one on the Agisoft forum posted by another user:

https://www.agisoft.com/forum/index.php?topic=10068.0

Can you please comment on best practices in Pix4D to address this issue? Should we be including oblique imagery, or is there some other processing workflow in Pix4D that we should implement, such as creating a custom camera calibration?

I’m happy to provide datasets, Quality Reports, etc. if you would like to have a look.

Thanks,

-pat

 

@ Blaz & @Andrew-

 

As @Lukasz suggested, Pix4D should allow import of a Geoid Height raster or text file rather than requiring a single value. These products are available from NGS or can be created easily by the user, and can account for the variation in Geoid height over the study area.

I understand the method you described using “From file…” to alter image altitudes, but this is an inefficient workaround compared to just being able to point at a file representing the Geoid height spatially.

Does anybody pay attention to this forum anymore?

I posted a question regarding altitude-dependent Z error and the need for camera calibration 2 weeks ago and not a peep.

 

Maybe I should create a new thread?

 

C’mon, Pix4D, what do you think?

Hi,

I am okay using WGS84 as an input coordinate system.
But will it effect my results if I want OSGB as an output coordinate system?
My results seem to be horizontally offset!

Any help appreciated!

Hello,
You have already opened the support ticket so we will deal with the issue there. If there is anything new that is helpful for others, I will share it on this post. Your’s output coordinate system should not be the reason for the issue.