ROS 2

I am a staff engineer at Canonical, where I have worked for six years. My time here has been filled with brilliant people and amazing technology, and I’ve had the pleasure and privilege of playing pivotal roles getting a number of new projects off the ground. As I’ve said in the past, I joined Canonical to help my technical growth, and they delivered in spades. I have really loved my time here, which made the decision to leave all the more difficult....

The snapcraft CLI (the tool used to create snaps) has long had support for building snaps that use both ROS 1 and ROS 2. ROS 2 Foxy Fitzroy is the latest ROS 2 LTS, which runs on Ubuntu 20.04 (Focal Fossa). The snapcraft CLI recently gained experimental support for building Foxy snaps, so I wanted to walk you through doing exactly that with the goal of helping both of us: getting you familiar with this new feature, and at the same time getting some mileage on this so as to make it not experimental....

We got an interesting question from a customer today, and I think the answer might be helpful to a wider audience. Python 2 will reach end of life in two months. This shouldn’t be news to anyone who hasn’t been living under a rock, and plans are in place to use Python 3 in Noetic (whereas ROS 2 has always used Python 3). However, the question from our customer was this: What does that mean for existing ROS 1 distributions (Kinetic and Melodic)?...

We at Canonical have been hard at work on the security features of version 2 of the Robot Operating System (ROS 2). However, if we lift our collective heads up out of the weeds it’s easy to see folks completely misunderstanding how security works today in ROS 2. We’ve written some design articles to help distill all the moving pieces into something comprehensible, but I wanted to do the same here in a slightly less formal way....

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