第 2 周（2026-07-20 ~ 2026-07-26）

蒋玉月 · StarryOS SG2002 TPU/NPU 推理加速阶段声明：单帧推理→端到端管线→控制层迁移，进入板上闭环联调阶段

一、本周目标

对接李明涛的 UVC 驱动打通摄像头→TPU 推理全链路，参照 AKA-00 开源方案移植机器人控制层，实测对比两款模型的板上性能。

二、关键成果

2.1 管线性能演进：v2 → v7

阶段	v2（基线）	v5（上周）	v7（当前）	改善
Camera	300ms	189ms	95ms	3.2x
Preprocess	235ms	146ms	96ms	2.4x
TPU Forward	51ms	70ms	40ms	硬件极限
NMS	4ms	4ms	2ms	2x
总计	590ms	409ms	233ms	2.5x
FPS	1.7	2.4	4.3	—

v7 相比 v2 总耗时降至 1/2.5，FPS 翻倍。主要收益来自：Camera（李明涛驱动优化 + 取帧策略改进）、Preprocess（零拷贝 + 浮点直写 TPU buffer）、NMS（C 实现精简）。

2.2 李明涛：StarryOS USB UVC 驱动

在 tgoskits 上合入了 UVC 驱动的核心模块：

uvc 驱动：uvc_camera.rs，含 YUYV 格式支持和 DWC2 USB Host 初始化
V4L2 框架：按 Linux include/uapi 实现设备节点层，/dev/video0 正常挂载
vivid 虚拟驱动重构至 drivers/media/vivid/
用户态工具 v4l2-test：v4l2-ctl 交叉编译 + 3 个 V4L2 采集/测试程序，run.sh 一键 build/deploy/sdcard

当前 Camera 取帧已从最初 300ms 优化至 95ms（v7），对比 Linux 端 10ms 仍有差距，驱动层持续优化中。

2.3 AKA-00 机器人参考架构分析

深度分析了 chenlongos/AKA-00 的完整技术栈：

硬件架构：SG2002 + ESP32-C3（底盘 PWM PID） + ZP10S/STS3215 舵机（UART）
控制算法：5 状态 FSM（chase→position→grab→bucket→release）+ P 比例差速控制
通信协议：ESP32 UART 帧协议（0xAA 0x55 + checksum），ZP10S ASCII 协议
Web 前端：React + TypeScript，支持方向键/RC 摇杆/重力感应/模型商店

2.4 控制算法迁移

将 AKA-00 控制算法迁移至 StarryOS，新增文件：

pipeline/
├── state_machine.py   # 5状态FSM + PID差速控制
├── motor_driver.py    # ESP32 UART协议 (Mock + TtPid)
├── servo_driver.py    # ZP10S / STS3215 舵机
├── hunter.py          # 主控循环（TPU推理→状态机→PID→电机）
├── web_server.py      # 内置Web遥控（纯Python，零外部依赖）
├── terminal_debug.py  # 终端可视化调试
└── robot.py           # 统一入口（debug/mock/web/run/test 五命令）

PC mock 验证：5 状态全通，PID 差速输出正确，10 帧确认抓取机制正常。

2.5 板上模型对比

AKA-00 Linux 系统上，两款 cvimodel 各跑 200 次 TPU Forward：

V2        avg=39.6ms  p50=39.5ms  min=39.5ms
AKA-00    avg=188.5ms  p50=188.4ms  min=188.3ms

模型	Forward	内存占用	Anchors	检出置信度
V2	39.6ms	2.2MB	8,400	0.95-0.97
AKA-00	188.5ms	10.7MB	27,600	0.85

V2 快 4.8 倍，因为 anchor 数为 AKA-00 的 1/3，推理负载更低。注意此对比使用的是 AKA-00 自带的 cvimodel（27,600 anchors），与 2.6 节中在 Linux 端运行 V2 模型（40ms）不是同一个模型。检出置信度更高得益于 YUYV native 路径（无 OpenCV JPEG 压缩损失）。

2.6 StarryOS v7 vs AKA-00 Linux

阶段	StarryOS v7	AKA-00 Linux	备注
Camera	95ms	10ms	Linux UVC 驱动更成熟
Preprocess	96ms	120ms	C 零拷贝 vs OpenCV
TPU Forward	40ms	40ms	TPU 硬件，与 OS 无关
NMS	2ms	4ms	—
总计	233ms	174ms	差距 1.3x
FPS	4.3	5.7	—

关于 StarryOS vs Linux 速度对比的更正：此前曾表述 “StarryOS TPU 推理比 Linux 快”，该结论存在误导。本周在 AKA-00 Linux 板上实测验证后发现：

TPU 纯 Forward 耗时与 OS 无关。同一模型（V2 cvimodel）在 StarryOS 和 AKA-00 Linux 上均为 40ms。TPU 是独立硬件加速器，推理速度由模型结构决定，不受 Host OS 影响。
此前 Linux 端 200ms 的数据来自 Sipeed Buildroot + cvitek_tpu SDK 旧版本，差距源于 SDK 调用链路。
StarryOS 端 Camera 95ms 对比 Linux 端 10ms，是当前总耗时差距（1.3x）的唯一来源。Preprocess 和 NMS 环节 StarryOS 反超。

2.7 预处理优化历程

版本	方案	Pre	TPU	FPS	关键改进
v2	malloc 分离版	235ms	51ms	1.7	基线
v5	浮点 + 直写 TPU	146ms	70ms	2.4	零拷贝写入 TPU buffer
v7	零拷贝 + 精简路径	96ms	40ms	4.3	消除中间 buffer + NMS 精简

三、产出

全部代码位于 ACT-Runtime：

pipeline/
├── state_machine.py   # 5状态FSM + PID差速控制
├── motor_driver.py    # ESP32 UART协议 (Mock + TtPid)
├── servo_driver.py    # ZP10S / STS3215 舵机
├── hunter.py          # 主控循环（TPU推理→状态机→PID→电机）
├── web_server.py      # 内置Web遥控（纯Python）
├── terminal_debug.py  # 终端可视化调试
└── robot.py           # 统一入口（debug/mock/web/run/test 五命令）

board_tools/
├── model_compare.py   # 双模型对比脚本
└── collect_data.py    # 数据采集脚本

dataset/
├── images_png/        # 202张待标注PNG（50MB）
└── images_yuv/        # 原始YUYV帧（119MB）

四、下周计划

跟进 DQBUF 驱动优化，StarOS 端到端闭环上线，目标 5fps
接入 ESP32 电机 + 舵机真实硬件，验证状态机 + PID 控制

Keyboard shortcuts

Chaofeng