A diagnosis should give your team something it can check. We test against real robot recordings and reproducible software failures, with evidence you can inspect.
Each reference case pairs a failing regression with the original maintainer's change. This library gives us a concrete basis for evaluating diagnoses and candidate repairs.
Sources and measurement methodsTested on real robot data
A driver can publish a value that looks plausible but conflicts with its message definition or physical meaning. TrialONE checks both, so a unit or driver error does not have to wait for a visible failure.
Battery current
Positive current reported while the battery is marked as discharging.
Battery voltage
Zero volts reported for a battery marked as present on a powered aircraft.
Magnetic field
Published values are inconsistent with the declared Tesla unit.
The same 3 data-consistency violations found in every recording.
49,181 IMU orientations correctly marked as unmeasured were left alone. Correctly declared missing data stays quiet.
Measured with TrialONE's ROS message-consistency checks on the original ALFA flight recordings. Dataset source.
Source code and regression checks
A convincing explanation is only the start. Our reference library tests the faulty source and the maintainer's repair under the same conditions. The failure and the passing result must both repeat.
Faulty source
Failure reproduced
The regression check exposes the original problem.
Upstream repair
Regression passes
The same check passes with the maintainer's change.
600 control runs across 150 cases and 38 projects.
Inspect the reference casesInside the reference library
A frozen replay, a stale callback and a middleware crash can each point away from the real cause. These reproduced upstream cases show the kind of reasoning a useful diagnosis needs.
rosbag2 · Reference case
Two recordings are played together. A short recording cannot fill its share of the message queue, and playback never starts.
The underlying cause
The player's readiness check waits for more messages than the short recording contains.
A useful fix has to handle recordings of different lengths, not just restart the player.
Read the upstream fixrclcpp · Reference case
One callback deletes an object. Another subscription stays alive and can still call into that destroyed object.
The underlying cause
The executor's wait set keeps the subscription alive longer than the object it accesses.
Checking one executor is insufficient. The repair also has to work for the static executor.
Read the upstream fixCyclone DDS · Reference case
Middleware crashes while matching a built-in writer, even though the endpoint is valid.
The underlying cause
The matching code assumes that every writer has a participant. A built-in writer can be a valid exception.
The crash location is only a clue. The cause lies in an assumption shared across several functions.
Read the upstream fixYour team's pilot
The next useful proof is on your robot. Start with one incident and agree on what a good diagnosis and a successful follow-up should look like.
Start with a recording, the symptom you observed and, where available, a healthy run and the matching source code.
Follow the measurements behind the finding, review the proposed cause and decide which check or change is justified.
Compare the affected signals after the change. Agree on a repeatable success criterion before calling the incident resolved.
