Horldsence/ESP32S3_vt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7 Commits 2 Branches 0 Tags
cd8344c69835d68e0d1579e34dfaacc1e22b9f4b
Commit Graph
4 Commits
Author SHA1 Message Date
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 a16ad8595e client: 队伍端 release 只接收绑定的那一块板子 
对抗赛里两队都用这套系统看自己小车的图传。需求是防止对手开第二个窗口连到另一
队的板子。

**关键是这必须做在接收端，而不是界面里。** 我先按"只在 release 下不显示 id 和
IP"理解，但那样等于没做：广播的 Hello 里就有 MAC 派生的 id 和 IP，对手
tcpdump 一下全都知道，而数据本来也已经收下并解码了。隐藏一行文字不阻止任何事。

所以改为 `Receiver::restrict_to`：队伍端 release 且已绑定时，只重组、只解码、
只统计绑定的那一块板子。对手的板子即使把流推到了本机端口（IP 已泄露、端口是
公开常量），数据也不会进入任何管线。

四种情况不限制：裁判端（中立第三方，本来就要两块）、debug 构建（开发时需要
看到全场）、队伍端未绑定（选择界面需要列出候选）、命令行临时覆盖 camera_id。

`--list` 在 release 队伍端直接报错：它会打印场上所有板子的 id 和 IP，正是要防
的那件事。与其列出来再叮嘱"别看"，不如不给。

`TEAM_DIAGNOSTICS = cfg!(debug_assertions)` 门控界面上的 fps / 丢帧 / 数据报数
等遥测和 stdout 的诊断日志。裁判端不受影响——它是中立方，双方遥测对判罚有用。

选择界面保留：现场换机器时还要用它重新绑定。数据侧的闸门已经足够。

顺带修一个设计上就错的判断：`is_online()` 看的是 `last_seen`，而它此前只由 Hello
更新，于是出现"画面每秒刷 22 帧、状态栏却显示离线（橙色）"的矛盾状态。正在推
流本身就是最可靠的存活证据，所以收到视频帧也刷新时间戳。
 2026-10-05 21:27:36 +08:00
Horldsence 7b6593bb75 文档：按 UDP 多端架构重写根 README 与 client README 
三份文档此前还是 UDP 之前的内容（旧 HTTP 架构、单路、无身份概念），与实现不符。

根 README 是总入口：拓扑（两块板不区分队伍，"哪一边"由客户端决定）、实测性
能对比、发现协议、身份派生理由、构建烧录、硬件坑、排查表。

client README 覆盖：两种身份对应的两个组件、命令行、绑定流程与配置格式、三个
线程的分工、Slint 的硬约束（Image/Weak 不是 Send、ModelRc 没有 From<Vec<T>>、
基础元素不能挂 callback）。

写的时候逐条核对了代码，发现并修正了几处"我以为是这样"：

  - WIFI_AUTH 一直能用但从未进文档，.env.example 里也没有
  - 两端各有超时淘汰（原以为没有），值不同：固件 6 秒丢订阅者、客户端 60 秒
    才从界面列表移除。固件还有 MAX_PEERS=4 的上限，也补上了
  - 两处注释写死 app 分区在 0x40000，实际由 flash.sh 自动挑选
  - 实测数字重测：22 fps / 0 丢帧 / 平均帧 22 kB / 350 包每秒

也把两条踩过的坑写进去了，因为它们都属于"看起来是 A，实际是 B"：帧率必须按
计数除以墙钟（累计值除窗口值会报出单调上升的假数字，这个错误出现过两次），
以及探到链路异常先怀疑测量工具。
 2026-10-05 19:13:52 +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