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:
<node name = "talker" pkg = "talker" type = "talker_node" />
<node name = "listener" pkg = "listener" type = "talker_node" required = "true" />
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.
In ROS2 Crystal’s launch system, getting similar functionality involves a lot more boilerplate:
talker = launch_ros.actions.Node(
listener = launch_ros.actions.Node(
msg="Listener exited; tearing down entire system."),
This also creates a talker/listener system where, if the talker exits the system continues, but if the listener exits the launched system is shut down. However, you can see that, unlike the ROS1 example, there are a few steps required to get there. Specifically, it requires the LaunchDescription to include an event handler to listen for an exit event for every required node which then emits a Shutdown event, which then FINALLY causes the launched system to shut down. That doesn’t scale particularly well to a real system where a large number of nodes may be required to run successfully.
We went through a few design iterations for how to best solve this, and decided that both the scaling and the boilerplate issues could be solved if the Node definitions could specify somehow that they were required. Rather than carry over that language from ROS1, though, we decided to keep some commonality with OnProcessExit and simply add an on_exit action list directly to the Node definition. We also added a new action called Shutdown. Using these two new features together allows one to very simply specify that, if a given node exits, it should shut the entire launched system down. This greatly reduces boilerplate and scales far better than adding an event handler for each node. Take a look:
This functionality is already available in master, and will of course be included in Dashing (scheduled for June).
This article originally appeared on Kyle Fazzari’s blog.
Learn how the Ubuntu desktop operating system powers millions of PCs and laptops around the world.
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…
Following previous events in New York, Seattle, and London, the fourth Snapcraft Summit is taking place in Montreal, Canada from June 11th to 13th 2019. We have partnered with Travis CI this time and also expanded the scope of the event to…
The snapcraft CLI has supported building ROS1 snaps for a while via the catkin plugin. We supported the ROS2 betas via the ament plugin, but that was before Open Robotics had a ROS2 package repository setup, which meant that the ament…