Connecting ROS to a real-time control framework

for embedded computing

M.M. Bezemer and J.F. Broenink

Robotics and Mechatronics Group,
CTIT Institute, University of Twente,
P.O. Box 217, 7500 AE Enschede, The Netherlands
Email: [email protected], [email protected]

Abstract—Modern robotic systems tend to get more complex

sensors at their disposal, resulting in complex algorithms to
process their data. For example, camera images are being used
map their environment and plan their route. On the other hand,
Complex Loop-controllers
the robotic systems are becoming mobile more often and need to
Algorithms
be as energy-efficient as possible; quadcopters are an example of
this. These two trends interfere with each other: Data-intensive,
complex algorithms require a lot of processing power, which is Fig. 1. System overview showing the separation of algorithms.
in general not energy-friendly nor mobile-friendly.
In this paper, we describe how to move the complex algo-
rithms to a computing platform that is not part of the mobile that require sophisticated, custom controllers also need their
part of the setup, i.e. to offload the processing part to a base own loop controllers, which are not available as pre-packaged
station. We use the ROS framework for this, as ROS provides a blocks, and also need their own software solutions.
lot of existing computation solutions. On the mobile part of the
system, our hard real-time execution framework, called LUNA,
is used, to make it possible to run the loop controllers on it. Another solution to the problem is to offload the complex
algorithms to a so-called base station, which is a resource-
The design of a ‘bridge node’ is explained, which is used to rich PC that does not have to be mobile or energy efficient.
connect the LUNA framework to ROS. The main issue to tackle
is to subscribe to an arbitrary ROS topic at run-time, instead of
An example of such a setup is depicted in Figure 1, showing
defining the ROS topics at compile-time. Furthermore, it is shown a mobile robotic setup, in the form of a helicopter, at the
that this principle is working and the requirements of network right and the base station at the left. The helicopter and base
bandwidth are discussed. station are able to communicate wirelessly where the helicopter
typically sends location, speed, camera, etc. information, which
is processed by the base station. The base station sends new
I. I NTRODUCTION
commands to the helicopter as response, so it is able to fulfil
Modern robotic systems have complex sensors in order to its tasks.
perceive their environment as good as possible, resulting in
complex algorithms, like environment mapping, visual servo- For this distributed approach, some software infrastruc-
ing or path planning, to process the sensor data. Integrating ture is needed. In this work, we use ROS for the complex
complex algorithms on computing platforms that are hard real- algorithms running on the rich-resource platform, and our
time or part of a mobile or energy-efficient robot, is not a LUNA execution framework [1] for the loop controllers on
straightforward task. The complex algorithms generally are the embedded platform. Using ROS allows easy combining
non-hard real-time, being not able to guarantee that they finish software parts, and their execution is soft real-time due to the
before a deadline is met, making scheduling them together with nature of ROS, as that is based on the publisher-subscriber
hard real-time processes impossible. Furthermore, complex pattern. Programs in LUNA run hard real-time, provided the
algorithms tend to use many resources, like CPU, memory or underlying operating system supports hard real-time execution.
storage, which as a result consume quite some power. Mobile However, the connection between these two frameworks is
or energy-efficient robotic systems do not have such amount missing.
of energy available in their batteries.
It would be possible to use dedicated hardware devices The focus of this paper is to connect an embedded applica-
containing loop controllers, which steer the actuators, for ex- tion to a ROS network. LUNA is used as example framework,
ample, ELMO Whistle1 or Maxon Servoamplifier2 . However, resulting in certain design choices, but most of it is generally
during development of loop controllers, one wants to be free to applicable to any other execution framework or application.
implement and experiment with own controllers, which is not Background information, including a discussion on related
feasible when using these hardware devices. Robotic setups work and relevant details about ROS and LUNA are provided
in Section II. The actual solution to connect LUNA and ROS
1 http://www.elmomc.com/products/whistle-digital-servo-drive-main.htm is discussed in Section III. A proof of principle of discussed in
2 http://www.maxonmotor.com/maxon/view/content/controls Section IV, followed by this paper’s conclusions in Section V.
 II. BACKGROUND actual (control software) model components becomes hidden
between the other non-relevant model contents.
A. Related Work
Combining different frameworks to support different de- B. ROS
mands w.r.t. timeliness or other properties has been done
before. Also several interconnects to specific (real-time) frame- The Robot Operating System (ROS) [8] is a software
works running on embedded systems and ROS have been framework that provides a set of tools and libraries to ease
made. We review here four different interconnects. Further- the development of robotic behaviour in software.
more, we discuss two rapid control-prototyping tools, which One of its strong points is the support of nodes and their
are regularly used for embedded hard real-time software de- interaction via a network of topics, which can be advertised by
sign. nodes and subscribed to by other nodes. This helps in building
a network of complex algorithms that each provides a part of
R2P [2] is an modular approach to hardware and software
the overall computations, each using the data that is sent via the
for robot prototyping. It focuses on the rapid prototyping of
topics. This data can consist of sensor information, calculated
small robots, and uses a CAN fieldbus between the robot
environment details or planned tasks.
computer components, of which each one controls a small
robot part, e.g. one motor. It uses ROS for the high-level Furthermore, ROS supports a wide range of sensors,
control, using the straightforward publisher-subscriber pattern. varying from simple force, torque or touch sensors to 3D
R2P cannot be used in our case, as we need run-time binding environment sensing sensors, like range finders or cameras.
of the signals, to prevent the complete LUNA execution engine The sensor-driver nodes handle interfacing with these sensors
to be recompiled after every change in the model. and send the sensors data and control commands through
topics.
Unity-Link [3] focuses on interfacing FPGA-based con-
trollers to software running on a PC, where ROS is used as Usually, a node written in C++ subscribes to a fixed set
middleware. This bridge between ROS-enabled algorithms and of topics, which are determined by using their data structures
hard real-time loop-controller code is quite specific, as the hard in the code. As a result the data structures of these topics are
real-time code runs on FPGAs. Therefore, it cannot be used checked by the C++ compiler, resulting in a robust design. This
for our situation. is due to the compiler being able to match the used fields with
the defined fields of a data structure and alert the developers
Scholl et al. [4] deal with connecting integrated wireless
about mismatches, for example a field being removed in the
sensor nodes to a computer. This work deals with a ROS
defined structure, or having its data type changed. Additionally,
client only, thus only soft real-time. As we need hard real-
the defined data structures have an MD5 checksum attached
time functionality, this approach is not usable in our situation.
to them, calculated using the field information of the structure
YARP [5] and Orocos [6], [7] are versatile robot mid- and thus making the checksum unique. The MD5 checksum
dleware packages, supporting hard real-time and soft real- is run-time checked with an expected checksum when a node
time behaviour, and extensive ways of configuring and tuning. connects to a topic. When these sums do not match, the user
This results in a quite large footprint, making them not really is alerted that the expected and defined data structures of the
suitable for UAVs that in general have restricted resources. topic do not match.
LabVIEW3 is a rapid control-prototyping tool for designing Due to its complexity and extensiveness, ROS is not
control-system software. By itself LabVIEW is only capable capable to provide a hard real-time software environment. The
of generating soft real-time signals, as it is running on a arrival of data on a topic, the scheduled time of a node and so
regular operating system without hard real-time capabilities. on cannot be guaranteed, as this depends on too many unknown
In combination with myRio4 , which is a CPU/FPGA platform, factors. On the other hand, most of the time these things will
it is possible to let LabVIEW generate setpoints that are used go as expected or designed, making ROS suitable for soft real-
by myRio to generate the hard real-time steering signals for time use.
the actuators. LabVIEW is only suitable for modelling the
controllers, it is not (easily) possible to model the plant and C. LUNA
simulate it together with to controllers to verify the dynamic
behaviour of the system. LUNA [1] is a hard real-time framework that provides
all kind of support for embedded applications, like loop-
Simulink5 is a rapid control-prototyping tool in which a controller implementations. It is component-based, meaning
developer draws block diagrams to direct the signal flows to that functionality that is or is not required can be enabled or
their destination blocks, which use these signals to perform the disabled, resulting in an as small as possible software footprint.
algorithm calculations. Using the code-generation capabilities,
it is possible to have hard real-time execution of the block LUNA also provides a CSP-execution engine, that is capa-
diagrams on a computing platform. Unfortunately for simu- ble of executing processes according to the Communicating
lations, the model needs to be annotated with so-called ‘sink Sequential Processes (CSP) algebra [9]. The CSP algebra
blocks’ to visualize the simulation results. This mixes different provides mathematical constructs for scheduling concurrent
uses of the models, resulting in a cluttered diagram where the processes and the rendez-vous communication between them.
The resulting schedules can be formally verified for correct-
3 http://www.ni.com/labview/ ness, like dead-locks and live-locks. This is used to be able to
4 http://www.ni.com/myrio/ guarantee that processes are executed before their deadlines,
5 http://www.mathworks.com/products/simulink/ resulting in hard real-time software execution. Another result
is that the required execution time can be calculated, which can Resource-rich Platform Embedded Platform Plant
be used to determine the maximum possible control frequency
of the software loop-control implementation for any computing LUNA

comm mgr
comm mgr
platform. luna-bridge TCP/IP app Actuators
node
LUNA-based software is typically developed using MDD raw msgs lib
PID Sensors
techniques, provided by the TERRA tool-suite, making use Hard Real-Time
parameter setpoint
of the CSP execution engine. As a result, data-flows in LUNA topics topics
applications are implemented using CSP rendez-vous channels.
ROS core
These channels require both ends to be actively present in order
to communicate the data.
Algorithm Environment
III. D ESIGN OF THE ROS TO LUNA BRIDGE node Sensors
Together ROS and LUNA fulfill all requirements to design
the software for a complex robotic system, as described Fig. 2. Architectural overview of the interconnected software platforms.
in the previous section. Therefore, integration between both
frameworks is required, which is provided by a so-called luna- existing network hardware is that other components can make
bridge ROS node. The LUNA application connects to this ROS use of this infrastructure as well. For example a video camera
node and is able via this node to communicate with the ROS can send its video stream over the same network, being able
network. The system overview is shown in Figure 2. The work to reach all computing platforms as well.
that is described in this paper, is emphasised in this figure. The
design choices for the luna-bridge node and the requirements
A. Robotic Network Design
of the LUNA application are discussed in the remainder of this
section. The robotic network, depicted in Figure 2, spans multiple
computing platforms. Two of these computing platforms are
As mentioned earlier, communication in LUNA CSP appli- shown in the figure, connected by a TCP/IP link to depict
cations is typically implemented using rendez-vous channels. the physical network topology. This is the minimally required
It is required for the integration between LUNA and ROS to network setup. Of course it is possible to add more platforms
provide means to connect these rendez-vous channels to the to the network if desired.
luna-bridge node. ROS does not have rendez-vous communi-
cation, so the connection between ROS and LUNA must deal The resource-rich platform contains the ROS network, to
with the mismatch between regular or periodic communication which two nodes are connected. The algorithm node uses the
and rendez-vous communication. environment-sensor data to perform its complex calculations.
In practice it is common to separate complex calculations
The integration between both framework must be as flexi- over multiple nodes, each with their own sub-task to execute.
ble as possible. This implies the following requirements: Besides algorithm-related nodes, the ROS network typically
contains task-planning related nodes as well, to determine
• Any primitive data type needs to be supported, so the
and schedule the short and long running tasks of the robotic
users are not limited in their designs by a (small) set
system, depending on the purpose of the system and its
of data types.
current environment. The final results of the algorithms, in this
• Complex data types should be build using these primi- situation ‘setpoints’, are provided via their topics. The luna-
tive data types, further expanding the support different bridge node is subscribed to such topics in order to be able to
data types. send the results to the embedded platform. Additionally, the
luna-bridge node can send parameter values to the algorithm
• Conversion between LUNA rendez-vous channels and node to properly configure it, depending on the needs of the
ROS topics must be available, since both are the native embedded loop-controllers for example.
means for communication.
The embedded platform contains the hard real-time, em-
• Naming conversion must be provided to connect a bedded loop-controllers. These controllers calculate the steer-
LUNA channel to a ROS topic field, as their names ing signals using the results provided by the luna-bridge node
are not the same by default. and the sensors. Again, only one controller (application) is
depicted in the figure, but in practice multiple controllers are
The LUNA application is located on the embedded plat-
typically present, each requiring one or more signals from
form, whereas the luna-bridge is located on a resource-rich
the luna-bridge node. The example application consists of a
platform, as depicted in Figure 2. The resource-rich platform
simple PID controller, but any other hard real-time controller
has access to plentiful resources and computing power. Con-
implementation can be used, depending on the requirements
necting these platforms requires support to communicate. Us-
of the actuators and the complexity of the movements of the
ing existing networking hardware is the most straightforward
robotic system.
way to connect the platforms to a robotic network. Nowadays
all computing platforms have access to networking hardware,
B. Connection Management
via a regular LAN port or a WiFi adapter. The latter is
suitable for mobile robotic platforms that cannot have a cabled As mentioned in the previous section, it is likely that mul-
connection to the robotic network. An advantage of using tiple controllers are present on an embedded platform and/or
that these controllers require more than one of the calculated “Tools for directing, throttling, selecting, and other-
values. Setting up a TCP connection for each controller and its wise messing with ROS topics at a meta level. None
input values, would result in too much resource usage, which of the programs in this package actually know about
especially needs to be prevented on embedded platforms. the topics whose streams they are altering; instead,
these tools deal with messages as generic binary
Adding a connection manager on both the embedded and blobs. This means they can be applied to any ROS
resource-rich platforms, solves this issue. The connection topic.”
manager on the embedded platform establishes a single con-
nection to the connection manager of the luna-bridge. Now This package provides the undocumented ShapeShifter
the managers are able to collect the data and send it over the API, that contains the actual mechanics to handle the topics
single connection. This even allows to bundle data of different as binary blobs. An overview containing the ShapeShifter
topics, and send it using a single TCP packet, further reducing class and related classes is depicted in Figure 3. Using its
overhead introduced by the TCP headers that accompany each getMessageDefinition() function, it is possible to obtain the
packet. string representation of the names and data types of the topic
fields at run-time for any topic. This provides some basic
C. Run-time Topic Binding means to verify that a topic indeed contains the expected data
and its location in the binary blob, as required by the embedded
As briefly mentioned in Section II-B, the software de-
applications. Using the data types of the field, its actual data
veloper needs to decide at compile-time to which topics the
value can be extracted/decoded from the binary blob.
application requires to subscribe to. In other words, the appli-
cations are bound to the topics at compile-time. This results Due to the complexity it makes sense to provide a separate,
in (virtually) no possible mismatches between the actual and reusable software library that provides the functionality of
the expected data format of the topics, making ROS-enabled decoding the binary blobs of topics, so any application can
programs as robust and smooth as possible with respect to just simply request the required data of any topic field. This is
topics. exactly what the raw messages library9 is doing (see Figure 2).
It provides a MessageDecoder class that is able to decode
Unfortunately, the luna-brige node has no definitive infor-
the raw messages receive from topics and a MessagePublisher
mation about the topics it is going to connect to when it gets
class to publish messages. The luna-bridge node, makes use of
compiled, as this depends on the LUNA applications, which
this library to subscribe to or publish at any topic (field) at run-
are designed separately (LUNA is used as a framework, i.e. a
time, when requested by an embedded application connected
pre-compiled library). It would be possible for a developer to
to it.
collect all required topics, depending on the topology of the
robotic network and the applications that are connected to it, The overview of the classes involved by luna-bridge in
but that would become an error-prone and tedious task. Es- receiving messages from arbitrary topics is shown in Fig-
pecially during development, when the embedded applications ure 3. When an application connects to the luna-bridge
tend to change a lot until they are working properly. Another node (depicted as LUNABridge) and requests to receive data,
disadvantage would be that the luna-bridge needs to be re- LUNABridge instantiates a TopicListener and adds it to its
compiled every time one of the embedded applications require listeners list. The TopicListener subscribes to an arbitrary topic
the information of another topic. In other words, compile=time using the ShapeShifter class. The callback() function is called
binding to topics is not useful, and run-time binding to any of when a message is received, with the ShapeShifter class as
the available topics is required by the luna-bridge node. message format, which is provided to the MessageDecoder.
The solution is to use a custom way of connecting to a The MessageDecoder is able to provide values of the topic
topics, circumventing the default subscription method of ROS. fields to LUNABridge in order to send them to the LUNA
This is already done by some software parts of ROS: application.
Sending messages from a LUNA application into the
• The Python wrappers for ROS6 , as an Python appli- ROS network is more straightforward compared to receiving
cation is not, per se, compiled before being executed, them. When the LUNA application requests to send a value,
so connecting to topics happens at run-time. LUNABridge uses the MessagePublisher to create a message
• Some of the ROS commands, that are part of the that can be sent over a topic. The MessagePublisher is con-
ros comm package7 , are able to show information figured with the topic and field type, this information is used
about the available topics and monitor them. when one of the publish() functions is called. These functions
check whether the configured type is matching, as an additional
The simple ros comm commands are written in Python, ba- safety check. If this is the case, it creates the corresponding
sically providing means to easily access the information that ROS message and simply sends it to the topic.
is provided via the Python wrappers. But the more complex
commands, like rosbag, are written in C++, and therefore In order for this to work, the message types have to be
use some other mechanism to circumvent the compile-time known in the luna-bridge node on beforehand. All ROS build-
topic subscriptions. These commands use the rather unknown in native types are currently supported in the luna-bridge
topic tools package, which has the following description8 : node. Therefore, the messages can only contain a single field
consisting of such a build-in type. Each type has its accompa-
6 http://wiki.ros.org/rospy nying publish() function. Without this limitation the amount
7 http://wiki.ros.org/ros comm
8 http://wiki.ros.org/topic tools 9 https://github.com/veger/ros-raw message
 1 0..1 0..*
ShapeShifter MessageDecoder TopicListener LUNABridge
msgBuffer: uint8 t* msg: ShapeShifter decoder: MessageDecoder listeners
publishers
getMessageDefinition(): decodeNextField() callback(msg: ShapeShifter)
String findField(name: String)
getFieldString(): String
getFieldInt64(): int64 t
...

0..*
MessagePublisher
topic: String
fieldType: FieldTypes
publish(str: String)
publish(i: int64 t)
...

Fig. 3. Class Diagram showing the relation between the different classes used by the luna-bridge node.

of publish() functions would exponentially increase, as all Resource-rich Platform Embedded Platform
combination would require their own function. Of course, it is 2a
2b 1a
possible to add several application-specific message types that luna-bridge LUNA 1b User Input
are required by the robotic system, for example, a message type node application
5
containing location and rotation information seems sensible to
include. 3a 3b 6
Screen
ROS core
IV. T ESTING
4
A. Essential tests
Algorithm
A straightforward test is performed to determine that ev- node
erything works as intended, i.e. all luna-bridge communication
paths are tested, both to the LUNA application and to the ROS Fig. 4. Data flow diagram of the test setup.
network. The data flows of this test are depicted in Figure 4.
The embedded platform is implemented using a Gumstix
Overo Fire module10 , running Linux version 3.2.21 and Xeno- of (WiFi) networks. A typical camera is able to send about 25
mai 2.6.3. A regular desktop PC with an Intel i7 860 2.8 GHz to 30 frames per second, but depending on the capabilities
CPU and 12 GB RAM is used for the rich-resource platform. and complexity of the algorithms a resource-rich platform
The desktop PC has Kubuntu 14.10 and ROS Indigo, build might not be able to process the frames at this same rate.
from sources11 , installed on it. Both computing platforms are Assuming that 25 loop-controllers get their setpoints at a
connected using a 1 Gbit/s dedicated LAN. 10 Hz rate, somewhat lower than a camera is able to send
First, the user is asked for 2 values on the embedded the frames, it results in 250 packets per second. In a most
platform. These values are sent to the ROS network via the simple implementation, these setpoints are not bundled into a
luna-bridge node on the resource-rich platform. A node on single TCP/IP packets but send separately. These 25 packets,
the ROS network performs a complex calculation (a simple each 1500 bytes (or 12,000 bits) large, result in a 3 Mbit/s
addition) using these values. Finally, the result is then sent back bandwidth requirement. We expect that this can be covered
to the embedded platform via the luna-bridge, and showed to by a WiFi connection, taking into account the often lower
the user for verification. channel capacity due to distance, wheather etc. So, we assume
at least 5-10 % of the theoretical maximum of a normal WiFi
The test showed that the luna-bridge node is working as connection to be available.
intended. It is able to connect the rendez-vous channels to ROS
topics, two channels to send the user input and one channel to A TCP/IP packet is large enough to bundle about 90
obtain the result of the algorithm. setpoints, assuming that 16 bytes of data are required per
setpoint. So by bundling the 25 setpoints of the example
B. Network occupation calculation into one TCP/IP packet, the bandwidth requirement
The bandwidth required to communicate with the luna- is reduced by a factor 25. Other means like data compression,
bridge node is neglectable in comparison with the bandwidth reducing the setpoint frequency, and so on can further reduce
the required bandwidth. Hence it is safe to conclude that
10 https://store.gumstix.com/index.php/products/227/ the required bandwidth to connect to the luna-bridge node is
11 https://github.com/veger/ros-builder neglectable.
 Since the network has lots of left-over bandwidth available, The principle of connecting the platforms is generally
it makes sense to connect the ‘Environment Sensors’ to the applicable, so implementing it for other tool chains should not
network as well, in order to communicate their measured impose too many problems. So, whether ROS and LUNA are
data. For example, if the mobile robotic systems has a camera used or other frameworks, or adding support to other (MDD)
attached, its video stream can be sent over the network. For tool chains does not matter.
example, a full HD video stream with H.264 encoding has a
bit rate of about 4.5 Mbit/s. Using a 54 Mbit/s WiFi network R EFERENCES
to connect a mobile robotic system, like a quadcopter, with
[1] M. M. Bezemer, R. J. W. Wilterdink, and J. F. Broenink, “LUNA: Hard
the resource-rich platform, would have enough bandwidth to Real-Time, Multi-Threaded, CSP-Capable Execution Framework,” in
theoretically stream up to 12 full HD video streams. However, Communicating Process Architectures 2011, Limmerick, ser. Concurrent
in practical outdoor situations, such video streams might be System Engineering Series, P. Welch, A. T. Sampson, J. B. Pedersen,
too much to let the bundle of setpoints be transported in J. M. Kerridge, J. F. Broenink, and F. R. M. Barnes, Eds., vol. 68, no.
WoTUG-33. Amsterdam: IOS Press BV, Nov. 2011, pp. 157–175.
a normal way. Note that this paper focuses on the network
bridge, leaving development of (quad-copter) applications out [2] A. Bonarini, M. Matteucci, M. Migliavacca, and D. Rizzi, “R2p: An open
source hardware and software modular approach to robot prototyping,”
of the paper’s scope. Robotics and Autonomous Systems, vol. 62, no. 7, pp. 1073–1084, 2014.
It is assumed in the previous discussion that the connection [3] A. B. Lange, U. P. Schultz, and A. S. Sørensen, “Unity-link: A software-
gateware interface for rapid prototyping of experimental robot controllers
strength is optimal; in practice this is often not the case. on fpgas,” in 2013 IEEE/RSJ International Conference on Intelligent
By implementing quality of service (QoS) mechanisms, it Robots and Systems, Tokyo, Japan, November 3-7, 2013, 2013, pp. 3899–
is possible to drop frames from the video streams in order 3906.
to make sure that the luna-bridge communication is getting [4] P. M. Scholl, M. Brachmann, S. Santini, and K. Van Laerhoven, “Integrat-
through when the available bandwidth is too low. Besides ing wireless sensor nodes in the robot operating system,” in Cooperative
dropping frames when the connection drops, the mobile system Robots and Sensor Networks 2014, ser. Studies in Computational Intel-
ligence, A. Koubaa and A. Khelil, Eds. Springer Berlin Heidelberg,
needs to be robust enough to handle temporarily connection 2014, vol. 554, pp. 141–157.
drops, so it will not continue flying to a direction and get lost, [5] G. Metta, P. Fitzpatrick, and L. Natale, “Yarp: yet another robot plat-
or crash into obstacles. form,” Int’l J. on Advanced Robotics Systems, vol. 3, no. 1, pp. 043 –
048, Mar. 2006.
V. C ONCLUSION [6] H. Bruyninckx, “Open robot control software: the OROCOS project,” in
Robotics and Automation (ICRA), 2001. IEEE International Conference
The essential test showed that the principle is working as on, vol. 3. IEEE, 2001, pp. 2523 – 2528.
intended. It is possible to send and receive data between a [7] H. Bruyninckx, P. Soetens, and B. Koninckx, “The real-time motion
hard real-time embedded platform to a resource-rich platform. control core of the Orocos project,” in Robotics and Automation, 2003.
Thereby solving the problem of offloading resource intensive Proceedings. ICRA ’03. IEEE International Conference on, vol. 2, Sep.
2003, pp. 2766 – 2771 vol.2.
algorithms from a embedded platform to a resource-rich plat-
[8] M. Quigley, K. Conley, B. P. Gerkey, J. Faust, T. Foote, J. Leibs,
form. R. Wheeler, and A. Ng, “ROS: an open-source Robot Operating System,”
It is also argued that the available bandwidth is amply suf- in ICRA Workshop on Open Source Software, 2009.
ficient for the required communication between the platforms. [9] C. A. R. Hoare, Communicating Sequential Processes. Prentice Hall
International, 1985.
There is even additionally bandwidth available to transport
data from environment sensors, like a camera, over the same
network. In order to use this additional bandwidth safely,
quality-of-service mechanisms may be necessary.
Therefore, this solution aids in adding more and more
computing platforms to a robotic system, as the the luna-bridge
deals with the data transport between the computing platforms.
Future work is to test the luna-bridge solution in more com-
plex research setups. We plan to use it in our ProductionCell,
i.e. a scale model of a molding machine, to combine vision
with basic control of the setup. A second use-case is to use
it on our drones in order to offload the vision algorithms to a
ground station.
Further future work is to develop QoS in the form of
producing warning messages when the available bandwidth is
below a given threshold, such that this can be used in appli-
cations to update their strategy (for example, let a quadcopter
hoover or even fly back until the connection is strong enough
again).
Additionally, we plan to extend our tool chain to support
this work, such that it is possible to model the connection
between the embedded and resource-rich platforms and include
this information into the generated code.