fix(autoware_ndt_scan_matcher): zero div if particles_num < 20

[kazu-321]

Description

This fixes an error that occurs when particles_num is less than 20.
publish_interval becomes 0, resulting in division by zero.
This causes the node to crash with an error at runtime.
This change avoids division by zero by adding publish_interval != 0 before the division if publish_interval is 0.

Related links

Parent Issue:

• Link

How was this PR tested?

Confirm that no error occurs when particles_num is set to less than 20.

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.

[Copilot]

Pull request overview

This PR fixes a runtime crash in autoware_ndt_scan_matcher that can occur during Monte Carlo initial pose estimation when initial_pose_estimation.particles_num is less than 20, by preventing a modulo-by-zero in the marker publish logic.

Changes:

• Guarded the marker publish condition to avoid evaluating (i + 1) % publish_interval when publish_interval == 0.
• Minor formatting adjustment to the out_of_map_range warning if statement.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[xmfcx]

Consider fixing this at the source by clamping publish_interval to at least 1, rather than guarding the modulo downstream.

Change line 1115

autoware_core/localization/autoware_ndt_scan_matcher/src/ndt_scan_matcher_core.cpp

Line 1115 in 003e245

const int64_t publish_interval = param_.initial_pose_estimation.particles_num / publish_num;

to:

const int64_t publish_interval =
  std::max<int64_t>(param_.initial_pose_estimation.particles_num / publish_num, 1);

Then this condition can stay unchanged:

Suggested change

	(publish_interval != 0 && (i + 1) % publish_interval == 0) ||
	(i + 1) == param_.initial_pose_estimation.particles_num) {
	(i + 1) % publish_interval == 0 || (i + 1) == param_.initial_pose_estimation.particles_num) {

This eliminates the zero divisor at the point of definition instead of working around it at the point of use. For small particle counts (< 20), it publishes progress every iteration, which is fine since the total is still under the 20-publish budget.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.98%. Comparing base (d0600fb) to head (7eeaa03).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #996   +/-   ##
=======================================
  Coverage   55.97%   55.98%           
=======================================
  Files         378      378           
  Lines       23654    23654           
  Branches    11175    11176    +1     
=======================================
+ Hits        13241    13242    +1     
  Misses       7540     7540           
+ Partials     2873     2872    -1     

Flag	Coverage Δ		*Carryforward flag
daily-humble	55.46% <ø> (-0.01%)	⬇️	Carriedforward from d0600fb
daily-jazzy	56.17% <ø> (-0.01%)	⬇️	Carriedforward from d0600fb
differential-humble	42.56% <100.00%> (?)
differential-jazzy	41.39% <100.00%> (?)
total	49.98% <ø> (-0.01%)	⬇️	Carriedforward from d0600fb
total-humble	55.46% <ø> (-0.01%)	⬇️	Carriedforward from d0600fb
total-humble-agnocast	55.30% <ø> (-0.01%)	⬇️	Carriedforward from d0600fb
total-jazzy	55.64% <ø> (-0.01%)	⬇️	Carriedforward from d0600fb
total-jazzy-agnocast	55.48% <ø> (-0.01%)	⬇️	Carriedforward from d0600fb

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[anhnv3991]

@kazu-321 This looks fine but do you have any dataset where the error occurs? I want to confirm that the patch can really fix the issue, i.e. before applying the patch the error occurred, but after applying the patch the error has gone.