Autoware working group: Call for participation

Autoware
2

Attendees

  • Geoffrey Biggs (Tier IV)
  • Esteve Fernandez (Apex.AI)
  • Liyou Zhou (Arm)
  • Eliot (Arm)
  • Luxiang Zhou (AutoCore)
  • Ryohsuke Mitsudome (Tier IV)
  • Stephane Strahm (Kalray)
  • Akihiko Tsukuba (eSOL)

Minutes

Working group backround and goals

  • Manage general development of Autoware.AI and Autoware.Auto
  • Coordinate activities between the two so we don’t duplicate work
  • Coordinate cross-functionality infrastructure and Autoware-wide functionality
    • Release process
    • Documentation
    • Docker
    • CI
    • …
  • Coordinate the overall architecture of Autoware.Auto
  • Ensure that function-specific working groups are not working at cross-purposes
  • Provide a place for cross-working group discussions (e.g. perception and planning when they need to talk) on an as-needed basis

Autoware specification proposal

Discussion

  • [Kalray] Add a document to define the overall structure of Autoware.
  • [eSOL] How does the specification fit with Autoware.AI?
    • It will not be forcefully aligned with the specification because it is due to be gradually phased out. We may need to alter Autoware.AI to match the specification in places to make the bridge work, but we want to keep these to a minimum because any resources put into Autoware.AI development are resources taken from Autoware.Auto development.
  • [Arm] Can Autoware.Auto have multiple implementations of a specific functionality, even though it is a reference implementation?
    • Yes. This will aid in it being a reference, because it will show multiple ways to implement the specification.
  • [Kalray] The Autoware working group will need to define target applications/use cases, particularly if we aim to go for certification in the future.
    • As a starting point we have the [existing five milestones for Autoware.Auto development]. These need to be fleshed out to be detailed use cases that can drive the specififcation’s development.
  • [Arm] Next step should be to define the use cases for the specification.
  • [eSOL] Will Autoware support ISO 26262, other than writing the document specification? For example, test coverage data.
    • This question applies more to Autoware.Auto (the reference implementation) than the specification itself. Currently the Autoware Foundation is not aiming to certify Autoware.Auto, due to the difficulty of certifying an open-source project. However we do aim to be high-quality (as close to production quality as possible), so we already support various useful things such as generating a coverage report in the documentation, thanks to work done by Apex.AI.
  • [Arm] What’s the process from now?
    1. Make the proposal to the TSC this week
    2. Define a formal process proposal over the next few weeks
    3. Propose the process in the August TSC meeting
    4. Once the process is accepted begin moving forward with proposing and accepting draft specification documents.
    • All work will be done via GitLab using MRs so that proposed changes and discussions are recorded.
  • [Tier IV] If the documents will be separated into various documents, who will do the documents that don’t currently have a working group?
    • For cross-functionality ones, such as introspection interfaces, this working group should be responsible.
    • For functionality-specific ones, such as perception, new working groups will need to be created.

Autoware.Auto