Principle:CARLA simulator Carla Simulation Replay
| Knowledge Sources | |
|---|---|
| Domains | Simulation, Recording |
| Last Updated | 2026-02-15 00:00 GMT |
Overview
Simulation replay deterministically recreates a previously recorded simulation session by restoring actor states frame-by-frame from a binary log file, enabling exact reproduction of past scenarios.
Description
Replay is the counterpart to recording: while recording captures simulation state to a binary log, replay reads that log and reconstructs the simulation state at each frame. During replay, the CARLA server spawns the same actors that existed in the original recording, positions them at their recorded transforms, and applies their recorded states (traffic light phases, vehicle controls) at each tick.
The replay system supports several powerful features:
- Time windowing: Replay can start at any point in the recording and run for a specified duration, enabling targeted inspection of specific segments.
- Camera following: A specific actor ID can be designated for the spectator camera to follow during replay, providing a first-person or chase-camera view of that actor's journey.
- Sensor replay: When enabled, sensors that were attached to actors during the original recording are recreated and produce output during replay, enabling sensor data regeneration from recorded scenarios.
- Deterministic reproduction: The replay produces the exact same actor positions and states as the original recording, regardless of the current simulation settings, because transforms are applied directly from the log rather than computed by the physics engine.
During replay, manually controlled actors or new spawns are not possible -- the world is entirely driven by the recording data. This ensures fidelity to the original scenario.
Usage
Use simulation replay when you need to:
- Debug a failure by replaying the exact scenario that caused an issue and inspecting it from different perspectives.
- Regenerate sensor data by replaying a scenario with different sensor configurations than the original recording.
- Demonstrate scenarios to stakeholders by replaying recorded events with controlled camera angles.
- Validate algorithms by running perception or planning code against replayed scenarios to compare results.
- Perform temporal analysis by replaying specific time windows of interest identified through recording introspection.
Theoretical Basis
Deterministic replay is based on the principle of state injection: rather than computing the next state from physics and control inputs, the replay system directly sets each actor's transform and state from the recorded values at each tick. This makes the replay independent of the simulation's physics engine and guarantees exact reproduction of the original scenario.
The replay operates in open-loop mode: actor transforms are applied unconditionally from the log, with no feedback from the physics engine. Between recorded frames, the system performs linear interpolation of actor transforms to produce smooth motion at the current simulation frame rate, even if it differs from the original recording's frame rate. This interpolation is disabled at time factors above 2.0x to avoid computational overhead during fast-forward.
Time windowing is implemented through log seeking: the replay system scans the recording file to the frame nearest the requested start time, spawns all actors that should exist at that point (including those spawned before the start time and not yet destroyed), and begins replaying from that frame. This requires the recording format to support efficient scanning, which is achieved through the frame-delimited record structure.
The follow_id mechanism works by setting the spectator camera's transform relative to the followed actor at each tick, providing a stable viewpoint that tracks the actor through the world. This is implemented as a post-replay-tick camera update rather than a modification to the replay data itself.