A deep dive into communication and collaboration within the Autoware Community
Our series TIER IV PEOPLE shines a light on the people and teams whose unique experiences, backgrounds, and stories bring our mission to life.
A deep dive into communication and collaboration within the Autoware Community
Autoware, the world’s pioneering open-source software for autonomous driving (AD), is championed by TIER IV. With a steadfast commitment to cultivating a sustainable ecosystem and enabling widespread access to AD solutions, TIER IV collaborates closely with the Autoware Foundation (AWF), fueling advancements in AD technology and fostering collaboration within the Autoware community.
In our latest interview, we delve into a conversation between Ryohsuke Mitsudome, Technical Steering Committee Chair of AWF, from TIER IV, and M. Fatih Cirit, AWF Architect from Leo Drive. Together, they provide insights into the dynamic partnership, highlighting their shared pursuit of excellence in AD technology.
Ryohsuke Mitsudome | R&D Unit, Architect at TIER IV, Technical Steering Committee Chair of AWF
A brief Introduction
R: I’m Ryousuke Mitsudome, a software architect at TIER IV and Chair of the Autoware Foundation’s Technical Steering Committee. I oversee the technical aspects of the Autoware Foundation, collaborating closely with Fatih.
M. Fatih Cırıt | Tech Lead at Leo Drive, Software Architect of AWF
F: I’m Fatih, software architect in the Autoware Foundation.
R: Let’s discuss our thoughts on Leo Drive. Since you’re here at TIER IV, I’m keen to know about your experience working in collaboration with us and the Autoware Foundation, in your engineering role both at Leo Drive and the Autoware Foundation. Before that, how has your experience been working in Japan at TIER IV?
F: I came to the TIER IV office not only to delve into the development process and office environment but also to immerse myself in Japanese culture.
R: I recall you went to Asakusa, Tokyo Sky Tree and even went to a Hanami festival. It’s wonderful that you got to experience all of that!
Leo Drive, The Autoware Foundation and TIER IV
R: Firstly, let’s discuss how TIER IV sees our partnership with Leo Drive. While not the first to join the Autoware Foundation, Leo Drive has become a significant contributor. They’ve evolved into a key member, actively participating and even leading various working groups. One notable achievement is the Bus ODD (Operational Design Domain) project.
Leo Drive, ITRI and Isuzu teamed up to integrate Autoware.Universe into the bus and showcased its capability. The demo that took place in February showed the seamless integration of Autoware.Universe into the bus, with smooth driving elements - from the acceleration, the braking, even when the bus door was opening, to when it arrives at the bus stop. We look forward to sharing the demo video and highlights soon.
F: Like many other software development and integration projects, integrating into the Autoware stack had challenges due to limited documentation and stability issues. But I believe we eventually overcame most of them. The CI/CD (Continuous Integration and Deployment) pipeline also posed challenges with potential breaking changes.
R: Now that the Bus ODD project is complete, it will be included in the first release of Autoware, making integration smoother for others. About CI/CD, we definitely need improvement. There was a lot of development for our first CI/CD pipeline and we keep saying that we should have more engineers to work on it and improve it.
During my visit to Leo Drive you also mentioned the difficulties debugging and monitoring the nodes. Could you expand on these difficulties?
F: Right now, when a node crashes in Autoware it's hard to figure out the exact cause of the failure. It's also hard to find out which actual node crashed at the time. We need better health monitoring systems in Autoware to make sure that when something crashes we know exactly the source of the failure and the reason for the crash.
R: Agreed, improved diagnostic tools are essential. Leo Drive’s engineers display a deep understanding of Autoware. Not only about ROS but Autoware and how it works. Are there specific training programs at Leo Drive?
F: Our approach involves following ROS 2 tutorials and the documentation, attending online courses, and peer training. This ensures that senior developers mentor junior developers to understand better how the process works and how they can get more information about development in general.
TIER IV, through the lens of Leo Drive
R: What’s your overall view of TIER IV?
F: TIER IV is impressive; they strongly emphasize open-source development in their vision. The tools and the development efforts created by TIER IV are really useful to work with. The workspace, particularly the garage with autonomous vehicles, sensors, and computing equipment, is remarkable. There’s also external equipment monitoring the vehicle’s setup for remote testing. The way TIER IV develops autonomous vehicles is noteworthy. Separating core development from testing and integration allows for a smoother process. I appreciate this approach.
R: Initially, TIER IV’s setup was similar to Leo Drive’s. Core developers managed both development and vehicle integration. Although TIER IV still follows this to understand their code’s impact or how to improve the algorithm, the integration team now has a dedicated team.
Shaping TIER IV’s relationship with the Autoware Foundation
R: I’m curious about your perspective on the relationship between TIER IV and the Autoware Foundation. In my view, we could enhance engagement by encouraging more engineers to join the Autoware Foundation working groups. Instead of relying solely on text-based GitHub discussions, live discussion could be more impactful. With the new working groups established, how do you foresee this evolving? As a Leo Drive and Autoware Foundation engineer, do you believe this will benefit the community?
F: We’ve had the software working groups and meetings consistently. Adding three more working groups in specific areas is beneficial. The software working group was too broad, limiting focused discussions due to its extensive scope. With the perceptional sensing, planning and control, and localisation and mapping working groups now meeting bi-weekly, we expect increased participation. The setup allows engineers to drive into their findings and foster Autoware’s improvement through collaborative efforts.
R: The concept of sub-working groups for the software working groups, originally proposed by Leo Drive, was excellent. Specialized discussions within each working group are now possible. Our team lead for the planning working group intends to include more engineers. I believe enhanced communication among the AWF members is vital for mutual growth.
Forming the Future of Autoware Community
R: We’ve focused on TIER IV and Leo Drive so far, but I’m interested in your thoughts on how we can change and enhance the Autoware community. Given our significant roles within the Autoware Foundation, we certainly have a vision for its future and roles in advancing autonomous driving technology. However, as a collaborator, what are your thoughts?
F: Our broad vision for Autoware is to establish it as the standard open-source autonomous driving software, accessible for everyone worldwide. I believe this aligns with the goals of other Autoware Foundation members. While we’re on the right path, more steps are needed to realize this goal.
R: Like you said, I would like to expand the Autoware committee further and seek direction from the board to make it more user-friendly. This way, we can attract more community members.
However, I still see a gap between the number of Autoware users and contributors. While creating new issues and discussion topics is valuable, we need more contributors at the code level. How can we encourage users to contribute more actively?
F: You’re right; the complexity of the Autoware project is a significant challenge. With around 250 packages and numerous nodes in runtime, it’s intricate to drive the vehicle autonomously through multiple and varied scenarios. To address this, our initial step should be improving the documentation and creating comprehensive guidelines and tutorials for each package. Clear explanations, detailed diagrams, and simplified instructions would help lower the entry barriers for potential contributors.
R: Absolutely. While we have basic command-line tutorials for running Autoware, we lack comprehensive documentation explaining its inner workings, architecture, and node functionalities. It’s a bit of a chicken-and-egg problem; we need more engineers to create documentation, but without documentation, it’s challenging to onboard new contributors. We need to take the first step to break this cycle. Did you have any other ideas for specific improvements in the Autoware community?
F: Currently, debugging the Autoware project is quite challenging. To improve this, I’m developing the Autoware core, which includes an essential package called the Autoware Node. This package will serve as the base for all other nodes to communicate with a central monitoring system, which we can call it the Autoware Control Center, or something similar. This system would greatly enhance transparency in debugging. Additionally, I plan to create templates for new nodes, simplifying package creation and verification.
R: So, it’s similar to the ROS create package command but modified for Autoware specifications. We might also need to integrate this with the base class for Autoware nodes to facilitate the development of new packages.
F: Additionally, we should prioritize testing and validation to prevent regressions and failures.
R: Agreed; tools like the scenario simulator and robust testing will be crucial to ensure code stability and prevent disruption.
