Skip to content

Fix corridor-only collision index delaying braking to path end - #30

Draft
cursor[bot] wants to merge 1 commit into
devfrom
cursor/critical-bug-inspection-ddad
Draft

Fix corridor-only collision index delaying braking to path end#30
cursor[bot] wants to merge 1 commit into
devfrom
cursor/critical-bug-inspection-ddad

Conversation

@cursor

@cursor cursor Bot commented Aug 4, 2026

Copy link
Copy Markdown

Bug

check_collision detects side obstacles via a buffered ego corridor (half-width + safety margin), but _find_collision_index searched with a bare centerline LineString.intersects. When only the buffer hits, the search fell back to n-1.

Impact

An agent beside the path inside the corridor (common parked/lateral case) was reported as a collision at path end. Velocity profiling and lattice urgent-switch then treated the threat as ~track-length away, so the ego kept cruise speed through the real obstacle.

Trigger

Straight path, ego width 2 m, margin 0.3 m, static agent at (30, 1.5) with width 2 m: corridor intersects, centerline does not → old idx 30, fixed idx ~8.

Fix

Binary search now uses partial_line.distance(obstacle) <= radius, matching corridor detection. Minimal change; no planner API churn.

Validation

  • Reproduced before/after in a local script (idx 30 → 8; speed at obstacle 10 → 0 m/s)
  • pytest test/c50_common/test_c55_collision_checking.py test/c20_planning/test_c27_local_behavioral_and_velocity_planners.py — 23 passed
Open in Web View Automation 

_find_collision_index now uses centerline distance within ego half-width
plus safety margin, matching the buffered corridor check, so side
obstacles trigger braking at the mid-path hit instead of n-1.

Co-authored-by: Majid Khonji <majid-khonji@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant