RoboticsASRLLMTTS

基于语音对话系统的零售机器人项目

前言

这是我真正意义第一个偏向工程落地的项目。

对我来说，它不是一个简单的应用过程，更像是一次完整的学习过程。过去我主要做深度学习模型训练，而在这个项目中，ASR、LLM、TTS、WebSocket、FastAPI、Firecrawl、DuckDB、Piper 等技术，几乎都是新的知识领域。

我也逐渐意识到，在 AI 快速发展的今天，重要的不只是训练出一个模型，更是理解模型如何进入真实系统，如何和机器人、网络、音频设备以及外部服务协同工作。

项目目标

这个项目主要围绕三条链路展开：

构建 ASR-LLM-TTS 语音交互链路，支持中文、英文和泰语。

实现机器人端与服务端之间的音频、文本、TTS 和任务信息传输。

完成机器人图传、货架检测以及目标点导航能力。

其中，LLM 只负责理解用户意图，真正的机器人动作还需要经过客户端校验。

实践过程

1. 接手项目后的第一步：先跑通最小链路

接手项目时，先是对项目的源码进行复制，进一步下载好对应的模型、配置.env文件用于Firecrawl的调用和公司llm的调用

然后检查服务端状态：


curl -s http://127.0.0.1:8000/health | python3 -m json.tool

重点关注 FastAPI、WebSocket、ASR worker、LLM 服务和 TTS provider 是否处于 ready 状态。

接着登录机器人端查看日志：

journalctl -t my_daemon -n 20 -f -o cat

确认 WebSocket 已连接、音频流已建立、任务线程已启动。

之后按照下面的顺序测试：

  1. 唤醒词测试：确认机器人能识别 Alexa。
  2. ASR 测试：说一句简单的中文，确认能返回文本。
  3. LLM 测试：通过 /ai/intent 发送固定文本，确认返回合法 JSON。
  4. TTS 测试：确认服务端返回音频，机器人能够正常播放。
  5. 全链路测试：完成“唤醒、识别、理解、播报”。
  6. 导航测试：先验证目标点存在，再观察机器人是否真正到达。
  7. 图传测试：上传一张图片，检查原图、检测结果和标注图。

只有最小链路稳定后，才适合继续排查单个模块。

2. 音频尾音怎么处理

最初的音频结束判断主要依赖 RMS 静音检测，用户说完后通常还要等待5～7秒，收音延迟比较明显。

后续引入 Silero VAD，将音频切成约 32 ms 的小帧。当连续约 240 ms 被判断为静音时，结束本次录音，同时保留一小段尾部缓冲，避免截断最后一个字。

这个过程不能简单地把静音阈值改得很小，否则用户停顿时可能被误判为说话结束，句尾音节也可能被截断。比较合理的做法是设置连续静音帧数量、保留少量尾音 padding，并避免客户端和服务端重复等待。

测试报告中，使用 VAD 后平均延迟降低了约 3～4 秒。

另外，FunASR 推理被放进独立子进程中，并设置识别超时。这样即使 CUDA 或模型推理阻塞，也可以重启 ASR worker，不至于拖垮整个 FastAPI 服务。这是因为一开始就老是出现ASR卡死导致需要重启机器人端server的缘故进行的debug。

3. 服务端返回的信息处理

服务端返回的llm文本仅仅基于对话和mappoint的缓存读取生成，测试中出现胡乱下发map中不存在的point的情况。

LLM 返回的是概率性的结果，即使外层包装成 JSON，也可能出现不存在的目标点、错误的字段或错误的语言。

因此，导航结果至少要检查：意图是否合法、目标点是否存在、地图名称和版本是否一致，以及坐标是否来自可信的地图数据。

LLM 只返回目标点名称，不直接返回坐标。机器人端根据本地地图快照解析真实坐标。

如果用户说的是一个模糊目标，机器人应该先询问确认，即后续加入的confirm流程。用户确认后，才允许执行 PointTask。

4. 中英泰三语支持

三语支持实际上包含三个部分：ASR 识别当前输入语言，LLM 使用当前语言生成回复，TTS 根据语言选择对应声音模型。

当前方案中，中文和英文使用 Piper，泰语使用 Vachana TTS。不能只依赖聊天历史判断语言，否则第一次对话识别错误后，后续回复也可能持续使用错误语言。

因此，每一轮都应该重新判断当前输入语言，并将语言信息传递给 LLM 和 TTS。如果识别结果不属于中、英、泰三种语言，可以提示用户重新说，并重新唤醒机器人。

多轮对话也设置了超时，例如一分钟没有新的输入，就清空上下文，恢复初始状态。

5. 图传和货架检测

图传链路相对独立：

上游路线规划 → 在软件端直接设置巡航任务 → 到对应的目标点机器人停止移动并拍照 → 上传图片到机器人端 → 巡航任务结束 → 图传到服务端保存 → ONNX Runtime 货架检测 → 返回 JSON 和标注图

机器人在完成一整个task后将原图传回服务器进行处理，调取api和模型进行货架检测并输出标注图。

总结

该项目的工程链路如下：

音频采集 → WebSocket → FastAPI → ASR → LLM → 结果校验 → TTS → 机器人执行

模型只是其中的一部分。真正困难的地方，是让模型、网络、设备和业务逻辑稳定地协同工作。

当 AI 开始控制真实设备后，最重要的问题就不再是“模型能不能回答”，而是它返回的结果是否可信，以及系统能否在错误发生时保持安全。