fkie / multimaster_fkie

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

General Question #70

Closed scholzt closed 6 years ago

scholzt commented 6 years ago

Hello,

I am currently trying to understand the functionallity of this package to reduce the network comnunication.

I an having 3 robots and one server. Each robot has its own namespace and all of them publishes the same topics. The Server is subscribing a few important topics. Each of thems starts a master discovery and sync node.

My aim is, that all robots ignore all nodes of the other robots. Therefore i use "ignore_nodes". The Server uses "ignore_topics / services" to receive only necessary information.

In case of ignoring e. G. a topic, does this mean, corresponding tcp data packages are not sent to the network and stay on the local master?

Checking the comnunication with wireshark, the robots still send a heap of packages into the network to each robot. But using ignoring nodes of this package they shouldn't, as far as I understand. The amount of meassured packages is nearly the same between Standard multimaster and multimaster using ignore Parameters.

Can you help me with this thread? Its hard to explain but I hope you can understand my general question behind this issue.

Thanks in advance!

atiderko commented 6 years ago

Hi,

master_discovery and master_sync do not care about ROS tcp traffic. master_discovery discover other master_discovery nodes and monitor the state of all registered ROS-nodes, topics and services in roscore. master_sync registers the state of discovered "remote" roscore's on local roscore. roscore does the rest.

In your scenario probably, you need only one master_sync on the server. And you define for master_sync e.g.:

sync_topics=[/robot1/topic_one, /robot2/topic_one, /robot2/topic_two]

to synchronize a few topics. Or use something like this:

<rosparam param="sync_topics">
        - robot1:
              - /robot1/topic_one
        - robot2:
              - /robot2/topic_one
              - /robot2/topic_two
</rosparam>

You can also configure master_discovery on robots with <param name="send_mcast" value="False" /> to avoid discover each other. So they respond only to discover messages of the server.

Now to problem with ignore_nodes. You're right in your assumption: if you configure master_sync to ignore all nodes with ignore_nodes:=[/*] (in this case you don't need run master_sync ;-) ) no data with node/topic names should be transmitted other the air. At least that's the case in my tests ;-)

If you still have a problem perhaps it is easier if you post parts of launch files.

regards

scholzt commented 6 years ago

Thanks for your reply!

I already tried the "sync_X" parameters, but I don't get the point of them. In case of using "ignore_X" parameters the topics / services share the data anyway, so what is the great advantage of using sync parameters? (Sorry for my silly questions, but I am not that familiar with the ROS communication system :) )

I think I still need on each system a master_discovery node. I will try to explain the system more detailled:

My aim is to make robot nodes (laser, imu, ...) in general as local, so that no data is being sent to the network and special defined topics (e.g. /info) and services for the system as global, to share the data between each other. That's why all nodes with robot namespace ("/robot0") are ignored by all other robots. Since the server is running RViz, some robot parameters e.g. "/robot0/move_base" are subsribed for visualization. What I can't see, is a reduction of data communication in Wireshark. It doesn't matter, if I use on each robot the ignore syntax or not. Only if I stop my multimaster on the server, the data reduces heavily to a minimum. I hope this explanation was a little bit more helpful? Since all launch files are pretty complex, I think I doesn't make sense to post some parts of them.

In general my idea was the following: Using multimaster to decentralize ROS Master. Furthermore, keep all robot nodes at first local. Only allow special defined topics (e .g. /info), nodes or services to send data to the network via TCPROS to reduce the network communication to a minimum. Do you think this is possible?

As far as I understand the ROS wiki, a topic does NOT sent any data to the network, in case of NO subsriber. That's the reason why I wanted to ignore all topics at first (to remove the subscribers and to block communication) and then to enable communication for specific topics.

Just one more question: Is it possible to ignore e. .g "/tf" on robot0, even if it publishes data to /tf? Which function has more priority in this case? Ignoring the topic or publishing data to this topic?

Thanks for your help anyway! Regards

atiderko commented 6 years ago

you should use "sync_X" if you have to synchronize a few topics and ignore the rest. If you have to synchronize a lot topics but ignore only few, you take "ignore_X".

I think, your problem is the "/tf" topic. If you start the synchronization on the server, the master_sync regiter all publisher/subscriber of /tf (e.g. /robot0/move_base, /robot0/xyz, /robot1/move_base, /robot2/move_base,...). The roscore ensures that all are connected together. So you have a NxN relation. Also the topics of robot0 are connected to robo1 although you configured on robot0 to ignore "/tf" from robot1. This is the reason why you don't see any changes in wireshark.

You can try to remap tf to specific robot tf:

<remap from="/tf" to="/tf_robot0"/>

Did you tried to run node_manager on server to see which nodes/topics or services are synchnized?

Note: master_discovery and master_sync do not care about the data traffic on topics. master_sync changes only the lookup table on local roscore.

regards

scholzt commented 6 years ago

Well, but all nodes sync themselves with this multimaster API even without using the "sync_X" parameters. So I don't understand the meaning of them. Does this mean, when I only use e. g. "sync_topic"[/info] all other topics are not synchronized by the master?

With a NxN relation do you mean, that each robot is connected to each other robot in the system? So having a global topic, which is subscribed by each robot, this topic is responsible for the connection between all robots, meaning all robots share there tcp data with each other even with usage of "ignore_X" parameters? So in this case, all of my master_sync parameters are useless?

Can you provide a code example how to use this tf remapping? I don't know this one.

No, I haven't tried node_manager yet. But I will check this on monday.

So, when you mean, they don't care about data traffic on topics, you say, it is not possible to reduce the network communication with this API?

Maybe it helps you to understand my system. Here are the launch files I am currently using:

######### Server PC multimaster.launch ###############

<launch>
    <node pkg="master_discovery_fkie" type="master_discovery" name="master_discovery_server" output="screen" >
      <param name = "mcast_group" value="224.0.0.1" />
     </node>
     <node pkg="master_sync_fkie" type="master_sync" name="master_sync_node_server" output="log">
        <rosparam param="ignore_nodes">[<!-- Internal robot nodes -->
                                          /*move_base*,
                                          /*IMU*,
                                          /*bob_laser*,
                                          /*diagnostic*,
                                          /*joy*,
                                          /*laser*,
                                          /*map*,
                                          /*mobile_base*,
                                          /*rplidar*,
                                          /*twist_mux*]</rosparam>
     </node>
</launch>

########## robot multimaster.launch (e.g. robot2) ###############

<launch>
  <node pkg="master_discovery_fkie" type="master_discovery" name="master_discovery_robot2" output="screen" >
      <param name = "mcast_group" value = "224.0.0.1" />
  </node>

  <node pkg="master_sync_fkie" type="master_sync" name="master_sync_node_robot2" output="log">
      <rosparam param="ignore_nodes">[/stdr_server, /robot*, /rviz]</rosparam>
  </node>
</launch>

Thanks again for your help and sorry for my continuing questioning!

regards

atiderko commented 6 years ago
> Does this mean, when I only use e. g. "sync_topic"[/info] all other topics are not synchronized by the master?

Yes

> So having a global topic, which is subscribed by each robot, this topic is responsible for the connection between all robots, meaning all robots share there tcp data with each other even with usage of "ignore_X" parameters? So in this case, all of my master_sync parameters are useless?

Yes, if you have at least one system, which does not ignore this topic.

> Can you provide a code example how to use this tf remapping?

It is default topic remapping functionality. This renames all /tf topics of all node in this lauchfile:

<launch>
  <remap from="/tf" to="/tf_robot0"/>
  <node ...> </node>
  <node ...> </node>
</launch>
> So, when you mean, they don't care about data traffic on topics, you say, it is not possible to reduce the network communication with this API?

It depends on scenario. If you subscribe on your server only /tf and /info of all robots it does not matter, if you ignore all other topics with master_sync since they are not used anyway. Thus you can not reduce the traffic with this API. In this case you need some kind of relay tools which decide for each message to forward it or not. In case of /tf it especially difficult if you need tf from all robots at the same time in one place. In this case also topic remapping will not help.

If you want to reduce the traffic try to avoid synchronization of /tf. Use it only for debug/monitoring.

scholzt commented 6 years ago

Ok, so I tested all your suggestions and everything is settled now.

/tfwas the real problem of my network, just as you said. I remapped the tf-topics of all robots and ignored defined nodes. With this improvements my network is finally stable enough to handle the entire system!

Thanks a lot for your help! It was a great support for me!

Just one last question: Do you know, if its possible to display Tfs on a different topic as /tf in RViz? E.g. Displaying all Tfs of Robot1 on topic /tf_robot1. I couldn't find any property to change the name of the topic.

atiderko commented 6 years ago

sorry for long delay!

Nice to hear about your success :-)

you can remap the topic in launch file or while start rviz: rosrun rviz rviz /tf:=/tf_robot1

atiderko commented 4 years ago

Hi @ChunJyeBehBeh

in first case the filter is applied only for topic of PC_2. In second case for all detected host. But you have to format it in multiple lines:

      <rosparam param="sync_topics">
        - tiderko_11322:
          - /chatter_1
      </rosparam>

This results in following output in master_sync:

[INFO] [1566540917.605071]: ignore_hosts: []
[INFO] [1566540917.609457]: sync_hosts: []
[INFO] [1566540917.613733]: sync_topics_on_demand: False
[INFO] [1566540917.617890]: resync_on_reconnect: True
[INFO] [1566540917.622051]: resync_on_reconnect_timeout: 0
[INFO] [1566540917.637195]: listen for updates on /master_discovery/changes
[INFO] [1566540917.665873]: ROS masters obtained from '/master_discovery/list_masters': ['tiderko_11322', 'tiderko']
[INFO] [1566540917.670563]: [tiderko_11322] ignore_nodes: ['/node_manager', '/param_sync', '/master_sync', '/rosout', '/node_manager_daemon', '/zeroconf', '/master_discovery']
[INFO] [1566540917.673706]: [tiderko_11322] sync_nodes: []
[INFO] [1566540917.676258]: [tiderko_11322] ignore_topics: ['/rosout', '/rosout_agg']
[INFO] [1566540917.678496]: [tiderko_11322] sync_topics: ['/chatter_1']
[INFO] [1566540917.680839]: [tiderko_11322] ignore_services: ['/*get_loggers', '/*set_logger_level']
[INFO] [1566540917.682845]: [tiderko_11322] sync_services: []
[INFO] [1566540917.684631]: [tiderko_11322] ignore_type: ['bond/Status']
[INFO] [1566540917.686532]: [tiderko_11322] ignore_publishers: []
[INFO] [1566540917.688386]: [tiderko_11322] ignore_subscribers: []
.
.
[INFO] [1566540962.973799]: [tiderko_11323] ignore_nodes: ['/node_manager', '/param_sync', '/master_sync', '/rosout', '/node_manager_daemon', '/zeroconf', '/master_discovery']
[INFO] [1566540962.982708]: [tiderko_11323] sync_nodes: []
[INFO] [1566540962.990797]: [tiderko_11323] ignore_topics: ['/rosout', '/rosout_agg']
[INFO] [1566540962.996384]: [tiderko_11323] sync_topics: []
[INFO] [1566540963.000062]: [tiderko_11323] ignore_services: ['/*get_loggers', '/*set_logger_level']
[INFO] [1566540963.003098]: [tiderko_11323] sync_services: []
[INFO] [1566540963.006094]: [tiderko_11323] ignore_type: ['bond/Status']
[INFO] [1566540963.008617]: [tiderko_11323] ignore_publishers: []
[INFO] [1566540963.010997]: [tiderko_11323] ignore_subscribers: []

The /chatter_1 topic is not applied for sync_topics for tiderko_11323. Since the sync_topics list is empty all topic are synchronized.