Autonomy Software WG Meeting 2022/04/26

[BonoloAWF]

Administrative

• Previous Meeting Minutes

Attendees

Chaired by Fatih

• Alan
• Bonolo
• Berkay
• Beyza K
• Beyza N K
• Chenying
• Esteve
• Fatih
• Gizem
• Haoru
• Jian
• Jianhua
• Kaan
• Maxime
• Mehmet
• Mert
• Melike
• Naoyori
• Norah
• Piotr
• Plane-li
• Ryohsuke
• Sena
• Shark
• Songsj
• Xinyu
• Zeynep

Common Resources

• Bus ODD software architecture proposal
• Bus ODD architecture design discussions
• Bus ODD candidate simulator comparisons
• Bus ODD milestone development plan
• Autoware contributors list

Announcements

• Please ask questions on Discussions Q&A and not on Discord or Slack.
• If you have any demos, showcase them on Discussions show and tell.
• If you create an issue, assign the appropriate labels to it so that people can easily use the filter function. Use the help wanted label if you are looking for people to work on the issue.

Autoware.Auto

• Updates on bug fixes and documentation bugs
• Release of Autoware.Auto v2.0.0

Autoware.Universe

• Bus ODD issues
• Autoware.Universe reported bugs
• Autoware design discussions

Discussion topics

Presentation from TierIV

Topic: Details of the planning module and a deep dive into the code structure and configurations used.

The presentation was a deep dive of the Tier4 planning documentation. Full details are in the recording, a summary is provided below:

• the planning module focuses on navigating to a goal, avoiding collisions, following traffic rules
• the planned trajectory should be feasible for execution by the control module
• use cases include lane change, parking, turning at intersections etc.
• Input: lanelet2 map, detected obstacles, goal position
• Output: trajectory and turn signal (where necessary)
• Autoware state monitor system module handles the current states
• scenario planning generates local trajectories based on scenario selector (high level ODD use cases such as parking, on-road etc.)
• parking is a free space planner implementation
• lane driving incorporates traffic rules via behaviour planning (rough trajectory with constraints); motion planner generates the feasible output trajectory. The output is smoothed via the motion velocity smoother.
• behaviour planner passes a reference path to one of the supported behaviour modes (free space, side shift, pullover, lane following etc.). Only static obstacles are currently supported.
• side shift sends a path via the safety driver (it is like a simple remote control to avoid obstacles). The algorithm implementation is a behaviour tree which allows for simple modification to use your own policies (use cases).
• details for how the actual trajectory is calculated (and the params used) are documented in the Behaviour Path Planner section of the docs.
• velocity planner calculates maximum speed based on traffic rules. First a reference velocity is generated which is later smoothed out. Modules include blindspot, intersection, detection area, occlusion spot. Implementation details can be found in the Behaviour Velocity Planner section of the docs.
• the behaviour planner selects modules to run individually based on the scenario. The behaviour velocity planner runs through the modules sequentially
• in Autoware the scenario_module_interface.hpp should be used to implement your own scenes https://github.com/autowarefoundation/autoware.universe/tree/main/planning/behavior_velocity_planner/include/scene_module
• motion planning optimises the shape to generate a smooth path, taking into account the cost map for obstacle avoidance.
• velocity motion smoother applies external velocity limit, stopping velocity limit, lateral acceleration limit, resamples the trajectoy and smooths the trajectory.

Shark - it's a good idea, like Fatih said, to output an Autoware state msg reporting which scenario is being used and why the vehicle stopped. Ryohsuke - currently we are not sure what kind of message type to use. It would be helpful to define a common interface for providing planning diagnostics.

Action Items

1. @armaganarsln to create a Discussion for investigating radar in Autoware when he receives a new radar from SmartMicro
2. @xmfcx to create an issue to test the existing lidar-only perception pipeline with the data provided Collect raw sensor data to test sensor drivers autoware.universe#562 (comment)

Review of Issues and Discussions

The following Issues and Discussions were reviewed (see comments for details):

• Evaluate performance of localization pipeline autoware.universe#602 - Xinyu is working on evaluating localisation pipeline with KITTI. We need to define the best metric for evaluation. A map can be created from the groundtruth data and NDT can be used to localise against it.
• Add another crop_box_filter node autoware.universe#703 - in progress
• The output of the gnss_poser package is not suitable for ekf autoware.universe#800 - a new msg that contains covariance may be required. This is related to Return error value at unknown operation key receieved #216
• Add linear interpolate mode Switch #215 - new contributors from AutoCore
• Runtime Manager, fix func overwrite at dialog close #214 - demo showing differential drive robot with Autoware