ROS production: our prototype as a snap [3/5]

This is the third blog post in this series about ROS production. In the previous post we came up with a simple ROS prototype. In this post we'll package that prototype as a snap. For justifications behind why we're doing this, please see the first post in the series.

We know from the previous post that our prototype consists of a single launch file that we wrote, contained within our prototype ROS package. Turning this into a snap is very straight-forward, so let's get started! Remember that this is also a video series: feel free to watch the video version of this post:

Prerequisites

This post will assume the following:

  • You've followed the previous posts in this series
  • You know what snaps are, and have taken the tour
  • You have a store account at dashboard.snapcraft.io
  • You have a recent Snapcraft installed (2.28 is the latest as of this writing)

Create the snap

The first step toward a new snap is to create the snapcraft.yaml. Put that in the root of the workspace we created in the previous post:

$ cd ~/workspace
$ snapcraft init
Created snap/snapcraft.yaml.
Edit the file to your liking or run `snapcraft` to get started

Do as it says, and make that file look something like this:

name: my-turtlebot-snap  # This needs to be a unique name
version: '0.1'
summary: Turtlebot ROS Demo
description: |
Demo of Turtlebot randomly wandering around, avoiding obstacles and cliffs.

grade: stable
confinement: devmode

parts:
prototype-workspace:
plugin: catkin
rosdistro: kinetic
catkin-packages: [prototype]

apps:
system:
command: roslaunch prototype prototype.launch --screen
plugs: [network, network-bind]
daemon: simple

Let's digest that section by section.

name: my-turtlebot-snap
version: 0.1
summary: Turtlebot ROS Demo
description: |
Demo of Turtlebot randomly wandering around, avoiding obstacles and cliffs.

This is the basic metadata that all snaps require. These fields are fairly self-explanatory. The only thing I want to point out specifically here is that the name must be globally unique among all snaps. If you're following this tutorial, you might consider appending your developer name to the end of this example.

grade: stable
confinement: devmode

grade can be either stable or devel. If it's devel, the store will prevent you from releasing into one of the two stable channels (stable and candidate, specifically)-- think of it as a safety net to prevent accidental releases. If it's stable, you can release it anywhere.

confinement can be strict, devmode, or classic. strict enforces confinement, whereas devmode allows all accesses, even those that would be disallowed under strict confinement (and logs accesses that would otherwise be disallowed for your reference). classic is even less confined than devmode, in that it doesn't even get private namespaces anymore (among other things). There is more extensive documentation on confinement available.

I personally always use strict confinement unless I know for sure that the thing I'm snapping won't run successfully under confinement, in which case I'll use devmode. I typically avoid classic unless I never intend for the app to run confined. In this case, I know from experience this snap won't run confined as-is, and will require devmode for now (more on that later).

parts:
prototype-workspace:
plugin: catkin
rosdistro: kinetic
catkin-packages: [prototype]

You learned about this in the Snapcraft tour, but I'll cover it again real quick. Snapcraft is responsible for taking many disparate parts and orchestrating them all into one cohesive snap. You tell it the parts that make up your snap, and it takes care of the rest. Here, we tell Snapcraft that we have a single part called prototype-workspace. We specify that it builds with Catkin, and also specify that we're using Kinetic here (as opposed to Jade, or the default, Indigo). Finally, we specify the packages in this workspace that we want included in the snap. In our case, we only have one: that prototype package we created in the previous post.

apps:
system:
command: roslaunch prototype prototype.launch --screen
plugs: [network, network-bind]
daemon: simple

This is where things get a little interesting. When we build this snap, it will include a complete ROS system: roscpp, roslib, roscore, roslaunch, your ROS workspace, etc. It's a standalone unit: you're in total control of how the user interacts with it. You exercise that control via the apps keyword, where you expose specific commands to the user. Here, we specify that this snap has a single app, called system. The command that this app actually runs within the snap is the roslaunch invocation we got from the previous post. We use plugs to specify that it requires network access (read more about interfaces), and finally specify that it's a simple daemon. That means this app will begin running as soon as the snap is installed, and also run upon boot. All this, and the user doesn't even need to know that this snap uses ROS!

That's actually all we need to make our prototype into a snap. Let's create the snap itself:

$ cd ~/workspace
$ snapcraft

That will take a few minutes. You'll see Snapcraft fetch rosdep, which is then used to determine the dependencies of the ROS packages in the workspace. This is only prototype in our case, which you'll recall from the previous post depends upon kobuki_node and kobuki_random_walker. It then pulls those down and puts them into the snap along with roscore. Finally, it builds the requested packages in the workspace, and installs them into the snap as well. At the end, you'll have your snap.

Test the snap

Even though we're planning on using this snap on Ubuntu Core, snaps run on classic Ubuntu as well. This is an excellent way to ensure that our snap runs as expected before moving on to Ubuntu Core. Since we already have our machine setup to communicate with the Turtlebot, we can try it out right here. The only hitch is that /dev/kobuki isn't covered by any interface on classic Ubuntu (we can make this work for Ubuntu Core, though, more on that later). That's why we used devmode as the confinement type in our snap. We'll install it with devmode here:

$ sudo snap install --devmode path/to/my.snap

Right after this completes (give it a second for our app to fire up), you should hear the robot sing and begin moving. Once you remove the snap it'll stop moving:

$ sudo snap remove my-turtlebot-snap

How easy is that? If you put that in the store, anyone with a Turtlebot (no ROS required) could snap install it and it would immediately begin moving just like it did for you. In fact, why don't we put it in the store right now?

Put the snap in the store

Step 1: Tell Snapcraft who you are

We're about to use Snapcraft to register and upload a snap using the store account you created when satisfying the prerequisites. For that to happen, you need to sign in with Snapcraft:

$ snapcraft login

Step 2: Register the snap name

Snap names are globally unique, so only one developer can register and publish a snap with a given name. Before you can publish the snap, you need to make sure that snap name is registered to you (note that this corresponds to the name field in the snapcraft.yaml we created a few minutes ago):

$ snapcraft register <my snap name>

Assuming that name is available, you can proceed to upload it.

Step 3: Release the snap

In the tour you learned that there are four channels available by default. In order of increasing stability, these channels are edge, beta, candidate, and stable. This snap isn't quite perfect yet since it still requires devmode, so let's release it on the beta channel:

$ snapcraft push path/to/my.snap --release=beta

Once the upload and automated reviews finish successfully, anyone in the world can install your snap on the computer controlling their Turtlebot as simply as:

$ sudo snap install --beta --devmode my-turtlebot-snap

In the next post in this series, we'll discuss how to obtain real confined access to the Turtlebot's udev symlink on Ubuntu Core by creating a gadget snap, moving toward our goal of having a final image with this snap pre-installed and ready to ship.

Comments

Hi Kyle, thank you for this awesome tutorials. I didnt know snaps and how ubuntu core can be used with ROS. Keep up the good work! Hope to see the remaining 2 posts soon.

By HectorA

Reply

That's great to hear, thanks Hector!

By Kyle

Reply

This is a great tutorial series. I am wondering about the support for ROS2 (ament)? I assume it's not even part of the Snapcraft system at all yet...

By SecretaryBirds

Reply

Thank you!

Good question. I've been following ROS2 development, but it's a bit of a moving target right now as it's so young. Add that to the fact that very few people seem to be using Kinetic much less ROS2 (most people are still on Indigo according to presentations at ROSCon), and you end up with Ament on Snapcraft's roadmap, but not having the highest priority right now.

Is that something you'd be interested in using?

By Kyle

Reply

Yes, I think so. Deploying on Ubuntu systems is still a new idea for us. But I like the concept behind snaps, and this blog is definitely helping me to see the benefits of releasing/deploying snaps.

By SecretaryBirds

Reply

Alright, I've created the issue[1], and put it on my backlog. I appreciate the input!

[1]: https://bugs.launchpad.net/snapcraft/+bug/1686850

By Kyle

Reply

This will be coming soon. Proposal here: https://forum.snapcraft.io/t/proposal-ros-2-support/1087

By Kyle

Reply

After several prerequisite features have landed, the Ament plugin pull request is here if you want to take it for a spin before it lands:

https://github.com/snapcore/snapcraft/pull/1583

By Kyle

Reply

Hi, this is really wonderful tutorial!

Now I'm trying it with my own robot, could you help me a point?

How can I set environment variable ROS_IP in snap package? I want to access the target remotely.

By Ron Tajima

Reply

Hey, thanks Ron!

How to set ROS_IP depends on how flexible you want it to be. The easiest way would be to use the `environment` keyword on your app, like this:

http://pastebin.ubuntu.com/25163796/

But of course that hard-codes the IP in your snap, which may not be desired. You can make it more flexible by writing a wrapper around the `roslaunch foo bar.launch` line and having it accept a parameter for the ROS_IP and set it before running `roslaunch`, or you could even go as far as using the configure hook to support changing it:

https://docs.ubuntu.com/core/en/guides/build-device/config-hooks

By Kyle

Reply

Hi, thank you for quick reply!
Your answer is perfect. I can go on using environment keyword while I'm surveying on config-hooks.
Thank you for your answer and effort on great software.

By Ron Tajima

Reply