Closed rmackay9 closed 8 months ago
Why not just treat changing the active lens as changing camera mode?
@auturgy,
Thanks for the review. I thought of using camera-mode but the purpose of the SET_CAMERA_MODE command (and enum) appears to be switching between picture-taking-mode and video-taking-mode.. so a different purpose.
With the ViewPro cameras there are 3 to 7 different combinations of "lenses".
I understand the problem :) I do have a few issues with this approach though. A "lens" usually refers to the pieces of glass in front of the imager: for many cinematic and survey cameras, this is as true as it is for your normal DSLR. What you're talking about is different imagers managed by the same "camera", not different lenses. It's more correct to treat these as different cameras than different lenses (although the camera microservice does already have the concept of lenses). From a mavlink perspective, adding additional messages/commands ad-hoc is not going to fly upstream without stronger justification, and as this is a PR into common, for it to be accessible to QGC and the wider ecosystem, there is no option but to work with mavlink/mavlink.
@auturgy,
Yes, I've raised a PR upstream and I'm looking forward to feedback.
It's really not two separate cameras though because they don't have separate controls. For example once the thermal lens (or whatever we call it) has become the active lens, other lens cannot be controlled. So it acts like a single camera with multiple lenses.
I'm very open to alternative solutions..
This adds a mavlink command to change the active camera lens (e.g. which camera lens is being streamed to the GCS). This is useful for cameras with multiple lenses like the ViewPro and Xacti cameras.
This has already been merged upstream albeit after much discussion. https://github.com/mavlink/mavlink/pull/2079
This also includes the unused mavlink command MAV_CMD_SET_STORAGE_USAGE which AP doesn't use but is directly above this new command in common.xml.