UPDATE: I’m leaving this series up for historical purposes, but please note that I no longer recommend Ubuntu Core or snaps for use in robotics. This is the second blog post in this series about ROS production. In the previous post we discussed why Ubuntu Core was a good fit for production robotics. In this post we’ll be on classic Ubuntu, creating the example ROS prototype that we’ll use throughout the rest of the series as we work toward using Ubuntu Core....

UPDATE: I’m leaving this series up for historical purposes, but please note that I no longer recommend Ubuntu Core or snaps for use in robotics. 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....

One of the key tenets of snaps is that they bundle their dependencies. The fact that they’re self-contained helps their transactional-ness: upgrading or rolling back is essentially just a matter of unmounting one snap and mounting the other. However, historically this was also one of their key downsides: every snap must be standalone. Fortunately, snapd v2.0.10 saw the addition of a content interface that could be used by a producer snap to make its content available for use by a consumer snap....

Previous Robot Operating System (ROS) releases only supported i386, amd64, and armhf. I even tried building ROS Indigo from source for arm64 about a year ago, but ran into dependency issues with a missing sbcl. Well, with surprisingly little fanfare, ROS Kinetic was released with support for arm64 in their prebuilt archive! I thought it might be time to take it for a spin with Ubuntu Core and its arm64 reference board, the DragonBoard 410c, and thought I’d take you along for the ride....

When researching snaps, one of the main advantages everyone talks about is the fact that they’re transactionally updated. That is, an upgrade either succeeds or fails, it doesn’t leave the snap in a broken state. If you have snap “A” installed and an update for it is released, it’ll automatically update. If that update is somehow broken, the snap will roll back to the previously-working revision. However, no one has really talked about how that works....