FAQ

InOrbit is an AI-powered, cloud-based robot management service that handles much of the infrastructure work required to develop, deploy and operate smart robots at scale.

InOrbit is a Software-as-a-Service solution, so you don’t need to worry about infrastructure: you only pay for what you use. We want to enable robotics startups to get to market sooner and are offering a free tier so you can get up and running right away without having to worry about cost. We also offer volume discounts for large operators. Check out our pricing page for details.

We are robot-agnostic and can control any autonomous mobile robots. Robots based on ROS or ROS-2 are especially easy to configure, but we have activated InOrbit on numerous non-standard platforms, as long as a roboticist has access and knowledge of the robot software and can provide details on the platform and OS. We offer consultation to accelerate integration for potential customers who have unique robots that we have not already integrated.

Once you have created an account, you will be logged into to your own InOrbit Control console. From there you will be able to add robots to your constellation in only seconds, by executing your own customized agent installation script on each of your robots.

As you add your robots to InOrbit ("put them InOrbit"), you will be able to see a range of data, from fleet-level analytics to diagnostics information for individual robots. But InOrbit isn’t just about monitoring; it provides operators and engineers a convenient way to conduct remote interventions.

The InOrbit agent currently supports Ubuntu 16.04, 18.04, 20.04 and 22.04.

Supported ROS versions are Kinetic, Melodic and Noetic. ROS 2 support is also available for Foxy and Humble versions.

Hardware requirements vary depending on the robot software being monitored, but we generally recommend:

• 1GB RAM
• 512MB HDD
• 1 CPU core (shared with other processes)

No. The installation script should be run from a regular user. The InOrbit agent will be stored on the home directory of the user used for the installation and will run as this same user.

If a particular step during the installation process requires root privilege (e.g.: installing dependencies), that will be clearly specified and prompted to the user during installation, allowing to choose to do that manually instead.

At a high-level:

• It installs a few essential system dependencies, such as python and virtualenv.
• It downloads the latest binary agent version from https://control.inorbit.ai/agent.tgz and expands it in ~/.inorbit/dist, inside the installing user’s home directory.
• It configures the InOrbit agent with your company’s API key and other configuration details, with files stored in ~/.inorbit/local.
• It configures systemd or upstart according to the robot’s operating system to automatically start and respawn the agent script.

Yes! The InOrbit agent runs continuously in order to maintain a link to the InOrbit cloud. Through this link, the agent can receive instructions from InOrbit Control, allowing it to provide vital information, perform any necessary corrective actions and stay up to date to the latest version of the software. Depending on the usage profile, the agent can use very limited compute/storage/network resources so it does not interfere with the normal operation of your robot.

The InOrbit agent provides the most efficient means of communication with your robots, using reliable, secure, low-bandwidth communication that was designed specifically for low-resource devices. The agent can operate in different usage profiles with adaptive data resolution and bandwidth utilization. In the limited usage profile, only the most basic, low-resolution/low-bandwidth data including vitals and alerts are transmitted. When actively accessing or controlling a robot through InOrbit Control, targeted higher-resolution data is transmitted to support specific user actions.

• ROS topics (string and other standard message types)
• Custom Commands (standard POSIX IPC via parameters and standard streams)
• Local HTTP connections (string input)

Using standard systemd or upstart commands, such as:

   sudo systemctl restart inorbit
   sudo initctl status inorbit

Whenever a new agent version is available, you will see an UPDATE AGENT button on the Robot Control widget (you can find it on the Robot Dashboard, for example).

 If you’ve installed the agent through the regular install process, you’ll be able to update the agent from InOrbit Control by following these steps:

1. Go to the Robot Dashboard and select your robot in the Robot Control widget.
2. Click on the UPDATE AGENT button:

The agent will receive the command and go offline for about one minute. When it comes back online, it will have the latest agent version. 

All you need to do is to shut it down, remove it from systemd or upstart (depending on your Ubuntu version) and remove the .inorbit directory in the user’s home directory.

You can use the ~/.inorbit/dist/scripts/uninstall.sh script to make this easier.

Yes. In the Robot Data settings screen, create Status elements configuring rules over one data source. In most cases two levels of alerts can be configured (Warning and Error), normally by giving two different thresholds and a comparing function (a data source having to contain at most a maximum value, or being equal to a value). Each “Status” will render as a colored box in the main Fleet page, depending on the status level.

Yes. You first need to configure status over a data source, defining what a warning or error situation is for that data. Then, add an Incident Definition in the Insights settings screen, and choose to trigger the alert for a Warning or Error status levels. Then decide where the notification is to be sent: In-app notifications, Slack messages and PagerDuty alerts are supported.

The InOrbit agent records error logs locally on each robot. They can be found in ~/.inorbit/local/inorbit.log and ~/.inorbit/local/inorbit_agent.log.This is a good place to check for details if the inOrbit agent is failing to connect to the inOrbit cloud.

If you need to report a bug to InOrbit, please make sure to include these logs with your report.

InOrbit can dynamically switch between cellular and WiFi as long as there is internet connectivity.

We use MQTT, an industry standard protocol designed to deal with spotty connections and take care of reconnections and other intricacies of dealing with connection unreliability.

On top of that we have our own protocols to provide further robustness in connectivity.

InOrbit can connect to any data (values or events) and take any actions that are available to monitor or control a robot, whether these are on the robot or in the cloud. They simply need to be published somewhere where InOrbit can find them and has access. Our platform interoperates with the robot’s technology stack, including navigation, so obstacle avoidance is automatic unless you explicitly override it. We offer several forms of teleoperation to send commands to robots to navigate.

As an example of our ability to adapt to specific robot features and extend to others, we offer a popular Precision Teleoperation feature that we designed in conjunction with a customer to navigate robots out of tight situations that can challenge the built-in navigation. You can see this feature in our videos.

InOrbit can be configured to execute scripts that customers provide on the robot, or to send a message via a ROS topic. This includes the supporting infrastructure, including role based access control, confirmation of command execution/error reporting, conditional actions based on configurable criteria, audit trail, etc.

At a technical level, the command is transmitted via MQTT. The agent connects (outgoing connection) to our MQTT broker, and then stays connected / keeps that connection open. That connection can send messages from the robot to the cloud (telemetry) but also from the cloud to the robot (commands), so is fully bi-directional.

InOrbit doesn't establish a tunnel to the robot. Specifically, it doesn't allow tunneling of other open-ended protocols like SSH or Telnet through into the robot. Instead, it uses a specific protocol designed only for outbound communication to publish data configured through policies and restricted inbound communication to receive preconfigured actions specifically targeted to this robot. The communication protocol used is MQTTS through TLS, although it can be also optionally configured to go over Secure WebSocket. In all cases it's encrypted with TLS 1.2 or higher.

To run a shell script on the robot as an InOrbit action you need to:

• Place the file in the ${HOME}/.inorbit/local/user_scripts directory
• Grant execution permissions to the script

As an example, you might write a script that lists the top 10 running processes on the robot and saves the list to a file. This could potentially be useful for debugging a robot with high CPU utilization. As described in Configure actions, 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 \
> $SAVEFILE

Please make note of the name of the script on the robot because you need to specify the name when you define the action.

We generally require Chrome v78 (since that is the current test target for most of our quality assurance tests) or higher and recommend having 1GB RAM available for it. For reference, this version was chosen based on tracking which was the commonly used version by our clients. Since all of the libraries we use are cross-browser, things will generally work well with older Chrome versions as well as Firefox.

We do the bulk of our testing on Linux but there should not be issues on Windows or Mac. We recommend a physical computer but it should work fine on a VM as well, as long as it complies with the above characteristics.

This is an unfortunate result of occasional lag in the time it takes for the map to upload to the cloud. The first thing to try is to clear the cache on your browser. If that doesn’t resolve it, we recommend a hard reset. For example, in Chrome, click on configuration (the 3 dots in the top right of the browser window) and select More Tools->Clear Browsing Data… and make sure the Cached images and files box is checked before clicking Clear data.

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 InOrbit’s custom data topic. Here are some examples for ROS 1 and ROS 2:

ROS 1

rostopic pub /inorbit/custom_data/0 std_msgs/String "battery percent=93.3" -r 10

rostopic pub /inorbit/custom_data/0 std_msgs/String "aisle=123" -r 10

ROS 2

ros2 topic pub /inorbit/custom_data std_msgs/String "{data: 'battery percent=93.3'}" -r 10

ros2 topic pub /inorbit/custom_data std_msgs/String "{data: 'aisle=123'}"  -r 10

You can publish different keys to the same ROS topic using different std_msgs/String messages. The agent will subscribe to the topic and handle the key-value pairs according to the sampling mode configured.

This feature works out of the box for any robot with ROS. See the doc on Customize robot data for more information, including non-ROS support.

InOrbit also supports advanced custom data setup, which can be enabled per customer request. These include handling complex custom data in JSON format, generating derived data and getting data from different ROS topics, and similar approaches for non-ROS robots. Please contact our support team at support@inorbit.ai for details on this advanced configuration. 

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.

Add this key (e.g.: apples) as a Data Source and use it for Status and visualize it in Timeline or Vitals widgets.

The values published will be also available in the Key Values widgets in the ROBOTS section.

Yes. You need to find out the namespace within the diagnostics message tree and the key name; which are configured next to a data source of type ROS Diagnostics in the Robot Data settings screen. For example a namespace /Power System/Battery Status with a key Percent to configure a battery percent data source.

Messages received in the configured ROS topics are assumed to be received repeatedly with a fixed or variable frequency, potentially at a very high rate, as per normal in-robot message processing. Taking this into account, the InOrbit agent will perform downsampling of the received data and transmit it to the Cloud, attempting to reduce bandwidth to the minimum necessary for remote observation while capturing a dataset consistent with its appropriate use case. 

Note that if messages are not received for a given time period, InOrbit will not transmit new values corresponding to these messages during this time.

The main setting controlling how data is sent on each data source input is the sampling mode, which can take one of these three values:

InOrbit’s agent has a Regular sampling mode configured for all custom data key-value pairs by default. InOrbit also offers the Diff and Event sampling modes to optimize bandwidth and support more immediate incident visibility. Please contact support@inorbit.ai for details on this advanced configuration.

Yes, we back up the data.

There are different storage options available, depending on the subscription level, from real time data that gets overridden by the latest values or historical data that is saved for a configurable amount of time.

Depending on data type (whether it's simple string key/value pairs, navigation data like maps, lasers, and paths where we use different structures), we have different options to store data.

This will also depend on the data type. For example, we offer an API that enables users to export real-time data from attributes in JSON format, and other formats like CSV are available where appropriate.

InOrbit offers different subscription tiers for access to the platform, aimed at meeting the needs of various customers and partners.

The Standard Edition is InOrbit’s base subscription, which includes most of the core functionality required for a small or growing fleet. You can get started for free, then as you add to your fleet you pay a variable monthly fee based on the number of monthly active robots (more specifically, the high water mark of daily unique active robots). Once you have outgrown the pay-as-you-go structure through scale and a clear line of sight to your deployment pipeline, you can lower per-unit cost by making upfront annual payments. Details are available on our pricing page.

If you have more advanced business and technical needs, you may benefit from InOrbit’s growing list of Premium functionality, available as an Add-on at an additional cost. You may find details on some Premium functionality listed in these FAQs and our documentation, such as webhooks and APIs for incident management; for a complete and current list, please contact our customer success team. 

In addition, if you are an enterprise customer with current/planned large fleets and advanced business needs, you may benefit from the Enterprise Edition. This includes several advanced capabilities, such as the add-ons to the Standard Edition, as well as enterprise-grade security capabilities like single sign-on. Premium Support is also bundled to ensure an appropriate level of access to InOrbit technical staff, prioritized bug-fixing, early access to upcoming features and a named customer success manager.

Does InOrbit offer different levels of support?

InOrbit is designed from the ground up to make it easy for anyone to integrate robotics into their operations. From a 1-minute robot install to point-and-click settings, InOrbit makes the complex simple. 

InOrbit’s Standard Support is offered free of charge to all InOrbit adopters and can address most customer needs via email or chat. Whether it’s answering a configuration question or finding the right documentation, InOrbit’s customer success team is available to help you maximize the potential of every robot.

Customers rely on InOrbit to tackle mission-critical use cases, from monitoring hundreds of robots to real-time interventions, in order to meet stringent operational service level objectives. If you need enhanced support and consulting, you can opt for Premium Support. With direct access to a named customer success manager and ability to communicate with InOrbit engineering, Premium Support allows customers to have access to the latest product information, real-time troubleshooting and consulting on best practices for robot operations. Premium Support is available for $3,000 per month with a 1-year commitment.

In addition to the existing capabilities offered today, the InOrbit platform continues to evolve, with new functionality and experiences being added regularly and becoming available over time. To drive additional alignment, InOrbit offers a very select number of strategic partners a greater level of service known as Enterprise Support, whereby additional influence on roadmap direction, priorities and capabilities can be achieved. If you believe that Enterprise Support is right for you, please contact our customer success team for a fee consultation.

How do I create a Time Capsule dashboard?

See the Time Capsule doc for step-by-step instructions for creating your Time Capsule dashboard.  

What does "Type" refer to?

Information in your Time Capsule can be visualized in different ways.  Currently four different visualizations are available.  

• Position shows the exact location of the selected robot at different points in time within your defined time range.  
• Position (heatmap) highlights with colors the areas on the map where the robot spent the most time within your defined time range.  Warmer colors (yellow, orange, red) indicate more time while cooler colors (green, blue) indicate less time.  
• Path shows the specific path(s) a robot took during the time range.  
• Incidents highlights points on the map where incidents were logged by the robot during the time range.  

Why is a robot not showing up in the "Select a robot" dropdown?

The dropdown displays only the first few robots in the fleet (based on your role assignment). To find any robot, start typing its name and it will appear in the list.

What are the recommended time periods to look for?

Each customer will have their own "interesting" time periods. We recommend choosing shorter time spans (e.g., 10 minutes - 3 hours), where you know the robot has been performing some mission to be able to visualize all of its movement. 

Why are the Path and Incident visualizations only available for shorter time windows?

Time Capsule manages large data sets through downsampling to maintain performance.  The Path and Incident visualizations often are incomplete and do not make sense when sampled, and thus are disabled to avoid providing misleading data.

What is downsampling and how does it affect my data?

Downsampling is a method of reducing the amount of data needed from a signal while maintaining an approximation of the original signal.  In the case of Time Capsule, large data windows may easily have thousands or millions of data points that would be very confusing if visualized together.  We use downsampling in these cases to generate a summary of the data that still provides insight into the circumstances and behavior of the robot. 

We are continuously refining our downsampling algorithms and welcome your feedback on any scenarios where the current approach is not meeting your needs.  

How can I find links between widgets?

The robot data in all of the visualization widgets are linked, meaning that when you hover over a particular widget, you will see what data is correlated in the other widgets. For example, if you hover over a particular entry in the Audit Log, you will see a mark in the timeline widgets indicating what the Operating Metrics or Network values were at that time, and the pose where it happened will be highlighted, if the specific data value is preserved in the downsampling.

Can I highlight robot data based on the robot Mode state (assuming we are using Modes)?

If you have configured Modes for your robot fleet, you can select the individual time periods associated with each Mode in the Modes widget. When you select each unique time period associated with any Mode, the visualizations will change to reflect the correlated robot data.

How do I share or save an interesting Time Capsule?

When you spot an interesting Time Capsule that you want to share, you can copy the URL and send it or save it, allowing you to easily come back to the Time Capsule. The URL will open up the Time Capsule visualizations in the same state, i.e., same robot, time window and selected time, map, Mode (if selected).  

How can I see a Time Capsule for an incident?

After creating your Time Capsule dashboard, a "Open Time Capsule" button will appear directly from the Incident List (available in the Fleet dashboard) widget.  This button will take you to a Time Capsule for the selected robot and incident.

The time range selected will start 5 minutes before the incident was triggered and end 5 minutes after the incident.