fkie / multimaster_fkie

ROS stack with FKIE packages for multi-robot (discovering, synchronizing and management GUI)
BSD 3-Clause "New" or "Revised" License
272 stars 106 forks source link

sync_hosts not working? #60

Closed davidbsp closed 7 years ago

davidbsp commented 7 years ago

Hi! I am using ROS Kinetic (Ubuntu 16.04) and I am doing some tests with ROS Multimaster.

According to the documentation (ROS Wiki): ~sync_hosts (array, default: []) This list with names of ROS master to synchronize. Only this ROS master in this list will be synchronized. The ~ignore_hosts list is processed first.

I have two PC running separate roscores:

1) "ing3", IP: 172.16.1.112 2) "robot-0", IP: 172.16.1.155

This is how I am roslaunching multimaster on both PCs:

<launch>
    <node pkg="master_discovery_fkie" type="master_discovery" name="master_discovery"/>

    <node pkg="master_sync_fkie" type="master_sync" name="master_sync">
        <rosparam file="$(find utils)/multimaster_config.yaml" command="load" />
    </node>    
</launch>

This is my "multimaster_config.yaml":

sync_hosts: ['whatever']
sync_topics: ['/results']   

I would expect the machines not to sync with each other. However, I still get the topic "/results" synched in the two different masters.

Is it a bug, or am I doing something wrong? My idea is to be able to selectively sync only a few topics, and between specific ROS machines (while excluding others).

atiderko commented 7 years ago

Hi,

try to add

ignore_hosts: ['/*']

Or you can specify as follow:

sync_topics:
  - whatever:
    - /results

It is an undocumented feature...

davidbsp commented 7 years ago

Hi @atiderko, thank you for the reply.

Using ignore_hosts: ['/*'] in both machines, surprisingly I get all topics relayed from one machine to the other. Although ignore_hosts: ['*'], without the dash, works fine.

Using:

sync_topics:
  - host:
    - /results

I am only getting the following topics on the "host" machine (no "/results" topic...):

/master_discovery/changes
/master_discovery/linkstats
/rosout
/rosout_agg

Additionally, in both situations I am now getting the following warnings in both machines:

[WARN] [1493717654.997942]: Master_discovery node appear not to running. Wait for topic with type 'MasterState.
[WARN] [1493717659.318225]: Resolved host of ROS_MASTER_URI ing3=None and origin discovered IP=172.16.1.112 are different. Fix your network settings and restart master_discovery!
[WARN] [1493717659.862571]: ERROR while update master[ing3]: Traceback (most recent call last):
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_sync_fkie/master_sync.py", line 169, in update_master
    self.masters[mastername] = SyncThread(mastername, masteruri, discoverer_name, monitoruri, 0.0, self.__sync_topics_on_demand)
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_sync_fkie/sync_thread.py", line 113, in __init__
    [])
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_discovery_fkie/filter_interface.py", line 79, in load
    sync_topics, mastername)
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_discovery_fkie/common.py", line 276, in create_pattern
    def_list = list(set(def_list))
TypeError: unhashable type: 'dict'

and

[WARN] [1493717647.587060, 1493717641.698958]: Master_discovery node appear not to running. Wait for topic with type 'MasterState.
[WARN] [1493717656.885759, 1493717650.962630]: ERROR while update master[robot-0]: Traceback (most recent call last):
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_sync_fkie/master_sync.py", line 169, in update_master
    self.masters[mastername] = SyncThread(mastername, masteruri, discoverer_name, monitoruri, 0.0, self.__sync_topics_on_demand)
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_sync_fkie/sync_thread.py", line 113, in __init__
    [])
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_discovery_fkie/filter_interface.py", line 79, in load
    sync_topics, mastername)
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/master_discovery_fkie/common.py", line 276, in create_pattern
    def_list = list(set(def_list))
TypeError: unhashable type: 'dict'
atiderko commented 7 years ago

you are right, it should be without slash!

But I can not reproduce the warning. Which version did you use?

Does this warning always occur?

[WARN] [1493717659.318225]: Resolved host of ROS_MASTER_URI ing3=None and origin discovered IP=172.16.1.112 are different. Fix your network settings and restart master_discovery!
davidbsp commented 7 years ago

Thanks for the reply @atiderko.

I am using the apt version for kinetic (got it via "sudo apt install ros-kinetic-multimaster-fkie"). According to the "package.xml" of both "master_discovery_fkie" and "master_discovery_fkie", this is version 0.7.2.

That specific warning only occurs sometimes when I start the system, and when it occurs, it just prints once. Could it be related to the fact that I am launching both nodes in a launch file, and the sync node may start before the discovery node?

Regarding my network settings, should I enable multicast as stated in pag. 8 of this document? I tried enabling it, and later I disabled it: the result seems to be the same.

atiderko commented 7 years ago

I reproduced the warning if I configured as follow:

<node name="master_sync" pkg="master_sync_fkie" type="master_sync">
    <rosparam param="sync_topics">
      - tiderko3:
        - /*cfg*
    </rosparam>
</node>

I fixed this issues.

To use the fixed version you have to install from github.

davidbsp commented 7 years ago

Commit aa3b870 fixed the issue regarding the synchronization of a specific topic from a specific host. Thanks! :+1:

Going back to the original issue: it seems that the "sync_hosts" parameter does not work as expected.

Example: If I have machine A, and B, and I set "sync_hosts: ['C','D']" in A and B, I still get all topics from A and B synchronized. Can you confirm @atiderko?

atiderko commented 7 years ago

you are right, it works only if 'ignore_hosts' is set to '*' at the same time. I added a fix to go confirm with the description.

davidbsp commented 7 years ago

v0.7.4 (commit 08598be) fixed the issue. Perfect, thanks!

atiderko commented 7 years ago

@davidbsp: thank you for reporting and testing