Reorganize the autoware.universe/common packages

[youtalk]

Despite the name "common," the autoware.universe/common directory contains many packages that are only used by specific modules.

Move these packages to specific directories to clarify dependencies and relationships. This is a preparatory step for multi-containerization.

Packages in autoware.universe/common:

• autoware_ad_api_specs
  • refactor(autoware_ad_api_specs): prefix package and namespace with autoware autoware.universe#9250
• autoware_auto_common
• autoware_grid_map_utils
  • refactor(autoware_grid_map_utils): prefix folder structure with autoware/ autoware.universe#9170
• [ ] autoware_mission_details_overlay_rviz_plugin
• autoware_motion_utils
• [ ] autoware_overlay_rviz_plugin
• autoware_path_distance_calculator
• [ ] autoware_perception_rviz_plugin
• autoware_point_types
  • refactor(autoware_point_types): prefix namespace with autoware::point_types autoware.universe#9169
• autoware_test_utils
• autoware_testing
• autoware_universe_utils
• [ ] bag_time_manager_rviz_plugin
• component_interface_specs
  • refactor(component_interface_specs): prefix package and namespace with autoware autoware.universe#9094
• component_interface_tools
  • refactor(component_interface_tools): prefix package and namespace with autoware autoware.universe#9093
• component_interface_utils
  • refactor(component_interface_utils): prefix package and namespace with autoware autoware.universe#9092
• cuda_utils
  • refactor(cuda_utils): prefix package and namespace with autoware autoware.universe#9171
• fake_test_node
  • refactor(fake_test_node): prefix package and namespace with autoware autoware.universe#9249
• geography_utils
  • refactor(geography_utils): prefix package and namespace with autoware autoware.universe#7790
• global_parameter_loader
  • refactor(global_parameter_loader): prefix package and namespace with autoware autoware.universe#9303
• glog_component
  • refactor(glog_component): prefix package and namespace with autoware autoware.universe#9302
• goal_distance_calculator
  • refactor(goal_distance_calculator): prefix package and namespace with autoware autoware.universe#9172
• interpolation
  • refactor(autoware_interpolation): prefix package and namespace with autoware autoware.universe#8088
• kalman_filter
  • refactor(kalman_filter): prefix package and namespace with autoware autoware.universe#7787
• object_recognition_utils
  • refactor(polar_grid): add autoware prefix to polar_grid autoware.universe#8945
• osqp_interface
  • refactor(osqp_interface): added autoware prefix to osqp_interface autoware.universe#8958
• perception_utils
• polar_grid
  • refactor(polar_grid): add autoware prefix to polar_grid autoware.universe#8945
• qp_interface
  • refactor(qp_interface): prefix package and namespace with autoware autoware.universe#9236
• signal_processing
  • refactor(signal_processing): prefix package and namespace with autoware autoware.universe#8541
• tensorrt_common
• [ ] tier4_adapi_rviz_plugin
• tier4_api_utils
• [ ] tier4_camera_view_rviz_plugin
• [ ] tier4_datetime_rviz_plugin
• [ ] tier4_localization_rviz_plugin
• [ ] tier4_perception_rviz_plugin
• [ ] tier4_planning_rviz_plugin
• [ ] tier4_state_rviz_plugin
• [ ] tier4_system_rviz_plugin
• [ ] tier4_traffic_light_rviz_plugin
• [ ] tier4_vehicle_rviz_plugin
• time_utils
  • refactor(time_utils): prefix package and namespace with autoware autoware.universe#9173
• traffic_light_recognition_marker_publisher
  • refactor(traffic_light_recognition_marker_publisher): prefix package and namespace with autoware autoware.universe#9305
• traffic_light_utils
  • refactor(traffic_light_utils): prefix package and namespace with autoware autoware.universe#9251
• tvm_utility
  • refactor(tvm_utility) prefix package and namespace with autoware autoware.universe#9241

[esteve]

@youtalk would it be useful to list the packages in common here so that we can check if they are truly "common" or can be moved?

[youtalk]

@esteve It's good idea! Please do it.

[esteve]

@youtalk I've updated the issue description with a list of packages from common

[esteve]

I think the rviz plugin packages can most likely be moved elsewhere, this would make the OpenAD Kit Docker base images smaller.

[youtalk]

Yeah, that's why #5076 was created.

[esteve]

@youtalk should the packages that have a tier4 prefix also have an autoware prefix? Or should they be renamed to only have autoware as their prefix?

[youtalk]

@esteve Thank you for your feedback.

@youtalk some of the packages in common are rviz plugins, I think it'd be best to move the plugins elsewhere so we can make a smaller base image for OpenAD Kit, I'm focusing on refactoring the packages (adding the autoware prefix) that are not rviz plugins

Exactly. I think it would be a good idea to move all the RViz plugin packages either directly under autoware.universe or under the tools directory.
@mitsudome-r @xmfcx What do you think?

@youtalk should the packages that have a tier4 prefix also have an autoware prefix? Or should they be renamed to only have autoware as their prefix?

For now, let’s keep the package names with the tier4 suffix unchanged.

[xmfcx]

I agree with moving them to reduce the base image size 👍

Some of the rviz plugins are crucial for running the Tutorials. (Basically any rviz plugin included in the main rviz config)

To alleviate this, we can first update the docs and then move.

Actions:

1. Update https://autowarefoundation.github.io/autoware-documentation/main/installation/autoware/source-installation/#how-to-set-up-a-workspace and https://autowarefoundation.github.io/autoware-documentation/main/installation/autoware/source-installation/#how-to-update-a-workspace to include vcs import src < tools.repos
2. Move the packages to tools

[esteve]

All the packages that didn't have a prefix (either tier4 or autoware) have been renamed or are in review. I haven't submitted PRs to rename rviz plugins because we're moving them out of common.

@xmfcx is there a tools repository I can move the rviz plugins to? Thanks.

[xmfcx]

@esteve you may move them here: https://github.com/autowarefoundation/autoware_tools/tree/main/common

But since some rviz plugins might be important for the tutorials, maybe we shouldn't move all of them. Or the tutorials won't work with the official autoware docker images.

https://github.com/autowarefoundation/autoware_launch/blob/main/autoware_launch/rviz/autoware.rviz

Could you go through here and only move the rviz plugins not referenced by this file?

cc. @youtalk

[esteve]

Here's the list of plugins that the https://github.com/autowarefoundation/autoware_launch/blob/main/autoware_launch/rviz/autoware.rviz file uses:

• AutowareDateTimePanel
• autoware_mission_details_overlay_rviz_plugin/MissionDetailsDisplay
• autoware_overlay_rviz_plugin/SignalDisplay
• autoware_perception_rviz_plugin/DetectedObjects
• autoware_perception_rviz_plugin/PredictedObjects
• autoware_perception_rviz_plugin/TrackedObjects
• rviz_common/Displays
• rviz_common/Group
• rviz_common/Selection
• rviz_common/Tool
• rviz_common/Views
• rviz_default_plugins/Camera
• rviz_default_plugins/FocusCamera
• rviz_default_plugins/Grid
• rviz_default_plugins/Image
• rviz_default_plugins/Interact
• rviz_default_plugins/Map
• rviz_default_plugins/Marker
• rviz_default_plugins/MarkerArray
• rviz_default_plugins/Measure
• rviz_default_plugins/MoveCamera
• rviz_default_plugins/PointCloud2
• rviz_default_plugins/Polygon
• rviz_default_plugins/Pose
• rviz_default_plugins/PoseArray
• rviz_default_plugins/PoseWithCovariance
• rviz_default_plugins/RobotModel
• rviz_default_plugins/Select
• rviz_default_plugins/SetGoal
• rviz_default_plugins/SetInitialPose
• rviz_default_plugins/TF
• rviz_default_plugins/ThirdPersonFollower
• rviz_default_plugins/TopDownOrtho
• rviz_plugins/BusInitialPoseTool
• rviz_plugins/CarInitialPoseTool
• rviz_plugins/DeleteAllObjectsTool
• rviz_plugins/MissionCheckpointTool
• rviz_plugins/MrmSummaryOverlayDisplay
• rviz_plugins/Path
• rviz_plugins/PedestrianInitialPoseTool
• rviz_plugins/PolarGridDisplay
• rviz_plugins/PoseWithUuidStamped
• rviz_plugins/Trajectory
• rviz_plugins::AutowareStatePanel
• rviz_plugins::PoseHistory
• tier4_adapi_rviz_plugins::RouteTool

Of these, only the following are ours:

• AutowareDateTimePanel (tier4_datetime_rviz_plugin)
• autoware_mission_details_overlay_rviz_plugin/MissionDetailsDisplay (autoware_mission_details_overlay_rviz_plugin)
• autoware_overlay_rviz_plugin/SignalDisplay (autoware_overlay_rviz_plugin)
• autoware_perception_rviz_plugin/DetectedObjects (autoware_perception_rviz_plugin)
• autoware_perception_rviz_plugin/PredictedObjects (autoware_perception_rviz_plugin)
• autoware_perception_rviz_plugin/TrackedObjects (autoware_perception_rviz_plugin)
• tier4_adapi_rviz_plugins::RouteTool (tier4_adapi_rviz_plugin)

The rest can be safely moved to another repository.

[xmfcx]

Didn't check all but:

• rviz_plugins::AutowareStatePanel is exported by:
  • https://github.com/autowarefoundation/autoware.universe/blob/f112f652bb85b7b980f3b1d7a7bb2c133cc84c61/common/tier4_state_rviz_plugin/plugins/plugin_description.xml#L6

We cannot move it either.

Edit:
Similarly:

• https://github.com/autowarefoundation/autoware.universe/blob/f112f652bb85b7b980f3b1d7a7bb2c133cc84c61/common/autoware_polar_grid/plugins/plugin_description.xml#L3

[esteve]

@xmfcx thanks, I only checked the packages that implement those plugins, but not the packages that depend on them yet. In any case, I'm sorry but I don't understand why we can't move all the rviz plugins to another repository. Couldn't we create a separate Docker image with them? And leave the rest of the common packages here in a base Docker image?

[xmfcx]

@youtalk -san might have a better plan for it.

But my expectation from the autoware runtime docker image (universe-cuda from https://raw.githubusercontent.com/autowarefoundation/autoware/0dd08838d0ebc154bf698ee1b8d157a456eb044f/docker/Dockerfile.svg ) to have the basic rviz plugins.

If we move all the rviz plugins to tools.repos, we also need to update the autoware installation instruction to tell people to vcs import tools.repos too or the tutorials wont work for them.

As for the docker images, how and at what stage they are required, I'll leave that decision to @youtalk -san and @oguzkaganozt .

In my opinion, looking at the structure of the docker images tree that these basic rviz plugins should be a part of universe-common-devel and be propagated downward the tree. Because they are useful for everyday debugging of the autoware. And necessary for the runtime.

cc. @mitsudome-r

[youtalk]

Our ultimate goal is to minimize the size of the runtime containers while enhancing maintainability and availability.

Therefore, I think it’s fine for the development containers to include RViz and its plugins, in line with @xmfcx's opinion. On the other hand, for the runtime containers, the visualization tools through a separate container, as @oguzkaganozt is currently working on, is preferable.

[mitsudome-r]

I think we have the following options:

1. create visualization folder under autoware.universe and move all the rviz_plugin packages into the visualization folder.
2. consider creating a new repository to maintain rviz_plugins (we can also consider releasing them through ROS buildfarm so that we don't have to specify in autoware.repos file anymore)
3. keep it in common folder, and the docker file refer to them by regex (like *_rviz_plugin)

I prefer option 1 for now. Option 2 is ideal, but I think there are still many dependencies to other Universe packages and isn't realistic to be done in short term.

[esteve]

I like option 1 too, in my opinion common should be as small as possible and aim for keep packages in folders that are more descriptive.

[xmfcx]

And for docker, the visualization packages can be excluded by --base-paths option from https://colcon.readthedocs.io/en/released/reference/discovery-arguments.html