Rhys Davies
on 7 January 2020
Please note that this blog post has out technical information that may no longer be correct. For latest updated documentation about robotics in Canonical please visit https://ubuntu.com/robotics/docs.
When a robot is not up-to-date, it becomes about as useful as an expensive paperweight, or companies have to burn money to get them back online. Yet when mobile apps need updating, it only takes a few clicks and a minute or two before it’s back up and running. This blog discusses how ROS robots utilising snaps can be kept up-to-date just as easily
Staying up to date and secure with snaps
Snaps allow for bug fixes as they arise. If there is a day 0 issue or day 1000 issue, each robot can receive the fix quickly, and if it breaks, they will roll back to their last stable state. Snaps are containerised software applications that can receive updates from anywhere. Either from the public snapstore or privately, for total control.
Take our Cyberdyne case study, for example; a Japanese robotics company that looked to solve the problem of labour shortages with robots. They built an autonomous robot, the CLO2, that uses artificial intelligence and 3-D mapping. With the CLO2 deployed in airports and malls across Japan, they deployed their software as snaps to eliminate the cost of getting engineers on site.
And with snaps came security. Snaps are automatically confined from the OS and other apps as digitally signed packages, with a very specific way of interfacing with other applications. The attack surface is minimal. This makes snaps useful for building reliable and long-lasting robots in the field. There are thousands of public snaps available to download that are maintained and continually supported by a community of developers. Any existing software can be made into a snap, or you can make your own.
Taking ROS robots to production
Development of your robot’s software might already be done for you. The robot operating system (ROS) is a framework that allows for the reuse of code between thousands of robotics projects. Thousands of packages already exist for as many use cases with countless ways to get started. The ROS community is huge, with varying levels of expertise. Developing on ROS can is for beginners and for experts. Plus, given that the number of ROS packages being deployed as snaps is always increasing, robots can enjoy all of the previously mentioned benefits of snaps.
We’re seeing major OPEX reductions as a result of
Professor Yoshiyuki Sankai, CEO and founder of Cyberdyne
implementing snaps, thanks to both lower engineering overheads
and bandwidth consumption. It is a solution that matches perfectly
with our strategy to connect all devices via network and handling
the accumulated information in the digital space.
Cyberdyne has been utilising ROS on Ubuntu since their earliest prototype. They received support from the community when they needed it and were able to take their product to production using ROS. They could be confident going to market because ROS has long term support (LTS) built-in, much like Ubuntu. This support ensures longevity in the field and can be extended to last a robot’s lifetime.
Managing a robot’s private software
To monitor and update software remotely and indiscriminately, a robot needs to talk to a private software repository, such as a Brand Store. Individually patched and updated software can make robots in the field a kind of special “snowflake” – An individual robot that needs specialist tracking and maintenance. A Brand Store provides over the air, secure and transactional device management through controlled snap updates. So if you discover a bug on a robot, a patch can be sent out immediately which can later be quality tested in-house before being deployed to the rest of your machines.
By implementing a Brand Store, Cyberdyne’s time and resources were freed up from manual updates for further development. Their snaps and ROS packages installed inside a private Brand Store for IP security and to definitively control their software development and distribution. As their organisation grows they will still be able to contribute to the open-source community software while keeping their products up to date and their own.
Summary
Robots need regular maintenance and frequent updates. With one or two robots, this process is manually pretty quick but is still tedious. With each robot added the monetary cost of paying for engineers to fix the product increases. The time cost of taking engineers away from developmental work increases. And the lack of long term sustainability grows. When organisations that have this problem scale-up, the problems scale with them.
Cyberdyne avoided all of these problems in their CLO2 cleaning robots with snaps, ROS and a Brand Store. By implementing snaps they were able to update their software remotely. With ROS this meant they could patch their entire system, from the OS to the drivers, as issues arose. And so they freed resources for the development of other Cyberdyne Robots. Once they began to grow, they then used a private Brand Store to scale their solution. For more information, our case study goes into more detail.
