[ros-users] Shared memory image plugin
Cedric Pradalier
cedric.pradalier at mavt.ethz.ch
Fri May 7 09:50:38 UTC 2010
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>
More information about the ros-users
mailing list