feat(multi_object_tracker): reduce publish delay

[technolojin]

Description

This PR suggests a new method to reduce latency about 100 ms.

Background:

Current multi_object_tracker publishes the tracked object triggered by a timer. This timer ensures the topic is published in target frequency. The delay is compensated by predict the tracked objects motion.
However, the input (merged objects from multiple detectors) frequency is unstable (see the following plots, name of input_latency_ms). The instability of the detection latency is absorbed by the multi_object_tracker and adds latency about one cycle (100 ms of TIER IV configuration).

The new method:

there is two triggers to publish the tracked object

1. on measurement : When the publishing frequency is in the target window, publish right after the process is done. The publishing object will be compensated the delay from the measurement to the publishing time.
2. on timer : When the input is late, publish tracked object with delay compensation.

Side effect:

The publishing frequency will not be kept precisely. (see the following plots, name of cycle_time_ms )

Related links

TIER IV INTERNAL

Tests performed

Current

Improved

Notes for reviewers

This PR will be merged after
PR #6706
PR #6757
PR #6775

This PR is an alternative work of PR #6687

TODO: improve input (merged object) stability

Interface changes

N/A

Effects on system behavior

It may reduces overall latency about one cycle of the perception (100 ms).

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

• I've confirmed the contribution guidelines.
• The PR follows the pull request guidelines.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR follows the pull request guidelines.
• The PR has been properly tested.
• The PR has been reviewed by the code owners.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.
• The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 19 lines in your changes are missing coverage. Please review.

Project coverage is 14.93%. Comparing base (35642a6) to head (76c47f7).
Report is 8 commits behind head on main.

❗ Current head 76c47f7 differs from pull request most recent head f9b483d. Consider uploading reports for the commit f9b483d to get more accurate results

Files	Patch %	Lines
...i_object_tracker/src/multi_object_tracker_core.cpp	0.00%	19 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6710      +/-   ##
==========================================
- Coverage   14.93%   14.93%   -0.01%     
==========================================
  Files        1944     1944              
  Lines      134061   134051      -10     
  Branches    39891    39879      -12     
==========================================
- Hits        20027    20025       -2     
+ Misses      91735    91733       -2     
+ Partials    22299    22293       -6     

Flag	Coverage Δ		*Carryforward flag
differential	0.00% <0.00%> (?)
total	14.94% <ø> (+<0.01%)	⬆️	Carriedforward from 8046005

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

[YoshiRi]

Now I get your idea.
The key value in your logic is constexpr double maximum_latency_ratio = 1.11; // 11% margin.

This value represents how large this "time keeper" can endure input delay variance.

If this value is small as 1.11, the time keeper is more strict so that it can cause large delay when larger input latency variance comes.

If I choose larger value like 1.5, the time keeper would not bother process and then processing time can be stick to smaller value. Apparently, it has drawback that the worst delay becomes larger since time keeper is loose, so this value should decided by maximum acceptable publish interval. I think.

Anyway, I prefer larger value because current tracking already has some variance in the publishing interval.

[technolojin]

@YoshiRi
Your understand is right. If we increase the value maximum_latency_ratio, probability of prediction-without-update will reduced.
However, I do not know users can accept the long silent of 150 ms.

One another key tuning point is
const double minimum_publish_interval = publisher_period_ * 0.7; // 70% of the period
If we allow to publish topics in a short time (lower the minimum_publish_interval), The publisher triggered by message will keep up the latest object.
I adjusted the value to 0.4 and the test result is as following.

The cyclic time is occasionally drops near to 40 ms, but the publish interval is kept within 116 ms (111 ms of configured maximum + onTimer maximum latency 5 ms) in my environment.

[YoshiRi]

[imo]
Since early publish is better for the planning module, I prefer larger value like 1.4 or more.

[technolojin]

the acceptable publish interval is set to 70% to 111%, as agreed with @yukkysaito

[technolojin]

This PR will be reviewed and merged after a bugfix of the MOT #6775 is merged.

[YoshiRi]

LGTM. Worked within my laptop