Method
How we measure
Every number on this site was produced the same way. This page is the way, so a partner's engineer can check it before the first call.
- 01
Digital twin first
Where a robot is involved, the workcell is built in Isaac Sim from the manufacturer's URDF and described in OpenUSD, so the simulated bench matches the physical one. Policies are evaluated there first, because every run can be repeated.
- 02
Then the target hardware
Inference runs on the Jetson that will ship, with the exact runtime, threading, and provider settings that will ship. Desktop GPU numbers are never quoted as edge numbers.
- 03
Repeat before reporting
A result is reported after it has held across repeated sessions. The IDS power gap was confirmed across three sessions before it went on a page.
- 04
Label what is not measured
Every result carries a status: measured, implemented but not measured, or unresolved. A partner should never have to guess which one they are looking at.
What gets logged
The measurements behind every result
Latency alone says very little about an edge device. The lab logs the things that decide whether a system can be deployed.
- Inference latencyp50 and p95 per inference on the target deviceTensorRT, ONNX Runtime
- Board powerSustained draw under the real workload, compared across runtime configurationsJetson power rails
- Junction temperaturePeak and sustained, over the length of the runJetson thermal sensors
- Task outcomePer-run success or failure, plus placement error where the task has a targetIsaac Sim, ROS 2
- Pipeline overheadFrames per second with a mock model, so the pipeline's cost is separated from the model'sCustom telemetry
- Runtime configurationThreading, batching, and execution provider, logged with every resultConfig capture
Instruments
What the lab measures with
The report
What a partner receives
The same structure whether the engagement is a fixed-scope evaluation or a pilot.
- The setup: hardware, software versions, runtime configuration, and the workload, so the run can be reproduced.
- The numbers: every measurement above, dated, with charts, as p50 and p95 rather than averages.
- What passed, what failed, and what is unmeasured, each labeled as such.
- Raw logs and the exact configuration files used.
- Open items: anything unexplained is listed as unresolved rather than left out.
Rules
Three rules that do not bend
No invented numbers. If it was not measured in the lab, on the stated hardware, on the stated date, it is not on the site.
No desktop numbers presented as edge numbers. Development happens on a workstation. Results come from the target.
No hidden failures. The worst single event in the IDS runs is still unexplained, and the project page says so. That is the standard.
Start here
See it applied
Two build logs walk through measurements produced exactly this way.