The answer is to qualify the computer under the complete robot workload until it reaches thermal equilibrium. Run sensor ingest, preprocessing, inference, postprocessing and control publication together, then align P50, P95 and P99 latency with temperature, power, CPU/GPU/memory clocks, memory use and dropped frames on one timeline.
For Jetson, NVIDIA's Platform Power and Performance documentation provides the release-specific power and thermal controls. Keep this test separate from choosing a CPU, GPU or NPU architecture, planning edge AI for robots, selecting robot sensors and solving robot joint thermal management.
TOPS describes a compute ceiling, not a sustained robot deadline
TOPS is tied to an operation type and numerical precision. It does not automatically include camera decode, copies, CPU preprocessing, memory contention, engine execution, postprocessing, planning or ROS 2 transport. Two systems with the same headline TOPS can deliver different camera-to-command latency.
A short run in a cool open bench also misses the clock state after a fan, heat sink and sealed enclosure absorb heat. Procurement should ask whether the system still meets the control deadline late in a patrol, not whether it posted one peak result at startup.
| Metric | What it reveals | What it cannot prove alone |
|---|---|---|
| TOPS | Compute ceiling at a stated precision | End-to-end robot latency |
| Cold mean latency | Central performance before heat soak | Hot tail behavior |
| P95 and P99 | Slow-frame deadline exposure | Safety of the resulting action |
| Clocks, temperature, power | When and why derating begins | Correct sensor and control integration |
Pin the board, software release, power mode and cooling assembly
The test header should record module SKU, carrier, Jetson Linux and JetPack, CUDA, TensorRT, kernel, model hash, precision, power mode, fan profile, heat sink and enclosure. The Jetson Thor r39.2 feature table illustrates why platform and release matter; interfaces and supported behavior cannot be generalized from a different family.
On a supported Orin release, for example, `sudo nvpmodel -q` reports the current mode, while `/etc/nvpmodel.conf` and the matching documentation define supported IDs and frequency ceilings. Results obtained after forcing maximum clocks should be kept separate from results in the deployable robot power mode.
Replay the real path from sensors to the action publisher
Enable the production camera count, resolution and frame rate; LiDAR parsing; timestamp synchronization; preprocessing; detector or VLA; postprocessing; mapping; logging; networking; and control messages. Repeating only a serialized engine removes the CPU, memory and I/O contention that often causes field drops.
NVIDIA's Jetson Test Plan and Validation guide checks CPU, GPU and EMC frequency under load and uses `tegrastats` to observe frequency, temperature, power and memory. Add application timestamps at every boundary so a system event can be tied to the stage that missed its deadline.
| Stage | Production load to retain | Telemetry |
|---|---|---|
| Sensor ingest | Real cameras, LiDAR and IMU | Rate, drops and timestamps |
| Preprocessing | Resize, normalization and copies | CPU/GPU time and transfer |
| Inference | Production engine and precision | P50, P95, P99 and throughput |
| Postprocess and control | Filters, planning and publish | End-to-end latency and misses |
| System services | Logs, network and storage | Temperature, power, clocks and memory |

Thermal soak must include the worst credible ambient and enclosure
Do not set the duration to an arbitrary ten minutes. Run until temperatures and clocks settle, or through the complete mission duty cycle, whichever is longer. Include maximum ambient, solar load if relevant, a dirty filter, restricted inlet, battery-voltage range and nearby heat sources.
The NVIDIA thermal-alert validation procedure raises temperature with long-running concurrent loads and observes the trip point and throttle alert. A product test should additionally capture clock reduction, P99 increase, dropped frames and recovery time before and after the event.
TensorRT results need warm-up, concurrency and transfer boundaries
When following the TensorRT 11.2.1 benchmarking guide, pin the engine, input shapes, batch, streams, precision, warm-up and measurement window. An engine-only number that excludes host-device transfers must not be presented as application end-to-end latency.
High throughput can coexist with a P99 that violates a control period. Compare the first five minutes with the final thermally stable interval, plot the latency distribution against clock and temperature, and report the sustained-performance loss rather than one aggregate average.

Pass on mission SLA, not on the absence of any clock reduction
Thermal throttling is a hardware response that lowers clocks to remain within thermal limits. Application rate limiting is a software policy that intentionally lowers request frequency. Distinguishing them in logs tells the team whether to improve cooling, optimize the pipeline or change the task cadence.
The acceptance table should include hot P95 and P99, deadline-miss rate, sensor-drop rate, minimum clocks, maximum temperature, mean and peak power, memory headroom and recovery or reboot events. NVIDIA documentation supports the Jetson example; other platforms need equivalent temperature, power, clock and memory telemetry to be compared fairly.
Frequently asked questions
Does higher TOPS always make a robot computer faster?
No. Precision, memory bandwidth, preprocessing, sensor I/O, power mode and thermal derating all affect end-to-end latency. Measure sustained P95 and P99 on the complete pipeline.
How long should a robot thermal-soak test run?
There is no universal duration. Run until temperature and clocks reach a stable state or until the full mission duty cycle is reproduced, whichever takes longer.
Is tegrastats enough to validate the workload?
No. It provides platform telemetry, but application timestamps are still required to measure sensor-to-action latency, frame drops and deadline misses.
Official sources checked
- NVIDIA Jetson Thor Series feature table r39.2
- NVIDIA Jetson Platform Power and Performance r36.4.3
- NVIDIA Jetson Test Plan and Validation r36.4
- NVIDIA TensorRT 11.2.1 Benchmarking Guide
2026-08-07