CARLA Simulation Framework

• CARLA Simulation Framework is an open-source, modular 3D simulator that models vehicle dynamics and sensor inputs for autonomous driving research.
• It leverages integrated components like the CARLA-ROS-Bridge and CARLA-Autoware-Bridge to ensure precise data mapping and deterministic, closed-loop simulations.
• Performance benchmarks show low latency (≈7.8 ms average) and scalable computational efficiency, making it ideal for reproducible system-level testing.

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 (Kaljavesi et al., 2024).

• 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 (Kaljavesi et al., 2024).

• 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 (Kaljavesi et al., 2024):

• 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 (Kaljavesi et al., 2024).

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 (Kaljavesi et al., 2024):

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 (Kaljavesi et al., 2024).