Beyond beautiful prototypes: equipping ROS 2 for efficient development of autonomous applications
The use of ROS 2, or Robot Operating System second generation, for the development of prototypes has been largely successful with explosive community growth over the years. From the automotive industry to agricultural machinery, researchers have found uses for ROS 2 in developing their applications. ROS 2 has many advantages in addition to the fact that it is an open-source tool. Developers using ROS2 for development have been faced with glaring challenges, but more so when deploying their systems into productive environment.
Despite attempts to solve most of the challenges that ROS 2 developers continue to face, the majority of the challenges persist. How can these challenges be addressed?
RTMaps – a proven tool for 20 years
RTMaps, or Real-Time Multisensor applications, has been used for the last 20 years in productive environments and seamlessly handles the challenges faced by ROS 2. Essentially, we asked ourselves if users can take advantage of the two systems and reap the full benefits. That is why we developed the ROS Bridge to allow communication across the two tools. Recently, we moved this integration up a notch by implementing a node manager that allows ROS nodes to run inside RTMaps.
The ROS 2 node manager allows for:
- Encapsulating a ROS 2 node into an RTMaps component
- Encapsulating a ROS 2 network into a single RTMaps component
Why develop ROS 2 applications in RTMaps?
Real-time requirements and safety: The real-time capabilities of ROS 2 are highly limited. In the automotive industry, deterministic behaviour is critical and indispensable. However, it is extremely complex and requires careful and time-consuming adjustments to achieve and ensure deterministic behaviour in ROS applications. In addition, functional safety, such as ISO26262 for the automotive industry, is a mandatory requirement when developing production-grade applications. Currently, it is not possible to obtain certification for ROS applications. There are solutions offered by third-party companies, but they require intensive and time-consuming recompilation of applications.
While ROS 2 faces challenges in production implementation, RTMaps is an ISO 26262-certified tool. Essentially, when developing using both ROS 2 and RTMaps, you are assured that you do not have to rewrite complete codes or adapt them for a different system when pushing your prototypes to production. Instead, only ROS 2 sections would require a rewrite. This significantly reduces time to market and resource allocation to your project.
Synchronization: Assuming we have three nodes, Node 1, Node 2, and Node 3, Node 3 subscribes into the topics published by nodes 1 and 2 (Figure 1). Its function is the fusion of these two streams and it will publish the outcome using its own timer. When latency in one of the upstream nodes is higher because of differential processing time, synchronization challenges arise.
RTMaps handles these challenges with simple changes in the reading policies. We can adjust the reading policy of the 3rd component to read data in a synchronized manner using time stamps. Essentially, with just a few clicks, you immediately can achieve synchronization of asynchronous data streams that would otherwise be a time-consuming and error-prone task in ROS 2.
Zero-copy mechanism: Modern systems are distributed and contain multiple applications which introduce the exchange of large volumes of data synonymous with automated driving. It is therefore desirable to avoid data copies because of the latencies that are introduced by these memory operations. To achieve this, we need to use a shared memory between our applications. In ROS 2, the publish-subscribe approach is employed, and the middleware is used in the communication to pass data between two applications. Achieving shared memory communication is difficult in ROS and requires the use of third-party tools or manipulation of low-level techniques, which are prone to errors. On the flip side, RTMaps default communication makes use of shared memory and hence eradicates the need for complicated workarounds.
Additionally, ROS 2 requires serialization and deserialization of raw data into .msg format for transfer, which can introduce latency and overheads for high bandwidth data, while RTMaps minimizes these operations by using shared memory for internal data transfer, allowing for more efficient data handling and reduced latency.
Data replay as fast as possible: Validation of software algorithms requires data replay. Having a framework that can replay data as fast as possible is important for efficiently testing perception and sensor fusion algorithms. It is not easy to adjust reading policies in ROS 2 to achieve these capabilities. The ease of changing reading policies on RTMaps simplifies the process of setting up your data replay to AFAP mode.
RTMaps simplifies debugging and visualization of applications
Debugging ROS 2 applications is straightforward if the number of nodes in a network is low. However, as the number of nodes increases, the complexity of debugging increases exponentially and the current debugging tools are inadequate. For instance, signal flow will increasingly become foggy as the number of nodes increases. The visualization below (Figure 2) gives a snapshot into the complications of dealing with a node heavy network/application. Not only is debugging complicated but maintainability of such a system is also compromised.
The fact that RTMaps is a tool with a graphical user interface means that the process of debugging code is simplified. Signal flow is clear and sections of the applications that have errors can easily be isolated. This not only makes it easy to debug applications, but also makes it easy to maintain your code and applications.
Figure 3. The user interface of RTMaps. The modular development environment allows for comfortable processing of a large variety of multisensor applications.
RTMaps eases the interoperability with existing automotive standards
The automotive and off-highway automotive industries are relatively mature. For instance, AUTOSAR is an architecture that is mostly used in the automotive industry. In addition, there is a need to have flexibility of choice on file formats such as PCAP, MCAP, MDF4, and so on. Standards such as XIL are also deeply integrated into the automotive test campaigns. Unfortunately, there is limited, if any, support of such standards when using ROS 2, which complicates the development of applications in these industries.
RTMaps has been used in the automotive industry for over 20 years and essentially has been tailor-made for automotive (highway and off-highway) applications. It supports AUTOSAR, XIL, DDS, CAN, CANFD, and many more automotive standards. Most of this support comes out of the box. Additionally, data file formats such as MDF4, MP4, PCAP, MCAP, HDF4, and many more are supported in RTMaps, and the support continues to grow. This implies that when developing with ROS, you only need to focus on the main sections of your applications and the rest is handled by RTMaps.
Data logging made easy
ROS 2 logs the time when data is received, which is useful for understanding the sequence and timing of data as it flows through the system. In contrast, RTMaps logs the time when data is captured, providing a precise record of when the data was originally generated by the sensor. It also logs time of issue (time stamp after data processing, i.e., latency). This distinction can be crucial for applications requiring accurate synchronization and analysis of sensor data, as it ensures that the logged time stamps reflect the true timing of events.
Conclusion
The development of applications for the automotive sector using ROS 2 is simplified by taking advantage of RTMaps capabilities. You can now simplify debugging, easily connect to automotive standards, develop faster, and make your production deployment easier and simpler.
