Get started
Your first pilot
Start with a real failure your team already spends time investigating.
Choose a useful incident
A good first case is a repeatable ROS 2 failure with logs or a recording: an intermittent stop, a node crash, delayed sensor data or a controller that stops responding. Choose a problem where your team can recognise a useful diagnosis and repeat the scenario after a change.
What to bring
| Input | Why it helps |
|---|---|
| The failing recording or logs | Shows what actually happened. Include the lead-up to the failure, not only the final error. |
| A short symptom description | Keeps the investigation focused on the problem your operator observed. |
| A healthy run, if available | Separates a persistent fault from the robot's normal behaviour. Keep the task and channels comparable. |
| The matching source and configuration | Helps locate the mechanism and propose a specific change. Tell us if the checkout differs from what ran on the robot. |
| Robot, ROS and deployment details | Makes the result understandable in the context of your hardware and software versions. |
We can start with files on your laptop. A continuous live connection is useful later, when your team wants to capture intermittent incidents and check subsequent runs. Agree the data settings with your team before connecting; Data and model processing explains the choices.
What you get back
- A finding with the relevant channels, log lines and timing.
- A proposed explanation tied to the evidence, with uncertainty or missing inputs stated.
- A repair proposal when the cause is supported, or a concrete next check when it is not.
- A follow-up comparison after your team applies the change and repeats the scenario.
Agree what success means
Before starting, agree the symptom to resolve, the conditions needed to reproduce it and who reviews the result. Useful pilot outcomes are a supported cause, a check that narrows the investigation, or a repair that holds on the repeated scenario. Track investigation time and remaining failures alongside the verdict.
TrialONE proposes and measures; your team applies code, configuration and hardware changes. It does not automatically move the robot or begin a recording. A difficult case may end with a missing measurement rather than a confident repair.
Arrange the pilot
Request Pilot Access or contact us with your robot type, observed symptom and the data you can use. We will agree the incident, processing setup and follow-up with your team. Public validation examples are on Proofs.
Something missing or wrong here? Tell us.