The robotics application, (abbreviated RApp) is simply an instance of an application developed by anyone who wishes to create an application, and is distributed by the RAPP platform, after submission. This application is of a distributed nature; it shall always execute on the robot, but may have components or utilize services that exist on the cloud. Using the respective terms from the robotics community, this causes a required behaviour, or a set of behaviours of the robot.
A RApp can be identified both as a Finite State Machine (Figure 8) and as a Set of Behaviours (Figure 9). As an FSM, an application is treated as a high-level organization of a set of functions, provided as part of the RAPP API. This sort of an approach allows for enhanced flexibility for the RApp programmer, while at the same time providing a safe sandbox of functionality that can be closely monitored and managed. The FSM or particular behaviours are embedded in the Dynamic Agent or the Cloud Agent.
Additionally, considering a RApp as a Set of Behaviours, one can identify cases of RApp components, where an application that describes a specific set of behaviours (i.e. employs a set of functions) can be further extended or reused in a second application. This sort of complimentary functionality allows for the re-use of RApps as components and further promotes the added value of the RAPP platform.
Each application resides on the robot, and is either installed on demand, or permanently stored on the robot, and invoked by the RAPP Core agent. A RApp may be complemented by the functionality provided through the RAPP Platform, which is executed on the cloud, and not on the robot. Whilst the API provides that functionality, what the developer chooses to do, is his or her own accord. For security and privacy issues, the functions executing on the cloud, will be sand-boxed and addressed accordingly (as third party software).
The RApp, may also access the RIC through the RAPP API-provided service calls. All calls are wrapped by the RAPP API, and can be either asynchronous non-blocking network calls, or synchronous blocking network calls. The only limitation in that sense, is the bandwidth capability connecting the two counterparts, and the amount of data transferred.
These calls will be performed under authentication, thus only registered users (and therefore robots) can invoke them.