AGV Programming Basics: Routes, Tasks, and Traffic Rules Explained

Table of Contents

1. Overview
2. AGV Route Planning and Path Programming
3. Task Allocation and Execution Workflow
4. Traffic Rules and Collision Avoidance in Multi-AGV Environments
5. Key Considerations for Real-World Deployment
6. Frequently Asked Questions (FAQ)

AGV (Automated Guided Vehicle) programming rests on three pillars: route planning, task allocation, and traffic management. Mastering these fundamentals is essential for engineers deploying safe, efficient multi-vehicle automation systems. This guide breaks down each pillar with practical algorithms, architecture patterns, and collision-avoidance strategies used in modern warehouses and manufacturing floors.

AGV Route Planning and Path Programming

Map Representation and Modelling

The first step in AGV path planning is building an environmental map model. Common representations include:

• Grid Map — Discretises the environment into equal-sized cells, each marked traversable or occupied. Well suited to search-based algorithms such as A* and Dijkstra.
• Topological Map — Uses nodes for key locations (workstations, charging stations) and edges for viable routes. Ideal for fast path queries across large warehouse networks.
• Hybrid Map — Combines grid and topological representations to balance global planning efficiency with local obstacle-avoidance precision.

Core Path Planning Algorithms

Three algorithms dominate practical AGV programming:

1. A* Algorithm (A-Star)

A* is the most widely used heuristic search algorithm in AGV path planning. It balances travelled cost against estimated remaining cost through the evaluation function f(n) = g(n) + h(n):

• g(n) — Actual cost from the start node to node n
• h(n) — Heuristic estimate from node n to the goal (typically Euclidean or Manhattan distance)

On grid maps A* finds the optimal path and searches more efficiently than Dijkstra. In AGV implementations, the heuristic must be admissible (never overestimating) to guarantee optimality.

2. Dijkstra's Algorithm

Dijkstra suits shortest-path search on weighted graphs. When path segments carry differentiated traversal costs — ramps, speed bumps, or high-traffic zones — Dijkstra guarantees a globally optimal solution. The trade-off is a larger search footprint and higher computational overhead than A*.

3. RRT Algorithm (Rapidly-exploring Random Tree)

For high-degree-of-freedom or heavily constrained environments — narrow corridors, dense dynamic obstacles — RRT and its optimal variant RRT* rapidly explore configuration space through random sampling. RRT* converges to the optimal path asymptotically, making it ideal for scenarios that require frequent replanning.

Path Smoothing and Trajectory Generation

Raw paths are typically piecewise linear; executing them directly would force repeated acceleration and deceleration. Engineering practice therefore applies smoothing:

• Bézier curves / spline interpolation — Generate continuous-curvature curves between waypoints for smooth motion
• Velocity profiling — Dynamically adjust linear and angular velocity based on path curvature and obstacle proximity
• Dynamic Window Approach (DWA) — Search the velocity space (v, ω) for the optimal velocity command that satisfies kinematic constraints

Code Example: A* Pseudocode

function AStar(start, goal, grid):
    openSet = PriorityQueue()
    openSet.put(start, 0)
    cameFrom = {}
    gScore = {start: 0}
    fScore = {start: heuristic(start, goal)}
    
    while not openSet.empty():
        current = openSet.get()
        if current == goal:
            return reconstructPath(cameFrom, current)
            
        for neighbor in getNeighbors(current, grid):
            tentative_gScore = gScore[current] + cost(current, neighbor)
            if tentative_gScore < gScore.get(neighbor, infinity):
                cameFrom[neighbor] = current
                gScore[neighbor] = tentative_gScore
                fScore[neighbor] = tentative_gScore + heuristic(neighbor, goal)
                openSet.put(neighbor, fScore[neighbor])
                
    return failure  // No feasible path found

Task Allocation and Execution Workflow

Task Scheduling Architecture

AGV task management is usually organised in three layers:

1. Management Layer — Receives task requests from the WMS (Warehouse Management System), MES (Manufacturing Execution System), or manual input, then decomposes and prioritises them.
2. Dispatching Layer — Executes allocation algorithms based on real-time AGV status (position, battery, payload) and task attributes, binding each task to a specific vehicle.
3. Execution Layer — The onboard AGV controller parses the task into concrete action sequences (move, pick, place, charge) and runs closed-loop control.

Task Allocation Strategies

Common allocation algorithms include:

1. Hungarian Algorithm

Solves the optimal bipartite matching between tasks and AGVs, minimising total execution time or total travel distance. Best when task and vehicle counts are roughly balanced.

2. Auction Algorithm

AGVs act as bidders competing for tasks; the highest bidder wins. This distributed algorithm scales well and suits large AGV fleets.

3. Contract Net Protocol (CNP)

A multi-agent negotiation mechanism: the manager announces a task, each AGV evaluates its own capability and submits a bid, and the manager selects the best contractor. Effective when AGVs have heterogeneous capabilities such as load capacity, speed, or attachment type.

Task Execution State Machine

A single AGV's task execution can be modelled as a finite state machine (FSM):

• IDLE — Standing by, waiting for a new task
• ASSIGNED — Task allocated, preparing to execute
• MOVING_TO_PICKUP — Travelling to the pick-up location
• LOADING — Executing the pick-up action
• MOVING_TO_DELIVERY — Travelling to the drop-off location
• UNLOADING — Executing the drop-off action
• CHARGING — Battery low, proceeding to charging station
• ERROR — Fault detected, awaiting manual intervention

Code Example: Simple Task Queue Manager

class TaskQueue:
    def __init__(self):
        self.queue = []
        
    def add_task(self, task, priority=0):
        # Higher-priority tasks move to the front
        self.queue.append((priority, task))
        self.queue.sort(reverse=True)
        
    def assign_task(self, agv_status):
        for priority, task in self.queue:
            if self.is_feasible(task, agv_status):
                self.queue.remove((priority, task))
                return task
        return None
        
    def is_feasible(self, task, agv_status):
        # Check whether the AGV has enough charge to complete the task
        estimated_energy = self.estimate_energy(task)
        return agv_status.battery > estimated_energy * 1.2  # 20 % safety margin

Traffic Rules and Collision Avoidance in Multi-AGV Environments

Collision Avoidance Strategy Hierarchy

Multi-AGV collision avoidance operates at three levels:

1. Centralised Path Planning

A central server computes paths for all AGVs simultaneously, eliminating conflicts at the source. Theoretical completeness is the main advantage; the drawbacks are NP-hard computational complexity and extreme dependency on communication reliability.

2. Distributed Negotiation

AGVs communicate directly to negotiate right-of-way. Common methods include:

• Priority rules — Dynamic priority scores assigned to each vehicle; higher priority wins
• Right-hand traffic rule — All vehicles keep right at intersections to reduce deadlock probability
• Time-window allocation — Exclusive time windows are assigned to each road segment to prevent spatio-temporal conflicts

3. Zone Control

The map is divided into mutually exclusive zones; only one AGV may occupy a zone at any given time. Simple to implement and the most widely adopted industrial collision-avoidance scheme.

Deadlock Prevention and Detection

Deadlock is one of the most severe failures in multi-AGV systems. Prevention strategies include:

• Ordered resource allocation — AGVs must request zone resources in a fixed global order
• Banker's algorithm — Safety check before granting resources to ensure the system cannot enter an unsafe state
• Timeout and back-off — After waiting beyond a threshold, an AGV retreats and replans its route

Sensor Fusion and Dynamic Obstacle Avoidance

Beyond logical traffic management, AGVs rely on sensors for physical dynamic obstacle avoidance:

• LiDAR — 360° environmental scanning detects unexpected obstacles
• Safety laser scanners — Multi-level safety zones (warning, slowdown, stop) configured around the vehicle
• Vision sensors — Classify specific obstacle types such as humans or forklifts
• Ultrasonic / infrared — Close-range blind-spot coverage

Communication Architecture and Real-Time Performance

Multi-AGV coordination depends on reliable communication infrastructure:

Key Considerations for Real-World Deployment

Programming Languages and Development Environments

The typical AGV technology stack includes:

• C / C++ — Real-time control programs demanding hard-real-time response
• Python — Algorithm prototyping, scheduling logic, and integration with higher-level systems
• ROS / ROS 2 — Robot Operating System providing navigation stacks (Nav2), communication middleware, and a complete ecosystem
• PLC (Ladder / Structured Text) — Traditional AGV motion control and safety logic

Simulation and Verification

Before physical deployment, thorough simulation testing is essential:

• Gazebo + ROS 2 — Physics-level simulation validating sensor models and control algorithms
• Discrete-Event Simulation (DES) — Evaluates system throughput and bottlenecks
• Digital Twin — Runs in parallel with the live system for predictive maintenance and policy optimisation

Safety Certification Standards

AGV systems must comply with relevant safety standards:

• ISO 3691-4 — Safety requirements and verification for industrial trucks
• ANSI/ITSDF B56.5 — Safety standard for driverless industrial vehicles
• CE marking (Machinery Directive 2006/42/EC) — European market access

Frequently Asked Questions (FAQ)

What is the difference between AGV path planning and SLAM navigation?

Path planning computes an optimal route from start to goal within a known or partially known map. SLAM (Simultaneous Localisation and Mapping) solves two problems at once: determining the vehicle's position and building the map of its surroundings. The two are typically used together — SLAM constructs the map, and path planning operates on that map to generate trajectories.

In a multi-AGV system, what are the pros and cons of centralised versus distributed dispatching?

Centralised dispatching lets a single server optimise globally, but introduces a single point of failure and limits scalability. Distributed dispatching lets AGVs negotiate autonomously, offering robustness and easy scaling, yet it risks local optima or deadlocks. Production systems often use a hybrid: a central server handles coarse-grained task allocation while vehicles manage local collision avoidance independently.

How do I choose collision-avoidance sensors for an AGV?

The choice depends on environmental characteristics and budget. LiDAR suits dynamic environments with high accuracy demands; magnetic tape or QR codes are low-cost but inflexible; vision sensors classify obstacle types but are sensitive to lighting; ultrasonics cover short-range blind spots. Industrial AGVs usually adopt a multi-sensor fusion architecture.

What advantages does ROS 2 bring to AGV development?

ROS 2 provides a standardised communication middleware (DDS), a rich navigation algorithm library (Nav2), and an active community ecosystem. Its distributed architecture naturally fits multi-AGV systems, supports real-time configuration through DDS QoS policies, and integrates seamlessly with the Gazebo simulator — significantly shortening development cycles.

What tests should an AGV system pass before going live?

A complete test programme covers: unit testing (individual module verification), integration testing (vehicle-to-ground communication and scheduler interoperability), simulation testing (large-scale stress testing), and on-site testing (gradual validation in the real environment). Safety-function tests — emergency braking and collision-response — must achieve a 100 % pass rate before production operation.