Skip to content

GitLab

Autoware Foundation
Autoware Foundation

ASWG minutes 20191127

Last edited by Geoffrey Biggs
Page history

Attendees

  • Geoffrey Biggs (The Autoware Foundation)
  • Esteve Fernandez (The Autoware Foundation)
  • Servando German (Linaro)
  • Brian Holt (Parkopedia)
  • Angelo Mastroberardi (Parkopedia)
  • Sandro Merkli (Embotech)
  • Ryohsuke Mitsudome (Tier IV)
  • Ben Murillo (Silexica)
  • Dejan Pangercic (Apex.AI)
  • Filipe Rinaldi (Arm)
  • Brian Shin (LGE)
  • Akihiko Tsukuda (eSOL)
  • Josh Whitley (AutonomouStuff)

Minutes Geoffrey Biggs

Action items

  • Set up native Arm CI at GitLab
    • Josh Whitley
  • Set up Arm runners in AWS
    • Filipe Rinaldi
  • Announce the release plan for Autoware.AI 1.14
    • Geoffrey Biggs
  • Circulate detailed architecture sketch
    • Dejan Pangercic
  • Fix integration problems between Autoware.Auto and LGSVL
    • Brian Shin, Sandro Merkli
  • Elicitate ROS 2 sensor driver status
    • Dejan Pangercic, Josh Whitley
  • Capture data from the AutonomouStuff carpark using available sensors
    • Dejan Pangercic, Josh Whitley
  • Get the physical properties of the car
    • Dejan Pangercic

Topics

CI on AWS

  • Committers for Autoware.Auto are setting up cross-compilation-based Arm runners for CI, but AWS has native runners available for arm64 and the AWF has credits that we can use for these.
  • These runners are only for arm64, and recently we had a problem in armhf that broke our packages on the ROS build farm, so we will still need cross-compilation-based CI.
  • Filipe will take the lead on setting up the runners.
  • Filipe to contact Esteve to get access to the credits account.
  • Josh will take the lead on the GitLab side.
  • Lanelets2 is broken on arm64 due to its automatic dependency creation by its mrt-cmake-modules CMake module.

Autoware.AI 1.14 release dates

  • With the release of Autoware.AI 1.13 fast approaching it is time to set the schedule for the 1.14 release.
  • Following the usual pattern, 1.14 should be three or four months after 1.13.
  • Need to avoid end of March or April due to AVP hackathon.
  • Need to leave enough space for MRs to be sent in, reviewed, and tested.
  • Release 1.14 on May 26th (Tuesday).
  • To allow two months for testing, alpha release should be on the 31st of March. Beta releases as appropriate between this and final release.
  • Merge request submission deadline on the 3rd of March.
  • Geoff to announce these dates.

Review of the Autonomous Valet Parking demonstration information

  • The Autoware Foundation's first short-term goal for Autoware.Auto is autonomous valet parking (i.e. self-parking) functionality.
  • A demonstration of this is planned for April 24th, 2020 in Palo Alto.
  • The activity of this working group for the next 6 months will dedicated to achieving this goal.
  • For more details, see the dedicated wiki page.

In-person planning workshop in Palo Alto

  • A workshop is planned for December 10th in Palo Alto to plan the work to be done for the AVP demonstration and design the architecture.

Hackathon information

  • In the week prior to the demonstration, a hackathon will be held at Apex.AI's office in Palo Alto, California. The purpose of the hackathon will be to polish the demonstration.
  • The hackathon will be held from April 20th to April 23rd.

Discussion on the AVP demo

  • Discussion over whether the Autoware.AI release dates and the hackathon clash, and if we should move the hackathon to after the Autoware.AI release.
    • It was decided not to change the dates as enough resources are expected to be available on both projects.
  • Current planned attendees for the planning workshop are:
    • Apex.AI (hosting)
    • LGE (Brian or Dmitry)
    • AutonomouStuff (Josh Whitley)
    • Parkopedia (remotely)
    • Embotech (remotely)
  • Apex.AI will produce a detailed architecture sketch and circulate this prior to the planning workshop.
  • Embotech is having trouble with integration of Autoware.Auto with LGSVL. LGE will help out.
  • Still missing pieces of the complete self-driving stack:
    • Integration (launch files, parameters, etc.) and automated/manual testing: Someone needs to write ROS 2 launch files for integrating the different parts of the pipeline and for the AVP demos. Someone needs to set up parameter configuration files correct for the hardware and application. Someone needs to write integration tests using the launch_testing framework.
    • Pose fusion (odometry and NDT): Someone needs to write a fusor node, e.g. an EKF pose fusor, either by porting the one from Autoware.AI or writing a new one. The fusion will not include the IMU data, just the odometry data and NDT output.
    • Tools and GUIs: Collecting rosbags, an easy way to store and download rosbags for debugging, an rviz setup for visualisation, etc.
    • Safety aspects (functional and operational): We need a safety plan and, hopefully, a safety case for the demonstration.
  • Since we will be targetting Eloquent for the demo, we need to:
    • Port Autoware.Auto to Eloquent
    • Get CI going for Eloquent
    • Decide if we should use XML or Python for our launch files; the XML launch files are quite limited in functionality compared to Python launch files
  • Silexica may be interested in taking on the integration task as it might fit with their goals for extending their own tool's demo. They will make a decision in the next few days.
  • The Apex.AI car (Lexus SUV) has two Velodynes, a very expensive GPS, and an Xsense IMU. They already have a URDF description of the car and sensors and a mesh for simulation/visualisation. It uses an automatic transmission and has a drive-by-wire interface from AutonomouStuff. It can autonomously shift between drive and reverse.
  • Apex.AI (Dejan) and AutonomouStuff (Josh) to find out which ROS drivers for sensors are available, then gather data in the AutonomouStuff carpark using them.
  • Apex.AI (Dejan) to get the physical properties of the car, or AutonomouStuff (Josh) if they cannot.
  • Parkopedia is best positioned to provide the safety case.
  • We need to define in detail the AVP application requirements, and how we will specify where to drop off the car, where to park, etc.
  • The ISO standard for AVP that is under preparation is focused on the relationship between the various actors in the AVP application, such as the vehicle and the traffic management system, to manage things like knowing if a vehicle can fit in a carpark, if there is a space available, where it is, etc.