[ros-users] roscpp with transport plugins

[Cedric Pradalier]

Hi Shaun,

It looks like the low-level transport plugin architecture is unlikely
to make it soon in roscpp.

However, I've now added a bz2_transport in our previous
message_transport stack:
http://www.ros.org/wiki/ethzasl_message_transport
The advantage of the stack is that it provides the different
transports (bz2, multicast, shm...).
The disadvantage is that the templates have to be instantiated for
each type. I've done it only for PointCloud so far, but it could be
copy-pasted to PointCloud2.
The other disadvantage is that the publisher needs to publish with a
specific publisher, similar to the standard image_transport
(compressed/theora).

What's also missing is a nice dynamic_reconfigure gui to change the
compression parameters. I'll see about doing it if the user base
justify it.

I hope that helps. Let me know if you find bugs or missing features.


On Wed, May 30, 2012 at 3:18 AM, Edwards, Shaun M. <sedwards at swri.org> wrote:
> +1 if the compress/decompress helps with point clouds and images.
>
> Shaun Edwards
> Senior Research Engineer
> Manufacturing System Department
>
>
> http://robotics.swri.org
> http://rosindustrial.swri.org/
> http://ros.swri.org
> Southwest Research Institute
> 210-522-3277
>
> -----Original Message-----
> From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Cedric Pradalier
> Sent: Tuesday, May 29, 2012 4:17 PM
> To: User discussions
> Subject: Re: [ros-users] roscpp with transport plugins
>
> 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users



-- 
Cedric Pradalier