[ros-users] Shared memory image plugin

[Cedric Pradalier]

Hi,

Patrick Mihelich wrote:
> On Thu, May 6, 2010 at 5:05 PM, Cedric Pradalier 
> <cedric.pradalier at mavt.ethz.ch <mailto:cedric.pradalier at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sharedmem_image_transport.tgz
Type: application/x-compressed-tar
Size: 6758 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100507/2bef7c68/attachment-0005.bin>