 Horldsence
|
3631a037d8
|
client: 槽位对应队伍，不再按 id 顺序对号入座
裁判端两个槽位的语义应该是"队伍一 / 队伍二"，而不是"第 N 块发现的板子"。之前
两者混为一谈，出现两个都会被现场误读成故障的现象：
1. **两块槽位显示同一块板。** 每轮都从 `online_cameras()` 取前两个 id 填满两
个槽位，于是只有一块板在场时两边一模一样。裁判会以为两队的图传串了。
2. **板子掉线时画面左右互换。** 低 id 的板子一离线，候选列表缩短，后面那块就
跳到前面的槽位——同样像串线，而实际上只是排序。
规则改成：每轮最多消费一个候选 id；已填且仍在线的槽位不动；掉线的槽位保留它的
id 并显示"离线"，等它回来时还在原位。
空槽的提示文案也改准：左槽"等待队伍一的图传"、右槽"等待队伍二的图传"，而不是笼
统的"未收到画面"。
顺带修两个假数字：`frames_shown == 0` 时 `stats.width`/`height` 还是默认值 0，界
面上显示成 `0x0`——一个看起来像分辨率的假分辨率；fps 显示 `0.0` 读起来像"板子
卡死了"，而真相是"还没收到"。状态行已经写了"已连接，等待画面…"，不该再补一个矛
盾的数字。
关于"别把刚掉线的板子又立刻选回同一个槽位"那条过滤：它只在槽位掉线时起作用，
且会跳过当前 id 去找下一个候选，槽位仍然有机会回来。实测唯一那块在推流的板子正
常占用一个槽位，另一槽保留着在线但不推流的真板子——符合预期。
|
2026-10-05 21:45:24 +08:00 |
|
|
Horldsence
|
cd8344c698
|
client: 修裁判端两格不等宽，加滚轮缩放与拖动平移，启动即最大化
**塌缩问题**（用户报的现象）：裁判端窗口放大时，左边那格吃掉约 55% 宽度，右边
只有 45%；空的那一侧更极端时会被压成一条缝。
原因不是缺 stretch，而是 `HorizontalLayout` 先按内容的**最大**需求分配、剩下
的才按 stretch 分。左格写着"已连接，等待画面…"（8 个字），右格"未收到画面"
（5 个字），左格就多要十几个像素。而没有画面的一格最小宽度接近 0，可以被压没。
三处一起改：
1. 占位文字改成绝对定位（给出 x/y），不再参与父级尺寸计算。文字长短本不该
决定画面大小。
2. 两格统一 `preferred-width: 480px` + `horizontal-stretch: 1`，需求变成相同，
于是精确平分。`min-width: 320px` 兜底，保证任何一侧至少有一个能看画的宽度。
3. 缩放指示与复位按钮也绝对定位。否则它们一出现就改变这一格的尺寸需求，把
不等宽重新引进来——而且是在用户放大之后才出现，最难排查。
**缩放**：Slint 的 `Image` 没有缩放因子属性，所以把它的 `width`/`height` 按 zoom
放大后放进 `clip: true` 的容器，靠 offset 平移。滚轮改 zoom、拖动改 offset、双击
复位、缩回 1.0 时自动归位（否则下一次放大会从偏移位置开始，看起来像"跳了一下"）。
`image-fit` 要跟着 zoom 切：`contain` 在 zoom=1 时保证完整可见且不变形，`fill`
才让画面跟着放大——只用 contain 的话放大不会有任何视觉变化。
**启动即最大化**：Slint 没有"最大化"这个状态，但有 `set_maximized`，它铺满工作区
且保留菜单栏和 Dock（真全屏 `set_fullscreen` 会盖掉它们，裁判终端要切去别的窗口
核对数据）。必须在 `show()` 之前调用，之后调用会被后端当成"用户点了最大化按钮"。
抽出 `VideoPane` 与 `StatusBar` 两个组件给两种身份复用。两者都不加 `export`——
它们只在 .slint 内部使用，加了会触发"doesn't inherit Window. No code will be
generated for it"的警告。
Slint 的两处写法记在这里，都是编译器试出来的：
- `TouchArea` 的 `pressed` 是**属性**不是回调，写 `pressed => {}` 编译不过。
拖动要用 `pointer-event(e)` 配 `PointerEventKind.down` / `.move`。
- `EventResult.accept` 要写全限定；`accept` 单独写无法解析。
|
2026-10-05 21:28:32 +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 |
|