Technical Steering Committee (TSC) Meeting #22 (2020/09/16) Minutes

Autoware
1

2020/09/16 22:00 UTC

Attendees

  • Jan Becker (AWF board)
  • Geoffrey Biggs (TSC chair)
  • Cheng Chen (Autocore)
  • Adam Dabrowski (Robotec.AI)
  • Larry Dimitrievski (Tata Consultancy Services)
  • David Van Geyn (AutonomouStuff)
  • Hiroshi Igata (Tier IV)
  • Jeff Johnson (Mapless AI)
  • Shinpei Kato (AWF board)
  • Seonman Kim (LGE)
  • Jaime Martin Losa (eProsima)
  • Kasper Mecklenburg (Arm)
  • Ryohsuke Mitsudome (Tier IV)
  • Tsutomu Otake (Macnica)
  • Dejan Pangercic (Apex.AI)
  • Joe Speed (ADLINK)
  • Daisuke Tanaka (AWF)
  • Akihiko Tsukuda (eSOL)
  • Josh Whitley (AWF)
  • Yang Zhang (Linaro)

Minutes: Geoffrey Biggs

Action items

  • Request a legal review of the OpenScenario license form the board
    • Geoff Biggs
  • On-board the new ODD working group co-leader
    • Geoff Biggs
  • Run an extra TSC meeting and email vote about changing the next target ODD
    • Geoff Biggs

Opening remarks and new member introductions (Board)

  • An Autoware workshop will be held at IV2020 on Friday, October 23rd (Nevada time)
  • An Autoware workshop will be held in conjunction with ROS World

Confirmation of previous minutes

Minutes accepted

Action items review

  • Add documentation on how to change the DDS implementation used
    • Josh Whitley
    • Action taken: Documentation page has been added to the Autoware.Auto documentation
  • Follow up on acknowledgements being given in Project Aslan
    • AWF board/Josh Whitley
    • Action taken: Acknowledgements provided by the board are now on the project Aslan website, and will be added to the GitHub repository
  • Change the default DDS implementation used by Autoware.Auto to Eclipse Cyclone DDS
    • Josh Whitley
    • Action taken: Done; this only applies when using the ADE. The default when not using the ADE will be the same as ROS 2

Working group report: Autonomy Software

  • Approximately 80% of the functionality for the AVP demo has been merged by the TSC meeting.
  • Feature freeze is scheduled for September 18th. After this, integration and on-vehicle testing will commence.
  • September 28th is the first day of the AVP hack-a-thon.
  • The primary goal for the hack-a-thon is to develop a GUI for controlling sending the vehicle to one or more parking spots and recalling the vehicle to a pick-up/drop-off zone.
  • We intend to make the hack-a-thon as interactive as possible by providing video chats and live streams of in-vehicle testing.
  • Discussion for the hack-a-thon will mostly happen in the #avp-hackathon channel of the Autoware Slack and also on ROS Discourse at Autonomous Valet Parking Demonstration and Virtual Hack-a-thon (new date).
  • October 2nd, following the hack-a-thon, will be the Demo Day. This will intentionally be kept to a small number of people at the demo location.
  • Between Apex.AI, AutonomouStuff, and AWF, we will produce a marketing video from footage taken during the demo.

Discussion

Q (AutonomouStuff): Will the SSC code from ROS 1 be ported for Autoware.Auto?

A: It can’t be used because the information sent by Autoware.Auto is different, so it will be mostly reimplementation.

Working group report: Autonomy Hardware

  • Get ODD2 definition as input
    • up to 20kph
    • min vehicle WidthHeight=1.33
    • max vehicle WidthHeight=2.25.5
    • use cases
  • Start to proposal sensor configuration for ODD2
    • proposal configuration for discussion
    • at list define two configurations for min/max size of cargo vehicles.
  • Next step
    • publish the proposal in the community for discussion
    • discuss with ODD/SW WG
    • discuss and determine tier-2 computer platform for ODD2
    • discuss with simulator contributor to realize sensor configuration in simulator

Discussion

  • This does not seem to be the output we need. By now we should be seeing hardware requirements and reference hardware platforms for the AVP ODD. This is minor details for the next ODD.
  • Should we suspend the hardware working group until we have a concrete set of scenarios and requirements from the ODD working group?
  • Lack of organisation of the working group is a root cause of not having the necessary output.
  • Is it sensible to try and come up with a reference hardware platform from scratch entirely on our own? This is good if it were to happen, but it hasn’t happened. An alternative would be to look at the market and bring in what is on the market.
    • Baidu/Apollo has a single supported platform, although they built it themselves rather than it being third party.
    • There are third-party hardware platforms that those third parties support for Apollo themselves, such as AutonomouStuff.
  • Should we choose an existing third-party platform and choose that as our reference platform?
  • We should find someone who has the knowledge of hardware and what we need from a reference platform, and is able to close the feedback loop with the ODD working group in terms of what information is needed to choose correct hardware, and hire them to lead our hardware efforts.
    • ADLINK is looking for such a person to hire and be their 1FTE.

Decisions

  • The Autonomy Hardware Working Group will be suspended until either:
    • the ODD Working Group has produced enough of an ODD description, scenarios, and requirements for the AHWG to work toward, or
    • we find a hardware engineer who can dedicate themselves full time to leading the working group and can begin working with the ODD WG outputs at that time.

Working group report: Operational Design Domain

Have been discussing the machine readable scenario format.

  • Proposals were made from Ridecell (RSL), LG (Python API & Scenic) and TierIV (OpenSCENARIO 1.0 with extension and the tool chain).
  • Findings include the following:
    • OpenSCENARIO 1.0 seems to be the most established standard and available now, but this standard has quite a few limitations.
    • In order for Software working group to start development based on Cargo Delivery ODD in a timely fashion, ODD working group should aim to provide comprehensive set of machine readable scenarios by mid November.
    • There’s a strong need to accept other scenario formats like RSL or Scenic to better handle more abstract scenarios and automated scenario generation, and for accepting various E2E simulation programs including LGSVL.
  • Agreed on the short and long term plan. Please see the [Scenario Testing Pipeline Diagram] (https://discourse.ros.org/uploads/short-url/uPZEBhvdcw2crrBrvXoGxu0nWbf.pdf).
    • [short] Adopt Tier IV’s proposal based on OpenSCENARIO 1.0 with enhancement and its tool chain including the Map based GUI scenario editor, runner, XML-RPC based interface and the planning simulator (These tools are being migrated to ROS2 and planned to be publicly available.)
    • [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.
  • The license for the extended use of OpenSCENARIO 1.0 is pending for legal review.

Discussion

  • Q: Do we have any implementation of any of the current proposed scenarios?
    • A: Tier IV has tools that they are working on for their own goals, and will make them available. To support following the ODD-driven process after the AVP ODD is complete, the WG has decided to use Tier IV’s tools rather than building or finding new ones.

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.

LGE (Steve Lemke) has volunteered.

Decisions

Steve Lemke of LGE will co-lead the ODD working group with Hiroshi Igata (Tier IV).

FTE activity reports review

FTE activity reports 2020_09_16.pdf (57.2 KB)

Indy Autonomous Challenge

Indy Autonomous Challenge for ROS 2 TSC.pdf (126.0 KB)

  • A competition set up similar to a DARPA Grand Challenge. It is not a series, it is a one-off competition with an end date and a $1.5 million cash price.
  • There are 39 universities (as of today, it’s still increasing) with teams participating.
    • Many of them already have existing autonomous racing teams that have participated in other races.
  • There is a significant amount of press around the competition. It is very high profile.
  • The competition has a series of hackathons, qualifiers (in simulation), etc. over the next year leading up to the race itself on October 23rd, 2021.
  • All teams use the exact same car (a Dallara IL-15 IndyLight), tuned identically, and identical sensor suite and computing. The only thing the teams can touch is the Team Competition Computer (which is custom-designed by ADLINK and Clemson University), and is where they load their software.
  • The Team Competition Computer will be running Ubuntu 20.04 (so that it supports ROS 2 Foxy).
  • Josh has been working in his own time on porting Autoware.Auto to ROS 2 Foxy (currently it officially only supports Dashing).
  • The IAC has an existing official simulation provider (Ansys). We’d like to help them integrate it with Autoware.Auto.
  • Some teams are already working with Autoware.

Discussion

  • Is it worth changing our next ODD to focus on the IAC?
    • This would be a heavy focus on control, at the expense of perception and planning. It would increase performance of control at high speeds but the overall capability for autonomous driving would not advance as much.
    • Perception is still needed, and it needs to be high-speed and highly accurate.
    • A lot of other work would also spill over, because racing at high speed amongst a group of cars is difficult.z

Decisions

  • ADLINK makes a motion that the next target ODD (after Autonomous Valet Parking) be changed from cargo delivery to autonomous racing, specifically the IAC competition.
  • Apex seconds the motion.
  • An extra TSC meeting will be held in the week of the 21st of September to discuss the motion further, followed by an email vote on whether or not to change the target ODD.
1 Like