---
title: CARLA Simulation Framework
url: https://www.emergentmind.com/topics/carla-simulation-framework
type: topic
---

# CARLA Simulation Framework

The CARLA simulation framework is an open-source, modular, high-fidelity 3D simulator designed for the development, validation, and verification of autonomous driving systems. By offering advanced capabilities for sensor simulation, environment control, and seamless integration with state-of-the-art autonomous vehicle (AV) software stacks, CARLA is now widely used as a reference platform in both academic research and industry for AV perception, planning, control, and system-level testing. Its extensible architecture supports low-latency communication with robotics middleware (e.g., ROS 2), enabling realistic closed-loop simulation and reproducible experiments. The following sections provide a technical analysis of CARLA’s core system architecture, communication protocols, synchronization and control mapping, performance profile, integration workflow, and validation methodology.

## 1. System Architecture and Modular Components

CARLA’s simulation framework is composed of four principal blocks: the CARLA Simulator, the (modified) CARLA-ROS-Bridge, a newly designed CARLA-Autoware-Bridge, and the Autoware Core/Universe AV stack. These interact through well-defined interfaces, enabling modular, closed-loop experiments [2402.11239].

- **CARLA Simulator**: Implements the core physics engine, high-fidelity vehicle kinematics, and sensor simulation (e.g., LiDAR, cameras, IMU). Simulation management tasks—including clock control, weather, deterministic random-seed handling, map loading, and actor orchestration—are performed natively within CARLA.
- **Modified CARLA-ROS-Bridge**: Bridges the TCP/IP protobuf-based CARLA data streams to ROS 2 topics by unpacking, reserializing, and republishing sensor and ground-truth messages. It enforces lock-step time synchronization by acknowledging each sensor stream before advancing simulation time, ensuring determinism for downstream modules.
- **CARLA-Autoware-Bridge**: This intermediary translates between ROS 2 topics and Autoware Core/Universe-specific messages. It performs high-fidelity type conversions (e.g., `sensor_msgs/PointCloud2` to `autoware_auto_perception_msgs/LidarPointCloud`), remaps topics, manages QoS settings, and integrates both a PID-based longitudinal controller and a lateral steering mapping calibrated through scenario data.
- **Autoware Core/Universe**: The AV software stack subscribes to the sensor topics, performs localization, perception, planning, and outputs low-level control (`AckermannControlCommand`, consisting of target speed, acceleration, and steering angles).

A simplified data flow illustrates the architecture:
```
CARLA ←TCP/IP→ ROS-Bridge ―ROS 2→ CARLA-Autoware-Bridge ―remapped→ Autoware
Autoware ←remapped― CARLA-Autoware-Bridge ←ROS 2― ROS-Bridge ←TCP/IP― CARLA
```

## 2. Communication Protocols and Data Exchange

Communication between modules leverages parallel protocols and serialization schemes to support high-throughput, low-latency streaming of full-sensor payloads [2402.11239].

- **CARLA–ROS-Bridge**: Uses TCP/IP to transmit custom protobuf messages. Each message contains sensor data for a simulation tick, which are deserialized and re-published as native ROS 2 messages via DDS/RTPS (CDR serialization).
- **ROS 2 Topics**: Key sensor and vehicle status topics include:
  - Odometry (`nav_msgs/Odometry`)
  - LiDAR (`sensor_msgs/PointCloud2`)
  - Camera images (`sensor_msgs/Image`)
  - GNSS (`sensor_msgs/NavSatFix`)
  - IMU (`sensor_msgs/Imu`)
  - Vehicle status (`carla_ackermann_msgs/CarlaEgoVehicleStatus`)
- **Autoware Mappings**: The bridge converts standard ROS 2 sensor messages to Autoware’s custom types, for example:
  - LiDAR: `sensor_msgs/PointCloud2` → `autoware_auto_perception_msgs/LidarPointCloud`
  - Camera: `sensor_msgs/Image` → `autoware_auto_perception_msgs/Img`
  - GNSS: `sensor_msgs/NavSatFix` → `autoware_auto_msgs/GnssFix`
  - Control Output: `autoware_auto_control_msgs/AckermannControlCommand` (${v_{\rm tgt}}$, ${a_{\rm tgt}}$, ${\delta_{\rm tire}}$)

Message serialization is performed once at the ROS-bridge and, if necessitated by conversion, again at the CARLA-Autoware-Bridge; large data payloads (HD images, dense point clouds) are handled efficiently to avoid unnecessary memory copies.

- **Latency Metrics**: Average end-to-end latency ($\tau_\mathrm{avg}$) from sensor generation in CARLA to nearest Autoware callback is approximately 7.8 ms, with $\tau_\mathrm{max} < 15\,\mathrm{ms}$ under benchmark conditions (Table I).

## 3. Data Mapping, Synchronization, and Control Interface

Robust data mapping and synchronization are fundamental to deterministic, reproducible AV system evaluation. The framework implements [2402.11239]:

- **Coordinate Transformations**: CARLA uses a left-handed coordinate convention, while Autoware expects right-handed coordinates. The bridge applies the conversion:
  $$
  (x_r, y_r, z_r) = (x_c, -y_c, z_c)
  $$
- **Time Synchronization**: The ROS-bridge advances CARLA's world clock only after all sensor topics for the current frame have published and acknowledged, enforcing a lock-step execution model and ensuring reproducibility.
- **Sensor-to-Topic and State Mappings**: Sensor packages may require splitting (e.g., vehicle status to multiple reports), aggregation, or summarization to suit Autoware expectations.
- **Control Mapping**: Conversion of Autoware’s Ackermann-style commands to raw CARLA actuators is handled via:
  - **Longitudinal PID**: Error $e_v = v_{\rm tgt} - v_{\rm act}$ is regulated by $u(t)=K_pe_v + K_i\int e_v\,dt + K_d\,d e_v/dt$, mapping $u>0$ to throttle and $u<0$ to brake.
  - **Lateral Mapping**: Steering-tire angle ${\delta_{\rm tire}}$ is mapped to wheel angle with $\,{\delta_{\rm steer}} = K_{\rm map}\,{\delta_{\rm tire}}$, calibrated in high-curvature maps (e.g., Town10HD).

## 4. Performance Scaling and Computational Benchmarks

Performance evaluation emphasizes modular scalability, throughput, and bounded latency for sensor-rich, closed-loop AV stacks [2402.11239].

| Sensors                | Count    | Mean CPU [%] | Std CPU [%] | CARLA FPS |
|------------------------|----------|--------------|-------------|-----------|
| LiDAR (500k pts/s)     | 2        | 120.9        | 3.06        | 78.9      |
| Camera (1280×720)      | 1        | 77.1         | 2.04        | 41.0      |
| Release sensor kit     | 2 + 1    | 97.5         | 1.18        | 35.2      |

- **Latency Scaling**: For low-density LiDAR (100k pts/s), mean latency ($\tau$) is ≈ 3 ms. At 1M pts/s, $\tau$ increases to ≈ 12 ms; introducing multiple sensors (up to 4 LiDARs or 3 cameras) increases $\tau$ commensurate with aggregate payload but without nonlinear losses.
- **CPU Utilization and Framerate**: Dual LiDARs at 500k pts/s each and a single 720p camera (“release kit”) saturate ≈98% of one CPU core at ≈35 FPS.

## 5. Integration Workflow and Reproducibility

A systematic workflow ensures reproducible experimental setups for rigorous AV testing [2402.11239]:

1. Install CARLA 0.9.15 and Autoware Core/Universe (ROS 2 Humble).
2. Clone the `carla-simulator/ros-bridge` and `TUMFTM/Carla-Autoware-Bridge` repositories.
3. Build both packages in a ROS 2 workspace:
   ```
   colcon build --packages-select carla_ros_bridge carla_autoware_bridge
   ```
4. Prepare necessary Autoware dependencies:
   - Vehicle model: e.g., VW T2 2021
   - Sensor configuration: `sensor_kit.yaml`
   - Map: `town10hd_lanelet2.osm`
5. Launch sequence:
   a) CARLA server: `./CarlaUE4.sh -opengl -carla-map Town10HD`
   b) ROS-bridge: `ros2 launch carla_ros_bridge carla_client.launch.py host:=127.0.0.1 port:=2000`
   c) CARLA-Autoware bridge: `ros2 run carla_autoware_bridge bridge_node --ros-args -p sensor_config:='sensor_kit.yaml'`
   d) Autoware: `ros2 launch autoware_launch planning_with_sim.launch.py vehicle_model:='vw_t2_2021' map_path:='town10hd_lanelet2.osm'`

## 6. Use Cases, Scenario Validation, and Known Limitations

- **Scenario Validation**: The bridge has been validated on the Town10HD map using multiple sensor configurations and task settings:
  - Longitudinal: Constant-speed tracking ($8.33\,\mathrm{m/s}$) demonstrates PID-tuned accuracy within ±0.2 m/s.
  - Lateral: Successive 90° turns assess lane-keeping; steering mapping was critical for failure-free trajectory.
  - Closed-loop: Full-stack Autoware navigation (obstacle negotiation, start/end goal routing).

- **Limitations and Planned Extensions**:
  - Latency increases roughly linearly with LiDAR density due to computationally expensive coordinate transforms; GPU-based optimization is proposed.
  - OpenDrive to Lanelet2 (map) conversion is currently manual.
  - Only a single supported vehicle/map; future work includes scenario database integration with dynamic actors and environmental variation.
  - The system does not yet provide automated support for sensor failure injection or synchronous multi-map execution.

CARLA’s current bridge design demonstrates reliable, low-latency, real-time simulation enabling seamless validation of AV modules at system level. Its modularity, scenario reproducibility, and support for high-throughput sensor simulation make it suitable for state-of-the-art AV research, albeit with recognized avenues for scaling and automation improvements [2402.11239].

Source: https://www.emergentmind.com/topics/carla-simulation-framework