Nodelet zero-copy transport not working with multiple nodelets

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

pmolina
108 ●4 ●8 ●12

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

Pablo

edit retag flag offensive close merge delete

Comments

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 ( 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 ( 2012-07-26 03:16:22 -0500 )edit

add a comment

3

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

Lorenz

22731 ●129 ●202 ●316 http://ias.in.tum.de/p...

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

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

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

add a comment

0

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

pmolina
108 ●4 ●8 ●12

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.

Thanks

edit flag offensive delete link

Comments

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 ( 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 ( 2012-07-26 04:55:35 -0500 )edit

4

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 ( 2012-07-26 04:55:51 -0500 )edit

2

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 ( 2012-07-26 05:08:46 -0500 )edit

add a comment

Nodelet zero-copy transport not working with multiple nodelets

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Nodelet zero-copy transport not working with multiple nodelets edit

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Nodelet zero-copy transport not working with multiple nodelets