Automated Warehouse Control

Project Overview

Warehouses running automated guided vehicles (AGVs) usually already have a vendor-supplied fleet controller. What's missing is a single, browser-based view that operations staff can watch without opening each controller's own interface, and a durable event history for investigating congestion or repeated faults after the fact.

Engineering Problem

AGV fleet controllers report state (position, battery, mission, faults) at their own pace and through their own protocol, and that state is transient - if no one is watching the controller's screen at the moment a fault happens, the information is gone. The engineering problem is turning a stream of vendor telemetry into a durable, queryable operational record, and doing it without gaining any command authority the vendor's safety systems don't already grant.

Operational Constraints

• The pattern is read-oriented: it may relay operator-initiated commands the vendor API already exposes, but it must never become an independent path to move a vehicle.
• Vehicle connectivity is intermittent by nature (warehouse RF dead zones, docking behind racking), so 'no signal' and 'stopped' have to be distinguishable states, not the same alarm.
• The vendor's own safety-rated control loop is authoritative for motion; this system only observes and surfaces exceptions.

Requirements

• Poll or subscribe to the vendor fleet API without exceeding its rate limits or degrading its own control loop.
• Persist every state transition (not just current state) so a shift supervisor can reconstruct what happened during an incident.
• Separate read (monitoring) permissions from any write (command-relay) permissions at the authorization layer.
• Degrade visibly - if telemetry goes stale, the dashboard must say so, not silently show the last known position as current.

System Architecture

An adapter service polls or subscribes to the vendor's fleet API and normalizes vehicle events into a common schema. Each event is appended to a SQL event log (not overwritten in place), so current state is a derived view, not the source of truth. A WebSocket layer pushes normalized state to connected dashboard clients; the dashboard itself holds no business logic beyond rendering what it's given.

Data Flow

1. Vendor controller emits a state change (position, battery, mission, or fault) for a vehicle.
2. The adapter service receives or polls that change and normalizes it into the system's internal event schema.
3. The event is appended to the SQL event log with a timestamp and vehicle ID - never overwriting a prior row.
4. A current-state view is derived from the most recent event per vehicle and pushed to subscribed dashboard clients over WebSocket.
5. If no event arrives for a vehicle within an expected interval, the dashboard marks that vehicle's telemetry as stale rather than reusing the last position as if it were live.

Integration Approach

Integration is entirely through the vendor's documented fleet API or protocol adapter - this pattern assumes that interface exists and is stable, and does not attempt to bypass it. Any command relay (e.g., "acknowledge fault" or "resume mission") only forwards actions the vendor API already exposes to an authorized operator.

Implementation

The adapter and event log are the parts worth getting right first: a schema that separates 'vehicle state' from 'event history' lets the dashboard stay simple while still supporting after-the-fact investigation. Command permissions are checked at the API boundary, separately from read/monitoring access, so a viewer account can never accidentally have write scope.

Reliability and Failure Handling

Stale telemetry is treated as its own state, not folded into 'offline' or 'idle' - a vehicle that hasn't reported in 30 seconds during normal operation is a different situation from one that reported 'stopped, charging' a minute ago. Event ingestion should buffer briefly during a short network interruption and reconcile rather than drop events, though the acceptable buffer window and reconciliation behavior are decisions the vendor's own retry/backoff behavior constrains.

Security Considerations

Monitoring (read) and command-relay (write) capabilities are modeled as separate permissions from the start, not as one "operator" role with everything enabled. Any relayed command is logged with the acting user, separately from the vehicle-generated event stream, so the audit trail distinguishes machine-reported events from human-initiated actions.

Testing and Validation

Before trusting the dashboard operationally, the adapter's handling of a dropped connection, a malformed or partial vendor message, and a burst of simultaneous vehicle events all need explicit test cases - these are the conditions most likely to actually occur on a warehouse floor, not the happy path of one vehicle reporting cleanly.

Deployment

Rollout depends entirely on the vendor's fleet API and the site's network segmentation between the warehouse floor and the network this system runs on. A production deployment needs sign-off from the equipment vendor and the site's safety process before it's treated as anything more than a monitoring aid.

Results

The intended outcome is a single observable fleet view with visible connection health and a queryable event history, replacing the need to check each controller separately. Whether that reduces investigation time or improves response to faults depends on the site's current process and would need to be measured against it - no such measurement exists for this pattern in the abstract.

Lessons Learned

• Treating 'no data' as a distinct, visible state prevented the single failure mode that matters most in fleet monitoring: an operator trusting a stale position.
• Appending events instead of overwriting current state cost very little upfront and made post-incident review possible without additional instrumentation.

Technologies Used

• Python
• WebSockets
• REST APIs
• SQL

Key Features

• Real-time battery and status monitoring
• Live routing and zone visualization
• Alerting for offline or low-battery units
• Web-based dashboard, no special hardware needed

Related Reading