AMR / AGV Computer Selection Guide for Edge AI Robotics

That's because an AMR or AGV computer sits inside a moving power, thermal, and network envelope. Its job is broader than running a detector: it must acquire sensors, move and transform data, execute perception and localization, support navigation, exchange state with the fleet, log evidence, and recover from faults without missing the robot's action deadlines.

AMR and AGV Create Different Compute Envelopes

A conventional AGV usually follows a constrained route using markers, reflectors, magnetic guidance, or fixed infrastructure. Its computer may emphasize deterministic vehicle interfaces, reliable localization inputs, and fleet communication. An AMR navigates through changing spaces, builds or updates a map, detects obstacles, localizes against multiple sensors, and replans around people or equipment. That raises the demand for perception concurrency, memory movement, and bounded end-to-end latency.

The boundary is not absolute. Vision-guided AGVs can run workloads that resemble an AMR, while an AMR assigned to a simple corridor may use a modest perception stack. Classify the computer by the production tasks and deadlines, not by the label printed on the vehicle.

Start with a mission table: maximum speed, stopping policy, map size, localization update rate, obstacle-detection range, number of camera streams, LiDAR scan rate, fleet reporting interval, and degraded-mode behavior. Convert each item into a deadline and a consequence for a late result. A detector that produces 30 frames per second is still unsuitable if a burst of slow frames delays a navigation update beyond its budget.

Map the Physical AI Pipeline Before Choosing Silicon

The production pipeline may ingest cameras, LiDAR, radar, ultrasonic sensors, wheel encoders, and an IMU. Camera frames can pass through decoding, debayering, rectification, resizing, color conversion, normalization, and tensor preparation. Perception may then run an object detector such as a YOLO-family model, segmentation for free space, pose or depth estimation, and tracking. LiDAR and inertial data feed SLAM or localization; sensor fusion aligns observations in time and space; path planning and navigation turn the world model into a motion request.

ROS 2 and DDS commonly connect these components, but middleware configuration is part of the performance model. Message serialization, copies, quality-of-service settings, executor scheduling, and callback contention can change latency and queue behavior. Record the node graph, message sizes, publish rates, QoS policies, and whether zero-copy or hardware-accelerated paths remain available in the intended software stack.

Worked Example: Sensor Ingest Before Protocol Overhead

Consider four 1920 x 1080 cameras at 30 frames per second using unpacked YUV 4:2:2 at 2 bytes per pixel. The camera payload is 4 x 1,920 x 1,080 x 30 x 2 = 497,664,000 bytes/s, or 497.7 MB/s in decimal units. If a 32-beam LiDAR produces an assumed 600,000 points/s and each stored point occupies 16 bytes, it adds 9.6 MB/s. The combined payload is therefore about 507.3 MB/s before packet headers, blanking, copies, alignment, retransmission, and buffering. This arithmetic is an assumption-based sizing example, not an ARBOR product benchmark.

Separate the Edge AI perception and decision computer from safety control. The AI system can identify obstacles, estimate pose, and request a trajectory. Emergency stops, protective fields, drive enable, braking, and other safety functions must remain within a validated safety architecture using appropriately certified components and engineering processes. A general-purpose Edge AI computer should not be presented as a safety controller unless the exact product and integration have the required evidence.

Turn the Robot Mission into a Compute Budget

List each pipeline stage with input rate, data size, execution resource, expected concurrency, and deadline. CPU demand includes sensor drivers, image preprocessing not offloaded elsewhere, middleware, compression, mapping, planning, encryption, logging, and device supervision. Measure CPU headroom per core and inspect scheduler contention; a high average idle percentage can coexist with one saturated core that delays a callback.

For GPU or NPU sizing, record the exact model, input resolution, precision, runtime, batch size, and engine version. TOPS is a peak arithmetic figure under defined conditions. It does not describe operator coverage, tensor layout conversions, memory traffic, CPU preparation, or the cost of running several models together. Benchmark the deployed engines with the same segmentation, pose, depth, and detection mix that will run on the robot.

Memory capacity must hold the OS, ROS 2 graph, maps, model weights, engine workspaces, camera buffers, point clouds, navigation state, logging buffers, and OTA reserve. Memory bandwidth controls how quickly concurrent producers and consumers can move those assets. Profile bandwidth pressure and copies while every sensor is active; do not extrapolate from a single-model demo.

Concurrency is where many apparently adequate designs fail. Camera acquisition, preprocessing, inference, fusion, SLAM, planning, logging, and network transfers overlap. Track p50, p95, and p99 latency for each critical stage and end-to-end. Also track queue depth and age. A growing queue means throughput is below the incoming rate even if individual kernel timing looks acceptable.

Worked Example: a 100 ms Navigation-loop Budget

Suppose the latest acceptable command is 100 ms after sensor capture. One provisional budget could assign 10 ms to exposure and timestamp alignment, 15 ms to ingest and preprocessing, 25 ms to inference, 20 ms to fusion and localization, 20 ms to planning, and 5 ms to command publication. The subtotal is 95 ms, leaving 5 ms of explicit margin. These are design assumptions, not measured ARBOR results. The production test must show that the end-to-end p99, not only the average, remains within the 100 ms deadline while the complete stack is active.

Match Sensor Links to the Vehicle Architecture

Camera-interface choice follows the vehicle harness. A remote automotive-style camera may favor GMSL for a long coaxial link and synchronized capture, while MIPI CSI-2 is efficient for short board-level attachment. USB3 is accessible and flexible, but hubs, host-controller sharing, connector retention, and reset behavior become part of the robot design. GigE reaches farther over standard Ethernet; PoE can reduce cabling when the switch power budget and uplink still cover simultaneous operation.

The vehicle side creates a second topology. CAN or CAN FD, RS-232/422/485, encoder signals, wake lines, and digital I/O each carry electrical details that a port count cannot express: termination, isolation, voltage level, update rate, and degraded-state behavior. Driver support and physical controller sharing determine whether those nominal interfaces remain usable together.

An I/O worksheet is most revealing when it follows actual controller and PCIe paths. Payload, protocol overhead, bursts, camera blanking or compression, storage writes, and fleet traffic then expose shared bottlenecks. Disconnect and reconnect tests complete the picture because steady-state streaming never exercises device recovery.

Plan Robot, Fleet, and Maintenance Connectivity

Wired Ethernet may connect service tools, sensors, or an onboard switch. Wi-Fi is common for fleet coordination inside facilities, while 5G or LTE can support wide-area operations or a maintenance backhaul. The computer needs suitable expansion, antenna placement, driver support, and a network policy that handles roaming, temporary loss, and limited bandwidth.

Fleet management, telemetry, remote diagnostics, and OTA updates share a link with operational traffic. Priorities and rate limits keep a log upload from delaying a control-relevant message. When coverage disappears, the robot needs a defined local behavior; when an update fails, it needs a rollback image. Software and model identifiers in the logs connect a field event to the configuration that produced it. Remote access belongs behind authenticated, least-privilege paths rather than an open maintenance service.

Design for Mobile Power and Controlled Shutdown

A mobile robot rarely supplies laboratory-clean DC. Battery state, motor acceleration, regenerative events, charger connection, contactor switching, and harness resistance can create dips, surges, and interruptions. Specify the accepted input range together with transient profiles, duration, source impedance, and recovery behavior. Verify the complete installed system, including converters, cameras, storage, radio, and PoE loads.

Ignition or wake input and delayed shutdown allow the computer to stop services, flush logs, preserve the filesystem, and coordinate with the battery controller. Define how long the hold-up or shutdown window must last and what happens if power returns midway. Measure power at idle, typical mission load, peak concurrent load, startup, and shutdown; use those values for battery runtime and thermal design.

Qualify Thermal and Mechanical Behavior at Sustained Load

Fanless systems remove a moving part but transfer heat through the enclosure and mounting surface. Validate sustained performance at the maximum specified ambient temperature, in the intended mounting orientation and enclosure. Record CPU and accelerator clocks, temperatures, power modes, and workload latency over a mission-length soak. Thermal throttling can increase tail latency before an application reports an error.

Check vibration and shock requirements against the installed mass, bracket, connector retention, cable strain relief, and storage device. Dust accumulation, nearby heat sources, restricted airflow, and mounting against an insulating panel can change the result. Use the environmental specifications of the exact SKU, then confirm the assembled robot under its own qualification plan.

Size Storage for Maps, Evidence, Logs, Models, and Updates

Storage must cover operating system partitions, maps, calibration, event images or video, rosbag or application logs, model engines, crash dumps, and at least one update or rollback image. Estimate daily writes and retention, then account for filesystem overhead and free-space policy. Select media endurance and temperature rating from the write workload rather than capacity alone.

Worked Example: One Day of ROSbag Retention

Assume the four cameras are recorded at 8 Mbit/s each, the LiDAR stream uses the 9.6 MB/s payload from the ingest example, and navigation telemetry plus logs average 1 MB/s. The cameras contribute 32 Mbit/s, or 4 MB/s, so the bag receives about 4 + 9.6 + 1 = 14.6 MB/s. Over 86,400 seconds, that is 1,261,440 MB, or about 1.26 TB/day in decimal units. Seven days require 8.83 TB before filesystem reserve, indexing, write amplification, and OTA space. For comparison, retaining the four cameras in raw YUV 4:2:2 would add roughly 43.0 TB/day by itself.

Avoid unlimited logging. Use quotas, rotation, event triggers, health monitoring, and a defined upload policy. When evidence is required after an incident, synchronize time across sensors and logs and preserve the software, model, and calibration identifiers that make the data interpretable.

PoC Failures Appear at the Integration Boundaries

A bench PoC often runs one camera, one model, an open chassis, stable power, and a strong wireless link. The robot adds simultaneous sensors, long cables, shared controllers, background logging, motor noise, hot ambient air, radio roaming, and repeated suspend or power cycles. Small buffers and default timeouts that were invisible on the bench become queues, dropped frames, or long recovery intervals.

Recreate these boundaries early. Use the production camera models and cable lengths, onboard switch, radio, battery path, storage, mounting plate, container images, ROS 2 QoS, and fleet messages. Exercise cold start, brownout, link loss, camera reset, storage pressure, OTA rollback, and service restart. If a requirement is not observed under the installed configuration, it remains an assumption.

Write the Acceptance Matrix Before Choosing Hardware

Turn purchasing requirements into measurements with a condition, metric, threshold, duration, and evidence file. Run the complete production sensor stack and production software concurrently. Collect synchronized traces so a latency spike can be correlated with queue depth, clock changes, temperature, network loss, or storage activity.

State the numeric threshold in the project acceptance matrix rather than copying a generic value from another robot. The threshold should leave margin between the measured tail and the latest safe action time. Keep the raw traces, configuration manifest, and test script with the purchase decision.

Use ARBOR Platforms as Verified Design References

ARBOR groups rugged embedded computers for AGV and AMR applications on its official AGV & AMR Computers. The current page distinguishes NVIDIA Jetson AGX Orin systems from Intel-based configurations that support either a Hailo-8 M.2 or MemryX MX3 M.2 accelerator. That distinction matters: these are alternative platform architectures, not three accelerators presented as peers on one board. The category is a starting point; an exact product and I/O variant still has to match the workload manifest.

For Jetson AGX Orin designs, ARBOR's official AEC-6000 series lists a fanless system family, AEC-6100 support for eight GMSL cameras, AEC-6200 support for two GbE plus four IEEE 802.3at GbE PoE+ ports, serial, isolated digital I/O, isolated CAN, 9-48 VDC input, ignition control, and an operating-temperature statement tied to a 30 W TDP condition. The last qualifier prevents a temperature-range line from being detached from its published power condition. The chosen SKU, module configuration, accessories, and test conditions still need to be confirmed with ARBOR.

For higher-density next-generation workloads, the AEC-8000 Series official page lists Jetson Thor T5000, 128 GB LPDDR5X, two GbE ports, a QSFP interface for 4 x 25 GbE, Wi-Fi 6E and 4G/5G expansion, NVMe options, and BTO variants for GMSL, PoE, or additional USB 3.2. These features expand the design space for concurrent perception and sensor throughput; they do not convert a missing production trace into evidence.

Contact ARBOR with a Workload Manifest

A useful project brief for ARBOR contains the sensor list, model and runtime versions, ROS 2 graph, I/O topology, power transient profile, ambient and mounting conditions, storage retention, network recovery targets, and acceptance matrix. It gives the discussion a concrete basis for selecting an AGV/AMR computer, AEC-6000 variant, AEC-8000 configuration, or another suitable platform. Contact ARBOR Technology

FAQ