ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Nodelet zero-copy transport not working with multiple nodelets

asked 2012-07-25 10:04:15 -0500

pmolina gravatar image

Hi There,

I am hoping someone can shed some light onto the following situation. I am using nodelets to achieve zero copy transfer between several algorithms running on the nodelets. (and hence using the object passed as shared-memory) When I launch only 2 nodelets and hence only 1 nodelet is subscribed to a certain message, the zero-copy transport works as expected. I am able to modify the data on the second nodelet and see the difference in the first nodelet object. However, when I launch a third nodelet subscribed to the same topic, the zero-copy transport stops working and I receieve a copy of the object (because I modify it and do not see the change)

Is there are reason why this might be happening?

I have tried modifying the queue size, etc? Are there any implementation details of the zero-copy transfer that might be causing this?

Thanks for your help


edit retag flag offensive close merge delete


I don't really understand your setup. So you have one topic /foo and two nodelets subscribing to it? And how is the third nodelet then connected?

Lorenz gravatar image Lorenz  ( 2012-07-26 02:03:20 -0500 )edit

Yes, two nodelets that subscribe to this topic. When I publish the message, I send a boost::shread_ptr to ensure that there is zero copy transport. This works when only 2 topics subscribe.When I also subscribe a 3rd nodelet to the same message, the zero copy transport stops working

pmolina gravatar image pmolina  ( 2012-07-26 03:16:22 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2012-07-26 04:06:14 -0500

Lorenz gravatar image

updated 2012-08-06 22:16:24 -0500

tfoote gravatar image

The zero-copy transport is not specific for nodelets but can always be used for intra-node communication. I just did a simple test that definitely works, so I don't think something is wrong with the transport mechanism itself.

How are you starting the nodelets? Are they all in the same nodelet_manager or is it maybe the case that you start the third nodelet in a separate manager?

You should not change data in messages after they have been published. There is a reason for them being const pointers in the callbacks and without proper locking, you shouldn't change data. And it's in the contract of the publisher to not change the data after having published it.

edit flag offensive delete link more

answered 2012-07-26 04:40:09 -0500

pmolina gravatar image

Hi Lorenz, Thanks for trying this yourself. I am sure that all the nodelets are running from the same manager

I basically need a mechanism for sharing memory among nodelets. I am using lots of images, point clouds and such (a there are real-time navigation requirements for the code) and therefore copying this data all around would be very slow. I was reading threads and it seems that this is the only way that one can somehow "share" data among nodelets.

What I am basically doing is sending an object that is allocated in the heap by one nodelet and passing it as a boost::shared_ptr. Then in the other nodelets I push this onto a vector of boost::shread_ptrs . Afterwards, I pass the ID of the object to the nodelets so they can start working (they look for the object on their vector of pointers)

The messages received by the nodelets are const boost::share_ptr but they are not necessarily const boost::shared_ptr const so the data can be modified... again this works pretty well with only 2 nodelets...the moment the third nodelet is started and subscribes, the zero-copy transport stops working. The second nodelet receives only a coy of the object.

There is a sort of locking mechanism because the nodelets will not start working on the data unless the IDs are received and this is how I am controlling what nodelet uses the specific data.

I will try printing the pointers to see what is actually happening. I will also try sending the object back as opposed to the ID as this might be causing copies.


edit flag offensive delete link more


If I start only 2 nodelets and print the pointers, the sent pointer address and the received pointer address are exactly the same ( 0x7f3c0c06ef50). If I start the 3rd nodelet, the pointer being sent is 0x7f477806ef50; received at the second nodelet 0x7f4780001760, at the third 0x7f477c000c30

pmolina gravatar image pmolina  ( 2012-07-26 04:46:09 -0500 )edit

if I start the 1st and 3rd nodelets, the sent and received pointer address is exactly the same as well (0x7fcfe406ef50)

pmolina gravatar image pmolina  ( 2012-07-26 04:55:35 -0500 )edit

Please don't create new answers that don't answer anything but edit your original post instead. Without seing your code and how you start up the nodelets, it is hard to infer what's going wrong since the shared_ptr transport definitely seems to work.

Lorenz gravatar image Lorenz  ( 2012-07-26 04:55:51 -0500 )edit

Trying to implement a multi-threaded shared-memory application without completely understanding the details is a recipe for disaster. @Lorenz already answered your original question, the bug is in your code not in ROS.

joq gravatar image joq  ( 2012-07-26 05:08:46 -0500 )edit

Question Tools


Asked: 2012-07-25 10:04:15 -0500

Seen: 1,363 times

Last updated: Aug 06 '12