Technical Steering Committee (TSC) Meeting #12 Minutes

Autoware
1

Wednesday, November 20, 2019 10:00 PM

Attendees

  • Geoffrey Biggs (AWF/TSC leader)
  • Kenji Funaoka (Tier IV)
  • Servando German (Linaro)
  • Brian Holt (Parkopedia)
  • Dan Isaacs (Xilinx)
  • Shinpei Kato (AWF board)
  • Kasper Mecklenburg (Arm)
  • Nikos Michalakis (TRI-AD)
  • Martins Mozeiko (LGSVL)
  • T. Otake (Macnica)
  • Dejan Pangercic (Apex.AI)
  • Rathour Swarn
  • Daisuke Tanaka (AWF Administrator)
  • Akihiko Tsukuda (eSOL)
  • Josh Whitley (AutonomouStuff)
  • Dmitry Zelenkovskiy (LGE)

Minutes Geoffrey Biggs

Agenda

  1. Opening remarks and new member introductions
  2. Admin Confirmation of previous minutes
  3. Follow-up Action items from previous meeting
  4. Project managers listing (@gbiggs, @esteve)
  5. Autoware Meetup @ CES2020
  6. Autoware Workshop at IV2020
  7. Report of Autoware-related activities at ROSCon 2019
  8. Tier IV demo space at the Tokyo Olympics
  9. Contributions of foundation members
  10. Working group report Autoware (@gbiggs, @esteve)
  11. Working group report Map formats (@Brian_Holt, @mitsudome-r)
  12. Working group report ECU/Platform (@sstrahm)
  13. Working group report Simulation (@bshin-lge, @hakuturu583)
  14. Suspending the Simulation WG (@gbiggs)
  15. Working groups names and meeting times (@gbiggs)
  16. Autoware.Auto hackathon commitments (All)

Action items

  • Follow up on why StreetDrone’s and ITDLab’s new representatives are not in the TSC meetings
  • 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

Detailed minutes

Opening remarks and new member introductions (Board)

  • No new members this time.

Confirmation of previous minutes (All)

  • Minutes approved.

Action items from previous meeting (All)

  • Release the safety case example
    • @Brian_Holt
    • Action taken Just needs to be signed and put up on the website. However it will not be released under a CC license. Should be up some time in the next week or so.
  • Create working group wiki pages
  • Review the notice proposed to be added to the safety case example documents
    • All
    • Action taken Reviewed and accepted.
  • Follow up on the use of the reference platform hardware in the AVP demo
    • @sstrahm
    • Action taken AVP demo team will not use reference platform hardware for the planned demo; this does not preclude doing the same demo later on the reference platform hardware.
  • Provide a backup plan for the AVP demo’s ECU
    • @sstrahm
    • Action taken Backup plan is the existing ECU in Apex.AI’s car, and this has now been adopted.
  • Get a summary of the LGSVL license review conclusions and make it publically available

Autoware Meetup @ CES2020

  • CES 2020 will be held on the 7th to 10th of January in Las Vegas, USA.
  • Meetup open to Autoware Foundation members only.
  • If you haven’t received an invite, contact Daisuke Tanaka of Tier IV.

Autoware Workshop at IV2020

Report of Autoware-related activities at ROSCon 2019

  • 600 in-person participants, 500 remote
  • 140 participants in the ROS 2 real-time workshop
  • 25 of 49 talks were about ROS 2. Another 10 talks were not ROS specific. ROS 1 is going EOL.
  • ROS community is focusing on building applications with ROS 2 since ROS 2 (core) has feature parity with ROS 1 (core)
  • Automotive companies present: Cruise, AID, Voyage, Bosch, Renesas, Continental, …
  • The Autoware Foundation (@gbiggs and @esteve) gave a presentation about the plan for the transition to Autoware.Auto.

Project leaders listing (@gbiggs, @esteve)

  • Currently the Autoware Foundation’s website lists premium member company representatives and board representatives in the TSC section.
  • Should this listing also indicate who are the project leaders for Autoware Foundation projects?
  • Currently clearly-defined leaders:
    • Autoware.AI/.Auto: Geoffrey Biggs, Esteve Fernandez
    • Autoware.IO: Yang Zhang
  • If these are listed, are they separate seats from company representatives, or just an additional role taken on by company representatives?

Discussion

  • AS: Worth recognising the project leaders, but we don’t need a whole separate section.
  • AS: If they are leading a project, they probably should be TSC members already.
  • Parkopedia agrees.
  • Decision: Just list the position.

Working group report Autoware (@gbiggs, @esteve)

Autoware.AI

  • New features merge deadline for 1.13 has passed and most features made it in.
  • Some features had to be pushed back to 1.14:
    • Reverse driving
    • Protective areas
  • 1.13 alpha1 has been released (thanks to Josh from AutonomouStuff)
  • Tier IV is conducting some light testing this week
  • We are aiming for beta1 by the last week of November
  • There are 30 MRs being held for 1.14, and that number is growing every day
  • There is 1 MR for 1.13 that is still to go in (this is a planned delay; the feature relates to visualisation)
  • There are 6 bug fix MRs waiting to go into 1.13.
  • Still on track to make the planned release date in December.

Autoware.Auto

  1. IMU/GPS driver merged: Initial Xsens driver and tests (!87) · Merge requests · Autoware Foundation / Autoware.Auto / AutowareAuto · GitLab
  2. Pure pursuit update:
    1. Control design document: Resolve "Revisit architecture for pure pursuit" (!80) · Merge requests · Autoware Foundation / Autoware.Auto / AutowareAuto · GitLab => merged
    2. Porting to Autoware.Auto Resolve "Implement pure pursuit" (!97) · Merge requests · Autoware Foundation / Autoware.Auto / AutowareAuto · GitLab => just merged
  3. PurePursuit MR brings in MPC repo, which in turn has:
    1. Helper functions (i.e. time conversion)
    2. Lots of project scripts–can be treated as “best practice” examples for future developments:
      1. A primitive .gitlab-ci which can be useful for starting up a federated model
      2. Helper scripts for enabling every possible warning and free static checker under the sun–for hopefully better quality open source projects
      3. Each package is an example on how to use ament_auto, which should make build scripts much more terse
    3. Controller and Planner base classes to facilitate future developments in those areas, and hopefully serve as patterns for other algorithm families
      1. The controller base class is pretty mature
      2. The planner base class is a bit of a WIP
    4. MPC implementation:
      1. A rather mature controller implementation (with parameterized and typed test patterns they can look at)
      2. A proof of concept planner implementation
      3. Helper scripting to facilitate the implementation of other MPC-based algorithms
  4. Vehicle interface:
    1. We should have an instantiation of the vehicle interface for LGSVL in the coming weeks
    2. 2 design documents, a failure analysis, and a “literature” review are in MRs
  5. Parkopedia is proposing a generic PID controller.

Working group report Map formats (@Brian_Holt, @mitsudome-r)

  • An example maps is available for use in OpenStreetMap XML Lanelet-flavour
  • Path planning using Lanelets works on this example
  • http://avp-project.uk/downloads
  • There is also a blog post that shows how to do path planning using this map
    • This is not a global planner but a lane-level planner. It gives you a centerline that can be followed.
    • Unfortunately there is a still a bug in planning a path that goes up ramps in multi-story carparks.
  • Two other maps are also available (NTP London Bridge and some other carpark in the UK) but they still have some bugs.
  • The Lanelet work is not relevant to global planning, which needs to operate at a higher level of abstraction.

Working group report ECU/Platform (@sstrahm)

  • 2 major calls done in two sessions each (NA/EMEA + APAC/EMEA), minutes in Gitlab

  • Very first Reference Platform, meaning the vector to help on its creation, the PCU from Autocore has been demonstrated at ROSCon and presented in China during the first Autoware Meet-up (thank you @Chen)

  • Description of the PCU pointed to on WG page: PCU Autocore

  • Participation to WG call has been limited…

  • Progress:

    • The Working Group is sketching its goal
      • Managed by the foundation, the WG will define the specification for creating Hardware Reference Platform allowing integration of Autoware software for evaluation, customization, preparation to production to users
      • Specification will cover: Collection of requirements defining the Reference Design, Functionalities, Basic guidelines for design, Interfaces , Integration of software (relationship with Autoware.Auto), Integration of sensors (relationship with Autoware IO), Performance expectations, Available through AWF
    • Categorization on Requirements to be covered
      • Sensors, Hardware for application, Hardware for acceleration, Drivers, Reference Design Configurations (Demo), Performance expectations / guidance, Software integration, Safety, Security, Simulation, Testing, Documentation, Support (to be defined)

  • Open Questions to TSC

    • Re-naming of the Working Group
      • As the ultimate goal of the working group is not to create the reference, but to generate the Specification
      • Proposing to rename the group: Reference Hardware Design
    • Way of managing requirements to be established
      • Using first Gitlab
      • To align with TSC

Working group report Simulation (@bshin-lge, @hakuturu583)

  • No report provided.

Working groups review (@gbiggs)

The AWF working groups have been running for a few months now, so it is time to review and revise them.

The working groups are used by the AWF as a place for technical discussion that goes into details, in contrast to the TSC which is a place for reporting activities and deciding long-term goals and roadmaps. For a list of our current working groups, see the Autoware Foundation’s technical activities wiki.

Proposal 1: Suspend the simulation working group

There are several reasons for this:

  1. The working group does not have much apparent activity and its goals are unclear.
  2. The working group leaders are not active, with sporadic meetings, no agendas, no minutes, and the working group’s wiki page not filled in.
  3. Meeting attendence is in general very poor.
  4. We need to concentrate our simulation-related activities on the AVP demo, which we prefer to coordinate via the Autonomy Software W.
  5. There is a proposal to start a general ROS simulation WG (not under the AWF, but in the wider ROS community). Anything related to simulation that is not specific to Autoware can be discussed there.

Decision Will suspend the working group.

Proposal 2: Rename the remaining working groups

We need to rename the working groups to make their purpose clearer. Here is a proposal:

  • Autoware WG → Autonomy Software WG; responsible for leading and coordinating all software-related efforts, most importantly Autoware.Auto but also things like maps.
  • Reference platform WG → Autonomy Hardware WG; responsible for leading and coordinating all hardware-related efforts such as the computing platform.
  • Maps WG → Maps and routing WG; responsible for executing the plan for maps and routing, including designing APIs and producing reference implementations.

Decision All names adopted.

Proposal 3: Reschedule the meetings to be more fairly balanced to all timezones

The meetings are currently all scheduled in a way that does not encourage increased participation from Asia and in some cases just plain excludes certain time zones. The proposal is to switch all working groups to a rotating schedule that gives every time zone an even balance of good, OK, and bad times.

Here is a proposed schedule for the meetings that rotates through the timezones.

Decision Meeting times adopted (subject to verification with WG leaders)

Proposal 4: All working group meetings will be conducted via Zoom

The AWF board has approved budget to purchase licenses for a teleconference tool. This proposal is to use Zoom, as it is being used by most people (who are not using Google Hangouts) already. A license will be provided to each working group leader.

Decision All strongly in favour.

Autoware.Auto hackathon (All)

Overview

  • The goal of the hackathon is to polish off the Autonomous Valet Parking use case functionality and finalise getting it working on a real vehicle, followed by a demonstration using a real car.
  • To reduce scope and risk, the hackathon will concentrate on software and use Apex.AI’s existing car and platform.
  • The hackathon will take place in Palo Alto, California.
  • The development days will be hosted by Apex.AI.
  • The demonstration will be hosted by AutonomouStuff, and will use the carpark of their office.
  • See this thread for details.
  • This work obviously includes not just the hackathon itself but the work to be done leading up to it.

Date and schedule

  • The hackathon will take place in April, 2020.
  • The specific week is not yet decided, however a poorly-voted-on poll suggests that the week of April 6th is preferred. The final decision needs to be made by the TSC either today or via a vote in Discourse next week.
  • The hackathon schedule is:
    • Days 1 to 4 (Monday to Thursday): Engineering work at Apex.AI office (Palo Alto)
    • Day 5 (Friday): Demonstration at AutonomouStuff carpark (Palo Alto)

Operation

  • The work for the AVP demo leading up to the hackathon will be managed through the Autonomy Software WG.
    • The TSC will receive reports only. Those interested in technical discussion must join the Autonomy Software WG.
  • Monthly tech milestones will be set and committed engineers will be expected to meet them.

Commitments

  • These companies have already committed to providing engineering time and achieving specific engineering goals:

    • Apex.AI: Object detection, NDT localisation, MPC motion controller
    • LGE: Simulator and simulation of the AutonomouStuff carpark
    • AutonomouStuff: Vehicle control
    • Parkopedia: Carpark map and maps-related interfaces
    • eSOL: Wants to contribute but not sure what yet
    • Embotech (non-member): Planner
    • Silexica (non-member):

  • These companies have already committed to attending the hackathon in Palo Alto:

    • Apex.AI (hosting developer days): As many as needed, minimum 3
    • AutonomouStuff (hosting demonstration): 1 engineer
    • LGE: 2-3 people present while the hackathon is running to provide support
    • eSOL: 1 engineer

  • Missing pieces:

    • Integration (launch files, parameters, etc.) and automated/manual testing
    • Pose fusion (odometry and NDT) (what happened to the EKF implementation?)
    • Tools and GUIs
    • Safety aspects (functional and operational)

Planning meeting

  • Face-to-face one-day meeting in Palo Alto to:
    • Plan activities in detail over the next few months
    • Design the architecture
  • Proposed to be held by early December adjacent to the Autoware Meetup (10th of December)
  • Who can attend?
    • Apex.AI can (obviously)
    • LGE can
    • AS can
    • Parkopedia can’t in person
    • Tier IV will try to attend
  • May start really early in the morning PST to allow those from Europe who can’t attend in person to join remotely.

Discussion

  • First two weeks of April are Easter, so these two weeks are not likely to feasible. Need to choose between third or fourth week.
  • Parkopedia’s main contributor will not be available in the last two weeks of April.
  • LGE and AS do not seen an issue with the end of April.
  • Decision Date set to week of April 20th.
  • LGE needs urgent feedback about the AutonomouStuff carpark simulation environment they have created, particularly about precision and if it is sufficient to run the AVP demo.
  • LGE still does not have a physical dynamics model from AutonomouStuff or anyone else and they need one urgently. They have been trying with a simple model and without correct dynamics even simple parking a car is not possible.
  • Parkopedia will as CPC if they are willing to allow the AWF to use the safety case they have produced as a starting point for the AVP demo safety case
    • Apex.AI has a DMV-certified vehicle and licensed safety operators who will be available for the demo. They have done a similar exercise last year with Autoware.AI on public roads and consider the AVP demo to be significantly less risky.
  • Kalray is interested in contributing to the pose fusion.
  • The ASWG needs to consider how communication will be handled.

Contribution proposal from Tier IV

  • Tier IV: We are planning new contributions. We are creating a new architecture for Autoware that we will take to the Autonomy Software WG. Prototyping will be done at the end of February. It will take about a month to prepare an architecture design, so Tier IV will propose the new architecture at the end of April.

Discussion

  • Apex.AI: Will this work be contributed to the AVP demo?
  • Tier IV: This work will not be available for the AVP demo.
  • Apex.AI: Will this work be done in Autoware.AI or Autoware.Auto?
  • Tier IV: It will be contributed through the Autonomy Software WG. The implementation will be done in Autoware.AI because it is not suitable for Autoware.Auto, it is just prototyping. It will be made available to Autoware.Auto via the Autonomy Software WG.
  • Apex.AI: Aspects such as when to do memory allocation, which need ROS 2 features like the node lifecycle, will be hard to prototype in ROS 1.
  • Tier IV: We are first considering the algorithm aspects in the prototype, then we will move to ROS 2 through the Autonomy Software WG.
  • Apex.AI: We are moving ahead with the AVP application and not having Tier IV’s input in Autoware.Auto now is not helpful.

Tier IV demo space at the Tokyo Olympics

  • Delayed to next TSC meeting.

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?
  • Discussion deferred to next meeting due to lack of time.
1 Like
2

What types of vehicle dynamics information does LGE need for their simulator? I’m sure AStuff would be the preferred ones to provide that information, but if time is critical, I can provide the x,y centers of gravity for an AStuff outfitted Lexus RX450h, Ford Fusion, and Chrysler Pacifica. I have approximate vertical CGs for the Lexus and Ford. Additionally, I have the wheel base and, for the lexus only, a mapping of steering wheel angle to wheel road angle. This is all from measurements done by hand using measuring tapes and specialized 4 wheel scales.

3

@Dejan_Pangercic @JWhitleyWork Does @msmcconnell’s comment help you?

4

@msmcconnell

Hello. Currently LGSVL Simulator uses the open source vehicle dynamics model developed by Elements Design Group of San Francisco and the Jaguar Land Rover Open Software Technology Center here and values based on this. While the CGs, wheel base and steering angle are helpful, we need a more accurate complete dynamics model, e.g., FMU or C# system to help users control vehicles more accurately.

This is an example of our current parameters in engine.

LGSVLSimulatorSimpleDynamics
LGSVLSimulatorSimpleDynamics988Ă—1080 76.6 KB

Hopefully this helps. It would be great if we could host the AStuff team at our office to look at this more in depth.

5

Thanks for the details @ericboise, it looks like you need more specific information than I can provide. You can PM me if you still want the CGs etc. But I think it would be better if you could sit down with AStuff directly. Perhaps @JWhitleyWork could help coordinate that.

6

@ericboise I’ve contacted our Director of Engineering and our VP of Products and Services. We’ll get back to you directly once we’ve talked internally about how to best provide the data.