从「改造火火兔」开始,到遇见 ChatGPT 玩具「FoloToy」
获取「改造火火兔」动态和「FoloToy」玩具进展请关注我的电报频道 FoloToy 从上个月在推上公开一系列脑洞开始,到选定其中做智能硬件的想法,借助「改造火火兔」到昨天大概一个多月才算验证通所有的产品化技术难点,群友们都在安静等待着产品发布,我自己反而觉得越来越着急,这是一个月遇到技术问题的汇总,希望也能给其他做 IoT 硬件产品的朋友以启发。 我们没有选用树莓派之类的可以运行完整 Linux 的方案,而是采用了 ESP32 嵌入式方案,我们希望模块可以做得非常小,功耗低,成本也低,这样我们就需要自己搞定硬件的设计和固件的开发,也就遇到了后续的这些问题。 开始的选择了 ESP32S3 模块,搭配数字麦克风,第一版硬件做出来以后,发现数字麦克风在 USB 充电时总是会受到干扰,导致录音噪声太多以致不能识别语音,经过多次尝试,始终无法解决问题,我认为这种缺陷无法接受,需要调整。在测试玩具自带的模拟麦克风时,发现效果非常好,于是尝试使用自带麦克风。 起初想法是用户在拿到板子后,不需要自己运行服务程序,只需在固件中配置好 OpenAI 和 Azure 的 APIKey 就可以使用,在做了一些测试之后,发现芯片计算能力有限,从录音到播放生成的回复语音这段过程耗时太长,这样的体验让人难以接受,而把语音处理的过程放到服务器来实现后,回复较短的情况下,整体的响应的速度提高到 3-5s。 ChatGPT 玩具在对话时需要一直在线,是需要联网的 IoT 设备,除了要支持上下行控制指令和配置参数的下发上传,还需要上传下载语音。实现上,在线控制我们使用了 MQTT, 实时发送语音使用单独了 UDP 通道,设备再通过 HTTPS 下载服务器生成好的语音回复文件来播放,数据传输的方案也是遇到一些问题后才确定的。 一开始,我们认为玩具的交互过程非常简单,直接使用 UDP 就可以了,但在实现的过程中发现,服务器在向 ESP32 板子发送 UDP 的语音数据时,会发生非常明显的丢包,从而造成扬声器播放有断断续续的现象,而且不同的电脑运行服务器程序现象还不尽相同,我的 MacBook 体验就很好,而换成 ThinkPad 就丢包严重。 从 UDP 上解决这个问题我感觉难度较大,可能要我们自己做缓存适配硬件解码速度的来播放语音。于是我们从服务器推语音文件转向由板子自己拉(下载)语音文件的方式,流程:板子通过 UDP 上传语音,服务器接收语音后通过 MQTT 下发语音文件 URL,在服务器完成所有的接口调用和语音处理之后,通知板子下载语音。 到此,技术上主要的问题都已经解决,此外我们还做好了通过 Web 更新固件,配网,定义好了灯的状态,而且芯片换为资源更多的 ESP32,从而有足够的 Flash 用于存储出厂固件等。 另外也我注册好了产品的域名 https://FoloToy.com,接下来我们在 https://FoloToy.com 上相会, 谢谢。