ESP32S3_vt

6 Commits 2 Branches 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
Horldsence	c7f42a1979	scripts: 修 udp_probe.py 的重组与 fps 两处测量错误探测脚本是诊断工具，测错比不测更糟——它给出的数字会被当成结论。重组状态必须按 (sender_id, frame_id) 存。原先只按 sender_id 存，于是丢片之后下一帧的分片会接着凑上一帧的计数，凑够了交出去一张混着两帧的 JPEG，表现为 "JPEG 不完整"。修完：14 秒 132 帧，0 张坏帧。换帧时被放弃的半成品单独计为"被新帧取代"，不并入"JPEG 不完整"——它们本来就不完整，混在一起会把两种情形都算成链路有问题。分窗 fps 的分子分母必须同量纲。原先用累计帧数除以窗口时长，于是报出 39、 61、79 这种随时间单调上升的假数字，看起来像板子越跑越快。改成窗口增量除以窗口时长后稳定在 22，也就是传感器上限。顺带修正两处与代码不符的注释： partitions.csv / sdkconfig.defaults 两处都写死 app 分区在 0x40000，实际是 scripts/flash.sh 自动挑选并写回，当前为 0x060000。补上 flash.sh 会重编译并复验的原因（重编译会让镜像位移，所以偏移无法是常量）。 .env.example 补 CAM_VSYNC_INVERT 和 WIFI_AUTH。WIFI_AUTH 一直能用但没进文档：通常不用设，扫描会报告 AP 的真实认证方式；只有扫不到时（隐藏 SSID）才需要指定，指定后只试这一种，不成功直接报错而不是挨个试 10 秒——挨个试等于在猜一个本该已知的值。	2026-10-05 19:13:37 +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

c7f42a1979

scripts: 修 udp_probe.py 的重组与 fps 两处测量错误

探测脚本是诊断工具，测错比不测更糟——它给出的数字会被当成结论。

**重组状态必须按 (sender_id, frame_id) 存。** 原先只按 sender_id 存，于是丢片
之后下一帧的分片会接着凑上一帧的计数，凑够了交出去一张混着两帧的 JPEG，表现为
"JPEG 不完整"。修完：14 秒 132 帧，0 张坏帧。

换帧时被放弃的半成品单独计为"被新帧取代"，不并入"JPEG 不完整"——它们本来就
不完整，混在一起会把两种情形都算成链路有问题。

**分窗 fps 的分子分母必须同量纲。** 原先用累计帧数除以窗口时长，于是报出 39、
61、79 这种随时间单调上升的假数字，看起来像板子越跑越快。改成窗口增量除以窗
口时长后稳定在 22，也就是传感器上限。

顺带修正两处与代码不符的注释：

  partitions.csv / sdkconfig.defaults
    两处都写死 app 分区在 0x40000，实际是 scripts/flash.sh 自动挑选并写回，
    当前为 0x060000。补上 flash.sh 会重编译并复验的原因（重编译会让镜像位移，
    所以偏移无法是常量）。

  .env.example
    补 CAM_VSYNC_INVERT 和 WIFI_AUTH。WIFI_AUTH 一直能用但没进文档：通常不用
    设，扫描会报告 AP 的真实认证方式；只有扫不到时（隐藏 SSID）才需要指定，
    指定后只试这一种，不成功直接报错而不是挨个试 10 秒——挨个试等于在猜一个
    本该已知的值。

2026-10-05 19:13:37 +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