chore(autoware_pointcloud_preprocessor): change unnecessary warning message to debug

[vividf]

Description

This PR provides a quick fix for changing unnecessary warning messages to debug to reduce the console log.
This PR #8300 fixes the issue but will take time to review.

According to TIER4_INTERNAL_LINK
[component_container_mt-1] [WARN 1724036039.656393647] [sensing.lidar.concatenate_data] computeTransformToAdjustForOldTimestamp(): "old_stamp is newer than new_stamp," at (/home/autoware/pilot-auto/src/autoware/universe/sensing/pointcloud_preprocessor/src/concatenate_data/concatenate_and_time_sync_nodelet.cpp:L255)

Warning messages keep showing up due to the algorithm design.

Current algorithm:

1. Sort the timestamp from large to small in a vector.
2. Pointclouds will find the timestamp smaller than its timestamp (in the vector) to calculate the transformation. But since it is finding the timestamp from large to small, if the pointcloud is not the newest one, it will always encounter the situation that the current pointcloud timestamp is smaller than the largest (or other larger) timestamp in the vector. When this happens the warning will show up.

Related links

Parent Issue:

• Link

How was this PR tested?

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.

[yukkysaito]

@vividf Thank you. I believe this should ideally be issued as a warning, so could you explain why it was categorized as debug information instead? The root cause should be addressed as a warning, but by downgrading it to debug, there’s a risk of missing the underlying issue.

That said, if this process has little to no impact on the system’s operation and doesn’t require correction, then treating it as debug information is acceptable.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 23.68%. Comparing base (1bfb4c0) to head (0fade6c).
Report is 2 commits behind head on main.

Files	Patch %	Lines
...atenate_data/concatenate_and_time_sync_nodelet.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8525      +/-   ##
==========================================
- Coverage   24.06%   23.68%   -0.38%     
==========================================
  Files        1397     1406       +9     
  Lines      102639   102355     -284     
  Branches    39035    39099      +64     
==========================================
- Hits        24697    24244     -453     
- Misses      75465    75601     +136     
- Partials     2477     2510      +33     

Flag	Coverage Δ		*Carryforward flag
differential	18.77% <0.00%> (?)
total	23.95% <ø> (-0.11%)	⬇️	Carriedforward from e958c63

*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.

[vividf]

@yukkysaito
Thanks for the comments.
From the algorithm described in the description above, all of the pointcloud will show this warning message instead of the pointcloud that has the latest timestamp.
For instance, if we have 4 pointcloud ready to concatenate, 3 of them satisfy the if condition.
if (old_stamp > new_stamp) { RCLCPP_DEBUG_STREAM_THROTTLE( get_logger(), *get_clock(), std::chrono::milliseconds(10000).count(), "old_stamp is newer than new_stamp,");

if condition is true
1st (earliest) pointlcoud: 3 time, 2nd pointcloud: 2 times, 3rd pointcloud: 1 times

Since almost all of the pointcloud will satisfy the if condition and this has no impact on system operation, I don't think a warning is a good logging message

[YoshiRi]

@vividf I think this PR is temporary because new design for concatenation in #8300 will solve this problem, right?
If so, saito-san's concern will not really affect products so much. LGTM.