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
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!