# /control/command/hazard\_lights\_cmd

## Specifications

| Item | Value |
| --- | --- |
| Last Updated | 2026-01-21 |
| Interface Type | topic |
| Interface Name | /control/command/hazard\_lights\_cmd |
| Data Type | [autoware\_vehicle\_msgs/msg/HazardLightsCommand](<https://github.com/autowarefoundation/autoware_msgs/blob/main/autoware_vehicle_msgs/msg/HazardLightsCommand.msg>) |
| Rate \[Hz\] | 10 or N/A |
| QoS Reliability | reliable |
| QoS Durability | volatile |
| QoS Depth | 1 |

## Description

Send the hazard lights change command to the vehicle. The command is `ENABLE` or `DISABLE`.

The [`autoware_component_interface_specs`](<https://github.com/autowarefoundation/autoware_core/blob/1.10.0/common/autoware_component_interface_specs/include/autoware/component_interface_specs/control.hpp>) package defines this topic with `volatile` durability. In the default launch of Autoware, the [`autoware_vehicle_cmd_gate`](<https://github.com/autowarefoundation/autoware_universe/blob/0.53.1/control/autoware_vehicle_cmd_gate/src/vehicle_cmd_gate.cpp>) node publishes the command periodically, at its `update_rate` of 10 Hz. This node uses `transient_local` durability, and `volatile` subscribers also receive its messages. The design intent is different: use `transient_local` durability and publish only when the command changes. Make sure that the publishers and the subscribers in your system use compatible QoS settings.

## Message

The `stamp` field is the command sent time. In the case of periodic publication, use the latest time, not the last command change. For the `command` field, use the valid values listed above. The `NO_COMMAND` value can be used internally by programs, but will never be sent as a topic.

## Errors

Invalid command: If the vehicle interface receives an undefined command, it is ignored and a diagnostic error is reported.

## Support

This interface is required. If the vehicle does not have hazard lights, always ignore the command.

## Limitations

None.

## Use cases

- Control the vehicle for autonomous driving.
- Relay commands from the operator.

## Requirement

- Support sending the hazard lights command to the vehicle.
- Report the error as diagnostics if an unsupported or unknown command is sent.

## Design

Separation from turn indicators: Hazard lights and turn indicators are defined in separate interfaces to allow independent state management. For example, an autonomous stack might request "Turn Left" for routing, but a safety system might simultaneously request "Hazard Enable" due to an emergency. This simplifies the logic because an autonomous stack and safety system no longer have to worry about their states being overwritten by each other's commands.

Priority logic: The vehicle interface must prioritize HazardLightsCommand.ENABLE over any TurnIndicatorsCommand. This ensures safety signals (hazards) always take precedence over navigation signals.

## History

| Date | Description |
| --- | --- |
| 2026-01-21 | First release in the new format. |