From ROS prototype to production on Ubuntu Core

Please note that this blog post has outdated technical information that may no longer be correct. For latest updated documentation about robotics in Canonical please visit https://ubuntu.com/robotics/docs.

My background is pretty heavily littered with robotics. A natural side effect of this is that I’ve published numerous posts discussing snaps, Ubuntu Core, and different robotics frameworks (ROS and MOOS specifically). But my robotics experience was professional, which meant I didn’t really have a reason (or money, these things can be expensive) to buy any robotic systems personally. As a result, most of my posts have been pretty high level. Well today, that changes. Today, I have this.

What you see here is a Turtlebot 2. Well, not really. What you see here is the iClebo Kobuki, which is the base of the Turtlebot 2. The barebones version of the Turtlebot 2 is the Kobuki plus some mounting hardware that goes on top. You can save some significant money if you can do without the mounting hardware: skip the kit, and buy the Kobuki itself.

Anyway, the Turtlebot 2 is the go-to robotic platform for people learning ROS. Not just because there’s no time needed for researching components and writing the necessary software to build your own, but because this is what the ROS community has standardized around. It already has numerous ROS packages written for it, as well as its own set of excellent tutorials on the ROS wiki.

This situation makes it the perfect guinea pig for the ROS blog series I’ve been itching to write: taking your ROS prototype to production with snaps and Ubuntu Core. This series will cover the following topics:

• ROS production: our prototype [2/5]
  Creating an example prototype using classic Ubuntu and ROS Kinetic.
  
• ROS production: our prototype as a snap [3/5]
  Packaging that prototype as a snap.
• ROS production: obtaining confined access to the Turtlebot [4/5]
  Creation of a gadget snap to allow explicit access to the Turtlebot.
• ROS production: create an Ubuntu Core image preinstalled with our snap [5/5]
  Creation of an image that is ready for the factory.

In this first post, I want to discuss why Ubuntu Core is such a good fit for production robotics. Note that this is also a video series, feel free to watch the video version of this post:

ROS is great for research and development. Getting started is as simple as installing a few packages from the ROS archive, creating a workspace, and diving in. This is all I ever did in the past. When it was time to try my changes out on the real robotic system, I’d SSH into it, fetch my changes from git, and run the source on the robot. This is great for prototyping, but what happens when you’re ready to ship something?

Going to production opens up a host of new concerns. You have to ask yourself a number of questions, such as:

1. What is my factory process?
2. How is the base OS updated so as to remain secure?
3. How do I update the robotic software I have on top?
4. How is the device recovered if an update goes wrong?

Let’s take a look at each of these questions in turn.

1. What is your factory process?

In other words: how do you initially deploy Ubuntu, ROS, and your special sauce on a device you’re about to ship? By hand? That doesn’t scale and is error prone. Seed a custom Ubuntu distro with everything? That would actually work, but it’s not easy to maintain. I know some ROS users use Chef or another automation tool for this, but there’s a serious learning curve there. With Ubuntu Core, you’ll end up with a single flashable image that includes the operating system as well as your ROS system, all ready to go. I’ll show you how in this series.

2. How is the base OS updated so as to remain secure?

Perhaps with your complex Chef setup you’ve also enabled automatic security updates. Good thinking, but there are other issues with this (see question 4).

With Ubuntu Core, assuming you use one of the reference devices (this includes just generic amd64) and don’t need to mess with the kernel, the kernel and core snaps are maintained by Canonical for the lifetime of the LTS. They’ll automatically update out of the box, too.

3. How do I update the robotic software I have on top?

A question to be answered first is: How is your software packaged? Is it, even? Are you still running it from source? Do you have it on the ROS build farm? What if it isn’t public? Perhaps you use bloom and then build debs locally, but then you need to maintain your own archive infrastructure. None of these are fun solutions, nor do they lead to an easy upgrade process.

If you package your ROS system as a snap, it includes all its dependencies (including its greater ROS dependencies). If your factory process included placing a snap on the robotic system, then it will automatically update. All you need to do is release the update in the store, and all the deployed devices with automatically update themselves.

4. How is the device recovered if an update goes wrong?

My wife had this happen recently. She brought her laptop to me with a screen showing the grub prompt, unable to boot. After some poking, it turns out that “somehow” (she denies any knowledge of how this may have happened) the computer was forcibly powered off while the kernel was being updated (an automatic security update, no less). I manually told grub to boot the previous kernel, reinstalled the new one, and all was right with the world. But that would have been a lot harder if her laptop was actually a headless, production robot in my warehouse that I didn’t even know ran Linux.

Ubuntu Core is based entirely upon snaps, which are really just squashfs images containing software and their dependencies. This allows them to have some neat properties, one of which is that the upgrade process is as simple as downloading the new image, unmounting the old one, and mounting the new one into place (this is all done automatically, behind the scenes). Another one is that the old snap, once unmounted, is actually kept around, in case something goes wrong with the new snap. If a problem is detected, either by automated health checks, your own health checks within the snap, or in the case of a kernel, a panic, the snap will be reverted to the old one automatically. The atomic nature of snaps also means that either an installation succeeded or failed, there’s no intermediate state like what happened above to my wife’s laptop. If power is pulled in the middle of an update, snapd will remember that it was updating next time it boots, and finish the update.

I hope I’ve given some good justification on why Ubuntu Core is a good fit for production robotics. The next post in this series will be all classic Ubuntu and ROS, discussing a basic prototype with the Turtlebot that we’ll use as an example throughout the rest of the series as we work toward production.

This article originally appeared on Kyle Fazzari’s blog.