[ros-users] Generic message transport infrastructure

[Cedric Pradalier]

I've finally spent some time updating significantly the 
sharedmem_transport plugin, in part to reply to Josh's comments.
All the buffers are now mutex-protected, variable-size data structure 
are supported, and data availability is communicated through conditions.

Shared mem seems to have a small advantage over loopback when multiple 
clients are reading simultaneously from a single source. In this case, 
the delay can be the same for all the clients, as long as they run on 
different cores. On the other hand, loopback allows reading the data 
while it is being written.

In the end, the performance improvement does not seem astonishing, but 
the package will be a good starting point for someone wondering if 
he/she would be better off with shared memory.

Comments welcome. Constructive comments preferred...

On 12/02/10 19:05, Cedric Pradalier wrote:
> After a long time since my first post about a generic message transport
> architecture, we finally released it in the ETHZ-ASL message transport
> stack.
> Details about the ethzasl_message_transport stack can be found at
> http://www.ros.org/wiki/ethzasl_message_transport
>
> In addition to the framework, we also implemented a shared-memory
> transport plugin and a udp multicasting transport plugin, and
> instantiated the transport plugins for images and point-clouds.
>
> The shared memory transport will not offer the same performance as using
> nodelets, but it can be an option when very large object needs to be
> passed around while keeping different processes (there have been several
> discussions on this topic on this list).
>
> The UDP multicasting transport is interesting when small objects needs
> to be passed very quickly to many receivers on several machines (in
> comparison, normal tcp transmission will incur a delay increasing with
> the number of subscribers). Note that the plugin does not manage object
> fragmentation, and does not intend to do it (it would defeat the
> purpose). This means that it will refuse to send object bigger than 8092
> bytes.
>
> Other type-specific transport plugins can quickly be implemented using
> this framework. As examples, I've adapted the theora and compressed
> image transport, and implemented a decimated point cloud transport.
>
> Ideally, the udp multicasting stuff (and shm) should go into the core of
> ROS, but I have not understood enough of the xmlrpc negociation to
> implement it myself.
>
> HTH
>
>    

-- 
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp