feat(map_based_prediction): plan paths of objects outside the lanelets.

[takayuki5168]

Description

• Added a publisher of calculation time
• Paths are planed even if the object is outside the lanelet if they are close enough.
  without the PR
  
  with the PR
  

FYI:
The case where object is in the opposite directional lane

Tests performed

• planning simulator
• scenario simulator
  • https://evaluation.tier4.jp/evaluation/reports/5511d35c-462a-5071-95f4-edb057611521?project_id=prd_jt

Effects on system behavior

Nothing

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.

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.

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

[takayuki5168]

This part was moved to

constexpr double epsilon = 1e-3;
if (lanelet.first < epsilon) {

[YoshiRi]

So, your idea is to allow getCurrentLanelet function to return neighbor lanelet if there are no corresponding lanelet with object.

My concern is:

• the program outside the getCurrentLanelet function can not distinguish the output is closest_lanelet or object_lanelet
  • For example, this 'current' lanelet is saved to object_history_ and which is used in checkCloseLaneletCondition and so on

If possible, it would be safer for later feature development if it is known whether the returned value is a closet_lanelet or an object_lanelet, but since this is for developers, there should be at least no problem if it is described in a comment.
I think we can accept this concern only if this PR pass all of P/C test case.

[YoshiRi]

need to check if calculateLocalLikelihood function is valid with obj outside the lanalet

[YoshiRi]

I think we need to check object yaw and lanelet yaw diff is small enough so that we will not get the unexpected lanelet such as opposite lanelet

[takayuki5168]

We call checkCloseLaneletCondition before the above condition so we do not have to check the angle and even distance (Now I removed the distance check).

[YoshiRi]

LGTM

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: -0.01% ⚠️

Comparison is base (7f02d6a) 14.82% compared to head (532fab1) 14.82%.
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4618      +/-   ##
==========================================
- Coverage   14.82%   14.82%   -0.01%     
==========================================
  Files        1529     1529              
  Lines      105811   105827      +16     
  Branches    32243    32243              
==========================================
  Hits        15690    15690              
- Misses      72965    72981      +16     
  Partials    17156    17156              

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

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

Files Changed	Coverage Δ
...map_based_prediction/map_based_prediction_node.hpp	0.00% <ø> (ø)
...based_prediction/src/map_based_prediction_node.cpp	0.00% <0.00%> (ø)

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