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.
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:
There is exactly one Master process for the entire RoboEarth Cloud Engine.
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.
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.
The Environment process is the second type of endpoint in the RoboEarth Cloud Engine. Its responsibilities are:
There is exactly one Environment process per Computing Environment
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.
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)]
with
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.
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):
Depending on the endpoint in which the interface should be deployed a different group of interfaces are applicable:
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:
'CN''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'.
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:
For resources on releasing AMIs, publishing documentation, visit Maintainer Resources.
