Launching InOrbit Configuration as Code

You asked and we listened: Configuration as Code is here.

For a broad explanation of this capability please visit the InOrbit blog. For more technical details, including code snippets and examples, read on.

We are thrilled to announce that you can now stay in the terminal or Postman when you want to change your robot’s settings instead of opening up InOrbit’s Control UI. Additionally, We’ve launched a CLI to make integration easy, or you can alternatively make an HTTP call to InOrbit’s REST API. Our goal for this new capability is to provide more options to fit your needs.

If you’re looking to jump in quickly, InOrbit provides schemas and further code examples on GitHub so you can start exploring right now. Configurations can be scoped to an InOrbit account, an individual robot, or user-defined tags, which unlocks endless possibilities.

Configuration as Code is rolling out steadily and our initial launch targets two key aspects of your robot management flow.

Incident Definitions can now be customized through Configuration as Code. This lets you control which metrics will trigger an alert, the threshold this happens at, and the way users get alerted. Perhaps you want to trigger an in-app alert if a robot’s battery level drops below 50% but if that battery drops below 20% you want to trigger an alert on Slack. This JSON payload is all you need:

{
"kind": "IncidentDefinition",
"apiVersion": "v0.1",
"metadata": {
"id": "1234567890",
"scope": "account"
},
"spec": {
"statusId": "0987654321",
"label": "My Battery Incident",
"warning": {
"notificationChannels": ["app"],
"autoActions": [],
"manualActions": [],
"severity": "SEV 2"
},
"error": {
"notificationChannels": ["slack#support"],
"autoActions": [],
"manualActions": [],
"severity": "SEV 1"
}
}
}

We support multiple levels of severity, various notification channels, and provide the ability for automatic actions in response to an incident. That’s a lot of power in a small JSON payload!

Check out this video walkthrough for a step-by-step guide to get your Incident Definitions configured.

Configuration as Code also supports Robot Camera customization. Camera feeds are one of the most vital sources of information for robot operators but they come with a lot of complications. Fluctuations in available bandwidth and varying image quality requirements create complexity in configuring your robots. Or maybe one robot in your fleet just has a camera installed upside down and you need a quick fix before support can arrive. Here’s an example JSON payload for rotating the camera feed by 180 degrees:

{
"kind": "RobotCamera",
"apiVersion": "v0.1",
"metadata": {
"scope": "account",
"id": "1234567890"
},
"spec": {
"label": "front",
"shortLabel": "F",
"rosTopic": "usb_cam/image_raw",
"width": 320,
"height": 240,
"rate": 1,
"encoding": "rgb8",
"quality": 50,
"rotation": 180,
"mirror": false,
"enabled": true
}
}

A single REST call allows users to configure a series of attributes for their camera feed, including:

Image dimensions
Number of frames per second
Image quality

Review this short video outlining how to configure your Robot Camera to meet your needs.

We know robot operators often want different configuration values in staging versus production. Now you can integrate REST calls into your CI/CD pipeline. Or you may want to version control your configuration files so if someone introduces a breaking change, rolling back will not only revert the code but ensure your configuration is back in a known and valid state. DevOps teams have long understood the benefits of this practice. Now InOrbit has enabled our RobOps tools with the same benefits.

Your next move should be to head over to our developer docs and start hacking.

If you haven’t made an InOrbit account yet, try the free version of our platform to get started with no strings attached, and no credit card required. Let’s get your robots InOrbit today,

InOrbit Configuration as Code Streamlines Your Workflows with Solutions for Specific Developer Needs