All work
01 / ROBOTICS · AGENT

Making robot failure,
understandable.

From “the task failed” to “this is where it went off course.”

Research in progressExecution traces / Failure analysis / Tested repairs
  1. 01

    Record the run

    Keep observations, actions, and feedback

  2. 02

    Locate the deviation

    Find the earliest meaningful mismatch

  3. 03

    Propose a repair

    Make one testable change

  4. 04

    Run it again

    Compare the evidence before and after

What should we ask after a task fails?

A robot failing to complete a task tells us the outcome. It does not yet tell us what to change. Where did the run first diverge from its goal? What information was available at that moment? Did the problem begin in task interpretation, action planning, or a changing environment?

Consider a two-arm handover. Failure might mean that the receiving arm was not ready, that the other arm released too early, or that the object’s pose differed from what was expected. Each possibility calls for a different change. A single label such as “action failure” loses that distinction.

Turn execution into evidence

This exploration draws on failure attribution and repair ideas from ASPIRE, alongside CaP-X’s program execution and feedback capabilities. The question is how to organize more detailed records of coordinated execution.

The proposed record follows observations, decisions, actions, and outcomes. Each step captures the expected state, the available feedback, and the constraints that should hold. The aim is to find the earliest meaningful deviation.

Keep observations, explanations, and hypotheses separate.

“The gripper-open sensor is active” is an observation. “The object may have been released too early” is an explanation. “Waiting for confirmation from the receiving arm may improve the handover” is a hypothesis to test.

A repair should be concrete. If release timing is the suspected cause, change the relevant condition and run the task again. If the target pose appears wrong, first inspect perception and coordinate transforms. Each change should address an observable cause and be checked for new problems.

Evidence and current limits

This page presents problem framing and method design. It does not yet include a complete system run, real-robot validation, or quantitative results.

A future case study should include the failed execution trace, the evidence supporting the diagnosis, the exact change, and the result of running it again. A plausible explanation alone does not establish that a repair worked.

Research question and workflowPresented here
Execution case studiesTo be added
Success rate and repair efficiencyAwaiting experiments

What comes next?

Start with one failure that can be reconstructed from beginning to end. Compare diagnoses based only on the final outcome with diagnoses based on a detailed execution trace. A small case with clear evidence is a useful foundation for the next experiment.

NEXT EXPLORATIONAttention, made visible.