AGV / AMR engineering · Control vs compute
Why AGV/AMR Compute and Motion Control Should Be Separated
Production AGVs and AMRs combine two very different computing problems. Trying to make one general-purpose Linux computer responsible for both can increase timing jitter, expand failure propagation and complicate validation.
Problem 1 · High-level compute
ROS 2, SLAM, perception, path planning, fleet communication and diagnostics.
Problem 2 · Deterministic control
Motor loops, drive communication, encoder feedback, actuator timing and safe response to missing commands.
In short
An AGV/AMR control vs compute architecture places ROS 2 navigation, SLAM, perception and fleet software on an industrial robot computer (the compute layer), runs motor loops on a dedicated MCU, motion controller or servo-drive network (the motion-control layer), and keeps emergency and protective stops on separately assessed safety hardware (the safety layer). The layers communicate over a defined interface such as CAN, CAN FD, EtherCAT or Ethernet, and the motion controller decides what happens when commands stop arriving.
Looking for the complete robot architecture including ROS 2, CAN FD, EtherCAT, functional safety, 24/48V power and fleet integration? See the AGV/AMR System Architecture Guide.
Quick answer
Compute vs control: three layers, three timing models
Compute layer · soft real-time
Industrial robot computer (x86 / ARM / Jetson)
ROS 2 · Nav2 · SLAM · perception · AI inference · fleet client · diagnostics
Defined interface · setpoints down, status up · CAN / CAN FD / EtherCAT / Ethernet
Motion-control layer · deterministic
MCU / RTOS / motion controller / servo drives
Velocity & position loops · encoder feedback · actuator timing · stale-command timeout
Independent safety chain · does not rely on the Linux computer
Safety layer · independently assessed
Safety PLC / controller + safety-rated devices
E-stop · protective stop · safety scanners · safe drive response
| Layer | Main responsibility | Typical hardware | Timing characteristic |
|---|---|---|---|
| Compute layer | SLAM, perception, navigation, AI, diagnostics, fleet client | x86 / ARM / Jetson industrial computer | High throughput, soft real-time |
| Motion-control layer | Motor commands, feedback loops, actuator coordination | MCU / RTOS / motion controller / servo drive | Deterministic |
| Safety layer | E-stop, protective stop, safety sensors, safe drive response | Safety PLC/controller + safety-rated devices | Independently assessed |
The industrial PC should normally be treated as the high-level robot computer, not automatically as the safety controller or the device responsible for hard real-time motor loops.
01 · Compute layer
What belongs in the AMR compute layer?
The compute layer handles workloads whose complexity and bandwidth are high, but whose timing requirements are different from motor-control loops. Typical platforms include industrial x86 computers, ARM edge computers and NVIDIA Jetson systems running Linux and ROS 2.
Typical responsibilities
- SLAM and localization
- ROS 2 / Nav2 path planning
- Camera and LiDAR processing
- Object detection and AI inference
- Sensor fusion
- Fleet communication
- Logging and diagnostics
- HMI and visualization
Size it for the combined workload
A compute platform should be selected according to the combined workload, not only CPU core count or published TOPS. Engineering validation should consider:
Camera resolution & FPSLiDAR scan rateROS 2 trafficAI model & precisionStorage write loadMemory useNetwork bandwidthSustained thermal load
02 · Motion-control layer
What belongs in the AGV motion-control layer?
The motion-control layer converts high-level motion requests into deterministic actuator behavior.
Typical responsibilities
- Motor velocity or position loops
- Encoder processing
- Servo-drive communication
- Actuator timing
- Stale-command detection
- Controlled response to lost communication
Commonly implemented using
- Dedicated MCU / RTOS
- Industrial motion controller
- Servo drive controller
- EtherCAT or CAN/CANopen network
The exact loop frequency depends on the drive, motor, controller and application. Motion-control loops may operate from sub-millisecond to multi-millisecond cycles. The important requirement is measured and repeatable timing within the limits specified by the motion system.
03 · Risk
Why mixing ROS 2 compute and motor control creates risk
Timing jitter
Linux, ROS 2 perception, logging, AI inference and network traffic can introduce variable processing load. If the same processor is also responsible for timing-sensitive motor loops, workload spikes may influence control timing.
Fault propagation
A crash, memory problem, driver fault or software update in the perception/navigation stack should not directly cause uncontrolled actuator behavior. Separating the layers provides a boundary where the controller can detect missing or invalid commands and apply a defined response.
Validation scope
The more application software included in a timing-critical or safety-related function, the harder it becomes to validate changes. Keeping high-level navigation separate from motion and safety functions reduces coupling between rapidly changing AI/software workloads and already validated control hardware.
Maintenance and upgrades
Perception hardware may need to move from RK3588 to Jetson or x86 + GPU as workloads grow, while the motion controller may not need to change. A layered architecture lets compute performance scale without forcing unnecessary redesign of the motor-control system.
04 · Interface
The interface between compute and control: CAN, CAN FD, EtherCAT
The boundary between the robot computer and the motion controller must be explicitly designed.
| Interface | Typical role | What must be validated |
|---|---|---|
| Classic CAN / CANopen | Drive commands, status, BMS, peripherals | Bus speed, termination, node IDs, timeouts, driver support |
| CAN FD | Higher-payload CAN communication | Controller/transceiver support, driver, bitrate configuration |
| EtherCAT | Synchronized drives and distributed I/O | NIC, master stack, drive profile, real-time configuration, measured jitter |
| Ethernet | High-level controller communication | Protocol, QoS, link-loss behavior, timeout handling |
| RS-485 / Modbus | Legacy devices and auxiliary I/O | Isolation, termination, timing, protocol |
Define the lost-command behavior
Every project should answer
- What happens if the robot computer stops sending commands?
- How quickly is a command considered stale?
- Which device initiates deceleration or stop?
- What happens after the Linux computer reboots?
This behavior must be designed into the controller and system architecture rather than assumed from the presence of a watchdog.
Illustrative stale-command sequence
- Commands stopRobot computer hangs, reboots or loses the link
- Timeout expiresMotion controller marks the last setpoint as stale
- Defined responseController applies the deceleration or stop set by the hazard analysis
- Held stateDrives remain in the defined state while the computer recovers
- Controlled re-enableMotion resumes only through the agreed restart procedure
Timeout values, deceleration profiles and re-enable rules are project-specific.
05 · Functional safety
The motion-control layer is not the safety layer
Do not treat separation between compute and motion control as equivalent to functional safety. A dedicated motion controller may improve determinism and fault containment, but this does not automatically make it a safety-rated controller.
Safety functions such as emergency stop, protective stop and safety-scanner response may require separately assessed safety hardware, safety-rated drives and a system-level risk assessment. For the full robot architecture, including safety, power and fleet integration, see the AGV/AMR System Architecture Guide.
06 · Hardware
Where the industrial PC fits in an AGV/AMR
For BITECH projects, the industrial PC normally sits in the compute layer. The correct platform depends on the actual sensor topology and software stack. Depending on the workload, this may be:
x86 industrial PC
For x86 software stacks, ROS 2 navigation and fleet applications.
Industrial Box PCs →
RK3588-class ARM
For cost-sensitive perception and control integration.
AE-3588 family →
NVIDIA Jetson
For CUDA / TensorRT workloads and multi-camera robots.
AE-NJ60BT →
MXM GPU edge AI
For high-performance vision or vision-language model workloads.
AE-760EBT →
Define before selecting hardware
Camera count / resolution / FPSLiDAR interfacesROS 2 distribution & Linux BSPCAN / CAN FD / EtherCATAI model & inference targetRAM / storageDC inputEnvironmental & thermal limits
AMR & AGV Industrial Computer Controllers → Isolated vs Non-Isolated I/O →
Glossary
Key terms in AGV/AMR control architecture
- Compute layer
- The high-level robot computer that runs ROS 2, SLAM, perception, path planning, fleet communication and diagnostics, with high throughput and soft real-time timing.
- Motion-control layer
- The MCU, RTOS, motion controller or servo-drive network that executes motor loops and actuator timing deterministically.
- Safety layer
- Separately assessed safety controllers, safety sensors and safety-rated drives that perform emergency and protective stops.
- Timing jitter
- Variation in when a periodic task actually runs; on a shared Linux computer, perception and logging load can increase it.
- Stale-command timeout
- The maximum age a motion request may have before the motion controller stops trusting it and applies a defined response.
- Lost-command behavior
- The documented sequence a robot follows when the compute layer stops sending commands, including who stops the drives and how motion resumes.
FAQ
Control vs compute: frequently asked questions
Can ROS 2 and motor control run on the same computer?
They can in some architectures, but the design must demonstrate that timing, fault containment and safety requirements are still met. For production AGVs and AMRs, separating high-level compute from deterministic motion control often reduces integration and validation risk.
Does using a real-time Linux kernel eliminate the need for a motion controller?
Not automatically. A real-time Linux configuration can improve timing behavior, but the decision still depends on the required cycle time, drive network, fail-safe behavior, software stack and validation scope.
Should CAN or EtherCAT connect the robot computer directly to the drives?
Both architectures are possible. The important question is which device owns the deterministic control loop. In many systems the industrial PC sends high-level setpoints while a motion controller or servo network executes the timing-sensitive functions.
Does an isolated CAN interface make the industrial PC a safety controller?
No. Galvanic isolation can improve electrical robustness and reduce ground-loop problems, but it does not provide functional-safety certification.
What happens if the AGV compute computer crashes?
The control architecture should define a communication watchdog or stale-command timeout so the motion-control layer can enter a predetermined state without relying on the failed compute computer.
Engineering review
Define the control boundary before selecting the robot computer
Before choosing CPU, TOPS or port count, define which device owns navigation, motion control, safety and lost-command recovery. BITECH can then recommend an industrial compute platform for the high-level robot-compute layer.
NavigationMotion controlSafetyLost-command recovery
BITECH can review your
- Sensor topology
- ROS 2 / Linux environment
- CAN / CAN FD / EtherCAT interfaces
- Compute workload
- DC power architecture
- Environmental requirements