Geotag CSV file - camera orientation values (X, Y Z) in wrong order for Pix4D

The CSV geotag generated by Mission Planner has the camera orientation values appear to be in the wrong order.

According to the Pix4D docs they values should be in the following order:

The order should be: Omega, Phi and Kappa. These should be X, Y and Z values for Roll, Pitch and Yaw per this explanation:

The geotag CSV file generated by Mission Planner however has these values in the order of Kappa, Phi and Omega. Kappa and Omega are reversed.

There is an additional issue - the orientation values in the geotag are for the copter - not the camera. If the camera is mounted face down - the reported value of Phi (pitch, or “Y”) should be about -90 degrees, not 0 degrees.

I have my camera in a mavlink connected gimbal - but it doesn’t appear that the gimbal pitch is used in the geotag data.

I’ve uploaded a CSV file that illustrates the problem. It’s from a photo mapping mission where outbound legs are south-east - about a heading of 110 degrees. Inbound legs are north-west - about a heading of 290 degrees. You can see these values in the 5th position. Pix4D is expecting this in the 7th position.

The outbound legs are downwind, inbound legs are upwind. This is properly represented in the CSV positions for pitch and roll as the copter compensated for the wind.

NOTE: I haven’t yet checked to see if the right values are placed in the EXIF data of the image files - only the CSV file.

Here’s some more findings germane to this subject:

I discovered that while Mission Planner will include the orientation data in the CSV file it generates when processing geotags - it does not put the orientation data in the EXIF of the image files.

And as a wicked twist - I’m told that Pix4D will not process orientation data from a CSV file. It will only process it from EXIF on the image files.

The orientation data (X Y Z values) have to be “processed” because Pix4D uses the (Omega Phi Kappa) coordinate system for orientation.

So there are two possible remedies:

  1. put the X, Y and Z values in the EXIF, or,

  2. convert the X, Y and Z values to the Omega, Phi and Kappa values in the CSV.

I’m told that the conversion of X, Y and Z values to Omega, Phi and Kappa coordinates is difficult math. But I’m sure it can’t be beyond anything EKF3 does.

Then there is the issue as noted above that CSV has the X, Y and Z in the wrong positions. But that’s easy enough to fix by loading the file into a spreadsheet and re-arranging the columns.

I’m looking into a couple more things - I checking to see if the AirPixel Air Commander Entire includes the orientation data when it writes to the EXIF.

That would solve the problem except the Phi (Y) orientation value produced by Mission Planner is for the copter - not the camera facing down - or in a gimbal.

So from the data I’ve found so far - there simply isn’t an option that handles this using Pix4D.

I’m told that other programs such as AgriSoft MetaShape will process the orientation data from the CSV file.