Autoware TSC meeting minutes for June 19, 2019

Autoware
1

June 19, 2019, 15:00 UTC

Attendees

  • Lee Baldwin (Autonomous Stuff)
  • Adrian Bedford (Parkopedia)
  • Geoffrey Biggs (Tier IV)
  • Cheng Chen (AutoCore)
  • Ian Colwell (AutonomousStuff)
  • Esteve Fernandez (Apex.AI)
  • Kenji Funaoka (Tier IV)
  • Brian Holt (Parkopedia)
  • Shinpei Kato (Tier IV)
  • Seonman Kim (LG)
  • Filipe Rinaldi (Arm)
  • Paul Sastrasinh (TRI-AD)
  • Antonis Skardasis (StreetDrone)
  • Matt Spencer (Arm)
  • Stephane Strahm (Kalray)
  • Akihiko Tsukuda (eSOL)

Minutes Geoffrey Biggs (Tier IV)

Agenda

  1. Opening remarks and new member introductions (Board)
  2. Admin Confirmation of previous minutes (All)
  3. Follow-up Action items from previous meeting (All)
  4. Project update Autoware.AI/Autoware.Auto (Apex.AI/Tier IV)
  5. Project update Map format (Parkopedia/Tier IV/Apex.AI)
  6. Project update Vehicle interface design (StreetDrone)
  7. Planning Topic-specific working groups (All)
  8. Planning Milestones for development of Autoware.Auto (All)
  9. Planning Hiring a system architect for Autoware.Auto (Apex.AI/Tier IV)
  10. Presentation Perception process unit hardware and software design (Autocore.AI)
  11. Presentation Arm and the ELISA foundation (Arm)

Action items

  • Close remaining Slack channels except general
    • Geoff
  • Follow up about free AWS minutes
    • Geoff & Esteve & Jan
  • Provide a set of launch files for starting just waypoint following-related functionality in Autoware.AI
    • Parkopedia
  • Start OpenDrive discussion in the Autoware Discourse category
    • Parkopedia
  • List planned contributions that go towards Foundation work and can be used to meet the milestone demos. Place planned contributions in this topic.
    • Kalray
  • Begin coordinating working groups
    • Geoff

Detailed minutes

Opening remarks and new member introductions (Board)

  • Macnica has joined as an industrial member.

Confirmation of previous minutes (All)

  • Minutes approved

Follow-up: Action items from previous meeting (All)

  • Close the Slack channels
    • Geoff
    • Action taken Channels closed
  • List planned contributions that go towards Foundation work and can be used to meet the milestone -demos. Place planned contributions in this topic.
    • LG
    • Kalray
    • AutonomousStuff
    • Velodyne
    • Action taken LGE, AutonomousStuff and eSOL have listed items.
  • Move the Autoware.AI code to GitLab
    • Autoware maintainers team
    • Action taken This is in progress; the move is mostly complete. Remaining is fixing the install process (using vcs) and making the GitHub repository a mirror of the GitLab one.
  • Set up a meeting to talk about how to contribute to Autoware.Auto
    • Tier IV (Geoff)
    • Action taken Delayed due to need for working group discussion
  • Set up a meeting to discuss map format work
    • Tier IV (Geoff)
    • Action taken Delayed due to need for working group discussion
  • Set up a meeting to discuss vehicle interface work
    • StreetDrone
    • Action taken Meeting held.
  • (Contingent on AWF board approving budget) Coordinate with TRI-AD to get CI going in AWS
    • Autoware maintainers team
    • Action taken Board approved some budget. Waiting for Jan to get back to us about possibility og AWS providing some free runner time.
  • Begin organising an integration verification team by discussing team make-up and specific tasks on Discourse and/or GitLab
    • Tier IV, AutonomousStuff, StreetDrone
    • Action taken No action taken yet.
  • Coordinate the threat modelling work of NDIAS and Alias Robotics
    • Tier IV, Apex.AI
    • Action taken Delayed until July by request

Project update: Autoware.AI/Autoware.Auto (Apex.AI/Tier IV)

  • Autoware.AI:
    • Repository move to GitLab is mostly complete.
    • Repository split is complete aside from getting CI going again.
    • On track to release 1.12 on July 1st, but with no where near enough testing. We will need to consider switching to a longer release cycle to provide enough time for MR merging and testing.
      • Feature freeze tried to happen on schedule but it took several weeks to get the PRs merged, because they all came in at the last minute and most had several problems.
      • Repository move and split, and new features coming in at the same time, made things unnecessarily complex. We should have done the move-and-split only.
    • Tier IV will test on the Lexus on 6/20.
    • Documentation still needs to be updated.
  • Autoware.Auto:
    • The LiDAR stack is now fairly complete. It was demonstrated at the IV 2019 workshop. It includes voxel grid down sampling, ground plane filtering, and a velodyne driver. Euclidean clustering will be merged in the next few days.
    • Autoware.Auto now uses ROS 2 Dashing, the first LTS release for ROS 2.
    • The ros1_bridge usage has been fixed and improved.
    • Planning on making a release at about the same time as Autoware.AI 1.12.
    • Demos will be produced showing the combination of Autoware.AI and Autoware.Auto (perception stack) will be produced.
  • Policy for implementing algorithms as ROS-independent libraries
    • How independent should algorithm libraries be from ROS? Should they be completely usable outside of ROS (i.e. don’t use ROS logging system, ROS data types, etc.?).

Discussion

  • We need to encourage more contribution from other members.
  • Parkopedia has a set of launch files to start just the parts of Autoware.AI necessary for waypoint following. We hope to use these to flesh out the waypoint follower capability milestone.
    • Parkopedia is cleaning these up for releasing in the next week.
  • Autoware.Auto currently uses Eigen for its math library, but Eigen is not static and real-time safe.
  • ROS-independent libraries:
    • Not using ROS in libraries has several drawbacks and few benefits, and the use case of taking an algorithm from Autoware and using it outside of ROS is likely to be too uncommon to make it a design goal.
    • Esteve and Geoff to move forward as appropriate based on design needs.

Project update: Map format (Parkopedia/Tier IV/Apex.AI)

  • The OpenDrive format is very widely used in industry.
    • It’s so common that the Navigation Data Standard (NDS) organisation has commissioned a converter between OpenDrive (an XML format) and NDS format (an sqlite3 database).
  • OpenDrive is being standardised within an organisation called The Association for the Standardisation of Automation and Measuring Systems, which is part of the OpenDrive Forum.
  • Parkopedia’s proposal:
    • Use OpenDrive (which is also supported by CARLA) as a map storage format
    • Continue the lanelets2 work as the library we use to read maps from disc
    • Create some OpenDrive maps for environments (car parks)
  • lanelets2 is just a library, and it reads from and writes to the OpenStreetMap format. In principle it should be able to make it read from and write to OpenDrive maps.
  • OpenDrive format is a single format on which we can concentrate our efforts.
  • We need to investigate how much of the features we need OpenDrive covers.
    • Parkopedia has not done a complete investigation, but the impression so far is that it covers more of the features we need than OpenStreetMap.
  • Parkopedia will start a discussion on Discourse about this topic.

Project update: Vehicle interface design (StreetDrone)

  • A meeting was held a couple of weeks ago.
  • As the first action, we are collecting use cases for the vehicle interface.
  • Based on the results of this, future development directions will be decided.
  • Next meeting will be held approximately 2 weeks from this TSC meeting.

Topic-specific working groups

https://discourse.ros.org/t/technical-discussion-and-the-tsc-meetings/9241

Discussion

  • StreetDrone prefers to have two leaders per working group, to reduce the burden on each leader and in case one leader cannot attend a meeting.
  • Kalray is in favour of the concept and would like new working groups to be possible whenever necessary.
  • No opposition to the idea
  • Proposal accepted
  • Initial set of working groups:

Milestones for development of Autoware.Auto (All)

  • https://gitlab.com/groups/autowarefoundation/-/epics
  • Milestones have seen no discussion or input except from Tier IV and Apex.AI.
  • We need to begin fleshing out the first milestone in detail and as much of the second milestone as possible at the current level of knowledge.
    • Propose to leave this detail work for the Autoware working group to do.

Discussion

  • Parkopedia will contribute to fleshing out the first milestone (waypoint following) by providing their launch files. However they are not ready to be able to convert this work to Autoware.Auto in the short term due to important business-side commitments until September.

Hiring a system architect for Autoware.Auto (Apex.AI/Tier IV)

  • Delayed to next time.

Perception process unit hardware and software design (Autocore.AI)

PCU2.4.pdf (458.3 KB)

  • A hardware processing unit designed for LiDAR data processing and sensor fusion.
  • It has connectors compatible with LiDARs so no conveters are necessary.
  • 4 CAN interfaces are included.
  • It runs FreeRTOS with Micro XRCS-DDS on the MCU, and Ubuntu/ROS/DDS on the MPU.
  • They have Autoware.AI 1.11 running on it successfully.
  • It will go on sale in around October.

Discussion

  • Arm: How do you deal with safety? Is there a separate safety-critical core?
    • Autocore.AI: It runs lock-step. The TI chip is ASIL D.
  • Kalray has previously discussed the idea of having the MPU accelerator with Autocore.AI.

Arm and the ELISA foundation (Arm)

  • Arm joined the ELISA project was important to reduce repeating work for things like MISRA compliance and meeting safety requirements.
  • Arm is a founding member of ELISA.
  • ELISA is looking in particular at safety certifying Linux.
  • Other work products will be best practices, tools, educational materials, etc. for safety-critical use of open source software.
  • The AWF is particularly interested in approaches ELISA develops for certifying open-source software.
  • The first ELISA face-to-face meeting was held last week.
  • ELISA has decided to use Apollo as the starting point to flesh out the process.
    • Arm would prefer that Autoware.Auto were chosen. The TSC obviously supports this. Arm will try to find out why Apollo was chosen.
    • Arm proposes that we approach ELISA and propose that Autoware is a more open-source-friendly project to work with.