MAVLink common camera control messages

[Michael du Breuil]

I've been working with a manufacturer for a MAVLink capable camera and we are looking to add more functionality to the camera. The two messages that we are particularly looking at are currently in the ardupilotmega.xml but they make more sense to convert them into general MAVLink messages. The two messages that are being looked at the most are CAMERA_STATUS ( https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/ardupilotmega.xml#L621 ) and CAMERA_FEEDBACK ( https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/ardupilotmega.xml#L635 ).

CAMERA_STATUS is very interesting to support as it allows a camera to report how many photos can be taken, the battery level (if self powered)  and camera errors. This is all really valuable information to an operator at the GCS. I'd like to suggest that we extend the definition of CAMERA_STATUS_TYPE_HEARTBEAT to additionally fill out the following fields:

  p1 camera mode (use an enum with the following: initializing, camera ready, camera capturing/busy) (Not sure on what the full list here should be)

  p2 camera battery (if present)

  p3 reported shots remaining (if stills are supported)

  p4 supported video minutes remaning (if supported)

CAMERA_FEEDBACK provides information about where the camera was taken, while this is what CAMERA_TRIGGER is meant to do, the full feedback message is valuable for any camera that is running it's own IMU or GPS system, which is potentially of a higher quality (or better correlated to when the image was taken) then that on the external interface. 

Is there any objection to moving these into the general MAVLink specification? What are other features people think should be included or changed?

[Meier Lorenz]

Hi Michael,

In fact if you want to call a camera “MAVLink compatible” it *has to* be in the common message set. I will be more vigilant on that definition next year, probably requiring units to pass a test harness to be blessed as MAVLink compatible.

There is an opportunity to potentially cut them over unchanged to the common message set, since the required min message ID was recently raised from 150 to 180 (which conflicts APM’s current use, but there was no good alternative either).

Would you feel the existing messages are a 1:1 fit or do you need modifications? That will largely define which direction we should take.

-Lorenz

[Michael du Breuil]

I'm glad to hear it actually on the vigilance side of it, and a test harness. I was opposed to using just the APM fields for that reason.

I'm okay with the fields as they are, the biggest change I want to make is add some more meaning to the heartbeat version of the camera status. Particularly I'd like to suggest that we extend the definition of CAMERA_STATUS_TYPE_HEARTBEAT to additionally fill out the following fields in camera status:

    p1 camera mode (use an enum with the following: initializing, camera ready, camera capturing/busy) (Not sure on what the full list here should be)

    p2 camera battery (if present)

    p3 reported shots remaining (if stills are supported)

    p4 supported video minutes remaning (if supported)

The values for camera mode that I can think of are:

    initializing (camera's powering on/mounting sd card/acquiring any sensor inputs required (GPS/IMU etc) and generaly not ready to respond to commands)

    idle (the camera is ready to take photos/commands etc)

    capturing (the camera is taking a photo or video)

    busy (the camera is processing data/saving it and should not be turned off)

The only other field I really questioned was if 16 bits was large enough to count photo sequences in the feedback message but upon further reflection I suspect it's fine. The most photos I've ever taken in a single flight is around the 8k mark, so it seems probable that we have a while before we start looping on the index. I'm not opposed to raising this to a 32 bit number just to be more future proof, or to accommodate imagers that take far more photos, but I suspect that this is fine as is.

I'm curious if others who've worked with these at all have opinions or limitations they've run into. The proposed changes for the CAMERA_STATUS message simply require an additional enum and add some meaning to the one enum but doesn't change any of the fields size/order, and the CAMERA_FEEDBACK image index is probably fine as is, unless someone else reports taking far more photos in a flight. If that's the case then we could probably reuse the current definitions and add the enum at the same message ids.

[Craig Elder]

Michael

We have at least six more companies who have expressed an interest in using MAVlink to support their cameras and their gimbals and camera equipped gimbals.  Actually several companies approached us at Interdrone last week on this specific topic.  We plan to create a working group within those companies to agree on common messages and then extend the messages to support features and functions particular to specific cameras.

We also have to come up with a solution for the System ID / Component ID issues that we have currently.

--
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.

[OlliW]

That's fantastic! It's good time to sort out the camera/video ambiguities and make things future proof! It's a bit sad though to see this triggered now by commercial interests and not earlier by DIY demand. I guess this just reflects APM going more commercially oriented. That's fine, but let's hope, and that's why I speak up, that this working group has also DIY aspects in mind when designing these messages. :)

You btw don't have a System ID/Component ID issue, you have a Mavlink issue, i.e. are hitting its inherent conceptual flaws, of which there are some. I started mentioning that months ago, but it seems to be an inconvenient truth and treated as such, so it's good to see that comprehension slowly raises, but it's also a bit sad to see that just the surface is touched and don't seem to look more behind the curtain. As I said somewhere before, the communication backbone can be an asset or a liability. The current approach has already started to turn from an asset to a liability, and this will continue, and it will get more and more a liability. Addressing what you call a System ID/Component ID issue may delay that but not prevent that from happening. So, I'd like to grab this opportunity anew, and encourage you guys to also create a working group on the communication backbone. (I think it would be high time, it's so fundamental and crucial to everything that, as said, it can be an asset or liability).

Just IMHO, and with the best intentions, as always. :)

[john...@gmail.com]

Regarding camera and video support, it might not be a perfect fit but take a look at:

http://www.onvif.org/

It's basically h264 streaming using RTSP and a standard for controlling camera settings and peripherals like pan&tilts etc. If we supported this we would plug and play support for literally hundreds of different cameras for different manufacturers.

[Akshat Deshpande]

Camera zoom and focus will be very important,
also some messages originating from the camera itself which can help us in image processing for target acquisition and following.