Technical Steering Committee (TSC) Meeting #13 Minutes

Autoware
1

Wednesday, December 18, 2019 3:00 PM (TZ)

Attendees

  • Geoffrey Biggs (AWF/TSC)
  • Shinpei Kato (AWF board)
  • Paul Sastrasinh (TRI-AD)
  • Holly Watson Nall (StreetDrone)
  • Servando (Linaro)
  • Tsutomu Otake (Macnica)
  • Matt Spencer (Arm)
  • Yang Zhang (Linaro/96Boards)
  • Cheng Chen (Autocore)
  • Lee Baldwin (AutonomouStuff)
  • Kenji Funaoka (Tier IV)
  • Akihiko Tsukuda (eSOL)
  • Josh Whitley (AutonomouStuff)
  • Stephane Strahm (Kalray)
  • Esteve Fernandez (Apex.AI)
  • Daisuke Tanaka (AWF/Admin)
  • Brian Shin (LGE)
  • Arun (TCS)
  • Zhi Yan (UTBM)
  • Dejan Pangercic (Apex.AI)

Minutes Geoffrey Biggs

Agenda

  1. Opening remarks and new member introductions (Board)
  2. Confirmation of previous minutes (All)
  3. Follow-up Corrections and clarifications from previous meeting (All)
  4. Follow-up Action items from previous meeting (All)
  5. Follow-up Autoware Meetup @ CES2020
  6. Follow-up Autoware Workshop at IV2020
  7. Working group report Autonomy Software (@gbiggs, @esteve)
  8. Working group report Autonomy Hardware (@cheng.chen, @sstrahm)
  9. Working group report Map formats (@Brian_Holt, @mitsudome-r)
  10. GitLab versus GitHub (AWF board)
  11. Proposal to investigate and define ARA::Autoware (AutoSAR Adaptive-compliant Autoware) (@YangZ)
  12. Tier IV demo space at the Tokyo Olympics

Action items

  • Update Linaro and Arm representatives about the setup of native Arm runners for CI
  • Run a vote on GitHub vs GitLab
  • Set up a follow-up meeting to discuss the AutoSAR proposal, including some people who have experience with AutoSAR

Detailed minutes

Opening remarks and new member introductions (Board)

  • New members:
    • Department of Transportation (USA)
    • NXP

Confirmation of previous minutes (All)

  • Minutes approved with one correction:
    • Tier IV’s new architecture proposal will not be merged with Autoware.AI. It will be a separate version of Autoware ideally released as open-source, but Tier IV has not made a final decision on whether they will release it or not yet.

Action items from previous meeting (All)

  • Follow up on why StreetDrone’s and ITDLab’s new representatives are not in the TSC meetings
    • @gbiggs
    • Action taken Still need to follow up with ITDLab. StreetDrone is now attending meetings again (new representative).
  • Release the safety case example
  • Enact the new working groups schedule
  • Rename the working groups
  • Set up the AWF events calendar and working group invites lists
    • @gbiggs
    • Action taken Google Groups created for each working group to manage calendar event invitations

Autoware Meetup @ CES2020

  • Meetup for members (not the open happy hour).
  • So far 15 to 20 people have signed up.
  • Please RSVP if you have not yet.

Event report: Autoware Meetup at Apex.AI

Working group report: Autonomy Software (@esteve, @gbiggs)

Autoware.AI

  • Autoware.AI 1.13 has been released
    • Big thanks to Josh Whitley for shepherding this release
  • Autoware.AI 1.14 schedule has been set. Release is targetted for Tuesday 26 May, 2020 (12:00 TZ).
  • The next release of ROS 1 (Noetic) is due for release some time in May, 2020. We need to decide if we support Noetic from 1.14 or 1.15.
    • Supporting from 1.14 would be helpful for compatibility with Autoware.Auto.
  • We are working on adding native Arm runners for Autoware.AI. @JWhitleyWork to inform the Linaro and Arm representatives when this is done.

Autoware.Auto

Autonomous Valet Parking demonstration

  • Demonstration of AVP functionality using Autoware.Auto planned for April 24th, 2020 in Palo Alto.
  • A planning workshop was held at Apex.AI on December 10th.
  • The work continues to be coordinated in the weekly Autonomy Software WG meetings. Anyone interested in participating should join this working group.

Working group report: Maps and routing (@Brian_Holt, @mitsudome-r)

  • No report provided.

Working group report: Autonomy Hardware (@cheng.chen, @sstrahm)

  • Minutes of most recent WG meeting
  • About specifiction, it’s not only about hardware’s performance/interface and sensor configuration, but also including system software of MPU/MCU.
  • Heterogeneous SoC have different IP cores for algorithm acceleration and some features will be realized inside RT-Core/MCU, it’s hard to let current open source code to support all kinds of SoC, so need to define software interface and acceptance testsuit (by Autoware WG?).
  • We will invite sensor vendors to join WG meeting to discuss sensor interface and configuration because they known well with their sensors.

GitLab versus GitHub

  • The old Autoware.AI repository at GitHub has over 3,600 stars.
  • The new Autoware.AI repository at GitLab has 63 stars.
  • Recently comments have been received from companies that “Autoware has so few stars so obviously no one is using it”.
  • Should we move Autoware back to GitHub?
  • Points to consider:
    • The disruption of moving from one site to another
    • The additional disruption of doing this twice in less than a year
    • Differences in functionality at GitHub and GitLab
    • GitLab provides us with enterprise-level tools for free; will GitHub do the same?
    • If we move back to GitHub, when should we move?

GitHub vs GitLab Dec 2019.pdf (66.4 KB)

Discussion

Some TSC members prefer to switch back to GitHub to improve the visibility of Autoware. Others prefer to find more effective ways of enhancing visibility (marketing, promoted usage examples) rather than relying on a nebulous measure like the number of stars on GitHub or GitLab. It was pointed out that we are looking at three different audiences who look for different things about a repository (e.g. most recent commit, number of committers, number of stars, number of downloads).

Shinpei Kato proposes that the Autoware repositories are moved from GitLab to GitHub.

Due to the split in opinions a consensus could not be reached. An email vote will be held to poll all TSC members for their decision in order to choose whether to switch back to GitHub or stay with GitLab.

Proposal to investigate and define ARA::Autoware (AutoSAR Adaptive-compliant Autoware)

From @YangZ:

discussion regarding defining a rule/specification (or APIs where applicable) in to help migrating (not replacing) ROS2 based development to AutoSAR Adaptive framework, to help people who have intention to use Autoware for R&D purpose with also intention for an AutoSAR Adaptive compliant stack development. Specifically, I am proposing to investigate and define ARA::Autoware.

Proposal document from @YangZ (1.9 MB)

  • The AutoSAR Consortium cannot be ignored. Like the ROS community, they are moving ahead.
  • By supporting AutoSAR Adaptive in Autoware, we would provide a path for people to move from R&D with the ROS 2-based Autoware to using AutoSAR Adaptive in their production systems, which would therefore increase adoption of Autoware.
  • Open questions:
    • Would it be OK if there were an open source implementation of ARA::COM in Autoware.auto?
    • Would an AutoSAR-based Autoware be useable by anyone or only AWF members?
  • The goal is not an open source AutoSAR-based Autoware stack. The goal is an open specification (API, specification, or whatever form it should take) that will help people adopt Autoware-developed technology into their own (or purchased) AutoSAR framework.

The report on AutoSAR Adaptive vs. ROS 2 prepared by @Dejan_Pangercic some time ago is relevant to this discussion. Note that this report is only available to AWF members, so do not distribute it.

Adaptive Autosar and ROS2.pdf (328.1 KB)

Comments from Apex.AI:

  • The AutoSAR license terms explicitly forbid open source implementations.
  • ARA::Comm is service-oriented, by contrast with DDS’s (on which ROS 2 is build) data orientation. Although AutoSAR has adopted DDS but none of the vendors are currently providing it.
  • Because none of the implementations are open source, you must by a license for an implementation, which means we do not know how easy or difficult it is to use.

Comments from AutonomouStuff:

  • If we are going to make a set of guidelines targetting AutoSAR, then we are aiming for a moving target which means we will need to keep updating this specification or API.

@YangZ proposes that the AWF spends some engineering effort on looking at the creation of ARA::Autoware, i.e. a specification of Autoware that is compatible with AutoSAR Adaptive.

  • We need to have a meeting including some people who have experience with AutoSAR.

Autoware Everywhere

  • Blog series called “Autoware Everywhere”
  • 96Boards is working across a range of different ARM-based SoCs, and this blog series looks at running Autoware.AI, Autoware.Auto, and both together, on different boards.
  • First post discusses running Autoware.Auto (the 3D perception demo) on the Hikey 970.
  • These blog posts will also be posted to the Autoware website.
  • One of the goals of this effort is to prove that Autoware can be optimised to run on different SoCs, which should also help bridge the gap between the software and hardware aspects of the Autoware Foundation’s activities.

Tier IV demo space during the Tokyo Olympics

  • This is a government project to operate some autonomous vehicles during (not at) the Tokyo Olympics.
  • The goal of the demo is to show several different autonomous vehicles, in order to show Autoware running on different vehicles, different hardware, and with different sensor configurations.
  • Show the same demo that was shown in April 2020 in Palo Alto (the AVP demo) in Tokyo, as well as additional functionality - not just the AVP demo.
  • The goal of the demo is to show that Autoware (including Autoware.AI and Autoware.Auto) works on many different hardware configurations.
  • Will come back to this in a future meeting.