3 Commits

Include renames

Author	SHA1	Message	Date
sloray	896b21fe44	feat(client): RMIC::2026 界面重做、可计算的版本机制与固件版本联动 ... - feat(client): 界面换成墨黑蓝底 + 单支红的矩形语言，切角全部去掉，仅装甲条保留平行四边形 - feat(client): 自托管 HarmonyOS Sans SC 与 JetBrains Mono，中文与拉丁数字逐字回退 - feat(client): 新增启动序列、首启门、用户端 HUD、裁判端控制台、设置抽屉与固件维护页 - feat(client): 裁判端中缝与下方控制台可拖，鼠标落在哪一路下方就看哪一路 - feat(client): 设置抽屉常驻实时预览，与画面共用同一份准星绘制代码 - feat(client): 动效改用 Material 3 的缓动曲线与时长，逐条替换掉自造的贝塞尔 - feat(version): 版本号与 CHANGELOG 由 scripts/version.mjs 从 git 历史算出，不再手写 - feat(firmware): Hello 报文携带语义化版本、构建号与自报协议号，负载向后兼容 - feat(client): 固件版本显示在绑定列表与裁判端每一格；协议不匹配时给出具体原因 - feat(firmware): 固件包版本与客户端同源，都从 version.json 读 - fix(client): getCurrentWindow() 在没有 Tauri 注入时同步抛异常，浏览器预览整棵树被卸载 - fix(client): 启动序列的淡出 effect 清掉了自己刚设的 setTimeout，界面永远停在启动页 - fix(client): 设置抽屉左侧导航的锚点没挂到 section 上，且用错了坐标系 - fix(protocol): Hello 改用宽松帧头解析，让协议不匹配的板子能被解释而不是静默消失 - fix(build): Windows 上 bindgen 加载不了 libclang 的同目录依赖，构建脚本补上搜索路径 - fix(build): esp-idf-sys 在长路径下拒绝构建，固件构建改用短的目标目录 - build(client): 队标图标，含光学尺寸分级与手工拼的多尺寸 ICO - build(ci): 守门 job 增加版本一致性检查，产物名改为 rmic-2026-* - docs: 补充界面语言、版本机制与协议通告布局的说明	2026-10-19 02:40:08 +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	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