Camera Manager: Sometimes appears to expect a CAM_MODE parameter

[olliw42]

The camera manager appears to sometimes expect that the MAVLink camera has a CAM_MODE parameter, which appears to be called when one switches between video and photo mode back and forth. In the following screen shot this are the Unknown Fact "CAM_MODE" error messages, which follow a setVideoMode() or setPhotoMode().

I could not yet figure out what exactly the conditions are for this to happen, there seems to be some history dependence. So I unfortunately can only report that this "sometimes" happens.

In the above example, the camera made use of a camera definition.xml file, which is hosted here: www.olliw.eu/drop/storm32mavcamera_default.xml. It has a DUMMY parameter but no CAM_MODE parameter. I did carefully read the spec, and I could not find a statement that if a xml file is used the camera must have a CAM_MODE parameter (and such a spec would not make sense to me). This I can reproduce reliably.

I have seen this Unknown Fact "CAM_MODE" error messages also in other circumstances, not only when a camera definition file is used, but I can't reproduce this on demand, i.e., this happens "sometimes".

As far as I can see, there are two situations: Either there shouldn't be a reliance on a CAM_MODE parameter in which case the above would be a bug, or the reliance on a CAM_MODE parameter is according to spec, in which case the spec documentation needs to be updated. I however also just may miss the point.

:)

[dogmaphobic]

It is indeed missing from the documentation. It should be added here:

https://mavlink.io/en/services/camera_def.html#common-parameters

It's OK not to have it. You would want to have it if when switching modes you have to exclude/change other parameters within the camera definition. Things you can't do if only relying on a MAVLink set mode command.

[olliw42]

many thx for the quick clarification.

I have certainly seen this list (and suspected that CAM_MODE might be missing), but I read it to be optional, not mandatory.

It's OK not to have it.

that's the all crucial statement. THX! So I just don't care about it. (that's always best solution for all side, isn't it LOL)

You would want to have it if when switching modes you have to exclude/change other parameters within the camera definition. Things you can't do if only relying on a MAVLink set mode command.

This would be probably very helpful to be explained in the docs.

But this would be so for any parameter, not just for the ones listed as common-parameters, right?

So the "only" difference of the common parameters would be that a camera manager might produce a more dedicated GUI for them, and that their names are reserved, right?

[dogmaphobic]

Correct. Those Known Parameters are used solely for UI. That is, if found, the ground station can build special UI elements for it.

The CAM_MODE parameter is a special case. For changing modes (Photo/Video), you normally use the existing MAV_CMD_SET_CAMERA_MODE command. For dumb cameras, that is all that is needed. However, if your camera provides a list of parameters and they (or their options) are dependent on which mode the camera is set, the only way to describe that is through a parameter. This is where CAM_MODE comes into play. For example, you may have a list of video resolutions and want it excluded from the UI when the camera is set to Photo Mode. Conversely, you may have a list of image sizes and/or compression levels, which you would want excluded from the UI if the camera is set to Video Mode.

[olliw42]

great explanation :+1:

I think the conclusion is that the docs could be somewhat improved.

Not sure if this issue should be closed or kept open to not "forget" this. Pl decide.

thx, sir!

[dogmaphobic]

@hamishwillee See above. I won't have time to deal with this until Monday, the 27th at the earliest.

[hamishwillee]

@dogmaphobic IN case you forgot, you already have a PR for this - https://github.com/mavlink/mavlink-devguide/pull/164 You just need to do a final review.

It looks like this:

[dogmaphobic]

Duh, too much going on at the same time and my brain has one single core... :P