Software WG Meeting 2024/11/12

[xmfcx]

Common Resources

Click to expand 🖱️🔛

• Past Meeting Minutes
• Software Working Group Project Board
• Autoware Contributors
• Autoware Foundation Events Calendar
• Discord Server Invite Link

Attendees

Click to expand 🖱️🔛

Announcements

• We'll propose to the TSC to merge the following groups into the Software Working Group until demand supports reactivating them:
  • Localization & Mapping WG
  • Sensing & Perception WG
  • Planning & Control WG

Updates from developers

• docs: fix links to design documents autoware.universe#9301

  • We should move the rviz plugins to tools repos to shrink the CI image.
  • fix: fix ticket links to point to https://github.com/autowarefoundation/autoware.universe autoware.universe#9304
  • chore: remove tvm_utility artifacts from Ansible tasks #5427 (tvm is completely removed now)

• Basic CI has been ported to Core

  • https://github.com/autowarefoundation/autoware.core/tree/main/.github
  • https://github.com/autowarefoundation/autoware.core/pulls
    • The remaining CI items will be merged as the first package comes through (to have something to test with)

• https://github.com/autowarefoundation/autoware.universe/blob/3a92654309cc68cddd3b5c686352af522b1d4fc7/planning/behavior_velocity_planner/autoware_behavior_velocity_planner/test/src/test_node_interface.cpp

Core transition

• Don't allow internal dependencies from outside organizations. (tier4_*_msgs)
  • autoware_internal_msgs
  • Let's add more sub-packages to autoware_internal_msgs
• https://github.com/ANYbotics/grid_map/tree/master/grid_map_msgs/msg
  • We can keep other dependencies as they are (as long as they are in the ros build farm)
• Duplicate the packages with autoware_core_ prefix? Options:
  • autoware_ and autoware_core_ packages at the same workspace
  • Maybe port some packages as they are, port some as duplicated and core prefixed?

[mitsudome-r]

I'm working on Autoware Core implementation(discussion link), and I wanted to discuss about the following items:

Dependency to tier4_*_msgs
Should we consider removing the dependency to tier4_*_msgs and create a new package like we did for autoware_internal_msgs? It was okay for Universe packages that has TIER IV as a codeowner to be depending on their messages, but since Autoware Core is maintained by AWF, I was thinking maybe we should remove the dependency. We are also using grid_map_msgs and nav_msgs for some communication within Autoware, I would like to clarify our policy with them as well.

Package naming
We are currently using autoware_ prefix for Autoware Universe packages. I was wondering if we want to use different package prefix for Autoware Core (something like autoware_core_ or aw_core_). Some packages need refactoring (e.g., ekf_filter) to make it more stable or simpler during porting, and it might be better to create it as a different package name to avoid name conflicts with the packages in Universe.