ESP32S3_vt

9 Commits 2 Branches 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
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	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

Author

SHA1

Message

Date

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

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