-
Notifications
You must be signed in to change notification settings - Fork 120
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
[ROS2] reconfigurable transport scoped parameters for theora #146
[ROS2] reconfigurable transport scoped parameters for theora #146
Conversation
- runtime reconfiguration for publisher and subscriber - <image>.<transport>.<param> as future replacement of <image>.<param> - e.g. `image.theora.target_bitrate` instead of `image.target_bitrate` - support both ways for now - emit deprecation warnings on setting through non-transport scoped parameter - synchronize deprecated changes to new ones - this is necessary for dynamic reconfigure The publisher is a bit more complex here - in general we reload config on publish - but some code paths (conditional compilation) - would result in resetting context on every config reload - so we flag to reload config only on parameter event change - and reload it once on init to mimic ROS1 dynamic reconfigure setup The subscriber is simple as it already had necessary checks. Related to ros-perception#140
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.
Apart from the suggestions left, things look great!
Good to see the parameters added back in and not left as a TODO.
- example parameter paths (comments) are now theora specific Requested in ros-perception#146
Should be fixed now. The only deviation was in subscriber which has parameter |
@Mergifyio backport iron |
✅ Backports have been created
|
#140 fix for theora_image_transport (publisher and subscriber)
#108 like (runtime reconfigurable)
Implementation is #143 like + minor deviation for publisher.
The original logic behind dynamic reconfigure callbacks was kept.
publisher notes
The publisher is more complex here
This is different from all other transport scoped changes so far where we could make transport reconfigurable without depending on parameter event monitoring (in the spirit of #108).
The difference is only in setting/resetting/checking flag but event handling code exists only for the purpose of deprecated parameters in other transports.
code repetition
There is some code repetition between:
This should be temporary until deprecated parameters are removed.
The way to proceed was sketched in: