Image/video capture commands do not set mode

[hamishwillee]

This updates the docs to note that the image and video capture commands do not set the camera mode.
So if you're in video mode and you start video capture the command may fail (depending on whether the camera supports separate image/video modes and whether it allows capture of the opposite type in each mode.)

@julianoes @Davidsastresas @rmackay9

FYI The camera API allows a GCS to handle cameras for the manual use case because you can query what the camera mode type is, whether separate modes are supported, and whether the camera allows capture in the opposite mode.

I'm not sure what we can or should do for missions though.
If you're using a camera that allows capture in any mode there is no issue. If you're using a camera that supports separate image/video capture and you're in the wrong mode then the capture will fail, ideally with a status update. That's it.

What a flight stack should do IMO is check the camera mode support as part of mission feasibility checks with associated sensible status/event updates to the GCS as to why the mission is invalid.

1. Should we suggest feasibility check in the docs?
2. Is there a standard behaviour when you get a command while you're already executing a command?
   • I.e. if I'm executing an image capture, and I get another image capture command, what should the camera do?
   • My thinking is that the command should always be rejected.. If you send another command to capture images on the same camera it should be rejected - you would first need to stop the existing capture. Reason being is that it is more predictable.
   • This does mean that missions that have a start image capture for a particular target should probably be preceded by a stop capture.
   • Should we state those things?

My concern ^^^ is that a GCS might do a simplistic mission implementation that assumes cameras can all capture images in all modes, and that the camera will always allow image capture commands to be overridden by later commands (the second is not specified)

[Davidsastresas]

The change in docs looks good to me too.

However, about the behaviour when a camera is under capture and we send another capture command, I think it would be better to take the new command and forget about the old one automatically. If user/mission sends a new capture command probably we are not interested any longer in the old ones.

Reason for this is that otherwise we would need a lot of extra waypoints on surveys, which are already very waypoint consuming.

[hamishwillee]

If user/mission sends a new capture command probably we are not interested any longer in the old ones.

I'm OK with that too. The important thing is to specify it. What do cameras/flight stacks do now?