Topics sharing with each other & other issues

[Lakshay Sharma]

Hi,

1. I have created a scenario in which there is one master controller (A) & two other robots (B & C).
   I want to send data from B to A & C to A, so for that I have establish a unicast network by turning send_mcast=false and listen_mcast:=false with robot_hosts name and also added host-name under ignore_hosts in B&C.
   After that on B & C, started a publisher node which publish its data on a /chatter topic & on A a listener is running which successfully reads data from both B & C, but when I started same listener on robot B , I was able to receive data from C as well,which we don't want to.
   IMPORTANT ONE
   So can you guide how we can isolate B & C robot ,because soon there will be some topics which will be common in both B & C and we want they only communicate with master i.e A

I have Attached one image ,so that you can understand whats going on

2. There is one more issue, we are using docker and created the above setup, without docker multicast works great but on docker, multicast failed to detect another fkie_masters which are on different host, they are under same WIFI network & communicating with each other via docker network overlay ,they got connected if we use robot_hosts & pass their host-names.
   (Ip_forward & icmp_echo_ignore_broadcasts are set as 1 & 0 along with hostnames of all robots in /etc/hosts)

So can you guide what we were missing ,why multicast failed to detect other hosts ,when running inside a docker.

3. There is one issue in master_sync.py file , please refer below image for error, it occurred when were sending /tf data from 3 different robots to a single Master

after debugging we found the content of warnings.items() were this, its missing _rtmd5sum

[(('/tf', '/play_1626337649605067242', 'http://192.168.1.12:32965/'), 'local: tf2_msgs/TFMessage, remote: tf/tfMessage')]

Thanks

[Alexander Tiderko]

Hi,

1. Due to ROS functionality on registration of a publisher the roscore informs all subscriber about new publisher. Then the subscriber connects to the publisher. Then only solution I see is to add the /chatter to ignore_subscribers on MASTER A and to ignore_publishers on robots. But you will not be able to send messages from Master A to robots!

2. Did you try to add a multicast route to docker interface on the host machine, e.g. sudo route add -net 224.0.0.0 netmask 224.0.0.0 docker0

3. Thanks for reporting! This bug has crept in with the last changes... should be fixed now!

[Lakshay Sharma]

Hi,
Thanks for your response,

1. As you said
   Then only solution I see is to add the /chatter to ignore_subscribers on MASTER A and to ignore_publishers on robots. But you will not be able to send messages from Master A to robots!
   It will be a one way communication , isn't there any way we can bidirectionally talk to each other?

2. I will check this route command & update you on this.

3. Thanks for fixing it up.

[Alexander Tiderko]

1. Do I understand correctly, you also want to send on /chatter topic from MASTER A to the robots, like /tf?

All endpoints that roscore knows will be connected by roscore. You can try to connect the publishers and subscribers directly without roscore, but then some of the ROS functionality (e.g. Inrospection with CLI) is likely to be lost. At this moment the master_sync does not support this functionality.

[Lakshay Sharma]

Not likely that will happen, let me first try scenario you mentioned then I will update you on the same.

Thanks

[Lakshay Sharma]

Hi @atiderko ,

1. first thanks for your help ,your solution worked very well, no topic data receiving on other robots which are mentioned under ignore_subscribers.
2. docker part didn't worked , I still have to manually pass hostnames ( I am using docker overlay as network driver which uses veth)
3. I was going through your documents & I found about mcast port, so I want to know can I use mcast_port to isolate my robots, like each robot is having different mcast ports & they are connected to a Main master computer A. Is this scenario possible ?
   e.g can a single launch file on Master computer A can handle all those robots having unique mcast ports or do I have to run same number of instances on Master computer too, can you clarify on this?

Thanks

[Alexander Tiderko]

Hi @marcus011 ,

1. Thanks for the feedback!
2. I'll take a closer look when I have more time
3. Short Answer: no
   mcast_port is used to start separate networks. This allows several groups to work in parallel without disturbing each other.
   Starting several master_discover and master_sync for one roscore can disrupt the local and the overall system.
   If you set send_mcast=true and listen_mcast=false the Master will see the robots but the robots not each other.

[methylDragon]

Hi @marcus011 ,

1. Thanks for the feedback!
2. I'll take a closer look when I have more time
3. Short Answer: no
   mcast_port is used to start separate networks. This allows several groups to work in parallel without disturbing each other.
   Starting several master_discover and master_sync for one roscore can disrupt the local and the overall system.
   If you set send_mcast=true and listen_mcast=false the Master will see the robots but the robots not each other.

Just wanted to check then, does this mean that using point 3 here, messages from each robot won't reach each robot, and the master can still send messages to each robot?

I.E. from Marcus' original post, where:

• B sends to master A
• C sends to master A

If we set send_mcast=True and listen_mcast=False, will the master be able to send messages to all robots, and the robots send messages to the master, but not to each other (since the robots won't see each other)?

Furthermore, should we be setting these parameters on the Master or on the robots? Or both?

[Alexander Tiderko]

No, unfortunately it's not that simple. That still depends on the configuration of the robots.
If a publisher and subscriber with the same name is created on all robots, they are registered with a ROS-Master on master. The result is that ROS ties all the topics together and everyone gets the message. Even though the robots cannot see each other. You then need at least additional filters for the master_sync on the master so that the robot's subscribers are not registered on the master Roscore.

So from the visibility of the robots one cannot infer the data transfer. Much more important is the question: where are which topics are registered? The roscore then takes care of establishing the connection between the topics.

If you set listen_mcast=False, this master_discovery won't see any other master_discovery.
send_mcast is True by default, but if you set it to False, no other master_discovery will see this master_discovery.

-> the listen_mcast should be True on the master to see the robots.