Research Article

International Journal of Advanced

Robotic Systems
May-June 2017: 1–13
Establishing remote networks for ROS ª The Author(s) 2017
DOI: 10.1177/1729881417703355
applications via Port Forwarding: journals.sagepub.com/home/arx

A detailed tutorial

Sami Salama Hussen Hajjaj and Khairul Saleh Mohamed Sahari

Abstract
In a Robot Operating System (ROS) application, robot software is often distributed across multiple networked
components, forming the ROS network, where every component acts as server and/or a client, and publishing and/
or receiving robot data simultaneously. For indoor robots, a local ROS network, through a Wi-Fi hotspot, is
sufficient. But for outdoor robots, a remote ROS network is needed to connect the ROS application to the cloud.
Although a number of cloud-based solutions support this, implementing them is challenging, as they need to be
configured to facilitate ROS’s unique, multidirectional, and simultaneous flow of robot data. This article presents
Port Forwarding as an alternative approach, which offers a private, secured, and a direct ROS-to-ROS, eliminating
the need for a dedicated middleware and its configuration and setup complexities. But Port Forwarding has its own
challenges; chiefly, the beforehand knowledge of Internet addresses of all networked components and the need to
update port forwarding settings when these addresses change, which they often do. This article addresses this issue
(and others) and presents a detailed procedure for setting Port Forwarding for ROS applications, highlighting
configuration, and troubleshooting steps. Also, the article compares between Port Forwarding and cloud-based
solutions, in terms of setup, performance, and others. Results show that robot performance under Port Forwarding
is on par with cloud-based solutions, but it required a fraction of setup time. The authors developed a set of shell
scripts that monitor the Internet addresses of all networked components and auto-update Port Forwarding settings
when they change, solving this issue. With this, Port Forwarding could be considered a viable option for ROS
system networks, on par with cloud-based solutions.

Keywords
Robot operating system (ROS), robot software, cloud robotics, port forwarding, agriculture robots

Date received: 28 September 2016; accepted: 14 February 2017

Topic: Robotics Software Design and Engineering (ROSENG)

Topic Editor: Anis Koubaa

Introduction
The Robot Operting System (ROS) is one of the fastest
growing platforms for robot software development,1,2 and
one of its many features is software distribution. As often
in a ROS application, robot software is distributed over mul-
tiple networked components, forming the ROS network
shown in Figure 1. In this network, robot data are shared
among all connected components, with every component
publishing and/or subscribing to this robot data, and ROS’s
Centre for Advanced Mechatronics and Robotics, College of Engineering,
Universiti Tenaga Nasional Malaysia (UNITEN), Kajang, Selangor, Malaysia
Corresponding author:
Sami Salama Hussen Hajjaj, Centre for Advanced Mechatronics and
Robotics, College of Engineering, Universiti Tenaga Nasional Malaysia,
43000 Kajang, Selangor, Malaysia.
Email: ssalama@uniten.edu.my

Creative Commons CC BY: This article is distributed under the terms of the Creative Commons Attribution 4.0 License
(http://www.creativecommons.org/licenses/by/4.0/) which permits any use, reproduction and distribution of the work without
further permission provided the original work is attributed as specified on the SAGE and Open Access pages (https://us.sagepub.com/en-us/nam/
open-access-at-sage).
2 International Journal of Advanced Robotic Systems
Figure 1. The ROS network. ROS: robot operating system.
architecture manages the flow of data, ensuring proper robot
operations.
For indoor robots, a local ROS network is sufficient,
where all components are networked via a local Wi-Fi
router. For outdoor robots, however, the situation becomes
more challenging.3 This is where a remote ROS network is
needed, where components are networked remotely
through the cloud. But due to standard Internet protocols
(IPs), the remote ROS network, as shown in Figure 4
below, would not work without further setup. One approach
is to create a bridge, or a middle point in the cloud, where
robot data are hosted and is accessible to all connected
components, allowing them to indirectly interact with each
other. A number of cloud-based solutions facilitate this,
such as webservers, android, and a number of cloud-
robotics platforms, such as RoboEarth.4–9
However, utilizing these solutions for ROS applications
is challenging; by default, webservers host data and publish
it only when requested by clients, such as web applications
or android Apps. But in a ROS network, every component
acts as client and/or a server, publishing and/or receiving
robot data. Therefore, cloud-based webservers need to be
configured to act as simultaneous clients and/or servers to
facilitate the multidirectional and simultaneous flow of
robot data needed in a ROS network.10,11 Other factors
need to be managed as well to ensure proper robot opera-
tions, such as security, privacy, concurrency, and time
delays.
This article presents an alternative solution, portfor-
warding (PF), which offers a secure, private, and a direct
ROS-to-ROS remote connection, without the need for a
middle ware, eliminating the need to configure a third party
technology for ROS. Furthermore, PF is also scalable, as it
allows application updates without further setup, some-
thing cloud-based solutions cannot achieve, as will be
shown below. However, PF has its own challenges and
limitations.
This article begins by reviewing cloud-based solutions,
highlighting pros and cons. Then, the article presents a
detailed procedure for implementing PF for ROS, high-
lighting configuration, and troubleshooting steps. Finally,
the article compares between the two solutions, in terms of
setup, performance, and challenges of each method.
Figure 2. Rosbridge and RobotWebTools in action.4
Literature review
ROS provides the needed tools to link its applications to the
cloud, such as the rosbridge package, which allows non-
ROS clients, such as web applications, to publish and/or
subscribe any ROS topic, by transporting JSON formatted
messages over the Internet.4 Being language and platform
independent, any non-ROS client, from any platform that
understands JSON, could interact with a ROS-based robot.
This was demonstrated in the RobotWeb Hackathon in 2013,
when researchers remotely teleoperated a ROS-enabled
robot, despite being hundreds of miles away (Figure 2).4
But as the figure shows, rosbridge is just a small compo-
nent of the software developed to make this happen. After
all, rosbridge only links ROS and non-ROS clients, but these
non-ROS clients still need to be developed. They need to
perform ROS operations (e.g. robot operations, sensor man-
agement, visualization, etc.) in a non-ROS environment. In
the example above, the web application interacting with
ROS, which utilizes the ROS.js library, the implementation
of ROS in JavaScript, is still needed to be written by the
developers. Furthermore, the teleop example shown above is
a very simple ROS application that requires very few mes-
sage types to be transmitted, such as Geometry_msgs/Twist,
which defines robot speed. Therefore, the ROS.js code
needed to achieve this is relatively simple. But in a typical
ROS application, there are tens to hundreds of message types
being transmitted simultaneously in all directions, describing
various aspects of robot operations, such as robot speed,
location, sensor data, odometry, and so on, and each of these
message types must be transmitted individually or their
meanings would be lost. In other words, each of these mes-
sage types requires its own bridge to be remotely trans-
mitted, see Figure 5, which only adds to the complexity.
Another cloud-based solution is android, by linking
ROS-enabled robots to android and Google’s cloud ser-
vices. This is achieved using rosjava and android_core
packages, which provide the implementation of ROS in
Java and android, respectively. Together, they allow devel-
opers create android Apps that can interact with ROS-
enabled robots.5,6,12,13 However, the challenges in using
android are similar to those of rosbridge, rosjava, and
android_core, which only provide the building blocks to
develop ROS-android apps, but developers still need to
develop them. They need to write the rosjava code to
Hajjaj and Sahari
Figure 3. Components of RoboEarth.7
facilitate the multidirectional and simultaneous flow of
robot data of the ROS network for every ROS message in
the robot application. This requires extensive knowledge of
advanced concepts of android App development, such as
background process and concurrency. Furthermore, Cþþ
(language of ROS) and Java are fundamentally different in
software architecture, so developers need to manage these
differences when linking ROS to android.
Researchers recognized these challenges and introduced
a number of cloud-robotics platforms to streamline the
process of linking ROS applications to the cloud. These
include RoboEarth, RobotWebTools, and others.7–9 In fact,
Figure 2 shows the architecture of RobotWebTools, while
Figure 3 shows the components of RoboEarth.
However, these platforms have limits. The best way to
describe these limits is by an analogy; consider rosbridge
and cloud-robotics platforms as manual and automatic
transmission in car; and the automatic transmission pro-
vides a bit of convenience, but the driver still needs to drive
the car. The same thing applies in cloud-robotics platforms;
while they do provide the scaffolding that links between the
various technologies discussed above, developers still need
to learn how to use these tools and then develop the neces-
sary applications that use these tools. For example, the
RoboEarth platform is built of several components such
as Rapyuta, KnowRob, WIRE, and so on. So, when using
this platform, one must learn each of these individual com-
ponents as well as their base technologies, which happen to
be rosbridge, webservers, database design, web application,
and so on. Also, these platforms can never fully predict the
individual needs of every robot application (e.g. message
type to be transmitted, etc.), and so developers could end up
coding and setting many of these components after all.
Finally, utilizing these open source platforms brings con-
cerns over data security and privacy, as robot data would be
exposed to anyone with access, which could be undesirable
for proprietary and private applications.
Port Forwarding for ROS applications
As discussed above, the remote ROS network would not
work without further setup. That is because each modem/
3
Figure 4. The remote ROS network. ROS: robot operating
system.
router acts as a gatekeeper that blocks any incoming remote
requests from accessing local components. This is a secu-
rity protocol designed to protect the local components from
remote attacks or unwanted intrusion. Because of this, the
robot and laptop in Figure 4 can only recognize the routers
of each other but not each other. So, if the laptop attempts
to contact the robot, it would not be able to do so, because
the robot’s router blocks that connection and vice versa. In
cloud-based solutions, this problem was solved by creating
a middle point in the cloud, such as webserver, where the
robot and computer would share and indirectly interact
with each other. But as discussed above, this extensive
websever setup is required to facilitate ROS’s multidirec-
tional and simultaneous flow of robot data.
PF offers an alternative solution, by allowing incoming
remote requests to be forwarded from the routers to the
local components, which allows remote access.14 So in the
above example, the robot and laptop would be able to
recognize each other directly, without a middle point or
a third party solution, establishing the remote ROS net-
work.15 Today, PF is used for pin-point remote access of
game servers, to bypass proxies, to create secure and pri-
vate networks, to remotely access Intranet and other pri-
vate networks remotely, and to remote access hardware
devices such as home computers and surveillance
cameras.
Another great advantage of PF over cloud-based solu-
tions is shown in Figure 5. As discussed above, due to the
need of a middle point, or bridge, every message type in the
ROS application requires its own bridge when transmitted
through the cloud. In PF, this is not necessary.
PF does not require a bridge or a middle point, instead it
creates direct ROS-to-ROS channel as if the connection
was local, alibi with time delay. This allows any and all
message types of the ROS application to be transferred.
Also, future application updates or modifications would not
require any further setup.
For example, if a new sensor was added to the robot in
Figure 4 was modified, then the cloud-based solution would
need to be reconfigured to accommodate the new bridges
needed to transmit the new sensor’s message types. But in
4 International Journal of Advanced Robotic Systems
Figure 5. Cloud solutions versus port forwarding.
PF, once the initial setup is done, then any new updates or
modifications are supported without further configuration.
Challenges to implementing PF
On the other hand, implementing PF comes with its own
challenges. First of all, implementing PF is a multilayered
process that involves settings from the Internet service pro-
vider (ISP), modem/router configuration, Linux OS, and
ROS, and in that order. This makes troubleshooting difficult.
In this work, a detailed procedure for configuration and
troubleshooting of each step is presented with examples.
Secondly, PF requires the beforehand knowledge of the
IP addresses of all networked components, and these set-
tings need to be updated if the IP addresses change. Unfor-
tunately, most ISPs provide dynamically changing IP
addresses, which require PF settings to be updated regu-
larly. Doing so manually is cumbersome and error prone, so
for this work, the authors developed a set of shell scripts
that automate this step and solve this problem. These
scripts and their inner workings are outlined in the
“Discussion” section.
Thirdly, implementing PF for corporate connection
(company or university) would require permission, and it
could be limited to a specific location on campus. This was
indeed the case for this work, permission was granted but
only for the laboratory of the author. However, and as
discussed in the beginning, the whole point of remote ROS
networks is implementing them for outdoor robots, where
the grounded connections are hardly, if ever, used. In this
work, multiple mobile broadband modems were used, sim-
ilar to those shown in Figure 4, whose settings are managed
by the ISP and not by IT department, and so no permissions
were required. In fact, modem/router configuration were
supported and guided by the ISP’s technical support teams.
Fourthly, due to the mobile nature of outdoor robots,
conventional virtual private networks (VPNs) could not
be implemented. Because the network tunnel needed for
conventional VPNs would always be disturbed, mobile
devices would roam in and out of the wireless coverage
area. The alternative solution is mobile VPNs, or mVPNs,
but unfortunately, these are not offered by most ISPs as of
yet, not in (country of author) atleast.16
Finally, ROS tutorials focus on local ROS net-
works.10,11 Although they provide useful information, they
do not provide actual guides for PF setup. This is perhaps
because it involves issues that are outside the scope of
ROS, such as networking, modem setup, and so on. In more
than one ROS training material, PF is mentioned but then
left for the reader implement.17 However, these tutorials
provide great connectivity tests, which are a set of tests
developers can perform to test whether the ROS network
is configured properly, and these were incorporated into
this work.
Methodology
A successful ROS network, local or remote, that consists of
a group of components (robots, computers, mobile devices,
and others), must fulfil the following10,11 requirements:
1. There must be a complete, bidirectional connectiv-
ity between all components, on all available ports.
2. Each component must advertise itself by name that
all other components can resolve.
3. One of these components is declared the ROSmas-
ter of the network (usually the main robot).
4. All ROS packages, distributed over this network,
must be configured to use this ROSmaster.
All the settings and configurations discussed in the sec-
tions below are designed to fulfil these requirements. The
following sections are divided into three parts; the expected
outcome, the configuration steps, and the verification steps.
The meaning of these parts should be self-explanatory. Also,
because each component is linked to the Internet through a
separate modem in a remote ROS network, the following
settings must be implemented on each modem, and its con-
nected component. For example, in Figure 4, the laptop is
connected to the internet through modem2, therefore, the
following settings must be performed on modem2 and the
laptop. Similarly, the settings below must also be performed
on modem1, the robot (through its netbook), and so on.
Step 1: ISP Settings
As discussed above, there are generally three types of ISP
connections, corporate, home, and telecom connections, and
so the settings for each connection type are discussed below.
Expected outcomes
1. Obtain confirmation from ISP that PF is enabled to
your connection, on All ports.
2. Obtain a public IP address for your modem that will
be used by others in the remote ROS network.
By default, the router/modem is usually provided by the
same ISP, and so this and the following steps, ISP and
router/modem settings, are usually performed concurrently.
Hajjaj and Sahari 5

Nevertheless, there are important factors that the user must

understand before selecting a suitable telecom ISP for PF,
which is discussed below.

Configuration steps
The configuration steps discussed below vary for each type
of connection, specifically:

Corporate connection. The user must contact the IT depart-

ment, specifically the network administrator to obtain per-
mission to use PF on all ports. Once that is accepted, the IT
department would usually help configure it and assign the
modem a fixed IP address. PF is usually meant for a spe-
cific port, hence the name port forwarding. But since ROS
requires all available ports be used, the term used here is
DMZ, which is basically PF to any available port. Also,
corporate connection usually uses a local area network
(LAN)-cabled connection, and the user would need a router
to establish a wireless network for ROS component. There-
fore, configuration of the router with PF (to all ports) could
also be handled by the IT department as well.
Home connection. By default, there is no need for a permis-
sion for this type of connection, but it does not hurt to
contact the ISP, and confirming the PF is indeed enabled.
Also, the public IP address is usually the IP address of
home router/modem.
Telecom connection. Unlike corporate and home connec-
tions, telecom connection is the only true mobile connec-
tion, which is ideal for outdoor mobile robots. Corporate
and home connections are useful for experimenting
indoors. Telecom ISPs either provide portable wireless
modems/routers or the user’s mobile phone can be used,
through the tethering and portable hot spot features. Either
approach provides a portable wireless connection. As such,
the user must contact the ISP to enable PF, however, when
contacting a telecom ISP, one must remember the follow-
ing pitfalls:
1. It is possible that the general tech support are not
well trained on PF, so request to speak to the more
technically trained networking department, or
arrange an appointment.
2. Not all the telecom ISPs support PF and some sup-
port it partially through specific types of portable
modems and specific types networks.
3. The ISP may or may not provide a fixed public IP
address, in the event the IP address is not fixed, the
user must put that in mind when performing later
configurations steps.Another issue to consider is the
coverage area offered by the ISP, connection speed
(3G or 4G), cost of subscription, and similar factors.
Once all that is done, the provider would supply the user
with a device that supports a wireless connection (portable
Figure 6. Router/modem settings: port forwarding.
or grounded), which also supports PF on all ports, with a
fixed or changing public IP address.
Verification steps
In reality, and as discussed above, the first two steps (ISP
and modem/router settings) are usually performed concur-
rently. As such, there is no verification at this point and the
actual testing begins after the router/modem has been con-
figured, which is the next step.
Step 2: Router/modem settings
As discussed before, the purpose of PF is to configure the
modem/router to forward remote requests to members of
the local network.
Expected outcome
There is only one expected outcome here: obtaining an
“Open” status when checking for PF through any available
and open port. Once the router/modem is configured, the
connection and PF are tested using online PF testing tools.
These are used to check the success or failure of the con-
figuration. For a modem/router provided by a telecom ISP
without a fixed public IP address, this has to be verified a
multiple times through multiple IP address, as discussed
below.
Configuration steps
Corporate connection. Usually, the network admin would
perform this step concurrently with the first step (ISP set-
ting). That is, the IT department of the corporation or Uni
would usually enable PF and configure the modem/router.
Home and telecom connections. Using a browser, log into the
router/modem’s homepage, navigate to firewall settings,
and enable PF, DMZ, and other filtering features shown
in Figure 6.
In order to forward remote requests from modem1 to the
robot, as shown in Figure 4, the modem is configured to
forward these remote requests to the local IP address of the
robot, which is the IP address value shown in Figure 6.
6 International Journal of Advanced Robotic Systems
This is very important, if the local IP address of the robot
changed for some reason, then the user must come back
here and reconfigure the router. Alternatively, the local IP
address (in this case 10.10.10.1) can be permanently
reserved for the robot and so no reconfiguration is required.
Since all available ports are required by ROS, the range was
set as shown in Figure 6. As it can be seen in the figure, this
router also support DMZ, which could be easier to setup,
but not all ISPs provide a separate page for DMZ, if not,
then the settings shown in Figure 6 would suffice. In the
event that the router/modem is not provided by the ISP,
then the router’s manufacturer’s support resources would
be consulted, such as the online resources for D-Link, Net-
gear, or others manufacturer’s websites.
Verification steps
An important point to remember here, ports must be
allowed open and available by the ISP or network admin
before attempting to configure the modem/router. There-
fore, this must be verified by the ISP before testing these
steps. To verify that PF and/or DMZ settings have been
correctly configured, follow these steps:
1. First, ensure your connection is working, open a
browser, and browse the internet. If OK, then
proceed.
2. Select a port number between 1024 and 65000, let
us call this value: portNumb.
3. Start a netcat chat session on the selected port.
4. In Linux, run: nc -l portNumb.
5. For example, if you chose portNumb ¼ 12345, the
command would be: nc -l 12345.
6. This will start a netcat server at the portNumb you
selected (you can try netcat if nc does not work).
7. Open a new browser window, search for any
PortChecker website, and then go to it.
8. In the website, you will see your modem’s public
IP address, and a space to enter the number of the
port you wish to check, enter the number, and hit
OK or Go.
9. If the status of the port is Open, then this step is
successful, and you can proceed to step 3.
10. Repeat the test with different portNumbs to con-
firm that your PF works on any port.
This test puts the component being configured (robot,
computer, etc.) in a situation that mimics the remote ROS
network (Figure 4). The netcat command mimics the ROS-
master service, while the PortChecker website mimics the
signal received remotely from other components. The ideal
result expected here is Open, which indicates that every-
thing is set properly. In the event, the result is Closed, and
there are two possibilities, as shown in Table 1.
As shown in the table, the user must ensure that the
netcat server is up (command has been typed in a terminal),
Table 1. PortChecker test results and their meanings.
Result Netcat server Indication
Open Up Port forwarding setup successful
Closed Down Port not being used
Closed Up Port forwarding setup failed
otherwise the selected port would not be used. However, if
the netcat server was indeed up, and the result is still
Closed, this means PF setup and configuration has not been
done correctly. This could be due to three possible reasons.
 Port is being used by another service on the network,
try another port numb (higher than 1024).
 There could be firewalls and/or network limitations
by the ISP or network admin, return to step 1.
 Modem/router PF configuration was not properly
performed, return to step 2.
Once the result is Open to all components of the remote
ROS network, as shown in Figure 4, then this step is com-
plete and you can proceed to step 3.
Step 3: Linux OS settings
From this point onwards, all configuration steps are within
the computer level (PC, laptop, netbook, etc.), therefore,
from now on, the term component refers to the computer of
the item being networked in the ROS network. For exam-
ple, referring to Figure 1, this could be the Desktop of the
observer, the laptop of the operator, the netbook onboard of
robot1, and so on. Also, this article assumes that Linux is
the operating system of all of these components. However,
the settings discussed below are generic and so they can be
applied in any other ROS-supported operating systems.
Expected outcome
At the end of this step, network components are expected
to:
1. Ping each other, using network names.
2. Secure SHell (SSH) to each other, using network
names.
3. Netcat chat with each other, using network names,
initiated from either side, and on any port.
These three tests check for important features used by
ROS. Recalling that in a ROS network, components must
recognize each other and exchange data in order to facil-
itate the performance of the robot. These steps verify that.
In the last test, it is important that the netcat chat session
should be successful when initiated from either side. That is
because in a ROS network, every component is expected to
initiate an exchange of data and act like a publisher and/or
subscriber.
Hajjaj and Sahari
Figure 7. Local hosts configuration—in the laptop.
Figure 8. Local hosts configuration—in the robot.
Configuration steps
For each component of the remote ROS network (Figure 4),
do the following:
1. Take note of the local and public IP address of the
component.
2. For example, the laptop in Figure 4 has a local IP
add ¼ 10.10.10.1 and a public add IP ¼
113.32.43.6.
3. Access the file that defines local hosts in your OS.
4. In Linux, run: sudo gedit /etc/hosts.
5. Edit that file as shown in Figure 7 below.
6. Ensure that you key-in the correct IP addresses.
7. Take note of the discussion below.
8. Save, close, and restart.
9. Repeat this step for each component.
The hosts file is a Linux environment file that registers
names and IP addresses of each component. As shown in
Figure 7, the laptop is defined as sami and the robot is defined
as turtlebot, where these names are completely arbitrary.
The hosts definitions must be created for each component
and from its point of view. Figure 7 shows the definitions
from the laptop’s point of view, where it is defined by its local
IP address, and robot is defined by its public IP address. From
the robot’s point of view, as shown in Figure 8, the situation is
reversed. The robot is now defined by its local IP address
and the laptop is now defined by its public IP address.
Also, notice how the names sami and turtlebot are the
same in both hosts definitions file. This is actually a con-
venience, and it is indeed recommended to be the same.
Because technically these components could be assigned
different names in different hosts files, but that would make
networking far more complicated. Apart from this, there
are several pitfalls and challenges that could arise here,
which are discussed below:
gedit might not work. The command sudo gedit/etc/hosts
may not work in some Linux distributions; due to some
Linux-related issues, you can either use others editor or
add more permissions.
Changing networks. Hosts definitions are valid for the net-
work they are part of. As can be seen in Figures 7 and 8,
7
Figure 9. A complete hosts file configuration.
public IP addresses are being used, which is only true for a
remote ROS network. If a user decides to switch to a local
network, where only local IP addresses are used, these
definitions can no longer be used and other definitions need
to be defined.
Furthermore, the component (robot or laptop) could be
used in different networks in different times, changing from
a corporate network to a remote network to a local-telecom
network (robot and laptop using the same portable telecom
modem/router). In every one of these networks, the IP
addresses would change.
Therefore, it would be useful to create a hosts definition
file that caters for all these changes, one example of such
file is shown in Figure 9.
As it can be seen in the figure, there are several sets of
hosts configurations that can be applied, depending on the
type of network currently used. There are two local net-
works (office and portable) and a remote network. The
local network use local IP address, while the remote net-
work uses public IP addresses. Finally, this file is from the
laptop’s point of view, and so a similar file should be cre-
ated for the robot’s point of view.
Dynamically changing IP address. As discussed above, ISPs
may not allocate you a fixed public IP address. If so, you
will need to update the hosts file every time you restart the
portable modem, this could be cumbersome and error-
prone. The solution is to automate this step using a combi-
nation of shell scripts and a cloud storage facility, such as
Dropbox. Through this setup, the robot’s netbook can
enquire about its current public IP address, informs the
laptop (through Dropbox), allowing the laptop to update
its hosts file. The scripts used for this project, developed
by the author, can be found on this repository.18 In the
discussion section below, these scripts and their inner
workings are further discussed.
Verification steps
There are three tests to be conducted here: the ping test,
the SSH test, and the netcat chat test. All the three are
8 International Journal of Advanced Robotic Systems
Figure 10. A successful ping test, through the remote network.
Figure 11. A successful SSH test, through the remote network.
conducted through the remote network. Note that the
names and IP addresses used in the test below are based
on the settings saved in the hosts files in the laptop and
the robot of the author, use the your own names and IP
address in your tests. The ping test is as follows:
1. In the laptop’s terminal, run: ping turtlebot.
2. If you used a different name for the robot, use it.
3. If successful, run the same test from the other side.
4. If successful, then you can proceed to the SSH test.
Figure 10 shows an example of a successful outcome,
where the laptop was able to ping the robot through the
remote network using only the host name. As it can be seen
from the figure, the public IP addresses are in effect (par-
tially hidden).
The SSH test
1. SSH from the laptop to the robot using a command
similar to the one shown in Figure 11.
2. If successful, run the same test from the other side.
3. If successful, then you can proceed to the netcat test.
It is possible that the SSH test could fail due to reasons
related to SSH itself and not anything discussed so far.
Issues are such as public key, username authentication,
installation issues of SSH, SSH being down (switched off),
and other related factors. Therefore, run the SSH test on a
local network first. This would require you to reconnect
robot and laptop through a single modem and update the
hosts definitions to reflect this change. Then attempt to SSH
between robot and laptop, and then deal with SSH-related
issues, and once resolved, then you can proceed to run this
test on a remote network. Figure 11 shows an example of a
successful outcome, where the laptop was able to SSH the
robot through the remote network using only the host name.
Figure 12. A successful netcat test, through remote network.
The netcat chat test
1. In the laptop, open two terminal windows.
2. In one window, SSH to the robot Now you have two
terminal windows open, one for the robot and one
for laptop, as shown in Figure 12.
3. In the laptop’s window, run: nc -l portNumb.
4. In the robot’s window, run: nc sami portNumb.
5. If OK, then you created a chat session, type a away
in either window, you should see it on the other
side.
6. If successful, then repeat step 3 from the
robot’s window and step 4 from the laptop’s
window.
7. If both sides are successful, then step 3 is complete,
and you can proceed to the final step (step 4).
Once again, portNumb is the port number you chose,
which could be any available port above 1024. Figure 12
shows an example of a successful outcome. In the figure,
we can see a chat session established in the robot’s side.
The chat session was successfully established from the lap-
top’s side as well.
It is important to understand that step 6 of the test is
very important. One must ensure that the chat server
can be established on both sides, because that repre-
sents the ability of each component to act as a server
and a client, which is a fundamental requirement for
ROS components.
Step 4: ROS settings
This is the final step in the configuration and so the reader
is advised to ensure all previous steps are completed suc-
cessfully before attempting this step. The objective of this
final step is to register all components of the remote ROS
network with the ROSmaster and insure that all compo-
nents are able to publish and subscribe to each other. A
ROSmaster could be any component of the ROS network.
For the network shown in Figure 4, the robot was selected
as the ROSmaster. Therefore, the expected outcomes
would be as follows.
Hajjaj and Sahari
Expected outcomes
1. The ROSmaster component is properly registered
for each member of the ROS network.
2. Every component is able to publish or subscribe to
other components in the remote ROS network.
This can be achieved by appending the bash file, the shell
environment file, and setting the value of ROS_Master_
URI to equal the IP address of the ROSmaster, or
specifically:
Configuration steps
1. In the ROSmaster component, add the following:
export ROS_MASTER_URI¼Robot_loclIP:
11311
2. In other components, add the following: export
ROS_MASTER_URI¼Robot_pubIP:11311
3. Do not add definitions of ROS_IP or ROS_HOST-
NAME as described in ROS tutorials.
Public versus local IP addresses. Once again, since the ROS-
master (robot) refers to itself, we use the robot’s own local
IP address. If we attempt to use the public IP address here,
roscore would throw an error and would not start.
As for other components, such as the laptop, they will
refer to the robot using its public IP address. This is very
similar to the hosts definitions created in step 3.
ROS_IP and ROS_HOSTNAME. ROS networking tutor-
ials10,11 recommend setting these values in order to solve
networking issues. However, it was found by the author
that doing so would cause ROS problems; some compo-
nents would be able to publish only and not subscribe, or
vice versa; subscribe only and not publish. One must
remember that these tutorials were written primarily for the
local ROS network, where these settings would be fine. But
for the remote ROS network, these definitions would over-
ride the hosts definitions created in step 3 (Linux settings)
and so cause the ROS problems discussed above.
As such, for the remote ROS network, the authors rec-
ommend using the ROS_MASTER_URI only and set the
hosts as discussed in step 3.
Changing IP address. If the robot’s public IP address is vari-
able, then once again, the bash settings in each component
must be updated every time the robot’s portable modem is
restarted. Once again, this step could be automated, as dis-
cussed in step 3, through the use of shell scripts and a cloud
storage facility such as Dropbox. In fact, the scripts developed
for this project,18 referenced above, automate this step as well.
Verification steps
At this stage, all settings and configurations have been
completed, and to verify the settings, the remote ROS
9
network needs to be started and tested. There are three ROS
tests that can be used here:
1. the minimal network test;
2. the listener/talker test; and
3. the turtlebot interaction tests.
These tests are designed to test specific ROS funtional-
ities, which are outlined and discussed below.
The minimal network test
1. Switch on all the modems, and ensure connection is
ON.
2. Update the hosts and the bash files to reflect the
current public IP address of the robot.
3. From the robot’s onboard computer, open a terminal
window and run: roscore to start ROS.
4. Alternatively, SSH into the robot’s onboard com-
puter from another component, and start ROS.
5. At this point, the remote ROS network is up.
6. From the laptop, run: rostopic list, you should see
the list of ROS topics. The outcome of the com-
mand may take few seconds longer than usual.
7. If you see a list of topics, then this test is successful,
and you can proceed to the next test.
The listener/talker test
1. From the robot’s computer, start a talker, buy run-
ning this command: rosrun rospy_tutorials
talker.py.
2. From the laptop, start a listener, by running this
command: rosrun rospy_tutorials listener.py.
3. If all is OK, the listener on the laptop should
respond to the talker from the robot’s computer.
4. Again, this might longer than usual to happen.
5. If successful, repeat this test from the other direc-
tion, a talker from the laptop and a listener from the
robot.
6. It does not matter who starts first, a talker or a
listener, and it should always work regardless.
7. If successful, then this test is successful, and you
can proceed to the next step.
The turtlebot interactions tests
If you have reached this point, then that remote ROS net-
work has been successfully configured. The final test is to
implement it on an actual robot. The following test assumes
that the robot is a ROS-enabled robot, which means that it
has already been preinstalled with the required ROS
packages needed to interact with other ROS components.
For this article, Turtlebot2 is used. Also, the reader is
expected to be familiar with ROS, its concepts, and the
terminologies used in this test. Before starting, ensure that
all the modems are switched on, that the network is up and
running, and that you updated all hosts and bash files to
10 International Journal of Advanced Robotic Systems

reflect the current IP addresses of the robots. In case you

automated this step with dynamic direct domain system
(DNS), double check the values for good measure. Then,
if all is set, then you can begin the final test.

1. Using roslaunch files, bring up the robot

(minimum).
2. From the laptop, start a keyboard teleop session.
3. From the laptop, start an rviz visualization session.
4. In rviz, add a camera view to receive a live feed.
5. Change the image quality to be compressed, or
black and white, to reduce burden on the network.
6. When everything is open, proceed to teleoperate the
robot (publish) and receive live visual feed
(subscribe).
Figure 13. Setup of the ROS-android method.

If you are able to teleoperate the robot and receive live

images from it, then Congratulations! You have success-
fully configured your ROS remote network via PF.

Discussion
In this section, an outdoor ROS application is to be linked
to the cloud, using a number of cloud-based solutions and
PF, with the following settings:

 The robot is a mobile (wheeled) agriculture robot.

 It is set to operate in an open field, performing a set Figure 14. Man-hours needed to develop each method.
of pre-programmed autonomous agriculture tasks.

For an effective performance of this robot, a remote
ROS network is developed, similar to the one shown in
Figure 4, using the following technologies: rosbridge,
ROS-android, RoboEarth, and PF.
 Through this remote network, the robot sends real-
time status and task updates to the operator.
 Who would use this data to monitor, control, and
select the needed agriculture task for the robot to
perform.
Data published by the robot are current robot speed,
current location in the field (global positioning system
[GPS], fix), live feed (camera view of the robot), battery
and power status, task status, and task completion.
For example, Figure 13 shows the setup of the ROS-
android method, showing the rosjava publishers and sub-
scribers (developed by the authors) to publish robot data,
user commands, and establish connectivity, as required.
Other methods followed similar setup and patterns.
Then, these methods are compared in terms of setup com-
plexity and effort required, robot performance (utilizing the
remote network), and challenges facing implementation of
each method (and how to resolve it). The findings of this
comparison are discussed below.
Table 2. Software needs for each method.
Method Software components
rosbridge ROS, networking, JSON, ROS.js webservers,
web applications
ROS-android ROS, networking, Java, rosjava,android,
android_core, Concurrency Android Studio,
Google Cloud App development, Google
Cloud
RoboEarth ROS, networking, rosbridge RoboEarth
components: Rapyuta, KnowRob, WIRE,
C2TEAM, etc.
Port forwarding ROS, networking, shell-scripting
modem configuration, Dropbox
Setup complexity
For this work, setup complexity is measured by the amount
of man-hours needed to learn, install, and develop the soft-
ware needed for each method. This is shown in Figure 14
and Table 2. The man-hours needed for ROS and network-
ing were excluded because they are common to all.
As it can be seen, PF required the least amount of man-
hours to learn, install, and develop. This is understandable,
considering that it does not require any third party technol-
ogy or platform. On the other hand, RoboEarth required the
Hajjaj and Sahari 11

Figure 15. Robot remote response time Figure 16. Agribot App and MapView.

most man-hours because developers need to learn all of its

components, as shown in Figure 3, which in turn require
learning all the basic concepts such as rosbridge, webs-
evers, web applications, database design, and so on.
Also, ROS-android also required extensive learning as it
involves learning of Java, and android app development,
along with its advanced concepts.

Robot performance
Effect of each method on robot performance can be mea-
sured in robot response time. If a method causes too much Figure 17. Auto-update PF settings.
delay, then it becomes impractical. Through ROS logging,
time of robot commands (when given by users) and time
of robot execution of these commands were recorded, and
by calculating the difference between them, robot
response time was found. Figure 15 shows robot response
times in each method, while performing a set of robot
operations.
As shown in the figure, robot performance is compara-
ble in all methods. So, regardless of the method used, the
robot performed autonomous tasks the fastest and sensor-
Figure 18. Auto-update PF settings, master-script.
related tasks, such as mapping and localization, the slowest,
since the robot needed to transmit sensor data to the home
computer, remotely, for processing.
Managing dynamically changing IP addresses
An unexpected challenge faced by the authors, when As discussed above, ISPs seldom provide users with fixed
developing cloud-based solutions, was the need to recreate IP addresses, instead they usually provide a range of IP
ROS’s visualization tools such as rviz but in non-ROS addresses, such as 173.17.XXX.XXX, where the XXX
environments. This meant more development effort was could range from 000 and 255. This is obviously a problem
needed to develop these visualization and monitoring tools for PF, as the settings outlined above would need to be
for android, RoboEarth, and web applications. updated every time the IP addresses change. The solution
In ROS-android, this was solved by utilizing android’s to this challenge is to auto-update PF settings through a
views such as ProgressBar, ImageView, MapView, and so combination of shell scripts, combined with a cloud-
on, as shown in Figure 16. These views allowed users to storage facility such as Google’s Dropbox. This is shown
view robot’s battery status, speed (currently not moving), in Figures 17 to 19.
GPS fix (shown in a google map), and current job status The process begins with the ROSmaster component of
(current task highlighted in blue). Also, control buttons the ROS network, which hosts the ROS session and man-
were added for users to interact with the robot. ages the flow of information across the ROS network,
For PF, there was no need for such extra work, as PF ensuring all components transfer their data to the right
allowed a direct ROS-to-ROS connection, so ROS’s visua- destinations. In this example, the ROSmaster happens to
lization tools were utilized as if the connection was local. be the agriculture robot, and there is only one other mem-
The only difference was the minor time delays. ber, the operator’s laptop.
12
Figure 19. Auto-update PF settings, member-script.
The master-script is installed in the ROSmaster’s
embedded computer and runs when the robot is started. It first
checks for internet connection, then it checks the current
public IP address. If there is any change, then it updates the
value stored in a file saved on Dropbox. Because all ROS
members are linked to the same Dropbox file, they all get
notified when the file is modified (when the IP address is
updated). This in turn triggers the member-scripts (Figure 19).
Similarly, the member-script checks for changes in the
IP address of the ROSmaster, which is indicated by changes
in the Dropbox file. Once triggered, then the PF settings for
the member (laptop) are updated. This is done by updating
hosts and the ROS_master_URI, which are steps 3 and 4 of
the PF configuration process, as discussed above. But, Fig-
ures 18 and 19 show simplified versions of these scripts,
where all prompts, confirmations, and the complete two-way
PF settings update are shown. The source code of the com-
plete scripts are available at the Github page of this project.18
To summarize the discussion section, PF-powered
robots performed on par with robots powered by cloud-
based solutions, while requiring the least amount of time
to learn, install, and develop. The shell scripts developed by
the authors were able to monitor the IP addresses of the
networked components and auto-update PF settings accord-
ingly, allowing PF to become a viable option for linking
ROS applications to the cloud.
Conclusions
In conclusion, this work was able to meet its objectives.
Cloud-based solutions for linking ROS applications to the
cloud were reviewed, a detailed process for setting up PF
for ROS was introduced, and a comparison between the two
methods was made.
Although cloud-based solutions do deliver on their
promise, they come with challenges. This is because link-
ing cloud-based solutions with ROS requires building a
ROS<¼cloud-based solution¼>ROS bridge, which in turn
would requires an extensive amount of man-hours to learn,
install, and develop the underlying technologies of these
solutions. This is especially true for complex robot appli-
cations that involve tens to hundreds of difference ROS
message types, each requiring its own bridge, and the pro-
cess could become really complex.
International Journal of Advanced Robotic Systems
A detailed process for configuring PF was presented in
this article, highlighting all configuration steps, and in all
of its layers. This includes the ISP level, the modem/router
level, the Linux level, and finally ROS itself. Along the
way, troubleshooting protocols were introduced to help
developers test their steps and ensure proper configuration
and robot operations.
One of the biggest challenges facing PF is handling dyna-
mically changing IP addresses. Since most ISPs provide
ranges of IP address and seldom fixed ones, PF settings
would need to be updated accordingly and doing so manu-
ally would be cumbersome and error prone. To solve this
problem, the authors introduced a collection of shell scripts,
combined with some cloud-storage facilities (ironically) to
auto-update PF settings of all networked components. This
is achieved by monitoring the connection, detecting changes
in IP addresses, and then updating PF settings seamlessly.
Performance-wise, robot systems utilizing PF per-
formed on par with those utilizing cloud-based solutions,
but with the fraction of the man-hours needed for learning
and setup. This was the case because PF provides a direct
ROS-to-ROS remote connection, without the need for a
third-party bridge, and its associated challenges such as
data conversion, non-ROS development, and so on.
Therefore, with the work presented in this article, PF
could be considered as viable option for setting up of
remote ROS networks and ROS-enabled outdoor robot
applications such as agriculture, military, search and res-
cue, and others.
Acknowledgement
The authors would like to thank the College of Engineering, the
Innovative and Research Management Centre (iRMC), UNITEN,
for their continued support of this work.
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with
respect to the research, authorship, and/or publication of this
article.
Funding
The author(s) disclosed receipt of the following financial support
for the research, authorship, and/or publication of this article: This
work was supported by the College of Engineering, the Innovative
and Research Management Centre (iRMC), UNITEN and the
Ministry of Higher Education, Malaysia through research grant
(20140127/FRGS/V3500).
References
1. Boren J and Cousins S. New Exponential Growth of ROS
[ROS Topics]. IEEE Robot Autom Magazine 2011; 18(1):
19–20. DOI:10.1109/MRA.2010.940147.
2. O’Kane JM. A Gentle Introduction to ROS. Independently
published, 2013. ISBN 978-1492143239. https://cse.sc.edu/
~jokane/agitr/
3. Emmi L, de Soto MG, Pajares G, et al. New trends in robotics
for agriculture: integration and assessment of a real fleet of
Hajjaj and Sahari
robots. Sci World J 2014; 2014: 21. DOI: 10.1155/2014/
404059. Article ID 404059.
4. Crick C, Jay G, Osentoski S, et al. ROS and rosbridge:
Roboticists out of the loop. In: Holly Yanko and Aaron Stein-
field (eds) Proceedings of the Seventh Annual ACM/IEEE
International Conference on Human-Robot Interaction. HRI
‘12, 5–8 March 2012, New York, NY, USA, New York:
ACM. ISBN 978-1-4503-1063-5, pp. 493–494. DOI:10.
1145/2157689.2157846.
5. Kohler D, et al. Google i/o 2011: Cloud robotics, introducing
rosjava. https://www.youtube.com/watch?feature¼player_
embedded&v¼FxXBUp-4800,2011. (accessed 26 June 2016).
6. de A Barbosa JP, Lima FD, Coutinho LD, et al. ROS, Android
and cloud robotics: how to make a powerful low cost robot.
In: Aydan M. Erkmen, Afşar Saranlı and Konukseven E.
ilhan (eds) Advanced Robotics (ICAR), 2015 International
Conference, 27 July 2015, pp. 158–163. IEEE. DOI: 10.
1109/ICAR. 2015.7251449.
7. G Mohanarajah DH, D’Andrea R and Waibel M. Rapyuta: a
cloud robotics platform. IEEE Trans Autom Sci Eng 2015;
12(2): 481–493. DOI:10.1109/ TASE.2014.2329556.
8. Toris R, Kammerl J, Lu DV, et al. Robot web tools: effi-
cient messaging for cloud robotics. In: Norman Hendrich
(ed) 2015IEEE/RSJ International Conference on Intelli-
gent Robots and Systems (IROS), Hamburg, Germany, 8
September–2 October 2015. pp. 4530–4537. IEEE. DOI:
10.1109/IROS.2015.7354021.
9. Koken B. Cloud robotics platforms. Interdisciplinary
Description of Complex Systems 2015; 13(1): 26–33.
10. The ROS Wiki. Running ROS accross multiple machines.
http://wiki.ros.org/ROS/Tutorials/MultipleMachines, 2016.
(accessed 20 September 2016).
13
11. The ROS Wiki. ROS network setup. http://wiki.ros.org/ROS/
NetworkSetup,2016. (accessed 20 September 2016).
12. Speers A, Forooshani PM, Dicke M, et al. Lightweight
tablet devices for command and control of ROS-enabled
robots. In: Fiorini Paolo (ed) Advanced Robotics (ICAR),
2013 16th International Conference on, Montevideo, Uru-
guay, 25–29 November 2013, pp. 1–6. IEEE. DOI: 10.
1109/ICAR.2013.6766481.
13. Do HM, Mouser CJ, Gu Y, et al. An open platform telepre-
sence robot with natural human interface. In: Wen Jung Li
(ed) Cyber Technology in Automation, Control and Intelli-
gent Systems (CYBER), 2013 IEEE 3 rd Annual International
Conference on, Kowloon Tong, Hong Kong, 26–29 May 2013,
pp. 81–86. IEEE. DOI:10.1109/ CYBER.2013.6705424.
14. Chinnadurai G and Ranganathan H. Two wheel self equili-
brium swarm robot controlled by port forwarding methods
using IoT. Int J Inno Sci Res 2015; 24(1): 79–85. ISSN
2351-8014.
15. Luo YB, Wang BS and Cai GL. Analysis of port hopping for
proactive cyber defense. Int J Security Appl 2015; 9(2):
123–134.
16. Shin DH. Overlay networks in the west and the east: a techno-
economic analysis of mobile virtual network operators.
Telecommun Syst 2008; 37(4): 157–168. DOI:10. 1007/
s11235-008-9105 -1.
17. Goebel RP. ROS by example, for Indigo, Vol 1, Section: 4.12.
7: Networking accress the Internet. Independently Published,
2015. ISBN: 5-800085-311092, p. 18.
18. Hajjaj S. A collection of scripts developed to autoupdate the
linux and ros setting for a remote ROS network via port-
forwarding. https://github.com/roboFriend1977/autoUpdate
PubIPforROS, 2016. (accessed 28 September 2016).