TOPS is meaningful only with operation, precision, sparsity and utilization context.
RCI 008 · Compute field guide
Robot compute beyond TOPS.
A selection model for precision, sparsity, memory, sensor I/O, latency, power, real-time behavior and software lifecycle.
Memory movement, camera I/O and software support can limit a robot before theoretical compute does.
Module power modes are not total computer or robot power.
A TOPS number describes a narrow arithmetic ceiling
Tera operations per second is not a universal robot-performance unit. The number may assume INT8 rather than FP16, structured sparsity rather than dense weights, a specific accelerator, ideal scheduling and no data-transfer bottleneck. Two vendors may count operations differently or publish architecture descriptions instead of one headline figure.
NVIDIA’s 275 TOPS figure for Jetson AGX Orin 64GB is explicitly an INT8 sparse claim. The Qualcomm RB5 brief describes its Hexagon DSP, vector extensions and tensor accelerator without providing a directly comparable TOPS number in the selected document. Raspberry Pi Compute Module 5 does not contain a dedicated NPU headline at all. Ranking those three records in a single TOPS column would confuse document choices with hardware capability.
Measure the end-to-end perception and control pipeline
A robot workload includes sensor capture, decoding, image signal processing, pre-processing, inference, post-processing, mapping, planning, communication and logging. Latency and jitter across the full path matter more than isolated accelerator throughput.
The benchmark should specify model, framework, precision, batch size, input resolution, number of streams, memory placement, clocks, thermal state and power mode. Report both throughput and latency distributions; an average can hide control-disrupting tail latency.
Camera lanes on a module are not cameras on a robot
A system-on-module can advertise MIPI lanes or virtual channels while the carrier exposes fewer connectors, routes them differently or requires a specific deserializer. GMSL2 cameras need serializer/deserializer hardware, power-over-coax decisions, device-tree configuration and compatible drivers. USB cameras share host-controller bandwidth and may introduce different timestamp behavior.
The record must therefore connect module capability, carrier design, sensor interface, driver version and verified combination. RCI treats each as a separate claim.
Software and production lifecycle are selection fields
Robot computers live longer than many development environments. Kernel, distribution, accelerator runtime, security updates and hardware availability determine whether an apparently fast module can be maintained. A product brief’s launch software is not proof that the same release remains supported today.
Raspberry Pi publishes a production commitment for Compute Module 5 through at least January 2036. NVIDIA publishes Jetson lifecycle information and versioned JetPack support. Qualcomm’s RB5 brief names an initial software baseline that should be rechecked before a new design-in. These are different evidence types and should remain dated.
RCI operating rule
The right comparison output is a workload-and-integration matrix, not a universal compute score.
Selected primary sources
These links support the examples and product claims used in this guide. They do not imply that every general engineering statement is a quotation from one source.
- NVIDIA Jetson modules lineup ↗
- Raspberry Pi Compute Module 5 specifications ↗
- Qualcomm Robotics RB5 Product Brief ↗