|Note: This tutorial assumes that you have completed the previous tutorials: Chatter Concert - Distributed.|
|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 - WirelessDescription: Wireless handling of distributed chatter concerts
Keywords: concert tutorials rocon
Tutorial Level: ADVANCED
Next Tutorial: Turtle Concert
The previous tutorial distributed a chatter concert across multiple machines. Realistically though, robots have to endure greater hardships than just being distributed. They also have to suffer isolation as well. This tutorial demonstrates how to handle a wireless connectivity between machines that can be up/down.
A concert PC, and an inno laptop (we will refer to this laptop by the name inno)
- The laptop at least must be wirelessly connected to the network.
The inno laptop is about to undergo forced upheavals on its wireless network interface. This means you can't run your ros master there. It has to be on loopback. At the same time, you need other systems to be able to know who the laptop is, so we will use hostnames if your machines already do not.
On the inno laptop, edit /etc/hosts so that it recognises itself as being on the loopback ip:
and also export the important multimaster variable:
On the concert pc you need to edit either /etc/hosts or add the appropriate info to your DNS server, e.g. in /etc/hosts
and setup your ROS_MASTER_URI to its own ip address, e.g.
See the Ros Networking guide if you need further understanding.
On the concert pc we launch the concert, one dudette and two dudes (just as in the previous tutorial).
> rocon_launch chatter_concert chatter.concert --screen --no-terminals local_machine_only:=false
Fire up two more shells to start some monitoring programs (you might like to add these to a copy of the chatter.concert file to automatically launch with the concert:
# First monitoring shell > remote_gateway_info --loop --loop-period=0.6
# Second monitoring shell > concert_conductor_graph
Inno Laptop Dude
On the inno laptop we launch another dude:
> roslaunch chatter_concert dude.launch --screen local_machine_only:=false
On the inno laptop click on the network manager and disable the wireless, you should see a succession of things happen:
The inno laptop dude complains that its interface seems down and so won't write connection statistics on the hub.
- A little while later, the concert hub reports that the remote dude has been uncontactable for a while
The remote_gateway_info monitor reports that the gateway is no longer alive.
The concert_conductor_graph reports that the client has moved to the 'missing' state.
Re-enabling the wireless network will see those events reversed.