The overall design of the RAPP Architecture is depicted in the following figure (click for larger resolution).

As evident, the RAPP ecosystem consists of two major components: the RAPP Platform (upper half) and the respective Robot Platform (bottom half). These systems are not only functionally, but also physically separated, as the RAPP Platform resides in the cloud and the Robot Platform obviously represents each robot supported by the RAPP system, constituting our architecture two layered.

The upper layer is the RAPP ecosystem’s cloud part, consisting of three main parts: The RAPP Store, the Platform Agent and a RApp’s Cloud agent. The RAPP Store provides the front-end of the application store, allowing the creation of accounts either from the robotic application developers or from the end users. Once a developer creates his account they are able to submit RApps via an interface, which are cross-compiled for the supported robots, packaged and indexed. Then they can be distributed at the corresponding robots. If any errors occur during this procedure, the developer is informed in order to correct them and resubmit the application. On the other hand, the end users are able to log in and select the RApps they desire for their robot to execute.

The main part of the RAPP Platform is the RAPP Platform Agent, where the core of the developed artificial intelligence resides. This includes a MySQL database, where all the eponymous information is safely being stored, offline learning procedures and the RAPP Improvement Centre (RIC). This constitutes of the ontology knowledge base, machine learning algorithms and various robotic-oriented algorithms. These are either developed or wrapped by ROS nodes. Finally, these algorithms can be utilized by robots via the Web services exposed by RIC. The Web services can be invoked by the RAPP Platform API with specific arguments, providing access uniformity and authentication security. The final RAPP Platform part is the Cloud Agent, which will be described later for better comprehension reasons.

The lower layer of the RAPP architecture includes the Robot Platforms. There three specific components exist: The Core agent, the Dynamic agent and the Communication layer. The Core agent is robot specific and is provided by the RAPP ecosystem. It uptakes the tasks of downloading / updating the RApps and providing robot-aware services to the applications. These usually are high level interfaces to the robot’s hardware or to locally embedded algorithms, such as mapping, navigation or path planning. A robot can utilize either low level drivers for interfacing with its hardware or higher level tools, such as ROS. When a RApp is downloaded and executed by the Core agent, a Dynamic agent is created, essentially being another naming for the RApp’s robot part. The Dynamic agent can be a ROS package, a JavaScript file, or a combination of them. This utilizes the RAPP API to invoke services either on the Platform or in the robot. One important aspect of the overall architecture is that the developer may choose for his application to be executed in a decentralized way, meaning that according to his submission, one part of the code may execute in the robot and another part of the cloud. The second part is the Cloud agent described before, which is initiated upon its submission.

Considering the RAPP database, it resides on the RAPP Platform and can be accessed a) by the RAPP Store, in order to keep track of the user accounts and the submitted / downloaded applications and b) by the RIC for machine learning / statistical purposes and data acquisition. The latter is performed via a ROS MySQL wrapper, providing interfaces to all the nodes in need for stored data.

Regarding the semantic / knowledge part of RAPP, we decided to employ already used and tested ontologies, aiming at not reinventing the wheel. The only limitations towards this selection were that the ontologies a) should have ROS support, since the RAPP Platform will be ROS-based, b) should have a common file format to easily merge the information and c) to be state-of-the-art in their respective fields. Since RAPP is multidisciplinary, the selected ontologies contain concepts from heterogeneous scientific fields. After researching in the ontology domain the KnowRob and OpenAAL ontologies were selected for deployment.

KnowRob was part of the RoboEarth FP7 project and was specially designed to be used by robots, extending classical ontologies and concepts in a machine-usable way. KnowRob is a state-of-the-art robotic ontology, used by many scientific teams in cloud robotics projects for concepts storage, inference and distribution of knowledge. One great advantage to our cause is that bindings to ROS exist, as it would be challenging to utilize it otherwise, being developed in SWI-Prolog. Finally, The ROS bindings are created using the JPL interface (Java / Prolog bidirectional Interface) and the rosjava package. Finally, KnowRob provides an abundance of ontology packages, all encoded in OWL files that can be dynamically loaded in the KnowRob software tool and queried. On the other hand, regarding the ambient assisted living field, the OpenAAL ontology was selected, created for the SOPRANO integrated project, providing a middleware for AAL scenarios. It should be stated that similarly to KnowRob, OpenAAL is not just an ontology but a software tool providing methods for context management, multi-paradigm context augmentation, context aware behaviors and others. In our case we will not utilize the overall software package but only the ontology semantic information, encoded in OWL files.

As obvious, KnowRob and OpenAAL are two different ontologies, intended for heterogeneous applications, thus means to utilize them efficiently and meaningfully must be implemented. An initial thought is to load both OWL files in the KnowRob software tool, in order to be able to access the information via ROS interfaces. Even though this would be possible, no higher level semantic processes can be deployed, since the two ontology upper level taxonomies would be semantically separated. Thus we decided to semantically merge the two taxonomies and to enrich them with classes relevant to the RAPP’s scope. Regarding the RAPP ontology’s access a KnowRob ROS wrapper was created that will provide querying capabilities to external services.

The RAPP Platform component diagram is presented in the image below and all functionalities are analysed in their respective wiki pages.

[[images/rapp_platform_class_diagram.png]]