[ros-users] Shared memory image plugin
cedric.pradalier at mavt.ethz.ch
Fri May 7 09:50:38 UTC 2010
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>>
> 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
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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6758 bytes
Desc: not available
More information about the ros-users