Traffic Light Compliance Checker

The traffic_light_compliance_checker package provides a deterministic validation layer that cross-references planned vehicle trajectories against real-time perceived traffic light signals and High-Definition (HD) vector maps to enforce strict traffic compliance.

Core Features

1. Signal State Tracking (TrafficLightStatusTracker)
   • Eliminates perception jitter and signal flickering by maintaining a temporal state history for each traffic light group ID.
   • Leverages stable duration thresholds before validating a transition to RED or AMBER.
   • Utilizes a hysteresis buffer to sustain known states during transient object occlusions.
2. Trajectory Validation (TrafficLightComplianceChecker)
   • Scans forward trajectory segments sequentially to isolate intersection entry points.
   • Appends a physical front-bumper projection to ensure the vehicle footprint stays behind regulatory stop lines.
   • Implements a kinematic pass/stop feasibility matrix for AMBER signals based on comfortable braking and intersection clearance times.
   • Returns prioritized, chronological arrays of Violation metadata if an unvalidated stop line overshoot is detected.

Inner Workings

Main Processing Pipeline

The execution flow follows a sequential logical from signal processing & filtering down to stop line interaction evaluations:

1. Filter signals and update status tracker: Feeds raw perception data into the status tracker to clean up transient noise and tracking dropouts.
2. Generate Geometric Trajectory Linestring: Removes path points situated behind the ego vehicle, clamps the forward path length at max(min_lookahead_distance, comfortable_stop_distance + stop_overshoot_margin) (or until the first planned stop), and extends trajectory end to account for ego front offset.
3. Extract and group map stop lines: Sorts overlapping intersection lines into separate evaluation queues for red and amber constraints.
4. Evaluate Stop Line Violations: Checks the trajectory linestring against active stop lines, records detected violations and generate compliance result.

@startuml
skinparam defaultTextAlignment center
skinparam backgroundColor #WHITE

start

:Filter signals and update status tracker;<<#LightBlue>>
:Generate Trajectory Linestring\n(Cull backward points & clamp at max(min lookahead, stop distance));<<#LightBlue>>
:Extend trajectory linestring\n(Add physical front bumper footprint offset);<<#LightBlue>>
:Extract and group map stop lines\n(Categorize into RED vs. AMBER targets);<<#LightBlue>>

if (Is check_red_lights enabled?) then (yes)
  group Get red stop line violations #Lavender {
    if (Trajectory Intersects stop line?) then (yes)
      if (Trajectory end exceeds tolerance threshold?) then (yes)
        :Record RED Light Violation; <<#LightPink>>
      else (no)
      endif
    else (no)
    endif
  }
else (no)
endif

if (Is check_amber_lights enabled?) then (yes)
  group Get amber stop line violations #LightYellow {
    if (Trajectory Intersects stop line?) then (yes)
      if (Trajectory end exceeds tolerance threshold?) then (yes)
        :Compute time_to_cross AND ego_stopping_distance; <<#LightBlue>>
        if (ego_stopping_distance< distance to stop line OR time_to_cross > crossing_time_limit?) then (yes)
          :Record Amber Light Violation; <<#LightPink>>
        else (no)
        endif
      else (no)
      endif
    else (no)
    endif
  }
else (no)
endif

:Return Compliance Check Result; <<#LightGreen>>
stop

@enduml

Signal Status Tracker Filtering

To prevent sudden, harsh emergency braking maneuvers caused by raw perception noise, the status tracker filters raw signals through three deterministic mechanisms before passing them to the validation layer:

• State Persistence Buffering: Incoming state transitions (e.g., green to amber/red/unknown) must continuously persist for a minimum time window (stable_duration_threshold_red, stable_duration_threshold_amber, or stable_duration_threshold_unknown) before the new state is considered valid. If a signal flips color or alters elements before this duration threshold is reached, its active elements array is cleared to suppress transient sensor noise.
• History Eviction Buffer: If a traffic light group drops out of the incoming message matrix completely, the tracker retains its record for a brief clearing window. The duration an un-updated signal persists in memory is dynamically determined by its last recorded color state: stable_duration_threshold_red for red signals, stable_duration_threshold_amber for amber signals, and stable_duration_threshold_unknown for other non-red, non-amber conditions. If the signal remains un-detected beyond this frame timeout, its stale context is permanently erased from the tracking ledger.
• Ego-Stopped Pass-Through Gate: The tracker continuously evaluates the current motion of the ego vehicle via is_ego_stopped. When the vehicle has brought itself to a halt beneath the configured ego_stopped_velocity_threshold, the entire stability duration filtering logic is completely bypassed. This pass-through guarantees that the vehicle maintains maximum responsiveness to incoming state changes while stationary, eliminating filtering-induced latency during intersection departures.

Safety & Compliance Logic

• Segment-by-Segment Geometric Scan: The checker evaluates trajectory segments sequentially against mapped stop lines using a localized boost::geometry::intersection check. The loop breaks immediately upon finding the first chronological intersection point, calculating the dynamic distance-to-stop-line and interpolating the exact crossing timestamp (for amber light) using autoware::interpolation::lerp.
• Red Light Evaluation: Generates a violation if an intersection occurs, unless the trajectory makes the ego come to a complete stop within the specified stop_overshoot_margin.
• Amber Light Evaluation: Computes the dynamic stopping distance based on current velocity, acceleration, applied deceleration, and system response latency. If the vehicle can stop safely before the line, or if it cannot clear the intersection within the crossing_time_limit, an amber violation is recorded to enforce a stop.
• Arrow-aware amber passing: On protected turn lanes with a separate direction-arrow bulb in the map, the circle signal often goes GREEN → AMBER → RED before GREEN *_ARROW appears. While the circle is amber after a green circle, requiring a stop would be overly strict. When enable_arrow_aware_amber_passing is true, the checker skips stop-line collection (no amber/red violation) if all of the following hold:
  • ego route lane is a left or right turn lane (turn_direction)
  • the traffic light has a static arrow in the map (subtype containing arrow, or light-bulb arrow attribute)
  • the amber phase was reached from a green circle (AmberState::kFromGreen)
  • the current signal still reports an amber circle

  Transitions from red (or unknown) to amber still require a stop. A brief red circle before the green arrow is reported is also still treated as a stop (same scope as the behavior velocity traffic light module).

Structs and Interface Definitions

The interfaces pass inputs and output results through the following standard data types:

File truncated at 100 lines see the full file

Changelog for package autoware_traffic_light_compliance_checker

0.53.0 (2026-09-29)

• Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog

• feat(traffic_light_compliance_checker): improve compliance checker stability and amber handling (#13371)

  • modify tl compliance checker to detect stop attempts at amber light and (optionally) add tl id to force rejection buffer
  • update traffic_light_stop params in modifier
  • update traffic_light filter params in validator
  • update modifier and validator parameter structs
  • implement logic to detect stops at ember light and optionally add to force rejection buffer
  • update & refactor traffic_light filter tests
  • refactor tl compliance checker
  • update amber rejection hystory while checking for violations instead of post process
  • apply allow_if_cannot stop check while checking for violations instead of post process

  * improve crossig time limit logic compute dynamic time limit for amber light based on tracked tl duration instead of using fixed value param

  • check the flag reject_if_stop_detected before adding tl to amber_rejection_history_
  • add test cases to traffic_light_stop and traffic_light_filter
  • minor refactor
  • fix(traffic_light_stop): floor scan length with min_lookahead_distance and wire stop time step (#3232)

  * fix(traffic_light_stop): check full traj horizon and wire stop time step At low ego speed the compliance checker capped the scan by comfortable stopping distance (~0.5 m), missing red stop lines ahead. Also assign trajectory_time_step_ so the existing 3-point stop fallback uses the configured step. Co-authored-by: Cursor <<cursoragent@cursor.com>>

  * fix(traffic_light): floor scan length with min_lookahead_distance Restore the comfortable-stop scan cap but floor it at 20 m so creeping ego still sees nearby stop lines, without rejecting far lights in the shared traffic_light_filter path. Co-authored-by: Cursor <<cursoragent@cursor.com>> ---------Co-authored-by: Cursor <<cursoragent@cursor.com>>

  • fix cherry-pick errors
  • implement arrow aware amber tl compliance check
  • Track YellowState (kNotYellow / kFromGreen / kFromNonGreen) in TrafficLightStatusTracker from raw Green Circle → Amber transitions
  • Skip stop-line collection for arrow-aware amber when enable_arrow_aware_yellow_passing, turn lane, mapped static arrow, and kFromGreen all hold
  • Keep Red→Amber / unknown-origin amber as stop (no override)
  • Add shared utils (is_equal, has_*_circle, has_static_arrow, is_arrow_aware_amber_pass) used by tracker and checker
  • Add enable_arrow_aware_yellow_passing (default true) and wire it through trajectory_modifier traffic_light_stop and trajectory_validator traffic_light_filter (params, schema, config)
  • Document arrow-aware amber behavior in the compliance checker README
  • Add unit tests for yellow-transition tracking and end-to-end arrow-aware amber cases
  • hold last stable TL status while gated states settle
  • Track current candidate and last stable signal separately in TrafficLightStatusTracker
  • Emit the last stable status while red/amber/unknown are below their stable-duration thresholds instead of clearing elements
  • Update YellowState only when the accepted stable status changes, avoiding single-frame false detections
  • Pass through raw signals when ego is stopped for responsiveness, while still updating stable history
  • Accept candidate states with duration >= threshold (including immediate green)
  • replace yellow usage by amber
  • fix test
  • rename test file and extend test cases for compliance checker
  • improve TL compliance checker to prevent chattering behavior
  • refactor TrafficLightStatusTracker::filter_signals to emit all stable statuses in the history, not only the ones in this frame
  • keep a history of violation arc lengths per id
  • use previous violation arc lengths to floor current frame lookahead distance
  • use current frame collected stop lines to cleanup the history of violation arc lengths

  * Update common/autoware_traffic_light_compliance_checker/include/autoware/traffic_light_compliance_checker/utils.hpp Co-authored-by: Maxime CLEMENT <<78338830+maxime-clem@users.noreply.github.com>>

  • feat(traffic_light_stop, traffic_light_compliance_checker): fix inconsistent amber rejection behavior

File truncated at 100 lines see the full file