Hey all. You’ve probably heard of snaps (a new packaging format that works on a number of different Linux distributions) and Ubuntu Core (a new distribution of Ubuntu based entirely upon snaps). In case you haven’t, imagine being able to create a pre-built, installable package of an entire ROS workspace with no more metadata than this:
name: ros-example
version: 1.0
summary: ROS Example
description: Contains talker/listener ROS packages and a .launch file.
confinement: strict
apps:
launch-project:
command: roslaunch listener talk_and_listen.launch
plugs: [network, network-bind]
parts:
ros-project:
plugin: catkin
catkin-packages:
- talker
- listener
That’s from the basic ROS demo contained within Snapcraft, the tool used to create snaps. Add one line (daemon: simple) to the launch-project object in apps and it would be a service, running at boot, no systemd knowledge required.
If that’s new to you and you like it, cool, you can stop reading right here! But I’m writing today to let you know about something new.
One of the key tenets of snaps is that they bundle their dependencies. This is by design, and is one of the strengths of snaps, but it can be a downside as it’s inflexible: ROS historically couldn’t be shared between snaps. I wanted to let you know that, as of Snapcraft v2.28 (soon to be released), this will be changing.
Soon you’ll be able to build snaps utilizing an underlay that comes from another snap, and utilize that underlay at runtime via what’s called the content interface. This will allow for a few things:
- Reduce size by not requiring every ROS snap to include
roscore,rosrun,roslaunch, and so on. - Allow for new behaviors to be shipped in “add-on” snaps that can work together with a base platform instead of requiring that every ROS snap be standalone.
This post is already getting a bit long, but if this sounds interesting to you I wrote a detailed article outlining the rationale as well as walking through a basic example. This has not undergone any heavy usage, but please do give it a try!