Robotics vs. IoT

Another day, another Demo Day. Last week we had the privilege of being among a select group of startups to show the latest and greatest in the IoT world, ranging from photonics to wireless power transmission, at the latest Plug and Play Demo Day for Internet of Things. This was a big event, with many corporate partners and investors in attendance.

Our focus at InOrbit is on driving the new field of RobOps – DevOps for Robotics. Our mission is to accelerate the adoption of robotics across all industries and applications, from food production to retail. We are doing that by bringing to the robotics community many of the best practices and tools that allowed the cloud to scale. This results in better productivity for roboticists and lower time to resolution for ops teams.

We are often asked why we focus on robotics versus creating a generic IoT platform. After all robots are just things, right? (At this point, I’m tempted to go with “robots are people, too” but we’ll leave the philosophical and ethical discussions around personhood and robot rights for another post.) Since we were just in the Internet of Things batch, I thought I’d cover our thinking on the unique needs and challenges of robotics that set it aside from the more generic IoT.

1. Each robot represents a self-contained constellation of “things”

In typical IoT scenarios, each node is a standalone sensor reporting data that is then aggregated in the cloud to make decisions. In the case of autonomous robots, each robot is typically includes its own _self-contained constellation _of sensors (RGB, depth stereo cameras, lidar, distance/proximity/bump sensors, GPS, etc.) and actuators (servos, brushless motors, grippers, etc.) By self-contained, we mean that the data generated by these sensors is primarily used locally by the robot’s on-board processor to build a real-time model of the world and make decisions on it, in turn sending real-time commands to the actuators.

Many modern robots use the Robot Operating System (ROS) as a way to manage this massive data flow. Technically more middleware than operating system, ROS includes capabilities for hardware abstraction and message passing to integrate these various data sources.

For instance, a typical ground-based autonomous robot may have four HD cameras, two 3D depth sensors, and one or more lidars. If we include input and output from robot processes doing AI (computer vision, path planning), this adds up to 500Gb/h.

To make matters worse, many robots run on networks outside of the control of their developers and/or operator. It is not uncommon for service robots to be deployed on customer’s premises, outdoors, in public areas or constructions sites. In addition, most robots have some level of mobility, whether moving from one location to another (AMRs, drones, autonomous forklifts, etc.) or manipulating physical objects (robot arms with 6 degrees of freedom, etc.)

All this adds up to a number of unique challenges. At InOrbit, we have built a platform specifically geared towards the kinds of data sources and operating environment the autonomous robots typically handle so that we can properly complement their on-board capabilities with cloud-based functionality.

2. The amount of data generated by a single robot is far greater than a typical IoT device

Partly as a corollary of the previous point, modern autonomous robots can generate several orders of magnitude more data than, say, a smart thermostat. This requires a different approach to enable remote management.

One of the key features of InOrbit is the ability to provide robot performance monitoring through real-time analytics. However, a naive approach of sending all the data to the cloud just wouldn’t work. Robots in the field typically operate in constrained network environments: spotty WiFi coverage in warehouses or retail stores, limited 4G bandwidth, etc.

Part of InOrbit’s secret sauce (aka patented technology) is what we call adaptive diagnostics, which allows us to process massive amounts of data at the edge and make only the most critical information available in the cloud as needed.

3. Robots can interact with people, with each other and with IoT devices

Robots can sometimes operate on their own, relying purely on their on-board sensors. However, real world deployments will typically have a variety of sensors and often multiple robots, most likely from different vendors.

Since InOrbit has already tackled the much harder problem of data analytics and remote management for robots, it is relatively easy to integrate other devices. For example, a robot may operate in a warehouse where there are fixed cameras, RFID readers, proximity sensors at loading docks, etc. The same warehouse may use heavier equipment such as autonomous forklifts for moving pallets, fixed arms for de-palletizing and goods-to-person systems.

InOrbit can help orchestrate all of this through the cloud, creating a “single pane of glass” for all the robot and sensor data. In our warehouse example, operators can have a full operational view that provides real time data as well as the ability to take coordinated actions when interventions are needed.

To wrap up, on the question of Robotics or IoT, we’ll take a page from improv and go with “Yes, and.” Robots can be thought of as either a subset or a superset of IoT devices. InOrbit is tackling the specific needs of managing autonomous robots that generic IoT data platforms can’t handle. With this more advanced capability, it is easier to integrate other data sources from simpler IoT devices and offer a single dashboard across devices regardless of their level of complexity.

If you want to dig deeper, you can try InOrbit for free. Go to inorbit.ai/quickstart to get started.