Autoware TSC meeting minutes for March 20th, 2019

Autoware
1

The Autoware Foundation (AWF) Technical Steering Committee (TSC) Meeting #4

March 20, 2019, 7 AM Tokyo (+1day), 10 PM London, 2 PM California

  • Attendees
    • Geoffrey Biggs (Tier IV)
    • Antonis Skardasis (StreetDrone)
    • Dejan Pangercic (Apex.AI)
    • Dmitry Zelenkovskiy (LG)
    • Esteve Fernandez (Apex.AI)
    • Jan Becker (Apex.AI/Autoware Foundation board)
    • Joe Buckner (AutonomousStuff)
    • John Buszek (AutonomousStuff)
    • Kenji Funaoka (Tier IV)
    • Nikos Michalakis (TRI-AD)
    • Paul Sastrasinh (TRI-AD)
    • Shinpei Kato (Tier IV/Autoware Foundation board)
    • Stephane Strahm (Kalray)
    • Victor Duan (Linaro/96Boards)
    • Yang Zhang (Linaro/96Boards/Autoware Foundation board)
  • Minutes: Geoffrey Biggs (Tier IV)

Agenda

  1. Opening remarks and new member introductions [2 minutes]
  2. Projects update: Autoware.Auto/Autoware.AI (Tier IV/Apex.AI) [10 minutes]
  3. Autoware.Auto toolchain (Tier IV/Apex.AI/TRI-AD) [20 minutes]
  4. Automotive Grade Linux cooperation (Tier IV) [10 minutes]
  5. Mapping system and format (Apex.AI) [15 minutes]
  6. Autoware projects use case (Apex.AI) [15 minutes]
  7. Heterogeneous computing platform for Autoware (Linaro) [10 minutes]
  8. Velodyne VLS128 usage proposals (Tier IV) [5 minutes]
  9. TSC member FTE work (All) [15 minutes]
  10. Release naming [5 minutes]
  11. Simulator licensing (Apex.AI/LG) [Remaining minutes]

Action items

  • Review opinions on the tool chain and information provided by TRI-AD and make a decision on what to use
    • Geoff, Esteve
  • 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
  • Lead improvement of mapping format used by Autoware
    • Brian Holt (Parkopedia)
  • 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
  • Coordinate with Tier IV and Kalray to bring their work on algorithm acceleration into the computing platform effort
    • Yang
  • List planned contributions that go towards Foundation work and can be used to meet the milestone demos (once decided)
    • All premium members
  • Follow up with premium members who have never attended a TSC meeting
    • Yang
  • Hire a lawyer with experience in open source licenses to look at licenses for all potential simulators
    • AWF board

Detailed minutes

1. Opening remarks and new member introductions (Board)

Nothing in particular.

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

Autoware.AI

Autoware.Auto

3. Autoware.Auto toolchain (Tier IV/Apex.AI/TRI-AD)

We need to settle on the tool chain to be used by Autoware.Auto for development. This encompasses tools used for management of the development, tools used by the open community for accessing the source code, filing bugs, and making contributions, and tools used for quality management.

There are several options being considered. Whichever one we choose, the AWF will need to pay for the cost of use.

1. GitLab

  • Covers repository, issues, task management, CI
  • Currently used by Apex.AI’s initial project setup
  • Cost-prohibitive and pricing model is not compatible with an open project.
    1. Special program for Non-Profit Organizations
      https://about.gitlab.com/solutions/open-source/
    2. We may qualify for this despite the rule against making money because the foundation itself is non-profit.
  • Apex.AI has experience with this toolset.

2. GitHub + Azure DevOps + Azure Pipelines

  • Esteve (Apex.AI) has experience with this toolset.
  • Use of GitHub maintains the existing Autoware community and keeps us close to the existing ROS community.

3. GitHub + JIRA + GitLab CI all running in AWS

  • TRI-AD proposes this. They are willing to maintain it.
  • Use of GitHub maintains the existing Autoware community and keeps us close to the existing ROS community.
  • JIRA is very powerful for managing complex projects.
  • JIRA can integrate with GitHub such that the average user won’t need to touch it (we can limit it to maintainers only), so they won’t need to see a complex tool and can work through the GitHub interface.
  • GitLab CI is a good tool and integrates well with GitHub

4. GitHub

  • Use of GitHub maintains the existing Autoware community and keeps us close to the existing ROS community.
  • No CI tool of its own.
  • Task management tools are poor; the best third-party replacement (waffle.io) is shutting down in May.

Discussion

  • Linaro: How will we deal with ARM-native CI?
  • TRI-AD is going to talk to a GitLab rep about costs; Apex.AI to join that meeting.
  • TRI-AD wants the decision to be based on the merits of the tools rather than the need to maintain it or not; they will do any setup and maintenance we need.
  • TRI-AD has put together a document describing their work on tool chains based around infrastructure-as-code.
  • Esteve is concerned about JIRA being an entry point for users; it’s fine for management but it’s too much for the average contributor. The Apache Foundation used to use it, but everyone hated it and as soon as the foundation allowed Github use, everyone moved there.
  • Dejan feels that option 3 is the worst option because of the combination of tools due to the issues syncing between tools. For example syncing between GitHub and JIRA issues is nearly impossible because of the different semantic models. Also problems switching between tools for different tasks.
  • Dejan has found that Gitlab (used alone) has produced the happiest engineers.
  • AWF board states that they are happy to cover CI cost, but would like a member to cover other costs if possible.
  • Decision: Geoff and Esteve to make final decision next week based on discussion.

4. Automotive Grade Linux cooperation (Tier IV)

  • Tier IV met the Linux Foundation people responsible for their Automotive Grade Linux project recently.
  • They have had success in producing a stripped down Linux for use in the entertainment stack in cars.
  • They are starting their next two projects now:
    • The instrumentation stack.
    • Unified Autonomous Driving Platform (UADP).
  • They want to cooperate with Autoware and Apollo.
  • UADP has significant involvement from Toyota, Honda, Mazda, Suzuki and Subaru. Volkswagen Group and Hyundai have just joined. Component suppliers such as Denso, Harmin and Panasonic are also involved.
  • Non-traditional companies are also involved, such as Amazon Web Services and Adobe.
  • Two expert groups currently working:
    • Vehicle to cloud, working on over-the-air updates, map provisioning, etc.
    • Vehicle to road infrastructure, working on smart infrastructure.
  • They are also related to/involved in/running ELISA, the project to produce a safety-certified Linux.
    • BMW and Toyota are major supporters of ELISA.
  • The Linux Foundation and the AGL project want an improved method for certifying open-source software. They believe ISO 26262 is out of date.
    • Tier IV is interested in coordinating on this for use for Autoware.Auto.
    • Probably TRI-AD is as well.
  • They will consider if AGL should join the Autoware Foundation in the summer, once they have figured out their concrete project goals.
  • The Autoware Foundation needs to decide if it wants to join the Linux Foundation and participate in AGL and ELISA.

Discussion

  • ARM, Linaro, TRI-AD, Tier IV and Kalray will coordinate on working with their safety-critical efforts.

5. Mapping system and format (Apex.AI)

Apex.AI:

  • I recently talked to several mapping providers: Atlatec, Mandli, Carmera, Parkopedia (Parkopedia in the TSC). Between them Atlatec and Mandli already provide maps as Lanelet2 format and Carmera also is thinking about trying to do that.
  • I also concluded, after talking to some mapping experts, that this is currently the best technical option.
  • On the other hand, Tier IV is creating a Lanelet2 to Autoware vector map format translator (in their recent work for AutonomousStuff at least).
  • So I feel that we are getting enough traction between mapping players such that they would finally all converge to a common format.
  • But we need someone in the AWF to a) make sure that Lanelet2 is really ok, b) to then come up with the plan and c) to start integrating this into Autoware.
  • Questions:
    • So Brian do you have time to start driving this?
    • Are you in a position to talk to above players since potentially you are competitors? Then I can also introduce you.
    • Shinpei, Geoff are you OK to start ditching vector map in favor of something that others use (e.g. Lanelet2)?

Discussion

  • Apex.AI had a lot of problems with the existing Autoware format, for things like not being able to represent certain features, and being inefficient at runtime.
  • We need someone from the TSC to take on management of the mapping format stuff.
    • Shinpei proposes that Parkopedia takes the lead, due to it being their core competency, and Tier IV provides back up due its experience with mapping.
  • Tier IV and AutonomousStuff have got Lanelets2 working with Autoware. OpenDrive is already supported.
    • Dejan is concerned that this support is only a translator, not using the Lanelet2 format as core.
    • Shinpei thinks that being based on open standards is good, but Lanelet2 has information in it that Autoware does not use. So Lanelet2 is a good frontend but we need to figure out how it will be used internally.
  • Mandli is probably going to join the AWF, so they may be able to contribute to this work.
  • Decision: Brian Holt will be lead and final decision making power on mapping formats.

6. Autoware projects use case (Apex.AI)

Apex.AI

  • Several AWF partners are working on the use cases/demos. For instance:
    • AutonomousStuff/Tier IV on City-pilot
    • Parkopedia/StreetDrone/Apex on Autonomous Valet Parking
    • TRI-AD on autonomous shuttles/taxis?
    • Tier IV on CES demo
    • AutoCore/96Boards/Robosense autoware demo on heterogeneous platform (<20 km and avp)
  • It would make sense to focus on one use case where at least the compute ECU and sensors are unified. This will make us faster and allow us to build a really good foundation to then expand into other use cases
  • Can we agree on one use case and all work towards it?

Tier IV

  • When ROS 1 was first being developed Willow Garage put significant effort into achieving a series of specific, well-defined use cases, the peak of which was the PR2 running a marathon. The recent ROS 2 user stories report identified that the lack of such milestones has hampered development and marketing of ROS 2 - without an eye-catching demo it is harder to demonstrate to users that ROS 2 is robust and useful and mature enough. Autoware must avoid falling into the same trap for Autoware.Auto. Having a single use case at a time that all of us are working toward would unify resources and improve quality.
  • We need a series of increasingly complex, capable and robust use cases that each builds on the previous to demonstrate improvements in capabilities and robustness. The initial set of milestones proposed by Apex.AI is a good starting point.
  • If we can publish these milestones and hold public demos when they are achieved, this would be good marketing.

Discussion

  • Apex.AI, Parkopedia and LG want to focus on closed environments (valet parking) as the first goal. Tier IV has worked on this area already, so probably interested. StreetDrone also has a project similar to the valet parking demo so probably interested.
  • AutonomousStuff wants to stay on the public roads of their CityPilot project.
  • TRI-AD does not necessarily want to stay on public roads; it would be nice but they are happy to scale down if necessary. Having something that works end-to-end is better than having a specific use case.
  • Decision on approach to demos: While we cannot stop companies doing demos they want for non-Foundation work, for Foundation-oriented work the Willow Garage-style approach will be adopted.
  • Decision on demos to do is deferred to next meeting (Geoff to produce proposals).

7. Heterogeneous computing platform for Autoware (Linaro)

96Boards Automotive - Heterogeneous Computing Platform.pdf (312.7 KB)

Discussion

  • Tier IV is also working with Kalray on acceleration and parallelisation of algorithms.
  • Tier IV can provide hardware logic (FPGA implementations) for some algorithms, such as MVP and Yolo, which uses much less power than GPU-based implementations.
  • Yang feels that Tier IV’s work on accelerating the compute aspects is complimentary to their work on the ECU.
  • Shinpei wants to get his university (not an AWF member) involved in the work on algorithm acceleration.
  • Stephane: What use case is the computing platform project working on?
    • Linaro: Parking and street driving. Minimum 40km/h driving. This is driving the necessary sensor and computing capabilities.
  • Decision: Yang will be leading this effort.

8. Velodyne VLS128 usage proposals (Tier IV)

Tier IV has a Velodyne VLS128 available for use by the foundation. What should we do with it?

Discussion

  • Linaro: If ROS driver and Autoware integration is ready and no one else is applying for then we can use it for demo in China in May probably more realistic
  • Apex.AI: Please mount it and drive around, then provide the data.

9. TSC member FTE work (All)

Apex.AI

  • What do FTEs from TSC members work on? A while ago there was a following suggestion being made:
    • AS/Street Drone provides vehicle, urdf, dbw, testing on parking lots
    • AutoCore provides a target ECU NOT including BSP and OS - to be confirmed
    • Linaro working on aarch64 CI for Arm native development, testing, vehicle interface
    • LG provides an integrated simulation environment with the car and the parking lot world model
    • Arm provides security
    • TRI-AD provides data storage in the cloud and data labeling services
    • Parkopedia provides map of the parking lot
    • Velodyne provides a vlp128 sensor
    • Apex and Tier IV provide all other SW

Tier IV

  • When we spoke to the Linux Foundation about the Autoware Foundation, something they very strongly insisted on was that using FTEs as a measure of commitment to the foundation and/or as a way to pay for membership is a very bad idea. They stated that they used to use this approach, but ran it as an honour system at first. When they started trying to track it, they found that it was very hard to accurately track, and more importantly, most members were not actually providing the FTEs they had promised.

Discussion

  • Apex.AI feels it is time to start tracking results of FTEs, such as code.
  • Tier IV proposes assigning member companies to specific projects.
  • There are two or three companies who are premium members who have never joined the TSC meetings, so are they actually contributing?
    • Yang to find out what these companies are doing.
  • LG wants to confirm the parking lot and the car to be used for the valet parking demo so they can produce an accurate simulation.
    • Esteve and Geoff to coordinate this.
  • Decision: Each company that is supposed to contribute FTEs to bring to the next TSC meeting their proposed contributions so they can be presented, discussed, and agreed upon by the board.
    • The proposed milestones need to be taken into account. Contributions should be related to the Foundation’s work and goals on these milestones.

10. Release naming

  • We could consider giving each release of Autoware.Auto a name, similar to ROS and Ubuntu release names.
  • Options proposed include famous car models, famous racing drivers, and car parts.
    • The first two may be legally problematic.

11. Simulator licensing (Apex.AI/LG)

Questions from Apex.AI regarding the LGSVL simulator and its license (https://github.com/lgsvl/simulator/blob/master/LICENSE)

  1. It seems that if we want to use LGSVL free of cost (i.e. the Personal tier), it’s only possible if the company/organization that develops it has a revenue of less that 100K a year (https://store.unity.com/compare-plans). If the simulator were to be developed under the umbrella of the Autoware Foundation, we’d have the problem, since its finances exceed 100K.
    LG: We hope that in the near future there will be no need to modify the code of the simulator. In cases when it is necessary - it is allowed to modify the code. To build the Simulator Free Personal license can be used if company revenue is less than 100K, $25-$35 per month Plus license if revenue is $100k-$200k or Pro license for $125 per month without any restrictions
  2. It seems that the license has certain limitations that make it not open source (e.g. it restricts use to ROS1 and ROS2 only ("(1) build source code or use binaries with ROS1 and ROS2 systems"), forbids reverse engineering, etc.).
    LG: Original intention was to say “ROS1/ROS2 based system”, whole clause could be removed after next license review.
    Apex.AI: This is unclear and it is hard to define what a ROS1/ROS2 based system is. e.g. what about rosjava, which is effectively a port of ROS1?
  3. Do the assets you provide have a separate license? Is it Creative Commons or an open source license?
    LG: No. Assets created by LGSVL are distributed under the same license. Not all assets in the repository are created by LGSVL.
  4. This sentence in your license: "Your goods and services (“Product”) integrated with the Licensed Materials may be publicly demonstrated or exhibited for non-commercial purposes": this means that an AWF member could NOT take e.g. https://gitlab.com/AutowareAuto/AutowareAuto/tree/master/src/drivers/velodyne_node, integrate it with lgsvl simulator and show the resulting point cloud at CES and try to sell it?
    LG: This use-case might be not the best to represent the problem. velodyne_node integration does not require any modification of the simulator. There is no any direct commercial purpose (related to simulator) in showing the simulator. Actually license means - we would like you to show simulator, if you are not charging for tickets (like in circus). You can generate data, build your product and use your product for commercial purposes by demonstrating it together with simulator.
  5. "(3) application only to files created by LG, skipping default assets and code provided by Unity3D as project scaffolding" => how can one in this case self integrate a map that e.g. Parkopedia did?
    LG: You can integrate the map and use it for development and distribute for free to customers, just do not sell maps without separate agreement.
  6. "application to 3D assets" - what does this mean?
    LG: Context is a bit lost without a full sentence here, but that means assets created by LGSVL are following the same license as the code, created by LGSVL.
  7. “This Agreement governs the use of the confidential, non-public, pre-release LG Simulator Software (the “Software”)” - I am not sure why words confidential and non-public are here? Isn’t everything in https://github.com/lgsvl/simulator non-confidential and public?
    LG: I believe this is a standard header, will be removed.
  8. The license refers to a PRE-RELEASE (section 1.1).
    • When will there be a final release?
    • What will be the license of the final release?
      LG: We did not make product release yet. Decision for the release will be done based on set of features available in the simulator by default. There is a development plan for at least 1-1.5 year. After release some new features might be developed as premium.
  9. "irrevocable license solely for the purposes of internally using, testing, evaluation, simulation and validation of the Licensed Material (the “Purpose”)" vs what is further below: Notwithstanding the above, Your goods and services (“Product”) integrated with the Licensed Materials may be publicly demonstrated or exhibited for non-commercial purposes => these are 2 conflicting statements.
    LG: Maybe we need to review this paragraph and simplify.

Comments from LG

  • LGSVL wants to offers AV simulator for Autonomous Development for free
  • LGSVL intention is to help Autoware Foundation with development process while keeping an opportunity to offer additional premium features in the future (possibly running simulation in the cloud as a service). As a ATF member LGSVL commits resources to provide foundation the best possible simulation tools for free and make sure there are no impediments for using it. Licence limitation are only related to immediate commercial usage: aka selling modified version of simulator or related derivative work (data, models and etc.) See LGSVL Simulator License Terms.
  • LGSVL will review current license agreement and use own legal adviser to make sure current license is FULLY reflecting intentions.
  • See also proposed modifications and clarifications to the license agreement: https://drive.google.com/open?id=1ILUKx97icpS2Hif8T3JfyF4AHsUkbMJN

Discussion

  • LG wants to support developers of autonomous driving systems, but also make sure they have a way to monetise in the future. LG feels that offering the simulator to developers now is important to enable future monetisation.
  • LG had ideas for what they wanted to achieve, and they asked their legal team to produce a license agreement that enabled them.
  • LG wants people to use the simulator freely except for changing it. They intend for things like maps and so on to be completely changeable without needing to change the simulator itself.
  • LG does not want people selling data generated from the simulator, such as LIDAR scans and simulated camera images. However, this does not extend to works produced using the simulator, such as DNN trainings.
  • LG believes that the Autoware Foundation is about making the self-driving stack, not the simulator, so they want to keep any potential commercial uses of the simulator for themselves.
  • Apex.AI: Why not just use an existing open source license? Using a custom license means that the foundation has to spend money and time getting a lawyer to check the license is OK. We want to use the simulator and LG wants the foundation to use it, so using an existing license would make it easy for all concerned.
    • LG: Because LG management believes there is a future for the simulator. If they choose the wrong open source license, the project might become unfundable. Most of the tools used and especially the game engine at the core of the simulator are expensive.
    • LG is interested in hearing about existing licenses that may achieve what they want but also be easily accepted by users.
  • Apex.AI: The license is not open source. It is shared source.
  • LG: We want people to use the simulator, but we want the right to decide how people make money from it.
  • The reason LG wants to distribute the code is because they believe that users being able to look at the code and understand how it works (and why it may not be working the way they expect) is important.
  • Dejan: The AWF needs to be protected against violating license terms they don’t understand.
  • Shinpei: We need to understand what LG intended, so they need to provide that information and answer the above questions by text. We also need to understand if the license is usable by the AWF.
  • Decision: The AWF will be getting a lawyer with experience in open source licenses to look at the licenses of all proposed simulators and tell us what we can and cannot do with them.
2

4 posts were merged into an existing topic: Autoware Foundation premium member contributions