把失败也写进系统：证据驱动的 Robot Twin 迭代

本文回顾 2026 年 7—8 月的项目，包含后续整理与补充。实验数字和验证范围按原始项目记录陈述；文末仓库路径为记录索引。

项目做到后面，有一类事情越来越费时间：日志在，结果也在，可这次到底算验证了什么？

同步失败，可能是通信、解析、批量接收，也可能是相机或者时间戳。候选表现变好了，也得先看看测试条件有没有换。没有 baseline、条件和原始数据，下一轮又只能把这些猜测重新过一遍。模块可以接着写，这些旧账却不会自己变清楚。

于是后期花了不少时间补记录、补检查，也补一些以前没分开的数据。写在这里，算是给这组文章收个尾。Robot Twin AI 目前已基本停止维护，下文保留的是这一阶段做过的事和当时尚未完成的计划。

后期修改与各自的验证范围

方向	做了什么	当前证据等级	不能扩大成什么
采集与分析解耦	用有界分析队列把视频写入和 AprilTag 分析拆开，记录分析丢弃和未完成项	`VERIFIED`，限离线代码和测试	不能写成真实相机帧率或识别率已经提升
虚拟车体几何	为 AprilTag 锚点增加车体中心、矩形角点和版本化 profile	`VERIFIED`，限软件契约	不能写成车体已经完成物理标定
同步轨迹仪表盘	设计参考形状、相机实际轨迹、融合航向和最近参考距离的分层显示	`PLANNED` 或设计边界	不能把视频提取形状叫绝对真值
六轴 IMU telemetry	独立分支已有 TCP-only 的解码、PC schema 和固件发送实现候选	`VERIFIED`，限独立分支软件实现；主线集成与实机验证仍是 `PLANNED`	不能写成当前主线固件已经运行六轴 telemetry，或六轴数据已经完成真实控制闭环
telemetry FIFO 与 ClockSync 仲裁	调整普通遥测的 FIFO 准备和 ClockSync 调度边界，保留丢弃计数	`VERIFIED`，限离线构建与测试	不能写成持续拥塞下零丢包或同步门通过
Clock Event Identity	将 exchange、causal parent、observed boundary 和 legacy replay 分开	`VERIFIED`，限软件契约	不能写成物理时钟已经绝对同步
PC endpoint uncertainty	用每次 `sendall()`/`recv()` 调用的实测区间建立中点和半宽不确定度	`VERIFIED`，限 PC 应用边界	不能写成知道 TCP/Wi-Fi 物理链路的完成时刻
Agent 治理记录	增加 task state、workflow/tool run、handoff 和证据分类边界	部分离线验证，运行时仍需新会话确认	不能写成 Agent 已经自主完成机器人研发

从标签坐标推导车体几何

看早期轨迹图，很容易把 AprilTag 的中心当成小车的位置。可标签只是贴在车上的一个点，车体中心在别处，前面的巡线传感器又在别处。显示一个点还不明显，要画整辆车、算传感器位置时，这个差别就绕不过去了。

后续我增加了一个版本化的初始车体 profile：车体长度 190 mm、宽度 140 mm，标签中心到车体中心沿车头方向的初始偏移为 55 mm，侧向偏移为 0 mm。这个 profile 的状态明确写成 HEURISTIC_UNVERIFIED，用于显示、数据结构和软件联调。

它带来了几个更清楚的区分：

anchor 是实际观测到的标签中心；
center 是根据 profile 推导出的车体中心；
corners 是由几何变换得到的车体矩形；
标签角点只有在检测器实际返回时才保留，不能从一个点姿态反推成“观测角点”。

这样可以沿着数据来源区分观测点和推导位置。上面的尺寸仍是未验证的初始值，车体几何的物理标定还没有完成。

让轨迹图保留来源与校准状态

仪表盘当时还在设计。我要放进去的线和形状不少，得先说明白每一种来自哪儿：

视频提取的参考形状；
相机实际观测到的轨迹；
由 IMU 提供的航向信息；
由标签姿态推导出的车体矩形；
离线模型产生的候选预测。

其中，视频提取的参考形状不是绝对地面真值；IMU 当前也不能单独提供一条可信的 x/y 位置轨迹；相机实际轨迹与预测轨迹更不能画成同一种颜色后让人猜它们的来源。

因此设计里要带上来源、时间范围和校准状态。没标定就显示不可用，填个零进去太容易让人当成真数据。最近参考距离也先用无符号几何距离，赛道一交叉，强行标左右反而会误导。

遥测发不完，先查队列怎么处理

真实运行里还遇到过一个很实际的问题：telemetry 在生成，CIPSEND 却来不及发，旧路径会把前面还没发出去的数据覆盖掉。后来的离线修改把普通遥测从 latest-window 改为 FIFO，也把 ClockSync 放进受保护的队列仲裁路径。

离线记录包括 simulation/digital_twin/tests 的 991 passed、5 skipped、Keil Target 1 的 0 Error 和 0 Warning，以及低于 IRAM 上限的 RAM 检查。这个结果说明队列和调度契约在软件和构建层面通过了检查，但同一记录也明确说明：持续拥塞时仍可能丢弃最旧的可丢弃遥测，当前 AXF 只是构建候选，没有因为这次离线工作就变成新的实机证据。

六轴 IMU telemetry 则是在另一个独立分支做的：解码器、PC schema、固件 TCP 发送都有离线实现候选，兼容旧 24/26 字节数据，传递六个原始 int16 轴值和 sample_seq。但这份记录对应的主线 HEAD 没包含它，也没有烧录运行的证据。代码写在分支里，和车上已经在用，中间还隔着集成与实测。另外，这六个值是原始计数，还不能当成换算后的物理单位，更别直接算成 IMU 已经参与了控制。

Agent 换个会话，也得知道上次停在哪儿

实验和 Agent 会话一多，还有一件麻烦事：上次到底做到哪儿了？为了下次不用从头猜，这一阶段也开始维护这些记录：

每个任务的 task state 和追加事件；
工具运行和 workflow run 的独立记录；
跨会话 handoff；
用户更新、授权状态和完成权限；
证据引用以及 VERIFIED、INFERENCE、INSUFFICIENT EVIDENCE、PLANNED 分类。

这些记录用于跨会话接续工作。新会话是否读取了它们、运行时消息是否按预期传递，仍需检查；目前的文件与离线测试不足以证明 Agent 能自主改进机器人。

整个阶段的结果与未完成项

已验证

V1-A 的控制器、车辆模型、虚拟传感器、预测和候选评估构成离线闭环；
受控硬件 Smoke 的通信、ACK、心跳、启动、停止和清理生命周期；
相机失败帧、采集时间和分析状态可以被单独记录；
一些 ClockSync、事件身份、PC 应用区间和队列行为的软件契约；
车体几何、旧姿态兼容和 dashboard 数据边界的部分软件结构。

合理推测

更清楚的时间和观测边界会减少把主机批量接收误判成传感器乱序的风险；
车体中心与标签锚点分离后，后续预测和可视化更接近真实机械结构；
采集和分析解耦会让失败原因更容易被复查，但它不一定提高检测器本身的准确率。

证据不足

数字孪生是否已经完成真实标定；
对独立真实 holdout 的预测是否可靠；
相机、IMU、MCU 和 PC 是否已经满足物理同步要求；
车辆轮速、位移和轨迹是否被稳定测量；
某个候选是否真的改善了实体机器人的控制；
AI 是否已经自主修改算法、设计硬件并通过真实验证。

当时计划中、尚未完成

在固定赛道、固定条件和版本化标定下保留 baseline；
进行不混淆预测与观测的独立 holdout；
用明确的时间边界重新进行一次受控真实采集；
完成相机、车体和传感器的必要校准；
经过人工确认后，才把一个受限候选带入真实 A/B，并保留接受或回滚依据。

如果重新开始实验

如果重启项目，我会先补独立真实数据，用它检查标定与模型预测，再进入候选筛选和受控实车对照。现有的 STM32 控制生命周期和离线路径可以复用，未完成的观测、同步和标定则要接着验证。AGI、自主学习与持续自我进化都不属于当前已有能力。