How to Choose a Robotics Development Board & Compute: The 2026 Buyer's Guide

Most robot compute is chosen the way people buy laptops: pick the board with the biggest number on the box, assume more is safer, and sort out the software later. It rarely survives contact with the robot. A team building a small autonomous rover reads that one module does 40 TOPS and another does 275, buys the 275, and then discovers it draws 40 watts they do not have in the battery budget, runs hot enough to need a fan they cannot fit, and spends three weeks fighting a board support package because the vendor's Linux image lags the mainline kernel their sensor driver needs. The TOPS number was the least of the constraints that actually mattered, and it was the only one they checked.

The order that works starts from the workload, not the board. A robot's compute has two jobs that pull in opposite directions. One is hard real-time: reading encoders, closing motor loops, servicing safety interrupts on a fixed schedule measured in microseconds. The other is throughput: running perception, planning, mapping, and increasingly a neural network, on a general-purpose operating system where a few milliseconds of jitter is fine. No single chip is good at both, which is why the most common robot compute architecture is two chips, a microcontroller doing the deterministic low-level work and a Linux computer doing the heavy thinking, talking to each other over a serial or Ethernet link. Decide what your robot actually has to compute, at what rate, with what determinism, and the tier picks itself.

This guide is the buying hub for robot compute on this site. It gives you a decision framework by buyer segment and workload, the five durable compute tiers and where each wins, the real-time-versus-Linux split and the microcontroller-plus-single-board pairing that resolves it, how to read AI throughput without getting fooled by a TOPS headline, the I/O and power and thermal constraints that decide whether a board survives the robot, the ROS 2 and ecosystem support that decides how fast you ship, budget tiers, the vendor landscape, and the total cost of ownership that a datasheet never shows. It points throughout at the deeper edge AI and robot compute guide.

The take: Choose the workload before the board. Split the robot's computing into the deterministic part (motor loops, safety, sensor timing) and the throughput part (perception, planning, learned models), because they want different silicon. The deterministic part wants a microcontroller with hard real-time behavior; the throughput part wants Linux on a single-board computer or, if a neural network is in the loop, an AI module with an NPU or GPU. Most real robots run both, a small MCU paired with a bigger Linux brain, and that pairing is the default you should reach for unless you have a reason not to. TOPS matters far less than most buyers think and software support matters far more: a board with a mature ROS 2 stack, a mainline-tracking kernel, and drivers for your exact sensors will ship a robot months before a faster board with a broken image. Answer two questions first, "what has to be deterministic and at what rate" and "is there a neural network in the loop," and the shortlist writes itself.

Companion reading: edge AI & robot compute, ROS 2, real-time control systems, robot sensors, machine vision, and how to choose a machine vision camera.

Table of contents

1. Key takeaways
2. Start with the buyer segment and the workload
3. The five compute tiers and where each wins
4. The real-time split and the MCU-plus-SBC pairing
5. Reading AI throughput without the TOPS trap
6. I/O, peripherals, and connectivity
7. Power, thermal, and mechanical
8. ROS 2 and the software ecosystem
9. Budget tiers and what each buys
10. The vendor and ecosystem landscape
11. Integration and total cost of ownership
12. A repeatable selection process
13. Frequently asked questions
14. Changelog

Start with the buyer segment and the workload

Before any board, place yourself in a buyer segment, because the segment sets what you optimize for. The same rover might use very different compute depending on whether it is a class project, a research platform, or a product headed for a thousand-unit run.

Hobby and learning. You optimize for cost, community, and how fast you can get a blinking result. You want the board with the most tutorials, the widest forum, and the cheapest entry, and you can tolerate a stale kernel or a rough driver because you are learning, not shipping. Arduino, ESP32, Raspberry Pi, and the Jetson Orin Nano dev kit dominate here for exactly that reason.

Research. You optimize for flexibility and software maturity. You want a platform where ROS 2 runs cleanly, where you can swap sensors freely, and where a new model or algorithm drops in without fighting the base image. Power and cost matter less than iteration speed. Jetson modules and x86 mini PCs running Ubuntu and ROS 2 are the research default.

Product development. You optimize for supply, longevity, certification, and cost at volume. You need a system-on-module with a multi-year availability guarantee, a documented board support package, a carrier board you control, and a path through EMC and safety certification. A dev kit is where you start and not what you ship. This is where system-on-modules and FPGAs earn their premium.

AI-heavy robots. You optimize for neural network throughput and memory. Humanoids, autonomous mobile robots doing 3D perception, and anything running a learned policy or a vision-language model need real accelerator silicon and enough memory bandwidth to feed it. The largest Jetson modules, Qualcomm robotics platforms, and dedicated NPU accelerators live here, and the edge AI and robot compute guide covers the model-side tradeoffs in depth.

Then quantify the workload on two axes. The first is determinism: what has to happen on a fixed schedule, at what rate, and what is the worst-case jitter you can tolerate. A brushless motor field-oriented control loop wants 10 to 40 kHz with microseconds of jitter; a safety stop wants a bounded worst case, not an average. The second is throughput: how much perception and planning you run, at what frame rate, and whether a neural network sits in the loop. A differential-drive robot following a line needs almost none; a robot doing real-time 3D object detection and path planning needs a lot.

Rule of thumb: If you cannot state your compute as two numbers, the fastest control loop in kHz and the heaviest perception task in frames per second with or without a neural network, you are not ready to pick a board. "Close a 20 kHz current loop with under 5 microseconds of jitter, and run object detection at 15 fps on a quantized model" points straight at an MCU paired with a mid Jetson. "Run some code" does not.

The five compute tiers and where each wins

Five durable tiers cover almost every robot compute purchase. Chips change every year; these categories do not. Find your workload here, then let it tell you which specs to weight.

Tier	What it is	Real-time	AI throughput	Typical power	Where it wins
Microcontroller	STM32, Teensy, ESP32, RP2350	Hard, deterministic	Tiny (TinyML)	mW to ~1 W	Motor loops, safety, sensor timing, small robots
Linux SBC	Raspberry Pi class, RK3588 boards	Soft (PREEMPT_RT helps)	Low to modest NPU	3 to 12 W	ROS 2 brains, mid robots, prototyping
AI SoC / module	Jetson Orin/Thor, Qualcomm QRB	Soft	High (tens to thousands of TOPS)	10 to 60+ W	Vision, learned policies, AI-heavy robots
x86	Mini PC, mini-ITX, embedded Ryzen	Soft (PREEMPT_RT / Xenomai)	Modest, or add a GPU/NPU	15 to 65+ W	Heavy compute, existing x86 software, AMRs
FPGA / SoC-FPGA	Zynq UltraScale+, Kria, PolarFire	Hard, parallel	Custom accelerators	5 to 25 W	Deterministic parallel I/O, custom sensor pipelines, low latency

A paragraph each on what actually decides the fit.

Microcontroller. A single-chip computer with no operating system or a tiny real-time one (FreeRTOS, Zephyr), running your code directly on the metal so timing is deterministic to the microsecond. It reads encoders, drives PWM, services interrupts, and closes control loops with no jitter from a scheduler. STM32 (a huge ARM Cortex-M family) is the industrial workhorse; Teensy 4.x (a 600 MHz Cortex-M7) is a favorite for fast hobby and research control; ESP32 adds Wi-Fi and Bluetooth for connected devices; the Raspberry Pi Pico (RP2040/RP2350) is a cheap dual-core option with programmable I/O. Choose it for anything that has to be deterministic. It cannot run Linux, ROS 2 natively (micro-ROS runs on it as a client), or a real perception stack, so on any robot bigger than a toy it is the deterministic half of a pair.

Linux single-board computer. A full computer on one board running Linux, giving you a real operating system, networking, USB, a package manager, and native ROS 2. The Raspberry Pi 5 (quad Cortex-A76) is the reference; Rockchip RK3588 boards (Radxa, Orange Pi, Khadas) add a 6 TOPS NPU and more I/O; BeagleBone and BeagleY-AI target industrial and education. Choose it for the perception-and-planning brain of a modest robot, for prototyping, and for teaching, where you want ROS 2 and Linux without the cost and power of an AI module. It gives you soft real-time only; pair it with an MCU for the fast loops.

AI SoC or module. A system-on-chip built around a GPU or neural processing unit for running neural networks at the edge, packaged as a module you drop onto a carrier board. NVIDIA Jetson is the category leader: the Orin Nano (around 40 TOPS, more in the Super refresh), Orin NX (around 100 TOPS), AGX Orin (up to 275 TOPS), and the newer Jetson Thor for humanoid-class workloads with far higher throughput. Qualcomm's robotics platforms (the QRB series) and NPU-heavy SoCs compete on power efficiency. Choose it when a neural network is in the loop: 3D object detection, semantic segmentation, visual SLAM at rate, learned control policies, or a vision-language model on the robot. It is the throughput half of the pair on an AI-heavy robot.

x86. A standard PC architecture in an embedded form factor: a mini PC, a mini-ITX board, or an embedded Ryzen or Intel Atom module. It runs the same software as your desktop, which matters when you already have x86 code, need heavy general-purpose compute, or want to drop in a discrete GPU or an NPU card over PCIe. Autonomous mobile robots and self-driving stacks lean on x86 for raw throughput and software compatibility. Choose it when the compute is heavy and general, or when your existing software is x86, and you can afford the power (15 to 65+ W). Real-time on x86 needs PREEMPT_RT or Xenomai and careful tuning.

FPGA and SoC-FPGA. A field-programmable gate array is reconfigurable logic that runs many operations truly in parallel with deterministic, nanosecond-scale timing. SoC-FPGAs (Xilinx/AMD Zynq UltraScale+, the Kria system-on-modules, Microchip PolarFire SoC) pair that fabric with ARM cores so you get hardware determinism and a Linux processor on one device. Choose it for custom sensor fusion pipelines, motor control across many axes at once, hard-real-time low-latency vision, and interfaces (camera MIPI, industrial buses) that need cycle-accurate timing. It is powerful and power-efficient for the right job and it carries the steepest learning curve on this list, so buy it when parallel determinism or a custom pipeline is the core need, not as a general brain.

Rule of thumb: Determinism at the bottom, throughput at the top. If the task is "do this exact thing on a fixed clock," it belongs on an MCU or FPGA. If the task is "figure out what to do from a lot of data," it belongs on Linux, an AI module, or x86. Most robots need both, which is the next section.

The real-time split and the MCU-plus-SBC pairing

The single most useful idea in robot compute is that hard real-time and heavy throughput want different silicon, so you split them. This is why the most common architecture on real robots is two computers, not one.

Why Linux is not hard real-time. A general-purpose Linux kernel schedules tasks for throughput and fairness, and it will occasionally let a background task delay yours by milliseconds. For perception and planning that is fine. For a current loop that must fire every 50 microseconds, a millisecond of jitter is a crashed control loop. The PREEMPT_RT patch (mainlined progressively over recent kernels) tightens Linux worst-case latency into the tens-of-microseconds range, which is enough for many joint-level loops but still soft compared with bare metal. The control-loop fundamentals are in real-time control systems.

The pairing. Put the deterministic work on a microcontroller and the heavy work on a Linux computer, and link them. The MCU reads encoders and IMUs, closes the fast motor loops, and enforces safety, all with no scheduler jitter. The Linux side runs the sensors, perception, mapping, planning, and the neural network, and sends the MCU setpoints (go this fast, hold this pose) over a link. The link is usually UART, SPI, CAN, or Ethernet, and micro-ROS lets the MCU speak ROS 2 to the Linux side as a first-class node, which is covered in the ROS 2 guide.

How to divide the line. Anything with a deadline under about a millisecond, or a safety consequence, goes on the MCU: current and velocity loops, encoder and IMU sampling, limit switches, emergency stop, watchdogs. Anything that reasons over data goes on the Linux side: camera and LiDAR processing, localization, path planning, behavior logic, learned policies. Position loops can sit on either side depending on rate; below a few hundred Hz they often live on Linux, above that on the MCU.

Task	Deadline	Put it on
Current / torque loop (FOC)	25 to 100 us	MCU or FPGA
Velocity loop	100 us to 1 ms	MCU
Safety stop, watchdog, limits	Bounded worst case	MCU
Encoder / IMU sampling	sub-ms	MCU
Position loop	1 to 10 ms	MCU or Linux
Localization / SLAM	10 to 100 ms	Linux SBC / AI module
Perception, object detection	30 to 100 ms	AI module / x86
Path and motion planning	10s to 100s of ms	Linux / x86
Behavior, task logic	100 ms+	Linux

War story: A student team ran their entire quadruped, motor loops and vision, on a single Raspberry Pi to save weight and cost. It walked on the bench. On uneven ground, the moment the camera pipeline spiked the CPU, the leg control loop missed its deadline, the gait went unstable, and the robot fell. They added a 20 dollar microcontroller to run the leg loops at a fixed 1 kHz and left the Pi to do vision and planning, and the instability vanished. The fix was to split the deterministic work off the shared, jittery scheduler onto its own chip.

Reading AI throughput without the TOPS trap

If a neural network sits in your robot's loop, you will be sold on TOPS, and TOPS is the most misleading number on the datasheet. Read it carefully or overpay for throughput you cannot use.

What TOPS means. Tera-operations per second is a peak count of multiply-and-add operations the accelerator can theoretically do, almost always quoted at INT8 precision, often with sparsity assumed. It is a ceiling under ideal conditions, and real models hit a fraction of it. Two modules both rated 100 TOPS can deliver very different real frame rates depending on memory bandwidth, the software stack, and how well your model quantizes.

What actually determines delivered throughput. Four things. The model itself: a model designed for the edge (a small YOLO, an efficient backbone) runs many times faster than a large one at the same TOPS rating. Memory bandwidth: accelerators starve if they cannot feed the compute, so the memory spec often matters more than the TOPS. Precision: INT8 gives the headline number, FP16 roughly halves it, and running a model unquantized in FP32 gives back most of the advantage. The software stack: NVIDIA's TensorRT, Qualcomm's SNPE, Hailo's SDK, and the quality of their model compilers decide how much of the peak you capture.

How to size it properly. Do not size on TOPS. Take your actual model, quantize it to INT8, run it through the vendor's runtime on the target module, and measure frames per second at the power budget you can supply. A benchmark on your model beats a spec sheet every time. If you are early and have no model yet, pick the tier by class of task: simple 2D detection at low rate runs on a 4 to 26 TOPS accelerator (Coral-class, Hailo-8, an RK3588 NPU), real-time 3D perception and multi-camera work wants a Jetson Orin NX or AGX class, and running a large vision-language or foundation model on the robot wants the top Jetson (Thor class) or a multi-accelerator x86 box. The model-side detail lives in edge AI and robot compute.

Workload	Rough throughput class	Typical silicon
Keyword spotting, simple sensors (TinyML)	under 1 TOPS	MCU with NPU, Coral micro
2D object detection, low rate	4 to 26 TOPS	Coral, Hailo-8, RK3588 NPU
Real-time 2D perception, single camera	20 to 70 TOPS	Jetson Orin Nano / NX
Multi-camera, 3D perception, VSLAM	70 to 275 TOPS	Jetson Orin NX / AGX
On-robot VLA / foundation models	1000+ TOPS	Jetson Thor, multi-GPU x86

Rule of thumb: Never buy compute on TOPS. Buy it on your model's measured frames per second at your real power budget, or if you have no model yet, on the class of perception task. A 100 TOPS module running an unquantized model on a starved memory bus can be slower than a 40 TOPS module running a properly quantized one.

I/O, peripherals, and connectivity

A robot brain is defined as much by what it can connect to as by how fast it computes. The wrong I/O turns a fast board into a paperweight for your build.

Low-level buses. Robots live on GPIO, PWM, I2C, SPI, UART, and CAN. Microcontrollers expose these natively and in quantity, which is a large part of why they own the low level. Single-board computers vary: a Raspberry Pi has GPIO, I2C, SPI, and UART but no native CAN or analog input without an add-on, and its real-time GPIO timing is poor. If you need many motor and sensor interfaces with tight timing, that is an argument for the MCU in the pair, or for an FPGA. CAN and CAN FD in particular are the backbone of multi-axis robots and vehicles, and native CAN support is worth checking for explicitly.

Camera and sensor interfaces. High-bandwidth sensors need the right port. MIPI CSI camera lanes give low-latency, high-resolution camera input and are standard on Jetson and Raspberry Pi; USB3 handles most machine-vision and depth cameras; GMSL (on higher Jetson carriers) supports long-cable automotive cameras. LiDAR and many depth cameras come over Ethernet or USB3. Confirm the board has the exact interface your sensors use, because a camera that needs MIPI on a board with only USB is a redesign. The sensor side is covered in robot sensors and the camera-specific choices in how to choose a machine vision camera.

Networking and wireless. Gigabit Ethernet (or multi-gig on higher-end boards) is the backbone for LiDAR, Ethernet cameras, and multi-computer robots. Wi-Fi and Bluetooth matter for teleoperation, monitoring, and configuration; ESP32 builds them in, most SBCs and modules need an add-on or an M.2 card. Time-Sensitive Networking and PTP time sync matter on robots that must timestamp sensors precisely across multiple computers.

Expansion. M.2 slots (for NVMe storage, Wi-Fi, or an AI accelerator), PCIe lanes (for a GPU or a frame grabber on x86 and higher modules), and USB ports decide how far you can grow the board. A board with no expansion is a board you will outgrow.

Rule of thumb: List every sensor and actuator and the exact bus each one needs, then check the board against the list before you look at compute. A brain that cannot connect to your LiDAR, your CAN bus, and your MIPI cameras is not a brain for your robot, however fast it benchmarks.

Power, thermal, and mechanical

On anything battery-powered these three constraints filter boards before performance is even relevant, and they are where the biggest-number buyer gets burned.

Power budget. A microcontroller draws milliwatts to about a watt. A Raspberry-Pi-class SBC pulls 5 to 12 W under load. An AI module ranges widely by its configurable power mode: a Jetson Orin Nano runs in a 7 to 25 W envelope, an Orin NX around 10 to 40 W, an AGX Orin from 15 to 60 W, and x86 mini PCs 15 to 65 W and up. On a battery robot that is your runtime, directly. A module that draws 40 W instead of 15 W cuts your endurance by more than half for the same battery, and the power budget is set alongside the robot power and batteries picture, not after it. Many AI modules let you cap the power mode, trading throughput for watts, and that knob is often how you make a module fit a robot at all.

Thermal. Every watt becomes heat that has to leave the board. Microcontrollers and low-power SBCs run passively. High-power SBCs and AI modules throttle or shut down without a heatsink and usually a fan, and a fan is a moving part, a noise source, a dust intake, and a failure point on a sealed or outdoor robot. In a dusty, hot, or sealed enclosure, passive cooling may be mandatory, which caps the compute you can run. Thermal design is a real constraint on the achievable TOPS, covered in thermal management and cooling.

Input voltage and power quality. Check the accepted input voltage against your battery. Many SBCs want a clean, regulated 5 V and brown out on a sagging battery rail; modules and industrial boards accept a wider range (for example 9 to 36 V) and tolerate the noise of a real robot power system. A board that needs a pristine 5 V on a robot whose motors dump noise onto the bus will reset at the worst moment.

Form factor and mechanical. Board size, mounting holes, connector placement, and the vibration and shock rating decide whether the board fits and survives. Industrial and automotive-grade boards carry wider temperature ranges (-40 to 85 C) and vibration ratings that a hobby board does not. A drone cares about grams; an outdoor robot cares about the sealed enclosure and the operating temperature; a factory AMR cares about vibration and the industrial temperature range.

Constraint	MCU	Linux SBC	AI module	x86
Power draw	mW to ~1 W	5 to 12 W	10 to 60+ W	15 to 65+ W
Cooling	Passive	Passive to small fan	Heatsink + fan usual	Heatsink + fan
Input voltage tolerance	Wide	Often needs clean 5 V	Wide on module carriers	Wide (DC-in) or ATX
Temp range (industrial variant)	-40 to 85 C	Varies	-25 to 80+ C	Varies

Safety rule: Size the power and thermal budget before the compute. An AI module that draws 40 W and needs a fan you cannot fit or cool in your enclosure is the wrong module no matter how it benchmarks. On a battery robot, the watts are your runtime; on a sealed robot, the heat is your ceiling. These are the constraints that quietly disqualify the board you wanted.

ROS 2 and the software ecosystem

The board is half the decision; the software support around it is the other half, and it decides how fast you actually ship. A faster board with a broken image loses to a slower board with a mature stack every time.

ROS 2 support. If you build in ROS 2, which most robotics teams now do, you want a board that runs a current Ubuntu LTS with the matching ROS 2 distribution cleanly. x86 and Jetson are the best-supported targets; Raspberry Pi and RK3588 boards run ROS 2 well on ARM Ubuntu; microcontrollers join the graph through micro-ROS as clients rather than running the full stack. Check that your ROS 2 distribution has binaries or a reliable build for the board's architecture and OS before you commit, because building the whole stack from source on an unsupported combination is a week you did not budget.

Board support package and kernel. This is the quiet killer of robot projects. Vendors ship a board support package (a Linux kernel plus drivers for the board's specific hardware), and its quality and how close it tracks the mainline kernel decide whether your sensor drivers, your PREEMPT_RT patch, and your security updates work. NVIDIA's JetPack, for example, has historically pinned Jetson to an older kernel than mainline, which can block a driver you need. A board whose vendor keeps the BSP current and close to mainline saves you months over one whose image is stale and forked. Ask what kernel the board ships, how far behind mainline it is, and how long the vendor commits to updating it.

Drivers and SDKs. Confirm there are working drivers for your exact cameras, LiDAR, IMU, and any accelerator, on this board and OS. A sensor with a driver only for x86, or only for an old kernel, is a sensor you cannot use on a mismatched board. For AI work, the accelerator's SDK and model compiler (TensorRT, SNPE, the Hailo or Coral toolchains) decide how much of the hardware you can actually use.

Community and documentation. For learning and prototyping, a large community is worth real performance. Raspberry Pi, Arduino, ESP32, and Jetson have enormous forums, tutorials, and third-party hardware; an obscure board with better specs but no community means you debug alone. For a product, vendor support, long-term documentation, and a support contract matter more than a forum.

Rule of thumb: Pick the board your software already supports. Before you buy, confirm your ROS 2 distribution runs on it, the vendor's kernel is close enough to mainline for your drivers, and there is a working driver for every sensor you plan to use. Time to a working robot is set by software maturity far more than by clock speed or TOPS.

Budget tiers and what each buys

Robot compute pricing steps by tier, and the board is only part of the system cost once you add a carrier, storage, cooling, and the sensors it drives. These bands are for the compute in 2026.

Under $50: microcontrollers and micro SBCs. ESP32 boards (5 to 15 dollars), Raspberry Pi Pico (4 to 8 dollars), STM32 Nucleo and Discovery boards (15 to 50 dollars), Teensy 4.x (around 30 dollars), Arduino boards. This tier buys deterministic low-level control, sensor and motor interfaces, and TinyML on the newest parts. It does not run Linux, ROS 2 natively, or a perception stack. It is the deterministic half of nearly every robot, whatever the top half costs.

$50 to $250: Linux SBCs and entry AI. Raspberry Pi 5 (60 to 90 dollars), Rockchip RK3588 boards (100 to 200 dollars with a 6 TOPS NPU), BeagleBone and BeagleY-AI, the Jetson Orin Nano dev kit (around 250 dollars after its price cut). This is the volume tier for a robot's Linux brain and for prototyping: ROS 2, Linux, modest perception, and light neural inference. Most hobby and much research compute lands here.

$250 to $1,000: mid AI modules and small x86. Jetson Orin NX modules (400 to 700 dollars) on a carrier, higher RK3588 boards with accelerators, x86 mini PCs (300 to 800 dollars), Kria robotics starter kits (around 350 dollars). This tier runs real-time multi-camera perception, visual SLAM, and mid-size neural networks, and it is where serious autonomous robots and research platforms sit.

$1,000 and up: high-end AI and x86 workstation-class. Jetson AGX Orin dev kits (around 2,000 dollars), Jetson Thor class modules and kits (several thousand dollars) for humanoid and foundation-model workloads, x86 boxes with discrete GPUs for autonomous vehicles and heavy multi-sensor stacks. This tier runs large learned policies, vision-language models on the robot, and dense 3D perception. The compute here is a serious line item next to the sensors.

Band	Get	Do not expect	Best for
< $50	MCU, micro SBC, TinyML	Linux, ROS 2 native, perception	Motor loops, safety, small robots, learning
$50 to $250	Linux SBC, entry AI (Orin Nano)	Heavy 3D perception, big models	ROS 2 brains, prototyping, hobby, education
$250 to $1,000	Orin NX, small x86, Kria FPGA	On-robot foundation models	AMRs, research, real-time multi-camera
$1,000+	AGX Orin, Jetson Thor, GPU x86	A cheap complete robot	Humanoids, AVs, on-robot VLA, dense 3D

Rule of thumb: Buy the tier your workload needs and stop. Over-buying an AGX-class module for a robot that runs one small detector wastes power, heat, and money every cycle; under-buying a Pi for a robot that needs real-time 3D perception strands the project. The compute price is the easy number; the sensors, the carrier, and the integration are the rest.

The vendor and ecosystem landscape

The market is concentrated by tier, and picking a vendor is picking an ecosystem of SDKs, board support, and community you live with for the life of the robot.

Microcontrollers. STMicroelectronics (STM32) is the industrial reference, an enormous family from tiny Cortex-M0 parts to fast M7 and M33 devices, with STM32CubeIDE and broad Arduino and PlatformIO support. PJRC's Teensy is a research and hobby favorite for its fast Cortex-M7 and Arduino compatibility. Espressif's ESP32 owns the connected-device niche with built-in Wi-Fi and Bluetooth. Raspberry Pi's RP2040 and RP2350 (the Pico line) are cheap, well-documented dual-core parts with unique programmable I/O. Nordic, NXP, Microchip, and Renesas round out the field. Zephyr and FreeRTOS are the common real-time operating systems across them.

Linux single-board computers. Raspberry Pi is the default for community, documentation, and software support, with the Pi 5 as the current mainstream brain. Rockchip RK3588 boards from Radxa, Orange Pi, Khadas, and others offer more compute and an NPU for the money, at the cost of a smaller community and rougher board support. BeagleBoard targets industrial and education with strong real-time I/O heritage (the PRU subsystem). For a product, weigh the community and BSP quality as heavily as the specs.

AI modules. NVIDIA Jetson dominates edge robot AI, from the Orin Nano through Orin NX and AGX Orin to the humanoid-class Thor, all sharing the CUDA, TensorRT, and Isaac software stack that is the deepest in robotics. That software moat is a large part of why Jetson wins even when a competitor's raw numbers look better. Qualcomm's robotics platforms (the RB and QRB series, QRB5165 class) compete on power efficiency and integrated connectivity. Dedicated accelerators (Hailo-8 and Hailo-10, Google Coral's Edge TPU, and various NPU cards) attach over M.2 or USB to add inference to a cheaper host.

x86. Intel (NUC-class mini PCs, Atom and Core embedded) and AMD (Ryzen Embedded) supply the x86 robot compute, from fanless mini PCs to mini-ITX boards that take a discrete GPU. ADLINK, AAEON, and other industrial vendors sell ruggedized x86 built for the vibration and temperature of a factory floor. This is the path when you need desktop-class software compatibility or a big discrete GPU on the robot.

FPGA. AMD (Xilinx) leads with the Zynq UltraScale+ SoC-FPGAs and the Kria system-on-modules (the K26, and the KR260 robotics starter kit) that package FPGA plus ARM cores with a friendlier software flow than raw FPGA design. Microchip's PolarFire SoC offers a low-power RISC-V plus FPGA option. Lattice serves the small, low-power end. FPGA carries the steepest learning curve here, so it is a choice you make for a specific determinism or custom-pipeline need.

How to choose among them. For learning, weight community and tutorials: Arduino, ESP32, Raspberry Pi, and the Jetson Orin Nano. For research, weight ROS 2 and software maturity: Jetson and x86 on Ubuntu. For a product, weight supply longevity, BSP quality, and certification path: a system-on-module (Jetson, Kria, or an SBC vendor's module) on a carrier you control, with a written multi-year availability commitment. The single best predictor of a smooth build is how well the vendor's software and board support fit the sensors and the framework you already use.

Integration and total cost of ownership

The board price is the visible cost and the smaller one. The system around it, and the years it runs, are where the real money and risk sit.

Dev kit versus module. A development kit is a board built for bring-up: every connector broken out, generous cooling, a friendly price. It is where you start. A product ships a system-on-module (the compute on a small board with a standard connector) mounted on a carrier board you design for your exact connectors, form factor, and power. Building a robot around a dev kit and then trying to productize it means a redesign; if you are heading to volume, prototype on the kit and plan for the module and a custom carrier from the start. Modules also carry the multi-year supply commitments that dev kits do not.

Supply and longevity. A hobby board can vanish or revise without notice. A product needs a compute vendor who guarantees availability for the years your robot will sell (industrial and automotive modules commit to 10 or 15 year availability), so you are not forced into an unplanned redesign when the board goes end of life. This is a real reason product teams pay the premium for industrial system-on-modules over consumer boards.

Storage, cooling, and the carrier. Budget the full compute system: the module, storage (a microSD card is fine for prototyping and a liability in production, where eMMC or NVMe is the right call), the heatsink and fan, the carrier board, and the connectors and cabling. These add meaningfully to the module price and to the engineering time.

Certification. A product that ships has to pass EMC (emissions and immunity), and depending on market and application, safety and radio certifications. The compute and its cabling are a major EMC contributor, and a board that was never designed with EMC in mind can cost weeks of shielding and filtering to pass. Factor certification into both the schedule and the choice of board.

Software maintenance. The board runs for years, and its Linux needs security updates, its drivers need maintenance, and its kernel eventually needs a jump. A vendor with a long, well-maintained board support package saves you from carrying that burden alone. This ongoing software cost is easy to ignore at purchase and expensive to discover later.

Rule of thumb: Budget the compute system and its lifetime, not the board. Price the module, carrier, storage, cooling, and certification, and weigh the vendor's supply commitment and software maintenance, because a 250 dollar board that goes end of life in a year or ships a stale kernel can cost far more than a pricier module with a decade of support behind it.

A repeatable selection process

Put it together into a checklist you can run for any purchase, from a class project to a product.

1. Name your buyer segment (hobby, research, product, AI-heavy), because it sets what you optimize for: cost and community, flexibility, supply and longevity, or throughput.
2. State the workload as two numbers: the fastest control loop in kHz with its jitter tolerance, and the heaviest perception task in fps, with or without a neural network. If you cannot, stop here until you can.
3. Split deterministic from throughput. Put sub-millisecond and safety-critical work on an MCU (or FPGA); put perception, planning, and learned models on Linux, an AI module, or x86. Default to the MCU-plus-SBC pairing.
4. Pick the throughput tier from the perception task: Linux SBC for modest work, an AI module sized by measured fps (not TOPS) if a network is in the loop, x86 for heavy general compute, FPGA for custom parallel determinism.
5. List every sensor and actuator and its bus, then confirm the board has the exact interfaces (CAN, MIPI, USB3, Ethernet, GPIO) before comparing compute.
6. Set the power and thermal budget from the battery and enclosure, and confirm the board fits it, capping the AI module's power mode if that is how it fits.
7. Confirm the software first-class: your ROS 2 distribution runs on the board, the kernel is close enough to mainline for your drivers, and every sensor has a working driver on this board and OS.
8. Decide dev kit versus module. Prototype on a kit; if you are heading to volume, plan the system-on-module and custom carrier and confirm the multi-year supply commitment.
9. Build the real budget: module, carrier, storage, cooling, certification, and software maintenance over the robot's life, not the board sticker.
10. Validate on your real workload. Run your actual control loop and your actual (quantized) model on the target board and measure jitter and fps before you commit the design.

Run this in order and the shortlist narrows to one MCU and one Linux or AI board you can build on with confidence. Skip the workload and the software steps and you will do what most first-time buyers do, which is buy the biggest TOPS number and discover the power, the thermal, and the board support package on the bench.

Frequently asked questions

Do I need a microcontroller and a single-board computer, or can one board do everything? For anything beyond a toy, the two-board split is the standard answer, because hard real-time motor and safety loops and heavy perception want different silicon and a shared Linux scheduler will let the perception work delay your control loop. A microcontroller (STM32, Teensy, ESP32) holds the fast deterministic loops with no jitter, and a Linux single-board computer or AI module runs the perception and planning. They link over serial, CAN, or Ethernet, and micro-ROS lets the MCU speak ROS 2. A single Linux board can run a slow, non-safety-critical robot, but the moment timing matters, add the MCU.

Raspberry Pi or Jetson for my robot? Pick by whether a neural network is in the loop. A Raspberry Pi 5 is the right brain for ROS 2, modest perception, and prototyping at low cost and power. A Jetson (Orin Nano and up) is what you buy when you run real-time object detection, visual SLAM at rate, or a learned policy, because it has a GPU and NPU the Pi lacks. The Pi wins on cost, power, and community; the Jetson wins on AI throughput and its CUDA and TensorRT software stack. Many robots use a Pi-class board for light work and step up to a Jetson only when the perception load demands it.

How much AI performance (TOPS) do I actually need? Size it on your model, not on the TOPS number. Quantize your actual network to INT8, run it through the vendor's runtime on the target module, and measure frames per second at the power you can supply. If you have no model yet, size by task class: simple 2D detection at low rate runs on 4 to 26 TOPS accelerators, real-time single-camera perception on 20 to 70 TOPS (Orin Nano or NX), multi-camera and 3D perception on 70 to 275 TOPS (Orin NX or AGX), and on-robot foundation or vision-language models on 1000+ TOPS (Jetson Thor class). Memory bandwidth and the software stack often matter more than the headline TOPS.

Is a Raspberry Pi good enough for real-time motor control? Not by itself for fast loops. A general Linux kernel on a Pi gives soft real-time with occasional millisecond-scale jitter, which is fine for position loops at a few hundred Hz but crashes a current loop that needs microsecond timing. The PREEMPT_RT patch tightens worst-case latency into the tens of microseconds, which covers many joint loops, but for field-oriented current control at 10 to 40 kHz you want a microcontroller or an FPGA doing that loop, with the Pi sending setpoints. This is exactly the case for the MCU-plus-SBC pairing.

Do I need an FPGA? Only for specific needs, and it carries the steepest learning curve here. Buy an FPGA or SoC-FPGA (Zynq UltraScale+, Kria, PolarFire) when you need true hardware parallelism with nanosecond determinism: controlling many motor axes at once, custom sensor fusion or vision pipelines with fixed low latency, or interfaces that need cycle-accurate timing. For a general robot brain running ROS 2 and perception, an MCU plus a Linux or AI board is simpler, cheaper, and faster to build on. Reach for FPGA when parallel determinism or a custom pipeline is the core requirement.

What is the difference between a dev kit and a module, and which do I buy? A dev kit is a board built for bring-up, with every connector broken out and generous cooling, and it is where you start. A system-on-module is the compute on a small board with a standard connector, meant to mount on a carrier you design for your product's form factor, connectors, and power. Buy the dev kit to prototype. If you are building a product for volume, plan from the start to move to the module on a custom carrier, and confirm the vendor's multi-year supply commitment, because building around a dev kit and productizing later means a redesign.

Will ROS 2 run on my board? On x86 and Jetson, yes, cleanly, on the matching Ubuntu LTS. On Raspberry Pi and RK3588 boards, yes, on ARM Ubuntu, with occasional rough edges. On a microcontroller, not the full stack; micro-ROS runs on it as a client node that joins the ROS 2 graph. Before you buy, confirm your specific ROS 2 distribution has binaries or a reliable build for the board's architecture and OS, and check that the vendor's kernel is current enough for your drivers, because an unsupported combination can cost a week of building from source. See the ROS 2 guide.

How much should I budget for robot compute? The compute itself ranges from under 50 dollars for a microcontroller, to 50 to 250 dollars for a Linux SBC or entry AI board (Raspberry Pi 5, Jetson Orin Nano dev kit), to 250 to 1,000 dollars for a mid AI module or small x86, to over 1,000 dollars for high-end AI (AGX Orin, Jetson Thor) and GPU-equipped x86. Then budget the system around it: carrier board, storage, cooling, cabling, certification, and software maintenance over the robot's life. On a product, the supply commitment and board support package are worth paying a premium for, because a cheaper board that goes end of life forces an unplanned redesign.

Why does software support matter more than raw performance? Because time to a working robot is set by how cleanly the software runs, not by clock speed or TOPS. A board with a mature ROS 2 stack, a kernel close to mainline, and working drivers for your exact cameras and LiDAR ships months before a faster board whose vendor image is stale and whose drivers fight your kernel. The board support package is the quiet killer of robot projects. Ask what kernel the board ships, how far behind mainline it is, how long the vendor commits to updates, and whether every sensor you plan to use has a working driver on it before you buy.