fix: properly filter blanked RPLidar angles using any() in _path_processor

[Ridwannurudeen]

Summary

Fixes #2138

A continue statement inside a nested loop caused the RPLidar angle blanking logic to silently fail. Readings from blanked angle ranges (fixed chassis reflections) passed through to the path planner as phantom obstacles, potentially triggering unnecessary stops or evasive maneuvers on any robot with non-empty angles_blanked.

Root cause

In _path_processor (line 453), the blanking check was structured as:

for b in self.angles_blanked:
    if angle >= b[0] and angle <= b[1]:
        continue  # only skips inner loop iteration

The continue targets the inner for b in self.angles_blanked loop, not the outer for angle, distance in data loop. So regardless of whether an angle matched a blanked range, execution always fell through to complexes.append(...) at line 472.

Notably, the standalone test script system_hw_test/rptest.py (lines 276-282) already implements this correctly using a flag + break pattern, confirming this was a regression when the logic was ported into the provider class.

Fix

Replace the broken nested loop with a single any() expression:

if any(b[0] <= angle <= b[1] for b in self.angles_blanked):
    continue  # now correctly skips the outer loop

This works because any() collapses the inner loop into a boolean expression, so continue now operates on the outer for angle, distance in data loop as intended. The generator inside any() short-circuits on the first match, preserving the same early-exit behavior as break.

Affected configurations

Any robot with non-empty angles_blanked was impacted:

• config/turtlebot4.json5 — blanks [-180, -160] and [110, 180]
• config/turtlebot4_lidar.json5
• config/turtlebot4_lidar_gps.json5
• config/test_lidar.json5

Robots with angles_blanked: [] (all Go2 configs) were unaffected since the inner loop never executed.

Tests added

• test_path_processor_filters_blanked_angles: Feeds 4 sensor readings through _path_processor with angles_blanked=[[-170, -150]]. Verifies that the 2 readings landing inside the blanked range are excluded and the 2 outside it survive. Each test angle is traced through the mounting offset and coordinate conversion to confirm correctness.

• test_path_processor_no_blanking_when_empty: Feeds 3 valid readings with angles_blanked=[] and verifies all 3 pass through, ensuring the fix doesn't introduce false positives.

Test plan

• ruff check — 0 errors
• ruff format --check — already formatted
• Both new tests pass with the fix applied
• Verified the fix matches the proven pattern in rptest.py
• Confirmed any() short-circuits on first match (no performance regression)

[letmehateu]

#2139
Already approved by reviewer

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[Wanbogang]

Hi @Ridwannurudeen
You can run pyright first locally, if everything passes, you can push to github.

[letmehateu]

Hi @Ridwannurudeen You can run pyright first locally, if everything passes, you can push to github.

Sorry, but i already mentioned this issue in my PR and got approve

[Ridwannurudeen]

Thanks @Wanbogang — good catch. The pyright failure was due to a # type: ignore comment landing on the wrong line after ruff reformatted a multi-line conditional. Pushed a fix that places the suppression on the actual attribute access line. Both pyright and ruff pass locally now.

[letmehateu]

Thanks @Wanbogang — good catch. The pyright failure was due to a # type: ignore comment landing on the wrong line after ruff reformatted a multi-line conditional. Pushed a fix that places the suppression on the actual attribute access line. Both pyright and ruff pass locally now.

Sorry, why you ignoring me?
To be honest it's unprofessional. If you found same issues, you can open yours, if PR already pinned to issue

[Ridwannurudeen]

Hey @letmehateu — apologies for not acknowledging your PR first, that was my oversight. I should have engaged with #2139 before opening a separate one.

My PR takes a slightly different approach (single any() expression instead of the flag pattern) and adds test coverage for the filtering logic, but I totally respect that you identified and reported the bug. Happy to let the maintainers decide which direction they prefer.

[0xbyt4]

#2139 Already approved by reviewer

for public 1 issues multiple developer can open PRs , the best one will merge after approve with multiple reviewers.

[Wanbogang]

Thanks @Wanbogang — good catch. The pyright failure was due to a # type: ignore comment landing on the wrong line after ruff reformatted a multi-line conditional. Pushed a fix that places the suppression on the actual attribute access line. Both pyright and ruff pass locally now.

Sorry, why you ignoring me? To be honest it's unprofessional. If you found same issues, you can open yours, if PR already pinned to issue

Hi @letmehateu
I am not ignoring you. I even suggested improvements to you. Actually, the main problem is that you tagged [bounty] in the issue. Because this is open source, everyone has the opportunity to improve it. I also have to be fair. I hope you can understand. Thanks