Principle:CARLA simulator Carla Batch Command Execution
| Knowledge Sources | |
|---|---|
| Domains | Autonomous Driving Simulation, Client-Server Architecture |
| Last Updated | 2026-02-15 00:00 GMT |
Overview
Batch command execution is a pattern for grouping multiple simulation commands into a single server round-trip, reducing network overhead and ensuring atomic multi-step operations during bulk actor creation.
Description
In a client-server simulation architecture, each command sent from the client to the server incurs network latency and serialization overhead. When spawning large numbers of actors (e.g., 100+ NPC vehicles for traffic generation), issuing individual spawn commands becomes a performance bottleneck. Batch command execution addresses this by:
- Bundling multiple commands into a single message sent to the server
- Executing all commands within the same server tick, ensuring temporal consistency
- Chaining dependent commands so that the output of one command feeds into the next (e.g., spawn a vehicle, then immediately set it to autopilot)
- Returning results for all commands in a single response, allowing the client to check for failures
The batch pattern is particularly important for traffic generation workflows where the sequence "spawn vehicle, then configure autopilot" must happen atomically. Without batching, a vehicle could exist for several ticks without autopilot, leading to unpredictable behavior during the gap.
Command Chaining
A critical feature of batch execution is command chaining via a .then() mechanism. This allows a follow-up command to reference the actor created by a preceding command before that actor actually exists. The server resolves these forward references at execution time.
The chaining pattern supports the following workflow:
- Create a SpawnActor command with a blueprint and transform
- Chain a SetAutopilot command using a FutureActor placeholder
- The server executes the spawn, obtains the real actor ID, substitutes it into the chained command, and executes the autopilot command
Usage
Use batch command execution when you need to:
- Spawn more than a handful of NPC vehicles or pedestrians simultaneously
- Ensure that spawn and configuration happen atomically within a single tick
- Minimize client-server round-trips in performance-sensitive scenarios
- Perform bulk operations like destroying all traffic actors at scenario end
Theoretical Basis
Command Pattern
Batch execution implements the Command design pattern from object-oriented design, where each operation is encapsulated as a self-contained command object. This provides several advantages:
Command = (operation_type, parameters, optional_chained_command)
Batch = [Command_1, Command_2, ..., Command_N]
Server.execute(Batch):
results = []
for cmd in Batch:
result = execute_single(cmd)
if cmd.has_chain() and result.success:
chained_cmd = cmd.chain.resolve(result.actor_id)
chain_result = execute_single(chained_cmd)
results.append(chain_result)
else:
results.append(result)
return results
Future/Promise Pattern
The FutureActor placeholder follows the Future/Promise concurrency pattern. At command construction time, the actor does not yet exist, so a symbolic reference (FutureActor) is used. The server resolves this reference when executing the command chain:
FutureActor = symbolic_reference()
SpawnCommand = SpawnActor(blueprint, transform)
ChainedCommand = SetAutopilot(FutureActor, enabled=True, tm_port=8000)
FullCommand = SpawnCommand.then(ChainedCommand)
# At execution time:
# 1. Server executes SpawnCommand -> returns actor_id = 42
# 2. Server replaces FutureActor with 42 in ChainedCommand
# 3. Server executes SetAutopilot(actor_id=42, enabled=True, tm_port=8000)
Network Efficiency Analysis
For N vehicles, the network cost comparison:
| Approach | Round-Trips | Latency (at 1ms RTT) |
|---|---|---|
| Individual spawn + configure | 2N | 2N ms |
| Batched spawn, then individual configure | N + 1 | (N + 1) ms |
| Batched spawn with chained configure | 1 | 1 ms |
For 200 NPC vehicles at a typical local RTT of 1ms, batched chaining reduces total spawn time from ~400ms to ~1ms, a 400x improvement.
Synchronous vs Asynchronous Batch
Batch execution can operate in two modes:
- Asynchronous (
apply_batch): Commands are sent to the server and the client continues immediately without waiting for results. Faster but provides no feedback on success or failure. - Synchronous (
apply_batch_sync): Commands are sent and the client blocks until all results are returned. Each result contains anerrorfield indicating success or failure, and anactor_idfor successful spawns.
For traffic generation, synchronous mode is preferred because it allows the client to track which vehicles were successfully spawned and handle failures gracefully.