autoware_carla_interface

ROS 2 / Autoware Universe bridge for CARLA simulator

Thanks to https://github.com/gezp for ROS 2 Humble support for CARLA Communication. This ros package enables communication between Autoware and CARLA for autonomous driving simulation.

Supported Environment

Setup

Install

Prerequisites

1. Install CARLA 0.9.15: Follow the CARLA Installation Guide

2. Install CARLA Python Package: Install CARLA 0.9.15 ROS 2 Humble communication package

   • Option A: Install the wheel using pip
   • Option B: Add the egg file to your PYTHONPATH

3. Download CARLA Lanelet2 Maps: Get the y-axis inverted maps from CARLA Autoware Contents

Map Setup

1. Download the maps (y-axis inverted version) to an arbitrary location
2. Create the map folder structure in $HOME/autoware_data/maps:
   • Rename point_cloud/Town01.pcd → $HOME/autoware_data/maps/Town01/pointcloud_map.pcd
   • Rename vector_maps/lanelet2/Town01.osm → $HOME/autoware_data/maps/Town01/lanelet2_map.osm
3. Create $HOME/autoware_data/maps/Town01/map_projector_info.yaml with:

   projector_type: Local
   

Build

colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release

Run

1. Run carla, change map, spawn object if you need

   cd CARLA
   ./CarlaUE4.sh -prefernvidia -quality-level=Low -RenderOffScreen
   

1. Run Autoware with CARLA

   ros2 launch autoware_launch e2e_simulator.launch.xml \
       map_path:=$HOME/autoware_data/maps/Town01 \
       vehicle_model:=sample_vehicle \
       sensor_model:=carla_sensor_kit \
       simulator_type:=carla
   

For E2E planning with VAD:

   ros2 launch autoware_launch e2e_simulator.launch.xml \
       map_path:=$HOME/autoware_data/maps/Town01 \
       vehicle_model:=sample_vehicle \
       sensor_model:=carla_sensor_kit \
       simulator_type:=carla \
       use_e2e_planning:=true
   

1. Set initial pose (Init by GNSS)
2. Set goal position
3. Wait for planning
4. Engage

Viewing Multi-Camera View in RViz

The carla_sensor_kit includes 6 cameras providing 360-degree coverage (Front, Front-Left, Front-Right, Back, Back-Left, Back-Right). A multi-camera combiner node automatically combines all camera feeds into a single 2x3 grid view.

To view the combined camera feed in RViz:

1. In the Displays panel (left side), click the “Add” button
2. Select the “By topic” tab
3. Navigate to /sensing/camera/all_cameras/image_raw
4. Select “Image” display type
5. Click OK

The combined view shows all 6 cameras with labels: FL (Front-Left), F (Front), FR (Front-Right), BL (Back-Left), B (Back), BR (Back-Right).

Note: If you don’t need the multi-camera combiner (to save CPU resources), you can comment out the following line in launch/autoware_carla_interface.launch.xml:

File truncated at 100 lines see the full file

Changelog for package autoware_carla_interface

0.53.0 (2026-09-29)

• Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog

• feat(autoware_carla_interface): allow cameras to publish bgr8 (#13411) CARLA renders BGRA and fills the alpha channel with 255. Nothing downstream reads it, so publishing bgra8 spends a quarter of every camera message on a constant. Accept bgr8 as an image_encoding alongside bgra8 and mono8: it drops the alpha channel and nothing else, so a consumer that wants colour gets the same picture for three quarters of the bytes -- 4,320,000 instead of 5,760,000 for a 1600x900 frame. Unlike mono8 it costs no information, so it is the cheaper default for any colour consumer. The default stays bgra8. Claude-Session: https://claude.ai/code/session_011TMdPd8VUDxUrFtckxg2AQ Co-authored-by: Masaya Kataoka <<ms.kataoka@gmail.com>>

• fix(autoware_carla_interface): stamp each sensor measurement with the frame it was captured on (#13408)

• feat(autoware_carla_interface): let a sensor mapping set the CARLA capture rate (#13407)

• feat(autoware_carla_interface): publish CARLA vehicles as ground truth detections (#13321)

  * feat(autoware_carla_interface): publish CARLA vehicles as ground truth detections Adds an opt-in parameter, publish_ground_truth_objects (default: false, no behavior change), that publishes every CARLA vehicle except the ego to /perception/object_recognition/detection/objects. This feeds the perception stack from simulator truth instead of from sensor data, so tracking and prediction keep running on the real Autoware nodes downstream. It is useful when the vehicles come from an external traffic simulator that the sensor pipeline cannot see reliably, and when the goal is to exercise planning rather than detection. Publishing happens on a world.on_tick() callback, so the objects follow CARLA's cadence rather than the sensor loop, which only turns once every sensor has delivered its frame. The poses come out of the tick snapshot, so a tick costs no round trip to the server and every object in a message belongs to one frame. A snapshot carries only ids and poses, so what never changes about an actor -whether it is a vehicle to report, its class and its size - is looked up the first time that id appears and kept; in steady state a tick asks the server for nothing. Messages carry the bridge's clock rather than snapshot.timestamp. The two count from different starts, and stamping from the snapshot puts the objects far enough ahead of /clock that the tracker's output rate collapses. Classification comes from the CARLA blueprint base_type attribute, so the mapping needs no hand maintained table of blueprint ids. Velocity is left to the tracker: publishing it would need a world to object frame rotation that is easy to get wrong, and a wrong twist is worse for prediction than no twist. Pedestrians are not covered yet.

  * chore(autoware_carla_interface): keep the ground truth publisher's comments in the file's style Shorten the docstrings to one line each, replace the multi-line rationale comments with one-liners and drop a noqa the repository's flake8 does not need. No behavior change; the rationale stays in the pull request.

  * feat(autoware_carla_interface): apply the review suggestions to the ground truth publisher Add the bus label (CARLA spells the base_type "Bus") and publish the bounding box center instead of the actor origin, as suggested in review. The suggestions were applied through the review UI without a sign-off, so they are folded into this signed commit; the content is unchanged. Co-authored-by: Mete Fatih Cırıt <<mfc@autoware.org>> Co-authored-by: Masaya Kataoka <<ms.kataoka@gmail.com>> ---------Co-authored-by: Mete Fatih Cırıt <<mfc@autoware.org>> Co-authored-by: Masaya Kataoka <<ms.kataoka@gmail.com>>

• feat(autoware_carla_interface): add a tick follower mode for co-simul… (#13286)

• feat(autoware_carla_interface): publish CARLA traffic-light states, matched to the map by position (#13327)

  * feat(autoware_carla_interface): publish CARLA traffic-light states, matched to the map by position Bridge the CARLA server's traffic-light states into Autoware's perception output so a CARLA closed loop can run without camera-based recognition. The key problem is associating a CARLA traffic light with an Autoware [traffic_light_group_id]{.title-ref} (a [traffic_light]{.title-ref} regulatory-element id in the lanelet2 map). Instead of assuming the CARLA OpenDRIVE signal id equals the regulatory-element id (true only for maps auto-generated from the same OpenDRIVE) or hand-writing an id table, the bridge discovers the mapping geometrically: each CARLA light head is matched to the nearest lanelet2 light head and its state is published under every regulatory element that references that head. This works for hand-authored / Vector Map Builder maps too.

File truncated at 100 lines see the full file