9 keys to selecting your robot’s OS

This year, surgeons at Oxford’s John Radcliffe Hospital used a robot to conduct eye surgery for the first time ever. Tokyo’s Henn Na Hotel implemented multi-lingual robots to help guests check in. The supermarket chain Schnucks tested an aisle-roaming robot named Tally to identify out-of-stock items and verifying prices. And Tennibot created the world’s first robotic tennis ball collector.

These are just a few examples of how robotics is converging with artificial intelligence and machine learning to become one of the most promising and exciting initiatives in the network of smart, internet-connected devices. IDC projects worldwide robotics spending on hardware, software and services will reach $230.7 billion by 2021. Robots are playing a larger and larger role across almost every industry.

However, as with many other initiatives in the wider internet of things (IoT) sector, companies shouldn’t just dive in without a well-crafted technological blueprint from the development stage onward to ensure they are building a highly productive, sustainable, future-proof, and secure robot.

The right strategy starts with the right operating system (OS). Unfortunately, the importance of the OS isn’t always obvious until the company is too invested to change it, which can lead to a slew of delays or other issues.

The OS that’s perfect for hacking things together may be impossible to maintain once the robot reaches production. Similarly, the build-your-own option means maintaining the entire OS (backporting upstream security updates, etc.) for the lifetime of the robot. The OS choice also can influence a company’s monetization route, support offerings, and security strategy.

As companies join the robotics revolution, there are a number of essential OS factors to consider that can help or hinder robot development as it moves from development through to production and maintenance. Here are nine of them.

1. A consistent OS
The OS used on the robot during development should also be the one used in production (or at least closely related). There’s a balancing act to be had here – for example, the engineering team will naturally want the OS that best supports whatever they’re developing, but it’s easy to get tunnel vision during development and forget to consider other factors.

2. Software stack compatibility
Regardless of other reasons that go into deciding on an OS, selecting one that isn’t compatible with the technology required (libraries, frameworks, etc.) is a recipe for disaster. The engineering team will spin its wheels while competitors hit the market first.

Perhaps required libraries are written specifically for certain Linux distributions, or the team has settled on using some middleware to enable faster development. If a potential OS is evaluated with this need in mind, it will help lead to a streamlined development process.

3. Hardware compatibility
Hardware compatibility should also be a primary concern, for much the same reason as software: a significant chunk of time will be spent ensuring components work together before any real progress can be made on the robot itself. For example, it’s not unusual to find hardware that requires drivers only written for specific Linux distributions, or to work with vendors that have limited exposure to Linux in general.

4. Development team familiarity
Speed is huge when developing any product. When a team is considering programming language options for a new project, the decision is heavily influenced by the team’s familiarity with said language. This isn’t necessarily because the team is resistant to change, but because they know they can produce higher-quality work in less time if they can use a familiar language.

A similar consideration must be made when considering robotics OS. If the engineering team isn’t already familiar with it, time to market will be delayed as they learn its ins and outs.

5. Ease of system integration
A robot is rarely a standalone device; it often needs to seamlessly interact with other devices. Cloud robotics, speech processing and machine learning are all use cases that can benefit from processing information in a server farm instead of on a resource-constrained robot.

If possible, it makes a lot of sense to use the same OS on the robot as in the cloud. It prevents division of domain knowledge, and keeps processes the same, decreasing development time of both the client and server components.

6. Support availability
Every engineer gets to the point where they need some help. Where do they turn? If they need help with the OS, they often turn to the community around that distribution, where more often than not, others are experiencing the same issues. While community support is one of the best things about Linux, it’s never a good idea to rely on it commercially: sometimes no one responds, no one knows, or no one has time to figure it out “right now.”

Robotics developers should choose an OS backed up by commercial support options where they can predictably and reliably seek advice and solve problems quickly.

7. Software update process
Once a robot starts the move from development to production and maintenance, new factors come into play. A big one is the software update process, since, sadly, it doesn’t take long to find examples of companies that started shipping devices without considering the need to update them.

With the rush to get devices to market, it’s not at all rare to find devices with hard-coded credentials, development keys, various security vulnerabilities and no update path. Companies should choose an OS that has this functionality built into it.

8. Long-term support
In addition to considering how OS updates are delivered, one must consider for how long those updates will be delivered. Specific versions of an OS are typically only supported for a set amount of time. If the supported lifespan of the OS is shorter than the anticipated lifespan of the robot being produced, it will eventually stop getting updates.

9. Ensuring a profitable lifespan
Actually shipping and maintaining robots might be the final story for some, but it shouldn’t be, and it certainly isn’t the strategy necessary to retain customers and extend the robot’s lifespan. How does it stay relevant as competitors come out with newer products? One way is by supporting an app store.

This isn’t something that will apply to all robotic platforms, but it’s something that should be considered. Depending on the purpose of the robot, one could actually open it up completely, allowing control or sensor use via APIs, and then support a third-party app store of some kind. This can increase the longevity of the robot by essentially allowing third parties to have another vision for it, but this depends on the robot being pretty general-purpose.

Even if the robot isn’t general-purpose, an app store can open up alternative revenue streams, where new functionality can be provided in exchange for a fee, or on a subscription basis.

By keeping these nine factors in mind, companies can successfully seize the huge opportunity that robotics presents. The demand and market potential are there – now it’s just a matter of being ready.

About the Author

Kyle Fazzari joined Canonical as a Software Engineer in 2015, where he works on Snaps and Ubuntu Core to help companies bring secure and robust IoT devices to market.

Prior to this, Kyle worked as a Roboticist for the US Navy. His background and interests include robotics, embedded systems, and proclaiming that C++ is the only real language.