Re: [ros-users] Shared memory image plugin

Top Page
Attachments:
Message as email
+ (text/plain)
+ sharedmem_image_transport.tgz (application/x-compressed-tar)
Delete this message
Reply to this message
Author: Cedric Pradalier
Date:  
To: ros-users
Subject: Re: [ros-users] Shared memory image plugin
Hi,

Patrick Mihelich wrote:
> On Thu, May 6, 2010 at 5:05 PM, Cedric Pradalier
> < <mailto:cedric.pradalier@mavt.ethz.ch>>
> wrote:
>
>     I've just written a small shared-memory based
>     image_transport_plugin using boost::interprocess

>
>
> Cool! I think you're the first person outside WG to write an
> image_transport plugin, so any feedback about the architecture is welcome.

The architecture is really easy to use and quite intuitive. This also
why I was wondering if a generic message_transport_plugins architecture
would make sense.

>
>     - First, I don't see how to write it efficiently while having the
>     publish function const in image_transport/publisher.h. I currently
>     wait to receive the first image to allocate the shared memory
>     segment, and as far as I could tell, I can only do it in the
>     publish function of the plugin, so this has to be non-const. Any
>     reason why it would have to be const? Or any hint on how to
>     achieve the same result while having the function const?

>
>
> publish() is const to match the API of ros::Publisher, but you can
> still do what you want. You just need to mark the class members that
> change with the "mutable" keyword. See TheoraPublisher in
> theora_image_transport for an example; it similarly does some setup in
> publish().

Thanks for the hint. This makes it work with vanilla ROS (from SVN).
Please find the updated version attached. Feel free to include it in the
image_transport_plugins if deemed useful.

>
>     - Second, as it is written now, the plugin does not care at all
>     that the object it manipulates are images (it cares that the
>     object are constant/bounded size though). So would it be possible
>     to extend/convert the image_transport plugin architecture, to a
>     generic message_transport plugin architecture? I think sharedmem
>     transfer would be particularly suitable for big point clouds...

>
>
> Shared memory transport is a common feature request. There's a long
> discussion of the issues at
> http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html
> <http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html%20>that
> should get you caught up.
>

This links says me "Not found"...

> Short version:
> * We haven't found shared memory transport of serialized data to be a
> significant improvement versus TCP over loopback, but are interested
> in evidence to the contrary.
> * Storing the message objects themselves in shared memory could be a
> win, but gets very complicated to implement.
> * We've focused on optimizing intra-process (no-copy) message passing
> and are developing the nodelet <http://www.ros.org/wiki/nodelet>
> infrastructure; big point clouds are the motivating use case.
>

Similarly, I don't observe a significant performance gain on my laptop
either. From htop output, I could make myself believe that 5-10% perf
gain are possible, but this is clearly marginal. However, it might be
different with more active processes, more cpus, less cpus, more/less
rams, bigger use of the network stack, different hardware (gumstix?), so
I would tend to put this image_transport_plugins in the common pool,
just in case.

Best regards, and thanks for the feedback.

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