Robot compute selection should begin with the real task. This article provides an evaluation checklist rather than specific product specifications or benchmark results.
1. What are the task boundaries?
Describe the actions, sensor inputs, and operating environment. Identify where perception, planning, and control run, and which capabilities must remain on the robot when connectivity is lost.
2. How is the latency budget allocated?
Put sensor acquisition, preprocessing, inference, postprocessing, and actuation into one budget. Measure end-to-end latency and variation; distinguish model throughput from closed-loop response time.
3. Are memory and data movement constraints?
Record the memory needs of weights, activations, intermediate tensors, and multiple camera streams. Evaluate the target model at a defined precision and input size. Save model and runtime versions for reproducibility.
4. Can power and thermal design support sustained operation?
Define acceptable power, cooling conditions, and task duration. Compare steady-state performance, record throttling, and separate chip, module, and full-system measurement boundaries.
5. Can the software ecosystem support the project lifecycle?
Check model conversion, operator support, debugging tools, operating systems, and sensor drivers. Verify SDK updates, documentation, and supply lifecycle. Run a minimal real task early.
Turn questions into an experiment log
For each test, save the model and version, input specification, precision, runtime, power mode, ambient temperature, measurement method, and raw results. A documented experiment is more useful for team decisions than a leaderboard without test conditions.
The SoC Database uses consistent fields to track sources and verification status. Product-specific conclusions should be based on the corresponding official documentation and reproducible experiments.