Trajectory Validator

Purpose/Role

This package provides a pluginlib-based C++ library for evaluating candidate trajectories against a configurable set of safety and traffic-rule filters. Each filter plugin receives a world-state context snapshot (ValidatorContext) and returns a feasibility verdict for a single trajectory. Trajectories rejected by any enforced plugin are removed from the output set. The library is embedded in autoware_trajectory_selector.

Algorithm Overview

For each input CandidateTrajectories message the library runs every loaded plugin against every trajectory:

1. Plugin evaluation: each plugin’s is_feasible() is called with the trajectory points and the current ValidatorContext (odometry, predicted objects, acceleration, HD map, traffic light states).
2. Feasibility decision: a trajectory survives if every plugin listed in filter_names returns is_feasible = true. Plugins listed in shadow_mode_filter_names are evaluated and reported but never remove a trajectory.
3. Diagnostics: the wrapper publishes an Autoware diagnostics status — OK if all trajectories pass all enforced plugins, WARN if at least one is rejected, ERROR if none survive.

Built-in Plugins

Interface

This package is a C++ library. The topics below are subscribed to by the hosting node (trajectory_selector_node) and passed to the validator as a ValidatorContext.

Topics

Parameters

{{ json_to_markdown(“planning/autoware_trajectory_validator/schema/trajectory_validator.schema.json”) }}

Changelog for package autoware_trajectory_validator

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