Nodelet zero-copy transport not working with multiple nodelets

Question

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

---

Originally posted by pmolina on ROS Answers with karma: 108 on 2012-07-25

Post score: 0

---

Original comments

Comment by Lorenz on 2012-07-26:
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?

Comment by pmolina on 2012-07-26:
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

Answer 1

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.

---

Originally posted by Lorenz with karma: 22731 on 2012-07-26

This answer was ACCEPTED on the original site

Post score: 3