Why Robot Failure Diagnosis Needs Episodes, Not Just Logs

Logs record events, not complete runs

A robot failure rarely lives in one file. ROS 2 node logs, topics, TF, odometry, maps, parameters, and Nav2 states describe different parts of the system at different rates and time scales.

Without task boundaries, robot configuration, environment, and software versions, engineers still have to decide manually which records belong to the same run. Data can exist without making the problem reproducible.

Complete logs are not automatically connected evidence.

An Episode is one mission run with context

In ZephaRobot, an Episode is not another log format. It is the container for what actually happened between mission start and finish, connecting state, events, incidents, and original evidence.

• Robot identifies the robot and its connector.
• Mission defines goals, environment, and success conditions.
• Episode preserves boundaries and runtime context.
• Signal represents continuous state such as battery, temperature, or pose.
• Event records task stages and state transitions.
• Incident identifies an anomaly and its triggering evidence.
• Report assembles the timeline, evidence, and follow-up checks.

What the current prototype validates

The current ZephaRobot prototype uses mock data to validate the minimum workflow. It includes the core data models, server APIs, incident rules, diagnosis summaries, an HTML Episode review report, and a console for inspecting runs.

Mock scenarios cover low battery, motor overheating, and successful runs. Tests check that incidents are detected, evidence remains attached, and reports can be generated.

This validates a software model—not real-robot applicability. A real ROS 2 connector, rosbag2 import, SLAM quality analysis, and Nav2 failure diagnosis are not yet complete.

The next validation target

The next phase will feed reproducible ROS 2 simulation runs into the same Episode model and test whether:

1. mission boundaries, versions, and environment metadata remain attached;
2. TF, odometry, navigation state, and logs align on one timeline;
3. an Incident can reference its exact time range and source signals;
4. two Episodes can compare conditions before and after a fix.

Only after this workflow is stable in simulation should it ingest real rosbag2 records. ZephaRobot becomes useful when robot data can be imported, replayed, and reviewed—not when the concept merely sounds complete.

Why start with Episodes

Robot reliability is not only an algorithm-accuracy problem. It is also whether a mission can be understood, a failure reproduced, and a fix verified. An Episode gives those questions a shared boundary and a continuous chain of evidence.