Support hub topology by adding favor_unicast param

[deng02]

In cases where multicast sending is enabled but favor_unicast is also set, we only listen for multicast messages to detect remote ROS masters and then use unicast to send out heartbeat requests and state. What this allows us to do is deploy multimaster nodes as a hub rather than a mesh: master_discovery nodes with multicast and favor_unicast enabled with act as a client to any master_discovery nodes with multicast enabled but favor_unicast disabled.

The one caveat is that this can only work if all ROS masters are on a separate host. If more than one master_discovery is on the same host we have to use multicast to ensure that all processes receive the heartbeat state/request messages. In this case we default back to the 'normal' mesh like behavior.

This is useful for situations where: 1) Each ROS master is running on a separate host 2) Only one ROS master (hub) needs to talk to every other ROS master (hub clients) 3) We do not know beforehand the name or IP of the hub and want hub clients to attach to the hub automatically (otherwise we could disable multicast on each hub client and set the hub IP in the robot hosts param).

[deng02]

Our motivation to add a feature like this was because in our deployment we really only need a single "supervisor" ROS master to be aware of a large number of "robot" ROS masters (hub topology), rather than having every ROS master know about everyone else (mesh topology). With the mesh connectivity we end up seeing alot of unnecessary ROS master activity as each robot tried to keep in sync with the other which introduced some complications in diagnosing connection issues etc.

[roehling]

You can avoid syncs between peripheral systems by setting their master_sync's ~sync_hosts parameter to the hub, or (if two-way sync is not required anyway) by running the master_sync node on the hub only.

[deng02]

Thanks for the feedback! While we could set the sync_hosts parameter or use the robot_hosts parameter to indicate the hub is the one we want to sync with exclusively, for various reasons we wanted a solution that allows us to avoid having to set the hub hostname or IP explicitly in the launch file. This way the robots can discover hub(s) automatically at run time. Unfortunately we do need two-way sync between the robot and hub as they both contain topics the other one needs. We jus want to avoid robot-to-robot sync.

[deng02]

@atiderko @roehling Is there any interest in pulling this in at all? I'd be more than happy to address any concerns you may have.

[atiderko]

@deng02 sorry for delay! We were not in the office this week.

We will discus your hub solution next week.

[deng02]

That sounds great. Thanks so much for the response.

[deng02]

I have found a bug in my code through our testing simulators. I will be updating the PR.

[deng02]

I just noticed the listen mcast functionality! I'm going to close this PR and use the new listen_mcast parameter. Thanks!

[atiderko]

Hi @deng02,

we discussed your solution to create a hub. We found that it is difficult to explain how the favor_unicast parameter works. That's why I splitted the send_mcast parameter into send_mcast and listen_mcast. I hope it will works like you wish. You need to set the send_mcast to False on robots. The hub need no parameter changes. Unfortunately, I make a mistake and pushed the changes into the master branch. I hope this fix will works.

Thank you for your improvements and pull requests. I'm also sorry for delay while solving this issue/feature.

I will create a new release of this feature work as expected!

Regards, atiderko

[deng02]

Hi @atiderko,

I greatly appreciate the feature update, the separate of the listen and send mcast makes much more sense. I can understand how the favor_unicast was somewhat confusing. We will start testing with this immediately.

Thanks, deng02