Imagine that you need to fly to a distant location, a busy airport you’ve never visited. You are the nervous kind, so you want to make sure it will be safe. You talk to the airplane manufacturer, and walk away with confidence that the machine has been well designed. You verify the maintenance schedule and are satisfied that it is thoroughly tested.
Then you talk to the management at the airport you’re flying into, and they tell you that they cobbled together their air traffic control system with some old PCs that nobody was using and installed some software for a taxi dispatch. Would you get on that plane?
Sadly, this is often the case in robotics. Since before we started InOrbit, and throughout the last 2 years, we have engaged with over 75 robotics companies and hundreds of people in the robotics space. We have talked to the C-suite setting strategy and to front line operators doing triage, to robotics Ph.D.’s and to self-identified robot baby-sitters. Across all these conversations, we had an overarching question: how do you manage robots after they leave the lab?
To summarize the response from the majority: Not well. This has motivated us to continue working on a way to help these companies accelerate. We also kept digging deeper, spending quite some time understanding why most robotics companies find themselves in this situation. For the most part, what we’ve learned is that, while effective robot management in the field is absolutely critical, for most companies it is not their core expertise.
The journey that most robotics companies follow is remarkably similar. For many of them, it starts with “robots are cool, let’s build one”; what the robot is for is a secondary consideration. Thanks to great advancements in tools and components over the last 5 years, the time and cost of building an initial prototype in the lab has dropped dramatically, so this story is repeated hundreds of times each year around the world as new startups are founded.
After getting their first robot working in the lab/garage/accelerator/maker space, it’s time for the initial deployment. It may be a field trial in a particular location, a proof of concept or a pilot with a corporate customer. The number of robots goes from a handful in the lab to a dozen or two in the field. Now some of the practices and tools that were meant for development in the lab start to show their limitations, but they can still largely brute force it: the company has raised some funding and has more engineers than robots.
The next stage is scaling, from dozens to hundreds and then thousands. This is where many companies crash land. Manufacturing can be outsourced, most components are off the shelf, and the robot software has been refined during the pilot. However, their operations are not ready for scaling. Their robot : human ratio is upside down, they can’t hire qualified people fast enough, their tools are clunky, inefficient and brittle.
Until recently, robotics companies didn’t have a choice but to build their own. For most of them, this was at best a distraction or side project; all the cool kids were building robots. A few select companies have recognized the need of investing heavily to develop these tools and best practices in-house. However, their learning is severely limited by the myopia of only looking at their own robots.
This is now changing. InOrbit and a few companies following in our footsteps are bringing scalable tools to help robotics companies and operators better utilize their robots in the field. In our case, our main focus is on RobOps, which combines the best practices and tools of DevOps and AI to bridge the autonomy gap and orchestrate the operations at scale of heterogeneous robot fleets.
There’s no longer an excuse to “cobble together” some disjoint tools. Companies facing the build vs. buy decision can now saw “Yes, and” by cherry-picking specific elements of the InOrbit platform, easily customizing/extending the functionality to meet their needs, combining it with their existing home-grown tools or adopting it as a ready-made cloud solution to run a complete ROC (Robot Operations Center).