5 Commits

Include renames

Author	SHA1	Message	Date
sloray	cc6b82d7ec	feat: 链路控制、延迟校准与长测工具，补全文档 ... - 固件：新增 link_control / stream_control，覆盖运行中 Wi-Fi 断线恢复、取帧节拍、 温控与质量/帧率减载；UDP 发送增加有界重试预算与帧期限，PSRAM JPEG 直发减少拷贝。 - 协议：重组器严格校验分片布局，统计未收齐、超时与完全缺失的帧，处理帧号回绕与设备重启。 - 桌面端：视频改 latest-value 通道并前置帧时间标记，拒绝积压和慢解码的过期画面；新增 延迟标记页与 --latency-report 校准，完善录制、服务端与退出流程。 - 文档与脚本：新增硬件、开发、延迟、功耗、实时性、稳定性文档和改动记录，重写根 README； 新增构建、性能、延迟与串口长测脚本，以及长测客户端脚本。 - 构建：固定 esp-1.97.0.0 工具链，分区表随构建复制，更新 sdkconfig 与忽略规则。	2026-10-19 00:19:07 +08:00
Horldsence	a89d7ae5fb	desktop: Tauri v2 后端 + 共享网络层（用户端/裁判端双身份） ... 把桌面端从 Slint 迁到 Tauri v2，后端先落地，界面待接。拆成三层： - desktop/core（cam-core，67 测试）：从旧 client/ 抽出的非界面部分。UDP 接收按 发送方重组、装甲板发现与血量、帧率窗口、槽位分配、配置与密码。 - desktop/src-tauri（27 测试）：Tauri 后端。回环 WebSocket 推二进制 JPEG、 每 200ms 一份状态快照、密码闸门、截图、ffmpeg 录制 mp4、演示数据源。 - protocol：新增 ArmorHealth::decode_from，把帧头里的 sender_id 交出来—— 装甲板一直带着 MAC 派生 id 在广播，旧解码路径把它丢了，所以"装甲板下拉可选" 不需要改固件。 几个改对了的旧问题： - 槽位分配：旧实现只排除"槽位自己原来那个 id"，于是队伍一的板子一离线，它的槽位 会去拿队伍二那块，两格显示同一块板子。现在候选要排除另一个槽位占着的 id。 - 帧率窗口的基线：掉线又回来的板子带着一个很大的累计帧数回来，从 0 起算会报出 几百 fps。改成 seeded + 用"已结算窗口数"判断有没有读数。 - 密码哈希：password-hash 能解析 `$argon2id$broken` 这种截断串，于是"配置坏了" 会被读成"密码错了"。现在要求盐与摘要都在。 - 录制文件名：同一秒停一次再开一次会用同一个名字，ffmpeg 的 -y 静默覆盖上一段。 现在先收尾上一段再开新的，并且重名往后排号。 - 两道闸门：帧的限制与发现列表的限制分开。设置界面需要列候选摄像头，但**画面** 不需要——旧版把两件事绑在一道闸门上，只能在"能列候选"和"挡住对手"之间二选一。 测试：protocol 15、cam-core 67、desktop 27，其中录制那条真的起 ffmpeg 并用 ffprobe 读回帧数与分辨率（只断言"文件存在"会漏掉空容器）。	2026-10-14 19:14:16 +08:00
Horldsence	7be8d7d2ba	protocol: 更正上一个提交的归因——坏帧不在这里 ... 上一个提交（1c65eaa）说"34 张 JPEG 不完整是重复分片凑数导致的"，并说修完从 34 降到 1。**这个结论是错的**，是我归因到了错误的地方。 实测复查：一到两个订阅者、20 秒 2000+ 个分片，重复投递数为 0（固定端口和 临时端口两种订阅方式都试过）。这条链路上根本不产生重复。 34 张坏帧的真实来源是探测脚本自己：scripts/udp_probe.py 的重组状态只按 sender_id 存，不按 frame_id 存。于是某帧丢了分片之后，下一帧的分片会接着往 同一个计数器里凑，凑够了就交出去一张混着两帧的 JPEG。 FrameAssembler 一直按 frame_id 隔离（换个 frame_id 就重置），所以它没这个 问题——脚本原先跟它不一致，而我又把脚本的输出当成了 crate 的行为。 本次改动： protocol/src/lib.rs 位图去重保留，理由改为正确性而非正在发生的故障，并在注释里写明实测重复 为 0、以及真正的坏帧来源。删掉一个死变量 `last`。行为不变。 protocol/README.md "重复分片必须去重" 一节改写：说清防护的定位是"哪天真的重复了"。 新增"按 frame_id 隔离，换帧即放弃"一节，讲清不隔离的具体后果。 记下探到坏帧时先怀疑测量工具。 值得记的不是位图本身，是那个错误归因：34 张坏帧配上"帧率正常、无报错线索" 这个症状，太像一个真的丢包/重复 bug 了，于是一路写到了注释、文档和提交说明 里。以后探到链路异常，先确认测量工具和被测对象说的是同一件事。	2026-10-05 19:13:24 +08:00
Horldsence	1c65eaabc6	protocol: 修复重复分片能凑出一张坏帧 ... `seen >= expected` 判断分片是否收齐是错的：UDP 会重复投递，一个丢失的 分片可以被另一个包的副本凑数，于是计数达标而缓冲区里留着空洞，交出去 一张尾部是 0 的 JPEG。 这个 bug 很隐蔽——帧率完全正常，没有任何报错线索，只是偶尔几张图解不 出来。实测 10 秒内出现 34 张这样的坏帧。 改为按分片下标记录是否收到，重复的直接跳过且不计数；再显式确认最后一个 分片确实到过。实测坏帧降到 1（板子启动瞬间的残帧），完整帧率不变。 补两个测试覆盖它——原有测试没有一个会重复发分片，所以这个 bug 一直没被 发现： - a_duplicate_cannot_complete_a_frame_with_a_hole - a_gap_that_is_never_filled_never_yields_a_frame 同时更新 scripts/udp_probe.py：它有同一个 bug，所以测不出修复效果。它还 把 Subscribe 的 role 字节多填了 12 个零字节，固件按偏移严格读取因而拒收， 表现为"板子在线但 0 clients subscribed"。脚本的意义正是独立核对线路格式， 所以这些偏移是手写的，改协议时必须同步。 另删 scripts/pick-flash-pad.sh：链接期 padding 已被证明移不动 .flash.text 内部，flash.sh 现在会自动挑选避开坏字节的 app 偏移。	2026-10-05 18:54:35 +08:00
Horldsence	4f893ce140	ESP32-S3 摄像头图传：固件 + Slint 客户端 + 共享协议 ... 两块 ESP32-S3-WROOM-1-N16R8 图传板（DVP 接口接 OV2640/OV3660/OV5640）， 向队伍客户端与裁判终端推 UDP 图传。固件是跑在 ESP-IDF 上的 Rust，用官方 esp32-camera 组件采集；客户端是 Rust + Slint 桌面程序。 三个 crate 各自独立构建： . firmware，交叉编译到 Xtensa protocol/ 线路格式与帧重组，两端共用，无 ESP-IDF 依赖，有单元测试 client/ Slint 桌面客户端 视频走 UDP 而非 TCP：实测传感器产出 22 fps，TCP MJPEG 只送出 1.9 fps， 且只占用链路能力的 1%——链路是空的，帧堵在队头阻塞后面等一个实时画面 等不起的重传计时器。改为独立数据报、不重传、缺片丢整帧后达到 20.8 fps。 发现是双向的：板子每 2 秒广播 Hello，客户端广播 Subscribe，板子据此定向 推流。板子身份由 MAC 派生，重启不变，所以客户端可以把绑定存进配置。 裁判端同时收两块板子（每个发送方一个重组器），队伍端绑定其中一块并只显示 自己那一边的血量。装甲板接口已预留（ArmorSource trait + ARMOR_PORT）， 当前无数据源，界面显示占位符。 vendor 了 esp32-camera 2.1.7：组件注册表的版本求解器找不到它，且需要打一处 补丁（见 components/esp32-camera/target/esp32s3/ll_cam.c）。 .gitignore 三条 target/ 都锚定在根目录，因为 protocol/ 与 client/ 各自也是 独立 crate；而 components/esp32-camera/target/ 是上游的按芯片分目录，里面是 源码，必须保留。	2026-10-05 18:22:19 +08:00