The Console.
Ask a physical question. Get an experiment, not an opinion.
The Console is meant to turn an ordinary question into a small, explicit test that the bench can safely perform. The important part is what happens after the sentence: every action becomes visible before it touches the board.
Interface storyConcept illustration used to explain the proposed workflow.
Today that question can produce twenty plausible explanations. We want it to produce one good test.
Before the run, the Console reads what it already knows: which board is in the fixture, which software image is installed, where the power probes are connected, which camera is looking at the board, and the safe temperature and current limits.
It then proposes a test in plain language and also shows the exact machine-readable version underneath. A person can approve it, edit it, or reject the reasoning.
Watch without changing the system.
Question: Is the restart more consistent with a power problem, overheating, or a software-only crash?
Plan: begin cold, record one minute of idle behaviour, start the heavy workload, and watch input power, two board power rails, the boot log, network link, system workload and the thermal camera together. End at restart, limit, manual stop, or the agreed maximum time.
Illustrative teaching data, not an RK3588 measurement.
Evidence narrows the story.
Suppose the first run sees a sharp change on the 5 V rail immediately before a brownout message, while the board is warm but still below its temperature limit. That does not prove which component is bad.
It does make a purely software crash less convincing and tells us what is missing: we still do not know whether the disturbance begins before or after the regulator.
The useful response is therefore not “replace the regulator.”
Next test: add one measurement on the regulator input, repeat the same workload, and run a second pass at a slightly lower accelerator power setting. Change nothing else.
Natural language on top. Explicit experiment underneath.
The friendly interface matters because people should be able to describe a physical question without learning a test framework first. But the actual experiment should become a structured object before it runs.
That object names the board, fixture, instruments, measurements, limits, repetitions, stop conditions and analysis. The engineer can inspect it. The safety controller can reject it. Another lab can reproduce it.
This separation is one of the central design rules of the project: conversation may propose; explicit tools execute.
Readable first. Raw when you need it.
Learn
“We are watching this rail because a drop too short for a normal meter can still reset the board.” The explanation sits beside the real control.
Basic
Question, limits, selected instruments, run/abort, synchronized evidence, next proposed experiment.
Advanced
Sampling rates, triggers, raw instrument commands, calibration, alignment uncertainty, source data, analysis code and provenance.