In 2018, the Robot Operating System 2 (ROS2) was launched as a successor to ROS1. At ROSCon 2019 several speakers shared their experience in moving from ROS1 to ROS2. Lessons were shared in two separate talks: the Autoware project, and a demo port by Rover Robotics.
The Autoware project took the opportunity to restart the design of their software to work better for ROS2. Autoware started as Autoware.AI, which is open-source software for self-driving vehicles. They based the software on ROS1, which was great for prototyping. However, there are three reasons why Autoware was not suitable for building certifiable products. The main reason is that ROS1 is not certifiable, and achieving this would take many years and people's effort. Determinism and memory safety of the Autoware AI application was not also possible. Last but not least, there are less than six years of support life left, as the end of life for ROS1 is specified as 2025. Therefore, Autoware decided to start autoware.auto as new software, which was more work but proved to give better long-term results.
Moving to ROS2 provided several benefits over ROS1. One benefit was managed launching, where you can specify in what order nodes launch. Another benefit was the Data Distribution Service (DDS) communication protocol, which can pass messages around with zero-copy, saving both CPU and memory resources. In terms of development they spend more effort on having increased test coverage, more and better understandable documentation, and more continuous integration to get the software certified.
To ensure continued happy use of the existing Autoware stack, the engineering team added support for the new project to the old project. This was achieved by adding a ROS1 bridge. This way new high-quality features are introduced in the new project, while keeping current existing contributors happy. In terms of contributors: because of the higher expected quality, Autoware needed to have a higher test coverage, a design document for every major contribution, and writing for and testing of deterministic execution. To encourage both current contributors and new contributors, people working on Autoware are mentoring them. They walk through the process of contributing to Autoware with potentially interested contributors, who are also given frequent encouragement.
A second talk was given by Nick Fragal and Nick Padilla, both working at Rover Robotics. They also used ROS1 for sharing common robotics code, and to minimize rewrites of common tasks. They want to use ROS2 to share reliable robotics code. The technical steering committee for ROS2 contains many people from large companies who take reliability seriously, and thus it can be expected that ROS2 will be adopted by many companies. This provides ROS2 with a lot of promise.
Fragal talked about their application: a t-shirt delivery robot which brings t-shirts to attendees at a conference. They made a demo using ROS1 and wanted to port it to ROS2. The initial port went smooth, but when they gave a new demo at a conference with slow wifi, they ran into problems.
The underlying reason was the DDS protocol, which did not run well over a slow wifi link. To solve this problem, they looked at the parameters which can be tweaked to make DDS work better on slow wifi. They also compared different implementations of the DDS protocol and worked together with suppliers to improve their implementation. Eventually, multiple DDS providers could be used to bring the software on the robot up within 10 seconds. The take-home message is to choose a DDS middleware that has zero-copy to prevent issues related to moving around images in your memory.
Overall, Rover Robotics estimate they spent approximately 60% of their time looking at the communication protocol when porting this demo. However, now that it is working better (for everyone) they hope to focus 90% of their effort on their navigation and application code.
