Jump to content

Connect Leeroopedia MCP: Equip your AI agents to search best practices, build plans, verify code, diagnose failures, and look up hyperparameter defaults.

Workflow:CARLA simulator Carla Simulation Recording and Replay

From Leeroopedia
Knowledge Sources
Domains Autonomous_Driving, Simulation, Testing
Last Updated 2026-02-15 12:00 GMT

Overview

End-to-end process for recording a CARLA simulation session to a binary file and replaying it with adjustable speed, time control, and event querying for scenario analysis and debugging.

Description

This workflow covers the complete simulation recording and replay pipeline. Recording captures all actor transforms, traffic light states, vehicle controls, and walker movements into a compact binary file. Replay reconstructs the recorded session, re-spawning all actors and replaying their movements frame by frame. The spectator camera can follow a specific actor during replay. Additional query capabilities allow extracting specific events (collisions, blocked vehicles) from recordings for automated analysis. The recorder supports variable-speed playback and time jumping for efficient scenario review.

Usage

Execute this workflow when you need to capture a simulation scenario for later analysis, replay a specific traffic situation for debugging, create reproducible test scenarios for regression testing, or extract collision and near-miss events from recorded driving sessions.

Execution Steps

Step 1: Start Recording

Begin recording the simulation session by calling the recorder API with a filename. The recorder captures all actor lifecycle events (spawn, destroy), transforms per frame, traffic light states, vehicle physics states, and optional additional data (bounding boxes, kinematics). The recording starts immediately and runs until explicitly stopped.

Key considerations:

  • Recording files use the .rec extension by convention
  • Filenames with path separators (/, \, or :) are treated as absolute paths; otherwise files are saved to the server's default directory
  • The additional_data flag enables recording of bounding boxes and vehicle physics at the cost of larger file size
  • Recording runs on the server side and adds minimal overhead to simulation performance

Step 2: Run the Simulation Scenario

While recording is active, run the desired simulation scenario. This may include spawning traffic, executing a driving algorithm, or allowing manual control. All actor movements and state changes are captured automatically. The recorder handles actor creation and destruction events during the session.

Key considerations:

  • All actors spawned during recording are captured, including vehicles, walkers, and sensors
  • Traffic Manager behavior is recorded as vehicle movements, not as TM commands
  • Environmental changes (weather, lighting) are not recorded in the current implementation

Step 3: Stop Recording

End the recording session and finalize the binary file. The recorder flushes all buffered data and closes the file. The recording is immediately available for replay and querying.

Key considerations:

  • Always stop recording explicitly; abnormal termination may corrupt the file
  • Note the recording duration for replay planning

Step 4: Inspect Recording Metadata

Query the recording file for its contents without replaying it. The file info API reveals the total duration, map name, number of frames, and all actor spawn/destroy events with their types and IDs. This information is essential for planning targeted replays.

Key considerations:

  • show_recorder_file_info provides a summary or detailed frame-by-frame breakdown
  • The 'hero' role_name identifies the ego vehicle for camera tracking during replay
  • Actor IDs from the info output can be used to follow specific vehicles during replay

Step 5: Replay the Recording

Start replay of the recorded file with configurable parameters: start time offset, duration, and an actor ID for the spectator camera to follow. The replay re-creates all recorded actors on the correct map and drives them through their recorded trajectories.

Key considerations:

  • Replay automatically loads the correct map if it differs from the current one
  • The follow_id parameter attaches the spectator camera to a specific actor
  • Start time and duration allow replaying specific segments without watching the full recording
  • Setting follow_id to 0 uses the default camera behavior

Step 6: Control Playback Speed

Adjust the replay speed in real-time using the time factor API. Normal speed is 1.0, values above 1.0 accelerate playback, and values below 1.0 create slow-motion replay. Speed can be changed dynamically during replay for detailed analysis of specific moments.

Key considerations:

  • Time factor of 2.0 plays at double speed; 0.5 plays at half speed
  • Speed changes take effect immediately without restarting replay
  • Very high speed factors may cause visual artifacts due to interpolation

Step 7: Query Recorded Events

Extract specific events from the recording using the query APIs. Collision queries filter by actor types (vehicle-vehicle, vehicle-pedestrian, etc.). Blocked actor queries find vehicles that remained stationary beyond a threshold time and distance, indicating traffic jams or deadlocks.

Key considerations:

  • Collision queries use type filters: 'v' for vehicles, 'w' for walkers, 'a' for any, or specific type_id strings
  • Blocked actor queries require minimum time (seconds) and minimum distance (centimeters) thresholds
  • Query results include frame numbers and timestamps for correlating events with replay positions

Execution Diagram

GitHub URL

Workflow Repository