Inspiration
TrustLoop: Building Trustworthy Autonomous Robots
Inspiration
Imagine asking a robot to pick up an object and place it inside a container. The robot moves its arm, closes its gripper, and completes its programmed sequence. But what if it never actually grasped the object? What if it dropped the object along the way or placed it incorrectly?
In robotics, executing an action is not the same as achieving the intended outcome. A robot that reports success without checking what happened can be unreliable, especially in environments where physical actions are uncertain.
This inspired us to build TrustLoop, a robotics framework designed around a simple principle: a robot should verify what it has accomplished, not merely what it has attempted.
Our demonstration task is straightforward: pick up a red cube and place it inside a blue container. Behind this simple task lies a broader challenge in autonomous robotics: how can we detect failures, recover when possible, and recognise when an attempted recovery has not worked?
What We Built
TrustLoop combines task execution, independent outcome verification, bounded recovery, and AI-assisted decision-making in a simulated robotic manipulation environment built with MuJoCo.
The framework evaluates three operating modes:
- Baseline: Executes the task without the additional verification-and-recovery loop.
- Verify Only: Checks whether the intended outcome was achieved and detects unsuccessful attempts.
- Verify + Recover: Uses verification results to trigger bounded recovery attempts and checks the outcome again.
We also integrated NVIDIA Nemotron through Nebius Token Factory as an AI advisor. The advisor receives task evidence and can recommend an adjustment when a failure is detected. Its recommendation is used within the recovery framework rather than being treated as unquestionable control output.
Our Octo integration follows a separate shadow-inference pipeline. It exports observations for inference and provides a way to associate predictions with task outcomes. Octo predictions are not executed by the robot controller in the current implementation.
How We Built It
1. Simulated Robotic Manipulation
We used MuJoCo to simulate the manipulation task. The robot must grasp a red cube and place it inside a blue container.
Rather than evaluating only a normal execution, we introduced fault conditions to examine how the system behaves when the task does not proceed as expected.
2. Independent Verification
After an attempted action, TrustLoop checks whether the intended task outcome was achieved.
This creates an important distinction between an action sequence finishing and the task actually succeeding. When verification detects failure, the system can avoid reporting a false success.
3. Bounded Recovery
When the task fails, the recovery framework can attempt to correct the problem. Recovery is bounded: if the task remains unsuccessful after the permitted attempts, TrustLoop reports the failure instead of claiming success.
4. AI-Assisted Recovery with NVIDIA Nemotron
We integrated NVIDIA Nemotron through Nebius Token Factory to provide evidence-informed recovery recommendations.
During integration, we validated API authentication, confirmed model availability, and successfully obtained a live response from nvidia/Nemotron-3_5-Lightning. In our connectivity test, the advisor recommended adjusting the approach after receiving evidence indicating a lack of gripper contact.
This demonstrated that the live model integration was functioning. We separately evaluated the broader recovery pipeline; the degree to which Nemotron improves recovery must be established through controlled experiments.
5. Octo Shadow-Inference Pipeline
We also developed a file-based integration for Octo. The pipeline exports rendered observations and a manifest, supports inference in a separate environment, and merges predictions with task outcomes.
This separation allows us to investigate how a vision-language-action model's predictions relate to verified outcomes without allowing experimental predictions to directly control the robot.
Experiments and Results
We evaluated the baseline, verification-only, and verification-plus-recovery modes across six conditions:
- Normal operation
- Grasp miss
- Weak grip
- Incorrect placement
- Container-rim interference
- Unrecoverable failure
Each condition was evaluated over five trials, giving 30 trials per mode.
| Metric | Baseline | Verify Only | Verify + Recover |
|---|---|---|---|
| Verified successes | 5/30 (16.7%) | 5/30 (16.7%) | 25/30 (83.3%) |
| False successes | 25 | 0 | 0 |
| Verified successes under normal conditions | 5/5 | 5/5 | 5/5 |
| Successful outcomes under recoverable fault conditions | 0/20 | 0/20 | 20/20 |
| Verified successes under unrecoverable failure | 0/5 | 0/5 | 0/5 |
The results show why verification and recovery serve different purposes.
The baseline reported success for all 25 unsuccessful trials involving injected faults. Verification-only eliminated those false success reports, but did not resolve the failures. Verification-plus-recovery achieved verified success in 20 of those 25 fault-injected trials, while correctly leaving the five unrecoverable trials unsuccessful.
In a separate experiment, the octo_shadow configuration also achieved 25/30 verified successes with zero false successes. This configuration ran the verification-and-recovery pipeline while exporting observations for Octo; these results do not establish that Octo inference itself improved task performance.
These are preliminary simulation results from five trials per condition, not a guarantee of performance in real-world robotics.
Challenges We Faced
One of our biggest challenges was distinguishing successful execution from successful task completion. A controller can finish its action sequence even when the object has not reached its destination. We therefore had to focus our evaluation on verified outcomes rather than relying on the controller's reported status.
We also had to design experiments that exposed different failure conditions instead of testing only ideal behaviour. This helped us compare failure detection, recovery, and explicit failure reporting.
Integrating an external AI advisor introduced additional engineering challenges, including API authentication, model selection, response handling, and fallback behaviour. We addressed these by testing the live API independently before proceeding to the larger experiment pipeline.
Finally, integrating Octo required separating observation export and model inference from the simulated robot's control loop. This allowed us to develop an experimental pathway without treating unvalidated model predictions as executable commands.
What We Learned
TrustLoop reinforced several lessons about building reliable AI-enabled robotic systems:
- Verification matters: Completing a sequence does not prove that the intended outcome occurred.
- Detection and recovery are different: Identifying a failure is valuable, but recovering from it requires additional logic.
- Failure must remain an acceptable outcome: A trustworthy system should recognise when it cannot complete a task.
- AI recommendations need boundaries: An advisor can suggest a response, but the system still needs constrained recovery logic and outcome verification.
- Evaluation must match the claim: A successful API call demonstrates integration, not improved robot performance. Similarly, exporting observations is not the same as demonstrating that a learned policy improves control.
What's Next?
Our next steps are to evaluate Nemotron-assisted recovery against the existing recovery strategy under the same fault conditions, run actual Octo inference on exported observations, and investigate whether its predictions provide useful information about task outcomes.
We also want to extend the framework to more complex manipulation tasks and eventually test it beyond simulation.
Conclusion
TrustLoop explores a fundamental question in autonomous robotics: How can we make robots more trustworthy when actions can fail?
Our approach combines outcome verification, bounded recovery, explicit failure reporting, and optional AI-assisted reasoning. Rather than assuming that every action succeeds, TrustLoop closes the loop between attempting a task and checking its result.
We believe trustworthy autonomy requires not only intelligent action, but also the ability to recognise mistakes, respond carefully, and know when to stop.
