Orientation Issues in EXIF data?

[Buckward]

I have been using my DJI Mavic Air for over a year now, taking 100's of overlapping photos and processing them in Pix4D. I never had a single issue until now.

Last month, I drove to an accident site and took several hundred photos of a road. The drone was about 110 feet in the air and I covered 1/2 mile of road with photos that overlap by 60%-70%. The images are looking straight down. There were also some images looking at a 45 degree angle sideways to the road, going along the road. When Pix4D processes images, I expect to get a high resolution orthomosaic image and a pointcloud. The ortho looked good, but later it turned out the road length was foreshortened. The pointcloud, when viewed from the side was extremely curved, like 90 degrees of circumference from a 360 degree circle. That accounts for the ortho image foreshortening. From the top, the curved pointcloud (the road as essentially flat) made the length of road covered seem shorter. Also, when I launched the drone on my 4th and final battery, it immediately wobbled erratically side to side as it lifted off. I landed, turned it off and re-launched. The wobble ceased on the forth try and I continued the survey with 68% battery left.

Two days ago, I drove to a rural area to test the drone. I took a couple hundred downward looking photos along an approximate 1/3 of a mile of road. I processed these images. There was a slight arc to the pointcloud (maybe 2 degrees of a circle's circumference), however the orthomosaic was garbage. It looked completely disjointed, like a Picasso painting and was a thin strip. I noticed the pointcloud had a drastically improper horizon. If I set the view of the pointcloud to TOP I was looking at the side of the pointcloud. I think this accounts for the bizarre ortho image. The Pix4D software identified the downward direction of the scene to actually be a side view. The resulting tiled photos were then viewed from the side, which is why my orthomosaic result was a very thin, smeared side view of the roadway.

Based on these results, it is clear that the Pix4D software is getting an incorrect indication of the horizon, or which direction is down, when processing my drone images. Along with the wobbling aircraft (it did not wobble in the test shoot), I theorize that some telemetry from the drone is incorrectly entered in the image metadata. I used BREXIFEXTRACTOR software to look at the test image metadata, however I saw nothing odd. Then again, there was no exif data reported that seemed to indicate direction. There was only GPS lat/long and altitude along with camera info.

Is there telemetry from this drone that indicates orientation that could be malfunctioning even though the drone flies okay (and perhaps is not flagged by exif reporting software)?

My drone is now unusable until this is sorted out.

Hoping for a solution.
Regards,
Buck Wyckoff

 

[Keule]

My drone is now unusable until this is sorted out.

Use ExifTool to verify the EXIF contents of an image.

If everything is good, you should see something like this:

Absolute Altitude : +1.20
Relative Altitude : +50.00
Gimbal Roll Degree : +0.00
Gimbal Yaw Degree : -134.30
Gimbal Pitch Degree : -41.00
Flight Roll Degree : -3.40
Flight Yaw Degree : -134.20
Flight Pitch Degree : +0.90

 

[sar104]

Use ExifTool to verify the EXIF contents of an image.

If everything is good, you should see something like this:

Absolute Altitude : +1.20
Relative Altitude : +50.00
Gimbal Roll Degree : +0.00
Gimbal Yaw Degree : -134.30
Gimbal Pitch Degree : -41.00
Flight Roll Degree : -3.40
Flight Yaw Degree : -134.20
Flight Pitch Degree : +0.90

Apart from the bogus +1.20 in the absolute altitude field - that was a bug in some of the earlier M2 firmware.

 

[Buckward]

Thanks for that info. This exif extractor gives you so much more than BREXIFEXTRACTOR.

Absolute Altitude : +1.20
Relative Altitude : +36.30
Gimbal Roll Degree : +0.00
Gimbal Yaw Degree : +178.70
Gimbal Pitch Degree : -89.90
Flight Roll Degree : -2.70
Flight Yaw Degree : +178.80
Flight Pitch Degree : -7.40

Different that yours, obviously. I was looking straight down at all times. If pitch is up/down (-89.90), then perhaps Yaw +178.70 is the incorrect side view I was talking about.
Thoughts?

 

[Keule]

Apart from the bogus +1.20 in the absolute altitude field - that was a bug in some of the earlier M2 firmware.

There are more bugs in MA EXIF/XMP fields:

Because DJI writes bogus (offset of a few hundred meters) Lat/Long coordinates in the MA EXIF fields, PIX4D extracted XMP coordinates to work with geolocation data.

 

[Keule]

then perhaps Yaw +178.70 is the incorrect side view I was talking about.

This is the direction in which the gimbal/aircraft is pointing to.
(In your case the AC is pointing ~South)

 

[Buckward]

This is the direction in which the gimbal/aircraft is pointing to.
(In your case the AC is pointing ~South)

The drone was pointing south as I was shooting along a N/S road, looking down and traveling north to south. Dang, I thought we had identified something.

 

[sar104]

There are more bugs in MA EXIF/XMP fields:

Because DJI writes bogus (offset of a few hundred meters) Lat/Long coordinates in the MA EXIF fields, PIX4D extracted XMP coordinates to work with geolocation data.

View attachment 100634

That's odd - the M2 doesn't do that.

 

[Meta4]

There are more bugs in MA EXIF/XMP fields:
Because DJI writes bogus (offset of a few hundred meters) Lat/Long coordinates in the MA EXIF fields,

Could that be due to the drone recording the location in WGS84 and you comparing to data using a different datum?

 

[sar104]

Could that be due to the drone recording the location in WGS84 and you comparing to data using a different datum?

It doesn't look like it - the EXIF data shown have two different sets of coordinates. On the other hand those two locations are only 2 meters apart.

 

[sar104]

There are more bugs in MA EXIF/XMP fields:

Because DJI writes bogus (offset of a few hundred meters) Lat/Long coordinates in the MA EXIF fields, PIX4D extracted XMP coordinates to work with geolocation data.

View attachment 100634

That's a 2 meter offset, not a few hundred meters.

 

[Meta4]

That's a 2 meter offset, not a few hundred meters.

But if he's comparing to a known location from a map etc, but that location's data is expressed in a different datum, it would appear that DJI has applied an offset.

 

[sar104]

But if he's comparing to a known location from a map etc, but that location's data is expressed in a different datum, it would appear that DJI has applied an offset.

Right - but I assumed that he was talking about the two different coordinates in the EXIF file. Perhaps I misunderstood the post. And I cannot imagine PIX4D using anything other than WGS84.

 

[Meta4]

Right - but I assumed that he was talking about the two different coordinates in the EXIF file. Perhaps I misunderstood the post. And I cannot imagine PIX4D using anything other than WGS84.

I didn't think he was talking about what Pix4D do.
If he was comparing location data from the Exif info against map data using European 1979 Datum, that would account for a transposition of 136 metres.
We'll have to wait for Keule to confirm whether he was confused by the two slightly different positions or was talking about his own observations where he is.

 

[Keule]

We'll have to wait for Keule to confirm whether he was confused by the two slightly different positions or was talking about his own observations where he is.

After digging through my projects I found 1 dataset flown with a MA which resulted in the following (wrong) geolocation:
(The location should be at the celltower and not the village to the SE ...)


Confirmed it was WGS84, of course.

Digging further about what the problem might be, it surfaced that at the time being (End of 2018) Pix4Dmapper, the desktop application v. 4.4.8 interpreted the geolocation wrong. Uploading the mission to their cloud services did not show that bug and processed that data set correct.

In January 2019, Pix4D fixed the bug with v4.4.9:

(4.4.9) Extracted image geolocation from DJI Mavic 2 is now correct.

It looked that pix4dmapper was using a different geodetic datum and not WGS84 or had some other unknown bug.

Processing the same dataset with the current version of Pix4dmapper 4.5.6 (March 2020) the results are as expected.

 

[Meta4]

It looked that pix4dmapper was using a different geodetic datum and not WGS84 or had some other unknown bug.

I've run into that sort of problem on the ground too many times before.
When you mentioned coordinates being offset by a few hundred metres, it brought back memories of data collected using the wrong map datum.

 

[Buckward]

Here's a response from my client/friend who is the one sending my test images to the pix4dmapper (cloud processing). As you can see in the image, the blue reference lines show my images pointing down, but analysis is re-directing things sideways, accounting for the garbage orthomosaic. Since you guys seem to be Pix4D aware, I wanted to show you this in case you have any other ideas as to what is going on.

When I look at the "rayCloud" view, I see all of your original photo orientations (in blue) look correct and oriented downward in Z, but the analyzed orientations (green) are hosed. All are rotated ~90 degrees, resulting in the pretty-good point cloud with completely incorrect orientation. Based on prior reading, the orthomo is a function of the point cloud, not just stitching but more like rendered from the 3D data, so we end up with the garbage orthomo.



I researched this on pix4d forums and found some info (Rotated sections of the cloud) that's similar. I'll do some research on how to straighten it out in pix4d - I'm not sure if it's trivial or not even possible. I have read some and watched a tutorial on GCP (Ground Control Points) but haven't tried implementing anything since they usually require survey data.

My preliminary thought is that I don't think there's anything wrong with your drone (wobbling aside) at this point. Thoughts to be refined with more info.

 

[DroneAce]

@Buckward

Did you ever figure this out. I am having the same problem