See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/317318127

ROSLink: Bridging ROS with the Internet-of-Things for cloud robotics

Chapter in Studies in Computational Intelligence · May 2017

DOI: 10.1007/978-3-319-54927-9_8

CITATIONS READS

60 6,063

3 authors:

Anis Koubaa Maram Alajlan

Prince Sultan University Prince Sultan University
349 PUBLICATIONS 9,360 CITATIONS 27 PUBLICATIONS 841 CITATIONS

SEE PROFILE SEE PROFILE

Basit Qureshi
Prince Sultan University
95 PUBLICATIONS 1,520 CITATIONS

SEE PROFILE

All content following this page was uploaded by Anis Koubaa on 22 January 2018.

The user has requested enhancement of the downloaded file.

 ROSLink: Bridging ROS with the
Internet-of-Things for Cloud Robotics

Anis Koubâa123 , Maram Alajlan14 , Basit Qureshi2

1
Prince Sultan University, Innovation Center
Robotics and Internet of Things (RIOT) Research Unit, Saudi Arabia.
2
Gaitech Robotics, China.
3
CISTER/INESC-TEC, ISEP, Polytechnic Institute of Porto, Porto, Portugal.
4
King Saud University, Riyadh, Saudi Arabia
[email protected],[email protected],[email protected]

Abstract. The integration of robots with the Internet is nowadays an

emerging trend, as new form of the Internet-of-Things (IoT). This inte-
gration is crucially important to promote new types of cloud robotics ap-
plications where robots are virtualized, controlled and monitored through
the Internet. This paper proposes ROSLink, a new protocol to integrate
Robot Operating System (ROS) enabled-robots with the IoT. The moti-
vation behind ROSLink is the lack of ROS functionality in monitoring and
controlling robots through the Internet. Although, ROS allows control of
a robot from a workstation using the same ROS master, however this so-
lution is not scalable and rather limited to a local area network. Solutions
proposed in recent works rely on centralized ROS Master or robot-side
Web servers sharing similar limitations. Inspired from the MAVLink pro-
tocol, the proposed ROSLink protocol defines a lightweight asynchronous
communication protocol between the robots and the end-users through
the cloud. ROSLink leverages the use of a proxy cloud server that links
ROS-enabled robots with users and allows the interconnection between
them. ROSLink performance was tested on the cloud and was shown to
be efficient and reliable.

Keywords: Robot Operating System (ROS), Cloud Robotics, Internet-

of-Things, ROSLink, Mobile Robots, Protocol Design

1 Introduction
Cloud Robotics [1] [2] [3] is a recent and emerging trend in robotics that aims
at levering the use of Internet-of-Things (IoT) and cloud computing technolo-
gies to promote robotics applications from two perspectives: (i.) Virtualization:
providing seamless access to robots through Web and Web services technologies,
(ii.) Remote Brain: offloading intensive computations from robots to the cloud
resources to overcome the computation, storage and energy limitations of robots.
Nowadays, Robot Operating System (ROS) [4] represents a defacto standard
for the development of robotics applications. ROS as a middleware, provides
several levels of software abstraction to hardware and robotics resources (i.e.
2 Anis Koubâa, Maram Alajlan, Basit Qureshi

sensor and actuators) in addition to the reuse of open source project libraries.
It has been designed to overcome difficulties when developing large-scale ser-
vice robots reducing the complexity of robotics software construction. Although
widely used in developing applications for service robots, ROS lacks the native
support for control and monitoring of robots through the Internet. It is possible
to write ROS nodes (i.e. programs) in a remote workstation on the same local
area network (LAN), where both the robot machine and the workstation use the
ROS Master Uniform Resource Identifier (URI)., however controlling the ROS
nodes from a remote location is challenging. To address this limitation many
research works have been proposed focusing on client-server based architecture
[5][6][7][8][9][10].
A milestone work that addressed this issues is the ROSBridge protocol [11].
It is based on Websockets server installed on the robot side that allows to send
the internal status of the robot based on ROS topics and services and receives
commands to Websockets clients to process them. This approach enabled the
effective integration of ROS with the Internet; however, the fact that the Web-
sockets server is running on the robot machine requires the robot to have a public
IP address to be accessible by Websockets clients, which is not possible for every
robot, or being on the same local area networks. Network address translation
(NAT) could also be used when the robot is behind a NAT domain, but still
this option may be cumbersome in deployment. In [12], the author proposed a
ROS as a Web service which allow to define a Web service server in the robot
to access through the Internet. However, this solution share the same limitation
as ROSBridge as the server is located at the robot side.
This paper fills the gap and proposes ROSLink, a communication protocol that
overcomes the aforementioned limitations by (i.) implementing specifications of
client in the robot side, (ii.) manifestation of a proxy server located at a public
IP server machine, such a cloud server. The idea is inspired by the MAVLink
protocol [13], where the robot sends its data in serialized messages through a
network client to a ground station that acts as a server which in turn, receives
these messages, processes them and sends control commands to the robot. As
such, it is no longer needed for a robot to have a public IP address, whereas it
will still be accessible behind the proxy server.
The contribution of this paper are two folded. First, we propose ROSLink a
new communication protocol that defines a 3-tier architecture. The ROSLink
Bridge client executes in the robot side; the ROSLink Proxy acts as a server
in the ground station, and a client application at the user side that interacts
with the robot through the ROSLink protocol. Second, we validate the proposed
ROSLink protocol through an experimental study on the ground Turtlebot robot
as well as the aerial AR.Parrot drone. We demonstrate the effectiveness and
feasibility of ROSLink.
The remainder of this paper is organized as follows. Section II presents mo-
tivating examples and objectives behind the design of ROSLink. Section III
presents the ROSLink communication protocol. Section IV presents the exper-
 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 3

imental validation of ROSLink and the evaluation of its performance. Finally,

Section V concludes the paper.

2 Motivating Problems and Objectives

2.1 Problem Statement
The motivation behind this work is to integrate ROS with the Internet of Things.
ROS does not natively support monitoring and control of robots through the
Internet. In fact, as illustrated in Figure 1a, ROS allows to control a robot from
a workstation using the same ROS master, but this solution is not scalable and
rather limited to a local area network usage. The typical scenario is that every
robot starts its own ROS Master node, and users can control the robot from
their workstations if they configure their ROS network settings to use the same
ROS Master running in the robot. This standard approach does not natively
allow to control the robot through the Internet as robots typically do not have a
public IP address. The use of port forwarding behind NAT can be considered in
certain cases, but might not be possible in other cases, like connection through
3G/4G connection.
One possible solution, as illustrated in Figure 1b, is to use one ROS Master
node for all robots, where the Master node runs on a central server with a public
IP address on the Internet. All users will connect to the same ROS Master
and can access any robot by publishing and subscribing to their topics and
services. However, this solution has several limitations. First, some ROS topics,
services and nodes may be in conflict with having the same name. This issue
requires a careful design of namespace for ROS nodes, services and topics to
avoid any conflict. With the large number of robots, this solution becomes very
complex. The second issue is the lack of scalability, i.e. the ROS Master might
become overloaded when several robots are bound to it at a given time. Apart
from the known networking issues while considering that several ROS topics are
bandwidth greedy, there is no viable solution to mapping individual users to
their robots since all topics will be visible to all users.
Our approach consists in the design of ROSLink, a lightweight communica-
tion protocol, inspired from MAVLink [13], to allow for a cloud-based interaction
between ROS robots and their users, as depicted in Figure 1c. The idea is to add
a ROSLink Bridge on top of ROS for every robot such that this bridge sends
all the status of the robot using JSON serialized messages. ROSLink Bridge is
a ROS node that accesses all topics and services of interest in ROS, and sends
selected information in ROSLink messages, serialized in JSON format. These
messages are sent to the ROSLink Cloud Proxy, which processes the messages
and forwards them to the individual user and/or users of the robot. In addition,
users send commands to the robot through the ROSLink cloud proxy utilizing
ROSLink JSON messages, which are later processed by the ROSLink Bridge re-
sulting in execution of the corresponding ROS action. The ROSLink cloud-based
approach presents three major advantages (1) to be independent from the ROS
master nodes of the robots, (2) ensure seamless communication between users
4 Anis Koubâa, Maram Alajlan, Basit Qureshi

and robots through the cloud, (3) provide effective management of robots, users
and underlying services.

2.2 Overview

The main objective of ROSLink is to control and monitor a ROS-enabled robot

through the Internet. In the literature, most of the related works focused on
using two-tiered client/server approach while the server is implemented in the
robot and the client is implemented in the user application. In fact, most of these
researches are based on the instantiation of ROSBridge and ROSJS frameworks
[11, 14] to build remotely controlled robots. ROSBridge represents a milestone
that enabled this kind of remote control of ROS-enabled tele-operated robots.
However, the drawbacks of this approach are (1) robot-centric approach, which
restricts the scalability of the system as the server is centralized in the robot
itself, (2) the deployment on Internet is rather difficult as the robot needs to
have a public IP address or accessible through a NAT forwarding port, when it
is inside a local area network.
To overcome these limitations, we propose ROSLink a three-tiered clien-
t/server model, where the client is implemented in the robot and the user,
whereas the server is located at a public domain and acts as a proxy to link
the robots with their users. ROSLink overcomes the two aforementioned prob-
lems. First, there is no longer a server implemented inside the robot, so it does no
longer follow the robot-centric approach. In contrast, the robot implements the
client side through the ROSLink Bridge components, which is a ROS node that
interfaces with ROS on the one hand, and on the other hand sends ROS data
to the outside world through a network interface (UDP, TCP, or Websockets).
Besides, the ROSLink server side of the model is implemented in a publicly avail-
able server called ROSLink proxy, which acts as a mediator between the robots
and the users. Robots and users send messages to the proxy server, which will
dispatch them accordingly to the other side.
ROSLink makes a complete abstraction of ROS by defining a communication
protocol (inspired from the MAVLink protocol) that provides all information
about the robot through ROS topics/services without exposing ROS ecosystem
to the users. The user does not need to be familiar with ROS to be able to use
ROSLink to send commands for robot. ROSLink defines a set of interfaces for
the users to interact with the robot, and a set of messages to exchange between
them.
ROSLink messages are constructed based on ROS topics/services parameters
to either get data from or submit data to execute an action. The messages are
represented as JSON strings. JSON format is opted to use in data interchange
because it is platform-independent and language-independent data representa-
tion format [15]. In addition, it is a lighter-weight solution as compared to XML,
which is more appropriate for resource-constrained and bandwidth-constrained
platforms. This will allow the client application developer to choose any pro-
gramming language ( C++, Java, JavaScript, Python, etc.) to develop a client
 Problem
ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 5

ROS Master

ROS Master

ROS Master

Possible Solution
(a) Standard Approach:Typical connection between ROS
robots and ROS users. A user is connected to the ROS Mas-
ter of the robot to control and monitor its status, typically, in a
local area network.

ROS Master

Approach
(b) Centralized Approach: One central ROS Master to which
all robots and users connected. This solution is not scalable, does
not provide effective management of robots and users.

ROSLink Bridge
ROSLink
Message ROSLink
Message
ROS Master

ROSLink
Message
ROSLink ROSLink
Message
Cloud Proxy ROSLink Bridge

ROS Master

ROSLink
Message ROSLink
Message

ROSLink Bridge

ROS Master

(c) ROSLink Approach: A cloud based approach, where ROS

robots and users interact through the cloud. The ROSLink cloud
provides users and robots management, service oriented inter-
faces, and real-time streaming services.

Fig. 1: ROS Operation Approaches

6 Anis Koubâa, Maram Alajlan, Basit Qureshi

application that interacts with ROSLink to command and monitor ROS-enabled

robots.
In summary, ROSLink differs from previous works, and in particular from
ROSBridge in these aspects:
– ROSLink implements a client in the robot as well as in the user applications,
and implements a server in an intermediate proxy, whereas ROSBridge im-
plements a Websocket server in the robot and Websocket clients in user
applications.
– ROSBridge is based on the Websocket protocol, whereas ROSLink can be
implemented with any transport layer protocol (TCP, UDP and Websock-
ets). In this paper, we used UDP and Websockets interfaces to implement
ROSLink.
– ROSLink does not rely on ROSBridge as in previous works but defines its
own communication protocol between ROS and non-ROS users.

3 The ROSLink Protocol

In what follows, we present an overview of system and software architecture.

3.1 ROSLink System Architecture

The general architecture of ROSLink is presented in Fig 2.

ROSLink
Cloud

ROSLink ROSLink ROSLink

Client Proxy Bridge
Control,
ROSLink
Monitor ROS
Cloud
App
drivers

Robot HW

Fig. 2: ROSLink Architecture

The system is composed of three main parts:

 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 7

– The ROSLink Bridge: this is the main component of the system. It is the
interface between ROS and the ROSLink protocol. This bridge has two main
functionalities: (1) it reads data from messages of ROS topics and services,
serializes the data in JSON format according to ROSLink protocol specifi-
cation, and sends to a ground station, a proxy server or a client application,
(2) receives JSON serialized data through a network interface from a ground
station or a client application, deserializes it from the JSON string, parse
the command, and executes it through ROS.
– The ROSLink Proxy and Cloud: it acts as a proxy server between the
ROSLink Bridge (embedded in the robot) and the user client application.
Its role is to link a user client application to a ROS-enabled robot through
its ROSLink Bridge. The ROSLink proxy is mainly a forwarder of ROSLink
messages between the robot and user. It allows to keep the user updated with
the robot status, and also forward control commands from the user to the
robot. In addition ROSProxy interact with ROSLink Cloud component, to
maintain and manages the list of robots and users, create a mapping between
them, and perform all management functionality, including security, quality-
of-service monitoring, etc.
– The ROSLink Client Application: it basically represents a control and
monitoring application of the robot. This application is intended to monitor
the status of the robot that it receives through ROSLink messages via the
ROSLink Proxy from the robot. In addition, it sends commands through
ROSLink messages to control the robot activities.

3.2 ROSLink Communication Protocol

We designed the ROSLink communication protocol to allow interaction be-

tween the different parts of the ROSLink system, namely the ROSLink Bridge,
ROSLink Proxy and the ROSLink Client application.
The ROSLink communication protocol is based on two main things: (1) The
transport protocol to use to communicate between the users, clouds and robots.
(2) the message specification and its serialization in JSON format

Transport Protocol ROSLink Bridge, ROSLink Proxy and ROSLink Client

all of them use a network interface to communicate. There are different options
for the transport protocol, which include UDP, TCP and Websockets. Commu-
nication through Serial port and telemtry devices is not considered as we only
aim at a communication pattern through the Internet.
In our ROSLink implementation, we considered both UDP and Websockets
transport protocols. The ROSLink Proxy implements both UDP and Websockets
servers providing different interfaces for robots and users to interact with it. On
the other hand, ROSLink Bridge and ROSLink Client can implement either
protocol UDP, or Websockets clients or both together that interact with the
ROSLink Proxy server. This gives enough flexibility to the developer to choose
the most appropriate transport protocol for his application. On the one hand, we
8 Anis Koubâa, Maram Alajlan, Basit Qureshi

opted for the UDP connection because it is better and lighter weight choice for
real-time and loss-tolerant streaming applications as compared to TCP, as it is
the case with ROSLink data exchange model. In fact, the robot will be streaming
its internal status (e.g. position, odomtery, velocities, etc.) in real-time to the
proxy server, which will deliver it to the ROSLink client application. On the
other hand, the Websockets interface also provide an idea protocol for more
reliable transport of data streams as compared to UDP, while meeting real-time
requirements. In fact, Websockets is a connection-based protocol that opens the
connections between the two communicating ends before data exchanges, and
ensure connection to remain open all along the message exchange sessions. The
connection is closed when any of the two ends terminate the sessions, which
make it more reliable. It is also possible to think of using a TCP connection for
better reliability of transfer, but in our context, the lost of data occasionally is
not that critical. It might be critical in case of closed-control loop applications,
which is out of our scope at this stage.

ROSLink Message Types The ROSLink communication protocol is based

on the exchange of ROSLink messages. ROSLink messages are JSON formatted
strings that contain information about the command and its parameters. To
standardize the type of messages exchanged, we specified a set of ROSLink mes-
sages that are supported by the ROSLink Proxy. These message can be easily
extended based on the requirements of the user and the application. There are
two main categories of ROSLink messages: (i.) State messages: these are mes-
sage sent by the robot and carry out information about the internal state of
the robot, including its position, orientation, battery level, etc. (ii.) Command
messages: these are messages sent by the client application to the robot and
carry out commands to make the robot execute some actions, like for example
moving, executing a mission, going to a goal location, etc. In what follows, we
identify an example of messages and command types:
– Presence message: the robot should declare its presence regularly to de-
clare itself and to be considered as active. Typically, Heartbeat messages
sent at a certain frequency (typically one message per second) are used for
this purpose.
– Motion messages: In robot mission, it is important to know the location
and odometry motion parameters (i.e.linear and angular velocities) of the
robot at a certain time. Thus, a motion message containing position infor-
mation of the robot should be periodically broadcast.
– Sensor messages: The robot needs to broadcast its internal sensor data
such as IMU, laser scanners, camera images, GPS coordinates, actuators
states, etc. ROSLink also defines several sensor messages to exchange these
data between the robot and the user.
– Motion commands: For the robot to navigate in ROS, certain commands
are sent to it like Twist messages in ROS, goal/waypoint locations, and
takeoff/landing command for drones. ROSLink also specifies different types
of commands to make the robot moves as desired.
 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 9

The aforementioned list is not exhaustive as other types of messages can be

designed based on the requirements of the users and available information from
the robot. In what follows, we present the ROSLink message structures for the
main state messages and commands.

ROSLink Message Structure A ROSLink message is a composed of a header

and a payload. The structure of the ROSLink message header is presented in
Figure 3.

roslink_version ros_version system_id message_id key

(8 bits) (8 bits) (16 bits) (8 bits) (24 bits)
sequence_number
(64 bits)

Payload

Fig. 3: ROSLink Message Header Structure

ROSLink Message Header : The total header size is 128 bits. The roslink version
is encoded as a short int on 8 bits and specifies the version of ROSLink protocol.
This is because in the future, new ROSLink versions would be released and it
is important to specify which version a message belongs to for correct parsing.
The ros version specifies the ROS version (e.g. Indigo). The system id is an
int encoded into 16 bits and specifies the ID of the robot. It helps in differen-
tiating robots from each other at the server side. It is possible to encode the
system id in 8 bits to reduce the header size, but the problem this restricts the
scalability of the system to only 256 robots ID. The message id specifies the
type of message received. It helps in correctly parsing the incoming message and
extract underlying information. The sequence number denotes the sequence of
the packet, identifies a single packet, and avoid processing duplicate packets.
Finally, the key field is encoded on 24 bits and is used to identify a robot, and
to map it to a user. A user that would like to have access to a robot, must use
the same key that the robot is using in its Heartbeat message.
ROSLink Message Payload : The payload carries out data relevant for
each ROSLink message type. ROSLink defines several state message and com-
mand types. In what follows, we give an overview of the most common state and
command messages. For a complete set of messages, the reader may refer to [16].
The most basic ROSLink message is the Heartbeat message, which is sent
periodically from the robot to the ROSLink proxy server, and vice-versa. Every
ROSLink Bridge should implement the periodic transmission of the Heartbeat
message. The objective of the Heartbeat message is for the proxy server to
ensure that the robot is active and connected, upon reception of that message.
In the same way, a robot that receives a Heartbeat message from the ROSLink
10 Anis Koubâa, Maram Alajlan, Basit Qureshi

Proxy server ensures that the server is alive. This message increases the reliability
of the system when it uses a UDP connectionless protocol, such that both ends
make sure of the activity of the other end. Failsafe operations can be designed
when the robot loses reception of Heartbeat messages from the user such as
stopping motion or returning to start location until connectivity is resumed.
The Heartbeat message structure is defined in JSON representation in List-
ing 1.1. In the ROSlink protocol, the message id of the Heatbeat message is set
to zero.

Listing 1.1: Heartbeat Message Structure

{ " roslink_version " : int 8 ,
" ros_version " : int 8 ,
" system_id " : int 1 6 ,
" message_id " : 0 ,
" sequence_number " : int 6 4 ,
" payload " : { " type " : int 8
" name " : String ,
" system_status " : int 8 ,
" owner_id " : String ,
" mode " : int 8 }
}

The Robot Status message contains the general system state, like which
onboard controllers and sensors are present and enabled in addition to informa-
tion related to the battery state. Listing 1.2 presents the Robot Status message
structure, which has a message id equal to 1.

Listing 1.2: Robot Status Message Structure

{ " roslink_version " : int 8 ,
" ros_version " : int 8 ,
" system_id " : int 1 6 ,
" message_id " : 1 ,
" sequence_number " : int 6 4 ,
" payload " : { " o n b o a r d _ c o n t r o l _ s e n s o r s _ p r e s e n t " : uint 3 2 ,
" o n b o a r d _ c o n t r o l _ s e n s o r s _ e n a b l e d " : uint 3 2 ,
" voltage_battery " : uint 1 6 ,
" current_battery " : int 1 6 ,
" battery_remaining " : int 8 , }
}

The Global motion message represents the position of the robot and its
linear and angular velocities. This information is sent to the ROSLink client at
high frequency to keep track of robot motion state in real-time. An instance of
the Global motion message structure is expressed in Listing 1.3:
 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 11

Listing 1.3: Global Motion Message Structure

{ " roslink_version " : int 8 ,
" ros_version " : int 8 ,
" system_id " : int 1 6 ,
" message_id " : int 8 ,
" sequence_number " : int 6 4 ,
" payload " : { " time_boot_ms " : uint 3 2
" x " : float 6 4 ,
" y " : float 6 4 ,
" z " : float 6 4 ,
" vx " : float 6 4 ,
" vy " : float 6 4 ,
" vz " : float 6 4 ,
" wx " : float 6 4 ,
" wy " : float 6 4 ,
" wz " : float 6 4 ,
" pitch " : float 6 4 ,
" roll " : float 6 4 ,
" yaw " : float 6 4 , }
}

Listing 1.4 presents the Range Finder Data message, which carries out
information and data about laser scanners attached to the robot. The Range
Finder Data sensor information enables to develop control application on the
client through the cloud, such as obstacle avoidance reactive navigation, SLAM,
etc.

Listing 1.4: Range Finder Data Message Structure

{ " roslink_version " : int 8 ,
" ros_version " : int 8 ,
" system_id " : int 1 6 ,
" message_id " : int 8 ,
" sequence_number " : int 6 4 ,
" payload " : { " time_usec " : int 6 4
" angle_min " : float 3 2 ,
" angle_max " : float 3 2 ,
" angle_increment " : float 3 2 ,
" time_increment " : float 3 2 ,
" scan_time " : float 3 2 ,
" range_min " : float 3 2 ,
" range_max " : float 3 2 ,
" ranges " : float 3 2 [ ] ,
" intensities " : float 3 2 [ ] , }
}

The following Listings present a few examples on command messages that

can be sent from the ROSLink client application to the robot through the cloud.
12 Anis Koubâa, Maram Alajlan, Basit Qureshi

The most basic command message is the Twist command message, which con-
trols the linear and angular velocities of the robot, and ins illustrated in Listing
1.5. This ROSLink Twist message maps directly with the Twist message defined
in ROS. Once the ROSLink Twist command reaches the ROSLink Bridge, it is
first deserialized from the JSON wrapper, then extract velocity commands and
publishes them as a ROS Twist message to make the robot move.

Listing 1.5: Twist Command Message Structure

{ " roslink_version " : int 8 ,
" ros_version " : int 8 ,
" system_id " : int 1 6 ,
" message_id " : int 8 ,
" sequence_number " : int 6 4 ,
" payload " : { " lx " : float ,
" ly " : float ,
" lz " : float ,
" ax " : float ,
" ay " : float ,
" az " : float , }
}

To stop the robot, it simply requires to send a Twist command message with
all velocities set to zeros. In the same way, the Go to Waypoint command
message defines a command to send the robot to a specific goal location. The
parameters x, y and z represent the 3D coordinates of the goal location. The
frame type field represents the world frame if it is set to true, and the robot
frame is it is set to false.

Listing 1.6: Go-To-Wayoint Command Message Structure

{ " roslink_version " : int 8 ,
" ros_version " : int 8 ,
" system_id " : int 1 6 ,
" message_id " : int 8 ,
" sequence_number " : int 6 4 ,
" payload " : { " frame_type " : boolean ,
" x " : float ,
" y " : float ,
" z " : float , }
}

Several other commands and state messages were also defined like the takeof-
f/land command messages in the context of drones, and the GPS state message
that provides information of the GPS sensor, etc.
 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 13

3.3 Integration of ROSLink Proxy in Dronemap Planner

As mentioned in Section 3.1, ROSLinkProxy is responsible for map users to

robots, manages them, and control the access of users to robots. We integrated
ROSLink Proxy into the Dronemap Planner cloud application [17]. Dronemap
Planner is modular service-oriented cloud based system that was originally de-
veloped for the management of MAVLink drones and to provide seamless access
to them through the Internet.
The software architecture of Dronemap Planner defines a proxy layer in-
terface that allow to mediate between robots and users. In [17], this proxy
interface was implemented as a MAXProxy component that mediates between
MAVLink drones and users. As such Dronemap Planner is a comprehensive sys-
tem that allow to control both MAVLink and ROSLink robots simultaneously.
Video demonstrations of Dronemap Planner related to control of drones over the
Internet are available in [18].
We extended Dronemap Planner to also support the ROSLink protocol by im-
plementing the proxy layer interface as ROSLinkProxy that allows the exchanges
of ROSLink messages between ROS-enabled robots and their users. Dronemap
Planner provides a comprehensive system for drones and users management, and
session handling. In addition, Dronemap Planner provides both Websockets and
UDP sockets network interfaces for ROSLink robots and users.
We have used Dronemap Planner to run experiments related to the perfor-
mance evaluation of ROSLink in controlling and monitoring ROS-enabled robots
through the Internet, in Section 4.

4 Experimental validation

In this section, we present an experimental study to demonstrate the effectiveness

of ROSLink and to assess its impact on real-time open-loop control applications.
We investigate the impact of network and cloud delays on the performance of
open-loop control applications of ROS-enabled robots. With open-loop control,
the commands are sent to the robot without the need for any feedback from the
robot. The problem can be formulated as follows:”If the control application is
offloaded from the robot to the ROSLink client, what is the impact of network
and cloud processing delays on the performance of the control? ”

Trajectory Control Application To address this question, we consider a pro-

totype open-loop control application of the motion of Turtesim robot (default
simulator in ROS) to follow a spiral trajectory. We have chosen a spiral trajec-
tory motion control application because the resulting trajectory is sensitive to
delays and jitters. A spiral trajectory is defined by a combination of an increasing
linear velocity over time and a constant angular velocity. The general algorithm
for drawing a spiral trajectory is presented in the following listing:
14 Anis Koubâa, Maram Alajlan, Basit Qureshi

Listing 1.7: Spiral Trajectory Motion Control Algorithm

d o u b l e c o n s t a n t _ a n g u l a r _ s p e e d=A N G U L A R _ S P E E D _ C O N S T A N T ;
double linear_velocity_step = LINEAR_STEP_CONSTANT ;
double time = SIMULATION_TIME_CONSTANT ;
double rate = FREQUENCY_OF_UPDATE_CONSTANT
i n t number_of_iterations = ( i n t ) ( time ∗ rate ) ;
double linear_velocity = _INIT_LINEAR_VELOCITY ;

f o r ( i n t i =0; i<n u m b e r _ o f _ i t e r a t i o n s ; i++){

l i n e a r _ v e l o c i t y=l i n e a r _ v e l o c i t y+l i n e a r _ v e l o c i t y _ s t e p ;
a n g u l a r _ s p e e d =c o n s t a n t _ s p e e d ;
send_velocity_command ( linear_velocity , angular_speed ) ;
sleep (1/ rate ) ;
}

We implemented this algorithm in both the ROSLink Control Application

in the client side, as well as on-board of the robot using ROS. The objective is
to qualitatively and quantitatively compare the resulting trajectories executed
on-board using ROS against the ones produced by ROSLink Control application
through the Dronemap Planner cloud.

Experimental Set-up We consider a spiral trajectory generation through the

transmission of Twist messages where linear and angular velocities follow the
algorithms in Listing 1.7.
We analyzed the impact of networks and cloud processing delays on the
generated spiral trajectories with varying the linear velocity steps, and also the
discrete time granularity captured by the update rate variable in Listing 1.7.
Using ROS, Twist velocity commands are directly published from a ROS
script running on the same machine of the robot ROS Master. When using
ROSLink, Twist velocity commands are sent in ROSLink Twist messages to the
Dronemap Planner cloud, which forwards them to the ROSLink Bridge which is
running on the robot. Finally the Twist ROSLink command is converted into a
ROS Twist messages published on the velocity topic.

Qualitative Analysis Figure 4 presents the generated spiral trajectories using

open-loop motion control for both ROS and ROSLink. The spiral corresponds
to a rate frequency equal to 2 Hz, an initial velocity of 1.0, a constant angular
velocity equal to 4.0 and a linear step equal to 0.05 and 0.13. A first observation is
that these spiral trajectories are visually correlated and follow a similar pattern
based on the linear speed incremental steps. However, it can be observed that
the spiral generated by ROSLink client control commands has more curves than
the trajectory generated by Twist control command published directly from
ROS. This becomes more contrasted when the velocity step increases. The main
reasons behind this behavior are both delays and jitters. The delay variation
observed with ROSLink are induced by the network and cloud processing results
in updating the linear velocity at different instances than with ROS.

Quantitative/Statistical Analysis Figure 5 depicts the box plot of the jit-

ters for four scenarios, namely, (i) using ROS onboard, (ii) using ROSLink when
 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 15

a.) ROS [step=0.05] b.) ROSLink [step=0.05]

c.) ROS [step=0.13] d.) ROSLink [step=0.13]

Fig. 4: ROS and ROSLink Spiral Generated Trajectories

the cloud server is located in the same localhost as ROS (ROSLinkLH), (iii)
two scenarios with ROSLink (ROSLinkCL1 and ROSLinkCL2) where the cloud
server is located on the DreamCompute cloud instance machine, while being ac-
cessed from two different networks. Table I presents the average values, standard
deviations and coefficient of variations for the jitter.
The ROSLinkLH scenario allows to investigate the impact of cloud processing
without networking delays as ROS and ROSLink are in the same machine. On the
other hand, ROSLinkCL1 and ROSLinkCL2 capture the impacts of both cloud
processing and networking over the Internet. As anticipated, in the presence of
the jitter, ROS is much stable compared with ROSLink scenarios. In fact, the
average jitters with ROSLink scenarios are around 1000 times larger compared
to ROS, as can be observed in Table I. This provides an explanation for the
discrepancies between the two spiral trajectories. However, the jitters remain
in order of tens of microseconds, which is acceptable and provides no threat of
compromising the real-time control of the robot through the cloud. Furthermore,
16 Anis Koubâa, Maram Alajlan, Basit Qureshi

Jitter (Seconds)

0.03

0.02

0.01

-0.01

-0.02

-0.03

ROS ROSLinkLH ROSLinkCL1 ROSLinkCL2

Fig. 5: ROS and ROSLink Spiral Generated Trajectories

we observe that the network has an additional impact to the cloud processing on
the jitter, when comparing the jitter of ROSLink cloud server when deployed on
Localhost, against ROSLink cloud server which is deployed over the Internet. The
unpredictable network delays on the communication channel contribute naturally
to a larger jitter. Results shown in Table 1 confirm this observation, where the
standard deviation of coefficient of variation reach upwards of up to 5 to 6 six
times increase in case of the Internet deployment of the ROSLink cloud.

Table 1: Effect of Jitter on various ROSLink deployments

Average StdDev Coeff Var
ROS 3.5274e-06 3.1892e-04 90.4110
ROSLinkLH 0.0031 0.0016 0.5206
ROSLinkCL1 0.0035 0.0044 1.2684
ROSLinkCL2 0.0044 0.0122 2.7605

It must be noted that although these jitters exist, they do not compromise
the quality of control and similarity of trajectories. To verify the similarity and
correlation between the generated trajectories, we applied chi-square test sta-
tistical method for assessing the goodness of fit between the time series of the
 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 17

trajectories at a significance level of 5%. It has been found that all trajectories
are correlated based on the chi-square goodness of fit.
The results presented here illustrate the effectiveness of robot control through
the cloud with reasonable real-time constraints. The quality of control could be
improved using a feedback-control, which we will investigate further in future
work. In addition, ROSLink could also be effectively used for request-response
communication pattern between the client and the robot by for example using it
to send goal points to be executed by the ROS navigation services of the robot.

5 Related Work

Over the past few years the robotics community has made quite a few forays
into using robots over the Internet Earlier contributions in remote access and
control of the robots over the Internet were made by on-line robotics labs. The
remote robotics labs allows users to address research and engineering problems
in physical laboratories which are made available over the Internet Examples of
such labs include the UWA Telerobot [19], UJI on-line robot [20], Lego robots
lab [5], PR2 Remote Lab [6] among many others. Previous endeavors focused
on executing simple experiments remotely supporting on-line learning but did
not address shared control of remote robots through middle-ware The PR2 Lab
[6] introduced a middle-ware that allows developing web based robots appli-
cations using the open-source Robot Web Tools (RWT) [14] interfacing robots
running the ROS. Further works in developing and using middle-ware involving
web accessibility of ROS based applications includes Robotic Programming Net-
work (RPN) presented in [7], which allows users to execute programs through
a client in a browser window using python. While RPN is a viable solution for
remote learning, users of the system need to be familiar with ROS packages and
programming interfaces which could be complex for new learners.
Esteller-Curto in [8] provide a REST-based architecture server to control a
ROS enabled robot using the client server approach where the robot executes
the client application connecting to the server. The communication between the
client and the server is done using HTTP headers and in XML. Although an
implementation is provided, the work lacks a high level architecture to store in-
formation from various clients so as to avoid collision at the server. The DAvinCi
project presented in [9] introduced a cloud robotics framework that allows mul-
tiple client applications executing on ROS enabled robots to communicate to the
DAvinCi server over the Internet The server maintains the state of collabora-
tive work completed by the clients. For large number of clients, the intermediate
server can be exposed to network congestion thus needing further work in re-
liability and scalability of the service. This project provided a foray extending
the robot-to-robot communications over the Internet to the cloud based robotics
middle-ware. Narita et.al. in [10] present a reliable cloud based robot services
platform extending their earlier work on Robot Service Network Protocol. The
suggested protocol adopts push communication and a reliable messaging mech-
anism in order to perform reliable communication on robot services based on
18 Anis Koubâa, Maram Alajlan, Basit Qureshi

web service technologies. Authors in [14] present rosjs, a Javascript library for
ROS, that allows developers to expose robot functionality as web services. The
rosjs allows developers to create robot applications that can be used in the web
browser and extends ROS to provide security and data logging mechanisms.
The ROSBridge protocol in [11] uses a Websockets server installed on the
robot side that allows to send the internal status of the robot based on ROS
topics and services and receives commands to Websockets clients to process
them. This approach enabled the effective integration of ROS with the Internet;
however, the fact that the Websockets server is running on the robot machine
requires the robot to have a public IP address to be accessible by Websockets
clients, which may not be possible for all robots. In [12], the author proposed
ROS-as-a-web-service which allows to define a Web service server in the robot
to access through the Internet. However, this solution share the same limitation
as ROSBridge as the server is located at the robot side.

6 Conclusion

In this chapter, we proposed, ROSLink, a novel communication protocol to inte-

grate ROS-enabled robots with the Internet-of-Things for cloud robotics. We de-
signed and developed ROSLink protocol that allows to access any ROS-enabled
robot through the Internet. We have specified the message set of the protocol
and used JSON serialization between the different ends of the system. ROSLink
performance was tested on the cloud on Internet and was shown to be efficient
and reliable for controlling robots through the cloud.
It can be noticed from the chapter outcomes that ROSLink is a lightweight
and effective solution to integrate ROS-enabled robots with the Internet of
Things. Having the server implemented into a publicly accessible cloud makes it
possible to map any robot to any user in a seamless fashion through the Internet.
There is no need for NAT translation as in solutions based on a robot-side server,
like ROSBridge and others. Furthermore, the high-speed connections available to-
day’s Internet and sufficient bandwidth is an enabling factor for providing high
quality of services for applications deployed with ROSLink. In fact, ROSLink
has a lightweight overhead (including both header and payload size) and thus it
does not consume much bandwidth over the network, which makes it scalable.
The evaluation study discussed the impact of network on the performance for
different networks’ configurations.
We are currently working on extending the performance evaluation study for
considering the closed loop control, namely with a PID controller for altitude
and position control of a drone over ROSLink. We also aim at improving the
security measures of ROSLink by using authentication and encryption of message
to prevent possible attacks like impersonation and authorized access to robots.
 ROSLink: Bridging ROS with the Internet-of-Things for Cloud Robotics 19

Acknowledgments

This work is supported by the Dronemap project entitled “DroneMap: A Cloud

Robotics System for Unmanned Aerial Vehicles in Surveillance Applications”
under the grant number 35-157 from King Abdul Aziz City for Science and
Technology (KACST), and supported by Prince Sultan University.
In addition, the authors would like to thank the Robotics and Internet of
Things (RIoT) Unit at Prince Sultan University’s Innovation Center for their
support to this work.

References
1. J. Kuffner, “Cloud-enabled robots,” in IEEE-RAS International Conference on
Humanoid Robots. IEEE, 2010.
2. R. Chaari, F. Ellouze, A. Koubaa, B. Qureshi, N. Pereira, H. Youssef, and
E. Tovar, “Cyber-physical systems clouds: A survey,” Computer Networks, vol.
108, pp. 260 – 278, 2016. [Online]. Available: http://www.sciencedirect.com/
science/article/pii/S1389128616302699
3. B. Qureshi and A. Koubaa, “Five traits of performance enhancement using
cloud robotics: A survey,” Procedia Computer Science, vol. 37, pp. 220 –
227, 2014. [Online]. Available: http://www.sciencedirect.com/science/article/pii/
S1877050914009983
4. M. Quigley, K. Conley, B. P. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and
A. Y. Ng, “Ros: an open-source robot operating system,” in ICRA Workshop on
Open Source Software, 2009.
5. M. Casini, A. Garulli, A. Giannitrapani, and A. Vicino, “A remote lab for experi-
ments with a team of mobile robots,” Sensors, pp. 16 486–16 507, 2014.
6. B. Pitzer, S. Osentoski, G. Jay, C. Crick, and O. C. Jenkins, “Pr2 remote lab: An
environment for remote development and experimentation,” in IEEE International
Conference on Robotics and Automation (ICRA),, 2012.
7. G. A. Casañ, E. Cervera, A. A. Moughlbay, J. Alemany, and P. Martinet, “Ros-
based online robot programming for remote education and training,,” in 2015 IEEE
International Conference on Robotics and Automation (ICRA), May 2015, pp.
6101–6106.
8. R. Esteller-Curto, E. Cervera, A. P. del Pobil, and R. Marin, “Proposal of a rest-
based architecture server to control a robot,” in 2012 Sixth International Confer-
ence on Innovative Mobile and Internet Services in Ubiquitous Computing, July
2012, pp. 708–710.
9. R. Arumugam, V. R. Enti, L. Bingbing, W. Xiaojun, K. Baskaran, F. F. Kong,
A. S. Kumar, K. D. Meng, and G. W. Kit, “Davinci: A cloud computing frame-
work for service robots,” in 2010 IEEE International Conference on Robotics and
Automation, May 2010, pp. 3084–3089.
10. M. Narita, S. Okabe, Y. Kato, Y. Murakwa, K. Okabayashi, and S. Kanda, “Reli-
able cloud-based robot services,” in 39th Annual Conference of the IEEE Industrial
Electronics Society,, 2013.
11. C. Crick, G. T. Jay, S. Osentoski, B. Pitzer, and O. C. Jenkins, “rosbridge: ROS for
Non-ROS Users,” in International Symposium on Robotics Research (ISRR 2011),
Flagstaff, AZ, USA, August 2011.
 20 Anis Koubâa, Maram Alajlan, Basit Qureshi

12. A. Koubâa, “ROS As a Service: Web Services for Robot Operating System,” Jour-
nal of Software Engineering for Robotics, vol. 6, no. 1, 2015.
13. “MAVLink Micro Air Vehicle Communication Protocol,”
http://qgroundcontrol.org/mavlink/start, accessed: 2016-8-7.
14. S. Osentoski, G. Jay, C. Crick, B. Pitzer, C. DuHadway, and O. C. Jenkins, “Robots
as web services: Reproducible experimentation and application development us-
ing rosjs,” in 2011 IEEE International Conference on Robotics and Automation
(ICRA), May 2011, pp. 6078–6083.
15. The JSON Data Interchange Format, First edition ed. ECMA International, Oc-
tober 2013. [Online]. Available: http://www.ecma-international.org/publications/
files/ECMA-ST/ECMA-404.pdf
16. “ROSLink Message Specification Set,” http://wiki.coins-
lab.org/roslink/ROSLINKCommonMessageSet.pdf, accessed: 2016-10-22.
17. A. Koubaa, B. Qureshi, M.-F. Sriti, Y. Javed, and E. Tovar, “Dronemap planner:
A service-oriented cloud-based management system for the internet-of-drones,” in
The 32nd ACM Symposium on Applied Computing, 2016.
18. “Dronemap Planner Demos,” http://wiki.coins-
lab.org/index.php?title=Dronemap, accessed: 2016-11-6.
19. “Telerobot,” http://telerobot.mech.uwa.edu.au/Telerobot/index.html, accessed:
2016-5-10.
20. R. Marı́n, P. Sanz, and A. del Pobil, “The uji online robot: An education and
training experience,” Autonomous Robots, vol. 15, no. 3, pp. 283–297, 2003.
[Online]. Available: http://dx.doi.org/10.1023/A:1026220621431

View publication stats