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 designed by robotics developers for robotics developers. Whether you’re an early stage startup trying to get your robot to work or a mature company with a large fleet of robots in the field, InOrbit will help you with the complexity of robot connectivity, monitoring and management.
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.
You install a small agent on each of robots: you add one line, it takes just 10 seconds. The agent establishes a secure, reliable, bi-directional connection to InOrbit’s cloud infrastructure. Part of our secret sauce is creating an efficient agent that does not interfere with the normal operation of the robot. Engineers and operators and use InOrbit Control to monitor and control robots, whether they are across the room or in a different continent.
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 agent runs locally on your robots and connects to the InOrbit cloud. It makes efficient use of available networks and doesn’t need to run as root. Once your robots are InOrbit, you’ll be able to control every aspect of the agent remotely, from what data is collected to when it is sent, and view vital metrics with InOrbit Control.
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.
Yes. The easiest way to do this is to download the installation script to your robot and inspect it, running each step manually yourself. In order to download the script, simply remove the trailing “| sh” from the proposed command and instead output it to a file 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
- 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.
Using standard systemd or upstart commands, such as:
sudo systemctl restart inorbit
sudo initctl status inorbit
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.
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.
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.
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.
std_msgs/String message with the form
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.
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.