autoware_sample_designs

autoware_sample_designs is a complete, working example of defining and launching a full Autoware system using Autoware System Designer.

It serves as the reference implementation for how to describe, configure, and deploy an Autoware autonomous driving stack using YAML-based system design — without writing ROS 2 launch files by hand.

What is Autoware System Designer?

Autoware System Designer is a toolset that lets you describe your entire software system in structured YAML files and automatically generates correct-by-construction ROS 2 launch files, parameter templates, and system visualization diagrams from them.

A system is composed of four entity types:

The build step collects node definitions from across the workspace (resolved via workspace.yaml), combines them with the system design files in this package, and generates launch files and a system visualization:

each ROS 2 package (core, universe, …)         ┐
  └── design/node/  *.node.yaml                │
                                               ├── autoware_system_designer
this package                                   │
├── design/node/    *.node.yaml  (optional)    │
├── design/module/  *.module.yaml              │
├── design/system/  *.system.yaml              │
└── design/parameter_set/ *.parameter_set.yaml ┘
                                               │
                                               ▼
                                               install/
                                               ├── systems.html
                                               ├── AutowareSample/
                                               │   ├── Runtime.launch.xml
                                               │   ├── LoggingSimulation.launch.xml
                                               │   └── PlanningSimulation.launch.xml
                                               └── ...node launchers...

The generated node diagram shows the full system topology including all modules, nodes, and topic connections:

Visualizing the System

After building, open the generated HTML page in your browser to interactively explore the full system graph:

# From your colcon workspace root
firefox install/systems.html
# or
google-chrome install/systems.html

The visualization page shows every node, module, topic connection, and operating mode defined in the system.

Package Structure

autoware_sample_designs/
├── design/
│   ├── node/              # System-specific node definitions (wrapper/optional nodes only)
│   ├── module/            # Reusable subsystem modules (sensing, perception, …)
│   ├── system/
│   │   └── AutowareSample.system.yaml   # Top-level system definition
│   └── parameter_set/     # Parameter overrides per node, per mode
├── config/                # Shared parameter YAML files (owned by this package)
├── launch/                # Hand-written wrapper launch files for legacy integration
├── urdf/                  # Vehicle URDF
├── workspace.yaml         # Provider resolution rules for the system designer
└── CMakeLists.txt

The AutowareSample.system.yaml defines four operating modes — Runtime, LoggingSimulation, PlanningSimulation, and E2ESimulation — each with mode-specific component overrides and connections.

Relationship with autoware_launch

autoware_sample_designs is independent of autoware_launch as a system builder. The system designer generates its own launch files and manages its own system topology. autoware_launch does not control how this system is structured or launched.

The only connection is that some parameter set files reference shared parameter YAML files from autoware_launch (e.g., tracker, fusion, and filter configs that are common across vehicle variants):

# design/parameter_set/sample_system_perception.parameter_set.yaml
parameters:
  - node: /perception/object_recognition/detection/clustering/...
    param_files:
      # shared param file from autoware_launch — values only, no launch dependency
      - param_path: $(find-pkg-share autoware_perception_launch)/config/...

This is a runtime parameter file lookup — autoware_launch is not involved in building or launching the system. Node-specific parameters that belong to this vehicle configuration live in config/ inside this package itself.

Building

File truncated at 100 lines see the full file

Changelog for package autoware_sample_designs

0.53.0 (2026-10-13)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base

• feat(autoware_sample_designs): compose the AD API, system and vehicle components from design modules (#1976)

  * fix(control, planning): connect the operation mode state and velocity limit inputs Wires collision_detector's operation_mode_state and remaining_distance_time_calculator's planning_velocity through the module designs; their node designs now declare the fixed topic names as remap targets.

  * fix(planning): connect the internal velocity limit path to the selector Forwards motion_velocity_planner's velocity_limit and clear_velocity_limit up to ScenarioPlanning and feeds them into external_velocity_limit_selector, whose internal inputs were unconnected.

  * fix(control, planning): connect the remaining module inputs to their sources Wires the operation mode transition manager's gate and selector inputs, the stop mode operator's vehicle status, the manual lane change handler's route availability and preferred primitive service, the parking costmap, and the route marker. Exposes the vehicle control mode service, the preferred lane service and the system hazard lights command as component interfaces.

  • fix(planning): follow the hazard lights selector input rename
  • fix(planning): add steering_status subscriber to various planning modules
  • feat(vehicle): add vehicle wrapper and launch file for vehicle interface
  • style(pre-commit): autofix
  • fix(planning): add planning factors publishers and connections for various modules
  • refactor(autoware_sample_designs): compose the AD API from design modules
  • Refactor ADAPI module structure and enhance planning factors
  • Updated AdapiRvizHelpers.module.yaml to include helper prefixes for instances and connections.
  • Modified AutowareSample.system.yaml to reorganize ADAPI components, introducing default_adapi for better structure.
  • Expanded planning factors in Planning.module.yaml, LaneDriving.module.yaml, ScenarioPlanning.module.yaml, and associated modules to include additional factors for improved behavior and motion planning.
  • Enhanced connections in behavior planning and motion planning modules to accommodate new planning factors.
  • Ensured consistency across scenario planning modules by aligning publisher and subscriber connections for new planning factors.
  • refactor: reorganize clients and servers in module configurations
  • fix(control): drop the collision detector operation mode link bound globally by the node design
  • implement system modules
  • vehicle modules and nodes, need validations
  • fix api topic remapped
  • reorganize to adapi and api
  • fix: update perception obstacle segmentation filters for clarity and functionality

  * refactor: update trigger conditions and outcomes in topic tools configuration ---------Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

• refactor(map)!: migrate tier4_map_launch to autoware_map_launch with a separate config package (#1980) Part of #1939 (map item). Splits the map launch stack into unit launchers under autoware_universe_launch/autoware_map_launch and moves its parameter tree into the data-only autoware_map_config, with component_map.launch.xml as the composition root. The resolved launch graph is unchanged. Co-authored-by: Claude Opus 5 <<noreply@anthropic.com>>

• refactor(localization)!: migrate tier4_localization_launch to autoware_localization_launch with a separate config package (#1971)

  * refactor(localization)!: migrate tier4_localization_launch to autoware_localization_launch with a separate config package Move the localization launch stack out of the product layer and split its parameter tree into autoware_localization_config. localization.launch.xml resolves every parameter file through localization_config_pkg; the launch graph is unchanged.

  * refactor(localization): move the localization design modules alongside the localization launch package The localization modules move into autoware_localization_launch/design/module, matching the planning and control layout; the parameter set and the wrapper resolve parameter files from autoware_localization_config.

  * refactor(localization): flatten pose/twist source selection into per-estimator junctions pose_source/twist_source string parsing

File truncated at 100 lines see the full file