fix(object_association_merger_node): fix the frame id of output object msg

[vividf]

Description

This PR solves the issue #8530.

If the frame id of output_msg is not base_link, the merged object will have the wrong coordinate.
This issue happens because all of the objects (0 and 1) are transformed to base_link, but the frame of output_msg is from input_objects0_msg->header

Before fixed:

After fixed:

Related links

Parent Issue:

• Link

How was this PR tested?

• rosbag: sample rosbag
• CenterPoint detection apply on top pointcloud

ros2 launch autoware_launch logging_simulator.launch.xml map_path:=$HOME/autoware_map/sample-map-rosbag vehicle_model:=sample_vehicle sensor_model:=sample_sensor_kit

Notes for reviewers

None.

Interface changes

None.

Effects on system behavior

None.

[github-actions]

Thank you for contributing to the Autoware project!

🚧 If your pull request is in progress, switch it to draft mode.

Please ensure:

• You've checked our contribution guidelines.
• Your PR follows our pull request guidelines.
• All required CI checks pass before marking the PR ready for review.

[cyn-liu]

Thank you very much for your fix, but I think there are some problem with this PR.

I don't think this bug should be fixed in this way. In theory, the frame_id of the two input topic of node object_merger should be base_link, so output_msg.header = input_objects0_msg->header is not a bug.
The real problem is that the frame_id of input/object0 for node object_merger is lidar frame_id instead of base_link, so we should modify the frame_id of node lidar_centerpoint output topic to base_link.

What do you think?

[vividf]

@cyn-liu
Thanks for your comment.
However, I don't think restricting the output of the centerpoint would be a better option. Since centerpoint should be able to run without providing the baselink frame and I think the object frame should also be the same as the pointcloud frame.

Since this node assigns the header of the output_msg to be the same as the input_objects0_msg, and the objects are transformed and merged in the base_link (which also means that the input can be in the different frame), I think setting the output frame id to base_link here probably is a better option.

@technolojin @YoshiRi @yukkysaito What do you think, thanks!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 24.12%. Comparing base (21ce55f) to head (6a8ba53).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8674      +/-   ##
==========================================
- Coverage   24.12%   24.12%   -0.01%     
==========================================
  Files        1400     1400              
  Lines      102282   102295      +13     
  Branches    38782    38785       +3     
==========================================
  Hits        24675    24675              
- Misses      75124    75137      +13     
  Partials     2483     2483              

Flag	Coverage Δ		*Carryforward flag
differential	0.00% <ø> (?)
total	24.12% <ø> (ø)		Carriedforward from 21ce55f

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[technolojin]

I think it was a bug, and will be fixed by this PR.

LGTM

[yukkysaito]

LGTM

[cyn-liu]

@vividf Thanks for your fix this bug.

By the way, I want ask a question: What is the mean of parameter world_frame_id: map in package autoware_lidar_centerpoint? I thought this parameter controlled the output frame_id of node lidar_centerpoint, but after verification, it has no relationship with the output frame_id.

[vividf]

@cyn-liu
From the documentation https://autowarefoundation.github.io/autoware.universe/main/perception/autoware_lidar_centerpoint/