Every component in an AGV drivetrain — servo drives, motors, lifting mechanisms, steering modules — takes its commands from a single source: the vehicle controller. The controller reads encoder feedback, interprets navigation commands from the fleet management system, executes motion profiles, monitors safety inputs, and coordinates every actuator on the vehicle simultaneously. It is the component that determines not just what the vehicle can do, but how precisely and how reliably it does it.
Despite this central role, AGV controller selection is often treated as a software integration problem rather than a hardware specification decision. Engineers focus on the programming environment and communication protocol support while underweighting processing capacity, I/O architecture, real-time performance, and long-term supply continuity — specifications that determine whether the controller can support the vehicle's full capability across its operating life.
This guide covers the main controller architectures used in AGV and AMR applications, the hardware and software specifications that govern selection, how the controller integrates with the drive system components, and the criteria that distinguish capable long-term supplier partners from commodity board vendors.
What an AGV Controller Does and Why It Matters
The AGV controller — also called the vehicle controller, motion controller, or master controller depending on the system architecture — performs several functions simultaneously in real time.
On the motion control side, it receives target position, velocity, or path commands from the navigation system and translates them into coordinated velocity and position commands for each servo drive on the vehicle. It reads encoder feedback from drive wheels and steering axes to maintain odometry — an ongoing estimate of the vehicle's position and heading based on wheel travel — and uses this feedback to execute motion profiles with the precision and repeatability required by the application.
On the communication side, it maintains continuous data exchange with servo drives over CAN bus, EtherCAT, or other fieldbus protocols, processes inputs from safety sensors and emergency stop circuits, and communicates vehicle status to the fleet management system over Wi-Fi or wired Ethernet.
On the safety side, it monitors safety-critical inputs — laser scanner zones, bumper contacts, emergency stop buttons, payload presence sensors — and executes defined safe-state responses when safety conditions are violated. In systems requiring functional safety certification, the controller must execute safety functions with documented response times and reliability levels.
The controller must do all of this simultaneously, deterministically, and without failure across years of continuous multi-shift operation. Controller selection decisions made at vehicle development time cannot easily be reversed after production deployment.
Main AGV Controller Architectures
Dedicated AGV Motion Controller
A dedicated AGV motion controller is a hardware unit designed specifically for mobile robot vehicle control — not adapted from a PLC, industrial PC, or general-purpose computing platform. These controllers typically integrate motion control processing, safety I/O, fieldbus interfaces, and communication ports in a single ruggedized unit optimized for the size, power, and environmental constraints of a mobile robot chassis.
The advantages of dedicated controllers are significant for production AGV programs: the hardware-software combination is pre-validated for AGV applications, reducing integration effort and commissioning time; the mechanical form factor is designed for chassis mounting with appropriate vibration tolerance and thermal management; and the supplier's support structure is organized around AGV application requirements rather than general industrial automation.
The primary consideration with dedicated AGV controllers is supplier dependency — the hardware and software are typically tightly coupled, and changing controller suppliers mid-program requires significant re-engineering effort.
PLC-Based Controller
Programmable logic controllers from major industrial automation vendors — Siemens, Beckhoff, Omron, and others — are used as AGV vehicle controllers in some applications, particularly where the vehicle integrates with existing factory automation infrastructure using the same PLC platform. PLCs offer mature programming environments, extensive I/O option availability, and established safety certification pathways.
The limitations in AGV applications relate to form factor, real-time motion control performance, and cost. Standard PLC hardware is designed for panel mounting in stationary equipment, not for integration into compact mobile robot chassis with vibration exposure and space constraints. Motion control cycle times and encoder feedback processing may not meet the performance requirements of high-speed or high-precision AGV applications without specialist motion control modules. Total system cost is typically higher than dedicated AGV controller solutions for equivalent capability.
Embedded SBC-Based Controller
Single-board computer platforms — typically running Linux with real-time kernel extensions — are used as AGV controllers in research, development, and some production applications where software flexibility and open architecture are priorities. ROS (Robot Operating System) is commonly used on these platforms as the software framework for navigation, sensor processing, and motion control.
SBC-based controllers offer maximum software flexibility and access to a large open-source ecosystem of navigation, perception, and motion control algorithms. The trade-offs are significant for production AGV deployment: real-time performance depends on software implementation quality and system configuration rather than hardware guarantees; reliability over multi-year continuous operation requires careful thermal management and storage media selection; and the absence of dedicated hardware safety I/O complicates functional safety certification.
Distributed Controller Architecture
In distributed architectures, vehicle control functions are divided across multiple processing nodes — a navigation and mission management processor, one or more motion control processors for the drive axes, and a dedicated safety processor — connected over an internal vehicle network. This architecture provides processing headroom for computationally intensive navigation and perception tasks without compromising the determinism of the motion control and safety functions, which run on dedicated processors with guaranteed cycle times.
Distributed architectures are more complex to design and integrate than single-controller solutions, but they scale better to high-performance AMR platforms that combine sophisticated navigation with demanding motion control requirements. They are increasingly common in autonomous mobile robots where simultaneous map-building, obstacle avoidance, and precise motion execution place processing demands that a single controller cannot serve without compromise.
Key Specifications for AGV Controller Selection
Real-Time Processing Performance
AGV motion control requires deterministic execution — the controller must complete its control loop within a guaranteed maximum cycle time regardless of other processing activity. For servo drive command update rates, control loop cycle times of 1ms to 10ms are typical, depending on application speed and accuracy requirements. For safety function monitoring, response times of 10ms to 100ms are common requirements depending on the applicable safety standard.
Verify that the controller's real-time performance specifications are hardware-guaranteed, not software-dependent. A controller whose cycle time is specified as typical rather than maximum cannot provide the performance guarantee required for safety-critical motion control functions.
Communication Interface Support
The AGV controller must communicate simultaneously with multiple subsystems: servo drives over fieldbus, fleet management system over wireless Ethernet, safety sensors over discrete I/O or safety fieldbus, and optionally with navigation sensors such as laser scanners or cameras over Ethernet or USB.
CAN bus and CANopen remain the most widely used interfaces for servo drive communication in AGV applications due to robustness and broad compatibility. EtherCAT is increasingly used in performance-critical applications requiring faster update rates. Confirm that the controller supports the specific protocol variant — not just the physical interface — used by the servo drives in the vehicle's drivetrain. As noted in servo drive selection, a CAN physical layer running a proprietary protocol will not communicate with CANopen devices even with identical connectors.
I/O Capacity and Expansion
The controller must have sufficient digital and analog I/O channels to connect all safety sensors, operator interface elements, payload sensors, and ancillary functions. Count the required I/O points for the vehicle's full specification — including development-phase optional features — before selecting a controller, and choose a platform with meaningful expansion headroom. Controllers selected at minimum I/O capacity for the initial vehicle specification frequently require redesign when features are added during development or when the vehicle design is adapted for a new application variant.
Safety Function Integration
Most warehouse AGV and AMR applications require the vehicle controller to execute functional safety functions — emergency stop, protective field monitoring, safe speed limiting — that must meet defined performance levels under applicable safety standards such as ISO 13849 or IEC 62061. Controllers with integrated safety I/O and certified safety function libraries reduce the engineering effort required to achieve safety certification compared to general-purpose controllers where safety functions must be implemented and validated entirely in application software.
Confirm that the controller's safety architecture — hardware redundancy, diagnostic coverage, common-cause failure mitigation — matches the required performance level for the intended application. Safety performance claims should be supported by third-party certification documentation, not only manufacturer self-declaration.
Operating Temperature and Environmental Rating
The AGV controller operates inside the vehicle chassis — an environment that can reach elevated temperatures due to motor waste heat, battery thermal output, and limited ventilation. The controller's rated operating temperature range must cover the expected chassis interior temperature under continuous full-load operation, including seasonal ambient variation in the facility.
Controllers with passive thermal management — no internal cooling fans — are preferred for AGV applications where fan failure is an unacceptable maintenance event and where fan noise is unwelcome in quiet logistics environments. Fanless operation requires either a low-power controller design or adequate thermal coupling to the chassis structure for heat dissipation.
How the AGV Controller Integrates with the Drive System
The controller sits at the top of the vehicle's control hierarchy — it generates motion commands that flow down to servo drives, which execute those commands at the motor level and report status back up to the controller in real time.
The motion command interface between controller and servo drives must be specified in detail during vehicle architecture design. The command type — position, velocity, or torque — and the update rate must be matched between controller output capability and servo drive input capability. A controller that updates velocity commands every 10ms to drives that expect updates every 1ms will cause control instability. A controller that sends torque commands to drives configured for velocity mode will produce unpredictable behavior.
Odometry integration — accumulating encoder pulses from drive wheels to estimate vehicle position — must be implemented with attention to encoder resolution, wheel diameter calibration, and the geometric model of the specific vehicle drivetrain. Differential drive, single-steering-wheel, and multi-steering-wheel vehicles each have different odometry models, and errors in the geometric parameters of the model translate directly into navigation inaccuracy that cannot be corrected by drive system tuning.
Safety function integration requires that the controller's safety outputs — drive enable signals, safe torque off commands, speed monitoring outputs — are connected to the servo drive safety inputs in a way that achieves the required response time from safety sensor activation to drive de-energization. The complete safety chain — sensor to controller to drive to motor — must be validated as a system, not tested in isolation at the component level.
Common AGV Controller Selection Mistakes
Selecting based on software environment familiarity rather than hardware specification. Development teams familiar with a particular programming language or framework sometimes select the controller that supports that environment rather than the controller whose hardware specification best matches the application. Software environments can be adapted; hardware real-time performance, I/O architecture, and thermal characteristics cannot.
Underspecifying I/O for the production vehicle variant. Development vehicles frequently carry fewer sensors and fewer optional features than production variants. A controller selected for minimum I/O count on a development prototype may have no expansion capacity for the safety sensors, payload interfaces, and operator panels added in the production design.
Assuming safety certification transfers from component to system level. A controller with a certified safety architecture does not automatically produce a certified safe AGV system. The safety certification of the complete vehicle depends on the implementation of safety functions in application software, the integration of safety sensors and actuators, and the validation of the complete safety chain response time. Controller certification is a necessary but not sufficient condition for vehicle safety compliance.
Ignoring supply continuity for production programs. AGV production programs may span five to ten years. A controller based on a single-source processor or FPGA with limited production lifecycle creates supply risk that materializes mid-program as component obsolescence forces hardware redesign. Evaluate supplier product lifecycle policies and component sourcing strategy before committing to a controller platform for a volume production program.
What to Look for in an AGV Controller Supplier
AGV application reference designs and validation data. A supplier with documented reference designs for AGV drivetrain architectures — differential drive, single steering wheel, multi-axis — and validation data from real vehicle deployments provides more reliable guidance than a supplier offering general-purpose motion control hardware with AGV application notes as an afterthought.
Integrated hardware and software support. AGV controller performance depends on the interaction between hardware capabilities and firmware implementation. Suppliers who provide both the hardware and the firmware — and who treat motion control algorithm tuning, safety function implementation, and communication driver development as part of their product support scope — reduce the integration burden on the vehicle development team significantly.
Documented safety architecture for functional safety applications. For applications requiring functional safety certification, the supplier should provide a safety manual, FMEA documentation, and third-party certification evidence for the controller's safety architecture. The level of documentation provided is a reliable indicator of whether the supplier's safety claims are engineering-backed or marketing-only.
Long-term component supply commitment. Confirm the controller's bill of materials stability and the supplier's policy for managing component obsolescence. A supplier with a documented product lifecycle guarantee — typically five to seven years of production availability with advance notice of discontinuation — provides the supply planning visibility required for multi-year AGV production programs.
FAQ
What is the difference between an AGV controller and a fleet management system?
The AGV controller is onboard the vehicle — it controls the vehicle's motors, reads its sensors, and executes motion commands in real time. The fleet management system runs on external infrastructure — typically a server or cloud platform — and coordinates the missions, traffic, and task assignments of multiple vehicles in the facility. The controller and the fleet management system communicate over Wi-Fi or wired Ethernet, with the fleet system sending high-level mission commands and the vehicle controller executing them locally.
Does every AGV motor axis need its own controller?
No. A single vehicle controller typically manages all drive axes on the vehicle — traction motors, steering motors, and lifting mechanisms — through fieldbus connections to individual servo drives. The controller sends coordinated commands to all drives and receives feedback from all axes within each control cycle. Multi-axis control from a single controller is standard in AGV architectures.
What communication protocol is most common between AGV controllers and servo drives?
CAN bus running the CANopen protocol is the most widely used interface for AGV controller-to-servo-drive communication in warehouse mobile robot applications. It is robust, low-wiring-complexity, and broadly supported across servo drive manufacturers. EtherCAT is increasingly adopted in performance-critical platforms requiring sub-millisecond update rates. RS485 and Modbus remain common in cost-sensitive designs.
Can a standard industrial PLC be used as an AGV vehicle controller?
Yes, in appropriate applications. PLCs with motion control modules can meet AGV vehicle control requirements, particularly for simpler vehicles operating in structured environments. The practical limitations relate to form factor for mobile chassis integration, motion control cycle time performance compared to dedicated controllers, and total system cost. For high-performance AMR applications requiring sophisticated real-time navigation and precise motion execution, dedicated AGV controllers or distributed architectures typically provide better performance-to-cost ratios than general industrial PLCs.
What safety standard applies to AGV vehicle controllers?
ISO 3691-4 is the primary safety standard for industrial AGVs, specifying requirements for the vehicle as a system including its control functions. ISO 13849 and IEC 62061 provide the functional safety frameworks used to evaluate the performance level of specific safety functions implemented in the controller. CE marking for AGV systems deployed in EU markets requires compliance with the Machinery Directive, with ISO 3691-4 as the relevant harmonized standard. Controller suppliers targeting the AGV market should be familiar with these standards and their implications for controller architecture design.
Conclusion
The AGV controller is not a commodity component — it is the system element that determines the vehicle's motion accuracy, safety compliance, and long-term operational reliability. Controller selection decisions made during vehicle development cannot easily be reversed after production deployment, which makes getting the specification right at design time among the highest-leverage engineering decisions in an AGV program.
Evaluating controllers on processing performance, real-time determinism, communication interface compatibility, safety architecture, and supplier supply continuity — rather than software environment familiarity or unit cost alone — produces selections that support the vehicle's full performance capability across its operational life and avoid the mid-program hardware redesigns that result from underspecified controller choices.
Share:
AGV Steering Wheel Selection Guide: Load, Speed, Motor Power, And Installation Space