为什么机器人故障诊断需要 Episode，而不只是日志

日志记录事件，却不天然构成一次运行

机器人故障通常不会只出现在一个文件里。ROS 2 节点日志、Topic 数据、TF、里程计、地图、参数和 Nav2 状态分别描述系统的一部分，而且使用不同的频率、格式和时间尺度。

即使保存了全部日志，如果没有任务开始与结束的边界、机器人配置、环境信息和软件版本，工程师仍然需要手动判断哪些记录属于同一次运行。一次故障复盘因此很容易变成在多个终端、文件和图表之间反复对齐时间。

数据存在，不等于问题可以被复现；日志完整，也不等于证据已经形成。

Episode 是带上下文的一次任务运行

在 ZephaRobot 中，Episode 不是另一种日志格式，而是一次机器人任务实际运行过程的容器。它从任务开始延伸到结束，连接这段时间内的状态、事件、异常和原始证据。

一个可以被复盘的 Episode 至少需要回答以下问题：

• 哪台机器人在什么环境中执行了什么任务；
• 任务使用了哪些软件版本、地图和关键参数；
• 运行从什么时候开始、什么时候结束、结果如何；
• 关键状态怎样随时间变化，异常在哪个时间区间出现；
• 每个诊断结论能够回到哪些信号、事件或日志证据。

从 Mission 到 Report 的证据链

Episode 需要和其他对象配合，才能把“系统报错了”转化为可以检查的工程结论：

• Robot 描述机器人身份、类型和数据接入方式；
• Mission 描述目标、运行环境和成功条件；
• Episode 保存某次实际运行的边界与上下文；
• Signal 保存电量、温度、位姿或其他连续状态；
• Event 记录任务阶段、状态切换和外部操作；
• Incident 描述值得调查的异常及其触发证据；
• Report 汇总时间线、异常、证据和后续检查项。

这个模型的重点不是自动给出一个看似确定的根因，而是让诊断摘要始终能够返回触发规则、发生时间和原始数据。自动化可以减少整理成本，但不能替代工程师对证据的复核。

当前原型已经验证了什么

ZephaRobot 当前使用 Mock 数据验证最小闭环，已经具备 Robot、Mission、Episode、Signal、Event、Incident 和 Report 数据模型，以及对应的服务端 API 和查看界面。

原型能够生成电量过低、电机过热和正常运行等模拟场景，使用明确规则产生 Incident 与诊断摘要，并输出 Episode HTML 复盘报告。自动测试用于检查异常是否被识别、证据是否保留、报告是否可以生成。

这些结果说明数据模型和报告链路可以运行，但还不能证明它已经适用于真实机器人。当前没有完成真实 ROS 2 在线连接器、rosbag2 导入、SLAM 质量分析和 Nav2 故障诊断。

下一阶段要验证的不是更多页面

下一步工作的重点，是让同一个 Episode 模型接收可复现的 ROS 2 仿真运行记录，并检查四件事：

1. 任务边界、版本和环境信息能否随数据一起保存；
2. TF、里程计、导航状态与日志能否在同一时间线上对齐；
3. Incident 能否准确引用触发它的时间区间和原始信号；
4. 修复前后的两次 Episode 能否使用相同条件进行比较。

当这条链路在仿真环境中稳定后，再接入真实 rosbag2 记录。只有真实数据能够被导入、复现和复核，ZephaRobot 才能从数据模型原型继续走向有实际价值的机器人诊断工具。

为什么从 Episode 开始

机器人可靠性不是单个算法的准确率问题，而是一次任务能否被理解、失败能否被复现、修复能否被验证的问题。Episode 为这些问题提供了共同边界，也让代码、数据和工程判断有机会形成一条连续证据链。

这是 ZephaRobot 当前最核心的研究假设。接下来的价值不取决于这个概念听起来是否完整，而取决于它能否在 ROS 2、SLAM 和 Nav2 的实际故障场景中经受验证。