AGV Fleet Comms: From Single Unit to 100-Vehicle Scheduling

A Real-World Dispatch Dilemma

At 2:17 AM, the AGV dispatch system at an automotive parts warehouse flashed a red alert:

"Path conflict detected between Vehicle B7-03 and Vehicle B7-07. Estimated collision in 4.2 seconds."

The dispatcher stared at the screen, fingers hovering over the keyboard. Three seconds later, the system automatically rerouted both vehicles. But he knew this wasn't the last time. The twenty new AGVs had already triggered eleven path conflicts, three deadlocks, and one full-zone emergency stop in the past week.

The warehouse manager slammed the table: "One hundred and eight AGVs, and they haven't even run for two months before they start colliding? What happened to the 'hundred-vehicle stable dispatch' we were promised?"

The root of the problem wasn't the dispatch algorithm—it was the underlying communication architecture.

One AGV and One Hundred AGVs Are Entirely Different Engineering Problems

A single AGV is simple: receive a task, calculate the path, reach the destination, stop. The onboard controller only processes its own sensor data, motion control, and obstacle avoidance. Latency of tens of milliseconds doesn't matter.

But with one hundred AGVs running simultaneously, the situation is completely different:

• One hundred nodes communicate simultaneously with the central dispatch server

• They broadcast their positions and intentions to each other

• They simultaneously receive tasks from the WMS, status from chargers, and signals from safety perimeters

Each AGV is not just an "executor"—it's also a "communication node."

Traditional AGV controllers follow a "good enough" design philosophy: one board per vehicle runs local tasks and connects to the dispatch center via Wi-Fi or 4G. In single-vehicle tests, latency is around 20ms with a 0.1% packet loss rate—perfect.

But when you connect one hundred such boards to the same network, the problems appear:

Half a meter—in the AGV world—can mean a collision, an emergency stop, or a production line interruption.

The Limitations of Point-to-Point Architecture

The core assumption of point-to-point architecture is that each vehicle works independently and communicates directly with the dispatch center. This works with a small number of vehicles, but bottlenecks emerge as the fleet grows:

Dispatch Center as a Performance Bottleneck: All vehicles connect directly to the dispatch center, creating a single point of congestion. As the fleet grows, the processing load increases linearly. Beyond a certain threshold, response latency spikes dramatically.

Inefficient Communication Model: Traditional architectures use a "polling" model, where the dispatch center queries each vehicle's status at fixed intervals. With one hundred AGVs, this means thousands of queries per second. A significant portion of the controller's CPU is spent responding to "where are you" inquiries instead of executing actual tasks.

Insufficient Real-Time Performance: General-purpose operating systems (like standard Linux) use "soft real-time" task scheduling. They can respond quickly in theory, but occasional preemption by other processes can introduce unpredictable delays. While tolerable for single vehicles, this uncertainty is amplified in a hundred-vehicle fleet.

From Point-to-Point to Fleet: Architectural Design Considerations

Consideration 1: From Star to Mesh Communication Topology

In a traditional star architecture, all vehicles communicate directly with a central dispatch hub. As the fleet grows, this hub becomes a congestion point. An alternative approach is to introduce mesh communication: each AGV communicates not only with the dispatch center but also directly with 3-5 neighboring vehicles. Local path negotiations happen between vehicles, with the dispatch center only responsible for global strategy, not micro-management.

This approach effectively turns a single highway into a grid-like urban road network—more routes, less congestion.

Consideration 2: From Polling to Event-Driven Communication

In traditional polling, the dispatch center periodically queries each vehicle's status, even when vehicles are idle, generating unnecessary communication load. An event-driven model is different: vehicles only report when their status changes—encountering obstacles, reaching nodes, or experiencing low battery. They remain silent normally and only "speak" when something happens.

In practical deployments, this change has reduced communication traffic by about 70%, and dropped dispatch center CPU usage from 85% to 30%.

Consideration 3: From Soft Real-Time to Hard Real-Time Communication

AGV obstacle avoidance decisions must be made within milliseconds. On standard operating systems, task scheduling can be disrupted by other processes, extending response times from a theoretical 10ms to 30ms or even 50ms.

Providing deterministic response paths for critical control commands is the foundation for ensuring safe fleet operations. This typically requires underlying operating systems that support priority scheduling, ensuring critical commands like obstacle avoidance are always processed first, unaffected by other tasks.

The Role of Industrial Communication Equipment in Fleet Scenarios

In AGV fleets, the communication equipment on each vehicle (such as industrial routers, onboard gateways) plays a crucial role in data transmission and network connectivity. In fleet scenarios, communication equipment must possess the following capabilities:

The selection of communication equipment should focus not only on peak data rates, but more importantly on stability and determinism under fleet concurrency—including jitter in forwarding latency, packet loss rate, and processing capacity with multiple devices connected simultaneously.

The Shift from "Functional" to "Reliable"

For engineers currently managing AGV fleets, the following points may be helpful:

1. Assess architectural bottlenecks early: AGV fleet performance issues often begin to appear at a certain scale (e.g., 50 units) but typically become critical at 80-100 units. Identifying communication architecture limitations proactively is more cost-effective than fixing problems after they occur.

2. Focus on fleet performance when selecting equipment: Beyond individual device performance, consider how multiple devices perform simultaneously—the dispatch center's processing capacity, the network's concurrent load handling, and end-to-end latency stability.

3. Consider edge processing: Offload some dispatch logic (such as local obstacle avoidance and path negotiation) to the vehicle side or edge devices near the vehicles. This reduces reliance on central dispatch, lowering central load and communication latency.

Conclusion

Scaling an AGV fleet is not just about increasing numbers—it's a qualitative change in system complexity. Being able to run a single point is not capability; being able to run a fleet is capability.

Systematically reviewing and optimizing the underlying architecture—from communication topology and data models to real-time performance guarantees—is essential to support the smooth scaling from dozens to hundreds of AGVs.

This article is based on general technical experience in AGV fleet communication architecture, intended as a reference for technical professionals. For specific project solutions, please combine on-site environmental surveys with equipment manufacturers' official technical specifications.

For more information on industrial equipment networking and data acquisition solutions, please visit the MovingComm official website: https://www.movingcomm.com/