multi-robot systems with ros lesson 1

Multi-Robot Systems with ROS Lesson 1

Teaching Assistant: Roi [email protected]

Summer 2015

mailto:[email protected]

(C)2014 Roi Yehoshua 2

Course Agenda• Working with multi robots in ROS• Handling communication and synchronization

between robots• Canonical multi-robot problems in ROS– Patrolling, Formation, Coverage, etc.

• Decision making system– We will be using CogniTAO, a decision making system

developed by Cogniteam

http://www.cogniteam.com/


Course Requirements• Course grade will be composed of:– 40% Assignments– 40% Project– 20% Exam


Who am I?• My name is Roi Yehoshua• PhD Student at Bar-Ilan Robotics lab headed by

Prof. Gal Kaminka• Teaching assistant at the courses:– Introduction to Robotics (89-685)– Multi-Robot Systems (89-689)

• My home page: http://u.cs.biu.ac.il/~yehoshr1/

http://u.cs.biu.ac.il/~yehoshr1/89-685/

http://u.cs.biu.ac.il/~yehoshr1/89-689/

http://u.cs.biu.ac.il/~yehoshr1/


Today’s Agenda• Intro to Multi-Robots Systems in ROS• Multi Turtlesim Demo


Intro to Multi Robot Systems in ROSThree 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


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


Two Turtle Simulators


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


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


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


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


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.


ROS Namespaces• Examples for resource names:– / (the global namespace)– /turtle1– /bar_ilan/robot/name– /wg/node1


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.


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


Name Resolving• There are four types of Graph Resource Names in

ROS: base, relative, global, and private, which have the following syntax:baserelative/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.


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.


Name Resolution Examples

Private Global Relative (default) Node

~bar -> /node1/bar /bar -> /bar bar -> /bar /node1bar -> /wg/node2/bar /bar -> /bar bar -> /wg/bar /wg/node2~foo/bar ->/wg/node3/foo/bar

/foo/bar -> /foo/bar

foo/bar -> /wg/foo/bar /wg/node3


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.


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


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"> <node name="turtle" pkg="turtlesim" type="turtlesim_node"/> <node name="controller" pkg="turtlesim" type="draw_square"/> </group></launch>


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.


Two Turtle Simulators With Two Drivers


Two Turtle Simulators With Two Drivers• rqt_graph shows the active nodes and topics:


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.


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


Remapping Arguments


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


Remapping Arguments


The <remap> Tag • Remapping arguments can also be done in the

launch file using the <remap> tag• Attributes:

from="original-name“to="new-name“


Remapping Arguments In Launch File

<launch> <group ns="sim1"> <node name="turtle" pkg="turtlesim" type="turtlesim_node"/> </group> <group ns="sim2"> <node name="turtle" pkg="turtlesim" type="turtlesim_node"/> </group> <node pkg="turtlesim" name="teleop" type="turtle_teleop_key" output="screen"> <remap from="/turtle1/cmd_vel" to="/sim1/turtle1/cmd_vel"/> </node></launch>


Multi Robot Systems in ROSThree 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


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.


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.


Network Setup• Find your IP address by typing the command

ifconfig and looking at inet addr


Network Setup• Assume that we want to run a ROS system on

two machines, with the following IP addresses:– 192.168.118.151 (machine A)– 192.168.118.154 (machine B)


Basic Check• Ping between machines– Ping machine A from machine B and vice versa


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 http://localhost:11311


ROS_MASTER_URI• Change ROS_MASTER_URI in machine B to point

to machine A IP address$ export ROS_MASTER_URI=http://192.168.118.151:11311


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


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


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.


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 127.0.0.1 | fgrep 'Mask:255.255.255.0' | egrep -o 'addr:[^ ]*' | sed 's/^.*://'; }export ROS_IP=$( get_ip_address )


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 127.0.0.1 | fgrep 'Mask:255.255.255.0' | egrep -o 'addr:[^ ]*' | sed 's/^.*://'; }export ROS_IP=$( get_ip_address )export ROS_MASTER_URI=http://192.168.118.151:11311


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=http://localhost:11311 (the default)

• The one that connects to the master should have ROS_MASTER_URI=http://[IP_OF_MASTER_MACHINE]:11311


Testing Network SetupTo 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


Testing Network Setup – Machine A


Testing Network Setup – Machine B


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)

multi-robot systems with ros lesson 1

Documents

14c2014 roi yehoshua

11c2014 roi yehoshua

7c2014 roi yehoshua

9c2014 roi yehoshua

turtle simulator node

rosrun turtlesim turtlesim

turtle simulatorsin

turtle simulatorsto