Heterogeneous by default

Compute selection in robotics looks continuous — more TOPS, more money, more watts — but in practice it clusters. It clusters because the constraints that matter change discontinuously. A motor loop needs a bounded worst-case response time, not throughput. A perception pipeline needs a memory bandwidth and an accelerated operator set. A foundation model needs enough dense compute to make a policy decision inside a control interval. Each of those constraints selects a different class of silicon, and the boundaries between them are sharp.

The practical consequence is that a single robot rarely lands in one tier. A mobile manipulator running a vision-language-action policy on a 700-TOPS module still drives its joints from a microcontroller, still speaks to its safety relay over a deterministic bus, and still reports battery telemetry from a low-power SoC. Four tiers, one chassis.

What follows is a map of the four classes: what each is for, what silicon serves it today, and the operational cost of spanning them.

The lowest tier is not a compromise; it is a different discipline. Microcontrollers here exist to close control loops at fixed intervals, drive motors and actuators, read encoders and limit switches, and hold a safety state when everything above them fails. There is no AI inference in this tier and none is wanted — a learned policy with a variable execution time is the opposite of what a joint controller needs.

Two families dominate. The STM32 line covers motor drives, industrial PLCs, medical equipment, and GPS platforms where reliable application control is the requirement. The ESP32 line trades some determinism for integrated Wi-Fi and Bluetooth plus ultra-low-power coprocessors, which is why it shows up in service robots, smart-home nodes, and sensor hubs that must sleep for months.

The defining shift in this tier is that acceleration moved on-die. Application processors now ship a dedicated neural block — NXP's eIQ-supported NPU, Qualcomm's AI Engine — sized for one camera stream, a keyword spotter, or a classical vision pipeline with a learned stage bolted on. One to four TOPS sounds modest, and it is: this is the tier for perceiving a specific thing reliably, not for reasoning about a scene.

NXP's i.MX 8M Plus and i.MX 95 target Industry 4.0 machine vision and automotive connectivity domain controllers. Qualcomm's Dragonwing QRB2210 and IQ6 push efficiency, landing in industrial gateways, HMI panels, and entry-tier robotics running mainstream Linux distributions.

Renesas is worth watching here for a different reason. One of the dominant automotive silicon vendors is carrying that functional-safety and longevity DNA into robotics with the RZ/V line, and doing it on efficiency rather than peak numbers — roughly 10 TOPS per watt, which is what makes a fanless, heatsink-free vision design possible. The RZ/V2H is also the clearest illustration of why these brackets are envelopes and not product categories: its dense throughput lands between tier 02 and tier 03, and its two Cortex-R8 real-time cores sit on the same die as the AI accelerator — the convergence pattern described in §06, arriving a tier earlier than expected.

Because these parts run a full Linux userspace, one board now carries five artifacts with five independent lifecycles: a kernel, a device tree, a container runtime, a model, and a vendor BSP. Each has its own release cadence — the kernel moves on upstream's schedule, the model on your training cadence, the BSP whenever the silicon vendor decides. Each has its own upstream, and none of them coordinates with the others.

Each also fails differently. A container that won't start is visible in seconds; a device-tree change that alters camera timing surfaces weeks later, in the field, as dropped frames. The dangerous one is the BSP bump: it can silently invalidate the other four, because it moves the kernel, the drivers, and the accelerator runtime underneath code that was validated against the previous combination. Tier 01 needed version control. Tier 02 onward needs a system of record.

Between the integrated-NPU tier and the humanoid brains sits a band that is easy to overlook and commercially enormous: 40 to 100 dense TOPS, rated for extended temperature, with functional-safety features in the silicon. This is the tier that runs sixteen cameras in a sortation cell, fuses lidar and radar on an outdoor AMR, or holds a certified safety function alongside a perception workload.

Qualcomm's Dragonwing IQ8 and IQ9 are octa-core platforms with ECC memory and safety-island partitioning — 20 to 40 dense TOPS on the IQ8, 100 on the IQ9, with up to sixteen concurrent camera inputs. AMD's Ryzen AI P100 and Versal AI Edge parts target digital cockpits and sensor fusion with deterministic control from −40 °C to +109 °C. NVIDIA serves the same band from above: Jetson Orin NX at 157 INT8 TOPS in a 25 W envelope, and AGX Orin configurable from 15 W to 60 W — one module that can be specified as a dense-perception part here and as a reasoning part in the tier above. The engineering constraint here is rarely peak TOPS; it is thermals, certification evidence, and a ten-year supply commitment.

The top tier exists because a new workload arrived: multimodal models running on the robot, in the loop, at interactive rates. Vision-language-action policies, on-device VLMs, and generative reasoning over a scene are not accelerated classical vision — they are datacenter-shaped workloads compressed into a 40 to 130 watt module bolted to something that moves.

NVIDIA's Jetson Thor quotes 2,070 FP4 TFLOPS on Blackwell silicon, purpose-built for generative reasoning and humanoid spatial awareness. Qualcomm's Dragonwing IQ10 pairs a quoted 700 AI TOPS — datasheets list 350 dense — with an 18-core Oryon CPU and support for 20-plus sensors across camera, lidar, radar, and IMU. AMD's Ryzen AI X100 pushes CPU core count alongside AI throughput for the most demanding autonomous systems.

Most fleets in the field today, though, run the previous generation: Jetson AGX Orin at 275 INT8 TOPS is the incumbent robot brain, and it will stay in production designs for years. That gap matters more than the headline benchmarks. A program that qualified on Orin and wants Thor-class reasoning is not swapping a module — it is changing GPU architecture, CUDA target, quantisation strategy, and thermal design at once, on a robot already in service.

What is genuinely new is the update cadence. Model weights change weekly; an operating system image does not. A tier-04 robot needs to accept a new policy without rebuilding its OS, and needs to reject one that regresses — automatically, in the field, on a subset of the fleet first.

Any survey that stops at integrated modules misses the configuration a large share of physical-AI robots actually ship with: an x86 host — a COM Express or NUC-class board built on Intel Core Ultra or AMD Ryzen Embedded — with an NVIDIA RTX GPU on PCIe or an MXM module beside it. It is not the elegant answer, and it is frequently the right one.

The reason is continuity. The policy was trained on x86 with an RTX card; running it on x86 with an RTX card removes cross-compilation, driver divergence, and the entire class of "works on the workstation" defects. VRAM is the other argument: 24 GB on an RTX PRO 4000 Blackwell SFF at 70 W, up to 96 GB on the larger RTX PRO parts, where integrated modules cap at 64 or 128 GB of shared memory. And the GPU is a replaceable part — a robot designed around a PCIe slot or an MXM socket can take next generation's silicon without a mechanical redesign.

The costs are equally concrete. System power lands between 150 W and 400 W, which means active cooling, filtered airflow, and a thermal design that survives vibration. There is no safety island, no lockstep core pair, and no automotive qualification on a workstation GPU — the safety function has to live on a separate controller, which puts you back in tier 01. Host-to-GPU transfers cross PCIe rather than sharing memory. And consumer or professional GPU lifecycles are short next to a ten-year industrial program, which is why embedded MXM vendors sell five-year lifecycle commitments as a headline feature.

Read the tiers as a bill of materials rather than a roadmap and the operational picture becomes clear. A single production robot commonly carries silicon from three tiers; a product family in the field spans all four. Each tier brings its own toolchain, its own artifact format, its own signing story, and its own CVE surface. Nothing about that is exotic — it is simply four parallel software supply chains inside one serial number.

There is one convergence worth naming. Across the mid and upper tiers, vendors are integrating the lower tiers back into the die — safety islands, separated real-time subsystems, dedicated Cortex-M or Cortex-R complexes sitting beside the AI engine. Qualcomm's IQ8 ships a physically and electrically separated real-time core cluster; NXP's i.MX 95 pairs its application cores with an M7 and an M33; Renesas puts two Cortex-R8 cores on the RZ/V2H beside its NPU; AMD's P100 argues determinism as a feature of an x86 part. The intent is identical in every case: when the generative model fails or stalls, something with a bounded response time still stops the machine. That does not collapse the tiers into one — it means a single die now contains two of them, each with its own lifecycle.

Independent of vendor, the same four capabilities show up on every serious multi-tier program:

None of these are properties of a chip. They are properties of the control plane sitting above the chips.

The four tiers are not a transitional state. They exist because four different constraints — bounded response time, accelerated perception, certified safety, dense reasoning — do not resolve into one piece of silicon, and there is no roadmap on which they will. Heterogeneity is the steady state, and the vendors are confirming it by putting safety islands and real-time complexes back onto their largest dies.

There is one industry that has lived with this profile for decades: automotive. A modern vehicle carries dozens of compute domains across every criticality class, updates over the air, and stays in service for fifteen years. Automotive absorbed that complexity slowly, with fifty years of Tier-1 suppliers, standards bodies, and certification regimes built to carry it. Robotics is inheriting the same profile with none of that scaffolding, from day one, at startup headcount. A twenty-person humanoid company now signs up for an electronics architecture that used to require an OEM.

That is what is being born: a machine category with automotive-grade architecture and datacenter-grade update cadence. Industrial and commercial operators will be the first beneficiaries. They have structured environments, supervised deployments, and customers who pay for uptime rather than novelty. Consumer comes later, and consumer is the point. The industry's obsession with robotics is, underneath, a bet that it becomes the next great consumer platform. The brands that intend to own it are securing their positions now, in the fleets they ship over the next five years.

The teams that win will not be the ones that picked the best module. The parts are documented, supported, and largely interchangeable within a tier. The hard problem moved up a layer, to coordination: keeping four artifact types, four release cadences, and four failure modes in agreement across a fleet that is already in service. That work does not show up on a spec sheet, and it is not optional.

Corrections, counterarguments, and figures we got wrong are welcome — the appendix is the page that ages first. Technical detail on managing multi-tier fleets lives at docs.peridio.com.

The same parts arranged on the axes that decide programs. Read A.1 for the envelope and A.2 for whether you can actually ship it.

Figures verified against vendor publications in July 2026. Silicon roadmaps move quarterly; treat the appendix as the page that ages first.