第五周（2026-08-03 ~ 2026-08-07）

总结：

1. SG2002 上完成语音识别：不可行（×）

   SG2002 侧已经验证过轻量关键词识别路线，但要做完整语音识别转指令，算力、音频前端和模型部署成本都不合适，因此不作为当前主线。

2. RK3588 上完成语音识别转指令：已验证

   当前已经能在 RK3588 上跑通语音识别链路。实际效果是，把录音切成约 2s 一段后，识别结果已经可以直接做关键词匹配，转换成“前进、后退、左转、右转”等控制指令。

   后续机器人控制部分与我无关，只需要把这一路识别输出对接给控制同学即可。

   DEMO：把控制部分对接完就有了。

3. Ascend 310B 上语音识别转指令：SD 卡里已有流程基础，待端到端验证

   SD 卡里已经有两部分：一部分是 SenseVoice OM 模型推理，另一部分是开发板录音样例。也就是说“录音”和“模型推理”都已经有基础，下一步要把录音、特征处理、模型推理、文本解码和关键词转指令串成完整链路，并在 310B 板端验证。

下一步

1. 验证 Ascend 310B 上录音到指令的端到端链路，并与相关人员对接语音控制。
2. 考虑到 SmolVLA 可能已经训练完成，尝试在 Ascend 310B 上进行推理。

细节

SG2002 结论

SG2002 上之前验证过关键词识别（KWS）方向，包括中文方向命令、DS-CNN、小模型导出和板端推理。该路线适合做固定短词检测，但不适合直接承担完整 SenseVoice 这类语音识别任务。

关于 SenseVoice 是否能在 SG2002 上跑，结论是：理论上可以尝试，但不适合作为这次机器人语音控制的主线。

原因很简单：SG2002 有小型 NPU，但内存只有 256MB。SenseVoiceSmall 这类完整语音识别模型本身就很大，直接跑会把内存和工程复杂度都顶满。即使用量化模型，也还要留空间给系统、音频处理、运行时和中间结果，因此稳定性风险比较高。

网上有些“ESP32 跑 SenseVoice”的案例不能直接类比。很多案例其实是 ESP32 只负责录音，真正识别在电脑、服务器、手机或外接 NPU 上完成；还有一些只是做唤醒词或简单关键词，不是完整语音识别。SG2002 比 ESP32 更适合本地小模型推理，但仍然不适合硬跑完整 SenseVoice。

如果一定要在 SG2002 上量化 SenseVoice，推荐路线也不是直接拿普通 ONNX INT8 文件跑，而是：

1. 固定输入长度，例如固定成 5s 或 10s 音频片段。
2. 在板外先把音频转成模型需要的特征输入。
3. 用 TPU-MLIR 先做 BF16 基线，确认模型能编译、能跑。
4. 再用真实业务音频做 INT8 校准，生成 cvimodel。
5. 如果 INT8 误差太大，再把敏感层保留成 BF16。

但这条路工程量大，而且最终效果未必比 RK3588 / Ascend 310B 更好，所以本周不建议继续作为主线。

如果目标只是识别“左、右、前、后”，更推荐走小模型或模板匹配：

1. 用“左转、右转、前进、后退、停止”这类长一点的词，不建议只用“左、右、前、后”单字。单字太短，小孩发音又不稳定，很容易误判。
2. 如果愿意训练，就训练一个小的六分类模型：左转、右转、前进、后退、其他、静音。
3. 如果不想训练模型，可以用录音模板匹配：每个指令录 10-30 条模板，运行时提取音频特征，和模板比相似度，足够像才触发，否则拒绝。
4. 小孩会乱说话，所以一定要有“拒绝执行”的机制。不能让模型在所有声音里硬选一个方向。

比较稳的产品交互应该是：

按键或唤醒词启动
  -> 只在几秒内听方向指令
  -> 识别到“左转/右转/前进/后退/停止”
  -> 连续确认或置信度足够高
  -> 再执行动作

这样小孩平时乱说话、唱歌、喊叫、背景电视声，都不会轻易触发机器人动作。

最终判断：

1. SG2002 不适合做完整 SenseVoice 语音识别。
2. SG2002 适合做固定方向词检测。
3. 如果不训练意图识别，最直接可用的是“录音模板匹配 + 强拒绝规则”。
4. 如果要理解自然人话，例如“小车你往左边走一下”，那就应该交给 RK3588 / Ascend 310B / 服务器上的 ASR，而不是 SG2002 本机硬做。

因此 SG2002 不再作为完整语音识别主线。

RK3588 语音识别转指令

RK3588 上使用 SenseVoice RKNN 模型完成验证。当前已经完成：

1. 下载并部署 SenseVoice RKNN 模型到 RK3588。
2. 安装并验证 RKNN Runtime、ONNX Runtime、特征提取和分词依赖。
3. 跑通离线音频识别，40s 左右样例音频可以正常输出中文文本。
4. 增加边录音边识别脚本，使用 arecord 采集 16kHz 单声道音频。
5. 定位并修复 ES8388 录音输入问题：真实麦克风输入在 Line2，而不是默认 Line1。
6. 验证录音切分后可以输出短句结果，后续可直接做关键词匹配转控制指令。

目前可用脚本在 RK3588 板端：

cd ~/Sensevoice-RK3588
./setup_mic_es8388.sh 3
python3 ./live_record_asr.py --alsa-device plughw:3,0 --chunk-seconds 2 --language auto --use-itn

其中 chunk-seconds=2 时，输出粒度更接近控制指令，可直接映射：

前进 -> forward
后退 -> back
左转 -> left
右转 -> right
停止 -> stop

后续只需要把识别文本交给控制模块做关键词匹配和动作下发。

Ascend 310B 语音识别转指令

SD 卡里实际存在两类 310B 相关内容：

1. SenseVoice OM 模型推理基准：

   /home/HwHiAiUser/voice-robot-bench/
   

2. 录音/播音样例：

   /opt/opi_test/USBAudio/
   /opt/opi_test/audio/record.sh
   

voice-robot-bench 中已有：

benchmark_ascend_om.py
sensevoice_t100.om
speech.bin
speech_lengths.bin
language.bin
textnorm.bin

其中 benchmark_ascend_om.py 已经完成 310B 上的 OM 模型加载、输入构造和 ACL 推理：

1. 加载 SenseVoice OM 模型。
2. 准备 speech、speech_lengths、language、textnorm 输入。
3. 通过 PyACL 调用 acl.mdl.execute 执行模型。
4. 输出推理耗时和 NPU 内存占用。

录音侧已有两条参考：

1. /opt/opi_test/audio/record.sh 使用 arecord 录制 48kHz PCM，并用 aplay 回放。
2. /opt/opi_test/USBAudio/main.c 使用 FFmpeg/ALSA 从 USB 麦克风录音，生成 audio.pcm。

因此 310B 上的端到端链路不是从零开始，而是需要把 SD 卡中已有的两段流程接起来：

麦克风录音
  -> 音频重采样/切片
  -> fbank/LFR/CMVN 特征
  -> speech / speech_lengths / language / textnorm 输入
  -> sensevoice_t100.om
  -> 文本解码
  -> 关键词转控制指令

当前已有模型本体推理基线：SenseVoiceSmall FP16 OM 在 310B 上单次推理约 33ms，模型本身不是瓶颈。下一步重点不是重新做模型，而是补齐录音到模型输入、模型输出到文本、文本到指令这三段胶水逻辑，并做板端真实麦克风验证。