
sponsored by Microsoft, which demonstrates the 
interest that big companies are putting in these 
topics. 
From the above list, RoboEarth is the initiative 
that has more in common with RAC. The platform 
obtained with RoboEarth allows robots connected to 
the Internet to directly access the powerful 
computational, storage, and communications 
infrastructure of modern data centres (Google, 
Facebook, Amazon, etc.) for robotics tasks and robot 
learning. To create a system for robots to 
communicate with each other, RoboEarth’s 
researchers use a language that organizes 
information into environments, objects, and actions. 
The developed PaaS (Platform as a Service) solution 
allows robots to perform complex functions like 
mapping, navigation, or processing of human voice 
commands in the cloud, at a fraction of the time 
required using on-board computers. 
Cloud robotics can be applied to any kind of 
robots, large or small, humanoid or not. Eventually, 
some of these robots could become more 
standardized and sharing applications would be 
easier. The “app paradigm” is one of the crucial 
factors behind the success of Apple and Google. 
Applications (apps) that are easy to develop, install, 
and use. This is the main characteristic that 
distinguishes RAC from existing approaches (like 
RoboEarth): the idea of providing an intuitive and 
easy to use notation for representing the desired 
behaviour of robots (the TR formalism) combined 
with a cloud computing infrastructure that allows to 
deploy complex missions into cheap devices (the 
micro-drones). This significantly will reduce the 
learning curve, requiring less training and effort to 
develop small-size missions (which perhaps 
represent the largest portion of cases). At the same 
time, the cloud serves not only as the common 
infrastructure where the missions are executed, but 
also provides a repository of missions where 
developers can take the benefit of sharing and 
reusing programs to control their own robots, 
obtaining in doing so the benefits of the mentioned 
app store philosophy.  
4 SCENARIOS  
As a demonstrator of the proposal, three scenarios 
have been defined. These scenarios will allow us to 
implement the final architecture shown in Figure 2 
in a staggered and progressive way. The evolution of 
architecture in different scenarios is as follows:
 
  Scenario 1: this scenario implements the 
minimum part of the architecture required in 
order to run a first demonstration. The 
Infrastructure Layer features the local cloud 
infrastructure. The Platform Layer includes the 
TR interpreter and a basic interface to the 
selected drones. Finally, the Application Layer 
implements the TR repository and the facilities 
needed for loading, saving and executing 
concrete TR programs and configure drones. It 
should be highlighted that in this first scenario 
we only consider reusing previously defined TR 
programs that use a single agent. 
  Scenario 2: Continuing with the architecture 
developed in Scenario 1, the Platform Layer will 
provide the possibility of using external Web 
services (useful for example for image 
processing). In the Application Layer we will 
add a graphical TR editor like Scratch in order to 
create and modify TR programs, and a module 
for 3D simulation. In this scenario several agents 
are incorporated, obtaining a more complex and 
mature case study. 
  Scenario 3: Finally, in this scenario the proposed 
architecture is fully implemented. 
Below the scenario 1 that has already been 
implemented is described. 
4.1 Scenario 1 Description 
For the scenario demonstration missions, a real 
environment replica has been deployed in a medium 
size area located in Cartagena (Spain). The mission 
considered the detection and tracking of persons in 
an emergency situation. Appendix A contains an 
excerpt of the TR rules developed in order to 
accomplish the mission requirements.  
For this task, we have selected micro-drones. 
Micro-drones are a particular type of UAVs of great 
interest to test new technological approaches given 
their low cost, the large number of application fields, 
and the possibility to use the results obtained with 
them in other fields. We have selected the Ar. Drone 
2.0 from Parrot, which has a good quality-price 
ration and includes two cameras (HD 720p frontal 
and QVGA vertical) and other sensors that assure a 
high stability during the flight and provides an API 
that allows us reading any sensor of the quadcopter 
as well as sending commands to the propellers, 
among other specifications. In addition, the well-
known Robot Operating System (ROS) (Quigley et 
al., 2009) is compatible with this aerial platform 
thanks to the ardrone_autonomy ROS driver. ROS 
runs in a Raspberry Pi B+ installed on the drone. 
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
62