[ros-users] roscpp with transport plugins

[Cedric Pradalier]

Replying my own email in case there is interest outside the RosNG SIG.

I've kept experimenting with roscpp a bit and added UDP multicasting
to the transport plugins.

Additionally, I've added a mechanism to pre-process serialized
messages before sending them. As an example, I've added a bzip2 plugin
that will compress/decompress any message on a topic (if the
TransportHints say so).

I'm not sure if there is an interest to push that up-stream or if this
should be an output of one of the SIGs...

On Sun, May 27, 2012 at 2:15 PM, Cedric Pradalier
<cedric.pradalier at gmail.com> wrote:
> Hi all,
>
> Following the interest on making ROS transport layer more modular, and
> as a conceptual experiment, I've tried making a version of roscpp with
> transport plugins.
> This is obviously C++ only and I did not find any road-block. To test
> it, I've created a transport plugin implementing shared memory.
>
> So what works?
> - TCP and UDP transport work as before
> - A transport plugin manager has been added, and offers functions to
> register new transport plugin
> - Transport hints can now refer to modules in the transport plugin manager
> - Place that were explicitly referring to UDPROS and TCPROS now use
> the transport plugin manager to find which transport to use.
> - A shared memory transport has been added. This is not in roscpp to
> experiment with dynamic loading...
>
> When writing a new plugin, one just need to create one descriptor
> class, and inherit from the PublisherLink and SubscriberLink classes
> for the details.
> To the contrary to my previous message_transport package, the
> transports do not need to be type specific.
>
> What's not working?
> - So far the transports (apart from UDP and TCP) need to be registered
> explicitly in any node after ros::init. I will probably use the
> pluginlib framework to make listing the transports easier. I'm not
> sure if dynamic loading directly from ros::init would be possible.
> - In the shared memory plugin, the shared memory object needs to be
> created and destroyed by an independent node (for persistence). This
> could possibly be integrated into a generic transport manager node...
>
> The conclusion is that, at least in C++, there is no particular
> problem to make the transport layer more open.
> I'm happy to send the diff for review if there is an interest. This is
> not production code, but I don't think what I changed has the
> potential to be disruptive. It's mostly reorganising some bits and
> pieces into functions and classes.
>
> I would guess that the same comment would apply to python, but I'll
> let this one to someone else.
>
> Cheers
> --
> Cedric Pradalier



-- 
Cedric Pradalier