How to Size an Edge AI Computer for Multi-Camera Machine Vision

That's because a multi-camera vision system is part of a larger machine, not a standalone benchmark target. In a robotic cell, autonomous mobile robot, or high-density inspection line, cameras provide perception; software interprets the scene; the machine then stops, rejects, routes, or moves. This is the useful hierarchy: Robotics defines the job. Physical AI closes the perception-decision-action loop. Edge AI is the computing layer that runs the loop beside the machine.

Ignoring that hierarchy is where sizing goes wrong. An accelerator may report impressive YOLO throughput while camera queues grow, CPU preprocessing spikes, exposures drift apart, or clocks fall after the enclosure heats up. The machine still misses its part.

Start with the action.

1. The Robot Sets the Deadline

Write down what happens after detection. A reject gate may have 100 ms between exposure and PLC output. A pick-and-place robot may need the pose before the object reaches its grasp window. An AMR perception stack may run object detection, depth, localization, and obstacle avoidance at the same time. ARBOR's AGV/AMR computers are built to run exactly that combination. These are different Physical AI workloads even when they use the same camera and the same YOLO family.

For each action, record the sensor-to-decision ceiling, acceptable exposure skew, maximum missed deadlines, and the safe behavior when the pipeline falls behind. Then describe the duty cycle: continuous 24/7 inspection, short bursts, or movement-dependent capture. This page becomes the acceptance contract.

2. Four Numbers That Change the Hardware Class

Record active width, active height, delivered FPS, and bytes per pixel for every camera. Do the math before choosing ports.

raw payload (MB/s) = width × height × delivered FPS × bytes per pixel × camera count ÷ 1,000,000

Eight 1920 × 1080 Mono8 cameras at 30 FPS produce about 497.7 MB/s, or 3.98 Gb/s, of image payload before Ethernet, USB, or framing overhead. Two 1080p30 Mono8 streams already total about 124.4 MB/s, effectively consuming the theoretical line rate of one 1GbE link before overhead and retransmissions. Basler's bandwidth guidance for multiple cameras walks through the same calculation from the camera-vendor side.

For eight uncompressed 1080p30 Mono8 cameras, do not build the aggregation path around single or dual 1GbE. Use a 10GbE-class uplink, enough independent NIC bandwidth, or a direct camera interface. Field debugging costs more than the network upgrade.

3. Physical AI Adds Work Around the Detector

The aggregate analyzed rate is simple:

aggregate inference rate = camera count × analyzed FPS per camera

Eight cameras analyzed at 20 FPS require 160 inferences per second. Benchmark the exact YOLOv5, YOLOv8, YOLO11, RT-DETR, EfficientDet, segmentation, pose, OCR, or anomaly engine at the production input shape and INT8, FP16, or FP32 precision, following NVIDIA's TensorRT performance guidance where the target platform runs TensorRT. Report inference-only latency for model comparison. Use sensor-to-decision latency for system acceptance.

Frames also pass through unpack or decode, Bayer demosaic, color conversion, lens correction, crop, resize, letterbox, normalization, inference, non-maximum suppression, tracking, sensor fusion, coordinate transforms, and PLC or robot output. An AI inspection robot may add pose estimation. An AMR may add SLAM and path planning. CPU headroom disappears quickly.

Queues grow fast.

Measure preprocessing with all sources active. A bounded worker pool usually produces steadier latency than one unconstrained thread per camera. Hardware ISP or GPU preprocessing can help when buffers remain in a zero-copy or low-copy path; otherwise memory transfers may erase the gain. Capture CPU load by core, run-queue depth, memory-controller traffic, accelerator utilization, and every buffer copy you can identify.

TOPS is useful for removing obviously undersized candidates. Stop there. A 5 ms engine at 160 inferences per second consumes roughly 800 ms of serialized accelerator time per second before preprocessing and contention. That is a benchmark requirement, not a purchase recommendation. Test concurrency and batch behavior on the target platform.

4. GigE, USB3, GMSL, and MIPI Serve Different Machines

Choose synchronization from the physical event. Use a shared hardware trigger when multiple views must describe the same moving part. Qualified GigE cameras may use PTP with action commands, following the same periodic-signal approach Basler documents for its own cameras. GMSL designs can distribute FSYNC through the serializer/deserializer path. NVIDIA's GMSL camera development guide covers the driver and virtual-channel requirements in detail. MIPI needs explicit support in the sensor, carrier, and driver stack. Measure exposure skew at the sensor output.

5. Batching Buys Throughput with Queue Time

A batch can raise accelerator utilization, but it waits for frames or a timeout. NVIDIA's DeepStream documents the same trade-off for its nvstreammux batching plugin. In a synchronized eight-camera cell, one delayed source can hold the group. Test batch sizes 1, 2, 4, and 8 when supported; log partial batches and per-source queue depth. Keep the smallest batch that meets throughput and the action deadline.

For a 100 ms sensor-to-PLC budget, an engineering allocation might reserve 10 ms for acquisition, 10 ms for transfer, 12 ms for preprocessing, 35 ms for inference, 8 ms for postprocessing and control output, and 25 ms for queue and operating margin. This is a test hypothesis. Replace every number with measurements from the production pipeline.

6. ARBOR Platforms Map to Camera Topology

The camera path should narrow the platform list before accelerator marketing numbers do. ARBOR's Edge AI computers span more than one camera-interface class, so matching the platform family to the camera path is the first cut. The AEC-6100 combines NVIDIA Jetson AGX Orin with eight GMSL camera inputs. The AEC-6200 uses four IEEE 802.3at PoE+ camera ports plus two GbE ports. Both belong to the fanless AEC-6000 family, which also provides isolated digital I/O, isolated CAN, 9-48 VDC input, and a published -25°C to +70°C operating range at 30 W TDP. Those are integration facts a robotics team can map to cameras, vehicle power, triggers, and control I/O.

Higher-density PCIe GPU work follows a different path. The FPC-9309W-G5 supports Intel Core Ultra Series 2 processors, up to 192 GB DDR5, four 2.5GbE ports, eight USB 3.2 Gen2 ports, dual external SATA bays plus two NVMe SSDs, and an NVIDIA RTX 50-series GPU up to 575 W. It suits workloads that need a larger GPU, heavier CPU preprocessing, more memory, and higher storage capacity. Plan the enclosure and power system around that class of heat.

For newer, very high-density perception stacks, the Jetson Thor T5000-based AEC-8000 series provides a QSFP interface for 4 × 25GbE. Variants provide eight GMSL, eight PoE, or eight additional USB 3.2 connections; combined variants are also listed. ARBOR states support for more than 64 HD video streams. Treat that claim as a platform capability statement, then validate the exact codec, resolution, FPS, models, and latency target.

These product facts make the architecture concrete. They do not replace a workload benchmark.

7. Heat, Storage, and Network Traffic Accumulate

Thermal envelope

Run acquisition, preprocessing, inference, control output, recording, and uplink traffic at the highest expected ambient temperature. Continue until clocks and temperatures reach equilibrium. Never approve a 24/7 machine from a five-minute desktop run. Log p95 and p99 latency beside frequency and temperature so throttling is visible in the same timeline.

Storage

Eight cameras encoded at 8 Mb/s each generate about 691 GB per day. The same eight 1080p30 Mono8 streams stored raw approach 43 TB per day. Define full-frame, defect-only, and pre/post-event retention separately. Verify sustained write rate, endurance, drive temperature, RAID policy, replacement procedure, and full-disk behavior.

Networking and PoE

Keep camera ingress separate from MES traffic, dashboards, model downloads, remote support, and event-video uploads when practical. For PoE, total the worst-case draw of every camera and leave switch-level power margin. Verify the uplink too. Four PoE ports feeding a 1GbE uplink do not create four gigabits of host bandwidth.

8. Eight Cameras on One Inspection Cell

Consider eight 1920 × 1080 Mono8 cameras at 30 FPS. The Physical AI pipeline analyzes 20 FPS per camera with a 640 × 640 YOLOv8s- or YOLO11s-class detector. A shared trigger captures the same part from eight views. The PLC needs a decision within 100 ms, and compressed event video is recorded at 8 Mb/s per camera.

The result is deliberately not a universal TOPS figure. It is a platform test specification. If the cameras are GigE, use 10GbE-class aggregation or enough independent host links. If the machine is mobile and uses GMSL, verify the deserializer and FSYNC path. Then run the real engine, recording policy, trigger burst, ambient condition, and PLC traffic together.

9. A Pass/Fail Test for Production

• Connect the production camera count through the intended NICs, USB controllers, GMSL deserializers, or MIPI lanes.
• Use final resolution, pixel format, exposure, trigger pattern, analyzed FPS, model engine, precision, tracking and sensor fusion.
• Enable preprocessing, PLC/robot control, MES communication, event recording, health monitoring and northbound traffic.
• Test at maximum specified ambient temperature in the intended mounting orientation and enclosure.
• Log camera counters, packet/USB errors, queue depth, CPU load by core, accelerator utilization, memory traffic, clocks, temperatures, storage latency and network throughput.
• Report p50, p95 and p99 sensor-to-decision latency, exposure skew, dropped frames and missed deadlines per camera.
• Run through thermal equilibrium; then add realistic trigger bursts, lighting changes, reconnects and storage events.
• Set pass/fail thresholds before the run. Zero unbounded queues. Zero silent frame loss.

FAQ

Sizing Checklist

Bring the robotics action deadline, camera matrix, model graph, precision, trigger method, retention policy, interface topology, power source, ambient range, and failure behavior into the first hardware review. Demand one sustained full-pipeline run on the target computer. That is the shortest path from a Physical AI demo to a reliable machine.

Need a platform review? Contact ARBOR with the camera matrix, model engine, latency target, interface topology, and operating environment.

ARBOR Platform and Technical References

• ARBOR Edge AI Computers
• ARBOR AGV/AMR Computers and Physical AI
• ARBOR AEC-6000 Series
• ARBOR FPC-9309W-G5
• ARBOR AEC-8000 Series
• Contact ARBOR
• NVIDIA TensorRT performance best practices
• NVIDIA DeepStream nvstreammux documentation
• Basler Bandwidth Manager