1. Multi-Robot Systems with ROS Lesson 2
Teaching Assistant: Roi Yehoshua

2. Agenda ROS Namespaces Launch files and remapping arguments
Multi Turtlesim Demo
Network Setup
(C)2014 Roi Yehoshua

3. Multi Robot Systems in ROS
Three options to run a multi-robot system in ROS:
Running multiple instances of the same node on the same computer
Running multiple nodes on different computers using one common roscore
Establishing a multi-master network
(C)2014 Roi Yehoshua

4. Two Turtle Simulators
Now we will try to run two turtlesim nodes at the same time
First start the ROS infrastructure by running in a terminal the command:
Then start the first turtle simulator node by running in a new terminal:
$ roscore
$ rosrun turtlesim turtlesim_node
(C)2014 Roi Yehoshua

5. Two Turtle Simulators
(C)2014 Roi Yehoshua

6. Two Turtle Simulators
Now try to run yet another turtlesim_node in a new terminal:
This naive approach does not work. Instead, the first turtle simulation terminates with a warning log and the new simulation node replaces the first one.
Node names must be unique across the ROS system. If a second node is started with the same name as the first, the first will be shutdown automatically.
$ rosrun turtlesim turtlesim_node
(C)2014 Roi Yehoshua

7. Two Turtle Simulators
(C)2014 Roi Yehoshua

8. Two Turtle Simulators
To avoid name conflicts, you need to provide a different node name for the second turtle simulator.
The rosrun command does allow to assign a different name to the node
You can provide a value to the __name parameter as the replacement for the default node name:
$ rosrun turtlesim turtlesim_node __name:=turtlesim2
(C)2014 Roi Yehoshua

9. Two Turtle Simulators
(C)2014 Roi Yehoshua

10. Two Turtle Simulators
In this case the two nodes publish and subscribe to the same topics
You can verify this by running the command rostopic list
(C)2014 Roi Yehoshua

11. Two Turtle Simulators
This means you can use the same driver to control both turtle simulations
In another terminal type:
Use the keys to move both turtles together
$ rosrun turtlesim turtle_teleop_key
(C)2014 Roi Yehoshua

12. Two Turtle Simulators
(C)2014 Roi Yehoshua

13. ROS Namespaces
A namespace can be viewed as a directory whose contents are items of different names.
These items can be nodes, topics, services or even other namespaces.
Each resource in ROS is defined within a namespace, which it may share with other resources.
This encapsulation isolates different portions of the system from accidentally grabbing the wrong named resource or globally hijacking names.
(C)2014 Roi Yehoshua

14. ROS Namespaces Examples for resource names: / (the global namespace)
/turtle1
/bar_ilan/robot/name
/wg/node1
(C)2014 Roi Yehoshua

15. ROS Namespaces
Usually topics related to a specific robot will be mapped into a namespace.
For example, robot1 would receive commands on the topic /robot1/cmd_vel, robot2 on the topic /robot2/cmd_vel, etc.
They both could exchange messages via some topic, such as /shared_topic.
(C)2014 Roi Yehoshua

16. Changing Node Namespace
All nodes launch in the global namespace
You can change the namespace of a node by:
Setting the ROS_NAMESPACE environment variable
Using a launch file
Changing the namespace of a node effectively remaps all of the names in that node.
Node name, topics, services and parameters will be rescoped into a child namespace
This in effect "pushes it down" into a child namespace
(C)2014 Roi Yehoshua

17. Name Resolving
There are four types of Graph Resource Names in ROS: base, relative, global, and private, which have the following syntax:
base
relative/name
/global/name
~private/name
By default, resolution is done relative to the node's namespace.
For example, the node /wg/node1 has the namespace /wg, so the name node2 will resolve to /wg/node2.
(C)2014 Roi Yehoshua

18. Name Resolving
Names that start with a "/" are global - they are considered fully resolved.
Global names should be avoided as much as possible as they limit code portability.
Names that start with a "~" are private. They convert the node's name into a namespace.
For example, node1 in namespace /wg/ has the private namespace /wg/node1.
Private names are useful for passing parameters to a specific node via the parameter server.
(C)2014 Roi Yehoshua

19. Name Resolution Examples
Private
Global
Relative (default)
Node
~bar -> /node1/bar
/bar -> /bar
bar -> /bar
/node1
bar -> /wg/node2/bar
bar -> /wg/bar
/wg/node2
~foo/bar ->
/wg/node3/foo/bar
/foo/bar -> /foo/bar
foo/bar -> /wg/foo/bar
/wg/node3
(C)2014 Roi Yehoshua

20. Two Turtle Simulators With Two Drivers
We illustrate the concept of namespace with two turtle simulators driven by two instances of the draw_square driver.
We will use a launch file that will run two instances of turtle_sim in two different namespaces
This will ensure that the nodes have different names and also that within each simulation, nodes use different topic names.
(C)2014 Roi Yehoshua

21. Launch Files
Launch files (.launch) are XML configuration files that specify the parameters to set and nodes to launch, as well as the machines that they should be run on.
roslaunch is the command-line tool to run the launch file
If you use roslaunch, you do not have to run roscore manually
(C)2014 Roi Yehoshua

22. Launch File Create the file multi_turtlesim.launch <launch>
<group ns="sim1">
<node name="turtle" pkg="turtlesim" type="turtlesim_node"/>
<node name="controller" pkg="turtlesim" type="draw_square"/>
</group>
<group ns="sim2">
</launch>
(C)2014 Roi Yehoshua

23. The <group> Tag
The <group> tag in a launch file is equivalent to the top-level <launch> tag and simply acts as a container for the tags within.
This means that you can use any tag as you would normally use it within a <launch> tag.
It has an ns attribute that lets you push the group of nodes into a separate namespace.
The namespace can be global or relative, though global namespaces are discouraged.
(C)2014 Roi Yehoshua

24. Two Turtle Simulators With Two Drivers
(C)2014 Roi Yehoshua

25. Two Turtle Simulators With Two Drivers
rqt_graph shows the active nodes and topics:
(C)2014 Roi Yehoshua

26. Specifying Namespace in Code
NodeHandles let you specify a namespace in their constructor:
This makes any relative name used with that NodeHandle relative to <node_namespace>/my_namespace instead of just <node_namespace>.
To get the namespace associated with this NodeHandle use the function:
ros::NodeHandle nh("my_namespace");
nh.getNamespace()
(C)2014 Roi Yehoshua

27. Remapping Arguments
Any ROS name within a node can be remapped when it is launched at the command-line.
This is a powerful feature of ROS that lets you launch the same node under multiple configurations from the command-line.
The names that can be remapped include the node name, topic names, and Parameter names.
Remapping arguments can be passed to any node and use the syntax name:=new_name.
(C)2014 Roi Yehoshua

28. Remapping Arguments
For example, to configure turtle_teleop_key node to publish command velocities to the first turtle simulator, we first have to find out the name of the topic it publishes to
This can be done by running rosnode info
(C)2014 Roi Yehoshua

29. Remapping Arguments
(C)2014 Roi Yehoshua

30. Remapping Arguments
Now remap the name of the topic /turtle1/cmd_vel to /sim1/turtle1/cmd_vel
$ rosrun turtlesim turtle_teleop_key /turtle1/cmd_vel:=/sim1/turtle1/cmd_vel
(C)2014 Roi Yehoshua

31. Remapping Arguments
(C)2014 Roi Yehoshua

32. The <remap> Tag
Remapping arguments can also be done in the launch file using the <remap> tag
Attributes:
from="original-name“
to="new-name“
(C)2014 Roi Yehoshua

33. Remapping Arguments In Launch File
<group ns="sim1">
<node name="turtle" pkg="turtlesim" type="turtlesim_node"/>
</group>
<group ns="sim2">
<node pkg="turtlesim" name="teleop" type="turtle_teleop_key" output="screen">
<remap from="/turtle1/cmd_vel" to="/sim1/turtle1/cmd_vel"/>
</node>
</launch>
(C)2014 Roi Yehoshua

34. Multi Robot Systems in ROS
Three options to run a multi-robot system in ROS:
Running multiple instances of the same node on the same computer
Running multiple nodes on different computers using one common roscore
Establishing a multi-master network
(C)2014 Roi Yehoshua

35. Network Setup
A running ROS system can comprise dozens of nodes, spread across multiple machines.
Depending on how the system is configured, any node may need to communicate with any other node, at any time.
(C)2014 Roi Yehoshua

36. Network Setup
When running only one master, ROS has certain requirements of the network configuration:
There must be complete, bi-directional connectivity between all pairs of machines, on all ports.
Each machine must advertise itself by a name that all other machines can resolve.
(C)2014 Roi Yehoshua

37. Network Setup
Find your IP address by typing the command ifconfig and looking at inet addr
(C)2014 Roi Yehoshua

38. Network Setup
Assume that we want to run a ROS system on two machines, with the following IP addresses:
(machine A)
(machine B)
(C)2014 Roi Yehoshua

39. Basic Check Ping between machines
Ping machine A from machine B and vice versa
(C)2014 Roi Yehoshua

40. ROS_MASTER_URI
ROS_MASTER_URI is a required setting that tells nodes where they can locate the master.
It should be set to the XML-RPC URI of the master.
The default value is
(C)2014 Roi Yehoshua

41. ROS_MASTER_URI
Change ROS_MASTER_URI in machine B to point to machine A IP address
$ export ROS_MASTER_URI=
(C)2014 Roi Yehoshua

42. ROS_MASTER_URI Run the master and turtlesim on machine A
Now if you type rostopic list on machine B, you should see the topics advertised from the nodes in machine A
$ roscore
$ rosrun turtlesim turtlesim_node
(C)2014 Roi Yehoshua

43. ROS_MASTER_URI
However, seeing the topics only shows you one direction of communication.
Every computer needs to be able to talk to each other (from/to) using whatever name this is known by to ROS. 
The host name used by ROS is defined by ROS_IP and ROS_HOSTNAME environment variables
(C)2014 Roi Yehoshua

44. Setting ROS_IP
ROS_IP and ROS_HOSTNAME are optional environment variable that sets the declared network address of a ROS Node or tool.
When a ROS component reports a URI to the master or other components, this value will be used.
Use ROS_IP for specifying an IP address, and ROS_HOSTNAME for specifying a host name.
The options are mutually exclusive, if both are set ROS_HOSTNAME will take precedence.
(C)2014 Roi Yehoshua

45. Setting ROS_IP In machine A add to your .bashrc:
Open a new terminal and make sure that ROS_IP is set properly
function get_ip_address { ifconfig | fgrep -v | fgrep 'Mask: ' | egrep -o 'addr:[^ ]*' | sed 's/^.*://'; }
export ROS_IP=$( get_ip_address )
(C)2014 Roi Yehoshua

46. Setting ROS_IP You must set ROS_IP also on machine B
Add the following to your .bashrc on machine B
Note that ROS_MASTER_URI on machine B points to the ROS_IP of machine A
function get_ip_address { ifconfig | fgrep -v | fgrep 'Mask: ' | egrep -o 'addr:[^ ]*' | sed 's/^.*://'; }
export ROS_IP=$( get_ip_address )
export ROS_MASTER_URI=
(C)2014 Roi Yehoshua

47. Network Setup Summary
Both computers should have ROS_IP set to their own IP address.
The one on which the master runs should have ROS_MASTER_URI= (the default)
The one that connects to the master should have ROS_MASTER_URI=
(C)2014 Roi Yehoshua

48. Testing Network Setup To test your network setup:
Run roscore on machine A
Run turtlesim node on machine A
Now you will be able to publish messages to topics on machine A from machine B
(C)2014 Roi Yehoshua

49. Testing Network Setup – Machine A
(C)2014 Roi Yehoshua

50. Testing Network Setup – Machine B
(C)2014 Roi Yehoshua

51. Homework (not for submission)
Run three instances of turtlesim at the same time
Control the first turtle with the keyboard
Make the second and the third turtles follow the first one (use the mimic node)
(C)2014 Roi Yehoshua