If this sounds unfamiliar, ROS (Robot Operating System) is an open-source framework and tool suite for building robotic systems, and it comes in two primary flavors: ROS – the original research version using Python and XML, and ROS2 – a performance-enhanced version that uses DDS as its connectivity framework.
This ‘Bouncy’ release is special because it includes RTI Connext DDS in the binary distribution under a non-commercial license. Professional-grade DDS is now a cost-free option for researchers, evaluators and academics using ROS2 for robotics applications.
This means that the DDS tools and services ecosystem is available to all ROS2 users, thanks to the standards-based interoperability inherent to DDS including:
- RTI Admin Console: the go-to tool for diagnosing system connectivity issues.
- RTI System Monitor: the best tool for tuning and optimizing system performance.
- RTI Recording Service: high-bandwidth, long-duration recording and playback of topic data from your system.
- RTI Routing Service: an out-of-the-box solution that acts as an architectural bridge/gateway.
Let’s take a look at how RTI Admin Console can make diagnosing and understanding ROS2 connectivity issues a breeze. I recently put together a LiDAR data source for ROS2, and my initial attempt to display the data using RViz resulted in: no data. The terminal for RViz was not producing many helpful messages:
I also used some of the ROS2 built-in diagnostic commands to help determine the cause of the non-communication. For example, I can use “ros2 topic list” to show the data items that are currently active:
I’m interested in the topic “/velodyne_points”:
Is the publisher of “/velodyne_points” producing any data?:
Yes . . . so why isn’t the data being displayed by RViz?
Let’s try diagnosing this problem using RTI Admin Console, which is conveniently available in the RTI Launcher:
From the moment Admin Console is launched, it lets me know that there is a problem amongst the DDS network participants (note the red X box indicator):
Expanding “Domain 0” and highlighting my topic of interest (/velodyne_points) immediately shows the cause of the problem – a QoS mismatch:
My publisher is offering “Best Effort” reliability, but the RViz subscriber requires a “Reliable” connection. Rather than allowing this mismatch to continue, DDS refuses the connection and prevents the mismatch from continuing to go unnoticed.
This QoS mismatch was immediately revealed by Admin Console, along with the details of every other participant in this ROS2 DDS network, including all of the normally-hidden internal topics of ROS2. At a glance I can determine that:
- There are some error log entries – will look at those later.
- There are a number of “Writer-only” and “Reader-only” topics. These are topics that can publish or subscribe to a topic, but do not have a complementary subscriber or publisher at this time.
- This system is running a mix of RMW layers from different DDS vendors. This is not a problem. DDS was designed for multi-vendor interoperability.
- When running with the Connext RMW layer, type code information is included in the DDS discovery traffic, and can be easily viewed in Admin Console:
When using other RMW layers, this information is suppressed.
Admin Console can also subscribe to data topics and print or visualize their data values:
With the help of Admin Console, I was able to identify the QoS mismatch that prevented the data transfer and get the system running in a few minutes.
Upcoming blog posts will continue to highlight the power of the combined ROS2/DDS ecosystem – to extend, diagnose and optimize a ROS / ROS2 system, and to provide enhanced 3D visualization to pure DDS systems.