Get started
How it works
Measurements identify departures. The investigation connects the evidence. A new run checks the result.
Detection against the machine's own normal
TrialONE combines documented protocol and log checks with numerical comparisons. Depending on the input, it checks signals against the rest of the recording, earlier behaviour of the same machine or a healthy recording supplied with --healthy. A detected departure is evidence to investigate; it does not by itself establish the physical cause.
Repeated operations make numerical comparisons more useful. For example, one robot arm cycle can be compared with other cycles under similar conditions. Detection does not require a model, and its result can be reproduced with the same inputs, configuration and software version.
Explanation: what the signal is, and why it moved
The model investigation uses tools to read available measurements, logs, source files and configuration. On a live ROS 2 robot, it can also inspect the graph, QoS, parameters and process state. It looks for a causal connection rather than returning a list of every possible cause.
For recording explanations, proposed mechanisms can include predictions that are checked against the measured data. Failed predictions are reported with the evidence that refuted them. A live proposal still needs follow-up evidence; a plausible explanation alone is not a verified repair.
The explanation never changes what was detected. With --no-explain you get the deterministic half on its own.
Three zones per finding
| Zone | When | What you get |
|---|---|---|
| FAULT | The finding has supporting evidence such as a decoded failure, missing data, a calibrated reference or a checked mechanism. | An actionable finding with the proposed repair or next check. |
| LOOK | There is a departure, but the evidence is not strong enough to establish a fault. | An observation to review, with the measurement needed next. |
| clear | The available checks found nothing to report. | No finding. This does not certify every part of the robot as healthy. |
An explanation can raise a zone, never lower it. Every report says how many findings stayed undecided, out of how many.
Routing: software or hardware
The report proposes who should act: a software engineer or coding agent for code and configuration, a technician for a physical intervention, or a policy engineer when recorded commands explain the behaviour. Files and lines are included where they can be supported. Missing inputs remain visible in the report.
Proof: the next recording decides
A person or coding agent reports a change. trialone verify compares a new recording with the earlier diagnosis and reports what disappeared, remained or appeared. A lower peak is not enough to pass when the same finding remains. See Checking a repair.
What it does not do yet
- The live value-change trigger needs several channels moving together. An isolated value change can be missed; separate checks cover missing topics, timing and documented protocol failures.
- Explanations on the live path are leads, not verified answers. Predictions are checked against recordings, not against a running stream.
- A fault present in every operation of a recording is invisible without a healthy reference. Pass
--healthy. - Live camera frames can provide visual context to an investigation. They are not a general image fault detector. Point cloud geometry is not analysed.
- File and line evidence depends on the supplied source version. A checkout on your laptop does not independently prove what ran on the robot.
- A passing follow-up covers the recorded scenario and checks used. It does not certify safety or prove that an intermittent fault can never recur.
Something missing or wrong here? Tell us.