UP | HOME

Remote Nodes

Overview

Nodes in ROS communicate (via topics and services) over a network. Thus ROS nodes need not run on the same computer.

When using ROS to control a mobile robot, there are often at least two comptuers involved: the robot's onboard computer, and the development computer.

The robot's computer typically runs the autonomous systems and the development computer typically runs visualization and diagnostics.

The Network

  • Computers running ROS nodes must be able to communicate with each other over a network
  • Typically, all computers are on a single local area network (LAN)
  • Each computer has a unique IP address, a 4 byte number identifying that computer (e.g., 192.168.0.1).
  • Each computer also has a hostname which is a human-readable name that corresponds to that computer's ip address
    • name lookup, converts a name to an ip address which is then used to connect to the remote computer
  • The rosmaster process runs on one computer in the network and coordinates ROS nodes
    • Nodes contact the rosmaster to register their publishers and subscribers
    • Nodes are then directly connected to each other as needed.

Environment variables

  • The ROS_MASTER_URI environment variable tells a node where to find the rosmaster
    • All nodes in the network, when launched, should have the same ROS_MASTER_URI in order to communicate on the same ROS network
    • We will run rosmaster on our development computers
      • Our development computer is always on, so we don't need to change the ROS_MASTER_URI when we, for example, turn of the robot (like the turtlebot)
      • If we wanted the turtlebot to be completely independent of the development computer, we would run rosmaster on the turtlebot
  • The ROS_HOSTNAME environment variable contains the address of the node.
    • When node A connects to rosmaster it provides rosmaster with the value of ROS_HOSTNAME. rosmaster uses this address to tell other nodes how to contact node A.
    • If no ROS_HOSTNAME is provided, the hostname of the computer on which the node is running will be used.
  • The ROS_IP variable is like ROS_HOSTNAME but contains the ip address of the node. Do not set this if using ROS_HOSTNAME.

Networking setup

  • ROS networking is easiest if each computer in the network can connect to the other computers via hostname resolution.
    • This means that every computer in the network can ping every other computer by hostname
  • The easiest way to get hostname resolution working on your network is to use a router that sets up name resolution for you automatically
    • Every computer just connects to the router. You then set ROS_MASTER_URI to the hostname of the comptuer running rosmaster
    • In my experience, openWRT, a Linux distribution for routers sets up hostname resolution automatically
    • When buying routers for use with robotics, I make sure to buy one that OpenWRT supports. Most consumer-level routers that I know of do not support hostname resolution
    • I use this setup on the TURTLENET network in the lab
    • You can also assign static ip addresses to each computer, and do everything by ip address or by hostnames written to /etc/hosts
  • The second easiest way is to use mdns or multi-cast DNS
    • This feature is setup automatically on ubuntu. It can be used via the avahi-daemon or it is also built-in to NetworkManager/systemd-resolvd.
    • mDNS (by default) automatically lets computers find each other via the address hostname.local.
    • To use this with ROS you must set each computer's ROS_HOSTNAME to <hostname>.local where <hostname> is the hostname of that computer
    • I use this setup with the turtlebot that I give you. This works well when mdns is working.
  • It is also necessary for the remote machine to have ssh enabled, and you must be able to login to the remote machine using an ssh key.

Remote Nodes

  1. To run a remote node, that node and all its runtime dependencies must be on the computer it runs on
  2. Therefore, you need to copy your nodes to the remote machine before you can run them
  3. It is easiest to do a catkin_make install to create the install directory
    • install directories in ROS are self-contained
    • You then copy the contents of install to the remote comptuer using rsync

Launchfiles

  1. Launchfiles can be used to run nodes on remote machine=
  2. The <node> tag in a launchfile has a machine attribute that lets you specify a <machine> on which to run the node
  3. The <machine> tag in a launchfile lets you specify the address of a remote machine
    • One important attribute is the env-loader script. This is a script on the remote machine that sets up the ros environment
    • loader.sh is what we use on the turtlebot
      • It essentially sources some workspaces and sets up ROS_MASTER_URI and ROS_HOSTNAME

Time Synchronization

  • Many ROS packages rely on timestamps indexed to the actual wall-clock time
  • Thus, computers on the network must have their clocks synchronized
  • If all computers are connected to the internet they will synchronize with ntp servers and you will not have problems
  • If however, a computer does not have internet access, for reliability you will have to run an ntp server on your local network to synchronize everything
  • For the turtlebot I have you install an ntp server on your computer. You then configure the turtlebot to connect to this ntp server, thus synchronizing the times.

Author: Matthew Elwin