What is RoboComp?

RoboComp is an open-source robotic framework. It is made up of different robotic software components and the necessary tools to use them. The running components form a graph of processes that can be distributed over several cores and CPU’s using software component technology. Communications are handled by the Ice framework, following the approach taken by the Orca2 robotics system. Our main goals in designing the system are efficiency, simplicity and reusability. RoboComp also uses in some of its components other tools like CMake, Qt4, IPP, OpenSceneGraph and OpenGL. Programming languages used in the project are mainly C++ and Python but the Ice framework makes possible to easily use components written in many other languages. RoboComp, as ROS, can also be called a robot operating system as long as it provides an abstraction layer to robot hardware.

Compared to other similar projects (such as Orca or ROS), the main advantage of Robocomp is its efficiency, and its ease of use.

What is component oriented programming (C.O.P.)?

Two major problems encountered when creating software are scalability and reusability. These problems are especially acute when it comes to software being used in robotics and is due to software use is exceptional in this field. Despite the importance of reusability, it is generally lose sight of this and just creating monolithic and unwieldy software.

In the field of robotics is very common for researchers to implement all the algorithms with a rigid design a task-oriented and / or a specific robot. If so, when it completes the implementation stage of the software developed is ultimately impossible to use. Often so tied to a specific platform or task that is more practical to start from zero (due to dependencies and side effects resulting from its stiffness).

The component-oriented programming emerged as a solution to such problems. It is an approach that does not necessarily have to do with concurrency and distributed computing, but with how software is organized. The object-oriented programming represented a major advance on structured programming, however, when the number of classes and their interdependencies increases, too difficult to understand the overall system. It is therefore beneficial to have a greater degree of encapsulation, which combines several related classes under a single interface, and for understanding the system with less detailed. The component-oriented programming, which was proposed to solve such problems, many see it as the next step after object-oriented programming.

From a design point of view can be seen as a great class to offer public methods. The only difference from this point of view is that the complexity introduced by the classes of dependent component (or class) that are not the domain of the problem disappears because the interface hides the component. A component can be arbitrarily complex, but a step back, all you see is the interface offered. This is what defines it as a component.

Generic representation of components

Therefore, if each component performs a series of tasks or answer a series of orders, who need to handle that communication. It comes into play Ice key to understanding the architecture and functionality of it. Ice is a very interesting communication framework for use in robotics. Despite being developed by a private company is open-source and licensed under GPL. In addition to its free nature there are two other reasons to choose Ice.
  • The first reason is its ease of use: unlike other technologies such as Corba, Ice philosophy is to support only those features that users will really need and avoid introducing other features that are rarely used and difficult learning.
  • The second reason is efficiency: while communication Ice efficiently encodes both in terms of time and space, other options are encoded in XML communication. The use of XML has advantages in other applications where it is desirable that humans can understand traffic and non-critical factors or latency and efficiency, but within a robot that does not happen.

Ice supports two types of communication, remote call (RPC type) or by subscription (through a service that makes messaging server). However, the latter introduces an intermediate step which makes latency unwise use in robotics where real-time execution is paramount.

To make a connection with a component all you must know is the «endpoint», ie the information needed to make the connection: the host name or address to which you connect, protocol, port and interface name. For example:

< name >:< tcp/udp > −p port − h host

where ‘name’ is the name of the component interface that you want to make the connection, ‘port’ is the TCP or UDP port on which the component is listening and ‘host’ computer name where the component is running. From the programmer’s point of view, once the connection is made, the use of Ice is extremely simple components. When a connection is made creates an instance of a proxy to the component as an object. When you run a proxy component method the framework automatically takes care of redirecting the call to the remote component, so the proxy instance is used as if it were an instance of an object with the component functionality. This idea of using a remote resource in a program is not new. Before the advent of object-oriented programming, and Unix had a protocol called RPC for remote procedure calls. Later emerged technologies such as RMI, CORBA, DCOM, or Ice.

To use component-oriented programming has split the software design into pieces that provide an interface. In return we get more reusability, using the same components in different contexts, thus significantly reducing time, cost and effort of developing new applications, while increasing flexibility, reusability and reliability of them. It will be easier to isolate and find bugs, getting eliminate the need to consider hundreds of classes to understand the developed software.