Autoware TSC meeting minutes for April 17th, 2019

Autoware
1

April 17, 2019, 15:00 UTC

Attendees

  • Jan Becker (Apex.AI)
  • Geoffrey Biggs (Tier IV)
  • Joseph Buckner (AutonomousStuff)
  • John Buszek (AutonomousStuff)
  • Chen Cheng (Autocore.ai)
  • Victor Duan (Linaro)
  • Esteve Fernandez (Apex.AI)
  • Kenji Funaoka (Tier IV)
  • Brian Holt (Parkopedia)
  • Shinpei Kato (Tier IV)
  • Seonmaan Kim (LG)
  • Angelo Mastroberardino (Parkopedia)
  • Dejan Pangercic (Apex.AI)
  • Paul Sastrasinh (TRI-AD)
  • Antonis Skardasis (StreetDrone)
  • Matt Spencer (Arm)
  • Stephane Strahm (Kalray)
  • Daisuke Tanaka (Tier IV)
  • Dmitry Zelenkovsky (LG)
  • Yang Zhang (Linaro)

Minutes Geoffrey Biggs (Tier IV)

Agenda

  1. Opening remarks and new member introductions (Board)
  2. Admin Confirmation of previous minutes** (All)
  3. Notice Removal of project-specific sub-categories on Discourse (Geoff)
  4. Notice Moving TSC home from Slack to Discourse (Geoff)
  5. Notice Moving Autoware support from Discourse to ROS Answers (Geoff)
  6. Follow-up Action items from previous meeting (All)
  7. Project update Autoware.AI/Autoware.Auto (Apex.AI/Tier IV)
  8. Project update Map format (Parkopedia/Tier IV/Apex.AI)
  9. Follow-up Use of code from Apollo and revisit policy towards Apollo (All)
  10. Follow-up Hiring a lawyer to look at simulator licenses (Board)
  11. Follow-up Unreal game engine licensing for simulators (Apex.AI)
  12. Proposal Invite Epic to join the Autoware Foundation (Apex.AI)
  13. Proposal Joining Google Summer of Code and Outreachy (Apex.AI/Tier IV)
  14. Planning Parkopedia commitment resources (Board/Yang)
  15. Planning StreetDrone commitment resources (Board/Yang)
  16. Planning Planned contributions from foundation members. (All)
  17. Planning Common hardware platform: Lexus and the parameters for control (Tier IV)
  18. Planning Milestones for development of Autoware.Auto (All)
  19. Presentation Arm and the ELISA foundation (Arm)
  20. Presentation Perception process unit hardware and software design (Autocore.AI)
  21. Proposal Threat model for Autoware.Auto platform and use case (Apex.AI)
  22. Proposal Automating map and vehicle model imports with Parallel Domain (Apex.AI)

Action items

  • Move TSC discussion place and AWF operations discussion place from Slack to Discourse
    • Tier IV (Geoff); will do in stages by the next meeting
  • Remove the public sub-categories of the public Autoware category at Discourse
    • Tier IV (Geoff)
  • Update the support guidelines and bug/issue templates for Autoware.AI to use ROS Answers instead of Discourse for support discussion
    • Tier IV (Geoff)
  • Arrange review of licenses for Unreal, Unity, CARLA and LGSVL
    • Apex.AI/Board (Yang)
  • Provide differences between Apex.Autonomy and Autoware.Auto, and between Apex.OS and ROS 2, in next meeting
    • Apex.AI
  • Review, discuss and improve milestones for Autoware.Auto development
    • All
  • Coordinate with Tier IV and Kalray to bring their work on algorithm acceleration into the computing platform effort
    • Linaro (Yang)
  • List planned contributions that go towards Foundation work and can be used to meet the milestone -demos. Place planned contributions in this topic.
    • Tier IV
    • LG
    • Kalray
    • Arm
    • Linaro
    • AutonomousStuff
    • TRI-AD
    • Autocore.ai
    • Huawei
    • Velodyne
  • Coordinate on prototyping work for Lanelets2 use in Autoware
    • Parkopedia, Tier IV
  • Talk to OSRF about using one of their GSoC slots for Autoware work
    • Apex.AI
  • Set up a teleconference to talk about the vehicle interface work for Autoware (especially Autoware.Auto)
    • StreetDrone

Detailed minutes

Opening remarks and new member introductions (Board)

Nothing in particular.

Confirmation of previous minutes (All)

Minutes approved.

Removal of project-specific sub-categories on Discourse (Geoff)

Discussion

  • No opposition, proposal accepted.

Moving TSC home from Slack to Discourse (Geoff)

  • Slack is nice for holding a real-time chat, but it has several disadvantages:
    • We are using the free tier, which means we only have access to the most recent 10,000 posts. Thus we are losing the background for decisions that have been made.
    • It is very hard to find where specific conversations occur, because everything is organised by channels rather than by conversations.
    • It can be distracting and hard to keep up with as notifications can come in at a high rate and if you do not respond rapidly the thing you wish to respond to can be lost in the conversation.
    • It requires direct engagement as soon as possible (relates to the above).
    • Message formatting is limited - only good for short messages.
  • By contrast, Discourse (provided by the OSRF) has many advantages, including:
    • All history is available.
    • Conversations are archived separately so the background for decisions is clear.
    • Discussion does not happen in real time so most conversations are easier to manage across time zones.
    • Direct messages are possible, and apart from rapid-fire chats are as useful as Slack direct messages.
    • Subscriptions can be done at a fine-grained level so you can get only the categories or threads you are interested in in your inbox, or as desktop notifications, or just via the Discourse site.
    • Necessary response time to join a conversation is much longer due to ability to reply to individual messages, easily quote parts of messages, etc.
    • Richer message formatting options.
  • Most important point is easier tracking of decisions and their background. This is important for the Autoware Foundation as an organisation.
  • Secondary point for some TSC members is that Slack is very disruptive to their work flow and hard to keep up with.
  • Proposal: Shift all TSC-related and Foundation operation-related discussion to the Autoware TSC private category on Slack.
    • Proposed extension: Shut down the TSC and operation channels on Slack; when real-time, rapid-fire conversation is necessary, start a direct message channel specifically for it.
    • Possible extension: Create a separate private category for Autoware Foundation operation discussion, separate from the TSC (like the Slack channel).

Discussion

  • Tier IV in favour.
  • Apex.AI strongly in favour.
  • AS in favour
  • Parkopedia no objections
  • Kalray in favour
  • Slack channel shutdown also agreed
  • Decision: Move from Slack to Discourse private category and shut down the Slack channels. All TSC and Foundation-related discussion should happen on Discourse in the private category or via direct message, not Slack, to avoid confusion or loss of material.

Moving Autoware support from Discourse to ROS Answers (Geoff)

To reduce noise on the GitHub issue tracker, we have, over the past two months or so, been enacting a policy of directing anything not a confirmed bug or feature request to Discourse for help. This has been effective, with help being provided actively by many Autoware developers at Discourse. However, the general ROS policy is that support should be done through ROS Answers because that site is better suited to providing a searchable archive of problems and solutions.

It has been the plan from the start to, in the long term, either set up an “Autoware Answers” site or use ROS Answers. Use of Discourse was intended to be a placeholder until traffic grew high enough to justify an answers site. Traffic has been higher than expected right from the start, however.

Because of the existing ROS policy of not doing support on Discourse, the OSRF is concerned that Autoware using Discourse for this purpose will confuse other ROS users (who are not likely to notice the category of a thread) and cause an increase in general ROS support requests on Discourse. Therefore we have been asked if we can shift support to ROS Answers.

  • Proposal: Shift support for Autoware to ROS Answers, with support guidelines asking for questions to be tagged with an autoware tag so we can find them.
    • Possible problem: Most new users are not likely to use the autoware tag, making finding their questions harder for Autoware developers; other ROS users do not have much experience with Autoware (its existence is surprisingly not widely known) and so won’t be able to provide support. The result could be an impression of Autoware having poor user support.
  • Possible alternative: Set up our own “Autoware Answers” site. The downside is maintenance is non-trivial.

Discussion

  • Apex.AI in favour of using ROS Answers.
  • Tier IV in favour.
  • Parkopedia in favour.
  • We will need to put effort into looking for mis-tagged questions and tagging them correctly, but this is the only problem.
  • Has the side effect of us being more involved in the ROS community.
  • Will investigate if we can provide a link that automatically tags a question with Autoware.
  • Decision: Will use ROS Answers. Geoff to do work to move to ROS Answers.

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

  • Review opinions on the tool chain and information provided by TRI-AD and make a decision on what to use
    • Geoff, Esteve
    • Action taken: Applied for and qualified for GitLab’s open source programme, so will use GitLab as the tool chain. Will need to do some engineering for CI to meet the fork and pull model.
  • Coordinate with the Linux Foundation/AGL on their efforts to improve safety certification practices of open-source software
    • Geoff to take point
    • ARM, Linaro, TRI-AD, Tier IV, Kalray to participate as interested
    • Action taken: None yet; AGL stated they won’t have anything to talk about until July.
  • Lead improvement of mapping format used by Autoware
    • Brian Holt (Parkopedia)
    • See dedicated agenda item
  • Produce some proposals for milestone demos that we could set to drive the development of Autoware.Auto and direct resources (choice and ordering to be decided in TSC meeting #5)
    • Geoff
    • Action taken: Milestone draft created and circulated for discussion. See dedicated agenda item.
  • Coordinate with Tier IV and Kalray to bring their work on algorithm acceleration into the computing platform effort
    • Yang
    • Action taken: None yet; will try to meet in the next week.
  • List planned contributions that go towards Foundation work and can be used to meet the milestone demos (once decided)
    • All premium members
    • See dedicated agenda item
  • Follow up with premium members who have never attended a TSC meeting
    • Yang
    • See dedicated agenda item
  • Hire a lawyer with experience in open source licenses to look at licenses for all potential simulators
    • AWF board
    • Action taken: Decided to use Apex.AI lawyer, paid for from AWF budget; waiting to receive revised license from LG. Also need to include CARLA, Unreal and Unity licenses.

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

  • Autoware.AI:
    • Improving development practices through reduced write access to repositories and stronger PR rules.
    • Splitting repositories and moving packages out of autoware repository.
  • Autoware.Auto
    • Ported two more algorithms from Apex.Autonomy
    • Was waiting for tool chain decision before setting up infrastructure, CI, etc. This decision has been made now (in favour of GitLab Gold via the OSS programme), so this work can begin.
    • Discussion going on at Apex.AI about how to sync Apex.Autonomy and Autoware.Auto. Will be testing a process using a GPS driver.
      • Apex.Autonomy runs on top of Apex.OS (the real-time, deterministic, certified version of ROS 2).

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

  • Focus has been on producing XML representations from the real-time data that they collect.
  • Currently have an internal XML representation that can represent all aspects of both open and covered carparks.
  • Next piece of work is to determine how to consume that map for the purposes of navigation and localisation.
    • This is where lanelets comes in.
  • Lanelets2 is an open source, open format map representation. It has a library that implements it available already.
  • Lanelets2 doesn’t cover as much as Parkopedia’s internal format, such as multiple levels, ramps, etc. But Lanelets2 is open source, and so modifiable and acceptable and no challenges of balancing releasing some parts and not others.
  • Parkopedia has had success converting their XML representation into OpenStreetMap.
  • Brian has spoken to Atlatec and they are using lanelets2 as well.
  • Parkopedia wants to support the effort required to integrate lanelets2 into autoware for navigation and localisation.
    • Lanelets2 supports localisation but it may not support everything needed but Autoware for localisation.
  • Parkopedia is working with leading OEMs on the use of artificial landmarks. They want to integrate this information into the lanelets2 format.
  • Parkopedia believes that all maps that Autoware can read and write should be in an XML format that ideally uses the lanelets2 library.
  • LG is concerned about the streaming of map data.
    • The wider OEM community is not considering using XML. Most automotive companies are using NDS, which is much heavier than an XML representation.
  • Apex.AI has talked to the authors of lanelets2 and found them very open to adding new features that Autoware requires, although they may want some kind of payment if they have to do any work themselves. It is worth considering trying to get them into the AWF.
    • Lanelets2 development is very active and it is very well maintained.
  • Proposal: Parkopedia wants to make the contributions to lanelets2 to support 3D.
    • Apex.AI is concerned if Parkopedia can afford to do this work.
  • Proposal: Apex.AI wants to see a lightweight prototype, e.g. using the NDT localiser node.
    • Tier IV is working on prototyping to see how lanelets2 can be used internally in Autoware.

Follow-up: Use of code from Apollo and revisit policy towards Apollo (All)

Discussion

  • For copying of code:
    • Board: Fine with this sort of code copying as long as the copyright is preserved.
    • Apex.AI: We should be using source from external sources as a dependency rather than copying it into Autoware.
    • Tier IV: The policy of not copying has already been established and clarified but there is a lot work to do for cleaning up existing code that has been forked unnecessarily.
  • For relationship to Apollo:
    • Board: We should be OK with using code from Apollo because it is open source.
    • Apex.AI: Then should we work with them to make their code easier to depend on rather than copy?
    • LG: If we understand the algorithms and they are better we should copy them because Apollo breaks their API all the time.
    • Decision: Decide to copy or not on a case-by-case basis.

Follow-up: Unreal game engine licensing for simulators (Apex.AI)

  • Esteve (Apex.AI) has spoken directly to Epic Games about how their licensing works for using Unreal in simulators for autonomous driving.
  • Epic stated that we can do whatever we want with Unreal, and only if we were to sell the simulator would the royalty policy kick in.
  • Still want a second opinion from the lawyer that the AWF will hire to look at the licenses.
  • Epic’s revenue model is through support contracts, not through royalties.

Proposal: Invite Epic to join the Autoware Foundation (Apex.AI)

  • Epic Games has expressed an interest in joining the Autoware Foundation as a paid member.
  • Their interest is obviously going to be in the use of their engine to drive self-driving simulators.
  • Epic have invited someone from the AWF to attend their event in Detroit next week for people using Unreal in industrial applications (not games).
  • Decision: If they are interested in joining they should go through the usual process.

Proposal: Joining Google Summer of Code and Outreachy (Apex.AI/Tier IV)

  • These outreach programmes allow organisations to work with students and with people from underrepresented communities (women, people from developing countries, etc.).
    • Targeted to people who want to be involved in open source projects.
  • They are very successful at giving these people experience they may otherwise not be able to get and at encouraging them to get into open source.
  • They are a good way to introduce new people to our projects.
  • They provide another way to find new employees (OSRF has had good experience with this)
  • For an example of the impact such diversity programmes can have, watch this short talk from ROSCon 2016: ROSCon 2016 Seoul Day 2 Lightning Talk: US sacntions on Sudan and its effect on students on Vimeo
  • For GSoC:
    • Organisation makes a proposal to be part of the programme.
    • Google selects organisations and allocates a number of slots to each selected organisation.
    • Google pays the student a stipend.
    • Organisations are responsible for mentoring the student with the goal of their work being integrated into the organisation’s projects.
  • For Outreachy:
    • Not specifically for students, for underrepresented communities.
    • Funded by donations (it’s a foundation) such as from Microsoft. May need to contribute financially to be involved.
    • Happens twice a year (summer and winter).
    • In general works the same way as GSoC.
  • Apex.AI suggests starting with one to avoid getting overworked while we figure out how to support it.
  • Apex.AI suggests that because we are late for GSoC, we ask the OSRF if we can use one of their slots instead.
  • Decision: Try to use an OSRF slot this year for GSoC, and use that to figure out how to work with it so we can participate properly next year.

Planned contributions from foundation members. (All)

  • See posted contributions
  • Listed:
    • Apex
    • Parkopedia
    • Streetdrone
  • Not listed
    • Tier IV
    • LG
    • Kalray
    • Arm
    • Linaro
    • AutonomousStuff
    • TRI-AD
    • Autocore.ai
    • Huawei
    • Velodyne
  • All “not listed” companies must provide their proposed contributions ASAP.

Common hardware platform: Lexus and the parameters for control (Tier IV)

  • We need to settle on a common hardware platform. Momentum and inertia seem to be pushing us towards the Lexus.
  • We need to know the detailed parameters of this car for:
    • Control algorithm tuning (Tier IV needs this)
    • Physical modelling for simulation (LG needs this)
  • It has been suggested that AutonomousStuff can provide this sort of detailed information.
  • AS is willing to help with this work, but they cannot spend weeks getting the exact parameters. They also need to figure out what they are already doing in relation to LGSVL, and how the control work relates to their commercial product.
  • AS to talk to LG offline about the LGSVL work.
  • StreetDrone has already done this work for their vehicle to get all the necessary parameters, and they provide a URDF model.
  • Conclusion: TSC members all agree on the need for a common format for defining the car’s parameters (URDF).
    • May need an automatic exporter from URDF to the simulator, depending on the simulator being used.
  • Conclusion: StreetDrone is driving vehicle interface abstraction. They will collaborate with AS.
    • StreetDrone to set up a meeting to talk about the vehicle interface.

Milestones for development of Autoware.Auto (All)

  • We must choose milestones to direct our development efforts for the next generation Autoware.
  • See milestones topic.
    • This is the planning topic. Agreed milestones will be made public in the open Autoware category and on the Autoware Foundation website.
  • We must agree on at least the first two or three milestones today.
  • Item dropped due to time.

Arm and the ELISA foundation (Arm)

  • Item dropped due to time.

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

  • Item dropped due to time.

Proposal: Threat model for Autoware.Auto platform and use case (Apex.AI)

  • Recently the ROS 2 TSC’s security working group has done quite a bit of good work in developing a threat model for two robots:
  • Proposal: A member company should undertake to develop a thread model for Autoware.Auto and its use case.
  • Item dropped due to time.

Proposal: Automating map and vehicle model imports with Parallel Domain (Apex.AI)

  • A company called Parallel Domain has capabilities for automating the creation of simulation worlds and vehicle models.
  • Should we get in touch with them and see if they want to work with us?
  • Item dropped due to time.