机器人语音交互实战：用WT2606A离线命令词+ESP32在线大模型打造双模式对话系统

最近一直在折腾给桌面机器人加上能“听懂人话”的耳朵和能“说人话”的嘴巴。最初的想法很简单对着机器人说“往前一点”它就能动问它“今天几号”它也能答上来。可真到选型的时候才发现市面上做语音的方案五花八门从完全离线的固定命令词到纯云端大模型对话各有各的坑。最后我用的是WT2606A做主语音芯片200条离线命令词覆盖基础控制再外接一颗WiFi模组走在线大模型对话做成了“离线兜底、在线扩展”的双模式语音系统。这篇就把整个从零实现的过程和思路完整记录下来给想在机器人上做AI对话的朋友一个可以直接参考的路线图。不只是WT2606A本身还包括离线命令词怎么规划、在线多轮对话怎么接、断网了怎么回退、被误唤醒怎么治这些实际操作里一定会遇到的问题我都会展开讲。无论你是做桌面玩具机器人、语音控制小车还是想给机械臂加语音指令入口这篇的思路都能迁移过去。1. 方案选型与系统架构为什么是WT2606A 离线在线双模式1.1 需求拆解先把需求摆清楚。我给机器人做语音要满足这几件事离线可用没有网络的时候基础的“前进、后退、停止、开灯、关灯”指令必须能响应不然机器人就是个聋子。在线能聊连上网络后可以自由地向机器人提问比如“今天天气怎么样”“帮我算一下25乘以8”“讲个笑话”它要能答上来。响应要快离线指令从说完到动作执行延迟尽量在1秒以内在线对话也不能让人等太长时间。开发成本低我是一个人折腾不想写一堆复杂的数字信号处理代码最好芯片厂商能把底层都打包好我只管业务逻辑。成本可控整套语音方案预算最好控制在50元以内能便宜就便宜。这个需求清单基本框定了技术路线底层语音识别不能自己从零写必须用现成的语音芯片或者模组在线部分不需要自己训练模型接大模型API即可离线命令词则是芯片本地内置识别引擎效果最稳。1.2 为什么选WT2606A当时我在几个方案之间纠结过。纯用ESP32SenseVoice或者树莓派跑Whisper其实也能做。但问题很明显树莓派方案功耗高、成本高一杯茶功夫配置一套识别环境对只想做机器人的人来说太重了。纯ESP32离线识别倒是便宜但要自己跑轻量模型命令词一多识别率就难保证而且离线TTS合成还得另想办法。WT2606A这类专用离线语音芯片的方案核心优势就是“低成本和低门槛的平衡”。它把麦克风拾音、语音采集、命令词识别、音频解码、喇叭功放、TTS这些都封装好了我只需要通过串口跟它交互。相当于买了一个“嘴巴和耳朵都长好了”的语音前端我的主控MCU只需要关心“收到哪个命令ID然后去做什么动作”。另一个理由是离线命令词容量。WT2606A系列的离线词库容量可以做到200条级别对于桌面级机器人来说完全够用。你可以把运动控制、表情灯效、基础问答、定时提醒这些高频指令全部丢进离线词表占掉大概80%的日常交互场景剩下真正的自由对话才走在线大模型。这样就算突然断网机器人也不至于变成一块板砖。还附带一个好处离线命令词不走网络所以隐私敏感的操作比如“打开摄像头”“开始录像”可以只在本地触发不会把音频数据传出去这在做家用机器人的时候是个很加分的点。1.3 系统架构与数据流整机结构拆开来看是这样几个角色WT2606A语音模块负责拾音、离线命令词判断、播报音频输出。主控MCU我用的是ESP32负责整体流程调度管理在线会话上下文控制电机、灯、显示屏等外设。WiFi模组负责联网调用大模型API和在线TTS。因为ESP32自带WiFi所以这里直接把主控和WiFi合并成一颗芯片。离线命令的数据流是用户说唤醒词比如“小杰小杰”。WT2606A本地识别到唤醒进入命令词监听状态。用户接着说出“前进”等离线命令。WT2606A把该命令对应的ID通过UART发给ESP32。ESP32收到后控制电机执行同时可以返回一个串口指令给WT2606A播放“好的”之类的回馈音。在线多轮对话的数据流是用户说唤醒词然后说“我想问你一个问题”。如果这个说法被定义为在线对话入口WT2606A就进入“在线模式”把后续拾音识别出的文本不断发给ESP32。ESP32把文本和对话历史一起组装成请求发给大模型API。大模型返回回答文本ESP32把文本交给TTS模块合成语音或者让WT2606A播放本地预置的语音。如果几句之间用户没有继续说话超过设定时间后自动退回离线待机状态。整体上WT2606A扮演的是“语音前端”ESP32扮演的是“大脑调度器”大模型API负责“自由发挥”。这套结构的好处是职责清晰语音识别和播放的脏活累活都被芯片扛了我只需要写好状态机。2. 硬件搭建与基础调试从模块到能出声2.1 需要的物料清单我实际搭建用的器件清单放在下面都是很常见的物料。器件型号/规格作用参考成本语音模块WT2606A系列离线语音模块命令词识别、音频播放、TTS15-30元主控/WiFiESP32开发板联网、写逻辑、调度状态机10-20元麦克风驻极体麦克风或硅麦模块自带则省拾音1-3元喇叭4欧3瓦或8欧1瓦小喇叭放音2-5元电源5V 2A适配器或3.7V锂电池升压板供电5-10元辅助材料杜邦线、排针、电容、电解电容、LDO接线、滤波少量买的时候要留意有些WT2606A模组已经把麦克风和喇叭接口做成排针或者焊盘直接插上就能用有些是裸芯片需要自己搭外围电路。第一次玩建议买带板载麦克风座和喇叭端子的模组省很多事。2.2 接线与供电的关键点接线本身不复杂但有几个坑会让第一次上电的人怀疑人生。供电方面语音模块和功放部分对电源质量比较敏感。喇叭播报的时候电流会突然拉高如果电源纹波大底噪就会很明显。我的做法是主控和语音模块分开供电或加一级LDO至少要在模块电源输入脚并联一个100uF电解电容再并联一个104陶瓷电容位置尽量靠近模块电源脚。实测下来这个做法能解决掉大半“喇叭有滋滋声”的问题。串口接线要注意交叉连接。WT2606A的TX接ESP32的RXWT2606A的RX接ESP32的TX地线一定要共地。逻辑电平方面大部分模组是3.3V或者5VESP32的IO也是3.3V通信起来基本兼容。如果买的模组明确标注是5V电平最好加一个电平转换模块避免长期使用把ESP32引脚搞坏。麦克风和喇叭的物理位置也很影响体验。麦克风尽量远离喇叭用海绵或硅胶套隔一下不然播报的时候麦克风又把喇叭的声音收进去形成自激啸叫。这是很多语音模块“识别率差”的隐形原因。2.3 首次上电与串口验证上电之前先习惯性用万用表量一下电源正负极确认没短路再通电。模块正常启动后会听到一个开机提示音或者可以看到LED指示灯亮起。接着做串口验证。用USB转TTL工具连接WT2606A的串口打开串口助手波特率从115200开始试。大多数模块出厂默认是115200或9600具体看模块资料。第一步测试播放功能发送播放一段预置音频的命令比如查一下对应命令表里“播放第1段音频”的指令码通常格式是类似FD 00 01 00 00这种帧结构不同的固件会不太一样。如果喇叭出声说明音频通路没问题。第二步测试离线识别对着模块说唤醒词串口应该会收到唤醒成功的事件帧再说一条出厂预置的命令词串口会收到对应的命令ID。能收到这两类数据说明核心链路已经通了后面就可以正式进入命令词定制环节。3. 200条离线命令词的规划与落地3.1 命令词表设计200条听起来很多但如果不规划词条之间会出现大量冗余和误触发。我的习惯是先按场景分类而不是想到什么加什么。对一台桌面机器人来说可以分成这几个词表场景分类典型命令词触发后的动作运动控制前进、后退、左转、右转、停止、加速、减速控制电机表情与灯效笑一个、生气、跳舞、灯光开、灯光关、换颜色控制屏幕/灯带基础问答现在几点、今天几号、你的名字本地RTC/预置播报在线对话入口我想聊天、问你个问题、今天天气怎么样切换在线模式待机与休眠睡觉吧、关机、再见进入低功耗状态紧急安全紧急停止、全部停下立即切断执行器并中断播报每个场景下再细分词条。建议第一版只做30到50条覆盖最高频的交互先把整条链路调通。200条是容量的上限不是让你一次性全塞进去。词条越多相似发音之间的混淆概率就越大后期排查越麻烦。等骨架稳定之后再逐步往上加词。3.2 词条命名与避歧义离线命令词的识别是芯片本地引擎完成的训练和配置时如果词条选得太像识别率一定会翻车。我踩过最经典的坑就是“前进”和“接近”“开灯”和“关灯”这种发音高度接近的词组。命名原则我总结了几条命令词之间发音要有明显区分。比如“前进”和“后退”没问题但“快进”和“前进”就很容易混。唤醒词不要太通用。不要用“你好”这种满世界都在说的词否则电视里播个广告都能把它唤醒。我用的唤醒词是“小杰小杰”四字叠读鲁棒性明显好很多。对立的动作不要靠单个字区分。比如用“开灯”和“关灯”不如用“小杰开灯”“小杰关灯”把距离拉开让识别引擎更容易分辨。避免生僻多音字。比如“行”有xíng和háng两个音识别引擎很容易选错干脆别用。配置完词条之后最好找普通话口音不一样的三四个人分别测一轮。每人每条约读5遍记录识别准确率和误触发次数。凡是识别率低于80%的词条要么换说法要么删掉不要让它在正式词表里留着埋雷。3.3 配置烧录与灵敏度调整WT2606A配套的上位机工具一般支持词条导入、音频导入、生成配置并烧录。操作流程大概是在上位机里新建一个工程选择对应的芯片型号和固件版本。在命令词列表里逐条添加“显示文本”和对应的“播报音频”。每条命令都绑定一个唯一的命令ID。设置识别灵敏度参数先按默认值放上去测试。生成配置文件通过USB/串口烧录到模块。灵敏度这个参数要讲一下。灵敏度太高阈值低误唤醒会频繁出现灵敏度太低站远一点就识别不到。我的经验值是桌面近距离使用灵敏度设置到中等偏保守的档位如果机器人是在一米外被呼救才需要调高。另外唤醒后的命令词监听超时时间也值得调通常设置成5到8秒比较平衡。太短用户犹豫一下就超时了太长机器人一直处于待命状态误触概率又会上升。还有一个容易被忽略的点命令词更新之后一定要重新做一次全量回归测试别只测新增的几条。因为新增词条可能会改变整个词表的区分度某些旧词条的表现会和之前不一样只有全部重新过一遍才放心。4. 在线多轮对话的实现思路4.1 在线链路怎么接在线对话部分我采用的是“WT2606AESP32”双芯片结构。WT2606A负责把用户语音转成文本然后通过UART发给ESP32ESP32负责拼接上下文、发起大模型请求、接收回答文本回答文本再交给TTS环节变成语音。一种简化做法是用支持OpenAI格式的大模型接口。ESP32侧的程序流程大概是从WT2606A收到用户文本。在本地维护一个消息数组保存最近若干轮的对话。把系统提示词、历史对话、当前用户问题一起组装成JSON。发起HTTP/HTTPS请求到大模型API。拿到返回文本后把该文本也存入消息数组。把文本交给TTS引擎播报。需要注意一点WT2606A的串口一次能接收的文本长度有限如果大模型返回了很长的回答不能一次性直接丢过去。我的做法是先在ESP32侧把回答按标点符号切分成短句一句一句发过去播报既避免串口一次传输过长数据又能模拟“边说边想”的自然停顿感用户体验反而更好。TTS环节有两个选择用WT2606A本地TTS把文本合成本地语音或者调用在线TTS接口返回音频再放。本地TTS音色一般但零延迟适合离线情况和指令播报在线TTS音色自然适合聊天场景。我的方案是两种都保留通过命令词入口切换。用户说“问你个问题”进入聊天模式时用在线TTS平时控制类播报用本地TTS。4.2 多轮记忆状态管理“多轮对话”和普通问答最大的区别在于要管理上下文。用户上一句说了“我叫小明”下一句问“我叫什么”如果只把这句单独发给大模型它肯定答不上来。所以必须在ESP32侧维护一个环形消息历史。我用的数据结构很简单就是维护最近N轮的消息列表messages [ {role: system, content: 你是一个桌面机器人助手回答要简洁控制在50字以内。}, {role: user, content: 我叫小明}, {role: assistant, content: 你好小明很高兴认识你}, {role: user, content: 我叫什么} ]每次向大模型发起请求时都把从system到当前这一整组消息一起带上。N的值我通常取8到12轮因为太多轮容易超出大模型一次性上下文的限制也会增加请求耗时。超过上限后最老的消息就被挤出队列。这里有个工程细节不能只靠“收到的文本”去判断一圈结束。用户可能连续说了几句但没有得到回复此时不应该把两句都当成独立的user消息塞进历史否则上下文机理会混乱。我做了个简单的合并逻辑同一轮对话中如果上一条已经是user角色就把它和新的user文本拼接中间用顿号或者逗号连接凑成一条完整请求再发送给大模型。另外多轮对话过程中要设置会话超时。比如用户和机器人聊完一句之后超过30秒没有再说话就自动清空消息历史把会话状态重置回待机。不清空的话过了半小时再问一句“还在吗”模型还会带着半小时前的聊天记录既浪费token又显得笨。4.3 离线在线切换与安全兜底不管在线对话做得多么流畅离线优先级永远要高于在线。这个原则必须在状态机里写死。我的状态机分了这几个状态待机、离线监听、在线聆听、请求处理中、语音播报中。切换逻辑是待机状态收到唤醒词进入离线监听。离线监听中识别到“在线对话入口”命令词进入在线聆听。在线聆听中有一段语音输入进入请求处理中。请求处理中拿到回复文本进入语音播报中。播报结束回到待机如果在等待期间识别到“紧急停止”等高优先级离线命令立即中断当前播报执行安全动作。特别注意“紧急停止”这类安全指令任何时候都要能被响应。我专门给WT2606A留了一个高优先级离线词即使处于在线播放TTS的过程中用户说“紧急停止”模块也会立刻通过GPIO中断打断播报并把一个高优先级的命令ID发给ESP32ESP32马上切断电机使能。如果有硬件急停按钮的语音急停只是辅助不能替代物理急停。断网回退也是必须设计的。我做了两个层级请求前检测和请求失败检测。请求前如果发现WiFi已断开就播报“网络不可用请先连接网络”然后切回离线监听模式请求发出后如果超过10秒没有响应就播报“网络好像开小差了你先直接指挥我吧”同时清掉这轮对话历史避免把一条超时消息留在队列里污染下一轮。5. 常见问题排查与避坑实录5.1 识别类问题“唤醒率低”是我被问得最多的情况。如果唤醒词经常叫不醒先不要急着怀疑芯片坏了按这几个方向查灵敏度参数是否调得过低。麦克风进音孔是否被机身遮挡桌面机器人的外壳设计如果挡住了麦克风孔识别率会骤降。是否在播报过程中说唤醒词很多芯片在播报期间会关闭麦克风输入要等播报结束再说。供电波动是否导致模块重启或工作不稳定。“误唤醒”则是另一个极端频繁被无关声音触发。解决办法就是调低灵敏度和选一个更不常用的唤醒词另外把唤醒后的命令词监听超时缩短。“个别词条总是识别成别的词”这个问题大概率是词表设计问题。建议先在上位机里单独跑一遍这两个词条的声学相似度测试如果确实接近就改词。不要指望靠调灵敏度解决那种只能顾此失彼。我整理了一个排查速查表现象常见原因处理方法完全没反应串口接线错、波特率不对、模块没上电用串口助手查看启动日志时灵时不灵电源纹波大、麦克风离喇叭太近加滤波电容调整麦克风位置频繁误唤醒灵敏度太高、唤醒词太通用调低灵敏度、换词个别词识别错词条发音接近换词条说法唤醒后不听话监听超时太短、命令词不在词表调长超时补充词条5.2 在线与网络类问题在线对话最常见的坑就是“ESP32发送HTTPS请求失败”。ESP32本身支持TLS但如果你用的是老版本AT固件的ESP8266HTTPS会非常难搞。我最终放弃ESP8266改用了ESP32直接在SDK里跑HTTP客户端省掉了AT指令的拼接麻烦。另一个高频问题是“大模型明明返回了文本但机器人有口型没声音”。这种情况一般是三个原因TTS通道切换没写对回答文本被送到了不播报的通道。文本里包含特殊字符或表情符号本地TTS不支持合成失败。播报音量被静音或者喇叭信号线脱焊。还有“多轮对话中模型突然失忆”的问题。排查思路是先确认每次请求时是否真的带了历史消息其次检查消息数组是否因为超出大小被意外清空。我调试时会在ESP32串口里把完整的请求JSON打出来一眼就能看清带了哪些历史。关于网络延迟实测下来大模型首字返回一般在2到5秒。这个时间没有TTS可以掩盖我的做法是播放一个短的“正在思考”音频提示然后用LED呼吸灯表示状态让用户知道机器人听到了、正在处理。直接干等是最差的体验。5.3 电源与硬件类问题电源类问题非常隐蔽。我遇到过一种情况机器人一播报旁边舵机就开始抖动。查了半天发现是语音模块的喇叭电流回灌到共用电源导致舵机控制信号被干扰。后来把语音模块电源独立用LDO供电再在舵机电源入口加了电解电容才解决。如果你发现“播报声音沙哑”或者“音量很小”除开喇叭本身质量问题还要检查功放供电电压够不够。有些模块喇叭输出是BTL结构音量跟电源电压直接相关5V供电比3.7V锂电池供电明显更响。想用电池供电的话尽量用升压到5V的方案。模块发热比较大也属于正常语音芯片带功放工作时摸起来会烫手但前提是不要超过数据手册的工作温度范围。如果烫到不能碰要检查是不是喇叭阻抗不匹配或者长时间满音量播放这会缩短模块寿命建议降低音量或给模块贴散热片。5.4 开发过程中的其他小坑开发过程里还有几个不好归类但很容易卡住人的点。第一串口通信乱码。优先级最高的排查是波特率不一致其次是接线接触不良。用逻辑分析仪看波形是最快的定位方式实在没有就反复松开重插杜邦线很多“乱码”其实只是接触不良。第二模块固件版本问题。WT2606A系列不同批次、不同固件版本支持的指令集可能略有差异。同一个命令帧在不同固件上的效果可能不一样所以拿到模块第一步就是确认固件版本并去下载对应版本的指令手册不要拿旧教程的指令直接套。第三电源时序。如果ESP32和WT2606A共用一个总开关上电瞬间可能因为ESP32的启动电流太大导致电压跌落语音模块初始化失败表现为“大多数时候正常偶尔开机没声音”。解决办法是给语音模块加延迟上电或者用一个MOS管控制语音模块的电源等主控启动完成之后再给它供电。6. 最后聊点实操体会整套方案真正落地之后我最大的感受是别把离线命令词当成一个“备用方案”它其实是整个对话体验的骨架。200条离线词把机器人最常用、最需要低延迟的交互全部承包了在线大模型只是给这个骨架补上了血肉让它能应对用户的自由发挥。这种“能离线则离线离线不行再上网”的设计思路对所有对话类硬件都适用。另一个很深的体会是小步快跑比一上来就做全功能靠谱得多。我第一版就先把唤醒、播放、3条运动指令跑通然后才慢慢加其他命令词和在线对话。如果你现在正打算在机器人上做语音建议也按这个顺序来先让机器人能听懂一条命令并做出反应再追求两百条命令再上大模型。把地基打牢后面的扩展都只是往架构里填内容而已。后续我计划把这套语音方案接到一台ROS2小车上让离线命令词直接映射到导航指令比如“去厨房”“左转90度”在线对话则用来做导航前的语义理解。如果你刚好也在往这个方向折腾欢迎按这条思路先把自己的机器人“耳朵”做出来遇到具体问题再针对性调试会比直接套代码模板踏实得多。