Technical Steering Committee (TSC) Meeting #18 (2020/05/120) Minutes

Autoware
1

2020/05/20 22:00 UTC

Attendees

  • Geoffrey Biggs (TSC chair)
  • Katie Blizzard (US DoT CARMA)
  • Cheng Chen (AutoCore)
  • Ian Colwell (AutonomouStuff)
  • Kenji Funaoka (Tier IV)
  • Servando German (Linaro)
  • Craig Johnson (AutonomouStuff)
  • Jeff Johnson (Mapless)
  • Shinpei Kato (AWF Board of Directors)
  • Taylor Lochrane (US DoT CARMA)
  • Tsutomu Otake (Macnica)
  • Dejan Pangercic (Apex.AI)
  • Filipe Rinaldi (Arm)
  • Philipp Robbel (Mapless)
  • Brian Shin (LG Electronics)
  • Stephane Strahm (Kalray)
  • Daisuke Tanaka (AWF)
  • Akihiko Tsukuda (eSOL)
  • Manabu Tsukuda (University of Tokyo)
  • Endika Gil Uriarte (Alias Robotics)
  • Víctor Mayoral Vilches (Alias Robotics)
  • Josh Whitley (AWF)
  • Yang Zhang (Linaro)

Minutes: Geoffrey Biggs

Action items

  • Follow up with the DoT about their ODDs, and investigate their Port Drayage ODD as a potential next ODD for Autoware
    • Dejan Pangercic
  • Get in touch with Taylor from the DoT and coordinate porting their modifications and extensions to Autoware.AI into Autoware.Auto.
    • Josh Whitley

Opening remarks and new member introductions (Board)

  • Covid-19 situation is continuing
  • Autoware course has been very well-received, with over 2000 people subscribing
    • Thanks in particular to Apex.AI and Dejan for driving this

Confirmation of previous minutes

Minutes confirmed

Action items review

  • Announce the EOL timeline for Autoware.AI in ROS Discourse and on the Autoware blog
  • Set up the ODD working group and hold first meeting
    • @gbiggs AutonomouStuff StreetDrone
    • Action taken: Both ODD working group leaders determined that they cannot run the working group
  • Change TSC operation to Google Group and Google Drive

Working group report: Autonomy Software

Autoware.Auto: Milestone 2 is coming to a close. Several issues have been encountered with the LGSVL simulator which are hindering completion of this milestone. In addition, we have lost access to several key developers which has slowed the progress of completion of NDT Matching and the MPC controller. The hope is to complete MS2 by next week but tuning the MPC for continuous, smooth operation is still an unknown. With regard to Milestone 3, work has begun in earnest on the HD Map, Planning, and Navigation integration portions. I’d like to thank Parkopedia, Embotech, and Tier IV for their contributions so far in this effort.

Autoware.AI: Version 1.14.0 of Autoware.ai should be released on Tuesday, May 26, 2020, midnight UTC. AutoCore has been very gracious in helping us to test the new features and fixes in this release and they have only a few more, minor tests to complete.

Working group report: Autonomy Hardware

Autonomy Hardware Working Group reorganisation

  • The AHWG working group has seen almost no participation other than the two working group leaders.
  • One problem may be that the topic of the working group is too broad.
  • The survey that Stephane put out only had a few answers.
  • Is producing a reference hardware design even appropriate? AutonomouStuff’s experience was that 80% of the time, their hardware had to be customised to meet customer needs, and changing the configuration of Autoware.AI changes computing requirements.
  • Linaro believes the need for reference hardware is not to provide something that will definitely work for most use cases, but to provide hardware manufacturers a place to start to produce Autoware-compatible hardware.
  • A practical thing to do is to create a list of hardware that supports Autoware.AI and Autoware.Auto.
  • We also need a standardised way that Autoware interfaces to vehicles.
  • Apex.AI believes that a bottom-up approach (producing a specific set of hardware) is more feasible than a top-down approach (such as a catalogue of available hardware).
  • The Autonomy Software WG needs someone to handle producing a set of hardware that can support the software produced for each ODD.
  • Actions that can be taken:
    • Re-send the survey in a more defined format
    • Determine what is needed to support Autoware, starting from the Lidar pipeline
    • Identify what people actually use to control a car, and attempt to specify requirements for that

Operational Design Domain Working Group

Both proposed leaders of the ODD working group (AutonomouStuff and StreetDrone) determined that they do not have the resources to run an ODD working group.

AWF Board of Directors will discuss this topic, but the call for volunteers to lead the WG remains open.

Moving Autoware back to GitHub

  • Although Autoware.Auto will not be moved back to GitHub until the AVP work is completed, Autoware.AI can be moved earlier.
  • Autoware.AI will be moved between release cycles, i.e. after 1.14 is released.
  • Servando (Linaro) has been investigating GitHub Actions so that we can have a new CI up and running as soon as possible, minimising the impact on any Autoware.AI development work.
    • See “GitHub Actions investigation” document

Github Actions investigation.pdf (26.6 KB)

AutoCore simulator presentation

AutoCore sim.pdf (789.7 KB)

Operational Design Domain proposal from US DoT

https://transportationops.org/event/carma-webinar-series-carma-ecosystem

DoT is thinking about the big picture: How does the vehicle interact with everything around it? They are developing a taxonomy for the whole transportation system.

The DoT is developing use cases for such topics as interaction with traffic lights, optimising intersection timings, management of vehicle spacing during adverse weather conditions, ensuring that an autonomous vehicle can be ordered to pull over by law enforcement.

  • Question: There is no standardised interface for Vehicle-to-Vehicle communication. This seems to be somewhere that the AWF could contribute. Is there any existing effort on this?
    • Answer: The US DoT is encouraging the development of such a standard. We need to define what that interface and protocol is so people can begin designing for it. We don’t want to define it ourselves, though, we want to help people define it.
  • Question: What is the difference between freight management and the Port Drayage programme?
    • Answer: Freight management does not deal with moving freight within ports autonomously to spare the truck driver time. This is a separate use case from moving freight along roads and highways, so it is dealt with separately in the Port Drayage programme.
  • Question: How much of this will be pushed to the Autoware Foundation?
    • Answer: We have to use different planning due to the way we deal with trajectories, and we also require higher speeds than Autoware is currently capable of. We have also developed additional capabilities, such as alternative localisation solutions. But we do want to collaborate with the Autoware Foundation. In particular we are moving to ROS 2 and this is a chance to get closer.