2020/07/15 15:00 UTC
Attendees
- Jan Becker (AWF Board)
- Geoffrey Biggs (TSC chair)
- Cheng Chen (AutoCore)
- Hiroshi Igata (Tier IV)
- Jeff Johnson (Mapless AI)
- Shinpei Kato (AWF Board)
- Kasper Ornstein Mecklenburg (Arm)
- Ryohsuke Mitsudome (Tier IV)
- Dejan Pangercic (Apex.AI)
- Tsutomu Otake (Macnica)
- Joe Speed (ADLINK)
- Stephane Strahm (Kalray)
- Daisuke Tanaka (AWF)
- Akihiko Tsukuda (eSOL)
- Josh Whitley (AWF)
- Yang Zhang (Linaro)
Minutes: Geoffrey Biggs
Action items
- Hold a vote by email on changing the default DDS for Autoware.Auto from Fast RTPS to Cyclone DDS
- Geoffrey Biggs
- Follow up on acknowledgements being given in Project Aslan
- Josh Whitley
Opening remarks and new member introductions (Board)
- The board has made a call for participation in a new Strategy Planning Committee.
- Contact the board if you are interested in participating in the SPC.
- This does not count as part of an FTE contribution, for those members who are required to contribute engineering time.
Confirmation of previous minutes
Minutes confirmed
Action items review
- Get in touch with Taylor from the DoT and coordinate porting their modifications and extensions to Autoware.AI into Autoware.Auto.
- Josh Whitley
- Action taken: Discussed with Taylor. The Autoware Foundation’s timeline does not match their project’s timeline, and they are still focused on ROS 1.They are not currently interested in porting the changes they’ve made to Autoware.AI to Autoware.Auto.
- Announce the Autoware.AI move to GitHub
- Geoffrey Biggs
- Action taken: Post made here
- Organise the first meeting of the Operational Design Domain Working Group
- Hiroshi Igata
- Action taken: Meeting was held on 2020/07/02. Minutes available here.
- Coordinate with AutoCore to get their open source projects moved to the Autoware Foundation
- Geoffrey Biggs, Josh Whitley
- Action taken: Contacted AutoCore. Josh is working with their engineers to get the repositories moved to the Autoware Foundation while maintaining permissions.
Project Aslan
A new project based in part on Autoware.AI 1.10 (from January 2019). See the announcement post. It is only focused on low speed (maximum 20mph), with the intention that it be a validated software stack for low-speed applications.
The project announcement was not clear about the heritage of the project and the board feels that insufficient credit was given to Autoware.
The board is particularly concerned because although StreetDrone is a premium member of the Autoware Foundation, no discussion was held regarding Project Aslan prior to its release, nor did StreetDrone speak of their concerns with Autoware or the Autoware Foundation which led to them deciding to create a fork rather than work with Autoware. In addition, StreetDrone does not appear to have been meeting its commitment to provide 1FTE to the Autoware Foundation even while they were working on a parallel project and organisation.
From StreetDrone’s perspective, Project Aslan grew out of significant modifications they had to make to Autoware.AI 1.10 in order to make it work for a demonstration they performed in 2019. StreetDrone and Project Aslan have always intended to continue working with the Autoware Foundation.
Requests from the Autoware Foundation to Project Aslan and StreetDrone:
- Verify that acknowledgement is sufficiently given to Autoware, including agreeing the wording and visibility with the Autoware Foundation (the board will work with StreetDrone on this)
- Work with the Autoware Foundation to clarify what constitutes a contribution from 1FTE.
FTE usernames
All member companies who have committed to providing some level of engineering time as part of their membership are required to assign a point-of-contact engineer. This engineer may be the actual engineer who will be doing the work, or they may be an engineer who coordinates other engineers to make that member’s promised contributions to the Autoware Foundation.
We require the email address, GitHub username, and GitLab username of all point-of-contact engineers. Several member companies have not yet sent this information. Please send it by the end of the week to the TSC chair (not to the TSC representatives mailing list).
Working group report: Autonomy Software
Temporary changes provided by Mitsudome-san allow NDT Localization to work out-of-the-box in the MS2 launch file. While additional changes are required to make NDT stable and flexible, this closes the NDT-related issues for Milestone 2. The final issue related to Milestone 2 is MPC and Takamasa Horibe has made significant progress. This final item for MS2 will be complete this week, at which point the repository will be tagged with AVP-MS2. Good progress continues to be made with MS3 as Lanelet2 is now incorporated into Autoware.AUTO and we can load a Lanelet2 map. The group is still discussing the APIs that will be used between components in the planning and navigation architecture but many components such as the Lanelet2 map loader, global planner, and parking planner have MRs which are currently in review.
Working group report: Autonomy Hardware
The proposed plan in Q1 has been progressing during first months but face a new hold due to lack of participation from members and community. The Hardware topic is NOT attracting people YET.
This is fine: the Software .AI being consolidated and .Auto being started are used so far in experiment.
The Hardware companies are on their side depending on maturity of this SW and on the actual definition of use cases for tuning needs (computing power, peripherals). With the exception of Autocore who actually proposed an Autoware Hardware setup, and NXP/Kalray being finalizing one for Autoware, members are for now experiencing with other available non-members hardware.
Instead of running after members and users with non efficient calls, and conducting one shot surveys, we are suggesting to enter in a more interactive and proactive mode.
The Hardware Working Group will
- Investigate proposed ODD to identify and proposed HW understood needs for achieving such ODD
- Build and execute a plan for reference platforms demo on Autoware.Ai and .Auto with Autoware members for next 6 months: Outcome proposed 1. How to setup reference hardware with simulator and running autoware 2. Guide for setting up in development environment and test vehicle and prototype vehicle 3. Demo by video guide when applicable
- Keep collecting HW setup in used by members (on-going) and defining an Id template (what is part of this hardware) ultimately used for mapping hardware to ODD and helping on setting up test suite
Discussion
- Many people seem unaware that the working group was still meeting.
- The proposal to start developing hardware for the next ODD may be too early, given that the ODD has not yet been designed so requirements on the hardware are unknown.
- An iterative approach is valid, so starting from what we currently have in Autoware.Auto and revising it as the next ODD becomes more concrete could still be useful.
- The hardware-based members need to start providing hardware to other AWF members so it can be used for Autoware software development.
Working group report: Operational Design Domain
- Started weekly meetings on JUL 2 and have had 3 weekly meetings so far.
- Investigated existing literature on ODD definition and identified the most comprehensive one is:
- Added quantitative information as much as possible to the ODD template which above report offers including from Tier IV’s cargo delivery project.
- Added AVP case (previous ODD) to the template for comparison.
- Working on items which needs better definition, etc.
- https://docs.google.com/spreadsheets/d/1ksGOQ9U5y19nQmZ5Vx73CHHhgTwFX2fq
- Plan to reach consensus on the ODD template/definition next week and start discussion on the scenarios and their machine readable format.
Choosing another ODD WG co-lead
The ODD WG currently only has one leader, whereas two are required. A volunteer is necessary for the second leader.
Discussion
- Stephane Strahm (Kalray) is volunteering to be a leader of the ODD WG, but we must first find a replacement leader for the Autonomy Hardware WG.
FTE activity reports review
https://docs.google.com/document/d/1EU0UQNeH_dcUpI3VQXQosPNbacSkTBVj4ev_6grUEZU
AVP Hackathon planning
AutonomouStuff has proposed that they handle the autonomous car in their carpark for a hackathon, while the hackathon itself is held virtually.
The Autonomous Software WG believes that the earliest a hackathon and demonstration can be held is the week of August the 24th. However a date some time between September 7 and October 2 is more likely to be achievable.
Target September 28th to October 2nd.
Long-term ODD roadmap
Postponed to next meeting due to lack of time
Default DDS for Autoware.Auto
For two reasons, the ASWG is recommending that we change the default DDS for Autoware.Auto from Fast RTPS to Eclipse Cyclone DDS.
- The ASWG has been working to get Autoware.Auto going on Eclipse Cyclone DDS.
- The LGSVL simulator does not work except with Eclipse Cyclone DDS at this time, due to an issue with Fast RTPS and Unity (the engine underlying LGSVL).
In addition to the above, the ASWG has seen significantly more technical support from ADLINK and the Eclipse Cyclone DDS developers than from other DDS vendors.
Some members wish to examine the documentation comparing Fast RTPS and Eclipse Cyclone DDS before making a decision, so an email vote will be held before the next TSC meeting.
Autoware.auto with Eclipse Cyclone DDS.pdf (300.6 KB)
Collaboration with navigation2
The ROS 2 navigation stack has obvious commonalities in functional goals with Autoware.Auto. We should investigate how we can work together.
Could one of the TSC members get together with Steve Macenski and prepare the analysis?
(Geoff Biggs and Steve Macenski have discussed a shared desire to make Autoware.Auto reuse as much of the navigation2 code as possible since last year.)
Community manager for Autoware.Auto project
The navigation2 project suffered a major loss when Intel pulled out of supporting ROS development earlier this year, removing six full-time engineers from the project, including the project leader. Steve Macenski stepped in as leader and was able to kick-start a vibrant community through his community management efforts. Amongst other things, he:
- Set up a Slack for the project
- Actively solicited people to join the Slack
- Spoke to every person who joined about their background, interests, and what they might be able to contribute
- Coordinated getting all these new people working together on common topics
Would one of the TSC members be willing to step up and copy what Steve Macenski has done in navigation2 for Autoware.Auto? We have 1700+ registered users in the Autoware slack and 2000+ registered for the Autoware online course. This is a huge pool of potential contributors that is currently untapped.