Developer Portal
Simple, configurable and easy to integrate, these are the tools every engineer needs to get the best out of InOrbit
Developer Portal


InOrbit is a RobOps platform aimed at resolving common infrastructure needs and integrating into the broader robotics solution. Here you can find a menu of the different options you can choose from including SDKs, APIs and tools.


All API and SDK access is authenticated with the InOrbit system using an API Key which can be obtained and managed through InOrbit Console, in the API Key section. An API Key is always associated with a service user in your account and its access is managed using role-based access control.

Integrating applications

These are interfaces that allow utilizing robot capabilities in other applications. There are various alternatives that are suitable for different types of applications and technologies.


InOrbit REST APIs are best suited for integrating robot functionality in custom applications and business workflows. They include methods to query online and historical robot data, execute remote actions, organize robots in collections, track ongoing and past mission status, inspect audit logs and more.


InOrbit's Embeds make it easy to include pre-made robot-specific UI components into any Web Client application. Through the InOrbit Console, you can configure dashboards with the widgets that you need for specific use cases and then using an embed code, make them available as part of your application, giving you total control of the user experience.

Configuration as Code

InOrbit's Configuration as Code makes it easier to define advanced configuration in a friendly format, thus allowing full control of the application with a refined granularity level.

Incident Management

InOrbit provides different ways to integrate robot monitoring capabilities into your overall incident management workflow. Through the Incident Management interface, it’s possible to dispatch robot alerts in real-time, react to them with context-specific actions from external systems and keep track of ongoing incident updates.

Out-of-the-box integrations with Slack, Google Chat, OpsGenie and PagerDuty can be configured through the InOrbit Console and are best suited for standard workflows.

An outgoing Webhook interface and incoming API are available to integrate with additional systems or implement custom integration behaviors. We’ve provided a code sample to make it easier to get started with these APIs.

Integrating robots

InOrbit provides different alternatives to connect your robots. This section will help you select the best option for your use case.

ROS-based agent

If your robot supports ROS, connecting it to InOrbit can be done in less than a minute using our Quickstart installer. From there, you can take control of the customization using a Debian or Docker based installation and/or applying advanced agent settings. You can also use and extend the InOrbit republisher ROS node to be in control of what specific data you want to expose.

Robot SDK

The Robot SDK enables developers to implement bidirectional communication between robots and the cloud using any robotics framework without using ROS. It leverages a stripped down version of the InOrbit agent to manage the communication between your robot and the cloud and provides simplified bindings for popular robot programming languages such as C++.

Edge SDK

The Edge SDK is useful for connecting robots from intermediary applications without requiring the installation of a software agent on individual robots. It provides a set of interfaces using language bindings to connect to the cloud and submit robot data selectively. This SDK is the recommended path for connecting the InOrbit platform through an existing Fleet Manager.

Interoperability standards

If your robot supports the Mass Robotics AMR Interoperability standard, you can connect it to InOrbit without installing any software or building on any SDK. You can configure and get the endpoint URL through the InOrbit Console. VDA-5050 compliant robots can be connected to InOrbit using the VDA-5050 to InOrbit Proxy. You can also find some open source tools and code samples to ease the implementation of interoperability standards on the robot side in our public GitHub organization.

Tools and samples

    Here are some open source code samples and tools to make it easier to integrate and manage robots:

  • The Google Chat Incident Management sample shows how to connect the InOrbit Incident Management webhook to dispatch alerts into a third-party system.

  • This Brickmart Executive Page shows how to use Embeds on a static site. You can see it live here

  • The ros_amr_interop repository brings together resources to help with the adoption of interoperability standards. It includes the massrobotics_amr_sender_py package, which allows you to make a ROS 2 robot compatible with the standard using only configuration.

  • The VDA5050 to InOrbit Proxy is a useful starting point for connecting VDA-5050 compliant devices to InOrbit and it also doubles as a sample code and starting point for using the InOrbit Edge SDK.

  • The ros_inorbit_samples repository provides code samples to make it easier to customize the integration of ROS robots with InOrbit. It includes the inorbit_republisher allowing you to use configuration to manage what data is published to InOrbit, and is available for ROS Melodic and Noetic.


InOrbit uses API keys to authenticate API requests, use of Embeds and calls from the Edge SDK. An API key identifies your company’s service user. This key provides security so that no one outside of your company can access your data.

To generate your API Key go to InOrbit Console and open the API Key tab. Here you’ll be able to create a new API Key for your company.


You should copy and save the generated key because it will not appear again. On this tab you are also able to delete the API Key, if you need to generate a new one or you don’t need to use it any more.

With the creation of a new API Key, InOrbit will create a new user named Service user, this user will be linked to the created API Key so that when the key is used the actions are logged under Service user.

Restricting API requests: To control access to the API requests made by your company you can change the role of Service user. You can create custom roles or use existing ones by simply changing the role of a user on the Admin tab in InOrbit Console.

API requests

Application Integration

This section describes different ways to integrate InOrbit and third-party applications, including the use of REST APIs and Embeds.

  • InOrbit REST APIs: provide programmatic access to InOrbit's functionality and are best suited for integrating with backend services.

  • Embeds: allow developers to build and embed dashboards containing robot or fleet level information into any applications using no-code.

  • Configuration as Code: allow customers to configure all InOrbit settings using code.

The following sections describe REST APIs, Embeds, and Configuration as Code in detail.


InOrbit offers REST and streaming APIs that enable programmatic access to InOrbit features. Using these APIs you can fetch data related to your robots, trigger actions, integrate with incident management systems and more.

  • Robots
  • Collections & Tags
  • Attributes
  • Localization & Maps
  • Navigation
  • Robot Lock
  • Actions
  • Incidents
  • Mission Tracking
  • Push APIs
  • Advanced Settings
  • Audit Logs

Check the APIs' documentation and specs here


InOrbit Embeds allows you to create a dashboard from InOrbit Console and embed it in any application. Leveraging Embeds you can show robot or fleet level information in your applications without having to implement the UI from scratch.

Some example use cases include:

  • Dedicated role based experience on a tablet for a Floor Operator
  • White-labeled end-user portal
  • Unattended team dashboard running on a centralized monitor
  • UI running on your robot’s physical screen to trigger actions

Defining an Embed

Embeds are created by defining a dashboard from the Console and then generating the embedding code for it.

To manage your dashboards go to Robot Data → Dashboards. From there you can create and edit dashboards, including setting visibility rules and modifying sections and widgets. As shown in the following image:


Using the gray plus sign you can add new sections. Each section has a name and scope, that can be robot or fleet.


Using the gray plus sign inside the section you can add widgets from the widgets palette, as shown below:


Once you have defined the dashboard, you are ready to embed it into your applications.

Using an Embed in your application

To generate the embedding code, go to InOrbit Console > Robot Data tab > Dashboards section and use the “< >” button on the right, near the top.


Clicking this button shows a code fragment that can be used to embed the dashboard into any HTML page.


You can customize the iframe’s properties to match your application layout. Remember to replace YOUR_APP_KEY_HERE with your InOrbit API Key.

The following image shows how an Embed looks as part of a web application from a fictional company named Brickmart:


Configuration as Code

Configuration as code allows you to customize different InOrbit settings using code. This way you can manage your settings using DevOps best practices and handle complex configurations in an efficient way.

Configurations can be coded using JSON and then be managed using InOrbit's command-line interface (CLI) or through REST APIs. The CLI is distributed as a python package and can be installed through pip.

Additionally, using configuration as code offers the following advantages:

  • Version control of changes
  • Workflows: PR, review, approve, traceability
  • CI/CD
  • Reusable and reproducible configurations
  • Rollback of changes
  • Security
  • Auditing
  • Software parametrization

Using configuration as code you'll be able to manage advanced settings in an efficient way.


InOrbit's configuration as code mechanism is built around the concept of configuration objects. These objects and their properties set how InOrbit and your robots must behave. For example a configuration object can define Incident rules.

    "kind": "<configuration_kind>",
    "apiVersion": "<api_version>",
    "metadata": {
        "id": "<configuration_id>",
        "scope": "<scope>"
    "spec": {
        "someProperty": "someValue",
        "anotherProperty": "anotherValue",

Each configuration object has the following general properties:

  • kind: Type of setting this configuration refers to, for example Incident. The supported kinds are described later in this document.
  • scope: The scope for which this configuration applies.
  • apiVersion: current API version.
  • spec: configuration values.

On the right you can see the schema in JSON format.

As said above, each configuration object applies to a specific scope, currently the following types of scopes are supported:

  • root: This is a system-wide level with default configurations.
  • company: Applies to the whole company. Can be specified using company or company/<COMPANY_ID>.
  • tag: Applies only to robots tagged with a specific tag. Can be specified using tag/<COMPANY_ID>/<TAG_ID>.
  • robot: Applies only to a specific robots. Can be specified using robot/<COMPANY_ID>/<ROBOT_ID>.

Scopes behave like a hierarchy, each level inherits the values from its parent and can override them or suppress them.

Suppress means that the configuration object must not be inherited from top levels for the specified scope. This is done by setting the spec to null.

How to Install the CLI

This section explains how to install and configure InOrbit's CLI. The CLI allows you to apply, list and clear configurations, between other functionalities. Make sure that you have Python 3 already installed in your system.

Installing the Package

pip install -i "" inorbit-cli

The inorbit-cli package. can be installed using pip by running the command on the right.

Configuring Environment Variables

# Example configuration of environment variables for the CLI
export INORBIT_CLI_API_KEY="company_api_key"
export INORBIT_CLI_VERBOSE="true" #optional

Before using the CLI, you'll need to configure the INORBIT_CLI_API_KEY with your API key. You can get the API key from the Developer Consoler.

The CLI verbose mode can be enabled by setting the INORBIT_CLI_VERBOSE environment variable to true.

Getting Started with the CLI

By typing the inorbit or inorbit --help command, you will find the CLI's help shown below.

The CLI provides the following main commands:

  • apply: Applies a configuration object.
  • delete: Deletes a configuration object.
  • get: Lists or dumps configuration objects.
  • describe: Get detailed information about configuration objects.

Listing Tags and Robots

To learn more about your current fleet, company, or tags, just run the inorbit describe <entity> command. You can query the following entities:

  • collections: Describe all collections and detailed collection data.
  • robots: Describe all robots and detailed robot data.
  • tags: Describe all tags and detailed tag data.

Applying a Configuration Object

The apply command can be used to create or update configuration objects. To apply a configuration object follow the steps described below:

  1. Create a JSON file describing the configuration object. (The reference schemas for the different kinds are described in following sections)

  2. Run inorbit apply -f config_file.json. If everything goes well, you'll a message like Configuration <config/file/path> applied successfully.

  3. You can use inorbit get config --scope "<scope>" --kind "<kind>" "<object_id>" --dump to check that the configuration object was correctly saved in InOrbit.

Deleting a Configuration Object

To delete a configuration object, run inorbit delete config --kind "<kind>" "<object_id>" --scope "<scope>".

To make sure that the configuration object was deleted, run inorbit get config --scope "<scope>" --kind "<kind>" "<object_id>" and check that there are no results.

Listing Configuration Objects

To get the configuration objects for a kind and scope, run inorbit get config --scope "<scope> "--kind "<kind>". This will output a table like the one below:

id                          kind    label          scope                     suppressed
--------------------------  ------  -------------  -------                   ------------
_K-3m47ys1eAHf1m            Kind    Some Label     company/Zasdasdjhj3a       False
Iyz65CWu4u1PoWnB            Kind    Other Label    tag/Zasdasdjhj3a/Lcm3      False
TfeF86osrfFhc-Q0            Kind                   robot/Zasdasdjhj3a/MasdJ6  True

You can also use the --dump option to dump the contents of the objects instead of just listing them.

Note that you can use --scope "*" to list any configuration object of the specified kind that applies to your account.

Configuring: Incident Definitions

Incident Definition Configuration Object Schema

    "kind": "IncidentDefinition",
    "apiVersion": "v0.1",
    "metadata": {
        "id": "string",
        "scope": "string"
    "spec": {
        "statusId": "string",
        "label": "string",
        "warning": {
            "notificationChannels": [],
            "autoActions": [],
            "manualActions": [],
            "severity": "string"
        "error": {
            "notificationChannels": [],
            "autoActions": [],
            "manualActions": [],
            "severity": "string"

Example incident definition with associated actions and notification via Slack.

    "kind": "IncidentDefinition",
    "apiVersion": "v0.1",
    "metadata": {
        "id": "yYHwWlQyineQtfW6",
        "scope": "company"
    "spec": {
        "statusId": "yYHwWlQyineQtfW6",
        "label": "My Battery Incident",
        "warning": {
            "notificationChannels": ["app"],
            "autoActions": [],
            "manualActions": ["RunScript-e5DhI8"],
            "severity": "SEV 2"
        "error": {
            "notificationChannels": ["app", "slack#support"],
            "autoActions": ["PublishToTopic-S84KUC"],
            "manualActions": ["RunScript-e5DhI8"],
            "severity": "SEV 0"

Incident definitions allow you to setup rules about when and how incidents are triggered and notified based on the configured statuses. You can configure how incidents must be notified, their severity levels, associated actions and more.

Each incident definition has the following main properties:

  • id: Identifies the definition.
  • statusId: status used as the trigger of these incidents.
  • scope: References the scope at which the definition is set.
  • warning: Defines rules to handle the case when the associated status is in "warning" state. Including the notification channels, severity level and associated actions.
  • error: Defines rules to handle the case when the associated status is in "error" state.
  • label: A descriptive label for the incident.

Incident definitions can be set at any of the following scope levels:

  • Company
  • Tag
  • Robot

Creating a definition with the same id at different scopes, you can refine or suppress the incident rules for a subset of your fleet.

The valid notification channel options depends on the integrations that you have configured on your account. These are the available options.

  • InOrbit application: app
  • Slack: slack#...
  • Google Chat: googleChat
  • OpsGenie: opsgenie
  • Webhook: webhook

For example to get notified in the App and also in the Slack channel #alerts, you should set the notification channels like this: notificationChannels: ["app", "slack#alerts"].

Finally, the valid severity levels are: SEV 0, SEV 1, SEV 2, and SEV 3.

NOTE: You can use the REST API to get the lists of valid status and actions ids.

You can find the full specification of the IncidentDefinition kind in JSON schema format at io-config-as-code repository.

Robot Integration

This section describes tools and libraries that can be used to connect robots to InOrbit. The connection can be made from the individual robots or from servers running on the edge.

Depending on the selected solution architecture, you can pick one of the following SDKs:

  • Robot SDK helps developers implement a bidirectional communication channel between robots and InOrbit. It can be used to feed robot data into InOrbit and then implement actions, such as teleoperation and more. The Robot SDK also streamlines integration with ROS and ROS2 by allowing developers to map ROS topics to InOrbit using simple configuration files.
  • Edge SDK simplifies the integration with third-party or custom applications, like fleet managers, or warehouse management systems. It can be used to fed data gathered by edge servers into InOrbit.

The following sections describe both SDKs in detail and provide examples about their usage.

Robot SDK

The Robot SDK enables developers to implement bidirectional communication between robots and the cloud. It leverages the InOrbit agent to implement the core communication mechanism in an efficient and secure way. Particularly the agent takes care of:

  • Adaptive sampling & throttling
  • Connection handling & offline buffering
  • Security / Encryption
  • Scripted actions
  • Video processing

The Robot SDK provides various methods to ease communication between the agent and other software running on your robot, including:

  • Language Bindings: High-level language-specific APIs that communicate with the agent. Currently the only supported programming language is C++11.
  • Helper components: reduce integration friction with ROS-based robots, but providing zero-code integration mappings from ROS topics.

The following diagram shows how the InOrbit agent interfaces with other software running on the robot:

Robot SDK Interfaces

Software on the robot can communicate with the agent using various mechanisms, depending on the chosen software stack.

Integrating with C++

The Robot SDK for C++ is provided as a C++11 header-only library that can be used to communicate with the InOrbit agent from C++ programs. The library can be downloaded from the Robot SDK for C++ GitHub repository. Note that it is designed to work with the non-ROS InOrbit agent (the Setup section explains how to install the agent).

Using the InOrbit Robot SDK C++ Library you’ll be able to publish data from your programs as shown in example in the right column:

#include "robot-sdk-cpp/include/inorbit/inorbit.hpp"
int main() {
 // Create an InOrbitSDK object
 inorbit::InOrbitSDK sdk;

 // Publish custom data
 sdk.sendKeyValue("battery", 0.56);

 // Publish the pose
 double location[] = {5, 4, 0};
 double rotation_quaternion[] = {0, 0, -0.131, 0.991};
 sdk.sendPose("my_reference_frame", location, rotation_quaternion);
 return 0;

The example uses the InOrbitSDK class to publish the pose of the robot and it’s battery level.

Non-ROS agent installation

To integrate from C++ you must use the non-ROS InOrbit agent. It can be installed in different ways, including via a Debian package. For simplicity in this documentation a one-line command that downloads and executes the agent installer is used. After installing the agent you’ll be able to start seeing data from your robot, such as CPU usage, when using InOrbit.

As a prerequisite you’ll have to fetch your company key to add a robot to InOrbit. You can get the key from the InOrbit Console in the “Add Robot” page as shown in the next image:

Developer Console Add a Robot

Your company key is the last segment of the URL, A9wXdA5dsD5in this screenshot. Take note of it since you’ll need it for the next step.

Run the following one-line command on your robot to install the agent, remember to replace ${YOUR_COMPANY_KEY} with the key you obtained in the previous step:

curl "${YOUR_COMPANY_KEY}?variant=nonros" | sh

Executing the command will trigger the agent installation process, follow its steps to get the agent running on your robot.

After completing the installation, the agent will automatically start and connect to InOrbit. By default the robot name is its “hostname”.

To be sure that everything is configured correctly you can try the following command to check that the agent is up and running:

curl http://localhost:5000

Executing the above should produce the following output: “InOrbit Agent API: OK”.

If for some reason you don't see your robot connected or reporting data, check the agent logs at ~/.inorbit/local/inorbit_agent.log. You are welcome to contact our Support Team if you need additional help fixing the problem.

You can customize the port and binding address used by the agent by editing ~/.inorbit/local/ and setting the following variables:

  • INORBIT_AGENT_API_PORT: Port used by the agent to listen for connections from the SDK, default values is 5000.
  • INORBIT_AGENT_API_BINDING: Address used by the agent to listen for connections from the SDK, default value is “localhost”.

Installing the C++ library

You can use the following command to include the library in your project as a git-submodule:

git submodule add robot-sdk-cpp

This command will create a new directory named robot-sdk-cpp containing the C++ library.

The InOrbit Robot SDK C++ Library is a header-only C++11 library that encapsulates the communication between C++ programs and the InOrbit agent. It is licensed under the MIT license.

Depending on your preferences, you can add the library to your project in a few different ways. The recommended way, if you are already using Git, is to use git-submodules to include the library's repository in your project. Another option is to just grab the files from the repository and copy them into your project.

Note that if you prefer you can download the library from its repository at GitHub.

Publishing data from C++

#include "robot-sdk-cpp/include/inorbit/inorbit.hpp"
int main() {
  // Create an InOrbitSDK object
  inorbit::InOrbitSDK sdk;
  return 0;

All the functionality provided by the SDK library is encapsulated in a class called inorbit::InOrbitSDK, so the first steps to communicate with the InOrbit agent is to include the library and then create an object of this class. This is shown in the code block on the right:

This code includes the library, added to the project in the previous section, and creates the sdk object.

By default the sdk object will talk to the agent using TCP, targeting localhost on port 5000. These and other parameters can be changed using more verbose versions of the constructor.

InOrbitSDK(const std::string &agent_host, int agent_port, bool log_errors);

Using this constructor, you can set the agent host, port and if errors should be reported on stderr (default is true).

The sdk object created in the previous step has a sendPose method that you can use to publish poses data from your program. It receives the reference frame, the robot position and its orientation as a quaternion.

Note that InOrbit uses the Right-hand rule to define the axes and rotation ordering, with X representing the forward direction and Y representing a direction towards the left of the robot. The SDK also uses the XYZW notation for quaternions. So, if you are using a different convention for your localization data, you must apply a conversion before calling sendPose.

#include "robot-sdk-cpp/include/inorbit/inorbit.hpp"
int main() {
 // Create an InOrbitSDK object
 inorbit::InOrbitSDK sdk;

 // Publish the pose
 double location[] = {5, 1, 0};
 double rotation_quaternion[] = {0, 0, 0.383, 0.924};
 sdk.sendPose("map", location, rotation_quaternion);
 return 0;

The example on the right shows how you can publish a pose to InOrbit:

The code reports the robot pose as being at x = 5, y = 1, z = 0 with a yaw of 45 degrees counterclockwise in the map reference frame.

The sdk object also provides a sendKeyValue method that you can use to publish almost any data value from your program. You can use this method for different data types, including double, integer and strings.

The example on the right shows how you can publish different values to InOrbit:

#include "robot-sdk-cpp/include/inorbit/inorbit.hpp"
int main() {
 // Create an InOrbitSDK object
 inorbit::InOrbitSDK sdk;

 // Publish custom data of different types: string, double, integer
 sdk.sendKeyValue("battery", 0.56);
 sdk.sendKeyValue("pending_tasks", 4);
 sdk.sendKeyValue("serial", "dd2bc73b");

 return 0;

This code publishes the battery level, number of pending tasks and the serial number of the robot. The reported data can be queried using APIs or be visualized from InOrbit Control.

Integrating with ROS 1

The InOrbit agent includes native support for ROS, using the publish/subscribe communication mechanism to exchange data with other software running on your robot. The agent automatically detects topics about maps, cameras and more. You can fine tune this configuration from InOrbit Console.

Publishing Custom Data

rostopic pub /inorbit/custom_data/0 std_msgs/String "battery=55"
rostopic pub /inorbit/custom_data/0 std_msgs/String "status=docked"

The SDK custom data mechanism, allows you to publish telemetry data, static/semi-static robot attributes, and events from your robot to InOrbit.

You can publish any string data to /inorbit/custom_data/0 to send it to InOrbit. You can easily send different elements by publishing a key-value pair either by writing a custom node or by leveraging InOrbit's configuration-based republisher node.

The example on the right shows how to publish some values.

Installing and configuring the InOrbit republisher

  - topic: "/mission_data"
    msg_type: "my_custom_msgs/MissionData"
    - field: "goal_id.stamp"
        topic: "/inorbit/custom_data/0"
        key: "mission_status_goal_timestamp"
    - field: "status"
        topic: "/inorbit/custom_data/0"
        key: "mission_status"
  - topic: "/errors"
    msg_type: "my_custom_msgs/CustomError"
    - field: "error"
        topic: "/inorbit/custom_data/0"
        key: "error_code"
    - field: "error_message"
        topic: "/inorbit/custom_data/0"
        key: "error_string"

The node republisher can be installed like any other standard ROS package e.g. for noetic you'd need to install ros-noetic-inorbit-republisher. To illustrate how to use it, let's assume you want to publish data from a complex custom message my_custom_msgs/ComplexCustomMessage.

The InOrbit republisher configuration shown on the right creates the required publishers and subscribers in order to send the data to InOrbit. To see all the possible parameters, please refer to InOrbit's configuration-based republisher node.

The messages that will arrive at InOrbit read:

  • Two key-value messages for each message on the topic /mission_data:

    • mission_status_goal_timestamp=123456789
    • mission_status="ok"
  • Two key-value messages for each message on the topic /errors:

    • error_code=9
    • error_string="something went wrong"

Running the InOrbit republisher

This node can be executed by using the roslaunch tool and a ROS launchfile pointing to the republisher configuration file, as shown in the example.

  <node name="inorbit_republisher" pkg="inorbit_republisher" type="">
    <param name="config" textfile="/path/to/config.yaml" />

Integrating with ROS 2

The InOrbit agent includes support for ROS 2, using the publish/subscribe communication mechanism to exchange data with other software running on your robot.

Publishing Custom Data

ros2 topic pub /inorbit/custom_data/0 std_msgs/String "{data: 'battery=55'}"
ros2 topic pub /inorbit/custom_data/0 std_msgs/String "{data: 'status=docked'}"

The SDK custom data mechanism, allows you to publish telemetry data, static/semi-static robot attributes, and events from your robot to InOrbit.

You can publish any string data to inorbit/custom_data/0 to send it to InOrbit. You can send different elements by publishing a key-value pair, as shown in the example on the right.

Edge SDK

The Edge SDK can be used to build integrations between third-party or custom applications running on the edge and the InOrbit platform. For example, it can be used to feed data from a fleet manager system into InOrbit, without requiring the installation of software on your individual robots.


Here a custom component acts as a proxy between the fleet manager system and InOrbit cloud using the Edge SDK.

Any data fed into InOrbit can then be used and queried from other components, like InOrbit Control or REST APIs. This SDK allows the publishing of data related to multiple robots, including their connection state, odometry, poses and any custom attributes you’d like to track..

The Edge SDK is distributed as a NPM package, and you can check the package’s web page at InOrbit Edge SDK npm package for more information. It can be run from Javascript and Typescript projects.


npm install inorbit@edge-sdk

The Edge SDK can be installed using npm by running the command from the right. This adds the edge-sdk package as a dependency of your project.

Using the SDK

This section explains how to initialize the Edge SDK and publish data to InOrbit. As a prerequisite you should have already installed the npm package and obtained your InOrbit API key.


The first step is to initialize the SDK by creating an InOrbit object as shown in the next code block:

import { InOrbit } from '@inorbit/edge-sdk';

const sdk = new InOrbit({ appKey: "YOUR_INORBIT_APP_KEY" });

The code above imports the edge-sdk package and creates the sdk that can then be used to publish robot related data to InOrbit.

Reporting robot connection status

The sdk object can be used to report the connection status of each robot to InOrbit. In order to do this, you need to know the IDs of your robots and use the connectRobot and disconnectRobot methods, as shown here:

const robotId = '12345';
await sdk.connectRobot({ robotId, name: 'MyRobot' });

// Sleep some seconds

await sdk.disconnectRobot(robotId);

The code reports the robot with id 12345 as connected and then as disconnected. Note that when a robot is reported as online, you can also optionally report its name.

The following sections show how data can be published. Note that the robot must be reported as “online” before publishing any data.

Publishing poses

The publishPose method can be used to report a time stamped pose to InOrbit as shown here:

const robotId = '12345';
await sdk.publishPose(robotId, {
  ts: new Date().getTime(),
  x: 5,
  y: 3,
  yaw: 0,
  frameId: 'map'

The code here reports that the robot with id 12345 is currently at the position (5, 3) in the “map” reference frame.

Publishing odometry

The publishOdometry method can be used to report odometry data to InOrbit as shown here:

const robotId = '12345';
await sdk.publishOdometry(robotId, {
  tsStart: new Date().getTime(),
  ts: new Date().getTime(),
  speed: {
    linear: 10,
    angular: 1

This code reports that the robot with id 12345 is moving with a linear speed of 10 m/s and an angular speed of 1 rad/s.

Publishing other attributes

Other custom attribute can also be reported using the publishCustomDataKV method, as shown in the next code block:

const robotId = '12345';
await sdk.publishCustomDataKV(robotId, {
  battery: 60,
  status: 'Idle'

The code here reports two custom attributes, battery and status.

Final Notes

Using the Edge SDK allows you to feed data from multiple robots into InOrbit. Contact us if you need help to use this SDK, integrate it with your software or generate your robot IDs.

Complete examples about using the Edge SDK to publish data from multiple robots to InOrbit can be found at:


This section details the different solutions provided by InOrbit Platform to work with robot interoperability standards, such as VDA 5050 and MassRobotics AMR interoperability. These standards are useful to orchestrate heterogeneous fleets that mix robots from different vendors.

Companies that use robots can leverage InOrbit Platform to connect standards compliant robots to the cloud without having to set up dedicated infrastructure. It’s also possible to connect robots that use different standards and orchestrate them in a homogeneous way using InOrbit’s UI and/or APIs.

Robot makers can also benefit from InOrbit Platform by using its open source packages to make any robot standard compliant using just configuration files.

The following sections detail the different interoperability options and solutions included in InOrbit Platform for different standards.

MassRobotics AMR Interoperability

The MassRobotics AMR Interoperability Standard allows AMRs from different vendors to publish information about their state, location, velocity, health, etc using a well defined set of messages. Data transmission is done over web sockets.

Robots compliant with this standard can be connected to InOrbit without requiring the installation of the InOrbit agent on them. ROS2 based robots can become compliant with the standard using the massrobotics_amr_sender package.

Connecting robots to InOrbit

Standard compliant robots can be connected to InOrbit without requiring the installation of the InOrbit agent. To do so, you have to configure your robots to point to InOrbit’s receiver.

You can find the receiver URL for your account in the Console, under Admin → Interoperability.


The next step is to configure the receiver URL on your robots to start sending data to InOrbit. The details about this step depend on your specific robot model and software.

Making ROS2 robots compliant with the standard

Using the open source massrobotics_amr_sender ROS package, ROS2 based robots can become compliant with the standard using just configuration files. Check the package documentation for more details and examples.

VDA 5050

The VDA 5050 V 1.1. AGV Communication Interface describes the communication interface for exchanging order and status data between a central master control and automated guided vehicles (AGV).

You can leverage InOrbit Platform infrastructure to provision the required components, including the MQTT broker, and connect your VDA 5050 compliant robots to the cloud.

Contact our support team for more information.