A “Robot Platform” is located on each robot and comprise of each robot’s operating system and the corresponding core agents. It enables the robot to communicate with the “RAPP Platform” and have access to its services. The Robot Platform is composed of 2 major elements:
- A “Core Agent”: This robot-specific software will enable the robot to download and execute applications. Robot’s owners will download it from the “RAPP Platform” and install it on their robot. Once embedded in the “Robot Platform”, The “Core Agent“ will also provide the application with the robot functionalities, which are its sensors and effectors. Some examples are the robot’s motors or its embedded cameras.
- A “Dynamic Agent”: Every time a robotic application is executed by the “Core Agent”, a “Dynamic Agent” is automatically created to process the application on the “Robot Platform” side, allowing the robot to execute the different tasks.
The specific design and architecture of the Robot-side part of the RAPP Platform can be seen below:
The robot side of the RAPP architecture can be further decomposed into three distinct elements; (a) the Core Agent, (b) the Dynamic Agent, and (c) the Communication Layer.
The Core Agent is the static part of the RAPP framework with regard to the robot side. It contains the basic functionality required for the robot to connect to the main RAPP platform, request new or updated RApps, and address basic interfacing with the human user. Furthermore it is responsible for exposing low level robotic services in order to acquire information from the robot sensors and give commands to the robot’s actuators. These are available for invocation from the Dynamic Agents via the RAPP API. It should be stated that the Core Agent is usually implemented via an FSM (Finite State Machine), uptaking the task of downloading, spawning or killing the Dynamic Agents.
The Dynamic Agent is, in essence, any RApp that may be executed within the robot. It can be constantly updated and can connect directly to services and functions available: a) on the Platform Agent, b) on the Cloud Agent (if exists) and c) on the respective robot’s Core Agent.
Finally, the Communication Layer is responsible for the connectivity of the specific RApp functionality to the underlying robot software / operating system, through the use of the ROSBridge Server and/or the HOP client library. It is a crucial component, as it addresses the issue of multiple ROS Nodes by providing the ROS Master and, through the latter, exposes the lower level functionality of the robot. The existence of both interfaces (ROS and HOP) is deliberate and aims in larger flexibility when creating a Core Agent for a new robot. Specifically, in the RAPP cases, the NAO robot contains a Core Agent implemented in ROS, using HOP to connect to the RAPP Store, whereas ANG-Med employs only the HOP client library, as there is a need of a more lightweight meta-operating system.
At initiation, the Core Agent connects to the main RAPP platform (i.e. the cloud) and waits for the user’s requests. Those requests will be issued through voice commands. Simple commands can be interpreted locally, while complex ones will have to be interpreted in the cloud. Eventually the Core Agent requests from the RApp repository an application (RApp) that is able to execute the user’s command. For that purpose the Application Download Service is used. The downloaded RApp is initiated by the Core Agent as a Dynamic Agent on the robot’s computer. In the case of simple commands the Dynamic Agent executes the user’s command. In the case of complex commands the Dynamic Agent may cause the invocation of a service in the cloud. This service will be provided by a RApp based in the cloud being equivalent to the Cloud Agent, or in other words the cloud based component of a RApp. It should be stated that the RApp developer must specifically declare the existence of both parts of the RApp during its submission. The Dynamic Agent and the Cloud Agent can communicate directly, jointly executing the complex user’s command. Upon termination of the execution of the command the Dynamic Agent and the Cloud Agent become redundant and thus they can be deleted. It should be noted that the Core Agent acts as an embodied agent, which has access to all the robot’s hardware (effectors and receptors), while the Dynamic Agent and the Cloud Agent act as computational agents, thus if they require access to the effectors or the receptors they must obtain it through the Core agent. The communication between the Core Agent and the Dynamic agent with the cloud, as well as the communication between the Core and Dynamic Agents is realised by the RAPP API.