Subscriber Collisions

Issue

• https://github.com/robotics-in-concert/rocon_multimaster/issues/136

Scenario

• 3-master system : 'PC Concert', 'Robot A', 'Robot B'

• 'Robot A' flips ros_tutorial listener's /chatter subscriber to 'PC Concert'.

• 'Robot B' flips ros_tutorial listener's /chatter subscriber to 'PC Concert'.

• 'PC Concert' starts ros tutorial talker.

Symptom

• Talker bounces between sending to robot A or B, but never both.

The problem here is that each listener node has the same id - typically /listener. These collide when registered in the third system and because individual ros systems must guarantee that node id's are unique, the publisher will delete any connection to the former every time a new connection is made by the latter.

Solution

This can be avoided by ensuring that thel listener nodes are pushed down into a unique namespace that won't collide on the third system. The concert framework does this by guaranteeing the robot is given a unique name before it starts its applications and this name is used to push nodes down into a unique namespace.

Multimaster Subscribers

Issue

• https://github.com/robotics-in-concert/rocon_multimaster/issues/127

Scenario

• 2-master system : 'PC Concert', 'Robot A'

• 'Robot A' flips ros_tutorial listener's /chatter subscriber to 'PC Concert'.

• A talker on 'PC Concert' connects to the subscriber.
• A talker on 'Robot A' also connects to the subscriber.

Result

As soon as the second talker connects, the listener removes the connection to the first talker.

Solution

Currently none. This is due to the way the subscribers receive updates over xmlrpc from the master when new publishers are connected. It doesn't just get the information about the new publisher - it gets the complete list of connected publishers on the current master. The subscriber makes sure these connections are all up to date, but this means any connections to other masters are lost.

This would be easy to fix actually, but those fixes would have to go in roscpp, rospy and rosmaster. Rather than tackling that now, we are planning to wait for the next gen comms design. For now, it is not a problem for us, as we only utilise such connections on the remote side.