Migrating a large ROS 1
codebase to ROS 2
A community perspective

Geoﬀrey Biggs (Tier IV/The Autoware Foundation)
Esteve Fernandez (Apex.AI/The Autoware Foundation)

AutowareToday’s Pop Quiz

How do you move a large existing community of users from ROS 1 to
ROS 2, while rebuilding your software from scratch to take advantage ofthe new capabilities of ROS 2, without causing the community tocollapse?

Autoware.AI● Open-source software forself-driving vehicles● Based on ROS 1● Great for prototyping:🙂 → 😀 → 😃 → 😄 →🥳
● Not so great for building products

Limits of ROS 1-Based Software● Autoware.AI’s design and implementation are constrained by ROS 1● Extremely diﬃcult to certify○ ROS 1 is not certiﬁable without signiﬁcant (many years andpeople) eﬀort○ (So is Autoware.AI, which makes it worse)○ Determinism, memory safety, etc. are not possible● Less than 6 years of life left
○ Last release in mid-2020○ End-of-life in 2025
○ We don’t want to maintain such a large open source software
project ourselves - lose the beneﬁts of the herd

Limits of ROS 1-Based Software● Simple launch system○ Hard to control startup order and timing of nodes○ Node wait-for loops● Custom protocol missing many features of modern communications
middlewares○ Security!
○ Real-time○ Implementation suitable for embedded systems○ Usability on lossy networks● Nodes running out of lock-step● Cannot choose when to compose nodesMove to ROS 2 and get...
● Managed launching● Node lifecycles● DDS○ QoS paradise○ DDS-Security● Composable nodes● Consistent API● Zero copy (in ROS 2 Eloquent)● Many, many other features🥳

Move to ROS 2 and get...

New ways to architect your system to achieve robustness, reliability, andsafety, as well as eﬃciency

Porting to ROS 2: The Options
1. sed -i ‘s/ros/rclcpp/g’ *.h *.cpp○ Gets you to ROS 2 quickly○ Still requires some work meeting new APIs so isn’t a ﬁve-minutejob○ Behaviour is not guaranteed to be the same between ROS 1 and
ROS 2○ → Not safe without comprehensive tests○ Miss most of the great new features of ROS 2

Porting to ROS 2: The Options (con’t)

2. Start again and re-design○ Re-think from the architecture up to take advantage of newcapabilities of ROS 2○ More work but better long-term results (so long as you ﬁnish it atsome point○ Can ﬁx other deep problems with your code base at the sametime
○ Your community will be … unhappy with youAutoware: The Next Generation
●
●

●
●
●
●

Autoware.Auto, the next generation of Autoware
Aims to ﬁx all the problems with Autoware.AI○ High test coverage○ Comprehensive and readable documentation○ Modular code base to improve CI times, reusability and adaptability○ Flexible and easy-to-extend architecture○ Deterministic execution
Provides a ﬂexible framework for self-driving research and application
development
As close to production-ready as possible for an open-source project
Better use of and contributions to upstream
ROS 2-based

The plan with a capital P● Throw out Autoware.AI (the ROS 1 version of Autoware)● Design a new Autoware○ ROS 2-based○ Deterministic, real-time, memory safe, and all that other goodstuﬀ that we want for safety○ Great new architecture that makes Autoware Even BetterTM● Implement this new Autoware with software engineering
best-practices● The result: Everyone loves hates us for forcing them to move to anew, incomplete system!

Wait, hold on...

Porting Can Hurt A Community● The project needs:○ Re-design to take advantage of
new capabilities of ROS 2○ Probably a lot of cleaning up andbreaking APIs
● But the community members need:○ A gradual transition○ A clear path to adoption of theported software○ Working software now

Porting Can Hurt A Community (con’t)● Porting must be carefully
managed if you want to bring the
majority of your community withyouNew plan!

● Start again, but don’t throw away the existing code base all at once
● Port the algorithms where appropriate, but○ Redesign the architecture○ Re-do the implementation to be memory-safe, deterministic, etc.
● Keep the community happy by building the Autoware of Theseus

The Ship of Theseus● Thought experiment that the ancient Greeks liked to play with○ https://en.wikipedia.org/wiki/Ship_of_Theseus
1.
2.
3.
4.

Theseus was a hero
He had a ship, and did great things with it, so it was kept as a
museum pieceOver time, bits rot and are replaced
When all the bits have been replaced, is it still the same ship that
Theseus used?

● See also: Your grandfather’s axe

Autoware.Auto: Theseus’s Self-Driving Platform

Empty project

Autoware.Auto
Full functionality
Full functionality

Port
algorithms

Autoware.AI
Time

Thin wrapper around
Autoware.Auto

Autoware.Auto: Theseus’ Self-Driving Platform● Users of Autoware.AI can continue to use it● Autoware.AI provides the missing pieces of Autoware.Auto○ Via ROS 2 launch ﬁles and the ros1_bridge○ Users of Autoware.Auto can do full self-driving● Over time, parts of Autoware.AI are removed and that functionality
used from Autoware.Auto○ Via ROS 1 launch ﬁles and the ros1_bridge● Replace Autoware.AI little by little to minimize disruption by users● If things go perfectly to plan (🤣), Autoware.AI users should not
notice that they are actually using Autoware.Auto

Bridging Two Autowares● Using the ros1_bridge to join
Autoware.AI and Autoware.Auto● Bridge translates any topics andservices where the data types
have not been changed● ros1_bridge does not handle
actions, but Autoware.AI does notuse actions

Point cloud data
ros1_bridge
Localisation result

Bridging Two Autowares● Where the data types havechanged, a customised
bridge is sometimes
necessary● Prefer to create custom
bridges rather than restrict
the new architecture

Old data formats
Custom bridges
New data
formatsros1_bridgeImproving Code Quality of Autoware● Applying good software engineering
practices○ Rationale for every change recorded○ High test coverage from the start○ Use of CI not just for tests but forvarious design and code quality
analysesImproving Code Quality of Autoware (con’t)●●

Requirements on PRs are more strict○ Must pass CI○ Must have suﬃcient test coverage○ Must have gone through a design review○ Must meet coding style standards○ Must not have unacceptable static
analyser violations○ Must add or update documentation(documentation reviews included)
Comprehensive integration tests using
launch_testingHelping The Community Step Up● Even if higher quality is a goal, the community may not be ready○ “That contribution guide is really long…”● Help your community learn how to meet your new, higher standards● Mentor contributors!
○ You cannot throw out detailed contribution requirements without
giving guidance○ Encourage new contributors, don’t throw them to the wolves● Contributors should know what they can expect of the process aswell as what the process expects of themHelping The Community Step Up (con’t)● Create detailed contribution guides○ Describe the code review process in detail○ Provide a detailed PR review guide for reviewers● Provide tutorials on the software engineering practices you wantused, e.g. how to○ Design and implement for testability○ Write eﬀective tests○ Check test coverage○ Check for memory leaks○ Write for and test deterministic execution

Helping The Community Step Up (con’t)● Use automated tools to assist contributors○ Make CI available to everyone so anyone can see their PR get
checked○ Provide automated code linters, static analysers, etc. so complying
with rules is as simple as possible

Helping The Community Step Up (con’t)

Mentor Contributors!
New contributors especially will be discouraged by strict requirements.
Walk them through the process and provide frequent encouragement!

End Goal
Autoware.Auto●●●

Full-functionality self-driving
stack in ROS 2
Near-production quality
Strict quality control policies
○
○
○

●

Design reviews
Code quality maintenance
Safety considerations

Well-documented andmentored contribution process

Autoware.AI●

Thin wrapper around
Autoware.Auto using thebridge○●●●Autoware.Sandbox●

Mostly launch ﬁles

For those who won’t orcannot move to ROS 2
Limited functionality
Maintained by its users

Box to hold proposed
extensions andmodiﬁcations toAutoware.Auto
○

●
●
●

For researchers andacademics

Less-strict quality policies
No need to worry about
safetyGraduation process foralgorithms to get them into
Autoware.Auto

End Goal
Autoware.Auto●●●

Autoware.Sandbox

A happy
community!
😄😄🚙😄😄

Full-functionality self-driving
stack in ROS 2
Near-production quality
Strict quality control policies
○
○
○

●

Autoware.AI

Design reviews
Code quality maintenance
Safety considerations

Well-documented andmentored contribution process

●

●
●
●

Thin wrapper around
Autoware.Auto using thebridgeFor those who won’t orcannot move to ROS 2
Limited functionality
Maintained by its users●

Box to hold proposed
extensions andmodiﬁcations toAutoware.Auto
○

●
●
●

For researchers andacademics

Less-strict quality policies
No need to worry about
safetyGraduation process foralgorithms to get them into
Autoware.AutoThanks!

Questions?

Links● https://www.autoware.org/● https://gitlab.com/autowarefoundation/autoware.auto/Aut
owareAuto● https://gitlab.com/autowarefoundation/autoware.ai● https://www.apex.ai/post/porting-algorithms-from-ros-1-t
o-ros-2