Support Website Contact Support Blog

GCP Computed Position wrong

 I added my GCP after processing step 1. I have re optimized and even reran step 1 and am confused. The 3D GCP should stay static and the point cloud should be dragged up to the location? 

Instead it seems that the point cloud is being dragged down to the computed position. 

 

The elevation of this point should be 808. 

 

Any headway? There’s an argument  within your block. If its the same magnitude and direction with all your GCP you might look to the vertical datum of your GCP versus wherever the ABGPS values came from. I’m assuming there are ABGPS coordinates for the photos being used? They usually aren’t great.

The airborne GPS values in Z could be way off from your measured GCP Z, even when everything is working properly. Different datums, ellipsoidal versus orthometric heights, etc… You could assign a really big value to the ABGPS Vertical Accuracy and see what happens.

Oh, and watch for the rod height in the field being factored propelrly. That would not be the first bad HI that snuck through!

Steve

I have not gotten back to the project yet. We use the ABGPS points off our Inspire 1. I run through processing step 1 and then enter the GCP’s we surveyed. The accuracy of the GCPs seem to be right and we did a second QA survey check on the site a few days later to double check points. I do need to double check Vertical datum heights vs. Pix4d.

Thank you for the response.

 

Matt

Hi Matt,

I’m curious about the use of ABGPS (Airborne GPS) insofar as your Step 1. processing options were chosen. Please confirm what is known and correct my assumptions as need be:

  • The DJI Inspire 1 is not survey grade; it geotags images with 2D GNSS fixes; i.e., only x and y; and uses its barometric data for geotagging the z. I’ve seen camera positions to be hundreds of feet off from reality using the Inspire 1.
  • Step 1., Processing Options in Pix4Dmapper are set with the all of default settings for the mapping project in question. (?)
  • The 9’ bias in z that you’re reporting is seen in all GCPs. (?)
  • All of the ground control points have been surveyed with precise survey grade precision; e.g., Dual Freq. GNSS RTK. (?)

If you could, please post a screen snippet from the QC Report showing Geolocation Details for the project in question.

 

 

Also, please post a snippet of the control layout/ distribution. GCP positions will influence the processing.

 

 

Random thoughts and in addition to what Steve has mentioned…
Image quality matters. The lack of contrast of the (3) mostly white images in your image above may exacerbate issues while processing. While I haven’t deliberately used overexposed images in my tests over the past 2 months, I did have a set of images which were in general, underexposed (Manual Exposure, Canon 40D) toward the conclusion of collecting nearly 300 images, shot an hour before sunset when Exposure Values change quickly. I also have had sets of images which were shot under bright late morning conditions using the camera’s Automatic Exposure setting instead of Manual Exposure (Canon 40D). In both of these situations, and using Adobe Camera Raw, the entire set of images were Auto Leveled (and Chromatic Aberration) removed and saved. Lightroom can also batch process levels. If you have ACR or LR, you might try processing again after the images are auto leveled to see what, if any impacts there are in the post-processed results. Just be sure not to change any aspects of image size or lens properties.

It’s good that you did a second set of RTK observations on a different day, but you may well know, GNSS RTK can produce bad fixes, poor RMS values and unrepeatable positions depending upon a wide variety of issues, most notably due to multipath. If your RTK gear is able to generate a statistical report, and you can see one outlier with dubiously high RMS values (particularly on both days), try changing its Type from GCP to Manual Tie Point (MTP) and see what happens. In this test above, I was looking at the validity of points on the outer edges of the project - more on that later.

 

If your GCPs are from real survey data; i.e., tied to a known Spatial Reference System, the Vertical height system; e.g., NAVD88, GEOID12B, already has taken worries about geoidal separation into consideration so I’m not sure what you meant by the “need to double check Vertical datum heights vs. Pix4d.

 


You mentioned processing Step 1. after importing your images and before entering the GCPs. Note that this is perfectly fine, but unnecessary as GCP entry can be done as soon as you’ve started your project and have imported your images. You will need to use the Basic GCP/MTP Editor instead of the rayCloud sidebar properties editor.

 

It’s also worth mentioning the Pix4Dmapper has a marvelous feature once you have found and marked your GCPs and MTPs in a project. In addition to Importing (and Exporting) your GCPs, the GCP/MTP Manager allows you to Export the marks; and then, in a new project Import them all saving lots of time. This is very handy when you’re using the same photos in different Pix4D projects.

Good luck and please post how you’re making out.

I was wondering if anyone had any new insights to this post?  I have had the same issue.  I was running a test on a project that I had done a few years back and new I had good survey grade ground control.  One of my GCPs does not correspond with the calculated GCP.  Same as the first picture above.  I ran two flights (I am just testing and learning) of the same area, but at different elevations.  The flight with higher elevation had a closer result with the GCP in question.

Why is that the point cloud is not moved up to the GCP position?  The GCP is correct.  I had surveys from two different survey companies and the two surveys match on that point.  But Pix4D did not move the cloud to that point…  I had 4 other GCPs and the results on those was much better.

My main questions are.  Why did Pix4D not move the point cloud up to the GCP?    Second.  I am using a Phantom 3 Pro.  Not a survey grade drone.  Is that the issue?  I was under the impression that with good GCP Pix4D would overcome the deficiencies of a lesser drone.

Thanks much!

 Todd

Matt.  I was able to figure out something with my issue.  I am using a Phantom 3 Pro.  The rolling shutter was causing the issue for me.  Once I updated the camera to Linear Rolling Shutter (default is Global Shutter or Fast Readout) my vertical RMS error went from 2.5ft down to 0.1ft.  Much much better. 

I have found that by running just step 1 first and checking to see if I need to optimize my camera settings and then also using the Linear Rolling Shutter option my results are greatly improved.

Todd

 

For people reading this possibly having the same problem. I don’t have an answer to the original question, but the mistake that I made, and maybe you made too, is that after you do step one and you mark the ground control points in RayCloud , you CANNOT go to step two and three, you have to run step one AGAIN.

1 Like

I agree with Ty Brady, the first step has to be re-ran, even after you reoptimize.

I have one project with several flights that it doesn’t matter how many times I rerun the project, there is one group of photos that the point cloud hovers above the rest and the ground control has a long vector. I’ve decided to run that group of photos in a different project rather than fight with it. 

Millie and TY,

 

I don’t think that step one has to be re run after the GCPs have been marked. It step one is complete a Re-optimize will suffice.

 

Colin