Skip to content
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

Various camera improvements #681

Merged
merged 11 commits into from
Mar 21, 2019
Merged

Various camera improvements #681

merged 11 commits into from
Mar 21, 2019

Conversation

julianoes
Copy link
Collaborator

As part of testing against the camera-manager, various issues are coming up.

Copy link
Contributor

@shakthi-prashanth-m shakthi-prashanth-m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Added few comments.

*
* @param id The camera ID from 0 to 5.
*
* Currently supported are IDs 0 to 5 mapping to MAVLink component IDs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to mention MAVLink ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for now this can be helpful.

There can potentially be multiple camera components under the same
system id. Therefore, we can select the camera ID from 0 to 5 for each
instantiation of the camera plugin.
We forgot to actually try to grab the camera definition file using the
URI supplied via mavlink.
This is a workaround to manually enable the camera plugin if a camera
only is connected. It is needed for tests where we test against a
camera (e.g.  camera-manager) without an autopilot. In this case the
current discovery mechanism doesn't work (or doesn't complete in time)
because we never receive a autopilot version. The workaround is just to
check at 2 Hz if a camera is now connected and in that case initialize
everything.
By adding a cookie such as this to the set_param_async and
get_param_async calls we can add a cancel method allowing any
outstanding work of an object to be deleted. This can prevent bugs where
objects are destroyed but callbacks are still dangling.
This adds a mutex around the callback which is shared data, and makes
sure we make a copy before capturing the callback in lambdas.
@julianoes julianoes marked this pull request as ready for review March 14, 2019 10:32
plugins/camera/camera_impl.cpp Outdated Show resolved Hide resolved
plugins/camera/camera_impl.cpp Outdated Show resolved Hide resolved
plugins/camera/camera_impl.cpp Show resolved Hide resolved
plugins/camera/camera_impl.cpp Show resolved Hide resolved
JonasVautherin
JonasVautherin previously approved these changes Mar 14, 2019
Copy link
Collaborator

@JonasVautherin JonasVautherin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@julianoes julianoes merged commit a615e52 into develop Mar 21, 2019
@julianoes julianoes deleted the camera-improvements branch March 21, 2019 15:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants