| Note: This tutorial assumes that you have completed the previous tutorials: Chatter Concert. |
 Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags. |
Chatter Concert - Distributed
Description: Distributing chatter concert on multiple machinesKeywords: concert tutorials rocon
Tutorial Level: INTERMEDIATE
Next Tutorial: Chatter Concert - Wireless
Overview
The previous tutorial demonstrated a concert with multiple masters running on a single machine. This tutorial takes it a step further and connects an additional dude from a master running on a remote machine.
The Concert
Preparation
You need two machines. Ensure that both machines have ROS_MASTER_URI and ROS_HOSTNAME configured to their own IP addresses. This is standard Ros Networking and has nothing to do with multiple masters. e.g.
# First machine has IP 192.168.1.2 export ROS_MASTER_URI=http://192.168.1.2:11311 export ROS_HOSTNAME=192.168.1.2 # Second machine has IP 192.168.1.3 export ROS_MASTER_URI=http://192.168.1.3:11311 export ROS_HOSTNAME=192.168.1.3
Launching
On the first machine We will run the concert, one dudette and two dudes (just as we did in the previous tutorial).
> rocon_launch chatter_concert chatter.concert --screen local_machine_only:=false
The local_machine_only:=false is the only difference here. The default tutorial setup configures both concert and concert clients to handle invitations across local (on the same pc) connections only. This just happens to be useful for testing and development when several people are runnning the same tutorial on the LAN to stop from stealing each other's clients.
On installed systems, you'd usually configure your concert with a unique name and use whitelists/blacklists.
Remote Dudes
On the second machine we launch another dude (chatter concert is configured to launch up to four dudes in total):
> roslaunch chatter_concert dude.launch --screen local_machine_only:=false
If all worked brilliantly, congratulations - you've just run your first distributed multimaster concert!
How Does it Work?
The multimaster side of it runs on the gateway model.
Startup
On startup the concert starts a gateway hub (a redis server) and uses zeroconf to broadcast its location. Clients can configure their gateways to find this hub using either 1) a pre-configured IP or 2) autodiscovery via a zeroconf implementation (in our case - avahi). For our clients in the chatter concert, zeroconf is used. Both concert and clients drop useful bits of information which makes concert and clients become aware of each other.
Joining
At this point, the concert will send out invitations to useful clients (chatter concert just grabs anybody) via gateway multimaster connections and if the invitation is accepted (whitelists/blacklists can be used), the clients (dudes and dudettes) become an idle, but usable resource in the concert framework.
Chattering
At the same time, the concert chatter service has put in a request for 1 dudette and 2-4 dudes. Once the minimum configuration is available (1 dudette, 2 dudes), the appropriate rapps are started on the clients (1 talker, 2 listeners) and the chatter gets underway.
Troubleshooting
There are two problems that usually come up when multi-mastering:
ROS Environment Variables
Make absolutely sure that you have ROS_MASTER_URI and ROS_IP/ROS_HOSTNAME set and configured correctly. If this is not true, then certain connections will just fail to deliver (e.g. one side of a talker-listener).
Zeroconf
If you have a misbehaving ISP, you may need to change a variable in avahi's default configuration. See the Avahi Troubleshooting section for more details.
