ROS 2 Foxy Fitzroy: Setting a new standard for production robot development

The highly anticipated Robot Operating System 2 distribution Foxy Fitzroy (ROS 2 Foxy) has been released. ROS 2 Foxy is the most secure and reliable ROS distribution to date for production robotics application development. In this blog, we highlight key features and improvements available in this new release.

Background: ROS and ROS 2

Robot Operating System (ROS) is an open source software framework for robot development, including middleware, drivers, libraries, tools, and commonly used algorithms for robotics. AWS RoboMaker and a number of other Amazon robot-related groups use ROS as part of their services and products. For more background on AWS involvement in the global ROS community, see Matt Asay’s blog How AWS is helping to open source the future of robotics.

ROS was originally designed for use in the education research communities, but robotics companies use ROS as a framework for robotics product development. Because ROS wasn’t designed with production robot systems in mind, companies must put in time and effort to productize their internal forks of various ROS components.

ROS 2 is the second generation of ROS, redesigned from the ground up. ROS 2 seeks to address prior ROS shortcomings, reducing the complexity of converting ROS 2 based prototypes into products. An original “Why ROS 2?” article from the ROS 2 design documents website, gives background and rationale for the ROS 2 re-design decision.

ROS 2 provides new capabilities that ROS originally did not. Beginning with a layered architecture that separates the ROS client layer (RCL) from the ROS middleware layer (RMW). The RCL provides the developer interface and the RMW layer enables compatibility with different interchangeable low-level communication protocols. The RMW is built on top of the Data Distribution Service (DDS), a certifiable real-time publish/subscribe protocol designed for safety critical systems. DDS makes ROS 2 a more robust and interoperable framework. This architecture separates the lowest level protocol (DDS) details, from the application developer layer. Layered abstractions allow developers to focus on their unique application, algorithm, or driver instead of the underlying details.

ROS 2 layered architecture

ROS 2 also adds new advanced features, like Quality of Service (QoS) settings to tune communication between processes, and lifecycle nodes for managing deterministic system startup and shut down. In addition, ROS2 relies on more up to date C++ 14 and Python 3 language standards and libraries.

ROS 2 has had several releases over the years. The initial release was Ardent Apalone in December 2017, which was followed by releases every 6 months. The initial long-term support (LTS) version of ROS 2 was Dashing Diadamata in May 2019. Foxy Fitzroy (code named Foxy) is the latest LTS version.

ROS 2 Foxy Fitzroy

In the year between the Dashing and Foxy distributions, Open Robotics and the ROS 2 Technical Steering Committee (TSC) have worked diligently to add new critical features, automation, and supporting processes for ROS 2 Foxy Fitzroy. These new features qualify ROS 2 Foxy for inclusion in production grade robotics products and systems. In the following sections we go into detail on new ROS 2 Foxy features:

New Community Processes: Quality Levels, Security Policies and Rolling Releases

First, the ROS 2 community has defined a standard process to evaluate the quality commitments of a software package. These take the form of five distinct Quality Levels to provide developers a standardized method to communicate the maintainers commitment to software stability. The highest level of commitment is “Quality Level 1”, and the lowest is “Quality Level 5”. All packages in the ROS core achieved “Quality Level 2” at ROS 2 Foxy release, excluding certain underlying dependencies. In addition, a continuing effort to move the ROS core and all underlying dependencies to “Quality Level 1” will be completed by AWS RoboMaker before the end of 2020.

Second, the community is committing to certifying and monitoring the security of ROS 2 Foxy with the ROS 2 Security working group. A ROS 2 threat model was created and a Security vulnerability disclosure policy adopted complete with Safe Harbor protections.

Finally, releasing packages is now simpler in ROS 2 with the Rolling release distribution. The Rolling Release will be the basis for all future distributions. This provides the option to release your software package into all future ROS 2 distributions with a single execution of the release tooling.

Towards ROS 2 as a secure framework for production robots

Security of a robot, or any system, cannot be overvalued. The Security working group has integrated the DDS security plugins of Fast DDS, Cyclone DDS, and RTI the three major supported DDS implementations. The plugins enable you to inspect the underlying DDS security events in ROS 2 applications.

As described, in the ROS 2 DDS-Security Integration documentation by community member Kyle Fazzari security patching is easier in ROS 2 Foxy. This is due in large part due to the DDS-Security specification, which expands upon the DDS specification. Security enhancements are added by defining a Service plugin Interface (SPI) architecture. There is a set of built-in implementations of the SPIs, and a security model enforced by the SPIs. Specifically, there are five SPIs defined:

• Authentication: Verify the identity of a given domain participant.
• Access control: Enforce restrictions on the DDS-related operations that can be performed by an authenticated domain participant.
• Cryptographic: Handle all required encryption, signing, and hashing operations.
• Logging: Provide the ability to audit DDS-Security-related events.
• Data tagging: Provide the ability to add tags to data samples.

Security features in ROS 2 Foxy use the first three of these SPIs. Authentication and Access Control built-in plugins use the public key infrastructure (PKI). Plugins require a public and private key for each domain participant. In addition, to an X.509 certificate that binds the participant’s public key to a specific name. Each X.509 certificate must be signed by (or have a signature chain to) a specific certificate authority (CA) that the plugin is configured to trust. The Cryptographic plugin provides encryption, decryption, signing, hashing, etc. Both the authentication and access control plugins use the capabilities of the Cryptographic plugin in order to verify signatures, etc. This is also where the functionality to encrypt DDS topic communication resides.

The user-facing runtime support for secure ROS 2 applications is contained within the ROS Client Library (RCL), a core component of ROS 2. RCL is responsible for coordinating the enablement of DDS-Security for each DDS implementation that supports it. It supports three main features:

• Security files for each domain participant,
• Permissive and strict enforcement options, and
• A master on/off switch for all security features.

Core libraries and communication improvements

ROS 2 Foxy topics now automatically publish performance metrics and statistics to help users tune and audit the performance of their applications. The metrics are easily logged during operation and include average, min, max, and standard deviation of your ROS topic period for example. Statistics data can be useful in data analytics, diagnosing unhealthy system behavior and as input for known issue alarm and notification systems. Further, insights from these gathered statistics can inform design improvements such as adding triggers for specific modes of behavior when in a degraded state.

In ROS 2 Foxy, subscription failures due to QoS incompatibility are automatically reported as errors. An example of QoS incompatibility would be if a topic is published as ‘best effort’, defined as “attempt to deliver messages, but may lose them if the network is not robust,” but the subscriber requires a ‘reliable’ publisher, defined as “messages are delivered if possible, may retry multiple times if network is not robust.” In this example the subscriber won’t connect to the publisher since the requested quality of service can not be delivered, therefore, an error is generated and messages are not received. This new behavior prevents developers from mistakenly subscribing to incompatible topics and instead ensures they resolve the problem immediately. Surfacing issues during design implementation saves companies valuable time by minimizing shipped defects and the resulting support burden of those defects.

With ROS 2 Foxy, there are now multiple Tier 1 ROS Middleware (RMW) layer options. The newest Tier 1 fully supported RMW implementation, Cyclone DDS has implemented a number of improvements. Also, the default DDS, FastDDS, incorporates a large number of new features such as DDS security, DDS dynamic types, real-time compatibility (static memory allocation, support for new QoS policies, which track the health of a node), improved intra-process communication and improved performance over Wi-Fi. These added choices allow developers options when the default RMW doesn’t match their products needs.

More effective and convenient tooling

Rosbags are a well known useful logging, debugging and test tool in ROS. Now in ROS 2 Foxy, rosbags can record and replay data with any QoS settings. Prior to ROS 2 Foxy, all topics with QoS settings incompatible with the defaults would not be recorded. Adaptive QoS profile detection allows recording Best Effort Reliability topics, like the SensorData message preset profile, and latched messages topics that were published prior to recording start time, such as navigation maps. These new improvements show that rosbags can now be included in any ROS-based logging system using QoS.

Another useful new rosbag feature new in ROS 2 Foxy is ability to compress and decompress bag files while recording and playing data. This can save disk space and bandwidth, both of which are in limited supply on robot systems.

Similarly, ‘ros2 node –verbose’ and ‘ros2 topic –verbose’ command line tools now report QoS information for the topics examined. This newly added introspection element help when determining if and where a mismatch is occurring when tracing issues.

If your company performs work on ARM embedded boards, the new cross-compilation tool is available to streamline and simplify the compilation of ROS 2 workspaces for architectures others than X86-64 (for example, ARMHF/ARMv8).

Navigation Framework Stability, Features, and Documentation

One basic capability in robotics is moving a robot from point A to point B. In ROS the software packages that provide this capability are called “Navigation.” In ROS 2 the “Navigation2“ software stack is the latest iteration of the framework. Navigation2 is based on the original ROS Navigation stack but with improvements such as extensibility via behavior trees (BT) and startup flow control using lifecycle nodes. Navigation2 was first released for ROS 2 Crystal Clemmys and it has been continuously improving since then. The framework’s stability has been demonstrated by running Marathon2, a 24-hour stability test on a college campus.

According to Navigation2 maintainer Steve Macenski, the Foxy release includes:

• Full Windows support; previously only Linux was supported.
• New BT node plugins for distance and speed controllers, checking distance and speed conditions, check “is new goal received?”, check “is transform (TF) valid?“
• Navigation now can preempt long running processes like planners and recoveries, which is great for canceling a navigation goal and sending a new goal.
• A new documentation website: ros.org including tutorials for planners and costmaps.
• Test coverage improvements.
• Action servers now have action feedback on state of the asynchronous action process.
• Network stability improvements – all service calls and transforms have timeouts installed and are verified to be running at expected rates.

Drivers and “Out-the-Box” Integrations

Traditionally, developers and companies alike have been able to leverage a plethora of hardware and component drivers supported in the ROS ecosystem. With ROS 2, it is no different. There are already a number of sensors and robot drivers already supported and more actively added to each distribution. For instance, AWS customer Box Robotics was able to leverage the existing Ouster OS1-16 lidar driver, and contribute a number of enhancements and performance improvements back to the community. Box Robotics has additionally contributed Ouster Tooling by open-sourcing it to the ROS Community along with extensive performance analysis. Ouster Tooling is built on top of Ouster ROS 2 drivers, which is valuable to ROS developers and users, because it saves them time and effort. Box’s work is a model for engagement in the ROS 2 community, as they are contributing fixes back to the community while building on top of existing open source packages.

Box Robotics is rebuilding the AGV perception stack with human-like spatial awareness for increased driving speed, safety, and lifelong autonomy. Box has been able to get to market in record time by building their products on top of open source ROS packages. Their software, Warehouse HD, brings together the latest advances in 3D LiDAR, HD maps, and Deep Learning into a ROS 2 application framework optimized for high-throughput warehouse operations. In the animation, Box Robotics’ Warehouse HD online 3D SLAM module maps a manufacturing facility in real time. The resulting map forms the geometric foundation of the HD Map that can be used for localization, planning, and object detection to improve performance beyond what can be achieved by the hardware sensors at runtime.

AGV utilizing Box Robotics Warehouse HD technology to perform real-time 3D mapping of a facility

Manipulation is now fully supported using MoveIt2

Another exciting package included with ROS 2 Foxy is MoveIt2. MoveIt is the premier ROS-based motion planning framework and manipulation software for robotics, used in applications where complex collision-free robot motions are needed in order to complete manipulation tasks. MoveIt has been widely used and well-supported in the ROS community for several years. Thanks to a collaboration with PickNik Robotics and Intel, MoveIt 2 is now fully ported to ROS 2.

In this ROS-Industrial blog post, Jorge Nicho walks readers through using MoveIt2 on an industrial open source application. The ability to assemble ROS 2 launch files in Python came in handy; it allowed Jorge to instantiate a Python dictionary from a YAML file and pass its elements as parameters for his ROS 2 application. Below, you can see a short animation of Jorge’s application planning with MoveIt2, where a simulated UR10 robot arm has to move a camera to three scan position, meanwhile MoveIt2 is used to plan collision-free motions to those positions.

Animation of MoveIt2 integrated with Southwest Research Institute’s (SwRI) Collaborative Robotic Sanding application in ROS 2

You can find a tutorial for getting started and more about MoveIt with ROS 2 by visiting https://moveit.ros.org/.

Conclusion

ROS 2 Foxy is a major milestone release for the worldwide open source robotics community. It includes new community processes, features, performance enhancements, tools, and quality improvements. While one blog post can’t cover them all, hopefully this overview has informed you of the highlights, and encouraged you to dig deeper and get started developing applications on top of ROS 2. Now it is time for you to install ROS 2 Foxy and try it for yourself. For more information on contributing to ROS 2 visit the developer guide.