Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_component_interface_specs at Robotics Stack Exchange
Package Summary
| Version | 1.10.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/autowarefoundation/autoware_core.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-07 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Takagi, Isamu
- Yukihiro Saito
- Ryohsuke Mitsudome
Authors
autoware_component_interface_specs
This package defines the standardized component interface specifications for Autoware Core, ensuring consistent communication and interaction between various components in the Autoware autonomous driving stack.
Purpose
The purpose of this package is to:
- Provide a single source of truth for component interface definitions
- Ensure consistency across different implementations
- Facilitate modular development and component interchangeability
- Document the communication protocols between Autoware Core components
Structure
The package contains interface specifications for various components, including:
- Message definitions
- Service interfaces
- Action interfaces
Usage
To use these interface specifications in your component:
- Add this package as a dependency in your package.xml:
<depend>autoware_component_interface_specs</depend>
- Use the provided interfaces in your component code.
#include <autoware/component_interface_specs/localization.hpp>
// Example: Creating a publisher using the interface specs
using KinematicState = autoware::component_interface_specs::localization::KinematicState;
rclcpp::Publisher<KinematicState::Message>::SharedPtr publisher_ =
create_publisher<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>());
// Example: Creating a subscription using the interface specs
auto subscriber_ = create_subscription<KinematicState::Message>(
KinematicState::name,
autoware::component_interface_specs::get_qos<KinematicState>(),
std::bind(&YourClass::callback, this, std::placeholders::1));
Versioning
Each domain namespace declares a semantic Version (version.hpp) and a Specs tuple listing every interface it owns. 0.x denotes an unstable interface while the standard is stabilizing. Compatibility is decided on the MAJOR field only; is_compatible is the reference encoding of that rule for consumers that compile against this package. The deploy-time admission gate in autoware_component_interface_admission is a no-dependency leaf package, so it restates the same relation rather than calling is_compatible — the two must be changed together.
A domain declares its version, its Specs registry, and the ADL hook that spec_version<Spec>() resolves through in one macro, so the three cannot drift apart:
namespace autoware::component_interface_specs::control
{
struct ControlCommand { /* ... */ };
AUTOWARE_COMPONENT_INTERFACE_SPECS_DEFINE_DOMAIN(0, 1, 0, ControlCommand)
} // namespace autoware::component_interface_specs::control
Quality of service
Topic specs carry the QoS their endpoints are created with (depth, reliability, durability); get_qos<Spec>() turns that into an rclcpp::QoS.
Services have a QoS profile too, but not a per-spec one. Every create_service and create_client call takes ROS 2’s rmw_qos_profile_services_default — KEEP_LAST(10), RELIABLE, VOLATILE — unmodified, so all services really do run under identical conditions. Rather than repeat that profile on every ServiceSpec, it is declared once as service_qos in utils.hpp and returned by get_service_qos(). test_service_qos.cpp asserts it still equals the RMW default it mirrors, so a change to that default surfaces as a test failure instead of as silent drift between the specs and the wire.
C++ standard
The domain headers, version.hpp and utils.hpp are C++17, matching the CMAKE_CXX_STANDARD 17 that autoware_package() gives every Autoware target.
concepts.hpp needs C++20, because the standard library only exposes <concepts> in C++20 mode. A target that wants it opts in:
target_compile_features(<target> PRIVATE cxx_std_20)
CMake raises that one target to -std=c++20 and leaves every other target — and every C++17 consumer of the domain headers — on -std=c++17. This is what the package’s own generate_interface_manifest and gtest targets do, and it builds on Humble / gcc-11 (Ubuntu 22.04) as well as on Jazzy. Both targets are BUILD_TESTING-gated, so a C++20 compile failure in either could never break the header-only package for its C++17 consumers.
Below C++20, concepts.hpp is an empty header rather than a hard error, so including it is always safe. Test AUTOWARE_COMPONENT_INTERFACE_SPECS_HAS_CONCEPTS before naming anything it declares.
Interface manifest
interface_manifest.json is a machine-readable list of every registered interface: its domain, interface name, message or service type, kind, version, and the QoS its endpoints are created with. It is generated from the Specs tuples by the generate_interface_manifest tool and committed to the repository as the source of truth.
```json { “domain”: “control”, “interface”: “/control/command/control_cmd”, “type”: “autoware_control_msgs/msg/Control”, “kind”: “topic”, “version”: “0.1.0”, “qos”: { “history”: “keep_last”, “depth”: 1, “reliability”: “reliable”, “durability”: “volatile” }
File truncated at 100 lines see the full file
Changelog for package autoware_component_interface_specs
1.1.0 (2025-05-01)
- feat(component_interface_specs): use template type in get_qos function (#364) Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>
- docs(autoware_component_interface_specs): fix [README.md]{.title-ref} (#363)
- Contributors: Takagi, Isamu, Yutaka Kondo
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
feat(autoware_component_interface_specs): add RIHS01 type-hash lockfile with opt-in freshness gate (#1265)
- feat(autoware_component_interface_specs): add RIHS01 type-hash generator
- feat(autoware_component_interface_specs): commit type-hash lockfile with opt-in freshness gate
- ci(autoware_component_interface_specs): enable type-hash freshness gate on Jazzy PRs
* chore(autoware_component_interface_specs): use "build farm" and drop local cspell words Spell "buildfarm" as the two-word "build farm" everywhere it appears --the README and the type-hash test's comment -- so no dictionary entry is needed for it at all, and restore the root .cspell.json to its state on main by dropping both "buildfarm" and "RIHS". "RIHS" is a real domain term, so it belongs in the shared dictionary rather than in a per-repo override; it is being added there in autowarefoundation/autoware-spell-check-dict#140. The spell-check workflows pull that dictionary from the repository's main branch, so spell-check-differential stays red here until #140 merges.
* fix(autoware_component_interface_specs): cover the sensing domain in the type-hash generator generate_type_hashes.cpp's own comment states its domain list mirrors generate_interface_manifest.cpp, but the sensing domain header was missing from both the #include list and the per-domain collect<> calls. generate_interface_manifest.cpp already includes sensing.hpp, so the manifest and the lockfile silently covered different type sets: the lockfile never hashed sensing's VehicleVelocityConverterTwist (geometry_msgs/msg/TwistWithCovarianceStamped). test_type_hashes.cpp's covers_every_manifest_type test exists to catch exactly this kind of divergence; it failed once the lockfile was regenerated for the domains registered since this generator was written. Add the missing include and collect<cis::sensing::Specs> call so both generators walk the same eight domains.
* chore(autoware_component_interface_specs): refresh the type-hash lockfile Regenerate interface_type_hashes.jazzy.lock with generate_type_hashes now that per-domain versioning has landed for all eight domains. Twelve hash lines are added for types newly registered by those domains: MrmState, the two point-cloud-map services (GetDifferentialPointCloudMap, GetPartialPointCloudMap), TrackedObjects, TrafficLightGroupArray, five vehicle command/report types (ControlModeReport, GearCommand, HazardLightsCommand, TurnIndicatorsCommand, VelocityReport), ControlModeCommand, and sensing's TwistWithCovarianceStamped. One line is removed: sensor_msgs/msg/PointCloud2. Its PointCloudMap spec is deliberately excluded from the versioned Specs tuple in map.hpp because it carries a raw point cloud payload rather than a bounded interface message, so it was never part of the registered surface the generator walks. No previously committed hash changed. ---------
-
fix(autoware_component_interface_specs): declare the dependencies it includes (#1359) The package includes headers from packages it never declares. It builds today only because another declared dependency re-exports them, so a change in an unrelated repository can break it without anything here changing.
-
feat(autoware_component_interface_specs): register and version the control boundary specs (#1300)
-
feat(autoware_component_interface_specs): register and version the sensing boundary specs (#1303)
* test(autoware_component_interface_specs): add a shared spec test helper header Add test/spec_test_utils.hpp, a header-only helper used by the per-domain spec tests. It provides has_type<T, Tuple> for asserting membership in a domain's Specs tuple, and expect_topic_qos<Spec>() which pins a topic spec's declared name/depth/reliability/durability and the rclcpp::QoS that get_qos<Spec>() derives from them. Every expected value is passed in by the caller as a literal, so the assertions never compare the
File truncated at 100 lines see the full file