尧图网页设计 
1. 项目概述一直关注宇树G1这台机器人的朋友应该清楚它在人形机器人里算是把性价比和可玩性拉满的一个存在。相比上一代或者同级别的其他平台G1不仅硬件开放度高而且官方提供的Unitree SDK几乎覆盖了底层关节控制、状态读取、运动控制等所有关键接口。但很多和我一样做过二次开发的人都有个共同的痛点官方SDK给到的是底层运动控制和基础状态接口想让G1真正“听懂人话”“和人对话”甚至做到对话中随时被打断、重新唤醒这些能力官方并没有直接给出一套开箱即用的方案。这就需要一个相对完整的二次开发链路来补齐。本文想聊的就是把“语音对话、打断与激活”这三件事在宇树G1上真正跑通的方法。我的思路很简单不改动G1本身的底层运动控制而是在它的外部计算单元就是G1头部或者背部搭载的工控机也可以是你自己外接的一台Linux主机上搭建一个语音交互中间层。这个中间层向下通过SDK连接机器人实时状态向上对接语音识别ASR、大语言模型LLM和语音合成TTS最终实现你叫它的名字它就醒来你说话它能听懂并回答你中途插嘴它能立刻停止当前播报并重新聆听。这篇文章适合谁已经能跑通G1基础运动SDK、想进一步提升交互体验的开发者或者是做机器人语音交互产品原型验证的工程师。我会尽量把架构选型、代码实现、参数调节这些关键细节都写清楚不绕弯子直接给可以抄作业的方案。先说下我用的整体配置供参考宇树G1系统镜像版本为官方出厂版本SDK使用Unitree Robot SDK支持C和Python这里用Python外部算力G1板载工控机或者通过千兆网口连接的独立Linux主机Ubuntu 20.04/22.04均可语音链路本地麦克风阵列拾音ASR服务用本地Whisper模型LLM用GPT系列APITTS用本地Edge TTS或者线上TTS服务中间层开发框架ROS 2 Humble 自研状态机节点整个项目从零到跑通花了大概两个周末。最花时间的不是代码本身而是音频回环延迟的处理和打断策略的细节调优。这些经验我都会在后面的章节展开能帮你少走很多弯路。2. 项目整体设计与技术架构拆解2.1 为什么选择外部中间层方案而不是魔改G1内部系统在动手之前我和不少做机器人开发的朋友聊过大家的第一个问题几乎都是能不能直接在G1的系统里装语音引擎其实可以但我不推荐。原因有三点。第一G1内部工控机的资源是给实时运动控制预留的。跑语音识别模型尤其是本地方言模型或者大一点的Whisper模型CPU占用会直接飙上去严重的会导致关节控制指令周期不稳定机器人会出现卡顿甚至抖动。万一在调试语音时机器人突然来个不规律动作轻则吓一跳重则设备受损。第二G1的系统环境是宇树定制的稳定性优先换源、装依赖、升级库都得相当谨慎。一旦把系统环境搞坏了恢复出厂镜像重来很麻烦而且可能影响运动控制固件的匹配。第三从架构上看语音交互和运动控制本来就是两个关注点不同的子系统。运动控制要求实时性和确定性语音交互要求模型灵活迭代和网络连通性。把两边在逻辑上分离后续升级ASR模型、换更大的LLM、改唤醒词都不用动运动控制那一层这个解耦带来的收益在做长期迭代时非常明显。所以最终定的架构是G1本体只负责任务执行和运动反馈外部中间层负责所有语音相关的能力。两者之间通过Unitree SDK的Userport用户自定义通信端口通信这个端口本身是官方预留出来做功能扩展的不会被内部运动控制逻辑干扰。2.2 语音交互链路的核心模块拆解一个完整的语音对话链路拆开来看其实是四个串行的环节拾音、识别、语义理解与生成、合成播报。放到机器人场景下还要加两个隐形的环节状态管理和打断仲裁。先看拾音G1本身没有内置麦克风阵列所以需要在外部中间层接USB麦克风阵列或者独立麦克风。我实测下来做机器人语音交互不是随便拿个单麦就能用的。G1工作的时候关节电机、散热风扇都有不小的噪声单麦在1米外基本就废了。我最终用的是带回声消除AEC功能的四麦阵列实测在1.5米内正常音量说话识别率能到90%以上。识别和合成这一块方案上可以走全云端也可以走本地加云端的混合方案。我的选择是本地ASR加云端LLM。ASR选用的是的Whisper large-v3模型在本地用TensorRT加速单句识别延迟控制在800毫秒以内。虽然云端方言识别效果更好但机器人交互场景对延迟很敏感一次完整对话加两秒多的网络往返体感就很差了。LLM部分直接接云端APITTS用Edge TTS单句合成延迟大约500毫秒。打断仲裁这一点是语音交互体验的分水岭。很多初做机器人的朋友把ASR、LLM、TTS串在一起跑通了就以为完事了结果真人和机器人聊起来会发现非常尴尬机器人正在长篇大论你插了一句“停一下”它完全没反应必须等它说完才能再下指令。这个问题我在第四章会详细拆解核心思路是引入独立的语音活动检测VAD组件做低延迟抢断。整个架构图如果用一句话概括G1是身体中间层是耳朵和嘴巴LLM是大脑而打断仲裁是反射弧。身体和反射弧之间通过SDK桥接这层设计让单点替换成为可能。2.3 核心选型对比与理由语音引擎选型可以直接决定项目开发周期和最终体验这部分我把自己对比过的方案和感受列出来方便你做决策。模块方案选项实测感受推荐理由ASR云端方案讯飞/阿里识别准确率高方言好但单次往返延迟1.5-2.5s适合对硬件要求低、网络好的场景ASR本地WhisperTensorRT加速单句800ms内环境噪音适应性中等需要配置较好的CPU/GPU延迟可控不依赖外网适合机器人本地闭环LLM云端GPT/文心等语义理解强但响应有1-3s变量延迟几乎必须用云端本地小模型在复杂对话场景撑不住LLM本地Qwen系列量化版隐私性最好延迟可接受但复杂指令遵循弱一些对数据敏感场景可以选TTSEdge TTS语音自然度高、部署简单、免费有轻微网络依赖最适合作原型和大多数商业场景TTS本地方向合成方案延迟最低但音色质量参差不齐只有在纯离线要求下才用唤醒自研关键词唤醒可控性强可以灵活配置多唤醒词必须自己实现这是机器人交互的入口我最终的选择是本地Whisper 云端LLM Edge TTS。这条组合路线兼顾了延迟、效果和开发效率。补一句如果你做的是纯展示用的原型不走大模型直接接个预设问答脚本也是完全可以的架构不用变只需要把LLM模块换成检索式问答逻辑。3. 环境准备与基础调试3.1 开发环境清单和软件依赖开发之前请先把环境列清楚我这边踩过的坑大多和依赖版本不匹配有关。以下是我调试通过的软件环境建议你尽量在相同大版本下操作操作系统Ubuntu 20.04 LTS或22.04 LTS64位Python版本3.8以上我用的3.10ROS 2版本Humble Hawksbill如果你不打算用ROS也可以但ROS能省掉很多线程通信的事Unitree SDK官方最新版本Python绑定需要编译安装音频框架PortAudio/PyAudiosounddevice用于录音和播放语音识别OpenAI Whisper本地版版本为2023年以后的大模型版本VAD检测silero-vad轻量级识别效果好延迟低LLM调用OpenAI Python SDK或者国内大模型兼容接口的SDK文本转语音edge-tts库或者你自己找到的其他TTS SDK提示先把上述依赖都装好再开始写业务代码。我自己因为中途补依赖遇到过不少很隐蔽的冲突比如PyAudio的底层库和PortAudio版本不匹配导致录音设备打不开查了半天才发现是系统里有两套libportaudio。安装步骤这里只做简要展开。ROS 2 Humble按官方文档安装即可Ubuntu 22.04直接apt源里装最省事。Whisper的安装我建议用pip装openai-whisper然后额外装tensorrt和onnxruntime做推理加速。silero-vad直接用pip安装torch版本它会自动下载模型权重。# 安装系统基础依赖 sudo apt update sudo apt install portaudio19-dev python3-pyaudio python3-dev python3-pip # Python依赖 pip install sounddevice numpy scipy websockets pip install openai-whisper edge-tts pip install silero-vad torch pip install openai # 或者你用的国内大模型SDK pip install unitree-sdk2-python # 宇树官方Python SDK3.2 麦克风阵列连接与音频参数调优G1本体没有麦克风所以拾音设备需要独立接入。这一步看着简单实际上音频参数的调试是个耐心活。先把USB麦克风阵列插到中间层主机上然后我用sounddevice库列出所有音频设备确认录音和播放的默认设备编号。import sounddevice as sd print(sd.query_devices())输出结果里重点看每个设备的默认采样率。常用的USB麦克风阵列一般支持16000Hz和48000Hz。这里就有一个大坑Whisper模型在16000Hz采样率下识别效果最好而很多USB声卡默认输出是48000Hz。如果你直接拿48000Hz的音频往Whisper里送识别结果会惨不忍睹甚至完全乱码。解决方式是做一次重采样。我习惯使用scipy的resample_poly函数把48000Hz降采样到16000Hz再送入Whisper。必须要说重采样的质量也会影响识别率建议用抗混叠滤波选项。from scipy import signal import numpy as np def resample_audio(audio: np.ndarray, orig_rate: int, target_rate: int) - np.ndarray: # 使用scipy的多相重采样抗混叠效果好比线性插值稳很多 number_of_samples round(len(audio) * float(target_rate) / orig_rate) resampled_audio signal.resample_poly(audio, target_rate, orig_rate, axis0) return resampled_audio.astype(np.float32)除了采样率还有两个参数非常关键一是块大小chunk size这决定录音的实时性。我设置的是1600个采样点在16000Hz下刚好是100毫秒的音频块。这个粒度足够细既能保证VAD及时响应又不会因为块太小导致CPU频繁切换线程。二是回声消除。如果G1在播报语音时麦克风把播报声音也录进去就会造成“机器人自己说话自己听”的严重干扰。好的麦克风阵列硬件会内置AEC但实测下来单纯依赖硬件还不够我在播报和录音之间做了软件互斥播报期间不录音播报结束后留200毫秒的余量再恢复录音。这会导致一个问题就是播报完成后立即说话的内容可能被截掉但比较下来这个代价是可以接受的总比回声把识别器搞疯强。3.3 宇树G1 SDK连接与运动状态监听G1的Unitree SDK走的是网络通信中间层主机和G1需要在同一局域网下或者直连千兆网口。官方Python SDK封装好了运动控制和状态上报的接口我这里只讲语音交互用到的部分。先做最低限度的连接验证确保SDK能正常读取G1状态。from unitree_sdk2py.core.channel import ChannelFactoryInitialize from unitree_sdk2py.idl.unitree_hg.msg.dds_ import LowState_ from unitree_sdk2py.g1.g1_client import G1Client # 初始化通信信道注意这里的网络配置要和G1实际IP对应 ChannelFactoryInitialize(0, eth0) client G1Client() state LowState_() client.GetLowState(state) # 打印一下当前关节状态确认连接正常 print(电机数量, len(state.motor_state)) print(第一个关节角度(rad), state.motor_state[0].q)跑通这个就说明SDK链路是通的。语音交互层里需要实时知道的状态主要是两个G1当前是否处于运动状态比如是否正在走路、转头以及是否正在执行某个动作的播报。前者可以从关节角速度判断后者则需要在动作执行代码里自己维护一个标志位。为了不干扰SDK原本的运动控制逻辑我单独起了一个线程以50Hz的频率读取LowState把关节运动状态缓存在全局变量里。语音对话链路只有在机器人处于空闲状态时才允许播放语音回复。注意语音对话期间不建议同时跑比较剧烈的运动控制。因为G1在运动过程中电机的噪声传播到麦克风识别率会急剧下降。我的经验是对话时让G1保持站立稳定等指令明确后再执行动作执行动作时不要播报长语音真要播报也等电机停下来再说。4. 语音对话链路实现4.1 唤醒词检测与激活机制设计“激活”这个词在机器人语音交互里有特殊含义它指的是让机器人从待机状态转为聆听状态。不是7x24小时都在听那样功耗和误唤醒都受不了而是有策略地唤醒。我实现了三层激活机制从轻到重第一层是物理按键激活优先级最高但使用频率最低。G1的外接按钮直接连到中间层GPIO上按下后立即打断当前一切语音播报并开始录音这相当于一个“强制抢麦”按钮。第二层是关键词唤醒是用户日常使用最频繁的方式。在这里我用了自研唤醒词检测没有用通用的“小X小X”那套。为什么不用现成的唤醒引擎因为那些引擎通常要求重训或者配置大模型反而不好适配G1这种需要低延迟和自定义词表的场景。我的唤醒词检测方案是先跑一个轻量的VAD检测到人声片段后把片段前0.8秒的音频用一个小型语音嵌入模型提取特征和预设的唤醒词特征做余弦相似度。相似度超过阈值就触发唤醒。这个方案的好处是延迟极低大约300毫秒就能判定而且可以在本地换不同的唤醒词。from silero_vad import load_silero_vad import torch model_vad load_silero_vad() def detect_wakeword(audio_chunk, threshold0.72): # 先用VAD检测是否有人声活动 confidence model_vad(torch.from_numpy(audio_chunk), 16000).item() if confidence 0.5: return False # 再和人声嵌入特征做相似度判断 embedding extract_audio_embedding(audio_chunk) similarity cosine_similarity(embedding, WAKE_WORD_EMBEDDING) print(f唤醒词相似度: {similarity:.3f}) return similarity threshold第三层是说话即唤醒。当机器人处于“待命”状态但VAD检测到环境中有明确的语句式人声非唤醒词时也会自动进入聆听状态。这一层体验很微妙需要在灵敏度和误唤醒之间找到平衡。我设置的策略是VAD人声持续超过1.2秒且环境噪声低于阈值才判定为主动对话否则忽略。4.2 语音识别ASR模块的本地化部署与接口封装ASR是整个链路里技术含量最高也最容易出问题的一块。我用的本地Whisper large-v3模型在本方案里是按服务模式跑起来的通过HTTP接口和语音交互主程序通信这样模型只需要加载一次所有请求复用同一个推理会话避免每次都重新加载模型的巨大开销。模型推理服务的核心代码框架如下from fastapi import FastAPI, UploadFile import whisper import numpy as np app FastAPI() model whisper.load_model(large-v3) # 可以换成medium或small识别速度和精度权衡 app.post(/asr) async def asr_endpoint(file: UploadFile): audio_bytes await file.read() audio_np np.frombuffer(audio_bytes, dtypenp.int16).astype(np.float32) / 32768.0 result model.transcribe(audio_np, languagezh, fp16False) return {text: result[text]}注意上面代码里的fp16False这个在CPU推理时必须关掉否则会报错。如果是NVIDIA GPU推理可以把fp16打开速度能提升不少。Whisper模型体积大large-v3光权重就快3GB所以推理服务建议至少留4GB内存/显存。模型大小和识别速度的关系是这样的模型参数量显存占用单句延迟(CPU)单句延迟(GPU)tiny39M约1GB约0.3s约0.15ssmall244M约2GB约0.8s约0.3smedium769M约5GB约2s约0.8slarge-v31550M约10GB约5s约1.5s实际项目里如果你没有很强的GPU建议在“准确的medium”和“快速的small”之间选。G1机器人场景下交互体验优先我是用large-v3加GPU如果条件有限medium也够用。除了离线模型我也封装了云ASR接口作为备用通道。万一本地服务挂了或者遇到极其嘈杂的环境本地识别率明显下降可以自动切换云端。4.3 LLM对话与大模型接口对接设计可控的机器人“人设”LLM对接在这几个模块里反而是最简单的主要工作是设计提示词系统、处理流式输出和控制回复长度。我给G1设计的人设是一个简洁、专业、少说废话的机器人助手。对应地提示词里会明确要求模型用“我”自称回复控制在100字以内不要探讨抽象哲学问题遇到不确定的事直接说不知道。这些约束不是装饰是实际交互体验的需要。机器人回复拖沓用户根本等不住。流式输出这块我要多说一句。很多初学者直接等LLM把完整回复生成完再一次性播放这在对话场景下会造成很大的等待感。我改成了流式接收LLM每生成一小段文字就立即送到TTS模块合成语音播放。这样用户听到第一个音节的时间能提前至少40%体验完全不同。from openai import OpenAI client OpenAI( api_key你的key, base_url你的API地址 ) SYSTEM_PROMPT 你是G1机器人助手名字叫小宇。你正在通过语音与人交流。 回答要求 1. 第一人称用“我”称呼用户用“你” 2. 回答控制在100字以内口语化 3. 不知道的就说不知道不要编造 4. 不要输出任何代码或命令行内容 5. 如果用户让你做机器人动作输出[ACTION]标签加上动作名称 def generate_reply(user_text: str): stream client.chat.completions.create( modelgpt-4o-mini, # 或你实际使用的模型 messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_text} ], streamTrue, max_tokens250 ) for chunk in stream: delta chunk.choices[0].delta.content if delta: yield delta有一点务必留心就是你接的外部大模型API如果有内容安全过滤在机器人语音交互场景下可能会输出“抱歉我不能...”之类的拒答话术。这种话术通过机器人的嘴巴说出来体验很差。我在中间加了一层回复过滤检测到拒答话术时统一替换成一句“这个问题我还不太会你换个说法问我吧”。整个过程对用户是无感的。4.4 TTS语音合成与播放策略TTS模块我选择edge-tts因为它在中文语音的自然度上非常出色而且免费、部署简单。它其实是调用了微软Edge浏览器的在线语音合成接口对网络有依赖但稳定性在大多数情况下都够用。TTS服务同样走HTTP接口语音合成结果直接返回音频流。主程序拿到音频数据和文本一起播放。import edge_tts TEXT 你好我是小宇有什么可以帮你的 VOICE zh-CN-XiaoxiaoNeural communicate edge_tts.Communicate(TEXT, VOICE) await communicate.save(output.mp3)播放的时候有几个细节要注意。第一播放前要把音频数据解码为PCM格式否则播放库之间不兼容。edge-tts默认输出MP3格式用pydub或者ffmpeg转成wav再播放。第二播放音量要设定成合适值我实测G1的扬声器天生偏小需要软件放大到120%左右才听得清楚。第三播放过程和录音过程的互斥必须做好具体怎么做我放在打断章节一起讲。播放策略上我放弃了传统的“完整合成再播放”模式改成流式播放。每次从LLM拿到一小段增量文本立即合成对应的音频片段并排队播放。这样虽然有几百毫秒的片段间隙但用户的等待时间明显缩短。5. 打断与激活机制深度实现5.1 为什么打断是机器人交互体验的灵魂先说一个现象。很多刚接触语音机器人的朋友想当然地认为把“听懂并回答”这个链路做好就行打断是第一版不用管的。但真实场景里打断几乎决定了用户愿不愿意继续用这个东西对话。想象一下你问G1一个开放性问题它的LLM启动了开始滔滔不绝讲起几十秒的长篇回答。在这期间你意识到它理解偏了想纠正但是不管你怎么插话它都当没听见必须等它全部说完才能重新下指令。这种体验在真人对话里是荒唐的在机器人语音交互里却是默认状态。坏消息是实现打断功能比听起来复杂得多。因为整个链路里有多个环节TTS正在合成、音频正在播放、LLM可能还在继续生成内容、ASR处于待命状态。要在一个合适的时机暂停这些环节而且不能产生奇怪的音频残留就需要设计一套完整的状态切换机制。好消息是这套机制一旦建好它会成为整个交互架构的基础设施。后续想加音乐播放、动作指令并发、多轮对话管理都能直接复用这套打断仲裁逻辑。5.2 基于VAD的语音活动检测与打断触发打断的第一步是听到用户说话了。这里的“听到”不能靠ASR因为ASR要等人说完一整句才给结果那样打断的响应时间会超过两秒根本谈不上“即时”。必须用一个轻量级的VAD来实时检测人声活动。silero-vad是我测试过最适合做这件事的模型。它是一个小型神经网络输入10到30秒的音频片段输出一个0到1的人声置信度。单次推理在CPU上只要几毫秒完全可以做到实时。打断的判定逻辑是这样的TTS播放过程中持续采集麦克风音频流每一帧都跑vad。如果发现连续两帧约200毫秒的vad置信度超过0.6就认为用户说话意图强烈立刻触发打断。置信度阈值不能设太低否则机器人播报时周围环境稍微有点声音就会把它打断。VAD_THRESHOLD 0.6 VAD_FRAME_RATE 16000 FRAME_DURATION_MS 40 # 每帧40ms保证低延迟 FRAME_SIZE int(VAD_FRAME_RATE * FRAME_DURATION_MS / 1000) def process_interrupt_detection(audio_stream): trigger_count 0 for frame in audio_stream: confidence vad_model(torch.from_numpy(frame), VAD_FRAME_RATE).item() if confidence VAD_THRESHOLD: trigger_count 1 if trigger_count 2: print(检测到用户插话触发打断) emit_interrupt_event() return else: trigger_count 0打断动作本身需要协调多个模块。触发后要按顺序做这几件事停止当前TTS音频的播放立即不是等播放完取消LLM尚未完成的生成如果还在流式输出断开流连接清空ASR内部的待处理音频缓存切换到“聆听”状态开始录音缓存用户接下来的指令整个过程我要求在150毫秒内完成。实测代码跑下来从触发事件到所有模块停止大概在100到120毫秒用户感知就是“我一开口它马上闭嘴了”。5.3 播放录音互斥与多线程状态协同打断能跑通的前提是录音和播放不能同时进行。但在Linux下实现真正的互斥比想象的复杂。如果只依赖线程锁你会在实际运行中遇到各种音频设备抢占问题。我的做法是引入一个音频路由管理器把它作为所有音频流的唯一入口。管理器内部维护一个状态机IDLE空闲、LISTENING聆听中、SPEAKING播报中、INTERRUPTING打断中。其他模块不能直接操作音频设备只能向管理器发请求由管理器统一调度。这个设计有几个好处。一是打断逻辑可以集中在一个地方实现而不是散落在各个模块里。二是音频设备只有一个打开者不会出现“播放占用设备导致录音失败”这种问题。三是在调试时可以通过打印状态机来观察整个系统在做什么。状态切换的时机从IDLE到LISTENING唤醒词触发或用户主动按键。从LISTENING到SPEAKINGASR返回结果LLM生成了回复准备工作播放。从SPEAKING到INTERRUPTINGVAD检测到用户插话。从INTERRUPTING到LISTENING播放停止重新开始收音。用Python的asyncio来管理这个状态机既能保证并发安全又比纯线程好调试得多。我在实际项目中用asyncio.Lock和asyncio.Condition实现了状态同步代码里没有出现过一个暴露的死锁问题。5.4 激活状态机与超时管理和“打断”配套的是“激活”这里的激活不是指系统授权而是机器人从待命状态切换到可交互状态的整个机制。机器人不能24小时都在听人说话那样既浪费算力也会因为环境杂音频繁误触发。所以需要一个激活状态机管理什么时候听、什么时候不理人。我定义了四个状态STANDBY省电待命只运行唤醒词检测不录音、不识别。ATTENTIVE已唤醒开始录音并准备识别用户指令。THINKING正在调用LLM不需要麦克风录音但依然监控用户插话。RESPONDING正在播放TTS同时监控打断信号。从STANDBY到ATTENTIVE的触发条件是唤醒词得分超过阈值。从ATTENTIVE到THINKING是检测到用户说完了一句话。从THINKING到RESPONDING是LLM返回结果。从RESPONDING到ATTENTIVE是播报完毕或被用户打断。超时管理是这个状态机的核心逻辑。用户唤醒后长时间不说话不能一直等下去否则会听到环境噪音被当指令。我设置的规则是ATTENTIVE状态最长持续8秒超时自动返回STANDBYTHINKING状态最长15秒作为LLM调用的保护性超时RESPONDING状态没有硬超时但播报完会自动退出。这套超时参数是多次实测调出来的。8秒的聆听窗口比较合适太长会失去交互紧迫感太短用户组织语言的时间不够。6. 完整实操流程与代码实现6.1 中间层系统搭建与网络配置硬件层面我的推荐是给G1配一个Intel NUC或者类似的紧凑型工控机作为中间层。它通过千兆网线直接连G1的网口组成一个独立的局域网。麦克风阵列和扬声器都接在中间层上。网络配置上G1出厂默认IP一般为192.168.123.18或类似地址。中间层的网口IP要手动设为同一网段比如192.168.123.20网关设成空不要接外网避免路由冲突。语音对话所需的外网连接通过中间层的另一个无线网卡Wi-Fi走这样G1的运动控制网和外部语音网完全隔离互不干扰。# 中间层网口配置 sudo ip addr add 192.168.123.20/24 dev eth0 # 临时配置测试用 sudo ip link set eth0 up验证和G1的连通性ping 192.168.123.18通了之后再验证Unitree SDK的DDS通信。宇树G1的运动控制和状态通信基于DDS协议SDK内部会自动处理。你只需要确保通信端口不被本机防火墙拦截。Ubuntu上如果开了ufw需要开放对应端口否则你会发现SDK能初始化但始终收不到数据。6.2 语音服务部署与联调记录部署完成后的第一个联调我强烈建议不要直接上完整链路而是分模块测试。我当时的测试顺序是第一步单独测ASR。命令行录一段音频调asr接口看返回文本是否正确。这一步排除了音频采集和模型推理解码的问题。第二步单独测LLM。用curl直接调大模型接口确认网络和提示词没有问题。第三步单独测TTS。调用edge-tts合成一段文本播放确认音质和延迟都达标。第四步把ASR和LLM串起来做一个“我说一句它回一句”的纯文本对话测试。这个阶段不接机器人和TTS先验证中间环节的稳定性。第五步接上TTS做完整的语音对话闭环先用PC的麦克风和扬声器测本地延迟基本在1.2秒左右。最后一步再接上G1的SDK状态监听做机器人场景下的联调。这时候才需要真机在场。每步通过后再往下走能极大缩短定位问题的时间。我见过很多朋友跳过前几步直接上完整系统最后遇到问题根本不知道是哪个模块出的错排查时间翻了好几倍。6.3 核心代码框架语音对话主循环与状态机实现下面给出核心主循环的代码框架本质是一个事件驱动状态机。为了简洁我去掉了部分异常处理和日志输出保留完整的逻辑骨架。import asyncio import sounddevice as sd from enum import Enum class RobotState(Enum): STANDBY 0 ATTENTIVE 1 THINKING 2 RESPONDING 3 class VoiceInteraction: def __init__(self): self.state RobotState.STANDBY self.audio_buffer [] self.lock asyncio.Lock() self.asr_client ASRClient() self.llm_client LLMClient() self.tts_client TTSClient() self.vad_model load_silero_vad() async def audio_stream_loop(self): # 用sounddevice开一个流持续读取麦克风数据 with sd.InputStream(samplerate16000, channels1, blocksize1600, callbackself.audio_callback): while True: await asyncio.sleep(0.01) def audio_callback(self, indata, frames, time_info, status): # 回调里只入队不处理复杂逻辑避免阻塞音频流 asyncio.create_task(self.process_audio(indata.copy())) async def process_audio(self, audio_chunk): async with self.lock: if self.state RobotState.STANDBY: # 只有监听唤醒词不缓存音频 if self.detect_wakeword(audio_chunk): self.state RobotState.ATTENTIVE self.audio_buffer.clear() print(唤醒成功进入聆听状态) elif self.state RobotState.ATTENTIVE: # 缓存音频并判断用户是否说完 self.audio_buffer.append(audio_chunk) if self.detect_end_of_speech(): user_text await self.asr_client.recognize(self.audio_buffer) print(f识别结果: {user_text}) self.state RobotState.THINKING asyncio.create_task(self.handle_user_text(user_text)) elif self.state RobotState.RESPONDING: # 只要检测到人声就触发打断 if self.detect_interrupt(audio_chunk): await self.interrupt_current_speech() self.state RobotState.ATTENTIVE self.audio_buffer.clear() self.audio_buffer.append(audio_chunk) print(打断成功重新聆听) async def handle_user_text(self, user_text): # 调用LLM生成回复 reply await self.llm_client.generate(user_text) # 合成语音并播放 audio await self.tts_client.synthesize(reply) self.state RobotState.RESPONDING await self.play_audio(audio) self.state RobotState.ATTENTIVE print(播报完成继续聆听)这里有个关键的细节在调用LLM和TTS期间process_audio里的RESPONDING分支是正常工作的所以才能在播放过程中实时检测插话。THINKING状态通常很快一两秒就切到RESPONDING了。6.4 关键参数调节记录与效果对比参数调节是机器人语音交互里水最深的部分参数好坏天差地别。以下是我实际调试中记录的数据留作参考。唤醒词相似度阈值我初始设为0.6结果环境噪音也经常误触发后来逐步调到0.72之后误触发明显下降。但阈值也不能太高超过0.8后唤醒率会掉得很厉害用户要喊好几遍才有反应。如果你的场景比较嘈杂可以适当提高一点如果环境安静0.68到0.72是最舒服的。VAD打断置信度阈值初始0.5结果机器人自己播报结束后尾音有时候都会触发打断。调到0.6之后正常语气的插话依然能稳定触发但轻声说话可能被漏掉。这里要体感验证建议在实机上多试几种音量。超时参数方面ATTENTIVE超时8秒、THINKING超时15秒是从实际测试中总结的。有个有趣的发现如果ATTENTIVE超时设置得太短比如4秒用户会因为急于说话反而卡顿交互压力很大。8秒刚好是一个自然停顿的尺度。播报结束后的录音余量非常关键。TTS播放停止后音频设备会有一段短暂的回尾如果立即开始录音会把回尾误当成人声。我设置了200毫秒的冷却时间但代价是用户如果在播报结束的瞬间立刻说话前150毫秒会被吞掉。为了缓解这个副作用我把最终方案改成了“软切换”播放停止后的500毫秒内VAD阈值提高到0.8500毫秒后恢复正常值。不同参数组合在实机上的效果对比如下参数配置唤醒误触发率打断响应时间用户体感评分唤醒阈值0.60VAD阈值0.50高约15%90ms差经常莫名打断唤醒阈值0.72VAD阈值0.60低约3%120ms好偶尔漏唤醒唤醒阈值0.80VAD阈值0.70极低180ms差响应迟钝最终选择的是第二组配置在误触发和灵敏度之间最平衡。7. 常见问题排查与避坑纪录7.1 音频相关的高频问题音频链路的问题在语音机器人项目里出现频率最高而且症状隐蔽。我挑几个最典型的。第一个录音设备打开了但一直是静音。最常见的原因是选错了设备编号。USB麦克风阵列有时候会被识别成多个设备比如一个“stereo mix”和一个“mono capture”默认设备可能是错的。排查方法是print出query_devices()结果手动限制device参数。第二个识别结果完全乱码。几乎总是采样率不匹配导致的。Whisper要求16kHz采样率但PyAudio默认打开设备时用的是设备自身的默认采样率很多USB声卡是48kHz。数据进了Whisper就会全乱。我猜你如果在做一个类似的系统八成会踩这个坑。第三个播放时爆音。通常是TTS合成的音频格式和播放器解码格式不一致。edge-tts输出MP3如果不解码直接用某些库播放会出现频率不匹配的爆音。统一转成16kHz、16位、单声道PCM后能解决。第四个G1电机声让识别率下降。这个硬件层面没法完全消除。我的经验是把麦克风尽量远离电机比如用延长线把阵列放在机身前方然后增加VAD门限让轻微的电机噪声不足以触发录音。7.2 SDK通信与系统稳定性问题G1的SDK通信比较稳定但偶尔也会出幺蛾子。最烦的问题是程序跑一段时间后收不到状态数据了。排查下来大多是DDS通信的QoS策略不匹配。宇树的SDK默认用的是best effort模式如果你在中间层自己建了DDS participant要确保QoS也设成best effort否则收发双方无法协商。另外多个程序同时连接G1会抢占通信端口。如果之前跑过某个占用SDK的程序没有正常退出再开新程序时会发现连不上。解决办法是重启中间层主机或者用pkill -f unitree把残留进程清掉。语音服务本身的内存泄漏也要留意。Whisper模型在部分版本下存在长期运行内存缓慢增长的问题。如果计划让机器人长时间运行建议在服务层加定时监控超过阈值就重启asr进程。7.3 交互体验优化经验把功能跑通很简单把体验调好需要大量测试。我在这轮开发里感触最深的三件事一是机器人的语速和回复长度要严格控制。大模型生成的中文回复往往书面感强通过TTS读出来非常像新闻播报完全没有机器人的“灵动感”。我后面在提示词里要求回复带语气词、短句效果好了很多。二是“对不起我没听见”这类兜底话术一定要做。唤醒成功但识别为空或者识别结果置信度太低机器人应该主动说一句没听清而不是傻等或者随便回。这个小细节能挽回很多体验分。三是打断的主动权尽量多交给用户。我加了一个“随时说停”的功能用户在机器人播报时只需要说“停”字系统会检测到短语音并立即静音再等待下一条指令。这个功能在展示场景下特别实用。8. 扩展思考与个人经验总结这次在宇树G1上实现的语音对话、打断与激活系统本质上搭建了一个机器人语音交互的完整参考架构。它的价值不仅在于G1一个平台上能用换成其他提供SDK的机器人平台这套架构一样可以平移过去只是底层通信接口需要适配。不少朋友问我为什么不用那些已经做好的语音机器人方案非要自己从底层拼一遍我的回答是现成方案的定制性太差。机器人场景千变万化有的是工厂巡检有的是展厅接待有的是教育演示每个场景对唤醒词、打断策略、回复风格、动作联动的要求都不同。自己搭一次这套链路后面换场景只需要改配置和提示词不用动底层的音频流管理逻辑这是一劳永逸的事。在实际编码过程中我还积累了两个小技巧这里一并分享出来。第一个是调试利器。语音交互系统开发时把状态机状态、识别文本、LLM回复、VAD置信度、打断事件全部打印到终端用时间戳关联起来。一次完整对话会生成一长串日志可以回溯每一毫秒发生了什么。我第一次调打断问题时就是靠这个日志链条发现“打断事件确实触发了但语音播报还占着音频设备新的录音请求被阻塞了”一分钟定位到问题。第二个是给所有外部服务加超时和降级策略。云端LLM偶尔会超时TTS服务偶尔会抽风返回空数据这些不能等到用户问的时候才发现。我写了一个简单的健康检查循环每隔30秒探测一次各服务是否存活不存活就切到降级模式ASR切到云端、TTS切到本地模拟音、LLM切到预设话术。这个冗余改造在演示场景下救了我好几次。如果你沿着这篇文章的路子做我最后想建议的一点是先把“最小可用闭环”跑通也就是唤醒、听清、回答、停止这四步再做打断和复杂的并发场景。别一上来就追求完美语音交互的坑会让人心态崩掉但逐步摸索过来的成就感也是真的。等你在实机上听到G1第一次准确回应你的问题而且中途插话能立刻停下来那种体验会告诉你这个项目的每一行代码都花得值。 宇树G1机器人语音交互二次开发：对话、打断与激活实战
1. 项目概述一直关注宇树G1这台机器人的朋友应该清楚它在人形机器人里算是把性价比和可玩性拉满的一个存在。相比上一代或者同级别的其他平台G1不仅硬件开放度高而且官方提供的Unitree SDK几乎覆盖了底层关节控制、状态读取、运动控制等所有关键接口。但很多和我一样做过二次开发的人都有个共同的痛点官方SDK给到的是底层运动控制和基础状态接口想让G1真正“听懂人话”“和人对话”甚至做到对话中随时被打断、重新唤醒这些能力官方并没有直接给出一套开箱即用的方案。这就需要一个相对完整的二次开发链路来补齐。本文想聊的就是把“语音对话、打断与激活”这三件事在宇树G1上真正跑通的方法。我的思路很简单不改动G1本身的底层运动控制而是在它的外部计算单元就是G1头部或者背部搭载的工控机也可以是你自己外接的一台Linux主机上搭建一个语音交互中间层。这个中间层向下通过SDK连接机器人实时状态向上对接语音识别ASR、大语言模型LLM和语音合成TTS最终实现你叫它的名字它就醒来你说话它能听懂并回答你中途插嘴它能立刻停止当前播报并重新聆听。这篇文章适合谁已经能跑通G1基础运动SDK、想进一步提升交互体验的开发者或者是做机器人语音交互产品原型验证的工程师。我会尽量把架构选型、代码实现、参数调节这些关键细节都写清楚不绕弯子直接给可以抄作业的方案。先说下我用的整体配置供参考宇树G1系统镜像版本为官方出厂版本SDK使用Unitree Robot SDK支持C和Python这里用Python外部算力G1板载工控机或者通过千兆网口连接的独立Linux主机Ubuntu 20.04/22.04均可语音链路本地麦克风阵列拾音ASR服务用本地Whisper模型LLM用GPT系列APITTS用本地Edge TTS或者线上TTS服务中间层开发框架ROS 2 Humble 自研状态机节点整个项目从零到跑通花了大概两个周末。最花时间的不是代码本身而是音频回环延迟的处理和打断策略的细节调优。这些经验我都会在后面的章节展开能帮你少走很多弯路。2. 项目整体设计与技术架构拆解2.1 为什么选择外部中间层方案而不是魔改G1内部系统在动手之前我和不少做机器人开发的朋友聊过大家的第一个问题几乎都是能不能直接在G1的系统里装语音引擎其实可以但我不推荐。原因有三点。第一G1内部工控机的资源是给实时运动控制预留的。跑语音识别模型尤其是本地方言模型或者大一点的Whisper模型CPU占用会直接飙上去严重的会导致关节控制指令周期不稳定机器人会出现卡顿甚至抖动。万一在调试语音时机器人突然来个不规律动作轻则吓一跳重则设备受损。第二G1的系统环境是宇树定制的稳定性优先换源、装依赖、升级库都得相当谨慎。一旦把系统环境搞坏了恢复出厂镜像重来很麻烦而且可能影响运动控制固件的匹配。第三从架构上看语音交互和运动控制本来就是两个关注点不同的子系统。运动控制要求实时性和确定性语音交互要求模型灵活迭代和网络连通性。把两边在逻辑上分离后续升级ASR模型、换更大的LLM、改唤醒词都不用动运动控制那一层这个解耦带来的收益在做长期迭代时非常明显。所以最终定的架构是G1本体只负责任务执行和运动反馈外部中间层负责所有语音相关的能力。两者之间通过Unitree SDK的Userport用户自定义通信端口通信这个端口本身是官方预留出来做功能扩展的不会被内部运动控制逻辑干扰。2.2 语音交互链路的核心模块拆解一个完整的语音对话链路拆开来看其实是四个串行的环节拾音、识别、语义理解与生成、合成播报。放到机器人场景下还要加两个隐形的环节状态管理和打断仲裁。先看拾音G1本身没有内置麦克风阵列所以需要在外部中间层接USB麦克风阵列或者独立麦克风。我实测下来做机器人语音交互不是随便拿个单麦就能用的。G1工作的时候关节电机、散热风扇都有不小的噪声单麦在1米外基本就废了。我最终用的是带回声消除AEC功能的四麦阵列实测在1.5米内正常音量说话识别率能到90%以上。识别和合成这一块方案上可以走全云端也可以走本地加云端的混合方案。我的选择是本地ASR加云端LLM。ASR选用的是的Whisper large-v3模型在本地用TensorRT加速单句识别延迟控制在800毫秒以内。虽然云端方言识别效果更好但机器人交互场景对延迟很敏感一次完整对话加两秒多的网络往返体感就很差了。LLM部分直接接云端APITTS用Edge TTS单句合成延迟大约500毫秒。打断仲裁这一点是语音交互体验的分水岭。很多初做机器人的朋友把ASR、LLM、TTS串在一起跑通了就以为完事了结果真人和机器人聊起来会发现非常尴尬机器人正在长篇大论你插了一句“停一下”它完全没反应必须等它说完才能再下指令。这个问题我在第四章会详细拆解核心思路是引入独立的语音活动检测VAD组件做低延迟抢断。整个架构图如果用一句话概括G1是身体中间层是耳朵和嘴巴LLM是大脑而打断仲裁是反射弧。身体和反射弧之间通过SDK桥接这层设计让单点替换成为可能。2.3 核心选型对比与理由语音引擎选型可以直接决定项目开发周期和最终体验这部分我把自己对比过的方案和感受列出来方便你做决策。模块方案选项实测感受推荐理由ASR云端方案讯飞/阿里识别准确率高方言好但单次往返延迟1.5-2.5s适合对硬件要求低、网络好的场景ASR本地WhisperTensorRT加速单句800ms内环境噪音适应性中等需要配置较好的CPU/GPU延迟可控不依赖外网适合机器人本地闭环LLM云端GPT/文心等语义理解强但响应有1-3s变量延迟几乎必须用云端本地小模型在复杂对话场景撑不住LLM本地Qwen系列量化版隐私性最好延迟可接受但复杂指令遵循弱一些对数据敏感场景可以选TTSEdge TTS语音自然度高、部署简单、免费有轻微网络依赖最适合作原型和大多数商业场景TTS本地方向合成方案延迟最低但音色质量参差不齐只有在纯离线要求下才用唤醒自研关键词唤醒可控性强可以灵活配置多唤醒词必须自己实现这是机器人交互的入口我最终的选择是本地Whisper 云端LLM Edge TTS。这条组合路线兼顾了延迟、效果和开发效率。补一句如果你做的是纯展示用的原型不走大模型直接接个预设问答脚本也是完全可以的架构不用变只需要把LLM模块换成检索式问答逻辑。3. 环境准备与基础调试3.1 开发环境清单和软件依赖开发之前请先把环境列清楚我这边踩过的坑大多和依赖版本不匹配有关。以下是我调试通过的软件环境建议你尽量在相同大版本下操作操作系统Ubuntu 20.04 LTS或22.04 LTS64位Python版本3.8以上我用的3.10ROS 2版本Humble Hawksbill如果你不打算用ROS也可以但ROS能省掉很多线程通信的事Unitree SDK官方最新版本Python绑定需要编译安装音频框架PortAudio/PyAudiosounddevice用于录音和播放语音识别OpenAI Whisper本地版版本为2023年以后的大模型版本VAD检测silero-vad轻量级识别效果好延迟低LLM调用OpenAI Python SDK或者国内大模型兼容接口的SDK文本转语音edge-tts库或者你自己找到的其他TTS SDK提示先把上述依赖都装好再开始写业务代码。我自己因为中途补依赖遇到过不少很隐蔽的冲突比如PyAudio的底层库和PortAudio版本不匹配导致录音设备打不开查了半天才发现是系统里有两套libportaudio。安装步骤这里只做简要展开。ROS 2 Humble按官方文档安装即可Ubuntu 22.04直接apt源里装最省事。Whisper的安装我建议用pip装openai-whisper然后额外装tensorrt和onnxruntime做推理加速。silero-vad直接用pip安装torch版本它会自动下载模型权重。# 安装系统基础依赖 sudo apt update sudo apt install portaudio19-dev python3-pyaudio python3-dev python3-pip # Python依赖 pip install sounddevice numpy scipy websockets pip install openai-whisper edge-tts pip install silero-vad torch pip install openai # 或者你用的国内大模型SDK pip install unitree-sdk2-python # 宇树官方Python SDK3.2 麦克风阵列连接与音频参数调优G1本体没有麦克风所以拾音设备需要独立接入。这一步看着简单实际上音频参数的调试是个耐心活。先把USB麦克风阵列插到中间层主机上然后我用sounddevice库列出所有音频设备确认录音和播放的默认设备编号。import sounddevice as sd print(sd.query_devices())输出结果里重点看每个设备的默认采样率。常用的USB麦克风阵列一般支持16000Hz和48000Hz。这里就有一个大坑Whisper模型在16000Hz采样率下识别效果最好而很多USB声卡默认输出是48000Hz。如果你直接拿48000Hz的音频往Whisper里送识别结果会惨不忍睹甚至完全乱码。解决方式是做一次重采样。我习惯使用scipy的resample_poly函数把48000Hz降采样到16000Hz再送入Whisper。必须要说重采样的质量也会影响识别率建议用抗混叠滤波选项。from scipy import signal import numpy as np def resample_audio(audio: np.ndarray, orig_rate: int, target_rate: int) - np.ndarray: # 使用scipy的多相重采样抗混叠效果好比线性插值稳很多 number_of_samples round(len(audio) * float(target_rate) / orig_rate) resampled_audio signal.resample_poly(audio, target_rate, orig_rate, axis0) return resampled_audio.astype(np.float32)除了采样率还有两个参数非常关键一是块大小chunk size这决定录音的实时性。我设置的是1600个采样点在16000Hz下刚好是100毫秒的音频块。这个粒度足够细既能保证VAD及时响应又不会因为块太小导致CPU频繁切换线程。二是回声消除。如果G1在播报语音时麦克风把播报声音也录进去就会造成“机器人自己说话自己听”的严重干扰。好的麦克风阵列硬件会内置AEC但实测下来单纯依赖硬件还不够我在播报和录音之间做了软件互斥播报期间不录音播报结束后留200毫秒的余量再恢复录音。这会导致一个问题就是播报完成后立即说话的内容可能被截掉但比较下来这个代价是可以接受的总比回声把识别器搞疯强。3.3 宇树G1 SDK连接与运动状态监听G1的Unitree SDK走的是网络通信中间层主机和G1需要在同一局域网下或者直连千兆网口。官方Python SDK封装好了运动控制和状态上报的接口我这里只讲语音交互用到的部分。先做最低限度的连接验证确保SDK能正常读取G1状态。from unitree_sdk2py.core.channel import ChannelFactoryInitialize from unitree_sdk2py.idl.unitree_hg.msg.dds_ import LowState_ from unitree_sdk2py.g1.g1_client import G1Client # 初始化通信信道注意这里的网络配置要和G1实际IP对应 ChannelFactoryInitialize(0, eth0) client G1Client() state LowState_() client.GetLowState(state) # 打印一下当前关节状态确认连接正常 print(电机数量, len(state.motor_state)) print(第一个关节角度(rad), state.motor_state[0].q)跑通这个就说明SDK链路是通的。语音交互层里需要实时知道的状态主要是两个G1当前是否处于运动状态比如是否正在走路、转头以及是否正在执行某个动作的播报。前者可以从关节角速度判断后者则需要在动作执行代码里自己维护一个标志位。为了不干扰SDK原本的运动控制逻辑我单独起了一个线程以50Hz的频率读取LowState把关节运动状态缓存在全局变量里。语音对话链路只有在机器人处于空闲状态时才允许播放语音回复。注意语音对话期间不建议同时跑比较剧烈的运动控制。因为G1在运动过程中电机的噪声传播到麦克风识别率会急剧下降。我的经验是对话时让G1保持站立稳定等指令明确后再执行动作执行动作时不要播报长语音真要播报也等电机停下来再说。4. 语音对话链路实现4.1 唤醒词检测与激活机制设计“激活”这个词在机器人语音交互里有特殊含义它指的是让机器人从待机状态转为聆听状态。不是7x24小时都在听那样功耗和误唤醒都受不了而是有策略地唤醒。我实现了三层激活机制从轻到重第一层是物理按键激活优先级最高但使用频率最低。G1的外接按钮直接连到中间层GPIO上按下后立即打断当前一切语音播报并开始录音这相当于一个“强制抢麦”按钮。第二层是关键词唤醒是用户日常使用最频繁的方式。在这里我用了自研唤醒词检测没有用通用的“小X小X”那套。为什么不用现成的唤醒引擎因为那些引擎通常要求重训或者配置大模型反而不好适配G1这种需要低延迟和自定义词表的场景。我的唤醒词检测方案是先跑一个轻量的VAD检测到人声片段后把片段前0.8秒的音频用一个小型语音嵌入模型提取特征和预设的唤醒词特征做余弦相似度。相似度超过阈值就触发唤醒。这个方案的好处是延迟极低大约300毫秒就能判定而且可以在本地换不同的唤醒词。from silero_vad import load_silero_vad import torch model_vad load_silero_vad() def detect_wakeword(audio_chunk, threshold0.72): # 先用VAD检测是否有人声活动 confidence model_vad(torch.from_numpy(audio_chunk), 16000).item() if confidence 0.5: return False # 再和人声嵌入特征做相似度判断 embedding extract_audio_embedding(audio_chunk) similarity cosine_similarity(embedding, WAKE_WORD_EMBEDDING) print(f唤醒词相似度: {similarity:.3f}) return similarity threshold第三层是说话即唤醒。当机器人处于“待命”状态但VAD检测到环境中有明确的语句式人声非唤醒词时也会自动进入聆听状态。这一层体验很微妙需要在灵敏度和误唤醒之间找到平衡。我设置的策略是VAD人声持续超过1.2秒且环境噪声低于阈值才判定为主动对话否则忽略。4.2 语音识别ASR模块的本地化部署与接口封装ASR是整个链路里技术含量最高也最容易出问题的一块。我用的本地Whisper large-v3模型在本方案里是按服务模式跑起来的通过HTTP接口和语音交互主程序通信这样模型只需要加载一次所有请求复用同一个推理会话避免每次都重新加载模型的巨大开销。模型推理服务的核心代码框架如下from fastapi import FastAPI, UploadFile import whisper import numpy as np app FastAPI() model whisper.load_model(large-v3) # 可以换成medium或small识别速度和精度权衡 app.post(/asr) async def asr_endpoint(file: UploadFile): audio_bytes await file.read() audio_np np.frombuffer(audio_bytes, dtypenp.int16).astype(np.float32) / 32768.0 result model.transcribe(audio_np, languagezh, fp16False) return {text: result[text]}注意上面代码里的fp16False这个在CPU推理时必须关掉否则会报错。如果是NVIDIA GPU推理可以把fp16打开速度能提升不少。Whisper模型体积大large-v3光权重就快3GB所以推理服务建议至少留4GB内存/显存。模型大小和识别速度的关系是这样的模型参数量显存占用单句延迟(CPU)单句延迟(GPU)tiny39M约1GB约0.3s约0.15ssmall244M约2GB约0.8s约0.3smedium769M约5GB约2s约0.8slarge-v31550M约10GB约5s约1.5s实际项目里如果你没有很强的GPU建议在“准确的medium”和“快速的small”之间选。G1机器人场景下交互体验优先我是用large-v3加GPU如果条件有限medium也够用。除了离线模型我也封装了云ASR接口作为备用通道。万一本地服务挂了或者遇到极其嘈杂的环境本地识别率明显下降可以自动切换云端。4.3 LLM对话与大模型接口对接设计可控的机器人“人设”LLM对接在这几个模块里反而是最简单的主要工作是设计提示词系统、处理流式输出和控制回复长度。我给G1设计的人设是一个简洁、专业、少说废话的机器人助手。对应地提示词里会明确要求模型用“我”自称回复控制在100字以内不要探讨抽象哲学问题遇到不确定的事直接说不知道。这些约束不是装饰是实际交互体验的需要。机器人回复拖沓用户根本等不住。流式输出这块我要多说一句。很多初学者直接等LLM把完整回复生成完再一次性播放这在对话场景下会造成很大的等待感。我改成了流式接收LLM每生成一小段文字就立即送到TTS模块合成语音播放。这样用户听到第一个音节的时间能提前至少40%体验完全不同。from openai import OpenAI client OpenAI( api_key你的key, base_url你的API地址 ) SYSTEM_PROMPT 你是G1机器人助手名字叫小宇。你正在通过语音与人交流。 回答要求 1. 第一人称用“我”称呼用户用“你” 2. 回答控制在100字以内口语化 3. 不知道的就说不知道不要编造 4. 不要输出任何代码或命令行内容 5. 如果用户让你做机器人动作输出[ACTION]标签加上动作名称 def generate_reply(user_text: str): stream client.chat.completions.create( modelgpt-4o-mini, # 或你实际使用的模型 messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_text} ], streamTrue, max_tokens250 ) for chunk in stream: delta chunk.choices[0].delta.content if delta: yield delta有一点务必留心就是你接的外部大模型API如果有内容安全过滤在机器人语音交互场景下可能会输出“抱歉我不能...”之类的拒答话术。这种话术通过机器人的嘴巴说出来体验很差。我在中间加了一层回复过滤检测到拒答话术时统一替换成一句“这个问题我还不太会你换个说法问我吧”。整个过程对用户是无感的。4.4 TTS语音合成与播放策略TTS模块我选择edge-tts因为它在中文语音的自然度上非常出色而且免费、部署简单。它其实是调用了微软Edge浏览器的在线语音合成接口对网络有依赖但稳定性在大多数情况下都够用。TTS服务同样走HTTP接口语音合成结果直接返回音频流。主程序拿到音频数据和文本一起播放。import edge_tts TEXT 你好我是小宇有什么可以帮你的 VOICE zh-CN-XiaoxiaoNeural communicate edge_tts.Communicate(TEXT, VOICE) await communicate.save(output.mp3)播放的时候有几个细节要注意。第一播放前要把音频数据解码为PCM格式否则播放库之间不兼容。edge-tts默认输出MP3格式用pydub或者ffmpeg转成wav再播放。第二播放音量要设定成合适值我实测G1的扬声器天生偏小需要软件放大到120%左右才听得清楚。第三播放过程和录音过程的互斥必须做好具体怎么做我放在打断章节一起讲。播放策略上我放弃了传统的“完整合成再播放”模式改成流式播放。每次从LLM拿到一小段增量文本立即合成对应的音频片段并排队播放。这样虽然有几百毫秒的片段间隙但用户的等待时间明显缩短。5. 打断与激活机制深度实现5.1 为什么打断是机器人交互体验的灵魂先说一个现象。很多刚接触语音机器人的朋友想当然地认为把“听懂并回答”这个链路做好就行打断是第一版不用管的。但真实场景里打断几乎决定了用户愿不愿意继续用这个东西对话。想象一下你问G1一个开放性问题它的LLM启动了开始滔滔不绝讲起几十秒的长篇回答。在这期间你意识到它理解偏了想纠正但是不管你怎么插话它都当没听见必须等它全部说完才能重新下指令。这种体验在真人对话里是荒唐的在机器人语音交互里却是默认状态。坏消息是实现打断功能比听起来复杂得多。因为整个链路里有多个环节TTS正在合成、音频正在播放、LLM可能还在继续生成内容、ASR处于待命状态。要在一个合适的时机暂停这些环节而且不能产生奇怪的音频残留就需要设计一套完整的状态切换机制。好消息是这套机制一旦建好它会成为整个交互架构的基础设施。后续想加音乐播放、动作指令并发、多轮对话管理都能直接复用这套打断仲裁逻辑。5.2 基于VAD的语音活动检测与打断触发打断的第一步是听到用户说话了。这里的“听到”不能靠ASR因为ASR要等人说完一整句才给结果那样打断的响应时间会超过两秒根本谈不上“即时”。必须用一个轻量级的VAD来实时检测人声活动。silero-vad是我测试过最适合做这件事的模型。它是一个小型神经网络输入10到30秒的音频片段输出一个0到1的人声置信度。单次推理在CPU上只要几毫秒完全可以做到实时。打断的判定逻辑是这样的TTS播放过程中持续采集麦克风音频流每一帧都跑vad。如果发现连续两帧约200毫秒的vad置信度超过0.6就认为用户说话意图强烈立刻触发打断。置信度阈值不能设太低否则机器人播报时周围环境稍微有点声音就会把它打断。VAD_THRESHOLD 0.6 VAD_FRAME_RATE 16000 FRAME_DURATION_MS 40 # 每帧40ms保证低延迟 FRAME_SIZE int(VAD_FRAME_RATE * FRAME_DURATION_MS / 1000) def process_interrupt_detection(audio_stream): trigger_count 0 for frame in audio_stream: confidence vad_model(torch.from_numpy(frame), VAD_FRAME_RATE).item() if confidence VAD_THRESHOLD: trigger_count 1 if trigger_count 2: print(检测到用户插话触发打断) emit_interrupt_event() return else: trigger_count 0打断动作本身需要协调多个模块。触发后要按顺序做这几件事停止当前TTS音频的播放立即不是等播放完取消LLM尚未完成的生成如果还在流式输出断开流连接清空ASR内部的待处理音频缓存切换到“聆听”状态开始录音缓存用户接下来的指令整个过程我要求在150毫秒内完成。实测代码跑下来从触发事件到所有模块停止大概在100到120毫秒用户感知就是“我一开口它马上闭嘴了”。5.3 播放录音互斥与多线程状态协同打断能跑通的前提是录音和播放不能同时进行。但在Linux下实现真正的互斥比想象的复杂。如果只依赖线程锁你会在实际运行中遇到各种音频设备抢占问题。我的做法是引入一个音频路由管理器把它作为所有音频流的唯一入口。管理器内部维护一个状态机IDLE空闲、LISTENING聆听中、SPEAKING播报中、INTERRUPTING打断中。其他模块不能直接操作音频设备只能向管理器发请求由管理器统一调度。这个设计有几个好处。一是打断逻辑可以集中在一个地方实现而不是散落在各个模块里。二是音频设备只有一个打开者不会出现“播放占用设备导致录音失败”这种问题。三是在调试时可以通过打印状态机来观察整个系统在做什么。状态切换的时机从IDLE到LISTENING唤醒词触发或用户主动按键。从LISTENING到SPEAKINGASR返回结果LLM生成了回复准备工作播放。从SPEAKING到INTERRUPTINGVAD检测到用户插话。从INTERRUPTING到LISTENING播放停止重新开始收音。用Python的asyncio来管理这个状态机既能保证并发安全又比纯线程好调试得多。我在实际项目中用asyncio.Lock和asyncio.Condition实现了状态同步代码里没有出现过一个暴露的死锁问题。5.4 激活状态机与超时管理和“打断”配套的是“激活”这里的激活不是指系统授权而是机器人从待命状态切换到可交互状态的整个机制。机器人不能24小时都在听人说话那样既浪费算力也会因为环境杂音频繁误触发。所以需要一个激活状态机管理什么时候听、什么时候不理人。我定义了四个状态STANDBY省电待命只运行唤醒词检测不录音、不识别。ATTENTIVE已唤醒开始录音并准备识别用户指令。THINKING正在调用LLM不需要麦克风录音但依然监控用户插话。RESPONDING正在播放TTS同时监控打断信号。从STANDBY到ATTENTIVE的触发条件是唤醒词得分超过阈值。从ATTENTIVE到THINKING是检测到用户说完了一句话。从THINKING到RESPONDING是LLM返回结果。从RESPONDING到ATTENTIVE是播报完毕或被用户打断。超时管理是这个状态机的核心逻辑。用户唤醒后长时间不说话不能一直等下去否则会听到环境噪音被当指令。我设置的规则是ATTENTIVE状态最长持续8秒超时自动返回STANDBYTHINKING状态最长15秒作为LLM调用的保护性超时RESPONDING状态没有硬超时但播报完会自动退出。这套超时参数是多次实测调出来的。8秒的聆听窗口比较合适太长会失去交互紧迫感太短用户组织语言的时间不够。6. 完整实操流程与代码实现6.1 中间层系统搭建与网络配置硬件层面我的推荐是给G1配一个Intel NUC或者类似的紧凑型工控机作为中间层。它通过千兆网线直接连G1的网口组成一个独立的局域网。麦克风阵列和扬声器都接在中间层上。网络配置上G1出厂默认IP一般为192.168.123.18或类似地址。中间层的网口IP要手动设为同一网段比如192.168.123.20网关设成空不要接外网避免路由冲突。语音对话所需的外网连接通过中间层的另一个无线网卡Wi-Fi走这样G1的运动控制网和外部语音网完全隔离互不干扰。# 中间层网口配置 sudo ip addr add 192.168.123.20/24 dev eth0 # 临时配置测试用 sudo ip link set eth0 up验证和G1的连通性ping 192.168.123.18通了之后再验证Unitree SDK的DDS通信。宇树G1的运动控制和状态通信基于DDS协议SDK内部会自动处理。你只需要确保通信端口不被本机防火墙拦截。Ubuntu上如果开了ufw需要开放对应端口否则你会发现SDK能初始化但始终收不到数据。6.2 语音服务部署与联调记录部署完成后的第一个联调我强烈建议不要直接上完整链路而是分模块测试。我当时的测试顺序是第一步单独测ASR。命令行录一段音频调asr接口看返回文本是否正确。这一步排除了音频采集和模型推理解码的问题。第二步单独测LLM。用curl直接调大模型接口确认网络和提示词没有问题。第三步单独测TTS。调用edge-tts合成一段文本播放确认音质和延迟都达标。第四步把ASR和LLM串起来做一个“我说一句它回一句”的纯文本对话测试。这个阶段不接机器人和TTS先验证中间环节的稳定性。第五步接上TTS做完整的语音对话闭环先用PC的麦克风和扬声器测本地延迟基本在1.2秒左右。最后一步再接上G1的SDK状态监听做机器人场景下的联调。这时候才需要真机在场。每步通过后再往下走能极大缩短定位问题的时间。我见过很多朋友跳过前几步直接上完整系统最后遇到问题根本不知道是哪个模块出的错排查时间翻了好几倍。6.3 核心代码框架语音对话主循环与状态机实现下面给出核心主循环的代码框架本质是一个事件驱动状态机。为了简洁我去掉了部分异常处理和日志输出保留完整的逻辑骨架。import asyncio import sounddevice as sd from enum import Enum class RobotState(Enum): STANDBY 0 ATTENTIVE 1 THINKING 2 RESPONDING 3 class VoiceInteraction: def __init__(self): self.state RobotState.STANDBY self.audio_buffer [] self.lock asyncio.Lock() self.asr_client ASRClient() self.llm_client LLMClient() self.tts_client TTSClient() self.vad_model load_silero_vad() async def audio_stream_loop(self): # 用sounddevice开一个流持续读取麦克风数据 with sd.InputStream(samplerate16000, channels1, blocksize1600, callbackself.audio_callback): while True: await asyncio.sleep(0.01) def audio_callback(self, indata, frames, time_info, status): # 回调里只入队不处理复杂逻辑避免阻塞音频流 asyncio.create_task(self.process_audio(indata.copy())) async def process_audio(self, audio_chunk): async with self.lock: if self.state RobotState.STANDBY: # 只有监听唤醒词不缓存音频 if self.detect_wakeword(audio_chunk): self.state RobotState.ATTENTIVE self.audio_buffer.clear() print(唤醒成功进入聆听状态) elif self.state RobotState.ATTENTIVE: # 缓存音频并判断用户是否说完 self.audio_buffer.append(audio_chunk) if self.detect_end_of_speech(): user_text await self.asr_client.recognize(self.audio_buffer) print(f识别结果: {user_text}) self.state RobotState.THINKING asyncio.create_task(self.handle_user_text(user_text)) elif self.state RobotState.RESPONDING: # 只要检测到人声就触发打断 if self.detect_interrupt(audio_chunk): await self.interrupt_current_speech() self.state RobotState.ATTENTIVE self.audio_buffer.clear() self.audio_buffer.append(audio_chunk) print(打断成功重新聆听) async def handle_user_text(self, user_text): # 调用LLM生成回复 reply await self.llm_client.generate(user_text) # 合成语音并播放 audio await self.tts_client.synthesize(reply) self.state RobotState.RESPONDING await self.play_audio(audio) self.state RobotState.ATTENTIVE print(播报完成继续聆听)这里有个关键的细节在调用LLM和TTS期间process_audio里的RESPONDING分支是正常工作的所以才能在播放过程中实时检测插话。THINKING状态通常很快一两秒就切到RESPONDING了。6.4 关键参数调节记录与效果对比参数调节是机器人语音交互里水最深的部分参数好坏天差地别。以下是我实际调试中记录的数据留作参考。唤醒词相似度阈值我初始设为0.6结果环境噪音也经常误触发后来逐步调到0.72之后误触发明显下降。但阈值也不能太高超过0.8后唤醒率会掉得很厉害用户要喊好几遍才有反应。如果你的场景比较嘈杂可以适当提高一点如果环境安静0.68到0.72是最舒服的。VAD打断置信度阈值初始0.5结果机器人自己播报结束后尾音有时候都会触发打断。调到0.6之后正常语气的插话依然能稳定触发但轻声说话可能被漏掉。这里要体感验证建议在实机上多试几种音量。超时参数方面ATTENTIVE超时8秒、THINKING超时15秒是从实际测试中总结的。有个有趣的发现如果ATTENTIVE超时设置得太短比如4秒用户会因为急于说话反而卡顿交互压力很大。8秒刚好是一个自然停顿的尺度。播报结束后的录音余量非常关键。TTS播放停止后音频设备会有一段短暂的回尾如果立即开始录音会把回尾误当成人声。我设置了200毫秒的冷却时间但代价是用户如果在播报结束的瞬间立刻说话前150毫秒会被吞掉。为了缓解这个副作用我把最终方案改成了“软切换”播放停止后的500毫秒内VAD阈值提高到0.8500毫秒后恢复正常值。不同参数组合在实机上的效果对比如下参数配置唤醒误触发率打断响应时间用户体感评分唤醒阈值0.60VAD阈值0.50高约15%90ms差经常莫名打断唤醒阈值0.72VAD阈值0.60低约3%120ms好偶尔漏唤醒唤醒阈值0.80VAD阈值0.70极低180ms差响应迟钝最终选择的是第二组配置在误触发和灵敏度之间最平衡。7. 常见问题排查与避坑纪录7.1 音频相关的高频问题音频链路的问题在语音机器人项目里出现频率最高而且症状隐蔽。我挑几个最典型的。第一个录音设备打开了但一直是静音。最常见的原因是选错了设备编号。USB麦克风阵列有时候会被识别成多个设备比如一个“stereo mix”和一个“mono capture”默认设备可能是错的。排查方法是print出query_devices()结果手动限制device参数。第二个识别结果完全乱码。几乎总是采样率不匹配导致的。Whisper要求16kHz采样率但PyAudio默认打开设备时用的是设备自身的默认采样率很多USB声卡是48kHz。数据进了Whisper就会全乱。我猜你如果在做一个类似的系统八成会踩这个坑。第三个播放时爆音。通常是TTS合成的音频格式和播放器解码格式不一致。edge-tts输出MP3如果不解码直接用某些库播放会出现频率不匹配的爆音。统一转成16kHz、16位、单声道PCM后能解决。第四个G1电机声让识别率下降。这个硬件层面没法完全消除。我的经验是把麦克风尽量远离电机比如用延长线把阵列放在机身前方然后增加VAD门限让轻微的电机噪声不足以触发录音。7.2 SDK通信与系统稳定性问题G1的SDK通信比较稳定但偶尔也会出幺蛾子。最烦的问题是程序跑一段时间后收不到状态数据了。排查下来大多是DDS通信的QoS策略不匹配。宇树的SDK默认用的是best effort模式如果你在中间层自己建了DDS participant要确保QoS也设成best effort否则收发双方无法协商。另外多个程序同时连接G1会抢占通信端口。如果之前跑过某个占用SDK的程序没有正常退出再开新程序时会发现连不上。解决办法是重启中间层主机或者用pkill -f unitree把残留进程清掉。语音服务本身的内存泄漏也要留意。Whisper模型在部分版本下存在长期运行内存缓慢增长的问题。如果计划让机器人长时间运行建议在服务层加定时监控超过阈值就重启asr进程。7.3 交互体验优化经验把功能跑通很简单把体验调好需要大量测试。我在这轮开发里感触最深的三件事一是机器人的语速和回复长度要严格控制。大模型生成的中文回复往往书面感强通过TTS读出来非常像新闻播报完全没有机器人的“灵动感”。我后面在提示词里要求回复带语气词、短句效果好了很多。二是“对不起我没听见”这类兜底话术一定要做。唤醒成功但识别为空或者识别结果置信度太低机器人应该主动说一句没听清而不是傻等或者随便回。这个小细节能挽回很多体验分。三是打断的主动权尽量多交给用户。我加了一个“随时说停”的功能用户在机器人播报时只需要说“停”字系统会检测到短语音并立即静音再等待下一条指令。这个功能在展示场景下特别实用。8. 扩展思考与个人经验总结这次在宇树G1上实现的语音对话、打断与激活系统本质上搭建了一个机器人语音交互的完整参考架构。它的价值不仅在于G1一个平台上能用换成其他提供SDK的机器人平台这套架构一样可以平移过去只是底层通信接口需要适配。不少朋友问我为什么不用那些已经做好的语音机器人方案非要自己从底层拼一遍我的回答是现成方案的定制性太差。机器人场景千变万化有的是工厂巡检有的是展厅接待有的是教育演示每个场景对唤醒词、打断策略、回复风格、动作联动的要求都不同。自己搭一次这套链路后面换场景只需要改配置和提示词不用动底层的音频流管理逻辑这是一劳永逸的事。在实际编码过程中我还积累了两个小技巧这里一并分享出来。第一个是调试利器。语音交互系统开发时把状态机状态、识别文本、LLM回复、VAD置信度、打断事件全部打印到终端用时间戳关联起来。一次完整对话会生成一长串日志可以回溯每一毫秒发生了什么。我第一次调打断问题时就是靠这个日志链条发现“打断事件确实触发了但语音播报还占着音频设备新的录音请求被阻塞了”一分钟定位到问题。第二个是给所有外部服务加超时和降级策略。云端LLM偶尔会超时TTS服务偶尔会抽风返回空数据这些不能等到用户问的时候才发现。我写了一个简单的健康检查循环每隔30秒探测一次各服务是否存活不存活就切到降级模式ASR切到云端、TTS切到本地模拟音、LLM切到预设话术。这个冗余改造在演示场景下救了我好几次。如果你沿着这篇文章的路子做我最后想建议的一点是先把“最小可用闭环”跑通也就是唤醒、听清、回答、停止这四步再做打断和复杂的并发场景。别一上来就追求完美语音交互的坑会让人心态崩掉但逐步摸索过来的成就感也是真的。等你在实机上听到G1第一次准确回应你的问题而且中途插话能立刻停下来那种体验会告诉你这个项目的每一行代码都花得值。