Skip to content

feat(map_based_prediction): consider arrow signals in priority stop prediction - #3231

Open
satoshi-ota wants to merge 1 commit into
feat/v0.64/e2efrom
feat/map-based-prediction-priority-arrow-signal
Open

feat(map_based_prediction): consider arrow signals in priority stop prediction#3231
satoshi-ota wants to merge 1 commit into
feat/v0.64/e2efrom
feat/map-based-prediction-priority-arrow-signal

Conversation

@satoshi-ota

Copy link
Copy Markdown

Description

Makes the priority (traffic-signal stop) prediction consider arrow signals.

Previously the stop requirement was evaluated using the turn_direction of the lanelet that carries the traffic light. When the light is referenced by a shared approach lanelet with no turn_direction, the straight / left / right predicted paths all resolved to that same lanelet, so arrow signals were ignored and every path was cut on red.

Now, for each predicted path, two lanelets are resolved separately:

  • traffic_light_lanelet — the first lanelet on the path carrying a traffic light; used for the signal lookup and the stop line (unchanged).
  • maneuver_lanelet — the lanelet whose turn_direction drives the arrow decision: the traffic-light lanelet's own turn_direction when present, otherwise the first downstream lanelet on the path that has one.

The stop requirement (isTrafficSignalStop) is then evaluated against the maneuver lanelet. So, e.g., with a right arrow:

Predicted path direction Result
Right-turn lane not cut (proceeds)
Straight lane cut at stop line
Left lane cut at stop line

When the traffic-light lanelet itself carries a turn_direction, behavior is identical to before (backward compatible).

Changes

  • resolveSignalLanelets() returning {traffic_light_lanelet, maneuver_lanelet}
  • Evaluate isTrafficSignalStop against the maneuver lanelet; stop line / signal lookup stay on the traffic-light lanelet
  • Reuses the existing autoware::traffic_light_utils::isTrafficSignalStop arrow logic

Tests

  • Added unit tests for maneuver-lanelet resolution (downstream turn lanelet vs. traffic-light lanelet carrying the turn_direction)
  • colcon build + colcon test pass on the base (feat/v0.64/e2e): 45 tests, 0 failures

🤖 Generated with Claude Code

…rediction

The traffic-signal stop hypothesis evaluated the stop requirement using the
turn_direction of the lanelet carrying the traffic light. When the light is
referenced by a shared approach lanelet with no turn_direction, straight/left/
right predicted paths all resolved to that lanelet, so arrow signals were
ignored and every path was cut on red.

Resolve, per predicted path, both the traffic-light lanelet (for the signal
lookup and stop line) and a separate maneuver lanelet whose turn_direction
drives the arrow decision: the traffic-light lanelet's own turn_direction when
present, otherwise the first downstream lanelet on the path that has one. As a
result, e.g. a right arrow keeps the right-turn path while still stopping the
straight/left paths.

- Add resolveSignalLanelets() returning {traffic_light_lanelet, maneuver_lanelet}
- Evaluate isTrafficSignalStop against the maneuver lanelet
- Add unit tests for maneuver lanelet resolution

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

@satoshi-ota Thank you for contributing to TIER IV E2E branch! Edit the checklist below and check the boxes as you complete the items.

Things to check before merging

Please check the following points before merging:

  • Write a brief description of this PR that can be understood by coding-agents.
  • Contact the branch manager on when the PR will be tested on vehicle.
  • Recommend to use Squash and Merge to merge the PR.
  • Report in #team-product-dev channel on the contents of the PR. @ branch manager.

After merging

Please check the following points after merging:

  • Wait for the automatic hash synchronization, which will automatically create a PR to update the hash, you should check the PR and merge it.

@tier4-autoware-public-bot tier4-autoware-public-bot Bot added beta/v0.64 Base branch: beta/v0.64 diffusion_planner Product: diffusion_planner labels Jul 22, 2026
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

beta/v0.64 Base branch: beta/v0.64 diffusion_planner Product: diffusion_planner

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant