Kyle Fazzari, Software Engineer, Canonical – the company behind Ubuntu.
This year, a robot called ‘Pepper’ appeared as a witness in parliament and gave evidence. 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 developments show how technology 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 that worldwide robotics-related spending on hardware, software and services will reach $230.7 billion by 2021. Robots are taking almost every industry by storm.
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.
To succeed, companies must start by by selecting 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.
Once the robot reaches production, it may be impossible to maintain the OS that’s perfect for hacking things together. Similarly, the build-your-own option means maintaining the entire operating system (backporting upstream security updates, etc.) for the lifetime of the robot. The operating system choice also can influence a company’s monetisation route, support offerings, and security strategy.
As companies join the robotics revolution, there are a number of essential operating system 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:
- A consistent OS: The operating system 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 operating system that best supports whatever they’re developing, but it’s easy to get tunnel vision during development and forget to consider other factors;
- Software stack compatibility: Regardless of other reasons that go into deciding on an operating system, 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 potential operating systems are evaluated with this need in mind, it will help lead to a streamlined development process.
- 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.
- 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 operating systems: If the engineering team isn’t already familiar with it, time to market will be delayed as they learn its ins and outs.
- 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 operating system 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.
- Support availability: Every engineer gets to the point where they need some help. Where do they turn? If they need help with the operating system, 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.
- 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.
- Long-term support: In addition to considering how operating system updates are delivered, one must consider for how long those updates will be delivered. Specific versions of operating systems are typically only supported for a set amount of time. If the supported lifespan of the operating system is shorter than the anticipated lifespan of the robot being produced, it will eventually stop getting updates.
- 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.
A robot app store can enable new functionalities, even if the robot in question isn’t general purpose. In exchange for a fee or subscription, these functionalities could open up alternative revenue streams.
To take full advantage of the demand and market potential for robots, companies should keep these nine factors in mind during the planning process. Robots present a huge opportunity just waiting to be seized – companies must be ready and waiting.