5 blockers to robot adoption

The market for autonomous service robots is on the verge of a massive expansion. This has been largely driven by advancements in core technologies such as computer vision as well as lower cost of key hardware components and a standardized software stack.

Like we’ve seen with other technology waves such as cloud and mobile, venture capital is pouring into the robotics space, tripling in size from 2016 to 2017 and reaching +5B in 2017 by some estimates, which in turn is attracting more startups tackling an incredible variety of problems, from life-saving to mundane.

However there are still some big potholes on the road to widespread robot adoption. We cover 5 of them here; number 4 will not surprise you (if you are already scaling your robots). To learn more, join us at RoboBusiness on September 27, 2018 in Santa Clara, CA for our panel on Robotics infrastructure at Global Scale.

1. Robotics companies need to solve real business needs

Robotics technology is fascinating, with many interesting technical challenges. However, the robotics companies that will succeed are those that solve a real business need. This requires specialization and single-minded focus on solving a specific use case, be it moving packages efficiently in a warehouse or hospital, scanning retail shelves or securing an office.

Spending time working on common infrastructure that every robotics company has to solve, such as secure, reliable communication with your robots, is not a great use of your limited resources, including your team’s attention.

2. The tools that work in the lab aren’t great in the field

Over the last few years, there has been great progress developing tools that help roboticists become more productive. This open source effort yielded platforms like ROS and tools like Gazebo, which have helped dramatically accelerate early-stage robot development.

However, once robots venture out into the real world, these tools have distinct limitations. For instance, recording ROS bags on production robots to collect diagnostics information presents a number of problems, from the risk of filling the robot’s hard-drive to sending large amounts of data over a flaky WiFi or costly LTE connection in order to pluck just a few useful insights. Even checking simple robot vitals such as battery load and HDD utilization become critical.

3. Using SSH to control your robots doesn’t scale

You may be able to manage a handful of robots by connecting to them one by one from your terminal. Once your fleet grows beyond that, this quickly unravels. Although roboticists rely heavily on these point-to-point connections with full access to the robot during development and initial testing, as the number of robots increases it can become a liability.

In fact, moving beyond SSH could almost be seen as a litmus test for the maturity of a robotics company that is getting serious about operations at scale. This is usually a painful transition; to quote a VP of Operations at a robotics company, there can be “much whining from engineers who are used to connecting directly” to a robot. The trade-off is increased accountability, security and robot management effectiveness.

4. A fleet of robots is like a data center from hell

Let’s face it: modern autonomous robots are essentially a mobile supercomputer with advanced data processing, running computer vision algorithms and other real-time calculations. A fleet of robots consists of distributed compute, storage and networking capabilities, just like a data center. However, in a data center the conditions in which machines operate are tightly controlled, with environmental, physical arrangement, power and connectivity having a high degree of reliability and consistency.

Robots, on the other hand, operate in uncontrolled environments, sometimes in far-flung locations, are usually mobile, have tight real-time computation constraints (eg to avoid obstacles), connect to unreliable networks and run the risk of running out of power in the middle of a task without a way to return to the charging station. And that’s without even getting into possible mechanical failures.

If you tried to design the least efficient data center in the world, you’d have to try hard to do worse than a fleet of autonomous robots. This means that robot management, including real-time monitoring, incident management and teleoperations, are much harder.

5. There are no best practices for managing autonomous robots at scale

The service robot industry is still evolving and has yet to develop consistent best practices like software-as-a-service developers have created over the years. Even basic maintenance like updating software is still largely a high-touch, artisanal process. In order to reach the level of reliability and predictability required for massive adoption, a set of best practices will need to emerge. These will range from data protection and privacy to auditable operations.

At InOrbit, we’re working on addressing these problems. Our cloud-based robot management system is designed to give robotics developers the boost they need at lift-off and the ongoing operational support they need to scale.

We have developed unique capabilities such as adaptive diagnostics, real-time dashboard and analytics, and remote micro-interventions all built on secure, scalable infrastructure. InOrbit enables robotics companies and operators at all stages of deployment to focus on getting their robots to work and solving specific use cases.

Here are some examples for how we address these problems.

1. Our robot-side agent takes less than a minute to install and supports secure, reliable, bi-directional communication as well as common robot vitals out of the box. It can be easily extended to adjust to each robot’s unique needs.

2. With adaptive diagnostics, the agent responds to conditions on the robot to capture and upload the most relevant diagnostics information and makes it available immediately for remote analysis. Incident management with built-in integrations for PagerDuty and Slack allows teams to resolve issues as they emerge.

3. Secure operations are handled through a number of best practices, including role-based access control, encryption at rest and on the wire, renewable cryptographic key management, auditable policy-driven controls and context-aware robot resource management. We provide tools for non-technical operators from micro-interventions (small nudges to get the robot back to working autonomously) all the way to full teleops.

4. InOrbit Agents efficiently manage storage, compute and network resources to avoid interfering with the normal operation of the robot, balancing robot and cloud data aggregation and analysis. Hierarchical configuration management makes it possible to have consistent software deployments while also managing the unique settings for each robot deployment.

5. Our team has experience scaling SaaS products and working with dozens of robotics developers, from Willow Garage to the latest crop of RaaS solutions. As we continue to work with many of the leading companies in autonomous robotics, we are helping develop best practices for RobOps similar to the emergence of DevOps over the last 10 years.

We’d love to hear from you. Are you running into these issues? Are you ready to scale but don’t know how to get started? Have you built it yourself but found your team getting pulled in other directions so you can never get your tools to be as reliable as you need them to be?

Come see us at the RoboBusiness expo and we’ll help you get your robots InOrbit.