Principle:CARLA simulator Carla Blueprint System
| Knowledge Sources | |
|---|---|
| Domains | Autonomous Driving Simulation, Software Design Patterns |
| Last Updated | 2026-02-15 00:00 GMT |
Overview
A blueprint system is a factory pattern that decouples actor type definitions (including configurable attributes) from their instantiation, enabling flexible creation of diverse simulation entities from a shared catalog.
Description
In autonomous driving simulation, the world is populated with many types of entities: sedans, trucks, bicycles, pedestrians, traffic lights, cameras, LiDAR sensors, and more. Each entity type has a set of configurable properties (color, number of wheels, sensor resolution, field of view, etc.) that must be specified before the entity is created.
The blueprint system addresses this by maintaining a library of blueprints -- template objects that describe everything needed to instantiate an actor of a given type. Each blueprint has:
- A unique identifier (e.g., "vehicle.tesla.model3", "sensor.camera.rgb").
- A set of attributes with types, default values, and optionally a list of recommended values.
- Tags for categorization (vehicle, sensor, walker, static, etc.).
The blueprint library is read-only and provided by the server based on the currently loaded content. Clients query the library, optionally filter it, configure individual attributes on a blueprint instance, and then pass it to a spawning function.
This pattern provides several benefits:
- Discoverability: Clients can enumerate all available actor types without hardcoding identifiers.
- Configurability: Attributes can be customized per-instance (e.g., different colors for each vehicle).
- Extensibility: New actor types can be added to the server without changing client code.
- Validation: The blueprint validates attribute values before spawning, catching errors early.
Usage
Use the blueprint system whenever you need to:
- Discover available actors -- Browse the catalog of vehicles, sensors, or walkers available in the simulation.
- Filter by category -- Retrieve only vehicles, only sensors, or specific models using wildcard patterns.
- Customize appearance -- Set vehicle color, sensor resolution, or other attributes before spawning.
- Randomize traffic -- Select random blueprints from the library to create diverse traffic scenarios.
Theoretical Basis
Blueprint hierarchy:
BlueprintLibrary
+-- ActorBlueprint: "vehicle.tesla.model3"
| +-- Attribute: "color" = "0,0,0" (RGB string)
| +-- Attribute: "number_of_wheels" = 4 (int, not modifiable)
| +-- Attribute: "role_name" = "autopilot" (string)
+-- ActorBlueprint: "sensor.camera.rgb"
| +-- Attribute: "image_size_x" = 800 (int)
| +-- Attribute: "image_size_y" = 600 (int)
| +-- Attribute: "fov" = 90.0 (float)
+-- ActorBlueprint: "walker.pedestrian.0001"
+-- Attribute: "is_invincible" = False (bool)
+-- Attribute: "speed" = 1.4 (float)
Filter pattern matching:
The filter operation uses Unix-style wildcard (glob) patterns:
| Pattern | Matches |
|---|---|
| "vehicle.*" | All vehicle blueprints |
| "vehicle.tesla.*" | All Tesla vehicle models |
| "sensor.camera.*" | All camera sensor types |
| "sensor.*" | All sensor blueprints (camera, lidar, radar, etc.) |
| "walker.*" | All pedestrian blueprints |
| "*" | All blueprints in the library |
Factory pattern pseudocode:
function spawn_actor_from_blueprint(library, pattern, attributes, transform):
blueprints = library.filter(pattern)
blueprint = select(blueprints) # choose one
for (key, value) in attributes:
blueprint.set_attribute(key, value) # customize
actor = world.spawn(blueprint, transform) # instantiate
return actor
Attribute types and validation:
Each attribute has a defined type and optionally a set of recommended values. Setting an attribute to an invalid type or out-of-range value will raise an error at spawn time rather than silently producing incorrect behavior.