Today, we describe how to use ROS Fuerte over the network and have a couple of ROS nodes running on different machines. We assume that you had successfully installed ROS and that you tested it on a single PC by running some tutorials. We also assume that you are running ROS on a PC with Ubuntu which is the reference platform for ROS. Ready? Then, let’s go!
Mapping IP Addresses to Hostnames
We work with two laptops named r2d2 and c3po. Both are under Ubuntu 12.04LTS and are connected to the same LAN. We use a wifi network, which is more convenient for controlling mobile robots.
In our network only servers have fixed IP addresses registered in the DNS. Our two PCs r2d2 and c3po are connected via DHCP. This means that their IP addresses are dynamic, they might change each time we connect Wifi. Fortunately, the IP address assigned to each machine in a given network tend to be stable overtime, especially in small networks. It seldom changes, so we can assume it as fixed.
To know the IP addresses of our machines, we look them up in the connection information menu under the wifi icon of the task bar (see Picture 1). Note that if your PC is connected to ethernet, the network icon will be different (double arrow). An alternative option is to execute ifconfig in a terminal.
The connection information menu opens a window (see Picture 2). The tab title is the SSID (i.e. the name) of the wifi network. Note that in case your PC is connected to ethernet, you’ll have two tabs, one for ethernet, and the other for wifi.
Symetrically, we add the IP of r2d2 in the hosts file of c3po.
Note that you need administrator rights to write access the hosts file and be allowed saving it. So, open the editor by evaluating the following command line.
sudo gedit /etc/hosts
It is important to remember that we are using IPs allocated by the DHCP. Although most the time such an IP is reused by the same machine, it can be assigned to another computer. So, if you have trouble in a future session, think to this issue and check the IP assigned to your PC.
Time to check our connections. First a ping to ensure that both computers are on the same network. Evaluate the following command in a terminal.
viki@r2d2:~$ ping c3po
We put the prompt (viki@r2d2:~$) on the command line to show that we are running the command on r2d2. As a result, we get a series of lines saying that we received some bytes from the c3po and that the transmission took some amount of milliseconds as shown by Picture 3. The ping continues running endlessly until we press Ctl-c.
Installing SSH (Optional)
Having SSH is not mandatory, but it makes life easier since it allows to work remotely. This is useful when the PCs are not next to each other. By default, Ubuntu comes without SSH. So, we have to install it ourselves by for example evaluating the following command in a terminal:
sudo apt-get install openssh-server
We do this install on both laptops. We use an account with administrator rights. After providing the password, SSH is downloaded and installed.
Now, let see if we can access one machine from the other through SSH. We assume that there exist an account for a user named viki on c3po. On r2d2, we evaluate the following command line where the user name viki is followed by an @ and the name of the remote machine which is c3po.
viki@r2d2:~$ ssh viki@c3po
After providing the password for viki, we land on c3po. The prompt is now viki@c3po:~$ . So, we can work remotely on c3po. For now, we just quit by pressing Ctl-d or by typing exit.
ROS Environment Variables
ROS needs to know the name of each machine it is running on. This done by setting the ROS_HOSTNAME environment variable of each machine with its own name. Besides, we should provide ROS with URI of the master node, that is launched by the roscore command. Since in a ROS graph, there should be only a single master node, its URI should replicated on all machines by setting the ROS_MASTER_URI environment variable.
In our setting, we chose to run ROS master node on c3po. So, in r2d2 we modify the .bashrc file to set the environment variables as following:
On c3po, we modify the .bashrc file to set the environment variables as following:
It’s almost the same, except for the hostname. This is why we put it in bold, just to highlight the difference.
Time for Test
First and foremost, we have to start the master node. So, on c3po, we execute roscore as following:
For this test we’ll play a bit with the turtle simulation provided with ROS. We run the turtle engine and display on one machine, say r2d2. The control is performed remotely on c3po to demonstrate the interaction between remote nodes.
We run the simulation on r2d2 as following:
viki@r2d2:~$ rosrun turtlesim turtlesim_node
As a result we get a blue window with a turtle standing still in the middle such as the one of Picture 4. The colors and the drawings of the turtle may be different on your machine. They actually change on every launch.
Now we run the turtle controller on c3po. We chose one that makes the turtle indefinitely draw a square. It is run by evaluating in a terminal the following command line:
viki@c3po:~$ rosrun turtlesim draw_square
The log of the interaction with the simulated turtle is displayed in the terminal as shown on Picture 5.
On the simulation window, we see the turtle moving. The path it follows is drawn as white lines. After few iterations, the display looks like the one provided by Picture 6.
It works. Congratulations! As a final remark we would like to point that the order of execution of nodes is arbitrary. We could start the controller first, and then the simulator. The result would have been the same.