feat: autoware system designer

[technolojin]

Description

DISCUSSION https://github.com/orgs/autowarefoundation/discussions/6760

ISSUE #6793

autoware system designer: https://github.com/autowarefoundation/autoware_system_designer

• implementation structure

• configuration so called autoware_system_design_format

• diagram visualization

• auto-generated ros launcher

How was this PR tested?

build

# repositories
vcs import src < repositories/autoware.repos
vcs import src < repositories/autoware-nightly.repos
vcs pull src

# pull PRs
cd src/universe/autoware_universe
gh pr checkout 12070

cd src/launcher/autoware_launch
gh pr checkout 1751

cd src/sensor_component/external/nebula
# for latest version
gh pr checkout 403
# for stable version
gh pr checkout 404

# build
colcon build --packages-up-to autoware_system_designer autoware_system_design_examples autoware_sample_deployment

launch

logging simulator

# launch logging simulator
ros2 launch '/your/workspace/install/autoware_sample_deployment/share/autoware_sample_deployment/exports/AutowareSample/launcher/LoggingSimulation/main_ecu/main_ecu.launch.xml' 

AWSIM

#  launch AWSIM simulator
ros2 launch '/your/workspace/install/autoware_sample_deployment/share/autoware_sample_deployment/exports/AutowareSample/launcher/E2ESimulation/main_ecu/main_ecu.launch.xml' 

planning simulator

# launch planning simulator
ros2 launch /your/workspace/install/autoware_sample_deployment/share/autoware_sample_deployment/exports/AutowareSample/launcher/PlanningSimulation/main_ecu/main_ecu.launch.xml

# open rviz for control
QT_QPA_PLATFORMTHEME=qt5ct rviz2 -d /your/workspace/install/autoware_launch/share/autoware_launch/rviz/autoware.rviz

visualization

# visualization
google-chrome /your/workspace/install/systems.html

[github-actions]

Thank you for contributing to the Autoware project!

🚧 If your pull request is in progress, switch it to draft mode.

Please ensure:

• You've checked our contribution guidelines.
• Your PR follows our pull request guidelines.
• All required CI checks pass before marking the PR ready for review.

[paulsohn]

First of all, I like to appreciate your great work. I have some opinions for the detail:

• while I support the idea to maintain launch files (or its source) in more controllable way, it might cause a strong lock-in effect for launcher to your system. I would like to have a backup plan to discontinue system designer and return to traditional launcher files if we consider necessary.
• I would say that launch artifact itself should be present before build (i.e. it should be autogenerated and available as source level, not compiled). In this way we can ensure transparency (1) for us developers that the launch file works as we intended, (2) and for current and future tools that trace launch file statically even before build.

---

More context for (2): as a former user of Bazel, I don't really like the misalignment between build stage and launch stage requirements. For example, v0.3.x nebula supports depending on only necessary components, but our sample sensor kits cannot enjoy this improvement, and our package.xml need to depend on the complete bundle.

Still work in progress, but I want to share my milestones here. I am working planning to work on designing an enhanced launcher from existing ros2 launch:

1. 'dry run mode' for which generates the resolved launch.xml file, which can then be tested whether arguments are passed correctly, or visualized using ROS 2 visualization tool
2. compiler-integrated launcher which detects and builds packages only necessary in a certain launch flow (ignoring depends in package.xml; depends info is now stored in per launch file). I'm not sure if this is even possible, especially when an absolute path is passed into <include from=""/> instead of a package and a relative path from it.

cc @mojomex

[Owen-Liuyuxuan]

@paulsohn

compiler-integrated launcher which detects and builds packages only necessary in a certain launch flow (ignoring depends in package.xml; depends info is now stored in per launch file). I'm not sure if this is even possible, especially when an absolute path is passed into instead of a package and a relative path from it.

Some plugins and libraries are used in the code, but not from the launcher. So we need a place for people to write the dependencies on packages.xml. I think it will be very difficult to skip this.

[paulsohn]

@Owen-Liuyuxuan Yes, I think it will really take lots of efforts and don't know even if it's possible for now.

In the meantime it would be great if we have something directly in launcher, not packages.xml:

<build_depends>
  <build_depend>dep1</build_depend>
  <build_depend>dep2</build_depend>
</build_depends>

... AND fallback to package.xml build_depend list if such entry does not exist. For now I'm just daydreaming on milestone 2, but it seems worthy to discuss.

[technolojin]

@paulsohn @Owen-Liuyuxuan
Thank you for your opinions.
Can you please discuss in https://github.com/orgs/autowarefoundation/discussions/6760?

[technolojin]

@mitsudome-r

I would like to check this PR

1. is autoware-nightly.repos the right file to be updated? or also autoware.repos?
2. the health-check(main) failed. It supposed not to be related with current update.

[mitsudome-r]

@technolojin If we are going to add under core/ directory, we should add them to autoware.repos.
autoware.repos file also needs to have a released version to be specified so you need to make a release (i.e., make a tag) to system_designer.

[technolojin]

@mitsudome-r when other reviews are finished, I will bring back to open with updates.

[technolojin]

autowarefoundation/autoware_launch#1751
autoware_launch will require the autoware system designer in workspace.
this PR shall be merged before the autoware_launch introduction

[mitsudome-r]

Build on arm was failing due to communication issue to runner so I'm rerunning the test just in case.

[technolojin]

I added build test to the autoware_system_designer repository autowarefoundation/autoware_system_designer#34

[xmfcx]

@mitsudome-r This is unrelated to the PR. The docker-build (main-arm64) runner got killed mid-build due to CPU/memory starvation -- the annotation on the job confirms:

"The hosted runner lost communication with the server. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error."

---

The main and nightly Docker builds both passed; only main-arm64 failed after running for ~1h47m. The "Build 'Autoware'" step has no logs captured because the runner was killed before it could flush them.

Root cause: colcon build in build_and_clean.sh uses all available cores by default. On the public ubuntu-22.04-arm runners (4 vCPUs / 16GB RAM), this leads to OOM when multiple C++ packages compile in parallel.

• Created fix(ci): limit CPU cores in Docker build to prevent ARM64 runner OOM #6956 to fix this by using taskset to limit colcon to nproc - 1 cores, leaving one for OS/Docker/BuildKit overhead.

[xmfcx]

@technolojin Is there a reason why this was not added to autoware.repos too?

https://github.com/autowarefoundation/autoware/actions/runs/24238221304/job/70766076243?pr=6958#step:12:4263

 > [rosdep-universe-depend 4/5] RUN /autoware/resolve_rosdep_keys.sh /autoware/src "humble"   > /rosdep-universe-depend-packages.txt   && cat /rosdep-universe-depend-packages.txt:
9.666 ERROR: no rosdep rule for 'autoware_system_designer'

Failed but not sure if related, still investigating.

But in general, we don't want to have a repo to only be in nightly.

• autoware.repos provides hash or version
• autoware.nightly acts as an overlay to override it to main or a branch

[technolojin]

@xmfcx
I thought a new concept may be tested under nightly and introduced after a good validation.
Anyway, thank you for your check and fix #7000

I confirmed the issue about cmake macros refers hard-coded paths. autowarefoundation/autoware_system_designer#46

The root cause is fixed in v0.3.2 autowarefoundation/autoware_system_designer#48 and it would be introduced to the autoware #7010

can you review the version update PR #7010 ?

then We may can bring back the autoware_launch PR autowarefoundation/autoware_launch#1814