feat: add docker-compose demo for CARLA

[mitsudome-r]

Description

#7079

Adds a Docker Compose demo that brings up CARLA and Autoware.

The stack is split into four services:

• carla-simulator — carlasim/carla:0.9.16 running CarlaUE4.sh -prefernvidia -quality-level=Low -nosound. Healthy once port 2000 accepts a TCP connection.
• carla-interface — autoware:universe-cuda-jazzy running autoware_carla_interface.launch.xml standalone. Healthy once an actor with role_name == ego_vehicle exists in the current CARLA episode.
• spectator-follow — autoware:universe-cuda-jazzy running ros2 run autoware_carla_interface spectator_follow, so the CARLA spectator camera chases the ego instead of staying where the simulator window started.
• autoware — autoware:universe-cuda-jazzy running e2e_simulator.launch.xml with simulator_type:=carla and launch_simulator_interface:=false, since the interface has its own container.

Notable points:

• Services are wired with depends_on: condition: service_healthy, so a cold docker compose up starts CARLA, waits for the server, starts the bridge, waits for the ego to spawn, and only then launches Autoware — no races against the CARLA client connect timeout.
• The Autoware image does not ship the CARLA Python API. The two services that talk to the CARLA server (carla-interface, spectator-follow) fetch the matching manylinux wheel for the container's Python version into the user site-packages on first run. That bootstrap lives in the x-carla-python-api YAML anchor at the top of the compose file, which is also where the CARLA version (0.9.16) is pinned.
• Running the bridge in its own container means it can be restarted on its own (e.g. when CARLA changes maps) without tearing down the Autoware stack.
• Maps and ML models come from the host via a bind mount of ~/autoware_data (create_host_path: false, so a missing directory fails loudly instead of being silently created empty). HOST_UID/HOST_GID default to 1000.
• traffic light recognition does not work since CARLA map does not encode traffic light information
• Requires manual download of CARLA Town01 map. I will create a separate PR to make this step simpler so that users can download the map just like planning-simulator maps.

How was this PR tested?

• docker compose up on a host with an NVIDIA GPU and the NVIDIA Container Toolkit, with Town01 extracted to ~/autoware_data/maps/Town01: the CARLA window comes up, the bridge connects and spawns the ego, RViz shows sensor data, and Init by GNSS → set goal → engage drives the vehicle.

[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.

[youtalk]

I understand that the autoware repository was split off to keep the container simple, specifically into the openadkit repository. Would a pull request directly to the openadkit repository not work for this?

[xmfcx]

This makes use of our existing images and extends the functionality instead of creating a different way of constructing the images like openadkit. I think this compose file + demo is in the right place with this PR 👍

I will review soon.

[xmfcx]

I ran this demo end to end on an RTX 3090 host. Used universe-cuda-jazzy-1.9.0 plus model data from the artifacts playbook at tag 1.9.0. The vehicle drove Town01 autonomously and arrived at the goal. On the tag-matched run every node loaded, lidar_centerpoint included. Nice work.

I have some suggestions: