Request Demo



InOrbit is a cloud platform for robot management. It's easy to get started receiving real-time data from your robots. Almost everything is customizable and extensible.

Read on to learn how to get the most out of InOrbit. Need some extra help? Contact us at

Getting started

InOrbit Control is a tool for managing robots and viewing robot data.

It gives you an at-a-glance view of your robots. The view is divided into several sections. From top to bottom, the details go from most general for the entire robot fleet to most specific for a single robot:

  • Key Performance Indicators (KPIs) across the top
  • Robot Fleet View in the middle
  • Individual robot details at the bottom
About Customizing InOrbit Control

Each section consists of widgets that display certain kinds of data.

The view of all data in all sections can be customized to your liking by adding or deleting widgets or by adding details in the Settings pages. You can define customers, robot operating modes, robot locations, and more.

These customized view can be associated with different types of user roles. For example, for an executive, you might want to create a custom view that displays only the summarized data without details.

Described here are the default widgets before customization.

Key Performance Indicators (KPIs)

At the top of InOrbit Control are Key Performance Indicators (KPIs) for your entire robot fleet. KPIs are a summation of details, showing real-time, aggregate data about the fleet.

The default KPIs before any customization are as follows:

KPI Description
Active Robots The number of active robots over the number of robots in your fleet
Robots per user Number of robots assigned to your operators
Odometry Physical distance travelled by all robots
Incidents Resolved Number of resolved problems (also called “incidents”)
Open Incidents Number of problems still needing attention
Robot Fleet View/Status

The Robot Fleet View widget is a table of the status of characteristics of your robots.

Fleet View by default has minimized data but can be maximized to display even more information. To see the maximized view, which includes deeper detail about locations, a timeline of component usage, and a list of incidents for all robots, on the far right above the minimized view, click the square icon.

Descriptions of the parts of minimized Fleet View are below.

Section Description
Fleet If robot collections have been defined, use the collections pulldown menu to select the collection you want to see. (A collection of robots is a group that you define for easier management. By default there are no collections, so Fleet View shows all robots.) You can group the fleet view by the following fields: Ungrouped (default), Location, Hardware, Customer, and Mode. Without customizing the fields, the groupings have no effect. Mode has some defaults: idle, charging, on mission, and more.
Status On the left of the table are the characteristics of the robots for each row of the table. The default characteristics are Battery, Disk Usage, RAM usage, Diagnostics, Localization, ROS Status, and payload weight.
Robot list The columns of the table list the color-coded status of the characteristic of individual robots. Red is error, yellow is warning, and blue is OK.
Robot names Names of robots are below the table. Use the scroll bar at the bottom to see the status of other robots in the fleet. Beneath each robot name, the mode of the robot is displayed.
Individual Robot Details

At the bottom of InOrbit Control is a view of the most specific details about an individual robot. You can also perform certain actions on a robot.

In the ROBOT / field, enter the name of the robot whose details you want to see. Across that row some widgets are displayed: SETTINGS, RESTART AGENT, TELEOP, UPDATE AGENT, and the number of collections to which the robot belongs.

Some of the default widgets in individual robot details include the following:

  • Vitals
  • Hardware
  • Operating Metrics
  • Mission Parameters

The list and order of the widgets can be customized to your liking.

With only these simple steps, InOrbit gives you near near instant results for managing your robot fleet:

  1. Set up your InOrbit account.
  2. Add a robot.
  3. View the robot's vital signs.

Follow these steps to get your robots InOrbit.

What you need
  1. In your browser, go to InOrbit Control.
  2. Click Sign in with Google.
  3. In the displayed dialog, click the desired Google account name to use to sign in.
  4. On the "Preparing for launch..." page, enter the name of your company or keep the default.
  5. Click Launch InOrbit.

The initial blank InOrbit Control dashboard is ready for you to add robots to your InOrbit fleet, configure settings, view metrics and KPIs, and more.

Here’s how you add a new robot to your InOrbit fleet. The process involves copying and running a command on your robot's command line to install the InOrbit agent.

What you need
  • Internet access from your robot
  • Shell access on your robot
  1. Log in to InOrbit Control.
  2. Scroll below the fleet list to find and click the circled + sign.
  3. Select and copy the displayed curl command.
  4. Log in to your robot's Linux shell.
  5. At the command line, paste the copied curl command.
  6. Hit enter to continue through the InOrbit agent installation process. See notes below.
  7. After the installation is complete, you are returned to the shell command line.
  • You are prompted to enter your username and other other information needed by the installer.
  • You are kept informed of the installation progress, including installation of software required by the InOrbit robot agent.
  • You might be instructed to enter various commands, such as sudo, as required by the installer.
  • The InOrbit agent is now installed on this robot.
  • The robot's host name in displayed in the list of your fleet on InOrbit Control.
  • InOrbit begins collecting data about your robot for you to examine on InOrbit Control.

After you've added a robot, you can see its operational status and vital signs directly on InOrbit Control.

What you need
  1. In your browser, go to InOrbit Control at
  2. If prompted, login with your Google account.
  3. In the fleet view of your robots, click the name of the robot you want to drill down on.
  4. Scroll down to see the robot's vital signs in the lower left of InOrbit Mission Control.

InOrbit Control shows you at-a-glance details about your robot's operational status:


Scroll down to see other valuable operational details about your robot, including operating metrics, mission parameters, network usage, and more.

Here’s how you invite a new user to your InOrbit account. This provides the authentication to enable colleagues to have individual access to a shared InOrbit account.

What you need
  • An active InOrbit account
  • Owner privileges on the account
  • Email addresses for any users you want to invite
  1. Log in to InOrbit Control.
  2. Go to Settings->Admin->Company Details->People.
  3. Click the circled + sign.
  4. Enter 1 or more email addresses separated by commas or spaces.
  5. Select the role (e.g., Owner, Administrator, User) that the new user(s) will be granted.
  6. Click SEND INVITES.
  7. User(s) should receive an email to confirm and will be added after confirming.
  8. After confirming, users can log in to InOrbit Control with the privileges for that role.
  • Roles can be configurable, but Owner is the only default role authorized to invite users.
  • Invited users will appear in a Pending state in the People list until they have confirmed.
  • While a user is Pending, a login link is available on their entry that can be copied and directly shared with them as a backup.
  • The invited users have individual logins to the shared account.
  • The invited users start with their assigned role, which can be modified by account Owners.

Advanced topics

You can augment InOrbit’s default robot data with your own custom settings to view specific information/robot attributes you want to see on InOrbit Control.

As described in A look at InOrbit Control, when you add a new robot, InOrbit Control displays default data/information of a robot, such as CPU Usage, HDD Usage, and RAM. These are called “Built-in” attributes.

You can configure InOrbit to capture other desired attributes of particular interest to you, such as system or robot metrics, sensor readings, software component details, and application-specific values. You customize your robot data via the Settings menus in InOrbit Control. A custom attribute applies to all robots in your entire fleet. Custom attributes can then be used for real-time monitoring, to visualize values over time directly in InOrbit Control, to track overall fleet status or to trigger notifications when something is not within expected tolerances.

Background: Data Sources

InOrbit supports the following data sources. These data sources are obtained from the Robot Operating System (ROS) installed by the InOrbit agent on each robot. (For more information about ROS itself, see the ROS Wiki.) InOrbit also supports additional non-ROS data sources. For assistance in configuring non-ROS data sources, contact InOrbit via e-mail at

Type of Data Description
System metrics CPU usage, RAM usage, specific HDD partitions, or network interfaces.
ROS Diagnostics  If you use ROS and have nodes that publish values in the /diagnostics or /diagnostics_agg topics, InOrbit can be configured to work with this data.
Custom key/value pairs If you use ROS and want to view a specific data value from your robot, you can publish a std_msgs/String message with the form key=value to the /inorbit/custom_data/0 topic on the agent; for example, apples=10.
What You Need
Tutorial Steps

This tutorial has two general parts: defining a custom robot attribute and displaying that attribute on InOrbit Control. These steps focus on a specific robot attribute for viewing: usage of the eth0 network interface on your robot.

Part 1: Define the eth0 custom robot attribute
  1. As Administrator, login to InOrbit Control.

  2. From the menu of three vertical dots at upper right, select Settings.

    Result: You are positioned on the Robot Data tab, which is divided into sections: Data Sources, Status, and Visualization.

  3. To add the new data source, under the Data Sources heading, click the circled + sign.

    Result: A new empty slot for the custom attribute is displayed.

  4. Define the attribute you want to add in two ways:

    1. Select the pulldown menu at the right of the new slot (the upside down ^) to view pre-defined system attributes.

    2. In the empty slot, begin typing the name of the attribute you want to add. InOrbit displays matching data source names that it discovers from your robots such as the different network interfaces, HDD partitions, ROS Diagnostics tools or custom key/value pairs.

    In this tutorial, we want to see the eth0 data source. From the pulldown menu, find and select eth0.

    Result: the custom attribute is added to the bottom of the list of Data Sources. It is also added to the bottom of the lists in the Status and Visualization sections.

  5. To add a more user-friendly name for the attribute, scroll to the bottom of the Data Sources list, find the newly defined attribute, and enter the user-friendly name in the first field. The user-friendly name is also updated in the Status and Visualization sections.

Result: You have defined the new custom eth0 attribute, and InOrbit automatically saves the new configuration.

Part 2: View the eth0 custom robot attribute on InOrbit Mission Control and change its position

InOrbit adds a new custom attribute defined in Data Sources to the Status and Visualization sections in Settings.

To see the new custom attribute, go to InOrbit Control and scroll down to find the new attribute.

Changing an attribute’s position on InOrbit Control

In Settings > Robot Data, by default, a new attribute is appended to the Visualization list. This means that on Mission Control, the new attribute is shown last.

To change the position of the attribute on InOrbit Control:

  1. Go to Settings > Robot Data.
  2. Find the attribute in the Visualization list.
  3. Grab the = handle to the left of the attribute.
  4. Drag the attribute up or down in the Visualization list to the desired display position.

Result: Return to InOrbit Control to see the attribute in the new position.

As discussed in View custom robot data, in addition to the default robot data sources, you might have created other sources of data from your robots that you want to see on InOrbit Control.

You can set thresholds on the data sources to trigger warnings or errors when a threshold is exceeded, alerts about those warnings or errors, and actions to take when a warning or error is triggered. An exceeded threshold is called an incident and is recorded in the incidents total shown on InOrbit Control.

  • Threshold values depend on the robot data source, such as disk space usage or camera state. Each threshold is defined by a function, which also depends on the data source. Some functions are as follows:
    • max-time is a length of time a condition must last before the threshold is exceeded.
    • always means that the condition is binary: either always on or off.
    • not equal to a value you specify
  • Alert channels are any of the following:
    • InOrbit Control itself, called In App.
    • PagerDuty, optional
    • Slack, optional
  • Actions can be any of the following. You can also show these actions on InOrbit Control’s Robot Actions widget.
    • Restart InOrbit agent on robot
    • Run a shell script that you have put on the robot
    • Go to a specific InOrbit page
    • Open a specific URL

Example. For a robot’s CPU usage, you might want to set these values:

Incident type Threshold Alert channel Action
Warning 85% CPU usage for 60 seconds or more In app Run script on robot
Error 95% CPU usage for 30 seconds or more Slack Restart InOrbit agent
About on-robot shell scripts

On-robot shell scripts you can run after an incident are Linux scripts that you yourself write and are completely under your control.

Continuing the example above about a warning of exceeded CPU usage, you might write a script that lists the top 10 running processes on the robot and saves the list to a file. Such a script could look like the following.

# !/usr/bin/bash
# where to save the script output
export SAVEFILE="/tmp/top10cpu.txt"
# list top 10 processes' percentage of CPU, PID, username,
# and running program with arguments, sorted by percentage of CPU,
# and saved to a file
ps -eo pcpu,pid,user,args | sort -k1 -r -n | head -10 \
  • Store the script in ${HOME}/.inorbit/local/user_scripts.
  • Make note of the name of the script on the robot because you need to specify the name when you define the action.
Setting up thresholds, alerts, and actions

These are steps to define thresholds, alert channels, and action.

What you need
  • Decide the data sources for which you want to define incident management.
  • Any on-robot scripts you want to run.
  • Pager Duty. If you want to send alerts, you must have Pager Duty installed and running.
  • Slack. If you want to send alerts to it, you must have Slack installed and running.

Automated incident responses have two general parts:

  • On the Settings > Robot Data tab, setting warning and error thresholds for the data source.
  • On the Settings > Status tab, defining alert channels and actions to take for warnings and errors.
Define thresholds
  1. As administrator, login to InOrbit Control.

  2. In the upper right, click Settings.

  3. Click the Robot Data tab.

  4. Scroll to find the desired robot data source whose thresholds you want to define.

    Not all data sources have the same definable fields, which depend on the type of data source.

  5. From the function pulldown menu, select the desired function. The function depends on the data source.

    For example, CPU and disk usage uses the max-time function.

  6. For the error at field, enter the error threshold.

    For example, for CPU, enter a percentage.

  7. For the warning at field, enter the warning threshold.

    For example, for CPU usage, enter a percentage.

  8. For the for sec. field, enter the length of time that the warning or error condition must last before the threshold is exceeded.

  9. For status label, keep the default label or enter a a different label for this data source.

Define alert channels and actions
  1. As administrator, login to InOrbit Control.
  2. In the upper right, click Settings.
  3. Click the Robot Data tab.
  4. Scroll to find the Status section.
  5. Scroll to find the desired robot data source whose alert channels and actions you want to define.
  6. For the ERROR block, select values for the following fields:
    • Alert channels
      • In App
      • Optional Pager Duty
      • Optional Slack
      • All of these channels
    • When triggered run:
      • Restart agent
      • Run script on robot. Enter the name of the script in ${HOME}/.inorbit/local/user_scriptson the robot.
    • When notified, user can run
      • Restart agent
      • Run script on robot. Enter the name of the script in ${HOME}/.inorbit/local/user_scriptson the robot.
  7. For the WARNING block, repeat the preceding step.


When you create your account, InOrbit will start with a default configuration, which tracks only a few attributes from your robots, such as CPU Usage, HDD Usage and Network Rate.

You can configure InOrbit to capture more meaningful attributes for your particular operation, such as additional system or robot metrics, sensor readings, software component vitals or application-specific values.

Any attributes you configure can then be used for real-time monitoring, to visualize their values over time, to track overall fleet status and to trigger notifications when something is not within expected values.

These configurations are managed in the Data Sources section of the settings screen, accessible through Menu > Settings:


InOrbit currently supports the following data sources:

  1. System metrics

    You can monitor CPU usage, RAM usage, specific HDD partitions and network interfaces.

  2. ROS Diagnostics values

    If you use ROS and have nodes that publish values in the /diagnostics or /diagnostics_agg topics, InOrbit can be configured to pick up any of these values.

  3. Custom key/value pairs

    If you are using ROS and want to publish an arbitrary value from your robot, you can publish a std_msgs/String message with the form key=value (e.g; apples=10) to the /inorbit/custom_data/0 topic on the agent.

  4. Other types / non-ROS

    InOrbit also supports additional and non-ROS data sources, which can be enabled per customer request. Please let us know about your need via e-mail at

In order to make it easier to configure, InOrbit lets you search over the data sources that it can discover from your robots. Simply start typing in the box to filter between the different network interfaces, HDD partitions, ROS Diagnostics tools or custom key/value pairs:


NOTE: In order for InOrbit to be able to discover the available data sources on your robot, it is important that the agent be running before you attempt data source configuration.

InOrbit allows configuring custom actions you can use to quickly and efficiently resolve issues or incidents that occur as part of operating your robot fleet.



InOrbit currently supports the following types of actions:

  1. Publish on a ROS topic

    Publish a configurable string value through the /inorbit/custom_commands topic on the robot.

  2. Run script on agent

    Run a shell script on the robot. Scripts must be placed in the ${HOME}/.inorbit/local/user_scripts directory.

  3. Jump to InOrbit page

    Bring the operator to a specified page in InOrbit Control, such as the localization and navigation screen for a robot. Useful to allow you to dive deeper into a problem and perform the most effective resolution action.

  4. Open URL

    Take the operator to the configured URL on a Web browser window. Useful to direct your operator to an internal system to continue the resolution protocol for a given incident.

  5. Execute a ROS service (coming soon)

    Execute a ROS service on the robot.

These actions can be made available for execution in the ROBOTS section of InOrbit Control through the Robot Actions widget:widget-actions

or tied to specific incidents for execution through InOrbit Control, Slack or Pager Duty:

actions-notifications-pngIntegration with other incident management systems such as Salesforce Service Cloud is underway. Please write to us to let us know about your integration needs.


As your fleet grows, InOrbit allows you to organize your robots according to different criteria, such as hardware iteration, customer deployment or location.

This allows you to filter or group robots in InOrbit Mission Control based on these different criteria.Each grouping of robots is called a collection; each robot may be part of one or more collections. All robots are members of the default collection called Fleet.

You can customize the collections and robot membership in each collection by going to Settings > Organization in InOrbit Control.

Manage Collections


Locations enable robots to be associated with a geographic location (a city or address that can be displayed on a map).

Locations have tags associated with them, like any other collection, but that tag has an underlying physical location. Adding that tag to any robot will enable grouping by location and easily associating robots with individual or common sites. Once robots are associated with a physical location, they may be displayed on an interactive, zoomable map to go from a world view all the way down to an individual robot map at a given site.

Configure locations for your account
  1. Use the Locations tab in Settings > Organization to define all the locations or sites you want to track. To add a new location, click the circled + sign. All locations are part of a collection type called Locations.

  2. Select a unique name (tag) for the location; this can be whatever you need it to be, from a city to something that makes sense within your system, such as Store #1234. For example:

    Add an address to enable displaying the location on a world map. Note that these locations are assumed to be fixed. Optionally add notes to help you with location management. You can also choose to have robots added to a given location by default.

  3. Now use the Robots tab in Settings > Organization and assign robots to this location. 

    Note: InOrbit also supports automatically assigning robots to locations if the location can be distilled from a data source, which is recommended as fleets scale.

  4. To see the locations on a world map, go to Mission Control and maximize the KPI section.


Modes is a special collection type that can be used to indicate the state or mode in which a robot is operating (e.g. Charging, Idle, or Mission). This value can change dynamically and is assumed to be MECE (Mutually Exclusive and Collectively Exhaustive), i.e. each robot can be in one and only one mode at any given time.

Modes map to a color in the block below the robot name in the Fleet view. The value of the mode is always displayed as text in this block on the currently selected robot.

Modes are reported in a custom data source. It is up to your application code to report these modes; any modes reported in the data source that do not match the modes defined here will be reported as Other.

Configure modes for your account
  1. Go to Settings > Organization > Modes.
  2. Select the data source that will determine the mode a robot is in (e.g., Mission Status):

  3. Now start adding the different values a mode might take. Click the ‘+’ button and add these one by one.

    Note: The tag field is the visible name the mode will have, which doesn’t need to match the actual data source’s values for the mode. Tags are unique.

    If values are not specified, it is assumed that the tag matches the value that the data source will take. So if, Mission Status can be any of Mission, Idle, Charging, Inventory or Error, the configuration should look like this:

    You can also change the order of modes to match the robot behavior; for example, if your robots usually change from Charging to Idle to Mission and back to Charging, you may organize them in that order. Colors are automatically assigned to each mode.

    If, for example, the Mission mode is triggered when Mission Status matches any of a set of values (e.g., mission, in_mission, running) or a value different from the tag, you can specify these using the values field:

  4. Done! Now you’ll just need the robot to publish Mission Status=<status> and if the mission status is any of the values defined above, the robot will enter in that mode. If the status is not on that list, the mode will be “Other”. For example:

Regular collections

All other collections can be defined in the Collections tab in Settings > Organization. You can add your own collection by clicking the circled + sign. Choose a type such as Customer or Hardware.

Enter a unique name, and optionally add notes and check the box to automatically add new robots to that collection.

Depending on the nature of the data source, collections can be either static or dynamic.


Static collections have fixed tags, manually generated, as the members are solely based on tags rather than data sources. Robots need to be explicitly assigned to a static collection by applying a particular tag to it. By default, several collections, including Deployment, Hardware, Customer and Other, are static.

Configure static collections for your account
  1. Go to Settings > Organization > Collections

  2. Click on the circled + sign, and a new row will be displayed for you to add a new collection.

Now you’ll need to create Tags for this collection.
  1. Go to Settings > Organization > Tags

  2. Select the tab for the Collection for which you would like to add a tag, and click on the circled + sign. This will present a new row where you can configure the new tag.

  3. Enter the tag name, which should be unique.

  4. Now use the Robots tab in Settings > Organization and assign robots to this tag. For example, If you want to update tags for a robot named ‘Kepler’, you’ll need to click on the dropdown next to the robot name and select the tags it belongs to.

  5. Then for the rest of the tags you can simply select the existing collection tab and add a new tag for it. Note that if the data source takes a value which doesn’t have a tag defined, a robot going into that state will have the tag “Unassigned”.


Dynamic collections are collections that are based on known data sources and thus membership can change as values change in the selected underlying data source. These are useful for enabling robots to be filtered or grouped by attributes that reflect the current state of that robot, such as the software version. Modes are an example of a dynamic collection that is built into the InOrbit platform.

Configure dynamic collections for your account
  1. Go to Settings > Organization > Collections
  2. Click on the circled + sign, and a new row will be displayed for you to add a new collection.
  3. Give this new collection a name (e.g., Software Version).
  4. You will see a new field on the right, which is the data source selector. The value of this data source on a robot will determine its associated tag.

Now you’ll need to create Tags for this collection. You can either do it:

  • Manually as described above for Static Collections.
  • Automatically

    Click the Auto create tags checkbox on the Collections config. This will automatically create new tags based on the values that the associated data source takes, which will be reflected in the Tags section.

    Note: clicking on the robot count for a tag will redirect you to Mission Control, with the fleet status filter set to the specific tag, so only those robots will appear.

You can edit an already created collection (change its name, switch between static and dynamic, update a data source for dynamic collections) by clicking on a row within the Collections tab in Settings > Organization. This will enable edit mode.

You can also delete collections or tags with the trash button. To delete a collection, you must first delete all its tags. To delete a tag, first make sure there are no robots on it. 

Once you have a collection, you can group or filter by collections in the FLEET section. For example:

Group by ‘Mode’:

Filter by a particular customer:

When autonomy fails and other means of resolution fall short, InOrbit Control offers powerful Intervention capabilities that allow you to temporarily take manual control of your robots and teleoperate them back to safety and autonomy.

This ability gives the human operator using InOrbit a greater power over the physical presence of the robot so it must be used with caution.


Relocalization and Teleoperation are available when opening the Navigation screen for a particular robot:

  1. Log in to InOrbit Control.
  2. On the FLEET section, click on the column corresponding to the robot you want to Teleoperate, or enter a robot by name at the top of the ROBOT section..
  3. On the ROBOT section, click on the NAVIGATION button in the title bar.


The controls for both relocalization and teleoperation can be found on the right side of the map view in the standard layout. 


InOrbit Control offers selectable layouts for adapting the focus between maps and specific cameras. The layout button brings up a pulldown menu of available layouts based on the visible cameras.


Other layouts (besides Standard) may have the teleoperation control hidden by default and available by clicking the button with the joystick icon.



To ensure that the robot is properly localized to accurately track and control the robot navigation, the map displays lidar dots reflecting how the robot is currently recognizing obstacles. If the lidar dots are not properly oriented with features on the map, navigation becomes more unreliable.

Relocalization may be all that is required to restore proper navigation by the robot, or it may be the first step before taking over navigation via teleoperation.

First activate relocalization by clicking the Relocalize button.


It is easy to relocalize a robot with two controls:

  • Clicking and dragging the rotation control above the robot enables rotating the map features relocalization_rotating
  • Clicking and dragging on the robot enables translating the map in xy space to align the lidar dots with the features

Click on the check mark in the lower right to confirm relocalization. If you decide to cancel or start over, click the Relocalize button again to turn off Relocalize.




To provide flexible options for different needs/preferences, there are currently 3 modes available for Teleoperation:

  • Open - send a very simple velocity or movement command to the robot to move in a certain way without invoking the robot’s navigation stack
  • Waypoint - send a command to the robot to move to a specific target location, using its internal navigation stack
  • Precision - send a command to the robot to move a precise distance forward or backward at a precise angle, using its internal navigation stack

Hovering over the visible Teleop button (beneath Relocalize) opens the Teleop drawer to reveal the available buttons to activate the preferred mode.

See the Security measures section below for important information about how InOrbit restricts teleoperation to ensure the safest possible operating conditions.

Open Teleop


Selecting Open Teleop activates the arrow buttons in the lower right corner. Clicking on the up or down arrows send commands to the robot to move a single step forward or backward, relative to the current robot position and orientation, respectively. Clicking on the right and left arrows send commands to the robot to rotate clockwise or counterclockwise by a fixed angle, respectively, again relative to the robot.

Above the arrows are meters to show the linear velocity and angular velocity when the robot is moving, and a network gauge to ensure that the roundtrip latency is sufficiently low to safely carry out the command.

Since this can be a risky mode to be in (since it bypasses the navigation stack that avoids obstacles), there is a bright bar along the top to make it very clear when the robot is in Open Teleop mode. You can deactivate Open Teleop by toggling off the Open Teleop button.

To set a new distance or angle of the increment for each step:

  1. From the menu of three vertical dots at upper right, select Settings.
  2. Select Navigation from the top menu.
  3. Select Teleop from the left-side menu.
  4. Optional - Select whether this change should apply to the Fleet or an individual robot with the selector in the upper left.
  5. Adjust the default Distance or angle using the sliders.
  6. Exit Settings and select Navigation to resume Teleop.


Waypoint Teleop

Selecting Waypoint Teleop enables selecting a target position and pose that will send a command to the robot to which it should move. Select the target position by clicking on an arbitrary point on the map or by dragging the pin icon that appears on the current robot to the new target position. Change the target pose by clicking within the circle indicating the target and dragging to orient the robot avatar to the desired final orientation.

Click the check mark at the bottom to send the command for the robot to move to the waypoint using its navigation stack. Once the robot’s navigation stack computes the path, it will be displayed and the robot will navigate to the target. The gauges on the right display the velocity, network rate and angular velocity. 

You can abandon setting a waypoint by toggling off the Open Teleop button.

Precision Teleop

Precision Teleop enables very precise movement to a nearby waypoint, including whether the robot should move forward or backward, within a relatively small range (default is 2 meters). Selecting Precision Teleop zooms to a region immediately around the robot and displays a gauge for the selected distance and angle in the lower right corner of the map.


Click on the robot and drag along the diameter line appears to define the angle and distance that the robot should move. The arrow on the target shows the direction that the robot will be facing at the end of the motion. To have the robot go backward, drag the arrow through the robot along the line such that the arrow is still facing the same direction as the robot is currently facing. You can also go to Settings > Navigation > Teleop as in Open Teleop to specify the increments for the distance and the angle if you want to use the arrows to specify these at fixed distances/angles.

Click the check mark at the bottom to send the command for the robot to move to the waypoint using its navigation stack. Once the robot’s navigation stack computes the path, it will be displayed and the robot will navigate to the target. The gauges on the right display the velocity,  network rate and angular velocity. 

You can abandon setting a waypoint by toggling off the Precision Teleop button.

Step-by-step mode

Open and Precision Teleop both have options for step-by-step or continuous mode, which respectively only issue a single command at a time or allow holding down a control to send a series of commands.

The default and recommended mode of operation gives you the ability to “nudge” the robot one step forward, one step backwards or rotating a fraction of a spin to the left or right.

This ability is intended to allow you to use discrete, safe movements to move the robot past an obstacle that its autonomous navigation algorithm can’t resolve on its own.

This enables a basic level of human intervention to apply in adverse network conditions to support re-establishing autonomous operations without the need for physical assistance.

Continuous mode (Experimental)

InOrbit includes an experimental feature to allow continuous teleoperation, similar to that found on remote control tools.

In order to enable continuous teleoperation mode:

  1. As Administrator, login to InOrbit Control.
  2. From the menu of three vertical dots at upper right, select Settings.
  3. Select Navigation from the top menu.
  4. Select Teleop from the left-side menu.
  5. Disable the Step-by-Step mode switch.

After this is done, the following functions become available:

  • You can click on a direction arrow repeatedly to achieve a seemingly smooth movement. NOTE: the robot will move an entire foot in the given direction after the last click is pressed.
  • You can switch to use a virtual joystick by clicking on an icon that appears in the bottom right of the teleop control.

For Open Teleop, we highly recommend step-by-step mode for safety reasons since the navigation stack is not involved to prevent collisions with obstacles.

For Precision Teleop, the continuous mode only affects the process of specifying the action by, for example, holding down the arrow to change the distance in fixed increments before sending the final command, so it is a convenience rather than a risk.

Security measures

As teleoperation is a dangerous operation, InOrbit includes several safety measures to avoid unintended robot movements:

  • Teleoperation is disabled by default, to avoid accidental clicks. In order to start teleoperating a robot, you must press the button for one of the active Teleop modes to expressly enable active teleoperation.
  • Teleoperation will be automatically disabled if the network round trip time to the robot is higher than 2 seconds. The currently measured round trip time value is displayed at the top of the teleoperation control.
  • Even while performing teleoperation, if the message sent from the user interface is delayed for any reason and the robot receives it more than one second after it was sent, the command will be discarded on the robot side, preventing an unintended delayed movement.

In addition, teleoperation will be blocked unless the following conditions are met:

  • Odometry information is being published by the robot and InOrbit can decode it properly
  • Robot movement as indicated by robot odometry matches the amount of distance intended by InOrbit’s teleoperation commands
Experimental features

Other experimental features such as gamepad support may be enabled selectively for specific accounts. If you are interested in trying out an additional experimental feature or have any input or questions, please contact our support team at



InOrbit allows individual robots to be locked while someone is sending specific actions to it to prevent multiple people from executing potentially conflicting actions.

This feature is only available for Enterprise accounts

Configuring Robot Lock

Locks can be configured under Settings > Insights > Actions to be:

  • Disabled - locks do not apply (default)
  • Selectable - locked explicitly through the LOCK button
  • Automatic - implicitly locked when a person sends an action that requires lock

Any action can be configured to require a lock on the robot.


Check the Requires Lock box to specify which actions will implicitly create a lock when used (Automatic mode) or require the robot to be locked before running (Selectable mode).

Using Robot Lock

InOrbit currently supports the following capabilities around robot locks:

Locking a robot

Any robot can be locked by clicking on the LOCK button, which toggles to UNLOCK to easily remove the lock.

Other people can hover over the UNLOCK button to see who currently has the lock on a robot and how long it has been in effect.

Unlocking a robot


The person who locked the robot can unlock it by pressing the UNLOCK button. This allows other people to claim the lock on the robot.

Breaking the lock

If the robot is locked, an authorized person other than the person who locked the robot can force the robot to be unlocked by pressing the UNLOCK button.

In this case, there is a confirmation on unlocking a robot to ensure that this is a deliberate action.

Lock expiring after a timeout

To prevent situations where a person who locked a robot forgets to unlock it, locks are automatically released after a period of time has passed since the last action on the robot.

Easily viewing which robots are currently locked

There is a Locked Robots collection that provides visibility into any robots that are currently locked.


InOrbit supports integration to various incident management platforms via webhooks.

InOrbit sends events to your webhook to notify you when a variety of interactions or events happen according to what you have configured, including when a status value goes out of range and enters the "WARNING" or "ERROR" levels. Webhook events are sent by InOrbit as POST requests to your webhook.

Setting up your Webhook

Setting up a callback URL for webhook events requires verification that you control or own the domain that hosts your application.

When you provide the webhook URL in InOrbit/Settings/Admin/Integrations, you will be sent a GET request including the header X-InOrbit-Key (a fixed value, randomly generated), which will contain the API key you see on the screen. Your server should respond with a status code of 200 and the API key that was sent.

Webhook Events

You will receive one webhook event per instance of an incident occurring.

For example, if you configured a Warning to be triggered when the Battery Level goes under 30%, you will receive a POST request when that happens.

alertId: <Alert ID>,
entity: {
id: <Entity ID>,
type: <Entity Type>,
name: <Entity Name>,
message: <Message of the alert>,
description: <Description, usually more detailed than message>,
actions: <Possible actions that can be executed for the given alert>,
componentId: <Component ID where the alert was triggered>,
status: <Status, could be "new", "resolved">,
ts: <Timestamp when the alert was triggered>,
priority: <Severity of the current alert>