A Cloud Robotics Platform

User Tools

Site Tools



  • March 15, 2014 | Rapyuta/Roboearth presented at TEDx, Adliswil, Switzerland (video)
  • November 03, 2013 | Rapyuta presented in IROS 2013, Tokyo, Japan.
  • April 12, 2013 | Rapyuta presented in ROSCon2013, Stuttgart, Germany. Successful live demonstration of RGBD mapping on the cloud.
  • April 10, 2013 | Rapyuta presented in invited talk at the ICRA 2013 workshop on long-term autonomy, Karlsruhe, Germany.

Rapyuta Overview

The standard configuration of the RoboEarth Cloud Engine consists of four different processes. Namely the Master process, the Robot process, the Container process, and the Environment process.

Master Process

The Master process is the brains of the RoboEarth Cloud Engine framework. Every administrative request from a User is handled by the process and it is responsible for the initiation of the necessary changes to the system. These administrative tasks include:

  • connections to robots (includes some load balancing when more than one Robot process is available)
  • creation/destruction of containers (includes some load balancing when more the one machine/Container process is available to create a container)
  • addition/removal of robots (includes authentication of the users)
  • addition/removal of nodes, parameters to/from the computing environments
  • addition/removal of interfaces to/from endpoints
  • addition/removal of connections between endpoints/interfaces

There is exactly one Master process for the entire RoboEarth Cloud Engine.

Container Process

The Container process creates and destroys computing environments (i.e. containers) according to the orders from the Master process. Note that the Container process needs super-user privileges to create and stop containers. There is exactly one Container process per machine, which should be used to run computing environments.

Robot Process

The Robot process is the first type of endpoint in the RoboEarth Cloud Engine. Its primary function is to manage the connections to the robots as well as converting incoming and outgoing messages to the appropriate format. It is possible to run mutliple Robot processes in a single machine.

Environment Process

The Environment process is the second type of endpoint in the RoboEarth Cloud Engine. Its responsibilities are:

  • addition/removal of ROS nodes
  • addition/removal of parameters to/from the parameter server
  • addition/removal of interfaces to/from ROS nodes

There is exactly one Environment process per Computing Environment

Computing Environment (LXC)

Each linux container has its own ROS environment, i.e. its own roscore and ROS parameter server. The ROS environment and the parameter server are controlled by the environment process running inside the container. The process is automatically started by the upstart deamon when the linux container is launched. Additionally the upstart scripts start the roscore which is necessary to run the application nodes.

Internal Communication

The processes of the RoboEarth Cloud Engine communicate over sockets with each other and its protocol is built on top of the twisted framework, an event-driven networking engine, which uses asynchronous messaging. The internal communication can be separated into two different types. the first is the administrative communications and the second is the exchange of data messages (i.e. ROS messages) between endpoints. While the former relies on the Perspective Broker, which is the twisted version of an RPC mechanism, is a custom protocol used for the latter case. The protocol is built on top of an Int32StringReceiver which has the following syntax

[length string (4 bytes)][string (x bytes)]

where the string has the custom syntax

[flag receiver ID (1 byte)][receiver ID (0/16 bytes)][sender ID (16 bytes)][length message ID (1 byte)][message ID (0-255 bytes)][message (x bytes)]


  • flag receiver ID :Flag which indicates whether the next 16 bytes are the receiver ID (true) or there is no receiver ID (false)
  • receiver ID :ID which is used to identify a single interface to which this message is sent
  • sender ID :ID which is used to identify the interface which sent the message
  • length message ID :Interger defining how many bytes long the message ID is
  • message ID :Message ID which is used to identify the message which is sent
  • message :Message which is sent

External Communication

The robots/users connect to the RoboEarth Cloud Engine using websockets. The communication protocol is explained in more detail here and is build on top of the autobahn project which also uses the twisted framework. The usage of websockets allows the RoboEarth Cloud Engine to push the results in contrast to a common webserver using the pull technology.


Type Definition

There are two possible ways to communicate with the ROS nodes, either using topics (asynchronous) or services (synchronous). This gives four different types of interfaces (for a more detailed explanation of topics and services have a look at the ROS documentation):

  • Publisher :Sends messages received from (multiple) Subscribers to a non cloud engine receiver (asynchronous in ROS)
  • Subscriber :Sends messages received from a non cloud engine sender to (multiple) Publishers (asynchronous in ROS)
  • ServiceClient :Sends a request received from a ServiceProvider to a non cloud engine service provider and returns the response from a non cloud engine service provider to the ServiceProvider from which the request was received (synchronous in ROS)
  • ServiceProvider :Sends a request received from a non cloud engine service client to a ServiceClient and returns the response from the ServiceClient to the non cloud engine service client. There can be only one connection to a ServiceProvider.

Depending on the endpoint in which the interface should be deployed a different group of interfaces are applicable:

  • Interface :Interfaces are used inside a container as a connection to a ROS environment.
  • Converter :Converters are used as a connection to a robot. They convert the data messages (i.e. ROS messages) into a JSON structure or a special binary format, which can be achieved implementing custom converters (as an example an Image converter is provided which converts to sensor_msgs/Image to PNG images) and vice versa.
  • Forwarder :Forwarders are used as a connection to a robot. They send the deflated (compressed) serialized data messages (i.e. ROS messages) to the robot and which send the inflated messages to another interface in the cloud engine.

A complete definition of an interface type consists of a prefix and suffix, where the prefix is one of the four interface types (Publisher, Subscriber, ServiceClient, or ServiceProvider) and the suffix is one of the three interface groups (Interface, Converter, or Forwarder).


To use any of these interfaces the following steps are necessary:

  1. Create the Interfaces with message type 'CN'
  2. Connect two Interfaces with message type 'CX'

The Interfaces are started only on demand in the endpoints. This means only when a connection exists for the interface will it be started. Similarly, when the last connection of an interface is removed the interface will be stopped. To also remove the definition of the interface in the Master manager the interface has to be removed with message type 'CN'.

Data Flow

In the following exemplary (and slightly simplified) the different stations a data message passes on its way from the robot/user to the application node(s) to illustrate the data flow in the RoboEarth Cloud Engine:

Robot Process
  • rce.comm.server.RobotWebSocketProtocol
    • Message is received by twisted/Autobahn
    • Assemble ASCII with binary messages if necessary (rce.comm.assembler.MessageAssembler)
    • Message is handled according to its type and is passed to the Robot Connection instance (rce.robot.Connection)
  • rce.robot.Connection
    • Message is passed to the Robot Connection's namespace.
  • rce.robot.Robot
    • Message is passed to appropriate Interface
  • rce.monitor.interface.robot.XXX
    • Message is converted from JSON message to ROS message using the converter tools (rce.util.converter.Converter) or inflated using zlib
    • Message is passed to the base class of all Interfaces
  • rce.slave.interface.Interface
    • Message is passed to a specific or all protocols which are connected with the interface (depending on interface type)
  • rce.slave.protocol.RCEInternalProtocol
    • Message is serialized and sent
Environment Process
  • rce.slave.protocol.RCEInternalProtocol
    • Message is received by twisted and deserialized
    • Message is passed to a specific or all interfaces which are connected with the sender (depending on interface type)
  • rce.slave.interface.Interface
    • Message is passed to Interface implementation for processing
  • rce.monitor.interface.environment.XXX
    • Message is sent to application node (ROS node) using ROS

Maintainer Resources

For resources on releasing AMIs, publishing documentation, visit Maintainer Resources.

developer_resources.txt · Last modified: 2014/06/03 17:38 by gajan