RCON: Dynamic Mobile Interfaces for Command and Control of

ROS-enabled Robots

Robert Codd-Downey and Michael Jenkin

Center for Field Robotics, Department of Electrical Engineering and Computer Science, York University,

4700 Keele Street, M3J 1P3, Toronto, Ontario, Canada

Keywords:

ROS, Human-robot Interaction, Teleoperation, iOS.

Abstract:

The development of effective user interfaces for an autonomous system can be quite difﬁcult, especially for

devices that are to be operated in the ﬁeld where access to standard computer platforms may be difﬁcult

or impossible. One approach in this type of environment is to utilize tablet or phone devices, which when

coupled with an appropriate tool such as ROSBridge can be used to connect with standard robot middleware.

This has proven to be a successful approach for devices with mature user interface requirements but may

require signiﬁcant software development for experimental systems. Here we describe RCON, a software tool

that allows user interfaces on iOS devices to be conﬁgured on the device itself, in real time, in response to

changes in the robot software infrastructure or the needs of the operator. The system is described in detail

along with the accompanying communication framework and the process of building a user interface for a

simple autonomous device.

1 INTRODUCTION

True autonomy does not usually exist in today’s com-

mercial and academic robots. Typically these sys-

tems are designed to take operational directives from

a human operator and communicate results back to

the operator in a meaningful way. This human robot

interaction problem is typically approached using a

ﬁxed point control station equipped with monitors

and haptic controllers (e.g., Joysticks, Mice). While

these control stations offer many beneﬁts they lack

the mobility necessary for high situational awareness

in extended range applications. A mobile operator

equipped with a portable device such as a laptop or

netbook offers this situational awareness on hardware

compatible with the target robot but commercial ver-

sions of such devices are not hardened for operations

outdoors. When considering the inclement weather

so often encountered with ﬁeld robotics the trade-

off between cumbersome equipment and environmen-

tal protection becomes apparent. Commercial off the

shelf mobile electronics such as iOS and Android de-

vices present an inexpensive alternative to custom en-

vironment and weather-hardened equipment. Protect-

ing these devices from the elements is inexpensive

and has a minimal affect on their portability. That

being said, these devices do not generally support the

traditional range of robot software development and

operational tools offered on laptop/netbook platforms.

The use of mobile devices for human robot in-

teraction has been actively explored in past. Pock-

etCERO (Httenrauch and Norman, 2001), one of the

ﬁrst forays into this area of research, was limited by

a lack of standardization across robotic platforms and

computational resources available on mobile devices

at the time. Implementations on more modern An-

droid devices such as, (Wu and Chen, 2004) have

demonstrated human robot interaction using a speciﬁc

hardware platform.

The acceptance of ROS (Quigley et al., 2009) as a

standard middleware for autonomous devices, at least

in the research domain, has simpliﬁed the develop-

ment of robot-user interaction substantively. Perhaps

the simplest method developing a human-ROS-based

robot interaction system on a tablet device would be

to deploy a full ﬂedged ROS installation on the tar-

get device. This would provide software developed

on the device access to the full ROS infrastructure.

Unfortunately, ROS’s primary development and de-

ployment environment is unix-based and this intro-

duces some difﬁculties when deploying ROS in non-

unix environments. ROSJava (2015) is a pure Java

implementation of ROS developed for just such a pur-

pose on the Android platform. On iOS there have

Codd-Downey R. and Jenkin M..

RCON: Dynamic Mobile Interfaces for Command and Control of ROS-enabled Robots.

DOI: 10.5220/0005540000660073

In Proceedings of the 12th International Conference on Informatics in Control, Automation and Robotics (ICINCO-2015), pages 66-73

ISBN: 978-989-758-123-6

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

been similar attempts such as ROSPod (2015) which

is still unstable and not a full-featured implementa-

tion. Even with a full underlying ROS infrastructure

to facilitate development on such devices there are a

number of other considerations. Android and iOS de-

vices are limited by available memory capacity, not to

mention processing power, and the overhead of an un-

derlying ROS implementation cuts into available re-

sources. Another consideration is the unreliability of

wireless communication. ROS assumes a high band-

width LAN connection between nodes and the mas-

ter. A user interface that augments the on-robot ROS

environment with user interface-based nodes on the

robot may have a substantive impact on robot per-

formance if communication becomes unstable. With

this in-mind a more prudent approach is to connect

to the ROS environment through other means. The

ROSBridge (Crick et al., 2011) library enables inter-

action with a ROS environment from external pro-

cesses. This interaction is facilitated through com-

mands in the form of JSON (Java Script Object Nota-

tion) strings (Crockford, 2006) . These commands are

mapped to internal ROS functions and enable external

processes to act as a ROS node operating within the

normal ROS environment.

This paper is organized into four major sections;

the ﬁrst reviews earlier efforts to link external user in-

teraction systems to ROS through ROSBridge. The

second describes the implementation in Objective-C

of a ROSBridge client framework that facilitates com-

munication with ROS. The third describes the imple-

mentation and functions of RCON which acts as an

interface builder on iOS devices. Finally, to illustrate

the effectiveness of the approach a sample UI is con-

structed and tested using an autonomous system.

2 PREVIOUS WORK

This paper outlines two important advancements from

those described in previous works. The ﬁrst is an iOS

implementation of an ROSBridge client library. The

second is the development of a ﬂexible robot-interface

creation tool that leverages this iOS library to enable

the construction of such user interfaces on the device

itself. This ﬂexibility would not be possible without

the capabilities offered by objective-c objects that en-

ables new class deﬁnitions to be created on-the-ﬂy.

In this paper we demonstrate how to leverage the

ROSBridge library to allow for the development of

a native interface on iOS devices to facilitate effec-

tive human-robot interaction. This strategy has been

used effectively in the past by Speers et al. (2013)

to create a ROSBridge client library for Android and

in Codd-Downey et al. (2014) for the Unity3D soft-

ware platform. These libraries can be used to de-

velop customized interfaces that interact with a target

robot. Such predeﬁned interfaces are very effective

on production robotic systems in which user-interface

requirements can be well speciﬁed in advance. How-

ever a majority of academic projects are experimen-

tal where the development of a customized interface

can be considered premature. This may also be true

for prototype robots in a commercial setting. Under

these circumstances maintaining a user interface that

keeps in stride with changes in the robot’s architecture

can be costly and time consuming. This motivates the

need for a dynamic interface that can be reconﬁgured

on the ﬂy based on the needs of the current operator.

Such an interface could be used for other purposes

that may not have been considered cost effective.

3 ROSBRIDGE iOS

FRAMEWORK

ROSBridge (Crick et al., 2011) facilitates communi-

cation between an external application and the ROS

environment. It exposes messages from the ROS en-

vironment to external software using JSON strings,

and allows an external agent to inject messages into

the ROS environment. In essence it allows an exter-

nal application to respond to and inﬂuence the ROS

environment without the overhead of a full ROS im-

plementation. The ROSBridge iOS framework lever-

ages this communication protocol to provide an iOS

application access to the ROS environment using na-

tive Objective-C constructs. Translating commands

to and from JSON strings and facilitating communi-

cation with the server is essential to providing a sim-

ple and comprehensible framework to developers. An

overview of this communication pathway is depicted

in Fig. 1, which also lists the full set of ROSBridge

commands supported by the iOS framework.

The motivation for choosing iOS as our develop-

ment platform in part is due to the support of na-

tive application development within iOS. This is to

be contrasted with the Android platform where appli-

cations are run within a virtual machine which adds

additional memory and processing overhead. iOS ap-

plications are written in Objective-C which is essen-

tially an object oriented framework built overtop C us-

ing a preprocessor and an extensive runtime environ-

ment. Leveraging this runtime environment, an iOS

application is afforded many of the capabilities avail-

able only to the compiler in many other languages.

These capabilities include but are not limited to; con-

structing and registering new class deﬁnitions, attach-

RCON:DynamicMobileInterfacesforCommandandControlofROS-enabledRobots

iOS

ROS

ROSBridge

Server

ROSNode Object ROSObject

ROSBridge

Client

JSON

advertise, unadvertise, publish

subscribe, unsubscribe, call_service,

advertise_service, unadvertise_serivce,

service_request, service_response

publish,

service_request, service_response

deserialization

serialization

Figure 1: Overview of the client communication pathway: The ROSBridge class handles all communication from the client

side. All incoming messages are serialized into a instance of a subclass of ROSObject and passed to the corresponding

ROSNode implementation. Outgoing messages and commands are serialized from an instance of a subclass of ROSObject

and compiled into a JSON string and sent to the ROSBridge server.

ing new methods and variables to a class and regis-

tering additional protocol deﬁnitions. These capabil-

ities make an excellent ﬁt for the requirements of a

dynamic user-interface framework.

3.1 Client Architecture

The client framework has a layout similar to that of

ROS (see Fig. 2). All processes that communicate

with the ROS environment via the client framework

implement the ROSNode protocol. This facilitates

bi-directional communication between a ROSNode

object and the ROSBridge client framework through

pair objects; a ROSObject, and a ROSInfo object. A

ROSObject carries information that has been dese-

rialized from either a message, response or request

from ROS. The accompanying ROSInfo object con-

tains both a name and a type and is used to identify

the speciﬁc topic or service which sent the data con-

tained within the ROSObject object.

ROSNode objects are registered with the main

ROSBridge class whenever they initiate a command

that necessitates a response. Each ROSNode is identi-

ﬁed using a globally unique string (similar to that of a

process and thread identiﬁer within ROS) which aids

message routing. ROSNodes have the ability to use

all functions within ROS’ publisher/subscriber frame-

work and request/response framework. The main

ROSBridge class also provides easy access to the

ROSAPI – the set of service calls provided by the

ROSBridge server – through a set of simple methods

and callbacks.

3.2 Mapping ROS Messages to Classes

Key to developing a user interface that interacts with

ROS is the structure of the relationship between ROS

messages and the software infrastructure within the

user interface itself. Incoming messages could be

dealt with using two different approaches: the ﬁrst

approach converts JSON strings to their generic ob-

ject counterparts (Dictionary, Array, String, Number),

the second approach converts JSON strings to the in-

stance of a predeﬁned class representing the message.

The beneﬁt of the ﬁrst approach is that message types

do not have to been known beforehand. Using prede-

ﬁned classes carries the beneﬁt of using literal syntax

and avoiding type casting. Mapping ROS messages

to predeﬁned classes is complicated because a JSON

object does not carry type information. Speers et al.

(2013) solved this problem by requiring all message

classes to be registered with the system, the corre-

sponding class is that which matches the layout of the

JSON Object. In their system new messages cannot

be added at runtime. The ﬂexibility of the Objective-

C runtime allows for both approaches to be taken si-

multaneously. Relying on a standard naming scheme

for message classes (e.g. /turtle1/cmd vel becomes

turtle1 cmd vel) an instance of the class can be cre-

ated at runtime assuming a corresponding deﬁnition

has been registered with the runtime environment by

the application executable. If the class is not regis-

tered a new class deﬁnition can be generated on the

ﬂy and registered with the runtime environment.

Traditionally Objective-C development required

that a developer actively manage memory within

the language’s reference counting framework. This

meant acquiring/releasing ownership of an object by

manually calling the objects retain/release methods to

increment and decrement the corresponding instance

reference count. In recent years there has been a push

in iOS software towards Automatic Reference Count-

ing (ARC) where the compiler adds these methods

automatically. Including ARC in a project allows a

developer to leave memory management to the com-

piler, which results in more time actively developing

and less memory related bugs. A major caveat in the

use of ARC is that the compiler forbids the use of a

dealloc, retain and release method. This is especially

problematic when constructing new class deﬁnitions

at runtime, as not implementing a dealloc method for

new classes results in catastrophic memory leakage.

Fortunately ARC can be disabled on select source

code ﬁles, however, best practices would dictate that

ﬁles compiled without ARC support be kept to an ab-

solute minimum. In our case all interaction with the

runtime environment is contained within the ROSOb-

ject class.

ICINCO2015-12thInternationalConferenceonInformaticsinControl,AutomationandRobotics

ROSBridge iOS Framework

ROSBridge

ROSTopicROSService

ROSObjectROSMessage

ROSServiceRequest

ROSServiceResponse ROSNode

0..*

ExampleNode

Figure 2: Overview of the client framework: The ROSBridge class handles all client side communication to and from the

server. All incoming messages are deserialized into ROSMessage objects and passed to the corresponding ROSNode imple-

mentation. Outgoing messages and commands are serialized into JSON strings and sent to the ROSBridge server.

4 RCON

RCON is an iOS application that is inspired by the

ROS tool rViz and aims to provide not only visualiza-

tion features, but command functions as well. RCON

provides a similar look and feel to rViz and enables

a user to construct and use a custom set of interface

elements (widgets) on-the-ﬂy. These widgets have ac-

cess to the full underlying structure of ROS messages

and can display information from a subscribed topic,

create data to publish on a topic, call an advertised

service or generate a response to a service.

RCON treats a set of user conﬁgured widgets as

a canvas. These canvases can be created, destroyed

and renamed. Changing from the active canvas to

another canvas automatically stops the operation of

the current set of widgets and starts the operation of

the widgets within the new canvas. Canvases afford

the user with the ability to create different interfaces

for different robots and tasks. A canvas be conﬁg-

ured by adding, removing, repositioning and resizing

its widgets. The views shown in Fig. 3 depict the

stages of adding widgets to the currently active can-

vas. The ﬁnal stage of the widget addition process in-

volves conﬁguring the per-widget settings that affect

its behaviour. For instance, a Stepper Widget requires

a minimum value, maximum value, step value and a

indicator of how often to send updates.

4.1 Available Widgets

Interaction with the ROS environment is facilitated

solely through the use of the predeﬁned widgets. Each

widget has its own set of customizable attributes that

deﬁne its behaviour. Additionally, each widget is only

capable of interacting with certain message types or

services. The widgets available with RCON include:

• Button - A button widget is used to call services

and can be conﬁgured to call separate services

upon being pressed and released.

• Label - A label widget displays raw data from

a large number of message and primitive types.

(Topic Subscriber only).

• Text Field - A text ﬁeld widget displays raw data

from a large number of messages and primitive

types, it can also be used to publish data to a topic,

if text is properly formatted.

• Switch - A switch widget can publish or sub-

scribe to a std msg/Bool message or bool primi-

tive types.

• Slider - A slider widget can publish or subscribe

to all standard number messages or types.

• Stepper - A stepper widget is capable of publish-

ing to all standard numerical messages and primi-

tive types.

• Image - An image widget displays data from sen-

sor msgs/Image, sensor msgs/CompressedImage

and is also capable of interpreting and

generating images from other mes-

sages (e.g., sensor msgs/LaserScan and

nav msgs/OccupanyGrid messages).

• Text View - A text view widget displays a large

scrollable text ﬁeld that remembers previous mes-

sages. Useful as either a publisher/subscribe of

string type messages (including ros graph/Log

messages).

• Map - A map widget displays the world map

showing visual GPS coordinate information and

can be used to both subscribe to and publish on

topics of type sensor msgs/NavSatFix.

RCON:DynamicMobileInterfacesforCommandandControlofROS-enabledRobots

Figure 3: Adding a widget to the current canvas can be initi-

ated through one of three pathways, selecting a target topic,

service or widget. After choosing a topic or service a user

is then displayed a list of compatible widgets. After select-

ing a widget it must then be conﬁgured using the widgets

settings panel. This settings panel displays a list of con-

ﬁgurable variables that can be used to modify the widgets

behaviour. Here the selected topic or service can be further

altered. When a widget has been properly conﬁgured it can

be dragged to the desired location on the canvas.

• Accelerometer - An accelerometer widget dis-

plays data from an accelerometer and publishes

this to a sensor msgs/Imu topic.

• Gyroscope - A gyroscope widget displays data

from a gyroscope and publishes this to a sen-

sor msgs/Imu topic.

• Magnetometer - A magnetometer widget dis-

plays data from a magnetometer and publishes

this to a sensor msgs/Imu topic.

• Camera - A camera widget displays images from

the onboard camera and can publish this image to

a sensor msgs/CompressedImage topic.

• Multi-Touch - A multi-touch widget displays

multitouch interactions from the user and pub-

lishes planar information using a variety of types

within geometry msgs.

• Compound - A compound widget can be con-

ﬁgured by grouping together other widgets to

form new messages, requests or responses. Using

this widget message or service types not previous

known to the application can be created.

Figure 4: An interface (canvas) within RCON can be modi-

ﬁed by adding/deleting widget or resizing (via a pinch ges-

ture) or repositioning (via a touch and drag). Canvases can

also be created, renamed and are hot swappable.

These widgets encompass a large percentage of

the standard user interface elements available within

iOS. Their capabilities as widgets stem from their

conﬁgurable attributes and visual interface within

iOS. For instance, the Stepper widget is not able to

function as a subscriber because its view (a plus and

a minus button) does not include feedback as to its

current value.

4.2 Use Cases

RCON makes it possible to create any type of user

interface one so desires. However, there is a particular

set of tasks for which RCON is expressly capable, as

described below.

Sensor Monitoring. Monitoring all sensors onboard

a robot can be a daunting task. This is especially true

for large complex robots such as the PR2 and Atlas

robots, where monitoring all of the sensors at once is

effectively impossible. In order to manage this prob-

lem it is common to group sensors either by location

or function. Thus a different group is monitored de-

pending on the current task. However, unexpected be-

haviour on the part of the robot may require that data

from another sensor be accessed to assess the prob-

ICINCO2015-12thInternationalConferenceonInformaticsinControl,AutomationandRobotics

lem. In this case a new widget can be added and oth-

ers moved around or resized to make room for the ad-

ditional view.

Using the camera widget an user can also publish

image streams of the robot while in operation. This

enables a user to simultaneously record the actions of

the robot while closely monitoring its sensors, assum-

ing the necessary topics are already being recorded by

the rosbag record utility. Normally this test requires

an additional person with a separate device capable of

recording video or taking pictures.

Motion Controller. One shortcoming of laptop and

netbook based human-robot interaction is their inabil-

ity to capture inertial data. Although motion con-

trollers such as the PlayStation Sixaxis, Dualshock,

etc. can provide this functionality, they add additional

complexity to the process of actually controlling a re-

mote device. Such sensors are typically integrated

within tablet/phone devices and can be easily adopted

to control a robot as demonstrated by Speers and

Jenkin (2013) . Using a compound widget contain-

ing an accelerometer, gyroscope and magnetometer

widgets, within RCON a complete sensor msgs/Imu

message can be compiled and sent to the robot where

this interaction can be carried out. One should be

aware how this model differs slightly from the ap-

proach taken in Speers and Jenkin (2013) . Lacking a

user scriptable engine RCON can’t process and inter-

pret new results. As a result calculations that turn raw

sensor data, into user commands must take place on

board the robot.

Discovery. Most human-robot interaction within an

academic setting takes place between a robot and an

experienced user. Within such a setting the user is

often intimately familiar with the robot and its capa-

bilities. A novice user typically does not have this

acquired knowledge. RCON provides a novice user

with an intuitive tool to quickly discover a robot’s fea-

tures and capabilities. Browsing through the list of

topics reveals onboard sensors. Browsing through the

services reveals the robot’s command structure.

Collaborative Interfaces. Multiple operators can be

connected to a robot simultaneously using RCON on

separate devices. Operators interact with the robot

but also with each other as well. For example, sub-

scribing to the image topic published by another op-

erator’s camera enables one operator to see what

the other sees. A chat room of sorts could be set

up using the TextView widget for viewing messages

and TextView/TextField widget for sending messages.

This facilitates cooperation between operators that are

interacting with the robot under different capacities

(e.g., controlling and monitoring) or those who are

operating separate sensor/mobility systems, or event

Figure 5: After a widget has been fully and properly conﬁg-

ured the warning overlay on the preview disappears. This

signiﬁes that the widget is ready to be added to a canvas.

Adding a widget to the current canvas can be done by drag-

ging and dropping the preview to the desired location on the

canvas.

separate multiple robots under a single ROS master

process.

5 EXAMPLE UI CONSTRUCTION

Constructing a new interface for controlling a robot

using RCON is quite simple especially if one is fa-

miliar with the target platform. In this example we

will demonstrate the interface construction process

for a Clearpath

Kingﬁsher (Fig. 6) that has been

outﬁtted with additional sensors (camera array and

depth sensor (Codd-Downey et al., 2014b) with in-

tegrated accelerometer). The ﬁrst step in this pro-

cess is to connect to the rosbridge server running on

the robot. When a connection has succeeded RCON

will display the list of topics and services that are be-

ing advertised by the device. The ﬁrst interface el-

ement we will create is a multi-touch widget. This

widget will be used to send velocity commands to

the robot in the form of a geometry msgs/Twist mes-

sage. To add this widget to the current canvas se-

lect the touch widget from the widget list panel, this

RCON:DynamicMobileInterfacesforCommandandControlofROS-enabledRobots

Figure 6: Overview of the Kingﬁsher Robotics Platform.

The unmodiﬁed platform comes equipped with an IMU, a

GPS antenna, a radio transceiver and differential drive ca-

pability. Additional sensing capabilities have been added to

the platform, these include a panoramic array of camera and

a SONAR depth sensor.

will bring up a settings panel where the widget can

be conﬁgured. The touch widget has two basic set-

tings (type and topic), in this case the type should be

set to publisher and the topic set to /cmd vel, when

the widget has been properly conﬁgured the preview

shown on the settings panel can be dragged on to the

canvas as depicted in Fig. 5. Next we add two im-

age widgets to the canvas so that live camera data

from the robot can be viewed on screen. To do this

you select the topic which corresponds to the desired

camera feed (sensor msgs/CompressedImage or sen-

sor msgs/Image) from the topics panel. This will dis-

play a prompt asking whether you wish to subscribe

to the topic or publish a message to it. After selecting

subscribe, a list of widgets that can act as subscribers

to the selected topic is displayed, of these widgets we

are interested in the image widget. Adding widgets

via this process sets the type and topic settings so the

preview can be immediately added to the canvas via a

drag and drop gesture. This process can be repeated to

add a second image widget to the canvas as illustrated

in Fig. 7.

When the canvas has been populated with the de-

sired widgets the canvas can be further conﬁgured by

repositioning and resizing widgets to achieve the de-

sired layout. The interface constructed in this exam-

ple is shown in Fig. 7. The touch widget that was

added to the canvas can be used to send motion com-

mands to the robot using a pan gesture to illustrate the

desired motion. This simple interface and the process

involved in its construction demonstrates how RCON

can be used to create effective interfaces for interact-

ing with robots.

Figure 7: This example interface consists of two image wid-

gets and a touch widget. The image widgets display live

camera data published by the robot. The touch widget can

be used to send velocity messages to the robot using touch

gestures.

6 DISCUSSION

RCON offers a wide variety of applications in the

ﬁeld of human-robot interaction. The most obvious

and notable is the ability to create interfaces that can

control and monitor a robot’s activity on-the-ﬂy. This

ability can eliminate the need to devote costly re-

sources into the development of custom user interface

applications. Multiple operators can choose to cus-

tomize an interface speciﬁc to their needs, whether

that be the size/placement of certain widgets due to

handedness/preference or the inclusion of additional

widgets for increased awareness.

Robots still in the development stage frequently

require debugging within the ﬁeld. This process ordi-

narily requires feedback from low-level systems and

accessing this information can be difﬁcult. With

RCON specialized one-off debugging an interface can

be created easily. If a custom look-and-feel is re-

quired later in the production stage the ROSBridge

client library allows such development to progress

without worrying about the underlying communica-

tion between ROS. For instance, much of the screen

real-estate used by RCON could be used for other

purposes, and custom views could facilitate greater

information exchange. This is of particular interest

ICINCO2015-12thInternationalConferenceonInformaticsinControl,AutomationandRobotics

to those who wish to develop simultaneously on iOS

and Android, as the AppPortable toolkit can translate

from Objective-C to Java, albeit with minor modiﬁ-

cation using compiler directives. Native Android de-

velopment does not provide this functionality and the

reverse process is not currently available.

At the moment, there is a caveat to proliferating

this technology. ROSBridge does not provide any

form of security to inhibit access to the core ROS en-

vironment. This could result in a nefarious third party

gaining unwanted access to the robot. The most ef-

fective method to prevent against this is to password

protect the wireless network in use by the robot. Ad-

ditionally the port on which the ROSBridge server is

running can be changed from the default port and kept

secret.

ACKNOWLEDGEMENT

The support of NSERC Canada and the NSERC

Canadian Field Robotics Network (NCFRN) is grate-

fully acknowledged.

REFERENCES

Codd-Downey, R., Forooshani, P., Speers, A., Wang, H.,

and Jenkin, M. (2014a). From ROS to unity: Lever-

aging robot and virtual environment middleware for

immersive teleoperation. In IEEE International Con-

ference on Information and Automation (ICIA 2014),

pages 932–936.

Codd-Downey, R., Jenkin, M., and Speers, A. (2014b).

Building a ros node for a nmea depth and tempera-

ture sensor. In Proc. 11th Conf. on Informatics and

Control, Automation and Robotics (ICINCO), Vienna,

Austria.

Crick, C., Jay, G., Osentoski, S., Pitzer, B., and Jenkins,

O. C. (2011). Rosbridge: ROS for non-ROS users. In

Proceedings of the 15th International Symposium on

Robotics Research.

Crockford, D. (2006). Rfc4627: Javascript object notation.

In Fiedler, M., M

oller, S., & Reichl, P.(2012). Quality

of Experience: From User Perception to Instrumental

Metrics (Dagstuhl Seminar 12181). Dagstuhl Reports,

volume 2, pages 1–25.

Httenrauch, H. and Norman, M. (2001). Pocketcero - mo-

bile interfaces for service robots. In In Proceedings of

the Mobile HCI, International Workshop on Human

Computer Interaction with Mobile Devices.

Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T.,

Leibs, J., Wheeler, R., and Ng, A. Y. (2009). ROS: an

open-source robot operating system. ICRA workshop

on open source software.

ROSJava (2015). ROSJava - ros wiki. http://wiki.ros.org/

rosjava. Accessed: 2015-02-25.

ROSPod (2015). ROSPod - ros wiki. http://wiki.ros.org/

rospod. Accessed: 2015-02-25.

Speers, A., Forooshani, P. M., Dicke, M., and Jenkin,

M. (2013). Lightweight tablet devices for command

and control of ros-enabled robots. In 16th Inter-

national Conference on Advanced Robotics (ICAR

2013), pages 1–6. IEEE.

Speers, A. and Jenkin, M. (2013). Diver-based control of a

tethered unmanned underwater vehicle. In Proceed-

ings of the 10th International Conference on Infor-

matics in Control, Automation and Robotics (ICINCO

2013), pages 200–206.

Wu, S. and Chen, Y. (2004). Remote robot control us-

ing intelligent hand-held devices. In The Fourth In-

ternational Conference on Computer and Information

Technology, 2004. CIT’04., pages 587–592. IEEE.

RCON:DynamicMobileInterfacesforCommandandControlofROS-enabledRobots