Implement Geotag support using CAMERA_IMAGE_CAPTURE

[DonLakeFlyer]

Currently only supports PX4 logs.

[DonLakeFlyer]

Good enough for now

[LorenzMeier]

@DonLakeFlyer The more generic approach is this one:

• Flight information (to tell consecutive flights apart): MAV_PROTOCOL_CAPABILITY_FLIGHT_INFORMATION. If the autopilot supports it, QGC request:
  • http://mavlink.org/messages/common#MAV_CMD_REQUEST_FLIGHT_INFORMATION
  • Autopilot sends http://mavlink.org/messages/common#FLIGHT_INFORMATION
• Autopilot sends http://mavlink.org/messages/common#CAMERA_IMAGE_CAPTURED on every trigger event
• QGC stores all that data in a QHashMap with the sequence as key
• It re-requests any dropped image frames using http://mavlink.org/messages/common#MAV_CMD_REQUEST_CAMERA_IMAGE_CAPTURE
• It stores all that data in the flight meta info
• It uses that in the geo-tagging, which now works with any MAVLink enabled autopilot (and hence doesn't need to be a plugin)

It also means no more log downloading - you can geo-tag right away after landing. Just point QGC to the mounted SD card and it can do the magic.

[mhkabir]

We should support a minimum of these EXIF tags : https://support.pix4d.com/hc/en-us/articles/205732299#gsc.tab=0

[dagar]

These might be obvious, but when I see people trying this kind of thing with cheap cameras and triggers I see a few common problems.

• camera time is often wrong and at best only 1s resolution. File modification time is often lost after the photos have been manually moved around.
• ignoring camera time and trusting the camera triggers from the autopilot works well, but only if you can get them to align and didn't drop any shots (IR trigger + bright day). There are often test shots before the log started.
• there's a delay between the autopilot camera trigger message and the actual photo. It's variable, and dependent on all the pieces (trigger, camera, camera settings), but people will want to add this nudge factor.

For tagging I think you need to try and align the list of camera tags with the images, while only trusting the time delta between photo timestamps. It needs to be clear to the user what's happening, and if they need to manually select the first photo.

[LorenzMeier]

@mhkabir Triggers get received here: https://github.com/mavlink/qgroundcontrol/blob/master/src/Vehicle/Vehicle.cc#L632-L643

So that's where the re-request should happen. And the geotagging plugin should take this trigger list. @DonLakeFlyer that's where your feedback is required.

[DonLakeFlyer]

The fundamental problem with this is that you can't rely on telemetry to tag against since it can be lossy. It is also not an uncommon Survey use case for the vehicle to go out of telemetry range due to geography. You want a non-lossy data stream to tag from which is why vehicle binary logs are used in almost all cases.

[birchera]

We already do something similar and I am happy to share our experience: All tags are stored on the aircraft during the flight. Once the aircraft lands and disarms we transfer all the tags. At that point it is usually well in range of telemetry connection.

Obviously the improved version would be to already transfer as much as possible during flight and only fetch the remaining tags after landing.

[mhkabir]

How are you storing them onboard?

On Fri, May 5, 2017 at 3:25 PM, Andreas Bircher notifications@github.com wrote:

We already do something similar and I am happy to share our experience: All tags are stored on the aircraft during the flight. Once the aircraft lands and disarms we transfer all the tags. At that point it is usually well in range of telemetry connection.

Obviously the improved version would be to already transfer as much as possible during flight and only fetch the remaining tags after landing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mavlink/qgroundcontrol/issues/4230#issuecomment-299463817, or mute the thread https://github.com/notifications/unsubscribe-auth/AFTNrKkx1TUCQ60bT9_Fmr0ecoJ61iwtks5r2yNagaJpZM4K4kCW .

[birchera]

As mentioned here we use the datamanager to store them.

[DonLakeFlyer]

With ulog format geotagging going I don't see this as needed for 3.2?

[LorenzMeier]

Yep, not desperately needed.

[DonLakeFlyer]

I don't see how the concept of re-requesting missed CAMERA_IMAGE_TRIGGERs from the ground station side of things is a good idea. This means that QGC needs intimate knowledge of a survey which it is currently flying. Once a survey is sent to the vehicle side there is no concept of where the camera triggers are from the Fly View side of things. The Fly View is dumb to all of that. It doesn't even know it is flying a Survey.

This would require a ton of work on the QGC side of things to make it work. What exactly is the problem you are trying to solve here?

[LorenzMeier]

Its not really a lot of work. What we definitely need to solve on the fundamental level is the download of flight meta data in a reliable fashion.

[DonLakeFlyer]

Its not really a lot of work.

Uh, ok. If you say so!

Why not keep camera triggers in a separate log on the vehicle. Then it's quick to download from the vehicle when the flight is done. And you don't have to do all sorts of crazy stuff to detect missing triggers.

[DonLakeFlyer]

I just realized there was an image index in CAMERA_IMAGE_TRIGGER. Duh!