autoware_traffic_light_pipeline

Single-node composition of the traffic light recognition pipeline.

Node (traffic_light_recognition)

Input / Output

Node parameters

{{ json_to_markdown(“perception/autoware_traffic_light_pipeline/schema/traffic_light_recognition.schema.json”) }}

Prerequisites

The ML models used by this pipeline (traffic light detector / classifier) must be downloaded in advance to ~/autoware_data. See Manual downloading of artifacts for how to download them.

The default data_path launch argument (see below) points to ~/autoware_data, so no additional configuration is needed once the models are placed there.

How to launch

ros2 launch autoware_traffic_light_pipeline traffic_light_recognition.launch.xml

Useful launch arguments:

Example, running against a second camera:

ros2 launch autoware_traffic_light_pipeline traffic_light_recognition.launch.xml camera_name:=camera7

How to test

PACKAGE_NAME=autoware_traffic_light_pipeline
colcon build --packages-select $PACKAGE_NAME
colcon test --packages-select $PACKAGE_NAME --event-handlers console_cohesion+

The unit/integration tests also require the ML models under ~/autoware_data, since test_traffic_light_recognition_node brings up the node with the same ml_model_path default as the launch file above.

Changelog for package autoware_traffic_light_pipeline

0.53.0 (2026-09-29)

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

• feat(autoware_traffic_light_pipeline): add traffic_light_recognition node (#13367)

  * feat(autoware_traffic_light_pipeline): add traffic_light_recognition node Compose, for one camera, the ROS-free core logic already extracted into autoware_tensorrt_yolox, autoware_traffic_light_map_based_detector, autoware_traffic_light_selector, autoware_traffic_light_classifier and autoware_traffic_light_category_merger into a single rclcpp::Node, in place of the 5-Node graph production currently launches per camera: map_based_detector -> whole_image_detector(yolox) -> selector -> car_classifier / pedestrian_classifier -> category_merger The fine_detection path (traffic_light_fine_detector + traffic_light_occlusion_predictor) is out of scope. The package ships a ROS-free core (TrafficLightRecognition) plus a Node adapter (TrafficLightRecognitionNode, registered as an rclcpp_components plugin). The core's constructor needs the vector map, so the Node builds it on ~/input/vector_map, which is also where the three TensorRT engines are built; build_only builds those engines without a map and exits. The ML artifacts are named in config/traffic_light_recognition.param.yaml relative to a single ml_model_path parameter -- the same split autoware_lidar_centerpoint's ml_package.param.yaml uses -- so the config file names no user-specific path and needs no launch substitution.

  • docs(autoware_traffic_light_pipeline): add launch and test instructions to README
  • fix(autoware_traffic_light_pipeline): clean up unused includes and stale test comment

  * fix(autoware_traffic_light_pipeline): skip build when autoware_tensorrt_yolox is unavailable autoware_tensorrt_yolox returns early and installs no headers when autoware_tensorrt_common is missing, so this package fails to compile on environments without CUDA / TensorRT such as the non-CUDA CI runners. Guard the package with the same early return instead.

  * feat(autoware_traffic_light_pipeline): sync image and camera_info with bounded ApproximateTime Image and camera_info come from the same camera driver and are expected to share a stamp, so ExactTime worked. ApproximateTime tolerates drivers that stamp the two slightly differently; with equal stamps it behaves identically, publishing as soon as the second message arrives. Its default max interval is effectively unbounded, which would silently pair the current image with a camera_info from up to a full queue ago whenever one is dropped -- and both are subscribed with best-effort SensorDataQoS, so drops are expected under load. A stale camera_info makes the map-based detector project its ROIs from the ego pose of a different instant than the image was captured at, misplacing every ROI. Bound the interval to 50 ms, well below one frame period, so such pairs are rejected.

  * fix(autoware_traffic_light_map_based_detector): validate timestamp offset range An inverted min/max timestamp offset silently degraded detection: the tf sample loop never ran, leaving only the single stamp sample, which shrank the rough ROI vibration margin without any error.

  * fix(autoware_traffic_light_pipeline): wait for tf before running recognition TrafficLightRecognition::run() looks up transforms through tf2::BufferCore, which cannot wait. Without the wait the map based detector returned no ROIs, so every detection was discarded and empty signals were published.

  • fix(autoware_traffic_light_pipeline): align min_timestamp_offset with original package

  * fix(autoware_traffic_light_pipeline): rebuild only the map based detector on vector map update TrafficLightRecognition was rebuilt from scratch in the vector map callback, which reloaded the YOLOX and the two classifier TensorRT engines even though none of them depends on the map. Construct TrafficLightRecognition once in the node constructor and feed the map through set_map(), which recreates only the map based detector. The construction failure is now reported instead of escaping the subscription callback, and the missing map is reported through the return value of set_route() and run().

  • refactor(autoware_traffic_light_pipeline): return tl::expected from set_route

  * feat(autoware_traffic_light_pipeline): publish exposure diagnostics Report the classifiers' over/under exposure flags on /diagnostics. The core builds the DiagnosticArray so the node adapter publishes it the same way as the other outputs, and a status is emitted on every processed frame -- including frames with no selected ROI, which is the normal case whenever no traffic light is in view.

  • perf(autoware_traffic_light_pipeline): skip whole image

File truncated at 100 lines see the full file