2020/06/17 15:00 UTC
Attendees
- Geoffrey Biggs (TSC chair)
- Cheng Chen (AutoCore)
- Ian Colwell (AutonomouStuff)
- Adam Dabrowski (Robotec.AI)
- Craig Johnson (AutonomouStuff)
- Jeff Johnson (Mapless AI)
- Hiroshi Igata (Tier IV)
- Dejan Pangercic (Apex.AI)
- Brian Holt (Parkopedia)
- Shinpei Kato (AWF Board)
- Seonman Kim (LG Electronics)
- Xiangyu Li (Hesai)
- Stefano Longo (Embotech)
- Ryohsuke Mitsudome (Tier IV)
- Ali Ors (NXP)
- Tsutomu Otake (Macnica)
- Philipp Robbel (Mapless AI)
- Paul Sastrasinh (TRI-AD)
- Joe Speed (ADLINK)
- Matt Spencer (Arm)
- Stephane Strahm (Kalray)
- Daisuke Tanaka (AWF)
- Akihiko Tsukuda (eSOL)
- David Van Geyn (AutonomouStuff)
- Holly Watson Nall (StreetDrone)
- Josh Whitley (AWF)
- Yang Zhang (Linaro)
Minutes: Geoffrey Biggs
Action items
- Get in touch with Taylor from the DoT and coordinate porting their modifications and extensions to Autoware.AI into Autoware.Auto.
- Josh Whitley
- Announce the Autoware.AI move to GitHub
- Geoffrey Biggs
- Organise the first meeting of the Operational Design Domain Working Group
- Hiroshi Igata
- Coordinate with AutoCore to get their open source projects moved to the Autoware Foundation
- Geoffrey Biggs, Josh Whitley
Opening remarks and new member introductions (Board)
- RTI has joined as an industry member.
- The Board of Directors is restructuring the Autoware Foundation to reduce bottlenecks and make it more productive in the long term.
Confirmation of previous minutes
Minutes approved.
Action items review
- Follow up with the DoT about their ODDs, and investigate their Port Drayage ODD as a potential next ODD for Autoware
- Dejan Pangercic
- Action taken: Meeting between Dejan and Taylor (USDoT) took place. Taylor presented USDoT plans for the Port Drayage use case and Dejan now also has them in a written form. Release of these plans is pending Taylor’s approval.
- 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: None yet
Revision of TSC operation
In order to improve the productivity and decision-making capability of the Technical Steering Committee, the organisation and processes of the TSC are being improved. The first stage is revising who the TSC representatives are and attendance in the TSC meetings.
Currently we have a primary and secondary representative from each organisation. Following this TSC meeting we will be shifting to a single representative from each organisation. This person will be the point of contact for TSC activities and will be expected to attend all TSC meetings. This is being done to improve the clarity of who is responsible for each member company’s opinions and positions during TSC meetings and during votes held outside of meetings.
The new method of managing participation approved by the Board of Directors is:
- The single representative of each premium member company may participate in TSC meetings
- A premium member representative may bring one or more observers to a TSC meeting, but prior approval from the TSC chairperson is required (so ask for permission a minimum of one day in advance)
- Observer participation will be on a meeting-by-meeting basis - approval for an observer to participate is only valid for a single meeting
- Observers do not need to be from the same organisation as the premium member who invited them
- The TSC chairperson will be responsible for sending the meeting information to approved observers
- Non-premium member companies may not participate in the TSC meeting.
- All meeting participants must set their name in the participants list for “Firstname Lastname [Organisation]”
- Any participant in the meeting who cannot be identified as the representative of a premium member company or a previously-approved observer will be removed from the meeting
We are considering ways to improve the participation of non-premium members of the Autoware Foundation. Although the minutes of TSC meetings are made public, we do wish to find a way to hear the opinions of non-premium members and are considering several different approaches to this problem.
Move of Autoware.AI to GitHub
With Autoware.AI 1.14 recently released, we have taken the chance between release cycles to move the Autoware.AI repositories to GitHub. You can now find Autoware.AI here:
The root repository is here:
The installation method has not changed, but the location of the documentation has changed to here:
The GitLab repositories are no longer used.
Working group report: Autonomy Software
Milestone 2 is still not quite closed due to NDT and MPC. The odom frame is fixed with a temporary work-around until LGSVL can complete changes for a “proper” fix so at least NDT work can continue for now. MPC work is ongoing.
Tier IV has stepped in to help with the MPC work and will be contacting Christopher Ho at Apex about his MPC implementation in the next day or two.
Milestone 3 work is moving along - initial merge requests for the Parking Planner from Embotech, the Global Planner from Parkopedia, and the Lanelet2 Map Loader from Tier IV have been submitted and are being reviewed.
Working group report: Autonomy Hardware
There has been little progress.
FTE activity reports review
https://docs.google.com/document/d/1EjoObrGPilzoZYQhxwRq1kli-MFmmiKmWekTTIgrtLg
Selection of an Operational Design Domain
The goals of this discussion are to:
- Choose an ODD to target
- Decide on specific use case(s) to develop as an application that will help drive that ODD development and provide demonstrations of working functionality upon completion. (Refer to the ODD process document.)
The ODD must be chosen from one of these four:
- Autonomous cargo delivery on closed, private roads
- Highway adaptive cruise control and driver assistance
- Autonomous Bus Rapid Transit (dedicated, fenced-off lanes)
- Active campus navigation
The choice must also meet the other criteria given in the ODD process document.
Discussion and presentations
tieriv_odd_proposal.pdf (3.1 MB)
Many TSC representatives have expressed their preference for ODD 1, Autonomous cargo delivery on closed, private roads.
Tier IV presented why they support the cargo delivery ODD. Reasons include commonalities with AVP, the limited environment, and an limited but useful expansion of the Autoware.Auto feature set, such as higher-level planning. Tier IV already has a working application in this ODD - cargo delivery between buildings in a factory campus - which they propose as the specific use case to target.
ADLINK supports the cargo delivery domain due to current market trends.
AutonomouStuff might be able to work with Caterpillar to do a test in one of their factory campuses, or with one of their other customers for port drayage.
Parkopedia stated that the ODD needs to include a definition of minimum risk conditions, because this has follow-on impacts on other parts of the ODD definition such as the maximum possible speed.
Apex.AI (on behalf of the US DoT) presented the port drayage application of the cargo delivery ODD, using autonomous articulated trucks:
- Drop off: Distribution Center to Staging Area - Staging Area to Port Gate - Port Gate to Yard - Yard to Staging Area
- Pickup: Staging Area to Yard - Yard to Inspection Facility - Inspection Facility to Staging Area, or Yard to Staging Area if Inspections Not Conducted - Staging Area to Distribution Center
The DoT has a test area available and will be testing this application by the end of 2021. This application would add features beyond AVP such as traffic light-controlled intersections, and planning for and control of trucks (which is very different from planning for and controlling small cars). This use case would also allow us to make a direct comparison between Autoware.AI and Autoware.Auto in capabilities, as the DoT has already implemented many of the capabilities in Autoware.AI.
In summary, the proposed use cases for ODD 1 are:
- Building-to-building transport of cargo that will include indoor travel.
- Transporting shipping containers in a port facility between different parts of the port.
Decisions
- (By vote, 13 in favour, 6 abstained) Use ODD 1, “Autonomous cargo delivery on closed, private roads”, as our next ODD
- (By consensus) Select use case 1 for the demonstration.
Operational Design Domain Working Group organisation
The ODD Working Group needs at least one leader. Their tasks include:
- Actively recruiting people to participate in the working group’s activities, including from outside the Autoware Foundation.
- Running regular teleconferences at a high enough frequency to ensure the work moves swiftly. Given the important nature of this work, I recommend holding a teleconference once a week at a minimum. The teleconference time must be scheduled to be fair to the timezones of all who want to participate.
- Updating the working group’s page with goals, progress, notes from meetings, etc.
- Providing a report to the TSC meeting every month. (The Working Group leader will attend the TSC meeting for the working group report, if they are not already a TSC representative.)
- Doing the work that the working group needs to do to achieve its goals, in order to subtly push other working group members to contribute. This means the working group leads need to be actively involved in and contributing to the defining of ODDs and creation of scenarios.
The working group will eventually be tasked with just defining an ODD and creating its scenarios, but initially there is additional work that needs to be done to get the working group going:
- Understanding and documenting the process for defining an ODD and its scenarios
- Understanding and documenting what information we need to specify for an ODD
- Understanding and documenting what information we need to specify for a scenario
This startup work is particularly important and will take particular commitment. It needs to be done to enough of a degree to begin defining our next ODD as soon as possible.
Discussion
Tier IV can provide one person to act as one leader of the ODD Working Group.
Linaro may be able to provide someone to act as the second leader but they need to confirm resource availability.
Decisions
- Hiroshi Igata from Tier IV will act as one leader of the ODD Working Group.
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.
AVP Hackathon planning
Dropped due to time constraints.
Long-term ODD roadmap
Dropped due to time constraints.