DJI Phantom 4 Pro - 3D GCP process to 20-30mm, but point cloud misses them by 500mm

Hi all,

 

I have been using Pix4D since 2012 with the original Sensefly Swinglet, moved on to the Ebee and now use the DJI Phantom 4 Pro (P4P) to make survey accurate contour maps. My experience in this field numbers in the thousands of projects flown and mapped.

I have come across an issue lately processing jobs with the P4P where the Quality report will show all green arrows, the GCP residuals will be 20-50mm but in the ray cloud editor you can visually see that the 3D GCP are not passing through the point cloud surface, and 3D check points in the middle of the data set are up to 500mm below the point cloud. Even the residuals for the check points report they are within 20mm but clearly are not.

This is further proven with comparison to conventional ground survey using the same control, and comparing the TIN surface with Pix4D cloud surface and find the surface ‘bends’ from the ground control through the middle and back again. Where the GCP check within 20-200mm of the point cloud (but report shows 20mm) and the check points are withing 500mm (but the report shows 20mm).

Clearly this is not supposed to occur, there should be a flag or error somewhere but on the surface it is a successful project, but to a qualified surveyor like myself it fails the simple test of simply not agreeing with independent checks. This is at least the 10th time I have seen this happen, in the past I have manually edited the cloud in a crude manor to make it fit for purpose in our survey software, or re-flown the site with the exact same specification and it has worked. Not an ideal solution.

I would like to upload and share the result in hoping to uncover the issue that systematically appears. Below is a screen shot of what Pix4D consider within 20mm 

 

 

Alex Symonds Today at 10:43

I think I have resolved the issue.

The EXIF data for each photo showed the altitude to be approx 45m. This is not correct, and as with most DJI drones I don’t think this is ever accurate and its hard to tell if it is barometric altitude or height above ellipsoid. In either case this is neither.

I knew the ground level of the site from our ground survey, and knew the height AGL we flew the mission (400ft/121m) and used the EXIF out and EXIF in command during the project setup phase and manually offset the values to the correct altitude (158m).

I also remove the second grid of Photos (as I think the altitude of the second pass was also incorrect) and reprocessed, this completely resolved the bend in the data.

My problem now is how can PIx4D claim to produce a QA report that shows all the data to be correct and accurate when clearly it isn’t. There needs to be more detailed analysis into the data set to detect such anomalies caused by consumer grade drones.

 

This is the bad data (500mm bend in shape of surface vertically)

This is the fixed survey with correct EXIF data heights and cross-checked with independant ground survey

If you can tell the difference in the reports without knowing, your doing better than I am.

Hello Alex,

Indeed as you already mentioned, the images that are saved on the drone’s SD card are geotagged by DJI. Lat./Long. coordinates are reliable in the image EXIF, however, there might be some inaccuracies for the altitude depending on the location where you are mapping. This is a known issue of the DJI drones. Note that this is just an offset meaning that within the model, the accuracy is not affected, only the absolute location is. 
As a consequence, we always recommend processing with ground control points (GCPs) in order to fix these uncertainties.

However, when GCPs are used in the project the elevation of the model is corrected. The vertical accuracy of the model in this case should be in the range of the GCPs accuracy. 
What is the accuracy of your GCPs in the first project? Are they homogeneously distributed over the project area?

The quality report can provide a first indication of the quality of the reconstruction but to better assess the absolute accuracy of your outputs we highly recommend using check points. 

 

To better advise on the case that you did not edit the EXIF data, I would need to see the full quality report. Are all the GCPs off by more than 100 mm?

Regards, 

I am currently discussing the issue with Rhea from support. The control points are in each corner, 4 corners of the project (it is basically a square.

The residuals of the control are ok, the data passes through the control within 100mm even though the report says they are more like 20-50mm. This however is not the problem.

The problem is the independent check shots are 500mm out in the centre of the project.

I corrected the issue once both geotags where corrected to be more closely aligned with their true altitude, 60m AGL and 120m AGL. The independent check shots agreed withing 30mm then.

Even with the EXIF left as us, Pix4D still thinks the cameras are separated vertically by 20m, but in the corrected model they are separated closer to 60m as they where flown in the real world.

There must be an issue with the false EXIF tags being combined with flights at two different altitudes.

Hello Alex,

I have discussed this issue with my colleague Rhea.
She already has the dataset and she will come back to you with her findings as soon as she has more insights on the issue.

In case, that the source of the issue is not project-specific and will be helpful for more users we will post our findings here.

Regerds,