Autonomy Software WG Meeting 2022/04/19

[BonoloAWF]

Administrative

• Previous Meeting Minutes

Attendees

Chaired by Fatih

• Ambroise
• Bonolo
• Beyza
• Berkay K
• Berkay N K
• David
• Deepak
• Evshary
• Esteve
• Fatih
• Goktug
• Haoru
• Jian
• Kaan
• Maxime
• Mark
• Mehmet
• Mert
• Melike
• Norah
• Piotr
• Plane-li
• Ram
• Ryohsuke
• Sena
• Shark
• 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.

Presentation is moved to next week.

Action Items

1. @mitsudome-r to contact NE Raptor developers to discuss https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/1102
2. @armaganarsln to create a Discussion for investigating radar in Autoware when he receives a new radar from SmartMicro
3. @Sharrrrk to provide driver code and files (PCAP, pointcloud) for Ouster lidar sensor => Collect raw sensor data to test sensor drivers autoware.universe#562 (comment) Fatih - did you have any issues with the existing Ouster driver? Shark - so far no, we used the driver to record the ros2 data. Fatih - we can use these rosbag files to test the lidar only perception pipeline.

Review of Issues and Discussions

The following issues were discussed (see comments for details):

• Add another crop_box_filter node autoware.universe#703 - will be updated to include polygon footprint around the vehicle to remove points.
• Collect rosbag of sensor data for camera autoware.universe#680 - ADASTEC will test Autoware.Universe on their vehicle. We did not discuss collecting camera data. Blocked by #679 and hotfix a typo #677.
• Ground segmentation fails for points behind the low objects autoware.universe#669 - assigned to Piotr
• feat(control_performance_analysis): add new functionalities to evaluate the control modules autoware.universe#659 - in progress since acceleration info is expected from localisation
• Fix package name which has velodyne launch files #137 - ongoing

The following design discussions were had (see comments for details):

• Put vehicle model(default.dae, prius.dae) under ros/src/.config/model #150 - Esteve (E) - if we have a package that needs files from elsewhere is a different script required each time to download? We should standardize how we include external files. We should always store files in the same way. S3 has the advantage of not being limited by Github's file size restrictions but the disadvantage is that it is not part of the Git workflow. When people clone our repos they must type another command to get the file and users don't always read the docs. Fatih (F) - my final opinion is that we need a database to store models or pcd files. Something like a simplified version of Pytorch Hub. We can use an S3 folder structure to keep track of files and their versions. We can use git lfs for image files. What are your thoughts? E - let us stick to using one tool, users don't want to deal with different tools for different data. F - I was thinking we use git lfs for small binary files. Ambroise (A) - When a fork happens, lfs files are pulled from the main repository and hosted on the fork. F - in that case there is a cost for that fork. We could use lfs for everything and just pay the cost. Or use folders and links without lfs. A - we should start with a non git lfs solution so that the git history remains intact and later we could always switch to using git lfs. E - what about the pcd files? Will we write scripts to download them? F - it's just downloading a link so it's not that complex. Just wget commands. E - we have to integrate into our source tree. F - I think I can create a folder containing all the pcd files and people can download what they need. E - but pcd files are needed for the tests. F - yes, so we will need a script. The script in the MR is not just wget actually, there are several lines. E - I would prefer one script that works with different endpoints. F - do we want the user to download the NN in one command? We need to know how git annex works with forks and who has access to push files etc.
  Please comment on the discussion to add your opinions.

• Remove extra level of indirection from cuMemFreeHost #112 - Fatih (F) - is there an easy way to align the map and find the origin? Ryohsuke (R) - QGIS tools can work for that. We could maybe write instructions on TierIV side on how to do the geo-referencing manually. There should be a way to convert to a user defined origin as well.
  R - how can we share origin information across different packages? F - GNSS poser could have a subscriber so we can easily update the map origin. We could use a map origin msg for that.

• Develop multi lane #166 - we could have a list of primary topics we expect users to record when using Autoware. A GUI interface (similar to the runtime manager in Autoware.ai could be used).

• https://github.com/autowarefoundation/autoware/discussions/89 - we can create a poll on Discord to find who has experience with orchestrators and k3s etc.

[xmfcx]

@xmfcx create an issue to test the existing lidar-only perception pipeline with the data provided autowarefoundation/autoware.universe#562 (comment)