We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSPecification.I2ND.Robotics - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSPecification.I2ND.Robotics
Chapter I2ND,
Catalogue-Link to Implementation [ Robotics]
Owner TI, ET, Consoft,



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2015 by TI, ET, Consoft.

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


The Robotics GE gives the FIWARE application and service developers the ability to define management functions and to enable the interaction and connection of Robots with smart devices, sensors and applications.

The I2ND Robotics Platform guarantees the robustness necessary for long-term operations in robotics applications. This platform leverages the well-known open source Robot Operating System (ROS), in order to exploit the broad amount of already available ROS nodes, and it abstracts robot hardware towards ROS service logic, residing in the platform. In the Rationale section some definition used throughout this page are explained.

The main features offered by the I2ND Robotics Platform are:

  • Ability to use multiple Robots, Servers (Physical/Virtual Machines) and Service Spaces, while keeping a common Management and a centralized Robotics Configuration database.
  • Distribution of processing nodes between Robots and external Servers according to user-defined configurations and management tasks.
  • Automatic detection and management of Robot connection and disconnection events.
  • Enabling applications to exchange sensors information and robot commands through the Context Broker.
  • Offloading demanding computations from the Robot hardware to a server side (so called “Robot remote brain” or “Robot cloning”)

Target Usage

The Robotics GE, together with other FIWARE GEs, enables a FIWARE Robotics platform able to fit with the different demands coming from both Application Developers and Robotics Developers.

Application developers who do not have deep skills and knowledge in Robotics may be interested in using Robots but their concern is about finding an easy way to manage and interact with them. Such developers are very interested in building up new applications and algorithms that connect the IoT world and Robotics by means of the Big Data and Cloud Computing. In addition, the targeted applications are typically designed for multiple platforms such as PC, mobile phones or web.

Skilled Robotics developers, on the other side, have a deep knowledge of robots, sensors, robotic platforms, such as ROS (Robot Operating System), and algorithms. Typically, robotics algorithms are very time consuming tasks in terms of computational power and they cannot be executed in real time. Robotics developers have a need for distributed computation which can be performed in the cloud. They want to improve the robot intelligence by using social robots and a multi-robot architecture. This implies robots that are able to interact with each other, sharing information even if they are in different locations. In addition, robotics developers have the need to build accessible user interfaces that can help the community to access the robotic world.

The Robotics GE offers a common platform able to fit with the needs of all such developers, by exploiting the capabilities provided by FIWARE to connect applications to IoT, Big Data, Cloud Computing, and adopting a standard ROS environment.

Basic Concepts

Robotics configurations

The Robotics GE allows the definition and employment of different configuration of a Robotics Platform by defining distribution of functional elements (ROS nodes) between the Robots and external Servers (Physical/Virtual Machines). Changing the balance of these nodes may lead to Robot-side or Server-Side deployments of the GE, suitable to serve different purposes and applications of robots.

A Robot-side configuration of the platform, for example, can be used to manage complex robots able to exploit their own “on-Robot” intelligence and their powerful processing and sensing capabilities. These Robots are able to perform simple to medium complexity tasks autonomously, even with simple or no custom programming at all, and they natively support deployment of ROS nodes. They may however need, or take advantage of, data from external sensors to solve their tasks.

A Server-side configuration instead, can be particularly suitable for managing "simple" Robots (i.e. robots with low-complexity and low-cost, for instance most of the currently existing commercial robots) and/or a heterogeneous set of Robots, which demand external processing resources to solve complex or simultaneous tasks. Such Robots are typically equipped with some sensors and can perform different specialized actions, but they do not have the intelligence (i.e. the processing capability) to perform advanced tasks on their own. They support some ROS nodes with limitations on complexity. However, when these Robots act in group and perform actions simultaneously, guided from an external process, they are able to execute much more complex actions, taking benefit of the different sensors and actuators employed in their own specialization. Also for server-side configuration the ability to communicate with external sensors and actuators can further evolve, empowering the usage scenarios which can benefit from robot usage. The Server-side configuration fully exploits the Robotics Platform capabilities and allows powerful management of multiple Robots; it can employ robots of any complexity and establish efficient communication and management of different ROS nodes.

A Robotics Platform in the Robot-side Configuration can be realized to connect sensors from the IoT domain and functions offered by the FIWARE GEs to the Robotics. In this solution, the availability of FIWARE capabilities like storage and processing can be exploited using traditional methods (not specifically oriented to Robotics) together with the functionality of FIWARE GEs. In this configuration a subset of functionalities provided by the GE are used, and an external server is only required to centralize and secure the management and the database, without the need to have processing ROS nodes outside the robot.

A Server-side Configuration of the Robotics Platform implies a full usage of the capabilities provided by the functionalities of the Robotics GE. Such configuration is able to operate Programming, Control and Management functions which reside outside the Robots (e.g. within a FIWARE Lab node). The Server-side configuration is the most flexible solution for applications and services where a generic fleet of heterogeneous Robots is employed to perform multiple tasks and coordinated operations. It fully exploits the Cloud capabilities to Control, Manage and exchange information between Robots (and ROS nodes) in an efficient and adaptable solution, without any strict requirement for the available Robot resources, i.e. robots can be easily exchanged by simply reconfiguring the ROS functions through the Robotics GE.

Besides, the Robotics GE supports all the possible mixed configurations in between the two cases above mentioned, by easily interchanging the deployment of ROS nodes between Robots and Servers. The Robotics GE is able to manage any number of ROS nodes or groups of ROS nodes defined by a ROS launch file (in the following, we simply refer to these groups as ROS launchers). Multiple ROS nodes or launchers are enclosed in a logical container called Service Space (also called "Robot Clone"), which hosts all the functions necessary to control a set of robots. The Robotics GE can manage multiple Service Spaces and, for each of them, allows to apply an ad-hoc configuration for the deployment, in a Robot or in an external server, of any of the required ROS nodes or launchers. These flexible configurations are empowered by a centralized master management function and a single common Robotics Configuration database.

Generic Architecture

The Robotics GE is based on two main components, RCM (Robot Clone Manager) and FIROS, that provide an interoperability layer between FIWARE and the robotics world, thus enabling the developers to build applications that use robots in the FIWARE context. The components can be logically distributed between different Robots and Servers (Physical/Virtual Machines), according to multiple possible configurations.

  • FIROS is a bridge that allows the communication between FIWARE and the robotics domain. Its main function is to translate the context information provided by applications in the FIWARE environment into the language of the robotics domain and vice versa. FIROS is able to work either in a standalone mode, inside a Robot, or in different configurations together with RCM, supporting centralized and decentralized architectures. FIROS is also able to create direct communication between robots and FIWARE applications when the data volume is high or complex, or when the information processing requires smaller transmission delays.
  • RCM (Robot Clone Manager) is a distributed platform able to manage multiple Service Spaces ("Robot Clones") to host all the functions necessary to control a set of robots, centralizing this information in a single database. Service Spaces perform the service logics associated to the corresponding robots and are automatically managed whenever robot events occur. A service logic identifies the set of algorithms (i.e. any set of ROS nodes or ROS launchers, also called algorithms or ALGs for brevity in the following) needed to perform a specific function, like e.g. the path planning: this function performs robot navigation from its current position to a specific goal avoiding possible obstacles.

An overview of the overall architecture is represented in the FMC diagram below. Three different entities are considered in the architecture:

  • A MASTER server, that centralizes the management function and the Robotics Configuration Data.
  • A ROBOT entity, which represents a physical Robot, able to host a module of RCM (PM_AGENT) and ROS nodes (e.g. DRIVERs, for the interaction between ROS and Robot Hardware).
  • A VM/Server which represents a logical or physical machine able to host modules of RCM (PM_AGENT and RCM_DRIVER), many ROS nodes (i.e. ALGs, for heavy load algorithms) and FIROS.

File:Robotics GE_arch.jpg

A ROS environment, including all ROS nodes related to one Roscore, is established in a logical space distributed among the Robot and the VM/Server, called Service Space ("Robot Clone"). FIROS and RCM are logically connected to the Service Space and communicate with each other through the ROS environment (via RCM_DRIVER).

RCM functionality

The RCM component, identified by a grey dashed line, has been exploded in the following logical functions:

  • Robotics Configuration Data, a database which contains information related to MASTER and different VMs/Servers, provisioned Robots, service logics and Service Spaces.
  • Robotics Data Mgmt, to retrieve information (retrieved querying both the Robotics Configuration Data and the Service Space directly) and to manage the provisioning of service logics and Robots in the Robotics Configuration Data.
  • PM (Platform Manager) is constituted by two different functions:
    • PM_AGENT, installed on each Robot and each VM/Server. It performs the RCM management related to commands and Robot events.
    • PM_MASTER, installed only on MASTER to serve multiple Service Spaces (Robots and VMs/Servers). It is an advance version of the PM_AGENT which also performs the interaction with the Robotics Configuration Data and is able to delegate jobs to the other PM_AGENTs.
  • RCM_DRIVER, a ROS node which performs the exchange (through the standard ROS communication methods) of the following information between RCM and FIROS:
    • Robot connection and disconnection events.
      • To correctly notify Robot disconnection events to FIROS, it is required that both ROS nodes involved (FIROS and RCM_DRIVER) are started on the same side: Server (MASTER or Physical/Virtual Machine) or Robot. The Server-side is recommended (as depicted in the FMC diagrams) as it is easier for a Robot to lose the connection to the CB and in this case FIROS would not be able to remove the related entity.
    • Information required by FIROS about the connected Robot; these information are extrapolated querying all the ROS nodes/launchers that are currently running within the Service Space ("Robot Clone") which manages the Robot.

RCM is able to manage multiple Service Spaces (i.e. creation, population, deletion) through Platform Managers (PM_MASTER and PM_AGENTs). A Service Space is a kind of "Robot Clone": it is a ROS environment (with ROS nodes) managed according to a service logic associated to a provisioned Robot. Each Service Space uses at most one VM/Server, and multiple Service Spaces can be hosted in the same VM/Server. All started ROS nodes (FIROS, RCM_DRIVER, DRIVERs and ALGs) within the same Service Space are related to the same Roscore, which is a key component of all ROS-based systems and is used by RCM as "head" of each Service Space. Depending on the ROS nodes started in the Service Space, additional functional interfaces can be dynamically provided by the Robotics GE.

Service Spaces are automatically managed by Platform Managers whenever an event related to a provisioned Robot occurs (i.e. connection/disconnection); this allows to have a unique API (RDAPI) exposed by the Robotics GE towards FIWARE applications.

An enhancement of the Master server entity will provide in next releases an interface to interact with the cloud Hosting FIWARE GEs. In particular, it will interact with the GEs like DCRM to automatically manage the provisioning of VMs used to deploy the Service Spaces (i.e. the "Robot Clones") and implement the additional computation capabilities required by Robots and their applications.

FIROS Functionality

The FIROS component has been split in the following logical functions:

  • Watchdog, receives the notifications about new robots and robots that are no more available. FIROS will create/remove entities in ContextBroker according to these messages.
  • Translator, performs the translation between ROS messages and ContextBroker entities; appending, updating or deleting the required entities. This element will also make the required subscriptions to ContextBroker and will receive its notifications.
  • FIROS Configuration data, stores the configuration required by FIROS such as ContextBroker address, robots whitelists, etc. It also stores links to robot descriptions files (actuator, 3D diagrams, etc).


Further architectural considerations

The global architecture diagram abovementioned is the most general view of the Robotics GE. There is however a simpler approach to use the enabler, considering that:

  • The PM_MASTER is an extended version of a PM_AGENT with additional functions to access the Robotics Configuration Data and to delegate jobs to the other PM_AGENTs.
  • A PM_AGENT is able to manage many Service Spaces hosted in the same VM/Server.

Consequently, it is possible to collapse MASTER and VMs within the same machine, reducing the architecture complexity to only two layers, as depicted in the following FMC diagram:

File:Robotics GE_arch_manySS_collapsed.jpg

Main Interactions

RDAPI (FIWARE_APP-GE interaction)

It performs the following functions:

  • Retrieving of information stored in the Robotics Configuration Data related to the provisioned service logics and the provisioned Robots
  • Retrieving of information related to the Service Spaces ("Robot Clones") currently managed by RCM; conventionally each Service Space ("Robot Clone") has the same name of the managed Robot (i.e. the Robot name)
    • The list of ROS nodes/launchers that are currently running within the required Service Space is returned; this information is retrieved querying both the Robotics Configuration Data (by PM_MASTER) and the Service Space directly (by PM_MASTER/PM_AGENTs)
  • Provisioning (and unprovisioning) of service logics. Parameters: service logic name and ROS nodes/launchers associated with it
    • For each ROS node at least the following information is required: ROS node identification (package name and executable name) and where it has to be started (on Server-side or Robot-side)
    • For each ROS launcher, defined as a set of ROS nodes (to be launched) with appropriate parameters, at least the following information is required: ROS launcher identification (package name and file name) and where it has to be launched (on Server-side or Robot-side)
  • Provisioning (and unprovisioning) of Robots. Parameters: Robot name and the name of the service logic to associate with it (related to one of the service logics already provisioned)

CBAPI (GE-ContextBroker interaction)

The interaction between the Robotics GE and the Context Broker is performed through the CBAPI inferface of the FIROS component. The interface is compliant with NGSI-9/-10 specifications adopted in FIWARE.

Each robot will be represented in ContextBroker as an entity. The interesting topics of each robot will be mapped as attributes following this scheme:

  • topic name as attribute name.
  • topic type as attribute type.
  • topic value as attribute value.

FIROS perform a whitelist filtering in order to select which topic will be sent to ContextBroker.

In addition to the aforementioned attributes, there will exists two more attributes:

  • COMMAND, used for announcing which attribute has changed.
  • firostimestamp, timestamp of the last change in the entity.

FCFGAPI (User-FIROS interaction for whitelist configuration)

This API controls FIROS whitelist filtering, it has three primitives:

  • Whitelist entry creating or overwriting.
  • Whitelist entry deleting.
  • Whitelist restoration.

Basic Design Principles


The Robotics GE adopts Robot Operating System (ROS) as a standard environment for the implementation and communication between Robotics functions and elements, which are called ROS nodes nodes or ALGs for brevity (because they generally implement algorithms to operate hardware and software components of Robots). The Robotics GE extends ROS by allowing to distribute ROS nodes between physical Robots and Servers (Physical/Virtual Machines) inside a logical container called Service Space (also called "Robot Clone").

The processes in ROS are encapsulated in the so-called nodes, executable files within ROS package that communicate with other nodes via a publication-subscription system which channels are called topics. Nodes can also communicate with other nodes via services, messages which allows to implements requests-responses mechanism. The existence of nodes, topics and services is coordinated by the "ROS Master" node. The ROS framework also allows to start a group of ROS nodes through specific ROS launch files. Definition of ROS nodes and ROS launchers (including the format of ROS launch files) can be found at ROS nodes and roslaunch.

ROS is supported by a wide list of robots and sensors and its ecosystem includes an extensive set of tools and algorithms (you can check ROS packages in http://www.ros.org/browse/list.php).

By adopting ROS as underlying environment, the Robotics GE opens to an easy use of a large number of different robots, as well as robot oriented functions and algorithms, thus enabling their adoption in FIWARE applications.

Detailed Specifications

  • Robotics API documentation is found at following links:

Re-utilised Technologies/Specifications

As said, the Robotics GE adopts ROS as underlying environment to manage robots. ROS is a flexible framework for writing robot software. It is a collection of tools, libraries, and conventions that, through low-level system abstraction, aim to simplify the task of creating complex and robust robot behavior across a wide variety of robotic platforms. As such, they are reused in the definition of the GE.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FIWARE level, please refer to FIWARE Global Terms and Definitions

Personal tools
Create a book