-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add new camera server #274
Conversation
This adds new camera server plugin protocol with a few basic commands for device discovery and still image capture. It works like this: 1. New camera service instance is created and attached to system. 2. The SetInformation method must be called right away, otherwise systems will think that there is no camera. 3. To handle taking pictures, the SubscribeTakePhoto method is called. When this method is called back, the implementer must call the SetInProgress with `true` method right away. Then the picture is taken and the implementer calls SetInProgress with `false`. Finally, the implementer must call the PublishPhoto method.
The bigger design pattern that can be inferred here is that for any state, there is a For messages received from an autopilot/GCS that require the camera to actually do something and not just return the current state, there are |
I've updated the proposed protocol to reflect this. The idea is that from the point of view of the plugin user, the subscribe function will always look like a single image capture message. The plugin internals will automatically call back the subscribe method multiple times for a single mavlink message with a time interval. |
Some additions on top of your .proto that I had in mind can be found at https://github.com/dayjaby/MAVSDK-Proto/commits/camera-server:
Each mode has its own subscribe function as the camera capabilities get automatically constructed depending on which camera mode subscriptions exist.
The ZoomRequest contains the minimal and maximal focal length, so it's able to handle both SET_CAMERA_ZOOM with the zoom values being in focal length or as a percentage.
Handles stuff like CAM_ISO, CAM_EV, or any other parameter specified in the camera definition xml. |
The subscription to feature flag idea is interesting. It took me a while to understand what you meant but now think I like it. 👍 It means that we would need an additional rule that all subscriptions need to be made before calling SetInformation. I like that better than having to specify the flags and subscribe separately. Also, as I described above, each Subscribe method needs a corresponding Respond method so that the user code can send an appropriate response when it has handled the action. It isn't safe for the plugin to assume that all of these operations were successful and respond automatically. Also it could take some time, e.g. to actually change the mode, and the response should be delayed until after the mode has actually physically been changed in the camera. Additionally, we will need methods like |
I think there should only be one SubscribeSetMode method since this will correspond to the CAMERA_CAP_FLAGS_HAS_MODES flag. The CAMERA_CAP_FLAGS_CAPTURE_IMAGE flag is determined by |
// Sets the camera information. This must be called as soon as the camera server is created. | ||
rpc SetInformation(SetInformationRequest) returns(SetInformationResponse) { option (mavsdk.options.async_type) = SYNC; } | ||
// Sets image capture in progress status flags. This should be set to true when the camera is busy taking a photo and false when it is done. | ||
rpc SetInProgress(SetInProgressRequest) returns(SetInProgressResponse) { option (mavsdk.options.async_type) = SYNC; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should rename it to "SetImageCaptureInProgress" as that's less ambigious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably pick either TakePhoto
or ImageCapture
and use that everywhere to keeps things consistent. I initially chose the name TakePhoto
to match camera.proto
, so this would be SetTakePhotoInProgress
to match SubscribeTakePhoto
.
@dlech how should we proceed here? There seem to be some good discussion but I'm not sure if they have been applied or if you plan on changing this PR? I'm sorry I was busy for a while and only just returning to all these PRs. |
I think I would like to solve mavlink/MAVSDK#1700 first. It would make creating and consuming an API much easier. |
Oops, I guess I merged your commits as part of #283, closing this. Let's follow up in new PRs. |
Ha, OK. |
This adds new camera server plugin protocol with a few basic commands for device discovery and still image capture.
It works like this:
true
method right away. Then the picture is taken and the implementer calls SetInProgress withfalse
. Finally, the implementer must call the RespondTakePhoto method.