Robotics Data API v1 Specification

DATE: 30 July 2015

Editors

Copyright © 2015 by Telecom Italia, Consoft Sistemi


Abstract

RDAPI is a set of REST APIs (which return JSON responses) allowing FIWARE developers to integrate robotic services to IoT ones in a simple way.

Status of this document

This is a work in progress and is changing on a daily basis. First major release 4 will be released by the end of September 2015

This specification is licensed under the FIWARE Open Specification License.


Specification

Introduction

The resources abstracted by RDAPI and needed by FIWARE are described below.

API Specification

Service Logics

A service logic identifies the set of ROS functions (i.e. ROS nodes and/or launchers) needed to perform a specific service, like e.g. "assisted teleoperation" or "path planning". For each ROS function is also indicated where it has to be started (Server o Robot side).

Read service logics [/service_logic/read]

Returns the list of provisioned service logics.

The following is the response structure:

  • result: OK if the requested information can be returned, otherwise ERROR with motivation in the reason field.

  • reason: if result is OK - an array of provisioned service logics, for each element:

    • slg_name: name of the service logic

Read Service Logics - GET /service_logic/read

Response 200 (application/json)

Read service logic information [/service_logic/read?slg_name={slg_name_value}]

Returns the list of ROS nodes and/or launchers associated to the service logic.

The following is the response structure:

  • result: OK if response can be returned, otherwise ERROR with motivation in the reason field.

  • reason: if result is OK - an object containing:

    • ss_side: the side of the head of the Service Space to create (S: Server-side, R: Robot-side)
    • sn_list: list of ROS nodes to start, for each element:
      • sn_package: the ROS node package
      • sn_type: the ROS node type
      • sn_side: the side where to start the ROS node (S: Server-side, R: Robot-side)
      • sn_name: the name to use to start the ROS node
      • sn_params: the ROS node parameters
    • sl_list: list of ROS launchers to start, for each element:
      • sl_package: the ROS launcher package
      • sl_file_launcher: the ROS launcher file
      • sl_side: the side where to start the ROS launcher (S: Server-side, R: Robot-side)
      • sl_name: the name to use to start the ROS launcher
      • sl_params: the ROS launcher parameters

Read Service Logic Information - GET /service_logic/read?slg_name={slg_name_value}

This action allows you to read the indicated service logic information.

Parameters
slg_name_value (Required)
Response 200 (application/json)

Provisioning a service logic [/service_logic/provisioning]

Before using a service logic, it has to be inserted into the platform by using the provisioning API.

The following is the request structure:

  • slg_name: name of the service logic to provide

  • sn_list: list of ROS nodes to start, for each element:

    • sn_package: the ROS node package
    • sn_type: the ROS node type
    • sn_name: the name to use to start the ROS node
    • sn_params: the ROS node parameters
    • sn_side: the side where to start the ROS node (S: Server-side, R: Robot-side)
  • sl_list: list of ROS launchers to start, for each element:

    • sl_package: the ROS launcher package
    • sl_file_launcher: the ROS launcher file
    • sl_name: the name to use to start the ROS launcher
    • sl_params: the ROS launcher parameters
    • sl_side: the side where to start the ROS launcher (S: Server-side, R: Robot-side)

The following is the response structure:

  • result: OK if the requested action can be executed, otherwise ERROR with motivation in the reason field.

  • reason: additional information

Provisioning a service logic - POST /service_logic/provisioning

You may provide your own service logic into platform using this action. It takes a JSON object containing the unique name of the service logic and two list related to the ROS nodes and ROS launchers associated to the service logic.

Request (application/json)
Response 200 (application/json)

Unprovisioning a service logic [/service_logic/r_provisioning]

If a service logic is no longer used, it can be deleted from platform by using the rollback provisioning API.

The following is the request structure:

  • slg_name: name of the service logic to unprovide

The following is the response structure:

  • result: OK if the requested action can be executed, otherwise ERROR with motivation in the reason field.

  • reason: additional information

Rollback Provisioning a service logic - POST /service_logic/r_provisioning

You may remove your own service logic from platform using this action. It takes a JSON object containing the unique name of the service logic.

Request (application/json)
Response 200 (application/json)

Platform Instances

The MASTER instance and the set of Robot instances provisioned in the platform.

Read robot instances [/platform_instance/read]

Returns the list of provisioned Robot instances.

The following is the response structure:

  • result: OK if the requested information can be returned, otherwise ERROR with motivation in the reason field.

  • reason: if result is OK - an array of provisioned Robot instances, for each element:

    • pi_name: name of the Robot instance
    • service_logic: name of the service logic associated with the robot
    • connected: true if the robot is connected to the platform, false otherwise
    • paired: true if the robot is associated to a server (MASTER) and the related service logic is started, false otherwise

Read Robot Instances - GET /platform_instance/read

Response 200 (application/json)

Provisioning a robot [/platform_instance/provisioning]

Before using a robot, the related Robot instance has to be inserted into the platform by using the provisioning API.

The following is the request structure:

  • pi_name: name of the Robot instance to provide

  • pi_service_logic: name of the service logic to associate with the robot

The following is the response structure:

  • result: OK if the requested action can be executed, otherwise ERROR with motivation in the reason field.

  • reason: additional information

Provisioning a Robot - POST /platform_instance/provisioning

You may provide your own robot into platform using this action. It takes a JSON object containing the unique name of the Robot instance and the name of the associated service logic.

Request (application/json)
Response 200 (application/json)

Unprovisioning a robot [/platform_instance/r_provisioning]

If a robot is no longer used, the related Robot instance can be deleted from platform by using the rollback provisioning API.

The following is the request structure:

  • pi_name: name of the Robot instance to unprovide

The following is the response structure:

  • result: OK if the requested action can be executed, otherwise ERROR with motivation in the reason field.

  • reason: additional information

Rollback Provisioning a robot - POST /platform_instance/r_provisioning

You may remove your own robot from platform using this action. It takes a JSON object containing the unique name of the robot instance.

Request (application/json)
Response 200 (application/json)

Service Spaces

A Service Space (also called "Robot Clone") is a ROS container hosting the service logic associated to a provisioned Robot instance.

It has a unique name within the platform (i.e. the same name of the managed robot) and traverses two platform instances:

  • Server-side (i.e. the "remote brain"), which is the MASTER instance

  • Robot-side (i.e. the "local brain"), which is a Robot instance: a real robot, a simulated robot or a gateway which manages a real robot

Each Service Space is:

  • Automatically created by the platform when the related robot connects to it and automatically deleted when the robot disconnects to it.

  • After the creation, the service logic associated to the related robot is started and it is stopped before the deletion

Read service space [/service_space/read?ss_name={ss_name_value}]

Returns the list of ROS nodes and/or launchers that are started in the Service Space and information related to FIROS to be reachable by the Context Broker.

The following is the response structure:

  • result: OK if response can be returned, otherwise ERROR with motivation in the reason field.

  • reason: if result is OK - an object containing:

    • r_nodes: list of ROS nodes started, for each element:
      • sn_package: the ROS node package
      • sn_type: the ROS node type
      • sn_name: the ROS node name
      • i_name: the instance's name where the ROS node is started
    • r_launchers: list of ROS launchers started, for each element:
      • sl_package: the ROS launcher package
      • sl_file_launcher: the ROS launcher file
      • sl_name: the ROS launcher name
      • associated_r_nodes: the array of ROS nodes belonging to the launcher
      • i_name: the instance's name where the ROS launcher is started
    • public_ip: the public IP of the MASTER
    • inbound_port: the inbound port which will be used by the Context Broker

Read Service Space - GET /service_space/read?ss_name={ss_name_value}

This action allows you to read the indicated Service Space.

Parameters
ss_name_value (Required)
Response 200 (application/json)

Examples

Service Logics

Read service logics [/service_logic/read]

Read Service Logics - GET /service_logic/read

Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK",
    "reason": [
        {
            "slg_name": "service_logic1",
        },
        {
            "slg_name": "service_logic2",
        }                
    ]
}

Read service logic information [/service_logic/read?slg_name={slg_name_value}]

Read Service Logic Information - GET /service_logic/read?slg_name={slg_name_value}

Parameters
slg_name_value (Required)
Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK",
    "reason": {
        "ss_side": "S",
        "sn_list":
            [
                {
                    "sn_package": "node1_pkg",
                    "sn_type": "node1_type",
                    "sn_side": "S",
                    "sn_name": "node1_name",
                    "sn_params": "node1_params"
                },
                ...,
                {
                    "sn_package": "driver1_pkg",
                    "sn_type": "driver1_type",
                    "sn_side": "R",
                    "sn_name": "driver1_name",
                    "sn_params": "driver1_params"
                }
            ],
        "sl_list":
            [
                {
                    "sl_package": "launcher1_pkg",
                    "sl_file_launcher": "launcher1_file",
                    "sl_side": "S",
                    "sl_name": "launcher1_name",
                    "sl_params": "launcher1_params"
                }
            ]
    }
}

Provisioning a service logic [/service_logic/provisioning]

Provisioning a service logic - POST /service_logic/provisioning

Request (application/json)

Headers

Content-Type: application/json

Body

{
    "slg_name": "service_logic1",
    "sn_list":
        [
            {
                "sn_package": "node1_pkg",
                "sn_type": "node1_type",
                "sn_name": "node1_name",
                "sn_params": "node1_params",
                "sn_side": "S"
            },
            ...,
            {
                "sn_package": "driver1_pkg",
                "sn_type": "driver1_type",
                "sn_name": "driver1_name",
                "sn_params": "driver1_params",
                "sn_side": "R"
            }
        ],
    "sl_list":
        [
            {
                "sl_package": "launcher1_pkg",
                "sl_file_launcher": "launcher1_file",
                "sl_name": "launcher1_name",
                "sl_params": "launcher1_params",
                "sl_side": "S"
            }
        ]
}
Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK",
    "reason": "The service logic with name 'service_logic1' has been provisioned correctly"
}

Unprovisioning a service logic [/service_logic/r_provisioning]

Rollback Provisioning a service logic - POST /service_logic/r_provisioning

Request (application/json)

Headers

Content-Type: application/json

Body

{
    "slg_name": "service_logic1",
}
Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK"
    "reason": "The provisioning of the service logic with name 'service_logic1' has been rolled back completely",
}

Platform Instances

Read robot instances [/platform_instance/read]

Read Robot Instances - GET /platform_instance/read

Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK",
    "reason": [
        {
            "pi_name": "robot1",
            "service_logic": "service_logic1",
            "connected": true,
            "paired": true
        }
    ]
}

Provisioning a robot [/platform_instance/provisioning]

Provisioning a Robot - POST /platform_instance/provisioning

Request (application/json)

Headers

Content-Type: application/json

Body

{
    "pi_name": "robot1",
    "pi_service_logic": "service_logic1"
}
Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK",
    "reason": "The platform node instance with name 'robot1' has been provisioned correctly"
}

Unprovisioning a robot [/platform_instance/r_provisioning]

Rollback Provisioning a robot - POST /platform_instance/r_provisioning

Request (application/json)

Headers

Content-Type: application/json

Body

{
    "pi_name": "robot1",
}
Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK"
    "reason": "The provisioning of the platform node instance with name 'robot1' has been rolled back completely",
}

Service Spaces

Read service space [/service_space/read?ss_name={ss_name_value}]

Read Service Space - GET /service_space/read?ss_name={ss_name_value}

Parameters
ss_name_value (Required)
Response 200 (application/json)

Headers

Content-Type: application/json

Body

{
    "result": "OK",
    "reason": {
        "r_nodes":
            [
                {
                    "sn_package": "node1_pkg",
                    "sn_type": "node1_type",
                    "sn_name": "node1_name",
                    "i_name": "master"
                },
                ...,
                {
                    "sn_package": "driver1_pkg",
                    "sn_type": "driver1_type",
                    "sn_name": "driver1_name",
                    "i_name": "robot1"
                }
            ],
        "r_launchers":
            [
                {
                    "sl_package": "launcher1_pkg",
                    "sl_file_launcher": "launcher1_file",
                    "sl_name": "launcher1_name", 
                    "associated_r_nodes": ["node1", ..., "nodeN"],
                    "i_name": "master"
                }
            ],
        "inbound_port": "10100",
        "public_ip": "..."
    }
}

Acknowledgements

The editors would like to express their gratitude to the following people who actively contributed to this specification: Gianmario Bollano, Pierangelo Garino

References