Principle:CARLA simulator Carla Walker AI Control
| Knowledge Sources | |
|---|---|
| Domains | Pedestrian Simulation, AI Controller Architecture |
| Last Updated | 2026-02-15 00:00 GMT |
Overview
Walker AI control is the mechanism by which autonomous pedestrian agents are given behavioral intelligence, enabling them to navigate along the navigation mesh, avoid obstacles, and move toward designated destinations at configurable speeds.
Description
Unlike NPC vehicles (which are controlled by the Traffic Manager through autopilot), pedestrian walkers in CARLA require a separate AI controller actor that is attached to each walker. This controller-actor architecture separates the physical representation (the walker mesh, collision, and animation) from the behavioral logic (pathfinding, destination selection, speed control).
The WalkerAIController is a special actor type that, once spawned and attached to a walker, provides three core capabilities:
- Start/Stop -- Activating or deactivating the AI controller's processing loop. When started, the controller registers the walker with the Detour crowd simulation system and begins computing paths and velocities each tick.
- Goal-Directed Navigation -- The controller accepts a destination location and computes a path along the navigation mesh from the walker's current position to the goal. The walker then follows this path, smoothly navigating around corners, through crosswalks, and along sidewalks.
- Speed Control -- The maximum walking speed can be set per-controller, allowing variation in the pedestrian population (some walkers stroll slowly, others walk briskly, some jog).
Controller Lifecycle
The AI controller lifecycle follows a strict sequence:
- Spawn the walker actor (the physical pedestrian)
- Spawn a WalkerAIController actor attached to the walker
- Start the controller (registers the walker with the crowd simulation)
- Set destination via
go_to_location() - Set speed via
set_max_speed() - (The walker now moves autonomously each tick)
- Stop the controller before destroying the walker (unregisters from crowd simulation)
- Destroy both the controller and the walker
Failure to follow this sequence -- particularly forgetting to stop the controller before destroying it -- can lead to dangling references in the crowd simulation system.
Usage
Use walker AI controllers when you need to:
- Populate sidewalks and crosswalks with autonomous pedestrian agents
- Test an autonomous vehicle's pedestrian detection and avoidance capabilities
- Create scenarios where pedestrians cross roads unexpectedly
- Simulate crowd dynamics in urban environments
Theoretical Basis
Controller-Actor Separation
The separation of walker (body) and controller (brain) follows the Component-Entity pattern common in game engine architectures:
Walker Entity:
- Mesh component (visual representation)
- Collision component (physics bounding capsule)
- Animation component (walk/run/idle animations)
- Transform component (world position and rotation)
WalkerAIController Entity:
- Navigation component (Detour crowd agent)
- Goal component (target destination)
- Speed component (max velocity constraint)
- State component (active/inactive)
Attachment: Controller.parent = Walker
=> Controller reads Walker.transform for current position
=> Controller writes Walker.velocity for movement
This separation allows the same walker body to be controlled by different systems (AI controller for NPCs, manual input for testing, scripted paths for cinematics) without modifying the walker entity itself.
Crowd Agent Registration
When start() is called, the controller registers the walker as a crowd agent in the Detour crowd simulation system. Each crowd agent is assigned:
- A position on the NavMesh (snapped from the walker's world position)
- A radius (the walker's collision radius, used for local avoidance)
- A max speed (configurable via
set_max_speed()) - A corridor (the sequence of NavMesh polygons forming the current path)
The crowd manager then updates all registered agents simultaneously each tick, applying:
For each tick:
For each active crowd agent:
1. desired_velocity = direction_to_next_waypoint * max_speed
2. adjusted_velocity = apply_local_avoidance(desired_velocity, nearby_agents)
3. new_position = current_position + adjusted_velocity * dt
4. snap new_position to NavMesh surface
5. if distance_to_goal < threshold:
mark goal as reached
Pedestrian Speed Distribution
Real-world pedestrian speeds follow an approximately normal distribution:
| Pedestrian Type | Speed (m/s) | Speed (km/h) |
|---|---|---|
| Slow walk (elderly) | 0.8 - 1.0 | 2.9 - 3.6 |
| Normal walk | 1.2 - 1.5 | 4.3 - 5.4 |
| Brisk walk | 1.5 - 2.0 | 5.4 - 7.2 |
| Jogging | 2.0 - 3.0 | 7.2 - 10.8 |
| Running | 3.0 - 5.0 | 10.8 - 18.0 |
For realistic simulation, walker speeds should be sampled from this distribution rather than using a single uniform speed. CARLA's generate_traffic.py example uses a simple bimodal distribution: walkers either walk (selected at random below a "running" percentage) or run (above the percentage threshold).