2 INFORMACION SOBRE LA CARGA

Once described the software methodologies applied, we introduced here the the Robotic Operative System (ROS) framework in which we have based our implementation.

ROS is a set of libraries and tools to help software developers create robot applications [109]. Nowadays, it exists a lot of robotic projects developed with ROS. For instance, the PR2 robot by Willow Garage [110] or the NAO robot by Aldebaran Robotics [111].

ROS has several features which make itself very usable. For instance, it is Peer-to- peer. This consists of a number of processes in different hosts connected at runtime in a peer-to-peer topology. Also it is Tools-based, that is a large number of small tools which are used to build and run the various ROS components, rather than a monolithic development and runtime environment. Furthermore, it is Multilingual, currently supporting four very different languages: C++, Python, Octave, and LISP. Although it has its own compilation system, deep inside it works with the CMake system that allows for easier code extraction and reuse beyond its original intent. Finally, ROS is Free and Open-Source, this makes a large community developing at the same time and evolving robotics functionalities faster.

ROS uses code from numerous other open-source projects, such as the drivers, navigation system, and simulators from the Player project, vision algorithms from OpenCV, and planning algorithms from OpenRAVE, among many others.

The main ROS concepts that we use in our system are metapackages and packages, nodes, topics, messages (publisher/subscriber), and services (server/client). The general scheme of a ROS based system could be found in Figure4.7.

ROS Node 1 ROS Node 2 ROS Node n Computer 1 Messages Registration Registration Messages Messages ROS Master

Firstly, a package is a software project where functionalities are implemented in a node. Furthermore, a metapackage does not have any source code because it only has dependencies to other packages, that is, it is like a container which references to packages it includes. Another important concept is nodes, which is an executable that uses ROS to communicate with other nodes. Nodes can publish messages to a topic as well as subscribe to a topic to receive messages. Nodes can also provide or use

services.

Messages are ROS data type used when subscribing or publishing to a topic. A

publisher send a message when data has to be transferred to another node. Meanwhile, other node, that is subscribed to the topic, will receive the message.

Services are another way that nodes can communicate with each other following a

server-client paradigm. Services allow nodes to send a request and receive a response synchronously. The server node provides a service that will receive the client call, realize the operations, and return the result. A client will do a petition on demand.

Both last concepts could be seen graphically in Figure 4.8.

Topic

Node

Node

Publication Subscription Service invocation

Service result

Fig. 4.8 ROS communication between nodes.

Another important tool ROS offers us is the actionlib stack3_{. The actionlib stack}

provides a standardized interface for interfacing with preemptable tasks. Examples of this include moving the base to a target location, performing a laser scan and returning the resulting point cloud, detecting the handle of a door, etc.

In any large ROS based system, there are cases when someone would like to send a request to a node to perform some task, and also receive a reply to the request. This can currently be achieved via ROS services.

In some cases, however, if the service takes a long time to execute, the user might want the ability to cancel the request during execution or get periodic feedback about

how the request is progressing. The actionlib package provides tools to create servers that execute long-running goals that can be preempted. It also provides a client interface in order to send requests to the server (Figure 4.9).

Fig. 4.9 The ActionClient and ActionServer communication.

In order for the client and server to communicate, we need to define a few messages on which they communicate. This is with an action specification. This defines the Goal, Feedback, and Result messages with which clients and servers communicate:

Goal To accomplish tasks using actions, we introduce the notion of a goal that can be sent to an ActionServer by an ActionClient. An example of goal would be for controlling the tilting laser scanner, the goal would contain the scan parameters (min angle, max angle, speed, etc).

Feedback Feedback provides server implementers a way to tell an ActionClient about the incremental progress of a goal. As example for controlling the tilting laser scanner, this might be for instance the time left until the scan completes.

Result A result is sent from the ActionServer to the ActionClient upon completion of the goal. This is different than feedback, since it is sent exactly once. This is extremely useful when the purpose of the action is to provide some sort of information. For the tilting laser scanner controlling example, the result might contain a point cloud generated from the requested scan.

We have defined a common result definition where the consequence of an action may only be SUCCESS, FAIL, or ERROR.