Support Website Contact Support Blog

Desktop, Pix4Dmapper, Survey elevation error

Hi again,  I have surveyed one of our company’s coal stock yards. 

I used several GCP put in place with RTK GPS. 

The error I have found is the point cloud is on average 300mm higher than where they should be, when compared to the check survey done on foot with the RTK GPS.

Unlike the previous issue with the camera calibration this has shifted the whole survey up 300mm and NOT a scale problem.

Whats concerning is that the GCP and the check points do not show there being a problem.

quality report:

https://www.dropbox.com/s/zpnp2899tupnpnw/Brenkley%20Coalyard%2025-01-18_report.pdf?dl=0

any ideas?

 I’m experiencing the same problem, but mine is about 70mm.   The last two projects, different drones/cameras as well.  

Hi there,

I don’t know if you had a direct answer from Pix4D, but it looks like a known bug that I experienced too:

 

Version 4.1.24

_ Bug fixes _

  • Fixed issues with coordinate systems:

    • incorrect offset between the GCPs initial and computed elevation when the vertical coordinate system of the image geolocation is different than the vertical coordinate system of the GCPs.

You have to download the latest version and reprocess to solve that for sure.

Maybe you could shift the whole point cloud of the average vertical offset between your GCPs and the calculated position, but I don’t know wether the said offset is homogeneous or not. I’m still expecting a feedback from Pix4D, it would save me a lot of time as it happened on a 3500 pictures project.

I did shift the whole thing 300mm but what gets me is that the reported error between the station and the calculated one was small.  So it only came to light when I over laid it with a conventional survey.  I’m trying to prove the accuracy of the drone system and this isn’t helping!

I’ll have a go at reprocessing it with .24

I saw that release and just assumed that the error is only in the  displayed value in the sidebar…not sure why I made that assumption. 

 

I was using version 4.0.25 and just downloaded version 4.1.24 and installed.  I get the usual pop-up when I open an older project saying I need to upgrade the project to the newer version and asking if I want to create a backup first.  When selecting either option, I get an error message saying the project can’t be upgraded. 

I just rolled back to 4.0.25

I didn’t re-run the project, so I don’t know if I would have the same error message, but I had an answer from P4D team, and the offset is homogeneous.

You can calculate it:

Offset = GCP GPS Z - calculated Z - quality report error on that GCP.

It should give you the same number for every GCP, in a range of 2 or 3mm, so you can do it on just one, and maybe check on 1 or 2 others.

The orthomozaic is not affected, so you can keep it. You just have to translate your whole point cloud of the offset using another software (I did it with 3D Reshaper, I didn’t manage with cloud compare though), and that will do the job.

Thomas - 

I only checked on one project, but the formula you posted gives me an average of 0.03’, but the actual error is 0.216’ when checking the outputs in CAD & GIS. 

Ok, I’m sorry I misread your post, in fact my offset was much bigger (40 meters or so…)

 

On my side, here is what happened:

I processed a project using a 4.0.XX version, and everything seemed OK, including errors in the report.

When I began working on the LAS file, comparing with a former survey, I found out a big offset between the 2.

When loading the pix4D file, it showed the calculated altitudes didn’t match with GCP coordinates, with a similar offset everywhere, and I solved that by the process explained before.

 

Derrick, I’m not sure about what’s happening to you, but it’s not the same bug obviously. The error of 0.216 is between which values: former survey points? present GCPs? project data in Pix4D? Outputs?

Peter, I suppose your present GCPs’ height match with the former survey, right? Are the drone survey pix4D project results homogeneous with the former survey results, so that only the output (point cloud) wouldn’t match? If that’s not the case, a RTK bias can also happen during the whole survey.

 

 

All of the above, really. 

 

Ground control was tied with RTK on VRS, including common ties to 3 monuments. Control was  shifted down to the city’s vertical datum and to match previous surveys. Those adjusted coordinates were then imported into Pix4d and included during processing. 

In the quality report and inside pix4d, the vertical discrepancy is listed as 0.01’, but you can visually see the 0.2’ offset in the raycloud editor and the elevations on the nearby points reflect this as well.  In GIS, the same control points from the same text file also show +0.21’ above the DSM, and the gridded DSM XYZ file reflects the same findings when importing into CAD. 

Did you set exactly the same parameters in the vertical reference system of the project outputs and the GCPs? What did you set as parameters there? If not, I would leave them both to Geoid altitude above WGS ellipsoid set at 0 and give it at try…

Per pix4d documentation, I don’t adjust the vertical parameters when including GCPs. 

Roger that. This is the right thing to do, I don’t know how to help any further, I never experienced such an error. I’ve been thinking about your problem, but I couldn’t find any other clue. Hopefully the support could give you better hints to fix your problem?

Let us know about your investigation.

Hello all,

As general recommendations in cases that you observe inaccuracies between the model generated by Pix4Dmapper and ground truth data, you could check the following parameters:

  • the accuracy of the ground truth data: in case you use GCPs or check points verify that the coordinates are correct

  • the selected coordinate systems (horizontal and vertical) in Pix4Dmapper are correct: 202560029.

  • the accuracy of the image geotags is correctly set in the software: 202557949.

  • the accuracy of the equipment used

The quality report generated after the first step of processing is a very useful tool for a first assessment of the quality of the reconstruction: 202558689.
In case you do not manage to find a solution using the quality report and the above mentioned tips, please submit a Support request if you have a valid license.

Regards,

Hi,

i also checked the new calculated points with RTK and got an difference in height of 50cm. It seems the problem is an Projectupdate from 3.1.23 to 4.0.25?

Greets,

Stephan