dingdang robot：一个开源的中文智能音箱项目

欢迎你们前往腾讯云社区，获取更多腾讯海量技术实践干货哦~

做者：潘伟洲

免责说明：本文介绍的 dingdang-robot 与公司的叮当助手没有任何关系。

这个项目其实来源于我生活中的一个需求：我天天晚上都会去厨房作一个面包当明天的早餐，当我把用料按顺序准备好放进面包机时，我须要准确预定到明天早上我吃早餐的时间。然而，几乎每次在这个时候我都没有带手机在身边，而是都放在客厅里充电，这时只能跑去客厅看时间。虽然厨房到客厅只有几步之遥，但本身又是懒癌患者，天天都要这么来回奔波就以为很不方便。要解决这个问题固然有不少种方法，好比直接买个小时钟放在厨房。不过我更但愿“连看都不用看”，直接有人告诉我时间。因此，我须要一个像 Amazon Echo 那样的智能音箱。

然而，不管是 Amazon Echo 、Google Home 仍是微软 Cortana 音箱，在国内的使用都是个问题。虽然国内也有相似的智能音箱产品，但我没有用过这些产品，不知道可定制性如何。好比，若是我须要开发个功能让它告诉我某种面包的配方是什么，这些产品就不必定能作到了。考虑再三，我决定本身动手写一个。整个项目用了差很少三个星期的业余零碎时间。

先放上项目主页：http://dingdang.hahack.com

Demo：https://github.com/wzpan/dingdang-robot/wiki/demo

下面分享一下我在开发这个项目过程当中的心得。

硬件

首先要解决的是硬件问题。我选择在 Raspberry Pi 上开发。因而我买了块 Raspberry Pi 三代主板。麦克风和音响方面，出于美观的目的，买了个自带音响的 USB 全向会议麦克风。整套设备看起来就像这样：

[图片上传失败...(image-99d2ff-1512030430320)]

过了不久以为这个麦克风自带的音响音质太通常了，因此我又外接了一个小音箱。而后再插了一个摄像头，用来实现拍照功能，又进化成了这样：

[图片上传失败...(image-6a565f-1512030430320)]

发布了不到一个星期，respeaker 的商务经理看到了我这个项目，但愿能提供硬件上的支持，因此我又玩上了各类 respeaker 的硬件（作为回报，我也零报酬给他们带去了 100 多个 respeaker-2mics-HAT 的销量）：

[图片上传失败...(image-8f30c5-1512030430320)]

由于软件自己是和硬件解耦的，并不依赖具体的硬件要求，因此不少用户也本身作了硬件上的定制和尝试（最后一张图里预装了 dingdang-robot 的是熊，不是妹子 :-p）：

[图片上传失败...(image-b39a-1512030430320)]

硬件有了，接下来就得开始写软件了。主要的框架借鉴了 Jasper 项目，并加入了我本身的定制和想法。这里说说一些有意思的部分。

指令接收

智能音箱要解决的一个最重要的问题就是如何接收指令。这里头主要涉及两个问题：

1. 被动唤醒（Passive Listening），即“何时开始听”。这个阶段只监听唤醒词。当听到唤醒词时，进入主动聆听。
2. 主动聆听（Active Listening），即“何时结束听”。这个阶段主动聆听用户的任何语音指令，而后对听到的内容进行分析处理。

被动唤醒阶段的基本策略是：每次以 16000 的采样率录制 1024 个采样做为一个采样集，而后对采样集进行信号强度估计，当某个采样集信号强度大于一个阈值时，就认为可能接受到了指令。而后持续录制多 1 秒时间，再转交给语音识别模块。当语音识别模块认为是唤醒词时，进入主动聆听阶段。

主动聆听的策略与被动唤醒基本类似，每次以 16000 的采样率录制 1024 个采样做为一个采样集，而后对采样集进行信号强度估计，当某个采样集信号强度低于一个阈值约 1 秒的时间时，就认为用户已说完了指令。固然还要考虑环境吵杂，一直处于聆听的可能。所以能够再加一个超时保护，超过 12 秒就结束聆听。

语音处理

说说STT（语音识别，说成ASR也是一回事啦）引擎和TTS（语音转文本）引擎的选择。因为被动唤醒会试图识别全部听到的内容，出于隐私保护的目的，应该使用离线的语音识别引擎，所以我选择的是 PocketSphinx 。而对于主动聆听，因为是在唤醒阶段才会进行转换，进入主动聆听前会有蜂鸣提示，用户也会清楚此时叮当正在听他们说话，相对来讲隐私泄露的可能性就比较低，所以我最初选择的是在线的百度 STT 语音识别服务，也省下了扩展语音识别模型的工夫，有利于更好地实现插件可扩展。TTS 引擎方面一样也先支持了百度的语音合成。

在实际测试中，PocketSphinx 的识别出乎意料的好。因为个人离线指令集只有几个候选唤醒词，PocketSphinx 对这些唤醒词的识别很是灵敏，甚至有时候其余声音也可能被误当成唤醒词而唤醒叮当。但即便被意外唤醒了，不去理会叮当就能够了。

相比之下，百度的语音识别就比较迟钝了。有时候明明我发音很清晰了，仍是会识别成另外的含义。经过在百度的语音识别平台上传自定义的语音识别词库 能够提升识别的准确率。另外，因为我用的是 Restful API，网速比较差的时候响应也比较慢。我在家用的是 10M 带宽的网络，反应速度还算能够接受。

下面这个视频是我与叮当对话的演示。我把唤醒词设置成了“小梅”：

http://www.miaopai.com/show/-yeEBNJlvrQ-UNZzaglxr2s9JQU8TZNy.htm

一个问题是当回答内容比较长（好比问叮当当天的新闻）时，合成语音的耗时会变得很长，给人的感觉是叮当的响应很慢。因此我加了个 read_long_content 的选项。当内容过长时，改为发送到用户的邮箱或者微信。

[图片上传失败...(image-11938c-1512030430320)]

到了九月份的时候，dingdang-robot 在离线唤醒方面又增长了 snowboy 引擎，在主动聆听和语音合成方面又增长了阿里、科大讯飞的服务，不管是识别速度和合成音色的丰富程度又有了很大的进步。

[图片上传失败...(image-1c1a35-1512030430320)]

技能插件

叮当最好玩的部分固然就是玩插件了，经过写插件可让叮当接入各类各样的服务，完成各类各样的事情。我在叮当里也内置了几个插件。为了方便用户扩展，我定义了三个技能插件目录：

• $HOME/dingdang/client/plugins：官方插件，与 wzpan/dingdang-robot 同一仓库；
• $HOME/.dingdang/contrib：用户贡献的第三方插件，单独维护一个 dingdang-robot/dingdang-contrib 仓库；
• $HOME/.dingdang/custom：用户自定义插件，用于存放用户本身开发的，暂时不计划对外发布的插件。

以下是截至本文发布前 dingdang-robot 提供的插件，能够看出，其余用户贡献的插件已经达到了叮当自带的插件的两倍：

插件名	用途	是否用户贡献
Echo	简单的回声/传话功能。	否
Email	检查邮件功能。	否
Time	时间插件。询问叮当时间。	否
Camera	用于调起摄像头拍照（若是安装了摄像头的话）。	部分
SendQR	要求叮当发送微信登陆二维码到用户邮箱（方便远程微信登陆）。	否
Chatting	用于进入/退出闲聊模式的插件。	否
Unclear	用于机器人聊天兜底。	否
Hass	用于控制接入HomeAssistant的设备	是
NetEaseMusic	网易云音乐播放插件	否
Weather	天气查询插件	否
SpeakIP	播报主机IP地址插件	是
Reboot	从新启动操做系统（root用户）	是
WebServer	启动HTTP服务器插件	是
SendMessage	向微信好友发消息插件	是
ControMqtt	经过Mqtt协议与其余开发板通信	是
WOL	经过WOL(Wake On Lan)实现语音开机	是
EmailMyPC	以邮件方式实现语音操控电脑	是
ToDo	简单的备忘插件	是
RaspberryPiStatus	简单的树莓派状态查询插件	是
HeadlineNews	新闻头条播报插件	是
Direction	出行路线规划插件	是
BaiduFM	百度FM音乐播放插件	是

音乐播放

既然是智能音箱，固然少不了播放音乐的功能。因此我额外写了个播放网易云音乐的插件 NetEaseMusic 。出于版权考虑，并不集成进官方插件中，而是放进 dingdang-contrib 里头。

这个插件的实现比较复杂。普通的插件接受到指令，响应完就退出了。而为了能支持各类指令控制音乐播放，这个插件在接收到播放控制指令后并不退出插件，而是进入一个播放器模式，这个模式主动聆听获得的指令只会在播放控制指令集中匹配，其余的插件指令都不起做用。只有当用户要求退出播放时才回到普通模式。NetEaseMusic 的播放控制指令以下：

指令	相同指令	用途
播放音乐	-	进入音乐播放模式。在音乐播放模式下，其余的插件功能将不可用。
下一首	切歌, 下一首歌, 下首歌	切换到下一首歌。若是没有下一首歌，就回到列表中第一首歌
上一首	上一首歌，上首歌	切换到上一首歌。若是没有上一首歌，就跳到列表中最后一首歌
大声点	大点声，大声	调高播放音量
小声点	小点声，小声	下降播放音量
随机播放	-	随机播放列表中的音乐
顺序播放	-	顺序播放列表中的音乐
暂停播放	-	暂停音乐的播放
播放	继续	继续音乐的播放
榜单	-	播放推荐榜单
歌单	-	播放用户的歌单（若是有多张，将只播放第一张）
结束播放	退出播放，中止播放	退出音乐播放模式。
搜索	查找	搜索歌曲/歌手。将自动播放搜索结果。
什么歌	-	正在播放的是什么歌

实现这个插件的过程当中还参考了 Vellow 的 MusicBox 项目以及 yaphone 的 RasWxNeteaseMusic 。为了方便重用，我把 MusicBox 的核心 API 抽离了出来封成了一个 MusicBoxApi 库 。比较坑爹的是就在我准备发布叮当的前几天，老的获取音乐地址的方式完全不能用了，而新的接口批量获取的地址不知道为何是乱序的，因而我只能在播放每首歌前都调用一下新版的获取地址的 POST 接口，又增长了一点响应时间。

下面这段音频是使用叮当控制音乐播放的演示：

http://onmw7y6f4.bkt.clouddn.com/%E6%92%AD%E6%94%BE%E9%9F%B3%E4%B9%90.mp3

完成了音乐播放功能后，叮当的好玩程度提升了不少。之前要听歌，至少得把电脑或者手机打开。如今只须要喊一声叫叮当播放歌曲就能够了。想换歌、搜索歌曲、调节音量都是说句话就搞定的事情，生活幸福指数大幅提高 ^_^ 。

开源心得

dingdang-robot 的正式开源时间是今年的 5 月 20 日（是的，我专门挑了个好日子），截至本文发表时，该项目的相关数据以下：

• Github Stars：418，平均一个月 100 star
• QQ群用户：340
• pull requests：48
• 项目主页 PV：12,000+
• 捐赠记录：https://github.com/wzpan/dingdang-robot/wiki/donate-list

虽然数据并非特别亮眼，不过对于这样的小众项目，我已经比较满意了。下面谈谈我的怎么维护一个开源项目吧。

前期：作好框架

根据二八法则，项目的前期应该要把整个项目指望能达到的 80% 的基本要求完成。一我的的力量毕竟有限，要完成剩余的 20% 的功能可能要耗费很是多的精力，还不如先推出来，造成社区后再去尝试完成。

以 dingdang-robot 为例，其实智能音箱最重要的几个用途：音乐播放、闹钟提醒和智能家电控制只有音乐播放是我在首次发布的时候提供的（由于不能播放在线音乐的智能音箱实在很差意思叫智能音箱）。剩下的几个功能都是我提了 feature issues 大体提供了实现思路，而后由其余的开发者去完成的。

因此，对于一个比较大的项目，更重要的是在这个阶段界定好 80% 的目标，设计好项目的框架，肯定 License，写好 README 和 CONTRIBUTION（代码审核、持续集成测试等）。

中期：推广 + 社区搭建

项目发布以后，推广和社区搭建是很是重要的，毕竟直接关系到项目的用户数量和这个项目的生命力。

推广方面，这个阶段我发布了三篇文章：

• 叮当：一个开源的中文智能音箱项目：介绍这个项目。
• 手把手教你编写叮当机器人插件：介绍如何开发和贡献技能插件。
• 使用叮当声控智米电风扇：介绍如何使用叮当控制家电。

这三篇文章推到了开发者头条和树莓派实验室上，都取得了不错的点击率。

另外，若是你跟微博上一些大 V 关系不错，也能够尝试 @ 他们帮忙推广，固然前提是项目要足够拿得出手才行。

在这个阶段，项目的主页和文档也必须尽快搞好，良好的主页和文档是吸引用户付出精力去尝试你的项目的必要前提。若是像我同样想省点事，能够直接用 Github Pages 生成简单的项目主页，而后直接用 Github Wiki 维护文档。

社区的搭建也是很是关键的一环。能够考虑的渠道好比：

• 即时通信工具：若是项目主要针对国内用户，可使用QQ群；若是针对国际用户，可使用 slack 。
• 论坛。即时通信工具的最大问题就是存在时效性。相似的问题在群里刚回答完，新加入的用户又问了一遍，很是崩溃。因此搭建一个论坛，引导用户多去使用论坛交流就能够解决这样的问题。

以 dingdang-robot 为例，QQ群是不少人决定参与项目以前先加入的社区。刚开始群里才几我的的时候也是很是冷清尴尬，但后面随着人愈来愈多，群里变得很是热闹（甚至我不得不选择上班时间屏蔽该群）。而论坛最初是其中一个用户用 discuz! 搭建的，但邮箱认证没搞定，长此以往论坛里一堆的 spam 。趁着国庆我又用 discourse 从新搭了一个，加了严格的审核策略，正好用腾讯云的体验代金券。

市集模式合做阶段：促进合做，保持生命力

一旦用户数量足够多，参与贡献的人就会多了起来。这时候怎么调动你们参与贡献的热情就显得格为重要了。

为了达到这个目的，项目做者自己首先固然要以身做则，体现出充足码力。该你承担的部分积极实现，该 code review 的时候赶忙 review，该发布新版本的时候保证发布。而后在社区里头多多抛出可能的 idea 和实现方案，这时候每每就会有人愿意参与贡献。

我比较喜欢的形式是在项目的 Github issue 页里提出需求，而后过不久就能够看到有人参与贡献了（好比 #28, #29 和 #39）。对于参与贡献的用户，要不吝致谢，让他们的名字出如今 changelog 中。

除了这种市集模式的合做方式以外，将来我可能会考虑其余新颖的促进合做的方式，好比在线直播写插件、发布新版本，线下 Hackathon 等。

总结和后续

对于有 Coding 能力的 Hacker 而言，本身动手作一个智能音箱，不只能够当作业余练手项目，还能够自由地定制硬件模块，并实现本身须要的各类功能，这远比直接购买一个 Amazon Echo 有趣得多。

更重要的，我更但愿能有其余有兴趣的朋友参与进来，一同开发完善这个智能音箱项目。我相信，这种个性化服务的产品自己就应该是彻底可定制的。而您的加入可使 dingdang-robot 变得更智能！

相关阅读

CNN 在语音识别中的应用 加权有限状态机在语音识别中的应用 揭秘腾讯云Supermind智能网络，百万级设备的网络高效运维

---

此文已由做者受权腾讯云技术社区发布，转载请注明原文出处