Enter the search phrase
ROS (Robot Operating System) is an open-source framework, a set of libraries and tools for building robot applications in a diverse set of areas such as automotive, mobile logistics, healthcare or UAVs. ROS has sensor drivers, state-of-the-art algorithms and powerful tools that can cut a lot of the cost of development. It is growing fast, with users rapidly moving towards ROS 2.
At Robotec.ai, we embrace ROS 2 and value our engineers’ strong expertise. We are an active part of the community and use ROS 2 in our commercial projects and in our products.
One of the important tools in ROS is called “rosbag” and has the purpose of recording and replaying data that robots send out and receive. This data can include sensor readings such as lidar point cloud or camera images, control commands and various states. Such recorded data can be useful in multiple ways:
The volume of recorded data can get quite high, especially with multiple high-resolution sensors in the use-case. In some cases, hundreds of megabytes of data in ROS messages per second are recorded, and the storage must deal with terabytes of rosbag files. Especially in such cases, performance of the rosbag matters a lot. If the recording software fails to cope with the incoming data, messages are lost in the process and the recording is incomplete.
This has been an issue with rosbag2 since the tools’ performance was underwhelming and many users were negatively impacted by the limitations. Some were forced to use ROS 1 for recording and others developed their custom recorders. At Robotec.ai, we ran into performance and stability issues with rosbag2 in one of our customers’ projects. Clearly there was a great need to make rosbag2 better.
Robotec.ai was selected by Apex.AI, Open Robotics, ADLINK and University of Tokyo to improve the performance of rosbag2. Previously, we evaluated the performance and pointed out its issues and suggested what needs to be done to fix them. Now it was time to make the actual improvements.
We worked closely with the ROS 2 Tooling team to improve rosbag2 performance by implementing buffered asynchronous writing as well as back-end optimizations. While developing these improvements, we also fixed some stability issues and added a new feature to apply filters to recorded data.
The impact of our work is best seen in comparison to the most recent release of ROS 2 called “Foxy”. To meaningfully estimate improvements, we implemented a dedicated benchmarking package which is now also a part of ROS 2.
On the plot below you can see actually recorded messages as the percentage of total number of messages that were to be recorded. Foxy (red) is compared to master branch which contains our improvements, in three setups to control for the transport layer. Note that throughputs of 100, 200 and 300 MB/s were tested and each datapoint is an average of 3 runs.
It is not hard to notice that the performance improved a lot! Details of benchmarking and other plots can be found in our report. You can find it in the ros2 repository.
The changes are so impactful that the Tooling team of ROS 2 wants to fast forward them to the LTS version (Foxy). This is a very rare case where the value of change could justify API breakage. ROS community is offering feedback on Discourse, the primary ROS community forum. So far most of the feedback is favoring the backport.
Stay tuned for our next post in which we will explain how to use the performance benchmarks with your use-case and how to tweak your recording system to maximize performance!
Image credits: Ela Chełmińska