Engineering guide · Reviewed October 2026
AGV/AMR System Architecture: ROS 2, Motion Control, Safety and Fleet Integration
A production-ready autonomous mobile robot needs more than a fast processor. It needs clear boundaries between navigation software, deterministic motor control, independent functional safety, battery power and fleet communication. This guide shows how to structure those responsibilities, select industrial compute hardware, and validate the full robot before deployment.
Answer these before choosing TOPS or port counts
- Which device owns the safety stop?
- What happens if the ROS 2 computer hangs?
- Can the sensor and driver stack run together without latency spikes?
- How does the robot respond to a 24/48V battery brownout or a fleet network outage?
Quick answer
A practical AMR/AGV architecture in five domains
Fleet manager
Orders, traffic, status · VDA 5050
Wi-Fi / 5G · offline policy defined
Navigation sensors
LiDAR · cameras · IMU · encoders · GNSS
Ethernet · USB3 · GMSL2 · MIPI
Robot computer (industrial PC)
Linux · ROS 2 · Nav2 / SLAM · perception · VDA 5050 client · diagnostics
Velocity / setpoints · CAN · CAN FD · EtherCAT
Motion controller & drives
MCU / RTOS / servo drives · deterministic loops · stale-command timeout
Safety controller
Separately assessed · safety scanners · E-stop · safe stop to drives
Independent of the Linux computer
Vehicle power
Battery · BMS · DC-DC stages · fusing · hold-up — feeds every domain
| System domain | Typical responsibility | Typical implementation | What to validate |
|---|---|---|---|
| Perception and navigation | LiDAR/camera ingest, localization, SLAM, Nav2, missions, logging | Industrial ARM, x86 or Jetson computer running Linux/ROS 2 | CPU/GPU/NPU use, memory, bandwidth, latency, thermal headroom |
| Deterministic motion | Wheel-speed/position loops, actuator feedback, drive enables | Dedicated MCU, motion controller, RTOS, servo drives or suitable industrial controller | Cycle-time jitter, drive protocol, stale-command timeout, safe response |
| Functional safety | Emergency stop, protective stop, safe motion functions where required | Separately assessed safety controller/PLC, safety sensors and safety-rated drives | Hazard/risk assessment, safety integrity, diagnostic coverage and stop verification |
| Fleet and supervision | Job assignment, traffic rules, status, maintenance, software rollout | Onboard fleet client + fleet management service, wired/wireless link | Offline behavior, reconnection, version interoperability and cybersecurity |
| Vehicle power | Stable rails for compute, controls, sensors and braking/charging events | Battery, BMS, DC-DC stages, fusing, protection and optional hold-up | Worst-case input voltage, regenerative events, startup, shutdown and energy budget |
Design rule: Treat the industrial PC as the high-level robot computer. A hardware watchdog, ROS 2 collision monitor, CAN isolation or secure boot does not by itself make it a certified safety controller.
For the deeper separation of processing and control responsibilities, see AGV Computing Architecture: Control vs Compute Layers.
Looking for an AMR/AGV computer rather than an architecture guide? Compare BITECH AMR & AGV industrial computer platforms, see ARM Controller.
01 · Sensors to actuators
Define the data and responsibility boundaries
A practical deployment starts at the sensors, not at a processor datasheet. A warehouse AMR may use a 2D LiDAR, IMU and wheel encoders. An outdoor delivery robot may add stereo or surround-view cameras, GNSS, depth sensing and cellular telemetry. Each sensor requires a real physical link, a timestamp strategy and a supported driver.
-
Acquire sensor data
Match LiDAR to Ethernet/USB; cameras to GigE, USB3, MIPI CSI or GMSL2 as appropriate. Check actual aggregate bandwidth rather than counting ports.
-
Estimate state
Combine odometry, IMU and localization using a validated transform and time-synchronization model.
-
Plan motion
ROS 2/Nav2 may create routes, trajectories or velocity requests, subject to the robot’s constraints.
-
Execute motion
A dedicated controller or drive network performs the timing-sensitive loops and handles missing or invalid commands.
-
Enforce safety independently
Safety sensors and safety-related functions can cause a protective response without relying on the general-purpose Linux computer.
-
Report fleet state
A separate software client exchanges orders, status and diagnostics with the supervisory system.
Do not assume all AI inferences need to be on the motion-control path. Semantic object recognition may help navigation, but a delayed recognition result must not disable a safety-rated protective function.
02 · Software stack
ROS 2, Nav2 and SLAM: match the software release to the actual BSP
ROS 2 distributions in 2026
| ROS 2 release | Reference Ubuntu release | Engineering selection consideration |
|---|---|---|
| Lyrical Luth (2026 LTS) | Ubuntu 26.04, Tier 1 | New developments where all kernel, camera, CAN and vendor libraries are compatible |
| Jazzy Jalisco (2024 LTS) | Ubuntu 24.04 | Established LTS option for production designs with validated dependencies |
| Humble Hawksbill (2022 LTS) | Ubuntu 22.04 | Existing, validated deployments; review remaining support and migration planning |
Important: A processor being ARM64 or x86 does not prove that a BITECH shipping image supports these combinations. Board support packages, device trees, kernel drivers, JetPack/RKNN releases and third-party camera SDKs may impose different Linux versions. Request a tested image, exact kernel, device enumeration and compatibility evidence for each proposed configuration.
A useful end-to-end ROS 2 test includes
- Sensor topics and QoS policies (particularly BEST_EFFORT vs RELIABLE on LiDAR and camera feeds).
- The
map → odom → base_link → sensorTF chain and time synchronization. - SLAM Toolbox, AMCL or another localization pipeline; Nav2 planner/controller and recovery behavior.
ros2_controlwhere applicable, including the bridge into actual motor controllers.- Continuous rosbag/logging, diagnostics, telemetry and realistic fleet traffic.
- A workload soak test: sustained CPU/RAM/GPU/NPU use, dropped frames, storage writes, thermal throttling and restart behavior.
ROS community troubleshooting shows that DDS QoS mismatches, incorrect Nav2 controller plugins and hardware integration assumptions can break deployment even when source code compiles. These reports are problem signals, not validated hardware benchmarks.
What TOPS does—and does not—tell you
A native RK3588J NPU can accelerate supported neural-network operators after model conversion and validation. It is not a direct measure of 2D LiDAR SLAM, ROS 2 middleware, point-cloud registration, route planning or drive control. Some of those workloads run on CPUs, some on GPUs, and some may benefit from acceleration only when the software specifically supports it.
For an AMR workload, collect camera resolution/FPS, model architecture and precision, LiDAR scan rate, localization frequency, target inference latency, RAM/VRAM use and sustained platform power. Benchmark the combined stack rather than a published peak TOPS number.
03 · Motion networks
CAN, CAN FD, EtherCAT and stale-command recovery
CAN can connect the host to drives, battery management, lifts and auxiliary controllers. But two CAN connectors do not automatically imply CAN FD, CANopen, native SocketCAN support or deterministic closed-loop performance.
| Interface | Appropriate role | Required integration check |
|---|---|---|
| Classic CAN / CANopen | Drive command/status, BMS and peripherals | Controller/driver, bus speed, termination, node IDs, PDO/SDO and application timeout |
| CAN FD | Higher-payload device communication, when supported end-to-end | CAN FD controller and transceiver on both ends, driver and bus configuration |
| EtherCAT | Synchronized motion networks and distributed I/O | Compatible NIC, master stack, licensing, drive profile, RT kernel and measured jitter |
| RS-485 / Modbus RTU | Legacy peripherals and industrial I/O | Isolation/grounding where required, bias/termination, serial timing and device protocol |
| Ethernet / DDS | LiDAR, cameras, navigation/fleet nodes | Traffic separation, QoS, time sync, link drops, network failover |
Fail-safe command behavior matters more than a peak bus bitrate. Define the maximum valid age of a cmd_vel/drive request and what the motor controller does when commands stop arriving. The required response must be derived from the robot’s hazard analysis and system design.
Isolated CAN: what the engineering specification must actually say
Galvanic isolation can reduce ground-loop and common-mode interference across differently referenced equipment. Specify the actual isolated channels, dielectric withstand test method/duration, continuous working voltage, common-mode transient behavior, isolation supply and physical connector arrangement. A “4000V isolation” headline alone cannot prove fitness for an application or functional safety compliance.
With power off, an approximately 60-ohm measurement across CAN_H/CAN_L is expected only when the measured bus has two 120-ohm end terminators in parallel with no additional termination or paths materially affecting the reading. It is a commissioning clue—not proof of correct bit timing, cable topology or signal quality.
04 · Functional safety
Functional safety is a separate engineering boundary
For driverless industrial trucks and relevant AGV/AMR systems, ISO 3691-4:2023 is an important current reference for machine-level safety requirements and verification; a revision is in development as of October 2026. The applicable scope, edition and assessment route depend on the machine and market. Other standards, including ISO 13849 or IEC 62061, may be relevant to particular safety-related control functions.
Navigation obstacle avoidance
May use Nav2 costmaps, planners and software collision monitors.
Protective safety functions
May require independently assessed sensing, safe motion and stopping systems designed to a specified performance level or safety integrity level.
Cybersecurity
Protects software and communications; TPM/Secure Boot does not substitute for functional safety engineering.
The Nav2 Collision Monitor supports software stop/slowdown zones, but do not label the feature “safety certified” without independent assessment. The robot integrator should document who owns E-stop, protective stop, overspeed, loss of localization, loss of communication, recovery and re-enable.
Example fault-ownership matrix
A starting template for that documentation. The actual detection method and response for each event must come from your hazard and risk assessment.
| Event | Detected by | Typical response owner | Must not depend on |
|---|---|---|---|
| E-stop pressed | Safety controller | Safety controller → safety-rated drive stop | Linux computer, ROS 2, fleet link |
| Protective field intrusion | Safety scanner + safety controller | Safety controller → protective stop or speed limit | Nav2 costmaps or collision monitor |
| Commands stop arriving | Motion controller command timeout | Motion controller → defined stop behavior | The robot computer noticing its own fault |
| Robot computer hangs or reboots | Motion controller heartbeat; hardware watchdog | Motion/safety chain holds a safe state; watchdog recovers the PC | The watchdog as the primary safety measure |
| Loss of localization | Navigation stack | Robot computer → halt mission, request recovery | Fleet manager reaction time |
| Fleet network dropout | VDA 5050 client | Robot computer → defined offline policy | Being treated as permission to ignore local safety |
| Battery brownout / BMS disconnect | BMS, power monitor | Power architecture → managed shutdown, drives safe | Undervoltage lockout alone |
05 · Battery power
Battery-powered AMR computing: 24V, 48V and power-loss behavior
A 9–36V industrial PC cannot connect directly to an unregulated 48V battery rail. For a 48V-class robot, specify an appropriately rated DC-DC converter or a separately validated wider-input design. Validate the actual chemistry, nominal voltage, charging maximum, allowable brownout, regeneration/transient conditions and power distribution.
For both 24V and 48V applications, ask
- What is the min/max steady input voltage at the PC terminals during charge and discharge?
- What voltage and duration occur during motor start, braking and BMS disconnect?
- Is reverse polarity, inrush and surge protection provided at the right point in the system?
- Is enough energy reserved for the operating system to flush storage and shut down?
- If power collapses without warning, is storage configured with suitable journaling/recovery provisions?
- How will a drive-safe state be maintained while the compute host reboots?
Undervoltage lockout is not the same as graceful shutdown. A clean shutdown requires detection, software sequencing and sufficient hold-up energy or a managed power architecture. A transient voltage suppressor alone also does not establish regenerative-energy absorption or load-dump qualification.
The robot’s total energy budget
Estimate average and peak consumption of compute, cameras, LiDAR, drives, radio, safety electronics and accessories independently. Compute power alone does not determine the overall robot runtime. Charge/dock events, cooling fans and GPU inference spikes can change the design margin.
06 · Fleet integration
VDA 5050 3.0: mixed fleets, free navigation and local decision-making
VDA 5050 is a robot-to-fleet-management interface, not a motor fieldbus or an embedded IPC hardware certification. Version 3.0 was released in 2026. Its updates include zone concepts and planned-path sharing for more freely navigating mobile robots, alongside revisions to operations and error handling.
Navigation
An onboard ROS 2 navigation stack owns the robot’s mapping/localization and local planning.
Fleet client
A distinct VDA 5050 client exchanges orders, state and path-related data with a compatible fleet manager.
Diagnostics
A diagnostics service records detailed fault evidence—sensor health, system load, drive errors and timestamps—rather than forcing all troubleshooting into limited fleet status messages.
Network loss
Defined behavior on Wi-Fi dropout prevents a network outage from being treated as permission to ignore local safety controls.
This separation allows the fleet interface to evolve without making the fleet protocol responsible for drive-level control. Validate VDA 5050 version interoperability with the customer’s actual fleet software rather than assuming version 3.0 compatibility because the hardware has Wi-Fi or Ethernet.
07 · Fleet maintenance
Cybersecurity and long-term fleet maintenance
A robot fleet requires secure provisioning, authenticated access, versioned system images, vulnerability response and staged updates. TPM 2.0 and Secure Boot can support parts of a secure architecture when implemented and provisioned correctly; they are not proof that a system is invulnerable or compliant with every standard.
EU Cyber Resilience Act timeline
11 Sep 2026
Vulnerability and incident reporting obligations started
11 Dec 2027
Full application scheduled
Product classification and manufacturer responsibilities should be assessed with the actual deployment and legal obligations.
Specify in an OEM program
Software support duration, driver/BSP dependencies, SBOM or component inventory as applicable, update signing responsibilities, rollback design, field-service logging and controlled BOM/PCN procedures.
Never promise that a processor swap across Intel generations automatically avoids mechanical, electrical or certification revalidation.
08 · Hardware selection
How to select BITECH industrial computers for this architecture
The following are candidate compute hosts, not certified robot safety controllers or prevalidated complete ROS 2 systems.
RK3588J · ARM
Compact ARM edge host with moderate sensor/AI workloads and isolated classic CAN
Qualify: exact Ubuntu/Debian image, ROS 2 compatibility, RKNN model support, isolation report, actual DC and temperature envelope
View AE-3588BT →
Jetson Orin NX
Multiple cameras and CUDA/TensorRT-based perception
Qualify: JetPack version, GMSL2 adapter/camera drivers, thermal/power limits, CAN FD implementation
View AE-NJ60BT →
Intel x86
x86-based navigation host, legacy software or industrial peripherals
Qualify: CPU-specific image, CAN driver, motion network stack, power and vibration integration
View AX-238BT →
RTX MXM · air-cooled
Multiple cameras, large perception models or sustained GPU workloads
Qualify: sustained GPU TGP/power, fan airflow, dust exposure, software stack and system-bus budget
View AE-760EBT →
RTX MXM · liquid-cooled · development
A protected compute compartment needing remote heat rejection
Qualify: full cooling-loop DVT, radiator ambient, pump/fan failure, shock/leaks and complete vehicle power budget
View AE-960EBT →
Full comparison
AMR & AGV Controller Solutions
Model comparison, specifications and RFQ for all five platforms.
This article focuses on how the components work together and what must be verified.
Compare platforms →
The AE-960EBT compute unit uses liquid cold plates, while the external radiator uses fans. It is not a completely fanless cooling system and should not be represented as qualified for every outdoor ambient before DVT.
09 · Commissioning
Commissioning and design validation checklist
Use application-defined pass/fail limits; the values cannot be inferred from a generic datasheet.
| Validation area | Field-ready evidence to request or record |
|---|---|
| ROS 2 / BSP | Exact OS, kernel, ROS 2 version, packages, build flags and hardware driver versions |
| TF / time synchronization | TF tree, timestamp offsets, odometry calibration and localization error under test |
| Perception and navigation | Combined CPU/GPU/NPU, RAM, dropped frames, goal completion and recovery logs |
| Motor network | CAN/CAN FD or EtherCAT traces, termination, error counters and timeout response |
| Safety response | Risk-assessment-defined stop tests, faults and restart behavior on the assessed safety chain |
| Battery and restart | Cold startup, max charge, transient, undervoltage, abrupt power loss and recovery |
| Thermal and vibration | Temperature/clock logs at steady state, vehicle mounting and harness retention |
| Fleet network | Wi-Fi handoffs, link loss, reconnect, duplicate order prevention and offline behavior |
| Software updates | Image signature, update interruption, rollback and recovery procedure |
| Production lifecycle | Fixed or controlled BOM, PCN/EOL terms, reproducible images and field-replacement procedure |
10 · FAQ
AMR/AGV engineering FAQs
Can ROS 2 and Nav2 directly provide certified emergency-stop functionality?
Not by installing them on a conventional industrial PC. A machine’s safety functions require hazard analysis, appropriate safety-related hardware/software and validated stopping behavior. Nav2 obstacle handling is useful for navigation but should not be presented as a replacement for a qualified safety system.
Does a robot with 2D LiDAR SLAM need a 58 TOPS computer?
Not necessarily. Typical 2D mapping/localization is largely determined by its algorithms, CPU, memory and sensor data paths. NPU TOPS matters mainly when supported neural inference models form part of the workload. Benchmark the real ROS 2 application.
Does dual CAN mean dual CAN FD and SocketCAN support?
No. These are separate characteristics. Confirm the transceiver/controller, Linux kernel driver and required higher-layer protocol on the specific SKU and image.
Can a 9–36V industrial PC run from a 48V AGV battery?
Not directly from an unregulated 48V-class rail. Use a correctly rated converter or a tested 48V-capable configuration, with protection and validation against charge/regeneration conditions.
What changed in VDA 5050 version 3.0?
It extends mixed-fleet use for freely navigating robots, including zone concepts and planned-path sharing. It does not control motor drive loops or certify the robot’s safety functions.
Which ROS 2 version should a new AMR project use?
Choose from supported LTS releases, but only after checking the sensor, kernel, driver, NPU/GPU and vendor BSP stack. In 2026, Lyrical (Ubuntu 26.04) and Jazzy (Ubuntu 24.04) are relevant new-project options; Humble remains important for existing deployed systems.
How should an AMR behave if the main computer fails?
The motion and safety architecture should detect missing or stale commands and transition to a risk-assessed safe condition independently of the failed navigation computer. A watchdog reboot is a recovery aid, not the primary safety measure.
Engineering review
Need a review of your AMR/AGV hardware architecture?
We review suitable compute platforms, I/O and ODM requirements against a practical qualification plan.
Send us
- Sensor models and data rates
- ROS 2 / JetPack / BSP version
- Drive protocols and CAN / CAN FD requirements
- Battery voltage profile
- Enclosure and ambient constraints
- Safety-system boundary
- Pilot and annual volume