Warehouse AGV Prototype.

Project Overview

A guided vehicle that takes jobs from a fleet manager, navigates a warehouse by markers, and moves goods between stations — the real logic behind automated warehouses.

Automated warehouses run on fleets of automated guided vehicles (AGVs) — robots that carry goods between storage, picking and dispatch — and the interesting engineering is not one robot following a line, but the system: a fleet manager that hands out jobs, vehicles that navigate a known layout to specific destinations, and traffic rules that stop them colliding at junctions. This project builds a prototype AGV that captures that system honestly: it accepts transport jobs from a central manager, navigates a marked warehouse to the pickup and drop-off, and handles the fleet realities of junctions, right-of-way and safe stopping.

The vehicle navigates by following guide paths (line or magnetic tape) with junction markers/tags that tell it where it is in the layout, so it can route from its current node to a target node — the difference between a toy line-follower (which just stays on the line) and an AGV (which goes to a named destination by choosing turns at junctions). Over the top sits the fleet layer: a manager assigns "move pallet from A to B" jobs to free vehicles, each vehicle reports its position and status, and simple traffic management (junction reservations, right-of-way, stop-on-obstacle) keeps multiple vehicles from colliding or deadlocking.

The value is showing the whole loop that a real automated warehouse runs on — job dispatch, destination navigation, and fleet traffic control — in a buildable prototype. It is honest that industrial AGVs use far more sophisticated navigation (laser/vision SLAM, natural-feature localisation) and fleet software with robust deadlock handling and safety-rated obstacle detection, and that this is a prototype of the logic, not a production vehicle. But as an AGV that takes jobs, routes to destinations by markers, and cooperates with a fleet through junction traffic rules, it teaches the genuine architecture of warehouse automation — the part that is about systems and coordination, not just staying on a line.

What this project does

• Accepts transport jobs (move from A to B) from a fleet manager
• Navigates a marked warehouse to named destinations
• Routes by choosing turns at junction markers/tags
• Reports position and status to the manager
• Manages junction traffic (reservations, right-of-way)
• Stops for obstacles and resumes safely
• Demonstrates the real architecture of warehouse automation

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Guide-path following with junction markers
• Node-to-node routing (destination navigation)
• Central job dispatch to a vehicle fleet
• Position/status reporting
• Junction traffic management (anti-collision)
• Obstacle stop and safe resume
• Honest about SLAM/safety-rated production AGVs

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Guide-path following with junction/marker detection
• Node-to-node routing (choosing turns to a destination)
• Central job dispatch and vehicle status reporting
• Junction traffic management / anti-collision
• Obstacle handling and safe resume

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹4,015, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 355 mA. With a 1.5× design margin the supply should deliver at least 600 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Use a guide-path sensor for following plus junction detection, and a marker reader to identify nodes.
• Add a ToF/ultrasonic obstacle sensor for a safe stop.
• Connect over Wi-Fi to the fleet manager for jobs and status.
• Differential drive through an H-bridge as in any line-guided robot.
• Keep the load bed over the drive centre so loads do not upset steering.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

The line-following robot answers "how do I stay on a path?"; the AGV answers a bigger question — "how does a fleet of vehicles get the right goods to the right places without colliding?" — and that is the real subject of warehouse automation. Three things distinguish an AGV system from a lone follower: it goes to named destinations (not just along a line), it takes jobs from a manager (not a fixed loop), and it shares space with other vehicles under traffic rules. This prototype exists to make those three system-level ideas concrete and buildable, because they, not the line-following, are what warehouse automation is actually about.

Destination navigation is the first step up. The vehicle still follows a guide path, but the warehouse is modelled as a graph of nodes (stations and junctions) connected by path segments, and markers or tags at junctions tell the vehicle which node it has reached. To go from its current node to a target node it computes a route — a sequence of "at junction X, turn left/right/straight" decisions — and executes it. That turns "follow the line" into "go to station B", which is the qualitative leap: the vehicle knows where it is in the layout and chooses turns to reach a specific place.

The fleet layer is where the system becomes a system. A central manager holds a queue of transport jobs ("move a load from A to B") and assigns each to a free vehicle — the same dispatch logic that drives a real automated warehouse, deciding which robot does what. Each vehicle reports its position and status (idle, en route to pickup, carrying, blocked) so the manager knows the state of the fleet and can assign sensibly. This is the difference between a robot and a robot fleet: work is allocated centrally and vehicles are coordinated rather than acting alone.

The hardest and most system-defining part is traffic management, because multiple vehicles on shared paths will otherwise collide or deadlock. The prototype uses the same ideas as real fleets in miniature: a junction is a shared resource that a vehicle must reserve before entering and release after clearing, so two vehicles never occupy it at once; right-of-way rules (and reservation ordering) decide who waits; and every vehicle stops for obstacles and resumes safely. Getting this right means thinking about deadlock (two vehicles each waiting for the other) and starvation, which is exactly the thinking industrial fleet software is built around. The design is candid about the gap to production: real AGVs navigate with laser or vision SLAM and natural-feature localisation rather than markers, carry safety-rated obstacle detection, and run fleet software with rigorous deadlock-free traffic control — this is a prototype of the logic and architecture, not a production vehicle. But by taking jobs from a manager, routing to destinations by markers, and cooperating through junction traffic rules, it teaches the genuine shape of warehouse automation: a coordinated fleet doing dispatched work in shared space, which is the part that matters and the part a single line-follower never touches.

The maths behind it

Node-to-node routing

Warehouse = graph G(nodes, path-segments).
To go from current node to target:

  route = shortest_path(G, current, target)
  → sequence of junction turns [L/R/straight,...]

At each junction marker: pop the next turn and take it.
"Follow line" becomes "go to station B".

Junction reservation (anti-collision)

A junction J is a shared resource:

  before entering J: acquire lock(J)   (else WAIT)
  after clearing  J: release lock(J)

No two vehicles hold J at once. Right-of-way / ordering
breaks ties. Avoid deadlock (cyclic waits) and starvation.

Job assignment

Manager holds jobs {A→B, ...} and vehicles {idle, busy}.

  assign job → nearest/available idle vehicle
  vehicle reports: {pos, state}  (idle/toPickup/carrying/blocked)

Central dispatch = a fleet, not lone robots.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Build the routing-capable vehicle

   Assemble the differential-drive base with a guide-path sensor, a marker/tag reader for node identification, an obstacle sensor, and Wi-Fi to the fleet manager.

2. Model the layout and add routing

   Represent the warehouse as a node graph, detect junction markers, and route from the current node to a destination as a sequence of turns.

3. Add fleet dispatch and traffic management

   Connect to a central manager for jobs and status, and add junction reservations/right-of-way plus obstacle stopping for multi-vehicle safety.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Route to a destination by junction markers

   Compute a route over the layout graph and, at each junction marker, take the next turn toward the destination.

   pythonroute.py Copy Download

   import heapq
   
   def shortest_path(graph, start, goal):
       # Dijkstra over the warehouse node graph -> ordered node list
       pq = [(0, start, [start])]; seen = set()
       while pq:
           cost, node, path = heapq.heappop(pq)
           if node == goal: return path
           if node in seen: continue
           seen.add(node)
           for nxt, w in graph[node].items():
               if nxt not in seen:
                   heapq.heappush(pq, (cost+w, nxt, path+[nxt]))
       return None
   
   def turn_at(junction, path):
       # given the planned path, which way to turn at this junction node
       i = path.index(junction)
       return DIRECTION[(path[i-1], junction, path[i+1])]   # L / R / straight
   
   class AGV:
       def __init__(self, graph): self.graph = graph
       def goto(self, here, target):
           self.path = shortest_path(self.graph, here, target)   # named destination
           follow_line_until_junction()
       def on_junction(self, node):
           t = turn_at(node, self.path)      # route decides the turn
           execute_turn(t)                   # not just follow the line

   def shortest_path(graph, start, goal):The warehouse is a graph and the route is a shortest path over it — the vehicle plans how to reach a named destination, not just where the line goes.

   def turn_at(junction, path):At each junction the planned route determines the turn, which is exactly what makes this an AGV (goes to a destination) rather than a line-follower (stays on the line).

   self.path = shortest_path(self.graph, here, target) # named destinationA job resolves to a route from the current node to the target node — destination navigation.

   execute_turn(t) # not just follow the lineThe vehicle actively takes the routed branch at a junction, the qualitative leap over blind line following.

2. Take jobs and manage junction traffic

   Accept jobs from the manager, report status, and reserve junctions (with right-of-way) so multiple vehicles never collide or deadlock; stop for obstacles.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

#!/usr/bin/env python3
"""
Warehouse AGV Prototype — vehicle node

Takes transport jobs from a central fleet manager, routes to named
destinations over the warehouse graph by junction markers, and
cooperates with other vehicles via junction reservations + right-of-way.
Stops for obstacles. A prototype of AGV LOGIC, not a production vehicle.
"""
import json

class AGV:
    def __init__(self, vid, graph, fleet):
        self.vid = vid; self.graph = graph; self.fleet = fleet
        self.state = "idle"; self.node = "depot"; self.path = []

    def report(self):                                  # fleet visibility
        self.fleet.publish(f"agv/{self.vid}/status",
            {"pos": self.node, "state": self.state})

    def take_job(self, job):                            # dispatched A->B
        self.state = "to_pickup"; self.report()
        self.run_to(job["from"])                        # navigate to A
        pick_load()
        self.state = "carrying"; self.report()
        self.run_to(job["to"])                          # navigate to B
        drop_load()
        self.state = "idle"; self.report()
        self.fleet.publish(f"agv/{self.vid}/done", job)

    def run_to(self, target):
        self.path = shortest_path(self.graph, self.node, target)
        for junction in self.path[1:]:
            follow_path()                               # PID line follow
            while obstacle_ahead():                     # safe stop
                stop(); self.state = "blocked"; self.report()
            if not self.fleet.reserve(junction, self.vid):   # traffic
                wait_for(junction)                      # right-of-way
            execute_turn(turn_at(junction, self.path))  # routed turn
            self.node = junction
            self.fleet.release(junction, self.vid)
            self.report()

if __name__ == "__main__":
    agv = AGV("AGV-3", WAREHOUSE_GRAPH, FleetLink())
    while True:
        job = agv.fleet.next_job_for(agv.vid)           # central dispatch
        if job: agv.take_job(job)

Configuration & Calibration

Configuration steps

• Configure the warehouse node graph, junction markers and station nodes.
• Configure the fleet-manager link, job format and status reporting.
• Configure junction reservation/right-of-way and obstacle-stop distance.
• Configure path-following (PID) and junction-turn behaviour.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Navigation

   Verify path following and reliable junction/marker detection so routing turns are taken correctly.

2. Traffic

   Test two vehicles at a shared junction: confirm reservation/right-of-way prevents collision and avoids deadlock.

3. Obstacle stop

   Verify the vehicle stops before contact and resumes safely.

Mechanical Assembly & Motion

Mechanical assembly

• Differential-drive base with a guide-path sensor at the front, a small load bed over the drive centre, and an obstacle sensor.
• A marker/tag reader positioned to detect node identifiers at junctions and stations.
• Load bed centred so goods do not shift the balance or upset path following.
• Rugged, low build suited to repeated station-to-station running.

Motion logic

Motion combines path following (differential-drive PID on the guide line, as in a line-follower) with discrete junction manoeuvres — at a marked junction the vehicle executes the routed turn (left/right/straight) rather than blindly following the line.

Between junctions it cruises the path; at junctions it consults its route and traffic clearance before proceeding, and it stops entirely for obstacles or when a junction is reserved by another vehicle.

Sensor integration

• Guide-path sensor: follows the path and detects junctions.
• Marker/tag reader: identifies the current node in the layout graph.
• Obstacle sensor (ToF/ultrasonic): safe stop before collision.

Actuator explanation

Two geared DC motors via an H-bridge for differential drive, executing both path following and routed junction turns.

A load actuator (optional) to pick/release the carried goods at stations; status LEDs for state.

Kinematics

Vehicle motion is differential drive; the system-level "kinematics" is graph routing — turning a destination into a sequence of junction turns over the warehouse layout.

Drive:   v = (v_R+v_L)/2,  omega = (v_R−v_L)/L   # differential
Routing: route = shortest_path(layout_graph, here, target)
         at junction j:  turn = route.next()          # L/R/straight
Traffic: enter j only if reserve(j) succeeds; release after

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

A vehicle that takes dispatched jobs, routes to destinations by markers, and cooperates with a fleet through junction traffic rules.

{
  "vid": "AGV-3",
  "job": { "from": "A12", "to": "D04" },
  "pos": "J7",
  "state": "carrying",
  "route": ["A12","J7","J9","D04"],
  "waiting_for": null
}

AGV-3 is carrying a load from A12 to D04, currently at junction J7 with its route planned ahead and no traffic wait — the dispatch, navigation and traffic loop of an automated warehouse in miniature.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Route node-to-node so vehicles reach named destinations.
• Reserve junctions and apply right-of-way to prevent collisions/deadlock.
• Report position/state so the manager can dispatch well.
• Stop for obstacles and resume safely.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.
• Profile before optimising — print micros() deltas around each stage and fix the slowest one first.

Safety Precautions

• This is a prototype of AGV logic, not a safety-rated vehicle — keep speeds low and always include an obstacle stop.
• Production AGVs require safety-rated obstacle detection; do not deploy this around people or valuable goods as if it were.
• Design traffic rules to be deadlock-free; a stuck fleet can be a hazard as well as an outage.
• Secure loads on the bed so they cannot fall during turns or stops.
• Lithium cells vent and burn when abused. Only use protected cells or a proper BMS, never charge below 0 °C, and never leave a charging pack unattended on a wooden desk.
• Moving parts pinch. Keep fingers, cables and hair out of gear trains and wheels, and always test motion with the drivetrain unloaded and the robot on blocks first.
• Motors are inductive — always fit a flyback diode across a DC coil, or use a driver that already has one, or the back-EMF spike will destroy your GPIO.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Keep guide paths and markers clean and intact for reliable navigation.
• Re-verify traffic rules when the layout or fleet size changes.
• Check obstacle sensors and drive wear.
• Review job/traffic logs for recurring blocks or near-deadlocks.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Log pack voltage. When resting voltage after a full charge drops below about 4.0 V, the cell is near end of life — replace it.
• Listen for gear chatter. A servo that buzzes at rest is either stripped or fighting a mechanical bind — fix it before it burns out.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Upgrade navigation to laser/vision SLAM (markerless).
• Add dynamic re-routing around blocked segments.
• Add battery-aware dispatch and auto-charging.
• Add robust deadlock-free traffic algorithms and safety-rated sensing.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add connectivity — an ESP32 and an MQTT publish turn a local gadget into something you can graph, alert on and analyse over months.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Automated guided vehicleReference
2. Warehouse automationReference
3. Multi-robot task allocationReference
4. DeadlockReference
5. Dijkstra shortest pathReference