Operating a fleet of robots has many challenges. The real world always has unexpected surprises and a robot operating correctly in a lab doesn’t mean it will handle real situations as intended. Even without an edge case occurring, expected time to complete a mission may vary between locations or time of day. A slight change in a scenario may justify a different response which operators may want to program ahead of time.

Building on the success of Configuration as Code, we have developed a robust solution for users to programmatically define Advanced Incidents. Advanced Incidents allows granular control of how a robot identifies and responds to incidents. Users can define a robot’s state as broadly or narrowly as desired using any combination of dynamic values from data sources and user-defined tags. Users can then assign unique actions as a response to any of these states. These actions can be automatic or manual, which can allow for user input.

In this Configuration as Code article, we programmatically determined how users were notified when a robot’s battery level drops below a certain threshold. Let’s take it up a notch. Imagine a common situation where a robot is on a mission but not moving. Maybe the robot is stuck or mislocalized. 

If the user sets a condition for an incident as “the robot has stopped moving” what happens when the robot is charging? What if the robot is moving a few millimeters back and forth, so it is still registering movement but is making no progress in its mission? Let’s go through what a user could do to define a desired behavior.

First, the user can define the conditions for warning and error states. Complex statuses can be set that take into account multiple parameters. Any combination of tags can be used, docked vs undocked, location, hardware, even custom, dynamic tags. InOrbit’s rich Expressions Language allows the use of arithmetic, functions, and localization data to develop a granular control that is unmatched in any RobOps platform. Here is a code sample of how a user could set a status for a robot that is on a mission but not moving:

The ”expression” means that the area that the robot has traveled in the last 60 seconds is a square with a diagonal distance under 1m and the robot’s mode is equal to “OnMission”. The “rules” mean that if this condition is satisfied for 60 seconds, the robot will be in a warning state.

Incident Definitions can be used to customize responses when a robot is in any defined state. The channels that are used to notify users of a warning or error state can be unique for each situation. This customizability applies to both the manual actions presented to users and the automatic actions that occur when a robot satisfies a status.

In this sample above we associate the Incident Definition with the previous Status Definition. This means when the “NotMoving” status enters an error or warning state, an alert will be generated in the appropriate notification channels. For example, during working hours, the team may want to be alerted on Slack for all errors. Outside of working hours, Ops Genie tickets are created to help the support team organize their response.

This example showed how more complex states can be defined and acted upon. Being able to use dynamic data from a data source as an input, combined with calculated values creates an extremely robust tool that can be catered to any use case. 

Next, head over to our developer docs and start hacking today.

Got a question? Feel free to drop us a line, or connect live with our team on Discord. And 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,