Principle:CARLA simulator Carla Simulation Configuration
| Knowledge Sources | |
|---|---|
| Domains | Autonomous Driving Simulation, Real-Time Systems |
| Last Updated | 2026-02-15 00:00 GMT |
Overview
Simulation configuration controls the fundamental execution parameters of a virtual environment, determining how time advances, whether rendering occurs, and how deterministic the simulation behaves.
Description
Configuring a simulation involves setting global parameters that govern the behavior of the entire virtual world. The most critical configuration choices in autonomous driving simulation are:
- Synchronous vs. Asynchronous mode: In asynchronous mode (the default), the server runs as fast as possible and clients receive state updates whenever they query. In synchronous mode, the server waits for an explicit tick command from the client before advancing the simulation by one step. Synchronous mode is essential for reproducible experiments, data collection pipelines, and reinforcement learning training loops.
- Fixed vs. Variable time step: A fixed time step ensures each simulation tick advances by a constant duration (e.g., 0.05 seconds), regardless of real-world wall clock time. This guarantees deterministic physics and sensor output. A variable time step lets the simulation advance by the actual elapsed real time, which is useful for interactive visualization but breaks reproducibility.
- Rendering mode: Disabling rendering (no_rendering_mode) eliminates the GPU overhead of producing visual frames, dramatically increasing simulation throughput. This is valuable for training scenarios where camera images are not needed.
- Substepping: Physics substepping controls how many internal physics iterations occur per simulation tick, balancing accuracy against performance.
Usage
Configure simulation settings whenever you need to:
- Ensure deterministic behavior -- Enable synchronous mode with a fixed time step for reproducible sensor data and physics.
- Maximize throughput -- Disable rendering and use synchronous mode to run simulation as fast as the CPU allows.
- Interactive exploration -- Use asynchronous mode with variable time step for real-time visualization and manual driving.
- Sensor data collection -- Use synchronous mode to guarantee every sensor captures data at each tick without frame drops.
Theoretical Basis
Time advancement models:
Asynchronous mode:
while server_running:
dt = wall_clock_elapsed()
world.step(dt)
broadcast_state()
Synchronous mode:
while server_running:
wait_for_client_tick()
dt = fixed_delta_seconds # constant, e.g., 0.05s
world.step(dt)
broadcast_state()
Determinism requirements:
For a simulation run to be fully deterministic, the following conditions must hold:
| Condition | Setting |
|---|---|
| Time advancement is constant | fixed_delta_seconds > 0 |
| Client controls tick rate | synchronous_mode = True |
| Same random seed | Set via Traffic Manager |
| Same map and actor configuration | Identical spawn sequence |
Performance trade-offs:
Throughput = f(rendering, physics_substeps, sensor_count)
no_rendering_mode=True --> ~10x faster simulation ticks
fixed_delta_seconds=0.1 --> 2x fewer ticks per simulated second vs 0.05
substepping=False --> faster but less accurate collision detection
Settings application semantics: When new settings are applied, the server acknowledges the change and returns a frame ID. All subsequent ticks use the new settings. In synchronous mode, the settings take effect on the next tick call.