Add MAV_CMD_SELECT_TRIGG_CAM command.

[MatejFranceskin]

MAV_CMD_SELECT_TRIGG_CAM as a mission item added to the mission plan selects the camera and stream that will be used for capturing images in case where the vehicle has multiple cameras and/or camera has multiple sensors available.

[hamishwillee]

Sounds sensible but I'll have a proper look tomorrow. The things I'm interested in checking/questioning are (and you might want to clarify, but you might not since it is a stream of muddy thinking ...):

• Whether this can be used as a command as well
• Confirming whether this applies for the next call on the camera, or all subsequent calls on the camera. Does it outlast the mission. So normally you might use this as a command to set the default behaviour and as a mission item to override the default behaviour.
• Will I ever want to trigger 2 but not all cameras - ie. this can trigger all and just one, but not necessarily specific ones.
• Is there any other camera triggering that this might clash with, in which case how is that resolved.
• Does/should this select anything for video as well?
• Is there any overriding that can happen from commands etc during mission, and is there any conflict resolution.
• Is there any other configuration that you might want to do in a mission other than triggering - let's think about that quickly now.

[MatejFranceskin]

1. MAV_CMD_SELECT_TRIGG_CAM is used as command as well. When it is reached in the mission the flight controller sends the same command to all cameras. This is because also those that are not addressed have to "unselect" itself.
2. Yes, the command outlasts the mission.
3. The way it is currently designed we can trigger only one or all the cameras.
   For other questions, we have to discuss it. In current implementation this command selects the camera for all commands that are related to camera triggering not just f.e. MAV_CMD_IMAGE_START_CAPTURE but also MAV_CMD_DO_SET_CAM_TRIGG_DIST and others. It could be extended also to MAV_CMD_VIDEO_START_CAPTURE which already contains information about which stream to record but if used as part of the mission plan then it doesn't address particular camera.

[hamishwillee]

Thanks @MatejFranceskin ! There is a dev call this evening (my time tonight) if you want to come and discuss. Julian is on holiday and I'm not sure who will show up. Here are my thoughts anyway.

As I understand it, when the autopilot executes this command it would broadcast the message to all cameras (vehicle system ID and component id =0). Each camera on the vehicle gets the message and checks whether it has a component id that matches the message (and stream ID). If it does, then it sets it's state to either ignore or accept future broadcast camera commands [the ignore is the interesting case, since presumably by default a camera will accept any broadcast command].
It will ignore further commands until it gets a new command to enable itself (should it persist the setting across reboots?)

Is that about right?

My first concern is what the GCS/user should do afterwards for cameras that were set disabled in the mission.

For example, in the current model when flying outside of a mission the GCS allows you to switch between cameras, and commands are directed to the current camera.

• If the current camera was disabled by the mission, should it be shown as active in the UI?
• What should a disabled camera do if it gets a camera trigger command later that is targeted to its component ID (not broadcast)? Should it decide it is still disabled, or should it accept the command?

My second concern is about the next mission. Generally it is much better if a setting in a mission does not persist beyond the mission.
Say I run a mission and it sets the camera up. I then run a new mission and it specifies nothing about cameras - it just uses whatever is currently set and that may not be appropriate.

Lastly, I wonder if the mission should in some way display which cameras are active and which are inactive?

Do we perhaps need to have a camera enabled/disabled state and publish that as well?

Lots of questions sorry.

PS
I think we either need to either

• explicitly publish and expose the enabled/disabled state of cameras and use that in our UI, or
• we need to make this new command NOT be set out, but instead modify all the other camera commands it sends out to have the desired component ids. That would be my preference, but probably very hard to implement.

[auturgy]

#1678

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[hamishwillee]

THanks for closing this @MatejFranceskin

I don't think it is a solved problem yet. If we ever need to then I think we'd lean towards the gimbal approach and just add a target component id to an empty param (like MAV_CMD_DO_GIMBAL_MANAGER_CONFIGURE) and get the flight stack or mavlink camera to use this if it is non-zero.
Not "perfect" but consistent.