docs: 完善AI桌面陪伴助手实施规划与采购方案
This commit is contained in:
ylhan
+202
-98
@@ -1,137 +1,241 @@
|
||||
# AI 桌面陪伴助手 · 方案
|
||||
# AI 桌面陪伴助手 · 实施规划 v2.3
|
||||
|
||||
> 状态: 🧭 方案已定稿（2026-09-12），尚未动手实现
|
||||
> 一句话: N5095(16G) 当"AI 大脑"，ESP32 头部 MCU 接管"屏+电机"实时外设，走 UART 分层。
|
||||
> 更新：2026-09-12。状态：架构方向确认，具体采购及环境待确认；尚未实现或实机验证。
|
||||
> 已确认：Ubuntu，复用 N5095 / 16G；麦克风、音箱、屏幕、摄像头均未购；LLM先用DeepSeek V4.1 Flash；语音优先本地运行。以本人使用为主，加入基础多人能力并预留身份扩展；预算分阶段投入。
|
||||
> 核心目标：听得清、回应及时、可打断、表情明确、转头自然。
|
||||
> 最新外形要求：屏幕不用太大，暂沿用1.28英寸圆屏；摄像头水平可用旋转总行程至少180°，按正前方左右各90°理解，不是镜头视场角180°。
|
||||
> 原方案备份：AI桌面陪伴助手方案.v1备份.md。本版指标为拟定目标，不是已测性能。
|
||||
|
||||
## 1. 最终形态
|
||||
## 1. 范围与待讨论事项
|
||||
|
||||
一个桌面设备，能：
|
||||
第一版做好本地中文语音、屏幕表情、按用户隔离的记忆；同一轮开发加入多人脸跟踪、轮流交互和显式身份切换。录入式人脸识别作为可关闭的试验功能，实测达标后用于身份建议；重叠说话分离、可靠声纹认人不作为首版要求。视觉问答和米家后续加入。
|
||||
|
||||
- **听** — 实时语音输入（唤醒、STT、打断）
|
||||
- **说** — 文转语音回复
|
||||
- **看** — 摄像头视觉理解
|
||||
- **记住** — 跨会话长期记忆
|
||||
- **控** — 控制智能家居（米家）
|
||||
- **动** — 小屏幕 + 电机云台，"转身面向使用者"
|
||||
|
||||
## 2. 核心架构分叉（已定）
|
||||
|
||||
| 决策点 | 结论 | 理由 |
|
||||
| 项目 | 状态/建议 | 影响 |
|
||||
|---|---|---|
|
||||
| 模型运行 | **云端 API**（Claude 系列） | 前期倾向云端，能力强、上手快；本地无 GPU 需求 |
|
||||
| 智能家居 | **倾向 Home Assistant + `Xiaomi Miot Auto`** | 统一接口控米家、可扩展；备选 `python-miio` 跑 demo |
|
||||
| 记忆 | 需**自建**向量库 + 长期摘要 | pipecat 不内置记忆 |
|
||||
| 屏幕连接 | **不用 HDMI，屏接 ESP32(SPI)** | 屏和电机同属"头部 MCU"，一体走 UART，线缆少、延迟低 |
|
||||
| 摄像头 | **单目 USB 1080p，不需要双目** | 只要方向不要距离，双目深度能力用不上 |
|
||||
| 主机 | 已有 N5095 / 16G，复用，不追加主机/GPU | 当前规划基础 |
|
||||
| 使用人数 | 本人使用为主，同时考虑多人扩展 | 首版基础多人，身份与会话从一开始分离 |
|
||||
| 新增预算 | 用户暂未设上限，先看选型；分阶段购买 | 音频优先，其次屏幕，再机械 |
|
||||
| 操作系统、现有外设 | 已确认Ubuntu；麦克风、音箱、屏幕、摄像头都没有 | 需采购；P0仍需确认Ubuntu版本和USB接口 |
|
||||
| 使用距离 | 待确认；暂以桌面约0.5～2米作为测试设计假设 | 不能当作已确认需求或性能保证 |
|
||||
| 屏幕 | 用户要求不用太大，原型沿用1.28英寸圆屏，显示表情和短状态 | 暂不扩大屏幕 |
|
||||
| 摄像头旋转 | 水平可用总行程至少180°，正前方左右各90° | 优先屏幕与摄像头共用一轴头部，麦克风固定底座 |
|
||||
| 模型及月费 | DeepSeek V4.1 Flash API；中文STT/TTS本地优先；云端语音仅为可选后备 | 本地速度实测；月费主要来自LLM/按需视觉 |
|
||||
| 米家设备 | 到扩展阶段收集型号、地区、网关/HA情况 | 集成与采购选择 |
|
||||
| 结构 | 屏幕/摄像头到货后称重，确认加工条件 | 电机、支架、电源 |
|
||||
|
||||
## 3. 硬件分工
|
||||
## 2. 总体架构
|
||||
|
||||
```
|
||||
N5095 (16G) "AI 大脑"
|
||||
pipecat + vision-agents
|
||||
听(DoA+STT) / 说(TTS) / 看(vision)
|
||||
朝向融合(人脸 + 声源DoA)
|
||||
──► 云端 LLM (Claude)
|
||||
│ UART 串口
|
||||
▼
|
||||
ESP32 "头部 MCU"
|
||||
├─ SPI → 圆屏 GC9A01（表情/内容）
|
||||
└─ PWM → 电机云台（PID 跟随）
|
||||
收指令, 本地渲染表情
|
||||
```text
|
||||
USB 麦克风阵列（固定底座） ──处理后音频、DoA──┐
|
||||
USB 摄像头（随头部转动） ──本地图像───────────┤
|
||||
▼
|
||||
N5095 / 16G
|
||||
会话状态机 + Pipecat：本地VAD / STT → DeepSeek API → 本地分句TTS
|
||||
TTS → 阵列 USB 播放端点 → 阵列音频输出 → 有源音箱
|
||||
本地人脸检测 / 目标锁定 → 角度控制（不依赖LLM响应）
|
||||
SQLite 记忆 / 受限工具调用 / 日志与故障恢复
|
||||
│ USB 串口，初始115200
|
||||
▼
|
||||
ESP32：本地表情、运动轨迹、限位、心跳超时处理
|
||||
├─ SPI → GC9A01屏幕
|
||||
└─ 控制信号 → 一轴执行器（独立合适供电支路）
|
||||
```
|
||||
|
||||
### 硬件 BOM
|
||||
- Pipecat作为唯一会话管线框架；本地音频已有示例，系统音频依赖仍需验证。[官方示例](https://github.com/pipecat-ai/pipecat/blob/main/examples/README.md)
|
||||
- 不叠加Vision Agents：它是Stream的独立框架，不是Pipecat官方扩展。人脸检测另选轻量本地模型。[项目官方仓库](https://github.com/GetStream/vision-agents)
|
||||
- STT/TTS采用本地可替换适配器，LLM使用DeepSeek V4.1 Flash。官方2026-09-10公告指定API模型名为`deepseek-flash`；这是可更新别名，实施时记录实际版本并做流式/工具调用验证。[官方公告](https://deepseek.com/news/deepseek-v4-1-flash/)
|
||||
- 视觉跟随先试640×480、5～10fps，按CPU、温度和延迟调整，未承诺该帧率已可达到。视觉问答按请求抓拍和缩放上传，不持续发送视频。
|
||||
- CPU标称TDP不能当整机常开功耗；实际插座功率、风扇噪声、温度在原型阶段测量。
|
||||
|
||||
| 模块 | 选型 | 接法 | 备注 |
|
||||
### 视频采集与框架边界
|
||||
|
||||
- Ubuntu由单一CameraService通过OpenCV/V4L2打开摄像头，维护带单调时间戳的最新帧；检测、身份候选和视觉问答共享采集源，不分别抢占设备。
|
||||
- 本地检测以低分辨率/限帧消费最新画面，积压时丢旧帧；按需问答读取足够清晰的新帧并缩放编码。必要时从较高分辨率采集再降采样，实际USB带宽和解码负载需测试。
|
||||
- Pipecat通过自定义适配器接入图像帧/取图工具。模型支持图像不等于当前Pipecat适配器已支持该模型的图像格式；P0补测纯文本流式、图片输入、工具调用、取消/超时四条路径。图像不通过时先修适配，不因此更换整套框架。[Pipecat DeepSeek服务](https://docs.pipecat.ai/api-reference/server/services/llm/deepseek)
|
||||
- 图像请求带request_id、拍摄时间和会话轮次，过期帧拒绝使用，图片不无限留在对话历史中。摄像头拔出后禁用视觉，语音保持可用。
|
||||
- 音频回调只做轻量读写；识别、合成和视觉推理在受控工作线程/进程执行，不能阻塞会话事件循环。各队列有限长，TTS限制预生成量。
|
||||
|
||||
## 3. 实施阶段与验收
|
||||
|
||||
阶段通过后再扩大范围，不预先给出未经验证的固定工期。
|
||||
|
||||
| 阶段 | 实施内容 | 拟定完成标准 | 硬件依赖 |
|
||||
|---|---|---|---|
|
||||
| 算力 | 闲置 N5095 / 16G | — | 云端 API，本地无 GPU 需求，15W 低功耗适合常开 |
|
||||
| 麦克风 | **硬件 DoA 阵列**（XMOS XVF3510/3610 类） | USB | 输出"角度 + 干净波束音频"，对 CPU 负担小；比裸麦阵 + 软件算法省事 |
|
||||
| 屏幕 | SPI 圆屏 GC9A01（或方屏 ST7789） | 接 ESP32 | 本地渲表情，不走 HDMI |
|
||||
| 电机云台 | 舵机 MG996R/DS3218 或步进(NEMA14+TMC2209) | 接 ESP32 | PID 跟随；避开南 SG90 小舵机（屏有重量会抖/发热） |
|
||||
| 头部 MCU | ESP32（板载 USB 转串口，如 DevKit） | — | 屏 + 电机 + UART 收指令 |
|
||||
| 摄像头 | **USB 1080p 单目**（十余~数十元） | USB → N5095 | AI 视觉主路，直连低延迟 |
|
||||
| P0 环境与服务 | 盘点Ubuntu版本/USB；固定依赖；本地STT/TTS基准及DeepSeek请求 | 样例音频/文本先测试；设备到货后10次录放测试；记录RTF、首音延迟、CPU和内存 | 无外设可先测文件；实时测试待音频套件 |
|
||||
| P1 基础语音 | 按键启动；流式回复；停止按钮；超时提示 | 20轮固定中文用例至少18轮完成；短问答结束到首段有声回复，目标P50≤2秒、P95≤4秒 | 耳麦或音频套件 |
|
||||
| P2 外放与表情 | AEC、打断、唤醒；听/想/说/离线/静音表情 | 指定距离音量下20次打断至少18次成功；检测到有效用户语音至停播目标≤300ms；30分钟外放无自我触发；运行2小时稳定 | 阵列、音箱、MCU、屏幕 |
|
||||
| P3 多用户记忆 | 用户档案、显式切换、偏好/摘要/修改/遗忘 | 两个用户同一问题得到各自偏好；未知用户无私人记忆；重启保留、更正/删除有效 | 无新增 |
|
||||
| P4 一轴转头 | 静态DoA/人脸验证，再接电机；锁定和限位 | 左/中/右各10次唤醒至少27次转向正确区域；轻微移动不频繁摆动；断联/重启不撞限位；运动时重复P2测试 | 摄像头、电机、支架、供电 |
|
||||
| P4a 基础多人/身份试验 | 2～3张脸跟踪；轮流发言；可选录入式人脸识别 | 20次轮流唤醒至少18次选中正确目标；同方向/交叉/遮挡时允许拒判；未知人、身份切换不得串记忆 | 同一阵列和单目摄像头，无新增专用硬件 |
|
||||
| P5 扩展 | 按需视觉问答；HA接一盏灯 | 检查10次视觉请求；开关灯、离线、超时均反馈真实结果 | 现有米家设备优先 |
|
||||
|
||||
## 4. N5095 ↔ ESP32 通信（选型）
|
||||
验收记录距离、背景声音、播放音量、网络、模型版本、样本数。目标用于定位瓶颈，不保证所有环境都达到。耳麦通过不能代替远场外放验收。
|
||||
|
||||
- **介质**: USB 转 TTL / ESP32 板载串口 → N5095 呈现为 `/dev/ttyUSB0`，波特率 115200
|
||||
- **主通道**: 串口 UART（低延迟、可靠、共地不出错）
|
||||
- **数据方向**:
|
||||
- N5095 → ESP32: 表情 / 转向 / 文字 `{"t":"face","face":"happy","dir":30,"text":"..."}`
|
||||
- ESP32 → N5095: 完成确认 / 告警 `{"t":"ack","done":true}`
|
||||
- **帧协议**: 帧式文本（`[SOF][长度][JSON][校验][EOF]`），处理粘包/断包
|
||||
- **备选**: WiFi/MQTT 做旁路（多设备调度时），HC-05 蓝牙做无线调试
|
||||
P2的30分钟/2小时测试仅是初步门槛，不能证明长期稳定。阶段通过后做一次正常音量下至少8小时运行：记录误唤醒次数、内存增长、音频欠载、重连及温度。P4a把“转对人”和“认对身份”分开统计，额外报告误认、拒判、切换次数，不用总成功率掩盖串身份。测试人数不足时，多用户记忆可用模拟身份测试，人脸/发言者匹配则明确标记未实测。
|
||||
|
||||
> 关键原则: 串口是字节流不是消息流，两侧都要实现按帧切包。
|
||||
## 4. 分批采购清单
|
||||
|
||||
## 5. 摄像头决策
|
||||
本表未报价：用户预算尚未确定，具体SKU和商家现价需核价。已确认麦克风、音箱、屏幕、摄像头均需购买；MCU和线材是否已有待核对。
|
||||
|
||||
- **主力**: 单目 USB 1080p 直连 N5095，vision-agents 直接吞流
|
||||
- **不要双目**: 只需"人在画面哪个方向"（人脸框偏移换算角度），不需要深度/距离
|
||||
- 何时才上双目/深度相机: 设备要自己移动避障、精确保持跟随距离、理解三维结构时才需要；桌面固定伴侣不做
|
||||
- **ESP32-CAM（可选副路）**: 能接但只当配角（如俯视监控/趣味镜）；主力视觉别用它——它走 WiFi 传 JPEG，多一跳压缩+WiFi，延迟和 CPU 开销都大，且会跟屏/电机抢 ESP32 资源
|
||||
### 第一批：可先购买的通用原型件
|
||||
|
||||
## 6. 朝向融合（核心算法，让它"追着你"）
|
||||
| 物品 | 数量 | 购买规格 | 备注 |
|
||||
|---|---:|---|---|
|
||||
| ESP32-S3开发板 | 1 | 优先N8R8等带PSRAM型号，已焊2.54mm排针，有原理图/引脚表/USB下载说明 | PSRAM便于放素材，简单表情并非必须 |
|
||||
| GC9A01圆屏模块 | 1 | 1.28英寸240×240、SPI、3.3V逻辑；明确供电和背光接法；已焊排针 | 不买裸屏FPC；当前沿用原方案圆屏形态 |
|
||||
| USB数据线 | 按缺口 | 匹配板卡插口，明确支持数据，原型约0.5～1米 | 阵列和摄像头线按套装补齐 |
|
||||
| 杜邦线/面包板/绝缘固定件 | 1套 | 与排针匹配 | 只用于逻辑低电流，不走电机大电流 |
|
||||
| 瞬时按键 | 2 | 普通低压按键，接空闲GPIO | 会话停止、软件静音；不宣称物理断麦 |
|
||||
|
||||
两个信号源都可以给朝向：
|
||||
如更想减少接线，可以用ESP32-S3带1.28英寸屏幕的一体板替代前两项，不能重复买。须先核实外露GPIO、接插件间距和电机控制引脚。一体板不同SKU不能混用引脚表。[Waveshare官方参考](https://www.waveshare.com/product/esp32-s3-lcd-1.28.htm)
|
||||
|
||||
| 信号源 | 何时为准 |
|
||||
|---|---|
|
||||
| 摄像头人脸检测（vision-agents） | 看见人脸 → 以人脸为准 |
|
||||
| 麦克风 DoA | 看不见人脸但听到声音 → 以 DoA 为准 |
|
||||
### 同期优先核价：音频套件
|
||||
|
||||
- 融合 + 卡尔曼/低通滤波平滑云台转向，避免抽搐
|
||||
- 这就是 vision-agents 不只是"能看"的原因
|
||||
| 物品 | 数量 | 优先候选/要求 | 下单条件 |
|
||||
|---|---:|---|---|
|
||||
| USB麦克风阵列 | 1 | Seeed reSpeaker XVF3800 USB 4-Mic Array成品板 | 核对具体SKU、USB固件、目标系统、DoA例程、录放音通道、输出与附件；报价合适再买 |
|
||||
| 有源小音箱 | 1套 | 需新购；3.5mm模拟输入，体积小，合适独立供电 | 与阵列输出匹配；初期不选只能走USB音频/蓝牙的音箱 |
|
||||
| 音频线 | 按缺口 | 匹配两端的3.5mm音频线 | 查套装是否自带 |
|
||||
|
||||
## 7. 记忆方案（自建向量库，选型已定）
|
||||
阵列官方资料列出USB音频、DoA主机控制、可接耳机/有源音箱的AUX输出。采购成品板，不能仅凭XMOS芯片名替代。[Seeed官方文档](https://wiki.seeedstudio.com/respeaker_xvf3800_introduction/)
|
||||
|
||||
**核心原理**：向量库不是把记忆直接塞给 LLM，而是"检索最相关片段、只注入少量"：
|
||||
拟定路径：N5095的TTS → 阵列USB播放端点 → AUX → 有源音箱。AEC需要实际播放参考；同一板卡也要验证固件/通道配置，不能假定接上即成功。[XMOS官方指南](https://www.xmos.com/documentation/XM-014888-PC/pdf/xvf3800_user_guide_v3.2.1.pdf)
|
||||
|
||||
```
|
||||
对话时:
|
||||
当前输入 ──► 转向量 ──► 检索最相关 3~5 段 ──► 仅这几段(数百~2k token)拼进 prompt
|
||||
```
|
||||
不为了阵列额外购买XIAO ESP32S3，主机直接接USB即可。最终内置喇叭/功放留到结构阶段，按接口、电压、阻抗和功率匹配。
|
||||
|
||||
> 做对就省 token（按需挑），不是把历史全塞进去。每次注入 500~2000 token 级别。
|
||||
### 第二批：摄像头
|
||||
|
||||
### 选型
|
||||
- 需新购普通USB UVC单目摄像头1个，支持1080p及低分辨率模式。为早测多人/身份，可与第一批一起买；无需增加第二台摄像头。
|
||||
- 优先小巧轻便、可固定、柔软线缆、有视场角资料的型号；近距离物品问答需核对最近对焦距离。
|
||||
- 摄像头随头部水平旋转，可用总行程至少180°（左右各90°）。这是机械旋转范围，不要求购买180°鱼眼镜头。单摄像头只覆盖当前朝向的视野，转动可依次查看不同方向，不能同时看全180°范围。
|
||||
- 首版多人按当前视野内、轮流发言验证。镜头选型兼顾多人覆盖与脸部像素，过广视角会让远处脸变小。
|
||||
- 不需要双目/深度相机和ESP32-CAM。摄像头不影响P0～P3先行。
|
||||
|
||||
| 层 | 方案 | 说明 |
|
||||
### 第三批：机械结构确定后购买
|
||||
|
||||
| 物品 | 为什么暂缓 | 解锁条件 |
|
||||
|---|---|---|
|
||||
| 记忆管理层 | **Mem0** | 专门做 AI 长期记忆的开源库，自带提取/检索/存储一条龙，推荐 |
|
||||
| 向量存储 | **Chroma**（嵌入式，零运维）| 起步最省事；量大再上 Qdrant/Milvus |
|
||||
| embedding | 云端 embedding API | 便宜；起步够用 |
|
||||
| 兜底（更轻） | 纯文本 MEMORY.md / SQLite | 记忆量小时连向量库都不必上 |
|
||||
| 舵机/步进 | 已要求可用行程≥180°，重量/重心/噪声未知，暂不锁MG996R/DS3218 | 称重后选型；额定/机械行程要有软限位余量，实测可用行程≥180° |
|
||||
| 电机电源/降压 | 电压及启动/堵转电流依赖电机 | 数据表确认，峰值留余量 |
|
||||
| 转台/轴承/支架/外壳 | 安装孔、重心、线缆弯曲需配合 | 原型尺寸确定 |
|
||||
| 步进驱动、回零开关、编码器 | 取决于执行器及是否需要实测位置 | 电机方案确定 |
|
||||
| USB Hub | 主机可能已有足够接口 | P0盘点确认不足 |
|
||||
| 米家网关/新设备 | 兼容性依型号地区而异 | 现有设备验证后再定 |
|
||||
|
||||
推荐：**Mem0（自带 Chroma 支持）+ 云端 embedding**，pip 安装配 API key 即可跑。
|
||||
当前不采购：新主机、GPU、双目相机、HC-05蓝牙、第二块视觉MCU、电池系统。
|
||||
|
||||
### token 消耗
|
||||
## 5. 音频与陪伴行为
|
||||
|
||||
- ✅ 只读相关片段 → 省，不会因记忆多而线性暴涨
|
||||
- ❌ 把整个记忆库/全部历史塞进上下文 → 必炸，别这么用
|
||||
- 检索端 embedding 模型很便宜
|
||||
### 本地STT/TTS优先方案
|
||||
|
||||
### 存储空间
|
||||
STT是语音转文字，TTS是文字转语音，都不要求云API。N5095负责本地推理，DeepSeek负责理解和生成回复；Pipecat编排这些组件，不要求每个组件都上云。
|
||||
|
||||
- 向量式存储，个人千条级记忆：**几十 MB**，N5095 磁盘随意放，完全不用担心
|
||||
| 模块 | 首选试验 | 备选与限制 |
|
||||
|---|---|---|
|
||||
| VAD | 本地轻量VAD | 单独处理唤醒和说完判断 |
|
||||
| 唤醒 | sherpa-onnx中文关键词检测作为候选 | 单独模型/词表，用户确定称呼后调阈值；普通STT不会自动等于唤醒引擎 |
|
||||
| STT | sherpa-onnx中文流式Zipformer模型 | 比较量化SenseVoiceSmall+VAD分段；后者不是原生流式识别，不混淆分段处理与流式中间结果 |
|
||||
| TTS | sherpa-onnx中文VITS，例如aishell3 | 对比中文Piper/Melo模型的速度和听感；先固定音色，不做克隆 |
|
||||
| LLM | DeepSeek V4.1 Flash API | 本地语音不等于整个助手离线：智能回复仍依赖网络 |
|
||||
|
||||
## 8. 技术栈分工（pipecat 管什么）
|
||||
[sherpa-onnx官方功能](https://k2-fsa.github.io/sherpa/intro.html)、[SenseVoice模型说明](https://k2-fsa.github.io/sherpa/onnx/sense-voice/pretrained.html)、[中文VITS模型](https://k2-fsa.github.io/sherpa/onnx/tts/pretrained_models/vits.html)。以上说明模型/运行时支持，不构成N5095性能保证。
|
||||
|
||||
- **pipecat**: 听(STT) / 说(TTS) / 视觉输入 → 云端 LLM 的实时管线 + 打断处理
|
||||
- **vision-agents**: 视觉 agent 能力（人脸检测、看摄像头/屏幕）—— pipecat 团队出品，向下兼容
|
||||
- **需自己在 pipecat 之外实现的模块**:
|
||||
1. 表情渲染 App（发指令给 ESP32，或 ESP32 端帮渲）
|
||||
2. 云台控制 App（朝向融合 → 角度命令走 UART）
|
||||
3. 记忆库（**Mem0 + Chroma**，见方案 7 节）
|
||||
4. 米家控制（HA REST API 或 python-miio）
|
||||
P0测试10～20条不同长度中文，覆盖数字、日期、中英混读。记录STT识别错误、语音结束后等待时间、TTS首段耗时和RTF（生成/处理耗时除以音频时长，低于1表示平均快于实时）。音频与视觉并发时重测，限制推理线程和视觉帧率，避免CPU争抢。
|
||||
|
||||
> pipecat/vision-agents 不碰屏幕和电机，这两块是外部模块，通过 Pipecat 会话/回调接入。
|
||||
TTS按语义短句合成并播放，不把整段一次合成称为原生流式；分句仍要测首音等待、接句停顿及取消响应。本地效果不达标时先调整模型/线程/分句，再讨论是否开启云端后备，不自动发送音频到第三方。
|
||||
|
||||
## 9. 下一步（待推进）
|
||||
- 本地唤醒引擎保持工作；闲置时暂停完整识别、降低视觉频率。保留短时内存音频预卷（初始0.5～1秒）避免唤醒后吞掉指令开头，静音时清除缓冲。[关键词检测官方文档](https://k2-fsa.github.io/sherpa/onnx/kws/index.html)
|
||||
- 活跃会话内允许免唤醒接续，初始闲置超时20秒后回到待机，参数可调。多人时其他人的普通谈话不应自动抢占；以唤醒/显式切换为主要入口。
|
||||
- 记录阵列实际采样率、通道和采样格式，STT/TTS边界显式重采样；避免把原始麦克风/回放参考通道当成处理后语音。Ubuntu固定设备标识和录放音路由，不依赖重启后会变化的默认声卡序号。
|
||||
- DeepSeek输出区分最终回答、思考内容、工具调用与工具结果，只将面向用户的回答交给TTS；数字/日期/单位和Markdown做轻量朗读归一化。
|
||||
|
||||
1. 先在 N5095 跑通 pipecat"听↔云↔说"闭环（普通麦克风，不接硬件）
|
||||
2. 调研并落地: pipecat / vision-agents 项目部署方式, Home Assistant + Xiaomi Miot Auto 接米家
|
||||
3. 再逐步接视觉 → 记忆 → 朝向 → 硬件
|
||||
- P1按键启动，P2再加唤醒。语音活动检测、说完判断、唤醒是不同环节。
|
||||
- 打断时取消旧回复生成、TTS和待播缓冲，丢弃旧轮次迟到结果，不能暂停后继续放旧回复。
|
||||
- 分别测安静、设备外放、背景音乐、风扇噪声；P4加入运动噪声，装壳后重测。
|
||||
- 默认简短自然回复；等待时及时更新表情，长回复按语义分段播放。
|
||||
- 明确待机、在听、思考、说话、静音、离线状态。专注/夜间默认不主动开口，主动问候后续再加。
|
||||
- 网络失败给简短提示，本地按键、静音和屏幕继续工作，不反复播旧回复。
|
||||
- 麦克风、音箱、电机尽量机械隔离；软件静音和真实物理断麦需明确区分。
|
||||
|
||||
---
|
||||
## 6. 朝向与机械
|
||||
|
||||
*第 1~7 节为架构决策，第 8 节为推进顺序。硬件选型可在采购前复核。*
|
||||
DoA是声源来向，不代表身份或距离。阵列固定底座，摄像头随头部转动。
|
||||
|
||||
状态：待机 → 有效唤醒 → 可靠DoA粗转 → 匹配人脸 → 锁定 → 丢失短暂保持 → 超时待机。多人先按轮流发言处理；同方向多人或重叠说话时保持目标/请求轮流，不凭DoA猜身份。
|
||||
|
||||
### 多人能力与避免返工
|
||||
|
||||
- 基础多人：同画面维护多个临时track_id，记录位置和最后出现时间；用带时间戳的DoA与人脸位置关联当前发言目标，设置切换滞后。走位/遮挡后track_id可能变化，不能充当永久身份。
|
||||
- 读取DoA时核对固件、波束选择和单位。XVF3800可返回多个波束角度，它们不是“几个人的身份/独立语音”；不要直接把第一个角度当发言者。优先用与当前处理后音频对应的选中波束，查不到可靠对应时允许拒判。[官方主机控制代码](https://github.com/respeaker/reSpeaker_XVF3800_USB_4MIC_ARRAY/blob/master/python_control/xvf_host.py)
|
||||
- 首版可靠身份入口：手动/对话确认切换到已建档的user_id；无法确认时使用unknown/guest。看到熟人不等于确认他正在说话。
|
||||
- 显式报名字用于个性化档案选择，不是身份认证，不能据此解锁敏感信息或权限。信任等级与user_id分开，未来增加认证时不改普通偏好存储。
|
||||
- 可选人脸试验：OpenCV YuNet检测+SFace特征作为候选，需用户主动录入、相似度阈值和未知人拒判。低频识别，平时跟踪；不用于门锁/支付或敏感身份认证。[OpenCV官方教程](https://docs.opencv.org/5.0/tutorials/dnn/dnn_face/dnn_face.html)
|
||||
- 注册特征本地保存，可查看和删除；识别不确定时不读取/写入私人记忆。群体会话默认仅共享明确公开的上下文，不主动播报私密记录。
|
||||
- 预留IdentityProvider接口：输入时间戳、track_id、候选身份、置信度与来源；输出确认的user_id或unknown。后续声纹模块可接入此接口，不改记忆表结构。
|
||||
- 声纹认人、声音与人脸可靠绑定、重叠语音分离属于更高难度阶段，不承诺通过增加一块阵列即可解决。第一版不做全场多人同时自由插话。
|
||||
|
||||
- 调试候选：3～5°死区、丢失保持1～2秒；速度/加速度实机调节。
|
||||
- 坐标约定：从设备视角向右为正。标定阵列零点、摄像头中心、电机零点；统一DoA单位和方向。
|
||||
- 人脸像素位置经相机内参/标定换算成相对角度，再加头部角度估计，不能把像素直接当绝对角度。
|
||||
- 普通位置舵机先做平滑目标角度，不默认再加内环PID；无反馈时只有估计位置。
|
||||
- 摄像头与麦克风有位置偏移，近距离DoA和画面方位不完全重合；先粗转，再以视觉纠偏。运动过程中按时间戳使用对应角度估计，避免拿旧图配新角度。无反馈舵机的首版身份匹配优先在稳定停转后进行。
|
||||
- 步进需独立驱动器、明确STEP/DIR等接口，补回零/失步/软限位。
|
||||
- 只做左右一轴，用户要求摄像头可用总行程至少180°；初始工作范围设为[-90°, +90°]，屏幕与摄像头共用转动头部，麦克风固定底座。不要求连续360°旋转。
|
||||
- 执行器实际机械行程须大于工作范围，以留软/硬限位余量；采购候选可考察标称270°的位置舵机，但型号、真实行程及噪声仍待核对。不能把普通标称180°舵机两端硬顶当作已满足要求，也不选无角度定位反馈的连续旋转舵机来直接代替位置舵机。
|
||||
- 转轴/轴承承担结构负载；USB摄像头线、屏幕/MCU线缆在左右端点均要有弯曲余量，避免拉扯插头。有限180°往返先用柔软线缆和固定应力释放，不把滑环列为必需采购件。
|
||||
- P4增加行程验收：实测摄像头左右端点至少相差180°，端点不碰撞、不拉线；低速往返100次检查线缆、USB掉线、抖动和供电。上电及重连仍须受限速和限位约束。
|
||||
- MCU独立限位和断联停止；失联先停止更新轨迹，保持/卸力按结构实测，避免盲目断电造成坠落。
|
||||
- 电机独立合适供电支路并正确共地，选合适线径/端子/去耦，不由ESP32板载电源或面包板供大电流。
|
||||
|
||||
## 7. 串口协议与恢复
|
||||
|
||||
先用UTF-8单行JSON、换行分帧，字符串换行由JSON转义。115200起步。Linux可能ttyUSB/ttyACM，Windows为COM，使用可配置稳定设备标识。
|
||||
|
||||
```json
|
||||
{"v":1,"seq":101,"type":"expression","state":"listening"}
|
||||
{"v":1,"seq":102,"type":"motion","yaw_deg":20,"max_speed_deg_s":25}
|
||||
{"v":1,"seq":102,"type":"ack","status":"accepted"}
|
||||
```
|
||||
|
||||
- 表情和运动分开；转向目标最新值优先，不排队执行过时动作。
|
||||
- 定义版本、字段范围、最大帧长（初始1KB）、坏帧丢弃和超时恢复。
|
||||
- seq关联请求与确认；重试不能重复动作。accepted仅表示收到，无传感器不能报告实测已到位。
|
||||
- 心跳500ms、失联2秒触发本地停止作为初始候选参数，实测后定稿。
|
||||
- MCU重启发hello/能力信息，重连恢复当前状态，不回放历史运动。
|
||||
- 字体和表情素材本地存储，串口不传全屏视频；WiFi/MQTT旁路暂不做。
|
||||
|
||||
## 8. 记忆、费用与数据
|
||||
|
||||
P3用SQLite，Mem0和向量库不是前置条件。从建表起就包含users、sessions、memories；记忆带owner_user_id、scope（private/shared）、来源会话/轮次、时间和确认状态。查询和写入均强制身份过滤，未知身份只用访客临时上下文。视觉track_id、会话session_id、永久user_id分开。
|
||||
|
||||
| 类型 | 保存策略 |
|
||||
|---|---|
|
||||
| 明确偏好 | 结构化键值，来源、确认状态、更新时间，新值替换旧值 |
|
||||
| 临时事项 | 带时间与过期规则；记住事项不等于实现提醒调度 |
|
||||
| 对话摘要 | 限长、按需检索、可清除，不默认永久保存逐字稿 |
|
||||
|
||||
- 支持记住/修改/忘掉/查看；模型推测不当作确认事实。
|
||||
- 默认显式切换身份；人脸只提供候选，经当前发言者关联及确认后才启用对应记忆。切换身份清理上一人的私有检索上下文；异步任务绑定创建时的user_id/session_id，避免迟到结果写入新用户。
|
||||
- 删除同时覆盖会话上下文、摘要和未来索引，防止删库后仍引用。
|
||||
- 回复后异步写记忆，检索有超时；记忆失败不阻塞对话。
|
||||
- 真实使用中检索不足再评估Mem0 + Chroma，支持不代表无需配置测试。[Mem0官方文档](https://docs.mem0.ai/components/vectordbs/dbs/chroma)
|
||||
- 本地STT/TTS记录耗时与资源，不产生语音API调用费；统计LLM/按需视觉及未来云端后备费用，按实际日用量估月费并讨论上限。
|
||||
- 默认不存原始音视频；视觉按需上传。密钥保存在本机配置，不写日志；提供静音和相机关闭入口。
|
||||
|
||||
## 9. 米家接入
|
||||
|
||||
P5通过Home Assistant统一调用。按实际设备比较官方Xiaomi Home和Xiaomi Miot Auto，核实地区、网关、本地/云端路径，不提前采购网关。[小米官方集成](https://github.com/XiaoMi/ha_xiaomi_home)
|
||||
|
||||
先接一盏现有灯：意图 → 工具/实体白名单 → 参数校验 → HA执行 → 状态确认 → 回复。请求受理和设备已改变分开描述，超时明确未确认。高风险设备不默认加入。
|
||||
|
||||
工具执行与语音回复生命周期分开：用户打断播报不意味着已发出的设备操作被撤销。每次动作保留执行ID和状态；超时先查状态，不盲目重试；优先使用“设为开/关”而非“切换”以降低重复执行风险。摄像头中的文字和检索记忆作为数据，不能自行扩大工具权限。
|
||||
|
||||
## 10. 运行维护与当前下一步
|
||||
|
||||
- 固定依赖版本，记录板卡SKU、固件、通道、引脚及接线图。
|
||||
- Ubuntu优先先以普通用户的本机环境打通音频/USB，再确定常驻部署，暂不增加容器设备映射。核对Ubuntu版本、Python兼容性和CPU指令要求；模型文件授权与运行时授权分别记录。
|
||||
- 日志保存耗时、错误、费用、连接事件并轮转，不默认保存完整私人对话。
|
||||
- P2后配置开机启动、异常重启、音频/串口重连，测试拔插、断网、主机重启恢复。
|
||||
- 已确认Ubuntu和四类缺失外设，不再重复询问。继续确认Ubuntu版本、USB接口和使用距离；按清单核价音频/屏幕/摄像头。基础多人和多用户数据结构纳入本次开发，自动身份能力以实测为准。
|
||||
- 不等待上述答案也能先推进表情和协议设计，通用原型件按缺口采购。
|
||||
- 本次只更新规划和采购条件；未安装依赖、重装系统、购买硬件或做实机测试。
|
||||
|
||||
Reference in New Issue
Block a user