Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:CARLA simulator Carla Walker AI Control

From Leeroopedia
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:

  1. 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.
  1. 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.
  1. 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:

  1. Spawn the walker actor (the physical pedestrian)
  2. Spawn a WalkerAIController actor attached to the walker
  3. Start the controller (registers the walker with the crowd simulation)
  4. Set destination via go_to_location()
  5. Set speed via set_max_speed()
  6. (The walker now moves autonomously each tick)
  7. Stop the controller before destroying the walker (unregisters from crowd simulation)
  8. 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).

Related Pages

Implemented By

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment