ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

基于 Azure IoT Hub 与 Functions 构建双语通用翻译器:IoT-For-Beginners 消费者课程结课实战

2026/9/15 17:53:49 拓冰建站 浏览量
基于 Azure IoT Hub 与 Functions 构建双语通用翻译器:IoT-For-Beginners 消费者课程结课实战 基于 Azure IoT Hub 与 Functions 构建双语通用翻译器IoT-For-Beginners 消费者课程结课实战【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners导读本文面向 IoT-For-Beginners 项目 消费者Consumer 系列第 4 课《支持多语言》6-consumer/lessons/4-multiple-language-support的课后作业系统讲解如何用2 台 IoT 设备搭建一个通用翻译器Universal Translator设备 A 采集用户语音并转写为文本经由 IoT Hub 与 Functions 无服务器应用送达设备 B再由设备 B 完成翻译并以语音播放实现不同语言使用者之间的实时沟通。读完本文你将掌握语音转文本Speech-to-Text、IoT Hub 消息路由、Azure Functions 中继与文本翻译Translator以及文本转语音Text-to-Speech的端到端串联方法并了解设备语言注册与 Azure Storage 配置存储等进阶设计。一、作业目标与端到端架构本作业要求利用前几课语音识别、语言理解、语音反馈学到的全部技能实现一个真实可运行的通用翻译器。核心需求如下将1 台设备配置为语言 A如法语另 1 台配置为语言 B如英语每台设备依次完成采集语音 → 语音转文本 → 通过 IoT Hub 与 Functions 应用把文本发给另一台设备 → 翻译文本 → 播放翻译后的语音如果只有 1 台实体硬件可按前几课的步骤把第 2 台设备配置为虚拟 IoT 设备Virtual IoT Device不影响整个作业的完成。整个系统可以抽象为一条清晰的消息流水线设备A(法语) --录音-- STT转写 -- IoT Hub -- Functions应用 -- 翻译 -- IoT Hub -- 设备B(英语) -- TTS语音播放对应到本仓库课程中使用的 Smart Timer 项目Raspberry Pi 的 app.py 与 虚拟设备 app.py 是理解这一链路的最佳参考实现设备端负责capture_audio→convert_speech_to_text→translate_text→device_client.send_message云端 Functions 负责解析意图、生成响应文本最终设备端调用 TTS 播放。上图来自本课 README展示了翻译注入式的多语言应用架构只在外围语音识别入口与语音播报出口做翻译核心业务逻辑仍以单一语言运行从而快速为应用增加新语言支持。二、前置知识本作业依赖的四项 AI 能力作业明确要求使用过去几课学到的内容这四项能力缺一不可语音转文本Speech-to-Text把用户语音转为文本是翻译器识别输入的入口第 1 课语言理解Language Understanding / LUIS理解用户意图如设置一个 2 分 27 秒的定时器第 2 课文本转语音Text-to-Speech把响应文本合成为语音播放第 3 课文本翻译Translation本课新增能力把文本从一种语言翻译为另一种是整个翻译器的核心。值得一提的是AzureSpeech 服务本身就支持识别 翻译二合一在 虚拟设备教程 中通过SpeechTranslationConfig与TranslationRecognizer一次识别即可同时拿到源语言文本与目标语言翻译结果。这是翻译器快速实现的一种捷径而对 Wio Terminal 这类微控制器语音 SDK 不可用则改用REST API Functions 中继的方式详见下文第五节。三、翻译技术基础从机器翻译到神经翻译在动手编码前理解翻译原理有助于你调试时判断翻译结果为何与预期不同。语言对Language Pair翻译服务按一对语言提供能力不同服务支持的组合可能不完整。例如某个翻译器支持英↔西、西↔意却不支持英↔意翻译时务必确认你的两个语种组合可用。机器翻译Machine Translation, MT早期技术通过词典替换加规则库完成翻译。对 Hello world→法语 这类简单句有效但遇到语序不同的句子如英文 My name is Jim → 法语 Je mappelle Jim字面意为I call myself Jim就会出错成语更是重灾区英文 Ive got ants in my pants 直译到德语会让听众困惑。统计机器翻译用大规模人工翻译语料网页、书籍、联合国文件等做统计选优常借助中间语言表示让新增语言只需与中间语言互译。神经翻译Neural Translation用单个模型翻译整句模型通常比规则库更小。现代翻译服务多为统计方法与神经方法的混合体。需要特别留意两点本课 README 明确提示翻译不存在 1:1 精确对应不同模型因训练数据不同会给出略有差异的结果翻译不一定对称——把一句话从 A 翻译到 B 再翻回 A得到的句子可能略有出入。这直接决定了作业验收时设备端听到的播报文字与 LUIS 训练例句不完全一致是正常现象如偏差过大可向 LUIS 补充更多同义例句后重新训练发布。四、创建翻译资源Translator 服务作业要求两端设备互译因此需要为项目创建独立的Translator 认知服务资源Speech 服务的 REST API 不内置翻译能力只有 SDK 支持。课程 README 给出的创建命令如下az cognitiveservices account create --name smart-timer-translator \ --resource-group smart-timer \ --kind TextTranslation \ --sku F0 \ --yes \ --location location参数说明参数含义--name资源名称示例中使用smart-timer-translator--resource-group资源组与本系列课程一致使用smart-timer--kind资源类型翻译服务固定为TextTranslation--sku定价层F0为免费层适合课程实验--location创建资源组时使用的区域创建完成后用以下命令获取 API Keyaz cognitiveservices account keys list --name smart-timer-translator \ --resource-group smart-timer \ --output table复制其中一个 Key 备用。在 Functions 项目中该 Key 与区域会被写入 local.settings.jsonTRANSLATOR_KEY: key, TRANSLATOR_LOCATION: location在代码中API 的调用形式为url https://api.cognitive.microsofttranslator.com/translate?api-version3.0 headers { Ocp-Apim-Subscription-Key: translator_api_key, Ocp-Apim-Subscription-Region: location, Content-type: application/json }注意两个细节该 API 的 URL 不区分区域区域通过请求头Ocp-Apim-Subscription-Key-Region传递使用 API Key 直连无需像语音服务那样先去令牌服务换取 access token。五、三种设备实现路径与源码对照作业可以跑在 Wio TerminalArduino、树莓派Python或纯虚拟设备上仓库为三种形态都提供了完整实现与逐步教程。核心思路一致语音入口从用户语言翻译到服务语言LUIS 训练语言语音出口再从服务语言翻译回用户语言。代码中对应两个关键变量language user language # 用户所说语言如 fr-FR server_language server language # LUIS 训练语言如 en-US语种采用 locale 名称例如法语fr-FR、粤语zh-HK支持的语种与 locale 清单以官方语音服务文档为准。若你不会第二外语可用 Bing Translate / Google Translate 先把训练例句翻译成目标语言再用其听翻译功能朗读进麦克风模拟外语输入。5.1 Wio TerminalFunctions 中继 HTTPClient微控制器内存有限无法直接用 Translator REST API因此仓库把翻译封装成一个名为translate-text的 HTTP 触发器。先用 Azure Functions Core Tools 创建触发器func new --name translate-text --template HTTP trigger其完整实现见 translate-text/init.py从请求体取出from_language、to_language、text构造上述 REST 调用把第一个翻译结果作为响应文本返回。可用 curl 以如下 JSON 体自测{ text: Définir une minuterie de 30 secondes, from_language: fr-FR, to_language: en-US }设备端则在 text_translator.h 中定义TextTranslator::translateText用 ArduinoJson 序列化请求体HTTPClient.POST调用 config.h 中配置的TRANSLATE_FUNCTION_URLHTTP 200 时取回翻译文本否则打印错误码。随后在main.cpp中分别在say函数首行服务语言→用户语言和processAudio的convertSpeechToText()之后用户语言→服务语言各调用一次翻译。5.2 树莓派直接调用 Translator REST API树莓派走 Python直接在 app.py 中实现translate_text(text, from_language, to_language)请求参数与响应解析如下params { from: from_language, to: to_language } body [{ text : text }] response requests.post(url, headersheaders, paramsparams, jsonbody) return response.json()[0][translations][0][text]要点body是数组一次调用可翻译多段文本返回的 JSON 同样是数组第一个元素的translations数组中按请求顺序给出各段翻译。在while True主循环中识别出的文本先打印原文再从用户语言翻译到服务语言后经 IoT Hub 上报say函数则先打印原文再从服务语言翻译到用户语言再走 TTS 播放。详细步骤见 pi-translate-speech.md。5.3 虚拟设备Speech SDK 一次识别即翻译虚拟设备是三种路径中最省事的方案也正好满足作业两台设备之一可为虚拟设备的要求。见 virtual-device-translate-speech.mdtranslation_config SpeechTranslationConfig(subscriptionspeech_api_key, regionlocation, speech_recognition_languagelanguage, target_languages(language, server_language)) recognizer TranslationRecognizer(translation_configtranslation_config)在recognized事件回调中从args.result.translations字典按服务语言取翻译文本并上报 IoT Hubif args.result.reason speech.ResultReason.TranslatedSpeech: language_match next(l for l in args.result.translations if server_language.lower().startswith(l.lower())) text args.result.translations[language_match]经验提示源语言也必须出现在target_languages中否则拿不到翻译结果且translations字典的键是 locale 的语言部分如fr而非完整 localefr-FR匹配时要用startswith这类前缀判断。由于 Speech SDK 的翻译只覆盖识别方向语音播报文本仍需要 Translator REST API 翻译该部分的translate_text实现与树莓派一致。六、把作业升级为真正的通用翻译器作业正文提供的提示 Tip给出了超越最小可行版的进阶设计这也是评分中Exemplary出色档的差异化所在随消息携带语言元数据从设备 A 发往设备 B 的消息不应只有文本还应包含该文本是什么语言否则接收端无法决定翻译目标。设备注册 Azure Storage 存储语言配置让每台设备在启动时先通过 IoT Hub Functions 应用注册自己支持的语种把该配置持久化到 Azure Storage翻译动作由 Functions 应用统一承接——收到设备 A 的语音文本后从存储读取设备 B 注册的语言翻译完成后再把译文发回设备 B。这样两端设备无需互相知道对方语言新增一台设备、新增一种语言都只改存储配置符合翻译注入式架构的精髓。消息流向的两种选择既可以让语音文本在 Functions 内完成翻译后由 IoT Hub 下发Cloud-to-Device也可以沿用本课 Smart Timer 的既有链路设备→Functions→设备前者更贴近翻译器中继语义。实现时可复用本课 Functions 项目中的既有触发器作为模板如 text-to-speech/init.py 展示了如何从环境变量读取密钥、如何生成 SSML 并返回 WAV 音频流把translate-text触发器扩展为查语言→翻译→下发的完整编排。七、运行验证与预期输出完整链路调试顺序建议先本地运行 Functions 应用func start确保translate-text、text-to-speech等触发器可被 curl 调用再启动设备端程序让两台设备分别注册语种最后在设备 A 前说一句目标语言指令观察设备 B 是否以另一种语言语音播报。本课教程给出了 Wio Terminal 串口监视器的真实运行样例法语↔英语Translating Définir une minuterie de 2 minutes 27 secondes. from fr-FR to en-US Translated: Set a timer of 2 minutes 27 seconds. Translating 2 minute 27 second timer started. from en-US to fr-FR Translated: 2 minute 27 seconde minute a commencé. Translating Times up on your 2 minute 27 second timer. from en-US to fr-FR Translated: Chronométrant votre minuterie de 2 minutes 27 secondes.可以看到翻译不对称现象确实存在英文回译成法语的句子与地道法语表达有差异这正是本课反复强调的机器翻译特性也是作业验收时对翻译质量应有的合理预期。八、作业评分标准对照本作业的评分Rubric只有一条主线标准三个档位供自测标准出色Exemplary达标Adequate待改进Needs Improvement创建通用翻译器成功实现完整链路一台设备采集的语音在另一台设备上以不同语言语音播放只跑通部分组件如仅语音采集或仅翻译未能打通端到端未完成任何可工作的功能部分对照自检清单① 两端设备是否分别绑定不同语种② 语音→文本→IoT Hub→Functions→翻译→文本→语音的全链路是否贯通③ 消息中是否携带语言信息、语言配置是否可由存储动态管理对应出色档。九、课程收尾清理云资源本课是消费者系列的最后一课作业完成后应清理所用云服务尤其注意先完成作业再清理否则资源不可复用。清理步骤可参照仓库根目录的 clean-up.md 指南释放 IoT Hub、Functions 应用、LUIS、Speech 与 Translator 等资源避免产生持续费用。十、延伸思考作业的 Challenge 提出了一个很好的开放问题机器翻译除了语音还能以哪些方式惠及其他 IoT 场景例如设备上报的遥测文本错误码、日志的多语言化、跨地区协作的工业看板实时翻译、机场/医院等公共场所的无障碍信息播报等都是翻译注入式架构可复用的落点。本文所述的消息链路——采集、上传、云端处理、下发、播报——本身就是一套可移植的多语言 IoT 应用骨架。【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考