AGV Computing Architecture: Control vs Compute Layers
A technical reference for engineers designing autonomous mobile robot systems.
Table of Contents
Executive Summary
Separating control and compute layers in AGV systems improves determinism, simplifies safety certification, enables independent scalability, and increases long-term field reliability. This architectural pattern is now considered a baseline requirement for production-grade autonomous mobile robots.
The Evolution of AGV Computing Architecture
Early automated guided vehicles operated with relatively simple architectures. A single industrial controller handled both navigation logic and motor control, often using magnetic tape or wire guidance that required minimal computational overhead. Safety was achieved through physical bumpers and simple proximity sensors.
Modern AGV and AMR systems face fundamentally different requirements. LiDAR-based localization generates millions of data points per second. Vision systems require GPU-accelerated processing for obstacle detection and classification. Fleet management demands continuous wireless connectivity and real-time coordination between multiple vehicles.
The response to these converging pressures has been architectural separation: dedicated hardware for time-critical control functions, separate processors for computationally intensive perception and planning, and clear communication boundaries between layers.
Defining the Compute Layer
Compute Layer Characteristics
High throughput, soft real-time, intelligence-focused
Primary Responsibilities
- • SLAM and localization
- • Path planning and navigation
- • Obstacle detection and avoidance
- • LiDAR and camera processing
- • Fleet management communication
- • User interface and diagnostics
Typical Technologies
- • x86 or ARM SoC with GPU/NPU
- • Linux with ROS/ROS2
- • Gigabit Ethernet for sensors
- • WiFi/5G for fleet connectivity
- • CAN interface for control layer
- • SSD for map storage and logging
Compute Platform: Industrial PC with GPU/NPU running ROS2 navigation stackThe compute layer handles all perception, planning, and decision-making functions. Latency tolerance is significantly higher—50-200ms delays are acceptable for navigation updates. This allows the use of general-purpose operating systems and complex software stacks like ROS2.
Defining the Control Layer
Control Layer Characteristics
Real-time, deterministic, safety-critical
Primary Responsibilities
- • Motor velocity and position control loops
- • Encoder feedback processing
- • Battery management interface
- • Safety circuit monitoring
- • Emergency stop execution
- • Watchdog timer management
Typical Technologies
- • ARM Cortex-M or dedicated MCU
- • Real-time operating system (RTOS)
- • CAN Bus for command interface
- • Hardware safety PLCs
- • Motor driver ICs
- • Safety-rated I/O modules
The control layer executes with hard real-time constraints. Motor control loops typically run at 1-10kHz, requiring consistent latency below 1 millisecond. This layer receives high-level velocity commands from the compute layer and translates them into motor PWM signals.
Why Mixing Control and Compute Causes Problems
Timing Jitter
General-purpose operating systems like Linux cannot guarantee consistent timing. When running navigation algorithms alongside motor control on a single processor, heavy computational loads cause unpredictable delays in control loop execution.
Certification Complexity
Safety certification (ISO 3691-4, ISO 13849) requires demonstrating that safety functions operate correctly under all conditions. When safety-critical code runs alongside complex application software, the certification scope expands dramatically.
Fault Propagation
Software bugs, memory leaks, or crashes in navigation code can affect motor control when both run on the same hardware. A null pointer exception in path planning should never cause uncontrolled motor behavior.
Field Reliability Issues
Systems that work in laboratory conditions often fail in production environments. EMI from motor drives, thermal throttling under load, and OS update conflicts create intermittent failures.
Why Mixing Control and Compute Causes Problems
Timing Jitter
General-purpose operating systems like Linux cannot guarantee consistent timing. When running navigation algorithms alongside motor control on a single processor, heavy computational loads cause unpredictable delays in control loop execution.
Certification Complexity
Safety certification (ISO 3691-4, ISO 13849) requires demonstrating that safety functions operate correctly under all conditions. When safety-critical code runs alongside complex application software, the certification scope expands dramatically.
Fault Propagation
Software bugs, memory leaks, or crashes in navigation code can affect motor control when both run on the same hardware. A null pointer exception in path planning should never cause uncontrolled motor behavior.
Field Reliability Issues
Systems that work in laboratory conditions often fail in production environments. EMI from motor drives, thermal throttling under load, and OS update conflicts create intermittent failures.
Benefits of Layer Separation
Deterministic Motion
Dedicated real-time hardware ensures consistent control loop timing regardless of compute layer activity.
Fault Isolation
Software crashes in the compute layer cannot directly affect motor control. The control layer detects communication loss and executes safe stopping independently.
Independent Scalability
Compute layer can be upgraded for more complex AI algorithms without changing validated control hardware.
Simplified Certification
Safety-critical control layer can be certified independently from application software, reducing recertification scope for updates.
Reduced Integration Risk
Clear communication boundaries between layers simplify testing, debugging, and integration.
Long-term Maintainability
Each layer can be developed, tested, and upgraded by different teams with specialized expertise.
Technical & Architecture FAQs
Why do production-grade AGVs require a decoupled control and compute architecture?
Mixing real-time motor control and high-bandwidth perception (like SLAM) on a single processor creates timing jitter and instability. Decoupling ensures that safety-critical control tasks remain deterministic and uninterrupted, even under heavy AI processing loads.
How does the BITECH control layer achieve sub-millisecond determinism?
Our control layer utilizes dedicated ARM Cortex-M or industrial MCUs running an RTOS, specifically designed to handle motor velocity and position loops at 1-10kHz without the latency overhead inherent in general-purpose operating systems like Linux.
What is the benefit of hardware-level isolation for CAN bus communication?
Galvanic isolation (typically 4000V) in our control platforms protects sensitive logic from high-power traction motors and prevents ground loops, which are common in high-current warehouse environments where ground potential differences can exceed 50V.
How does BITECH’s unibody design handle extreme outdoor thermal conditions?
Our passive cooling unibody architecture uses the entire die-cast aluminum chassis as a single thermal mass to conduct heat away from the CPU/NPU. This eliminates the maintenance failures associated with fans, such as dust ingress and bearing wear, maintaining 100% performance even at 70°C ambient temperatures.
Can you perform OTA updates on remote AGV fleets without the risk of "bricking"?
Yes. BITECH platforms utilize a fail-safe dual-flash A/B partition architecture. If a firmware update fails or boot verification is unsuccessful, the system automatically rolls back to the last-known-good image, eliminating the need for expensive on-site manual recovery.
What compute performance is required for modern AMR perception and path planning?
Advanced AMRs performing multi-sensor fusion and real-time obstacle avoidance typically require 6-58 TOPS. Platforms based on the RK3588J provide high-performance edge inference at 32 TOPS, capable of running YOLOv8 with latency under 20ms.
Engineered for Autonomous Mobility: Secure Your AGV/AMR Logic
From perception-heavy VSLAM to real-time collision avoidance—our industrial edge controllers handle the compute load while you focus on the swarm intelligence. Our FAE team provides technical feasibility reviews, thermal analysis, and BSP customization tailored to your project.
Get Technical Assessment