Updated: Jul 2
image_transport is the backbone of any non-local image processing in ROS/ROS2. The workhorses of image_transport architecture are the plugins.
While migrating numerous Extend Robotics repositories we noticed a problem in the current ROS2 implementation.
In ROS/ROS2 image_transport plugins declare parameters which control internal mechanisms of (de)compression. Think of bit-rate, format, compression level and alike.
In ROS1 this is supported by dynamic_reconfigure as defined in image_transport 4.1.2 Parameters documentation. Each transport plugin parameter lives in
<base topic>/<transport name>/<parameter name>
What we encountered in ROS2 were plugins declaring parameters in
<base topic>.<parameter name>
Some of the difference here stems from different representation of ROS1/ROS2 parameter paths. The real problem is not scoping parameters under transport name like compressed.
The end of the world
Consider two transports, declaring some_parameter. With the existing implementation both declare parameter as say
... and KABOOOM!
The lucky ones would crash from
The less fortunate may suffer from side effects of clashing parameters with different defaults, data type or meaning.
The clash might also happen between the transport and camera driver if it declares parameter on image level.
We originally reported the problem to ROS community here.
The fix would be a three-liner...
... if it wasn't for the fact that ROS2 has been in development for 8 years now.
There are thousands of software packages and people depending on broken behavior.
Taking responsibility means the hard way - supporting the correct parameters, deprecating old ones, emitting warnings and supporting both in transition period.
That is something a lot more complex.
We supplied the fix in a series of pull requests, namely:
While doing that we also made all parameters runtime reconfigurable (were only for compressed publisher) and reintroduced theora parameters for ROS2.
We would like to thank ROS2 image_transport_plugins maintainer Kenji Brameld for working with us to get this fixed.
The gory details of ROS2 image_transport parameters are complex. If every plugin solves it independently we are asking for trouble. We believe that in the future core support and guidelines should be pushed up to image_transport and not solved by individual plugins.
Extend Robotics is happy and proud to be part of worldwide robotics community!