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