feat(ekf_localizer): input ekf_dt to simple1dfilter

[YamatoAndo]

Description

Instead of calculating dt within Simple1DFilter, I modified it to pass ekf_dt_ as an argument.

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.

[YamatoAndo]

@reviewers I'm not confident that this fix is correct.
So, I would like everyone to consider what the correct approach should be.

[SakodaShintaro]

This change makes the "Simple1DFilter" class a ROS-free implementation. I think it's admirable from the view point about readability.

Are you concerned that ekf_dt_ is not equal to pose.header.stamp - latest_time_?

[YamatoAndo]

I’m more concerned about potential issues when there are two pose sources, such as NDT and GNSS.
Depending on the output timing of NDT and GNSS poses, the calculation of pose.header.stamp - latest_time_ could result in a negative value, which seems like an incorrect implementation.
In this case, I'm not confident that ekf_dt_ is correct.

[TaikiYamada4]

@YamatoAndo
I believe there is nothing wrong with using ekf_dt_ in the update function. I understand that dt in the update function determines the "variance of prediction." This variance should be larger as the timer period increases, because the longer the time, the more difficult the prediction becomes. In a traditional Kalman filter, the variance of prediction doesn’t need to be affected by the observation, regardless of how the observation appears.

In terms of multiple pose sources, it still seems natural to me that ekf_dt_ is used in the update function, and it doesn't significantly affect the system, even if multiple pose observations are stacked in the queue. If the timer period becomes longer for some reason, all the pose observations in the queue should have a larger impact.

Perhaps the concern arises from the fact that current 1D filters don't update the variance during delay compensation. If the observations in the queue are too old and the variance doesn’t increase during delay compensation, unexpected results may occur.

[codecov]

Codecov Report

Attention: Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 24.10%. Comparing base (bda8706) to head (79e5249).
Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
localization/ekf_localizer/src/ekf_localizer.cpp	40.00%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8622   +/-   ##
=======================================
  Coverage   24.10%   24.10%           
=======================================
  Files        1399     1399           
  Lines      102337   102334    -3     
  Branches    38870    38868    -2     
=======================================
  Hits        24668    24668           
+ Misses      75141    75138    -3     
  Partials     2528     2528           

Flag	Coverage Δ		*Carryforward flag
differential	31.20% <40.00%> (?)
total	24.10% <ø> (-0.01%)	⬇️	Carriedforward from bda8706

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

[SakodaShintaro]

I'll perform the performance tests for all data.

TIER IV INTERNAL LINK

• https://evaluation.tier4.jp/evaluation/reports/72dcc4cf-12c1-5d60-ab9f-aea42cbc3836?project_id=autoware_dev
• https://evaluation.tier4.jp/evaluation/reports/779f0860-8f91-5529-94fa-db21eb4c12c4?project_id=prd_jt

[SakodaShintaro]

I have compared the new code with the old code using 30 data points. Since there is some randomness in the logging_simulator, the results may have some deviation, but it can be interpreted that the performance is almost the same as before.

LGTM