2020/10/14 15:00 UTC
Attendees
- Geoffrey Biggs (TSC chair)
- Angelo Corsaro (ADLINK)
- Tomoyuki Watanabe (Macnica)
- Stefano Longo (Embotech)
- Yang Zhang (Linaro)
- Stephane Strahm (Kalray)
- Hiroshi Igata (Tier IV)
- David Van Geyn (AutonomouStuff)
- Jeff Johnson (Mapless.AI)
- Matt Spencer (Arm)
- Joe Speed (ADLINK)
- Luca Cominardi (ADLINK)
- Ryohsuke Mitsudome (Tier IV)
- Gabriele Baldoni (ADLINK)
- Christian John (AWF SPC)
- Akihiko Tsukuda (eSOL)
- Daisuke Tanaka (AWF)
- Shinpei Kato (AWF Board)
- Jaime Martin Losa (eProsima)
- Josh Whitley (AWF)
- Adam Dabrowski (Robotec)
- Dmitri Lapanik (TRI-AD)
- Seonman Kim (LGE)
- Laksh Parthasarathy (TCS)
- Tsutomu Otake (Macnica)
- Ali Ors (NXP)
- Dejan Pangercic (Apex.AI)
Minutes: Geoffrey Biggs
Action items
- Produce a roadmap for what to do with our AVP implementation
- Board
- Request a legal review of the OpenScenario license form the board
- Geoff Biggs
- Run an extra TSC meeting about a racing ODD
- Geoff Biggs
Opening remarks and new member introductions (Board)
- Three more industry members just joined the AWF
- Futurewei
- FLIR
- PixMoving
- Congratulations to the AVP demo team
- The AWF has started its Strategic Planning Committee in parallel with the TSC
Confirmation of previous minutes
Minutes accepted
Action items review
- Request a legal review of the OpenScenario license form the board
- Geoff Biggs
- Action taken: Review requested, need the license
- On-board the new ODD working group co-leader
- Geoff Biggs
- Action taken: Has started working
- Run an extra TSC meeting and email vote about changing the next target ODD
- Geoff Biggs
- Action taken: Ran extra meeting
Eclipse Zenoh for Autoware.Auto V2X, V2V research & development
- Zenoh is a new communications middleware from the Eclipse Foundation focused on IoT and edge computing.
- It supports peer-to-peer and client-router-client (brokered) communication modes.
- The protocol is very lightweight enabling high performance.
- Interchange with DDS and use with ROS 2 are possible.
Change in motion/voting procedures for the TSC
To enable well-considered decisions, the TSC will use the following process for making motions and taking votes, for all major decisions. What constitutes a “major decision” is at the discretion of the TSC chair.
- A TSC member makes a major motion.
- The motion must be seconded by another member.
- The motion maker provides background information of some kind for other members to make their decision on.
- The motion is held for one or more TSC meetings, at the discretion of the TSC chair, to give TSC members time to properly consider the background information and the potential impacts of the decision.
- A discussion is held in a future TSC meeting, followed by either a retraction of the motion or an email-based vote.
Definition of an FTE contribution
To assist members who are required to provide engineering time to the AWF, the TSC has defined precisely what constitutes a contribution. From the next meeting, the following will be used to judge acceptable contributions.
- Commits and merge/pull requests on a repository under The Autoware Foundation · GitHub, Autoware.AI · GitHub, or Autoware Foundation · GitLab.
- Verifiable porting efforts for Autoware.Auto or Autoware.AI to new hardware, accompanied by documentation of how the porting was carried out, what Autoware users need to do to use Autoware on the target hardware, etc. Videos of Autoware running on the hardware are recommended. Porting to hardware that is not accessible to Autoware users (e.g. unreleased hardware) is not a valid contribution.
- Verifiable hours testing Autoware.Auto or Autoware.AI for a release, accompanied by a test report (minimum one per month) and issues filed in the appropriate repositories for all bugs and problems found.
Autonomous Valet Parking ODD report
Discussion
- Apex.AI: What should we do with the implementation of the AVP ODD?
- Josh: This is probably a question for the SPC.
- NXP: We want to port this onto our hardware platform to demonstrate it. Commercialising it with a partner, including expanding the operational domain and robustness, could be interesting.
- eSOL: We will use it as a demonstration for our industry customers.
- Robotec: Having a roadmap to commercialisation would be good. We also need to make sure the simulation resembles reality.
- AutonomouStuff: We will be able to use AVP as a demo platform.
- Action item for the board to sketch out the roadmap for what to do with AVP with respect to commercialisation and demonstrations.
Working group report: Autonomy Software
Discussion
- Apex.AI: We unfortunately were not able to produce an easily repeatable process for setting up the map, etc. to take the AVP implementation to a new car park rapidly.
Working group report: Operational Design Domain
Continuing discussions based on the short and long term plan which were agreed upon in ODD WG last month.
- [short] Adopt Tier IV’s proposal based on OpenSCENARIO 1.0 with enhancement and its tool chain, aim to create the initial scenario set by November.
- [long] After the scenario set is created, design the pipeline architecture to accept high level scenario formats like RSL and Scenic, and E2E simulation programs including LGSVL.
Tier IV made a presentation, a walkthrough and the example scenario explanation using the tools (the GUI scenario editor and the planning simulator) in weekly meetings.
Discussing which map data (location, e.g. AutonomouStuff parking lot, Kashiwa test track near Tokyo) best serves as the base to create the scenarios upon.
Recruiting additional volunteers to help create the machine readable scenarios based on the (short-term) plan.
FTE activity reports review
FTE activity reports 2020_10_16.pdf (74.6 KB)
Transition to GitHub for Autoware.Auto
- Some time ago the TSC took a decision to move Autoware Foundation projects from GitLab to GitHub.
- Autoware.Auto is very well established on GitLab, where we receive access to the enterprise features of GitLab for free. We have come to depend heavily on many of these features. These features are not available at GitHub in the same capacity. Some examples are given below.
- We are able to hierarchically organise projects, and especially multiple multi-repository projects, which makes it easy to standardise development processes, permissions, etc. across all our projects. This is not possible at GitHub.
- We use project management features which do not exist at GitHub.
- We depend on GitLab CI for automated testing of Autoware.Auto. GitHub’s equivalent feature is significantly limited by comparison.
- Autoware.Auto currently has 122 stars and 112 forks at GitLab. This indicates a large number of developers who are engaged with the project, as the majority of people who star the project also fork it in order to contribute.
- Because there is a significant quantity of work in flight, we would have to move all issues and merge requests from GitLab to GitHub. This must be done manually. The move would therefore require two months of work, during which time no work could be done on Autoware.Auto.
- The Eclipse Foundation is moving to GitLab.
- Propose that we reconsider the decision to move Autoware.Auto from GitLab to GitHub.
- Autoware.AI should stay on GitHub.
Architecture Proposal for Autoware.Auto for the next ODD
Back in March, Tier IV proposed new architecture for Autoware to aim for Level 4 autonomous driving stack. However, implementation in Autoware.Auto was postponed in order to avoid confusion in the AVP project. Now that the AVP demo is over, Tier IV would like to resume the discussion on the architecture of Autoware.Auto and discuss how we should proceed with the implementation of Tier IV’s proposed architecture.
Implementation of Cargo Delivery ODD.pdf (55.6 KB)
Discussion
- Josh: Is the agreement between Tier IV and Apex.AI for the cargo delivery ODD only? What about other work that needs to be done?
- Apex.AI: We want to prioritise the cargo delivery ODD first.
- Tier IV: Cargo delivery is the priority. We want to update and re-design the architecture of Autoware.Auto. If we were to do a racing ODD, then we believe that an entirely different architecture would be necessary.
- NXP: It seems that Tier IV and Apex.AI plan to move forward with this anyway, so are you really just asking for buy-in from the AWF?
- Apex.AI: We do not want to appear to be pushing something in as a two-company solution. We can do it on our own somewhere other than Autoware.Auto, if we need to. We are putting in significant resources and want other AWF members to match those resources.
Indy Autonomous Challenge follow-up
- ODD-related discussion
- IAC collaboration update
- F1TENTH
Dropped due to lack of time. Will discuss in an extra TSC meeting.