1. 从一个真实需求说起为什么我要做这个发声辅助装置去年秋天我的一位长辈因为脑卒中住院万幸抢救及时但留下了比较明显的语言障碍。他能听懂别人说话意识也完全清醒可就是没办法顺畅地把想说的话讲出来。那种“脑子里清清楚楚嘴上却表达不出来”的憋闷感我作为旁观者都替他着急。医院里虽然有专门的沟通卡片和简单的辅助工具但要么是纸质的、翻起来慢要么是平板上的App、需要一直用手点对偏瘫患者来说并不友好。这件事让我动了念头能不能用一块树莓派Raspberry Pi做一个放在床边、按一下就能替他把常用话“说”出来的小装置这就是我后来断断续续折腾了两个多月的“Stroke Communication Aid”——一个基于树莓派的语音辅助设备。它的核心目标很朴素让语言表达困难的人用最少的操作把最常用的需求变成清晰的语音播放出来。这篇文章我会把整个项目的来龙去脉讲清楚包括我为什么选树莓派而不是别的方案、硬件怎么搭、软件怎么组织、语音合成怎么选、实际用下来踩了哪些坑。如果你家里也有类似情况的老人或者你本身在做辅助技术、无障碍设备相关的项目这篇内容应该能给你省下不少试错时间。关键词里提到的Raspberry Pi和Voice是贯穿始终的两条主线而最近大家讨论比较多的“本地部署 sense voice”“voice studio”这类思路我也会结合自己的实践聊聊取舍。需要先说明一点这个装置不是医疗器械不能替代专业的言语康复训练它只是一个帮助日常沟通的辅助工具。定位清楚这一点后面的设计取舍就都好理解了。2. 硬件选型为什么是树莓派而不是手机或单片机2.1 树莓派在这个场景里的真实优势很多人第一反应是“手机App不就能做吗为什么要专门搞个硬件”。我一开始也这么想但实际用下来发现手机方案有几个绕不过去的坎。第一手机屏幕小、操作层级深对偏瘫或手部不灵活的用户来说解锁、找App、点按钮这一串动作本身就是负担。第二手机是私人设备放在床边给长辈用家属想临时调整内容很麻烦。第三长时间亮屏待命对电池和寿命都不友好。树莓派的好处在于它是一个“专用设备”的形态。我可以把它做成一个固定放在床头的小盒子上面只有几个大按键通电就进入待命状态按一下立刻出声没有解锁、没有广告、没有通知打扰。这种“开机即用、零学习成本”的体验是通用手机很难给的。从性能上看我用的是一块Raspberry Pi 4B4GB 版本。有人会问做个语音播放用得着 4GB 吗其实单纯播放音频树莓派 Zero 2 W 都够。但我留了余量是因为后面想加本地语音识别、想跑更自然的语音合成模型这些都比较吃内存。如果你只做“按键播放预录语音”Zero 2 W 完全够用成本还能压到很低。2.2 外围硬件的搭配思路硬件清单我列一下都是很常见的东西部件型号/规格作用备注主控Raspberry Pi 4B 4GB运行主程序Zero 2 W 也可看预算存储32GB microSD 卡系统与音频文件建议选耐久卡音频输出USB 小音箱播放语音3.5mm 也行USB 底噪更小输入大号轻触按键 x4~6触发播放直径 12mm 以上更好按连接杜邦线、面包板接线调试定型后建议焊接电源5V 3A 官方电源稳定供电别用杂牌会重启按键我特意选了直径比较大的轻触开关因为目标用户手指力量和控制精度都可能不足。小按键按不准大按键容错率高。这一点在选型时特别重要很多人做原型时随手拿个小按钮结果真正给老人用的时候根本按不动。接线方面我把按键一端接 GPIO 引脚另一端接地用树莓派内部的上下拉电阻来读状态。这样电路简单不需要额外的电阻。具体用哪几个引脚后面软件部分会讲。提示如果你打算把装置做成成品强烈建议把按键焊在一块洞洞板或定制 PCB 上面包板长期使用接触不良会出现“按了没反应”的假故障排查起来很折磨人。2.3 一个容易被忽略的细节供电与散热树莓派 4B 对供电比较敏感电压不稳会导致随机重启。我一开始用了一个旧手机的充电头结果装置偶尔会自己重启语音播到一半就断了。换成官方 5V 3A 电源后问题消失。这个坑很典型做长期待机的设备电源一定要留足余量。散热方面如果只是播放语音树莓派基本不发热。但如果后面加了本地语音识别CPU 会持续跑建议加个小散热片或者风扇。我实测跑识别时 CPU 温度能到 70 度以上加了散热片后稳定在 55 度左右。3. 软件架构把“按键”变成“说话”的完整链路3.1 整体流程拆解整个软件的逻辑其实不复杂我用一句话概括监听按键 → 匹配对应语音 → 播放出来。但要把这条链路做稳中间有不少细节。我把它拆成几个模块按键监听模块持续检测 GPIO 电平变化做去抖处理。语音资源管理每个按键对应一段语音文件或一段待合成的文本。语音合成/播放模块把文本变成声音或者直接播放预录文件。状态反馈模块按键按下时给个提示音或 LED 反馈让用户知道“系统收到了”。为什么要有状态反馈因为如果按下去没反应用户会以为坏了然后反复猛按反而触发多次播放。加一个短促的“嘀”声或者 LED 闪一下体验会好很多。这是我在实际使用中才意识到的纯功能实现时根本想不到。3.2 按键去抖一个必须处理的问题机械按键在按下和松开的瞬间电平会抖动程序可能把一次按下识别成好几次。软件去抖的常见做法是检测到电平变化后等待 20~50 毫秒再读一次如果状态一致才认为是有效按下。import RPi.GPIO as GPIO import time GPIO.setmode(GPIO.BCM) BUTTON_PIN 17 GPIO.setup(BUTTON_PIN, GPIO.IN, pull_up_downGPIO.PUD_UP) def wait_for_press(pin): while GPIO.input(pin) GPIO.HIGH: time.sleep(0.01) time.sleep(0.03) # 去抖 if GPIO.input(pin) GPIO.LOW: return True return False这段代码是最基础的版本。实际用的时候我建议用gpiozero库它内置了去抖和事件回调写起来更省心from gpiozero import Button from signal import pause button Button(17, bounce_time0.05) def on_press(): print(按键被按下) button.when_pressed on_press pause()bounce_time0.05就是 50 毫秒去抖实测很稳。用库的好处是它帮你处理了很多边界情况不用自己造轮子。3.3 语音资源的组织方式我一开始想的是“每个按键对应一段预录的语音”让家属用手机录好常用句子比如“我想喝水”“我要上厕所”“帮我翻个身”“我有点疼”。这种方式的好处是声音熟悉、自然长辈听着亲切。缺点是内容固定想改就得重新录。后来我加了一个“文本转语音”的通道家属可以直接输入文字系统合成语音。这样灵活性大大提高但合成音的自然度就成了关键。这就引出了下一节要重点聊的语音合成选型。资源目录我这样组织/audio/ ├── preset/ │ ├── water.wav │ ├── toilet.wav │ └── pain.wav └── tts_cache/ └── (动态合成的缓存文件)预录文件放preset动态合成的放tts_cache方便区分和管理。4. 语音合成怎么选在线、离线与本地部署的取舍4.1 三种路线的对比语音合成这块我试了好几种方案踩的坑最多也最有分享价值。大致分三条路线路线代表方案优点缺点在线云合成各类云端 TTS 接口音质好、自然依赖网络、有隐私顾虑、可能收费本地轻量合成eSpeak、Festival完全离线、免费机械感强、听着累本地神经网络合成本地部署的语音模型音质接近云端、离线吃算力、部署复杂对于这个项目我的结论是如果树莓派性能允许优先考虑本地部署的神经网络语音合成。原因有两个。第一这是放在卧室床边的设备涉及个人隐私语音内容不该往外传。第二医院或家里网络不一定稳定依赖网络意味着关键时刻可能掉链子。4.2 本地部署语音模型的现实考量最近“本地部署 sense voice”“voice studio”这类词讨论度很高本质上都是想把高质量的语音能力搬到本地设备上。我在树莓派 4B 上试过几种本地合成方案说点实在的体验。轻量级的方案比如 eSpeak NG安装简单、资源占用极低但声音非常机械像早期导航仪。长辈听这种声音会觉得“冷冰冰”接受度不高。神经网络方案音质好很多但对算力有要求。树莓派 4B 跑一些优化过的模型合成一句话大概需要一两秒这个延迟在“按键说话”的场景里是可以接受的因为用户按完键本来就有个心理预期。这里有个关键取舍预录语音 vs 实时合成。我的做法是混合使用。高频、固定的句子用预录保证零延迟、音色亲切临时想说的话用本地合成保证灵活性。这样既照顾了体验又控制了算力压力。注意本地部署语音模型时一定要先确认模型的授权协议确保在个人和辅助用途下可以合法使用。另外模型文件往往比较大microSD 卡要留足空间。4.3 音频播放的稳定性处理播放音频看起来简单其实也有坑。我用的是pygame.mixer来播放因为它对多种格式支持好控制也灵活。import pygame pygame.mixer.init() pygame.mixer.music.load(/audio/preset/water.wav) pygame.mixer.music.play() while pygame.mixer.music.get_busy(): pygame.time.Clock().tick(10)这段代码能保证播放完整再继续。如果不加get_busy的等待程序可能在音频还没播完时就进入下一轮监听导致声音被截断。这个细节在快速连按时特别明显。另外多个按键同时按下时要有优先级或者互斥处理否则会出现两段语音叠在一起听不清。我的做法是加一个“正在播放”的标志位播放期间忽略新的按键或者用队列排队。5. 实际部署中的那些坑从实验室到床边的距离5.1 开机自启与断电恢复装置是要长期放在床边的不可能每次都手动登录系统去启动程序。所以必须配置开机自启。我用的是 systemd 服务比改rc.local更规范也方便管理。[Unit] DescriptionStroke Communication Aid Aftersound.target [Service] ExecStart/usr/bin/python3 /home/pi/aid/main.py WorkingDirectory/home/pi/aid Restartalways Userpi [Install] WantedBymulti-user.targetRestartalways很关键。万一程序因为某个异常崩了systemd 会自动把它拉起来用户完全无感知。这个在长期运行里太重要了我遇到过好几次因为音频设备占用导致的崩溃全靠自动重启兜住。断电恢复也是同理。家里难免跳闸或者插头被碰掉重新通电后系统要能自动回到待命状态不需要人工干预。这一点在给老人用的设备上是硬性要求。5.2 声音太小、底噪太大怎么办音频输出这块我折腾了很久。一开始用 3.5mm 接口接小音箱底噪很明显安静环境下“嘶嘶”声很烦人。后来换成 USB 声卡加 USB 音箱底噪小了很多。原因是树莓派的 3.5mm 输出本身质量一般容易受板载电路干扰。音量方面除了系统音量还要在播放层面做归一化。不同来源的音频响度不一样预录的句子可能偏小合成的可能偏大。我用ffmpeg批量做了响度归一化ffmpeg -i input.wav -af loudnormI-16:TP-1.5:LRA11 output.wav这样所有音频的响度基本一致用户不会因为某句话突然变大或变小而吓一跳。5.3 用户误触与重复触发老人手抖或者无意识动作可能会反复碰到按键。如果每次碰都播放会很吵。我加了一个“冷却时间”同一个按键在 2 秒内只响应一次。另外长按和短按可以区分不同功能比如短按播放长按进入“取消”或“重播”。还有一个细节按键的物理位置。我一开始把按键排成一排结果发现长辈分不清哪个是哪个。后来改成用不同颜色、不同大小的按键并且在按键旁边贴了大字标签。视觉和触觉的双重提示能显著降低误操作。6. 让装置真正“好用”的交互设计心得6.1 减少认知负担比增加功能更重要做辅助设备最容易犯的错就是功能越加越多。我一开始想加语音识别、想加屏幕显示、想加联网通知后来发现每加一个功能用户的学习成本就上升一点。对语言障碍的用户来说简单、可预测才是第一位的。最后我砍到只剩最核心的功能几个大按键按一下说一句话。没有菜单、没有设置界面、没有复杂交互。家属要改内容通过手机或电脑连到树莓派上改配置文件就行用户端永远保持极简。6.2 语音内容的措辞很有讲究这一点是我和言语康复师聊过之后才意识到的。同样一个意思措辞不同沟通效果差别很大。比如“我要上厕所”比“厕所”更完整、更有礼貌也更容易被护理人员正确理解。语音内容应该是完整的句子而不是零散的词。另外语速要偏慢吐字要清晰。合成语音时适当放慢语速、增加停顿能显著提升可懂度。我在合成参数里把语速调到正常语速的 85% 左右长辈反馈听起来舒服很多。6.3 家属端的维护体验同样重要设备是给患者用的但维护它的是家属。如果家属改一句话要折腾半天这个设备很快就会被闲置。所以我把配置做成了简单的文本文件家属用记事本就能改{ buttons: [ {pin: 17, type: preset, file: water.wav, label: 喝水}, {pin: 27, type: tts, text: 我有点不舒服请帮我叫护士, label: 求助} ] }改完保存重启服务就生效。不需要懂编程不需要重新烧录系统。这个设计让设备真正能被长期用下去。7. 这个项目还能往哪些方向延伸7.1 加入本地语音识别做双向沟通目前装置只解决了“表达”这一半另一半是“理解”。如果加上本地语音识别把对方说的话转成大字显示在屏幕上就能形成双向沟通。这也是为什么我一开始选了 4GB 内存的树莓派就是给识别留的余量。本地识别同样涉及隐私和算力问题思路和语音合成类似优先本地、优先离线。7.2 用传感器做“无接触”触发对于手部活动严重受限的用户按键可能还是太难。可以考虑用红外或超声波传感器检测到挥手动作就触发。或者用吹气传感器对着管子吹一下就能说话。这些方案我在一些无障碍项目里见过思路很值得借鉴。7.3 记录使用数据辅助康复评估装置可以记录每个按键的使用频率和时间分布这些数据对康复评估有参考价值。比如某个表达用得特别多说明这个需求强烈某个时间段使用集中可能和用药或作息有关。当然这些数据的采集和使用要严格保护隐私只给家属和专业人员看。8. 一些掏心窝子的经验做这个项目最大的体会是技术实现只是冰山一角真正难的是理解使用者的真实处境。我一开始满脑子想的是怎么把语音合成做得更自然、怎么把代码写得更优雅但长辈真正在意的是“按下去有没有反应”“声音听着舒不舒服”“会不会按错”。如果你也想做类似的东西我的建议是先别急着写代码花时间观察使用者的日常。看他什么时候最需要表达、最常表达什么、手部动作能做到什么程度。这些观察会直接决定你的设计方向比任何技术选型都重要。另外别追求一步到位。我的装置到现在还在改按键布局调过三次语音内容换过好几轮。辅助设备就是这样得跟着使用者的状态一起演进。把它当成一个持续打磨的过程而不是一个交付即完成的产品。最后说个小事。装置做好那天长辈按了一下“我想喝水”的按键音箱里传出清晰的声音他愣了一下然后笑了。那一刻我觉得这两个月的折腾都值了。技术能做的事情有限但哪怕只是帮人把一句话说清楚也是有意义的。
