Support Website Contact Support Blog

Huge camera position uncertainty ellipses

Quick background: I’ve been experimenting with AutoGCP. The first time using it (2/25/2021) I flew a grid with 70° camera angle, but then read shots should be nadir, but it worked. I’m using Aeropoints, and had no issue using that state plane coordinate data imported during the data set import (pretty intuitive). The orthomosaic GCPs and their locations lined up perfectly.

I flew with Mission yesterday, good conditions and connectivity the whole time. This time flew a grid, 80/80, normal+, sunny, 200’ agl. First indication of issue was that only 2 of my 6 GCPs were found (and not many photos of each). I then noticed on the quality report the uncertainty ellipses were nothing like I’d seen before! While the orthomosaic looks good enough for its purpose, none of the GCPs aligned. I assume this was because of the uncertainty.

Looking through the quality control help, I’m trying to determine if moving construction traffic was to blame, or what exactly I should be chasing after (flying during less traffic, more GCPs, etc). Any help or input is appreciated.

Project-2021-02-25_report.pdf (2.4 MB) Project-2021-03-12_report.pdf (1.9 MB)

Hi There

You’ll need at least 3 GCP’s to get the project georeferenced. That’s why your 3/12/2021 project GCP’s wont align. Also the camera optimization is way off.

Ah… makes sense on the georef… missed it by one!

Camera is just the stock Phantom Pro 4 v2. I’ve read more on camera optimization. Going down that list:

  • Project area is relatively flat, but not homogenous.
  • P4P has a mechanical shutter, not rolling.
  • Image blur: All “out-of-camera” images look free of motion, focus, or smudge blur, and no filters are used. Sample:
  • Overlap was 80/80.
  • Images were not processed prior to upload.
  • Camera parameters: I confirmed the correct drone and camera are selected in Pix4DMission settings. There was nothing abnormal during mission upload at time of flight. Past missions with this drone and camera have gone fine.

I’m not sure what to do differently next time (edit: other than add a lot more GCPs, but I thought 6 over 14 acres would be enough).

I’ve also uploaded the log: Project-2021-03-12.log (1.6 MB)

Hi Michael

If you can share the dataset I could take a look at it

I appreciate the assistance. This includes all images, Aeropoint GCP data export, and the GCP csv that I uploaded to Pix4D: Box

Hi Michael,
I think the issue here is the camera optimization, in the project where the GCP detection failed it changed by 40%. Are you using the same drone and camera? Has the second flight the camera tilted as the first one?

On another issue, have the GCP coordinate conversion done in the same way?
Thanks.

It was the same exact drone and camera. On the second flight I flew just a grid and confirmed the “angle of camera” in the settings was 90 degrees.

Also, the GCP I double-checked that the coordinate conversion was identical for both flights.

Jaakko_Laihola was able to help me running it in Mapper, where he processed the project with ‘all prior’ calibration setting, and that fixed the camera optimization. I’m in the process of uploading that to cloud.

Lastly, there’s a lot to see here, but this is my flight log for the mission. I’m picking through it to see if I see anything unusual, but so far no: Mar-11th-2021-09-56AM-Flight-Airdata.zip (425.4 KB)

Thanks for the feedback.
Yes, All prior usually solves this problem but it is not available in the cloud (unless you upload from mapper) so that is why I was asking.
What is really weird is that in the first flight, there is no problem with the camera optimization.
Is there any difference in the image capture?
Thank you very much.

The image quality of the successful and unsuccessful flights both look the same.

I’d like to learn more about how “camera optimization,” works, and what, “41.77% relative difference between initial and optimized internal camera parameters” means exactly. I’m interpreting it to mean that for some reason, something about the images gave the “processing engine” the impression that the camera’s selected parameters (focal length, sensors dimensions, etc in the Pix4D capture app) differed from what was actually captured.

A couple of things I’m going to try in my next mission to see if it makes any difference:

  1. Run any calibrations I can using the DJI Assistant 2 program.
  2. In DJI GO, I always shoot my non-mapping stills in RAW. Capture of course changes the setting to jpg, but I’m going to manually change to jpg first, then switch to Capture. Other than RAW, I don’t have any special or unusual image mode settings. I don’t expect this to be the issue.
  3. I have a few identical Phantom 4 Pro V2s. With the same GCPs down, I’ll also fly another one 20’ lower (or something) and if I have a problem, see what the backup drone captures.

My only real heartburn with all of this is that I’m burning through a chunk of my monthly image allowance when I have this issue. Hopefully I’ll sort it out soon!

Hi again,
Pix4D works better with the original images, so better not to apply any calibration, jut work with the camera as it is.

I believe the calibration is just the same tool they use on the drone in the factory. It’s not a thing that alters the images after they’re taken.

I flew another mission today. Crossing fingers.

Yesterday’s mission processed better. Project-2021-03-18_report.pdf (1023.3 KB)

Had a much lower Camera Optimization difference (5%) and all GCPs aligned this time.