Rosbridge: ROS for Non-ROS Users
Christopher Crick, Graylin Jay, Sarah Osentosiki, Benjamin Pitzer,
and Odest Chadwicke Jenkins
Abstract We present rosbridge, a middleware abstraction layer which provides
robotics technology with a standard, minimalist applications development frame-
work accessible to applications programmers who are not themselves roboticists.
Rosbridge provides a simple, socket-based programmatic access to robot interfaces
and algorithms provided (for now) by ROS, the open-source “Robot Operating Sys-
tem”, the current state-of-the-art in robot middleware. In particular, it facilitates the
use of web technologies such as Javascript for the purpose of broadening the use
and usefulness of robotic technology. We demonstrate potential applications in the
interface design, education, human-robot interaction and remote laboratory environ-
ments.
1 INTRODUCTION
At present, we are at the cusp of a revolution in robotics. For most of the field’s
history, scientific progress has been hindered by the fact that to have a robot meant
investing a great deal in its mechanical engineering and low-level control systems.
The result being that every researcher had a different system with different capa-
Christopher Crick
Brown University, Providence RI, e-mail: chriscrick@cs.brown.edu
Graylin Jay
Brown University, Providence RI, e-mail: tjay@cs.brown.edu
Sarah Osentoski
Robert Bosch LLC, Mountain View CA, e-mail: sarah.osentoski@us.bosch.com
Benjamin Pitzer
Robert Bosch LLC, Mountain View CA, e-mail: benjamin.pitzer@us.bosch.com
Odest Chadwicke Jenkins
Brown University, Providence RI, e-mail: cjenkins@cs.brown.edu
1
2 Christopher Crick et al.
bilities. Furthermore, robots were extremely expensive, both in terms of money and
researchers’ time. Only very well-funded laboratories could have a robot, and the
scope of the robot’s activity was constrained by the resources, research focus and
imagination of the scientists and engineers that created it.
The emergence of widely-available common robot architectures promises to mit-
igate the “silo effect” that has heretofore lessened the impact and wider application
of research contributions within robotics. Furthermore, developments in robot mid-
dleware have begun to create the software engineering infrastructure vital to foster-
ing interoperability and code reuse, a necessary prerequisite to the use of robots on
a large scale.
However, the current state of robot middleware is such that users and develop-
ers must make a heavy ontological commitment to a particular environment and
philosophy in order to use it to its full effect. Furthermore, middleware designers
have (perhaps by necessity) assumed that users of their systems would be roboti-
cists themselves, well-versed in the low-level systems programming and complex
control and decision algorithms which have always been a part of robotics research.
We developed rosbridge to expose these systems to the much wider world of general
applications developers, with the hope of unleashing for the first time a “web-scale”
revolution in robot availability and accessibility.
2 BACKGROUND
Several robot middleware system have been proposed to enable code sharing among
roboticists. These middleware systems include Player/Stage [8], the Carnegie Mel-
lon Navigation Toolkit (CARMEN) [24], Microsoft Robotics Studio [13], YARP
[17], Lightweight Communications and Marshalling (LCM) [12], and ROS [20], as
well as other systems [14]. These middleware systems provide common interfaces
that allow code sharing and reuse. While middleware systems differ in their design
and features, they typically provide a communication mechanism, an API for pre-
ferred languages, and a mechanism for sharing code through libraries or drivers.
Middleware systems typically require developers to code within the middleware
framework, and often within a specified build environment.
At their heart, many of these middleware packages provide a messaging and mar-
shalling protocol between processes running on multiple machines connected in
some fashion to robotic hardware. The framework permits, say, a stereo camera to
deliver images to a stereo image processor, which in turn can send a depth map to an
object recognition routine, which then routes coordinates to an inverse-kinematics
driver, which sends motor commands to processes delivering voltages to individual
servos. In a complex robot architecture, the number of independent processes and
the information that interconnects them quickly becomes massive. Even so, deep
down, the system is merely serializing and routing messages, and rosbridge takes
advantage of this fact. By way of analogy, web applications have developed huge
and complex backends that span continents and perform breathtaking feats of traffic
Rosbridge: ROS for Non-ROS Users 3
analysis, shaping, routing, data acquisition and conglomeration, but still communi-
cate with browsers and each other over the HTTP protocol. Likewise, robots and
their controlling middleware can grow arbitrarily complex on the back end, but with
rosbridge they can communicate with an application layer over a single socket and
a plain-text protocol.
3 ROS
Rosbridge is designed to work initially within the paradigm established by the ROS
middleware system currently maintained by Willow Garage. ROS uses a peer-to-
peer networking topology; systems running ROS often consist of a number of pro-
cesses called nodes, possibly on different machines, that perform the system’s com-
putation. Nodes communicate with each other by passing messages. Under ROS,
messages are data structures made up of typed fields. Messages may be made up of
standard primitive data types, as well as arrays of primitives. Messages can include
arbitrarily nested structures and arrays.
Nodes can use two types of communication to send messages within the ROS
framework. The first is synchronous and is called a service. Services are much like
function calls in traditional programming languages. Services are defined by a string
name and a pair of messages: a request and a response. The response returns an
object which may be arbitrarily complex, ranging from a simple boolean indicating
success or failure to a large point cloud data structure. Only one node can provide a
service of a specific name.
The second type of communication is asynchronous and is called a topic. Topics
are streams of objects that are published by a node. Other nodes, “listeners”, may
subscribe by registering a handler function that is called whenever a new topic object
becomes available. Unlike services, listener nodes are unable to use their subscrip-
tion to the topic to communicate to the publisher. Multiple nodes may concurrently
publish and/or subscribe to the same topic and a single node may publish and/or
subscribe to multiple topics.
Unlike many other robot middleware systems, ROS is more than a set of libraries
that provide only a communication mechanism and protocol. Instead, nodes are de-
veloped within a build system provided by ROS. The intent is that a system running
ROS should be comprised of many independent modules. The build system is built
on top of CMake [16], which performs modular builds of both nodes and the mes-
sages passed between them.
Furthermore, ROS has assimilated a number of tools, algorithms and systems
which can serve as a basis for complex robot control. Thus a full suite of ROS
packages provides vision processing algorithms [4], 3D point cloud interpretation
[21] and simultaneous localization and mapping (SLAM) [10], among many others.
This represents the largest effort to date to foster a robotics community that supports
code-sharing and building on the prior work of others. This alone serves as reason
for applying the rosbridge architecture to ROS initially.
4 Christopher Crick et al.
Fig. 1: Recreating traditional abstraction layers in robotics with rosbridge. As de-
picted at left, software development depends on well-established layers of abstrac-
tion. Developers and engineers working at each layer possess very different skill
sets, but the enterprise succeeds due to well-defined abstractions and interfaces. At
present, roboticists must deal with all of these layers at once, limited by both their
own skills and by the unwieldiness inherent in poorly-abstracted systems (center).
At right, rosbridge attempts to establish a more clear abstraction boundary to ad-
dress this problem.
4 ROSBRIDGE
Rosbridge provides an additional level of abstraction on top of ROS, as depicted
in Figure 1. Rosbridge treats all of ROS as a “back end”. This shields application
developers from needing intimate knowledge of low-level control interfaces, mid-
dleware build systems and sophisticated robotic sensing and control algorithms. At
a bare minimum they must understand the build and transportation mechanisms of
the middleware package. Rosbridge layers a simple socket serialization protocol
over all of this complexity, on top of which application developers of all levels of
experience can create applications.
ROS abstracts individual robot capabilities, allowing robots to be controlled
through messages. It also provides facilities for starting and stopping the individual
ROS nodes providing these capabilities. Rosbridge encapsulates these two aspects
of ROS, presenting to the user a unified view of a robot and its environment. The
Rosbridge protocol allows access to underlying ROS messages and services as seri-
alized JSON objects, and in addition provides control over ROS node execution and
environment parameters (Figure 2).
Rosbridge allows simple message handling over both HTML5 websockets and
standard POSIX IP sockets. For example, a simple Python client which handles
data being published on a ROS topic called “/sensorPacket” can be written, simply,
as
Rosbridge: ROS for Non-ROS Users 5
Fig. 2: Rosbridge serializes all applicable ROS topics and services over a single
socket interface.
host_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
host_sock.connect((host_address, host_port))
host_sock.send(’raw\r\n\r\n’)
host_sock.send(’\x00{"receiver":"/rosbridge/subscribe","msg":["/sensorPacket",0,]}\xff’)
while True:
incoming = source_socket.recv(1024)
#handle sensorPacket data
This paradigm can be exploited in any language that supports IP sockets, which
is to say, all of them. Thus rosbridge enables robot application development in a
user’s language of choice.
5 ROSJS
Computing paradigms have developed over the years, from batch systems to time-
shared mainframes to standalone desktops to client-server architectures to ubiqui-
tous web-based applications. Current technology allows transparent administration,
redundant storage, and instantaneous deployment of software running on wildly het-
erogenous platforms, from smartphones to multicore desktops. This relatively new
and extremely ecosystem has spawned a population of users who understand ba-
sic web technologies such as HTML and Javascript [1]. Familiarity with basic web
technologies extends beyond expert application developers to users who would not
necessarily call themselves programmers, but who nevertheless use the web for all
manner of creation and communication and are familiar with the basic technologies.
One of the goals of rosbridge is to broaden robotics to this vast untapped popula-
tion of writers, artists, students, and designers. Javascript has become the default
language of the web and as such is one of the most popular languages in the world.
We hope to leverage a small part of that popularity to open robotics to an entirely
