Camera meta information #7164
Camera meta information #7164
Conversation
The camera trigger now sends image meta data which is important for geotagging / survey applications.
|
@mhkabir I've added http://mavlink.org/messages/common#MAV_CMD_REQUEST_CAMERA_IMAGE_CAPTURE for the re-request command. Please add to vehicle_command.msg with the same ID / meta info. |
|
Related QGC issue: mavlink/qgroundcontrol#4230 @DonLakeFlyer Note that this is gating the v1.6 release, so reasonably high prio if you can fit it in somewhere. |
|
@dagar Would be fantastic if you could review and potentially help on the QGC side. |
|
Complete communication spec updated here: In particular the bit on http://mavlink.org/messages/common#FLIGHT_INFORMATION |
|
@LorenzMeier I don't know anything about the Quaternion definition. It should just be the same as the vehicle. The Euler angles are in the same frame as we describe the vehicle, facing level to North. |
|
@julianoes OK, got it. |
| @@ -41,6 +41,7 @@ set(msg_file_names | |||
| att_pos_mocap.msg | |||
| battery_status.msg | |||
| camera_trigger.msg | |||
| camera_image.msg | |||
There was a problem hiding this comment.
I think the name camera_image_captured would better describe this.
| float64 lon # Longitude in degrees (WGS84) | ||
| float32 alt # Altitude (AMSL) | ||
| float32 relative_alt # Altitude relative to home | ||
| float32[4] q # Attitude of the camera, pointing down is XXX |
There was a problem hiding this comment.
As said, pointing level to North should be the frame, same as the vehicle.
|
|
||
| msg.time_boot_ms = image.timestamp / 1000; | ||
| msg.time_utc = image.timestamp_utc; | ||
| msg.camera_id = 1; |
There was a problem hiding this comment.
This should probably be 0 for all camera IDs, unless the trigger is specifically sent to camera ID 1 only.
| // efficient retransmission logic. | ||
|
|
||
| if (static_cast<int>(cmd.param1) == 0 /*_prev_image.seq*/) { | ||
| // Send prev image again |
There was a problem hiding this comment.
So you just have a "queue" of one message before the current one to retransmit? That's doesn't sound very robust.
There was a problem hiding this comment.
The robustness judgement should be made on timing, not on queue size. You want to allow for ~50-250 ms retransmission requests for the GCS before it gets overwritten. Taking into account that we realistically will not exceed 3 Hz with current systems that means we 250 / 333 ms = 0.75 messages queue size, rounding up to 1.
There was a problem hiding this comment.
I can think of cases where we miss one message and likely miss a couple more.
There was a problem hiding this comment.
e.g when the data link goes out of range briefly.
There was a problem hiding this comment.
We are currently using a similar mechanism to get the tags to the GCS. And I can confirm that it happens every now and then that you lose the mavlink connection for a longer time. Especially when you start to fly further away and BVLOS.
We found a workaround to store the tags using the datamanager during the flight. Then only after the flight we transmit the full set of tags. As the tags are only little data and we don't save them in junks this proofed to work reliably.
|
Superseded by #7201 |
@mhkabir This is just the architectural foundation for you to complete. This changes the whole approach to geo-tagging: Instead of doing this using the log file we resort to storing the trigger events in the GCS (@bkueng, @DonLakeFlyer your help might be needed) during the flight. The Geotagging then should just use that hash map to tag the images.
@julianoes Can you help with the quaternion definition of the camera message? What is 0 roll, 0 pitch, 0 yaw? Facing level to north or facing down to north?
MAVLink message: http://mavlink.org/messages/common#CAMERA_IMAGE_CAPTURED