We at Canonical care deeply about robotics. We firmly believe that robots based on Linux are cheaper to develop, more flexible, more secure, and faster to market. One of the contributing factors to this being the case is the Robot Operating System (ROS). ROS is by far the most popular middleware for creating Linux-powered robots. It provides all sorts of open source tools and libraries and pre-made components that solve common problems encountered during robot development....

I’ve had a very particular itch for a long time, now. Something I love about open source is that it empowers developers to scratch their own itches, and a while back I decided to do exactly that. We’ve used it in production on the Nextcloud snap for a few months with relatively few issues, so I think it’s time to open it up for wider use… in case you share my itch....

A while back I wrote a post about distributing a ROS system among multiple snaps. If you want to enable some sort of add-on story, you need to have multiple snaps, and that remains the way to do it today with ROS. That approach works, but I’ll be the first to admit that it’s not terribly elegant, and we’re working on making it better. However, in my experience talking to various ROS users creating snaps, they oftentimes end up using multiple snaps not for an add-on or app store story, but for build speed....

Security is a always a balancing act between safety and practicality. If we’re talking about the internet, you can go all the way from something impenetrable and completely useless to something easy to use and also part of a botnet. In the case of the Nextcloud snap’s SSL cipher suite, as with any website, it’s a balance of supporting only the best ciphers while also ensuring that older clients aren’t left out in the cold....

When using the Robot Operating System (ROS), it’s fairly common to want to shut down a launched system if a specific node (or set of nodes) exits. This is pretty easy in ROS1, because launch files support the required attribute on each node. As a result, crafting a two-node system where one of the nodes is required is straightforward: <launch> <node name = "talker" pkg = "talker" type = "talker_node" /> <node name = "listener" pkg = "listener" type = "talker_node" required = "true" /> </launch> This launch file creates a talker/listener system where, if the talker exits the system continues trucking along, but if the listener exits the entire launched system is shut down....