why image_projection_based_fusion need multi types of msg

[storrrrrrrrm]

in older version of roi_cluster_fusion, it only process msg of type 'DetectedObjectsWithFeature',now it supports msg of different types,currently,there are two types:

• autoware_auto_perception_msgs::msg::DetectedObjects
• tier4_perception_msgs::msg::DetectedObjectsWithFeature

is this necessary? Essentially, they contain the same information. why we need multi types of msg,current design is an interim version or a final version?

[storrrrrrrrm]

it makes code more complex and difficult to modify. for example,recently i want to add 'filter points out of user-configured-scope ' to make it easier when debug, so i need to add a fuction like this

bool out_of_scope(sensor_msgs::msg::PointCloud2 cluster);

under current design, i have to change

template <class Msg>
class FusionNode : public rclcpp::Node
{

to

template <class Msg,class ObjType>
class FusionNode : public rclcpp::Node
{

where 'ObjType' is autoware_auto_perception_msgs::msg::DetectedObject or tier4_perception_msgs::msg::DetectedObjectWithFeature,and then implement virtual function out_of_scope() in different subclass

it makes code harder to understand.

[yukke42]

roi_cluster_fusion and roi_detected_object_fusion subscribe the different type of messages, but the most of implementations are the same. Therefore, I implemented to allow to use some message types.

We're implementing PointPainting autowarefoundation/autoware.universe#569 and this feature is also added to theimage_projection_based_fusion package. It subscribes PointCloud and DetectedObjectWithFeature.

bool out_of_scope(sensor_msgs::msg::PointCloud2 cluster); seems only for roi_cluster_fusion, so, is it not good to add only to RoiClusterFusionNode?

[storrrrrrrrm]

roi_cluster_fusion and roi_detected_object_fusion subscribe the different type of messages, but the most of implementations are the same. Therefore, I implemented to allow to use some message types.

We're implementing PointPainting autowarefoundation/autoware.universe#569 and this feature is also added to theimage_projection_based_fusion package. It subscribes PointCloud and DetectedObjectWithFeature.

bool out_of_scope(sensor_msgs::msg::PointCloud2 cluster); seems only for roi_cluster_fusion, so, is it not good to add only to RoiClusterFusionNode?

so, you are suggesting me just add 'out_of_scope' to 'roi_cluster_fusion'? i think it is better to unify 'roi_cluster_fusion' and 'roi_detected_object_fusion', otherwise, user would be confused, i prefer to add a virtual function into FusionNode.

[yukke42]

so, you are suggesting me just add 'out_of_scope' to 'roi_cluster_fusion'? i think it is better to unify 'roi_cluster_fusion' and 'roi_detected_object_fusion', otherwise, user would be confused, i prefer to add a virtual function into FusionNode.

I make sense. It's better to add as a virtual function.

[yukkysaito]

When DetectedObjects as CenterPoint output and 2D ROI are fused, the roi cluster fusion function only support Clusters, not support DetectedObjects. However, mostly because of the same algorithm.
So, in order to fuse CenterPoint output and 2D ROI, roi cluster fusion function is changed the name and support DetectedObjects.

[storrrrrrrrm]

When DetectedObjects as CenterPoint output and 2D ROI are fused, the roi cluster fusion function only support Clusters, not support DetectedObjects. However, mostly because of the same algorithm. So, in order to fuse CenterPoint output and 2D ROI, roi cluster fusion function is changed the name and support DetectedObjects.

i get what u are concering,why not use a unified message define like this?

source: cluster/lidarcnn
vector<object>

Essentially, whatever the detection algorithm is, whatever msg u use to represent the obj,it is collection of xyz. There are so many msg defines in autoware,sometimes called tier4_xx_msgs,sometimes called autoware_xx_msgs,i am sometimes confused about this.

[ghost]

There is active work to finalise the messages types used by Autoware and to remove any confusion around the differently named messages, so this should be much more straightforward to understand in the future.

https://github.com/orgs/autowarefoundation/discussions/99