-
-
Notifications
You must be signed in to change notification settings - Fork 510
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
Capability flags in camera information #2213
Conversation
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.
Can you fix the style by running ./tools/fix_style.sh .
? That should make the CI happy 😇
Oh one more thing: you need to make the mavsdk-proto submodule point to your branch that adds this definition (otherwise the CI will fail). When both PRs (this one and the mavsdk-proto one) are accepted, we can merge the mavsdk-proto one, you can update the submodule here, and finally we can merge this PR. Does that make sense? |
Yes, that makes sense. I will then wait for that one to get merged and will change the proto submodule here |
You can already point this PR to your MAVSDK-Proto branch, such that the CI passes here. Then it will have to be changed again once the MAVSDK-Proto PR gets merged 👍 |
…ate in proto repository
3423b1b
to
0eb1dea
Compare
Signed-off-by: Julian Oes <[email protected]>
Signed-off-by: Julian Oes <[email protected]>
Quality Gate failedFailed conditions |
* Capability flags im camera information * Updated interface of camera capability flags setting to match the update in proto repository * Fixed code style * Merged tracking_server plugin into camera_server * Fix not registered callback for set_message_interval command * Fixed missing fourth argument in track_rectangle * camera_server: fixup conflicts * Update proto submodule
This PR goes together with the #329 PR in MAVSDK-Proto and adds the implementation for setting CAMERA_CAP_FLAGS in camera information by the user. This allows the user to set additional capabilities that cannot be determined automatically based on callback presence or so. For example, the implementation can not determine whether the CAMERA_CAP_FLAGS_CAN_CAPTURE_IMAGE_IN_VIDEO_MODE should be set, but this can be useful for some users. Another example of such a need is when the component also uses the tracking_server plugin for object tracking and the CAMERA_CAP_FLAGS_HAS_TRACKING_POINT or similar should be set in that case.
I didn't remove the functionality of determining four of the flags based on callback presence. This way, setting no flags will behave in exactly the same way as before