camera feedback MAVLink messages

[Andrew Chapman]

Hi everyone, 

I've been working to tighten the camera feedback loop and display in the GCS software (initially Mission Planner) when photos are being taken. For now it is just dropping a pin on the map, but the aim is to project an accurate sensor footprint region onto the map to check coverage and overlap. Eventually it could even overlay a low-res thumbnail of the images live onto the map.

I've fleshed out the camera feedback MAV messages I think we need - any input appreciated. Initially this will be for feedback from the autopilot to the GCS, but it is also supporting the ability for a 3rd party piece of hardware with tighter connection to the camera to be in the loop and reporting back when the camera is triggered independently from the autopilot (e.g. if using a CHDK intervalerometer script).

First step working:

http://vimeo.com/92748754  (password: camfeedback1)

MAVLink definition update (description of changes further below):

https://github.com/chapman/ardupilot/blob/Cam_Control_Board/libraries/GCS_MAVLink/message_definitions/ardupilotmega.xml

CAMERA_EVENT:

message from camera to autopilot: mainly for camera trigger events, but could also be things like error, low power, full card, etc

CAMERA_FEEDBACK:

message from autopilot to both GCS and camera control system, in response to a camera trigger event, including GPS pos, attitude, etc, everything needed to plot capture region on the GCS map as well as all data needed for image stitching and orthorectification

CAMERA_INFO_REQUEST:

message requesting camera control system to interrogate the camera for info, sensor size, res, etc. Needs to be passed from GCS->autopilot->camcontrol

CAMERA_INFO_0:

camera info response message, from camcontrol->autopilot->GCS, it can be expanded to CAMERA_INFO_1, CAMERA_INFO_2, etc if necessary later

AC.

[Kevin Hester]

smart.  Looks like a good list to me.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Randy Mackay]

     Very snazzy.

 

     Do we have a mavlink enabled camera or camera board?  That would be great.

 

     If the camera/camera board is mavlink capable, maybe we should expose all the board’s cameras to the ground station.  Basically there are those component IDs that the ground station sends.  If the autopilot knows that it has a camera board attached and it’s component ids, it could just act as a pass through.  Passing all the parameters might be as good as the special purpose camera-info-request and camera-info-0 messages.

 

     Maybe the Camera-event and camera-feedback could be combined?  I guess they’re very similar except that we’re expecting that the camera itself won’t know it’s position so the autopilot needs to fill in the location before forwarding onto the ground station?

 

-Randy

[Andrew Chapman]

On Sunday, May 4, 2014 5:36:56 AM UTC-7, Randy Mackay wrote:

If the camera/camera board is mavlink capable, maybe we should expose all the board’s cameras to the ground station.  Basically there are those component IDs that the ground station sends.  If the autopilot knows that it has a camera board attached and it’s component ids, it could just act as a pass through. 

I'll add to the CAMERA_EVENT_TYPES enum a heartbeat event which will periodically (1hz?) return the camera component ID. That will allow multiple cameras to announce themselves as being connected and currently online, rather than needing the GCS to configure the IDs to talk to. 

The CAMERA_INFO_REQUEST and CAMERA_INFO_0 messages would merely be passed through by the autopilot, but the CAMERA_EVENT message from the camera needs to be received by the autopilot which causes it to generate a CAMERA_FEEDBACK message containing the position+orientation data to be sent back to the camera (to embed in the image EXIF) as well as to the GCS (to display the capture region on the map). Maybe CAMERA_POSITION is a better name for the CAMERA_FEEDBACK message?

Passing all the parameters might be as good as the special purpose camera-info-request and camera-info-0 messages.

Sorry Randy, can you elaborate? Not sure what you mean by that - maybe that instead of a message with a bunch of fixed parameters we use a similar mechanism as the autopilot parameters, one param value per message?

 

Maybe the Camera-event and camera-feedback could be combined?  I guess they’re very similar except that we’re expecting that the camera itself won’t know it’s position so the autopilot needs to fill in the location before forwarding onto the ground station?

Yeah, I was thinking of that initially, i.e. the camera first sends an empty CAMERA_FEEDBACK with all the positional data zeroed out, and that is then filled in by the autopilot and resent, but then I thought it would be clearer to have separate messages than to overload one based on whether it is fully or partially filled in.

And although it makes sense for the camera trigger event, it isn't a good match for other event types (e.g. low cam battery, cam error, card full, etc).

Though if we're worried about running out of MAVLink message IDs that could be enough of a motivation to combine.

AC.

[Kevin Hester]

Randy's point about params is a good one.  Rather than CAMERA_INFO_REQUEST, you could just pick a new component id for your camera and just have it show up as params (which would also ease integration into GCSes).