陪伴老人智能机器人设计：硬件选型、交互链路与具身决策实践

简介面向人口老龄化背景下养老服务的迫切需求陪伴老年人智能机器人设计研究文档提供了从需求分析、技术架构到功能实现的系统参考。内容聚焦老年人生理与心理特征重点讲解PAD情感空间中的创新人机交互、语音交互与面部表情识别技术并详述机械结构系统的传动、执行、驱动三大子系统以及包括传感器系统、语音识别系统、图像处理系统、神经网络和安全加密在内的机器人控制系统。文档还展示了提醒服药、天气播报、寻医问诊等实际应用场景同时强调一对一认证交流与个性化交互设计对缓解孤独感、提升晚年生活质量的价值。压缩包内含1个docx文档大小152KB已有62人学习下载。适合互联网产品设计、养老科技研发及人机交互方向的人员阅读能够快速建立智能陪伴机器人的整体知识框架。1. 陪伴老人的智能机器人难点不在“智能”在“不被关掉”给独居老人装智能音箱三天后音箱被塞进抽屉装监控摄像头老人拿毛巾盖住镜头。这两件事在养老产品圈反复发生原因是一致的传统方案默认老人是“被监护对象”而不是“使用对象”。陪伴老年人的智能机器人要解决的核心问题不是人脸识别准不准、语音问答聪不聪明而是让老人愿意把它留在客厅、放在床头持续用上半年。这背后牵扯到一套完整的系统设计从硬件功耗、传感器布局、交互链路到近年讨论度很高的具身智能机器人行为决策框架缺一环都会导致设备吃灰。这篇内容就按“需求拆解 → 硬件架构 → 交互软件 → 具身智能决策 → 真实环境调优”的顺序把整套设计方案讲透适合正在做养老机器人原型、智能家居终端或适老化硬件产品的工程师参考。2. 陪伴场景的硬件选型从传感器到底盘先满足“安静”和“续航”2.1 陪伴场景对硬件的三个硬约束工业服务机器人可以不在乎噪音和功耗因为车间本身噪音就大机器人永远在充电桩附近。家庭陪伴场景完全不同老人对噪音敏感睡眠浅机器人半夜风扇声稍微大一点就会被关掉。所以硬件设计第一约束是噪声第二是续航第三才是算力。先说噪音。被动散热优先于主动散热选型时尽量选能无风扇运行的算力平台。NVIDIA Jetson Orin Nano在10W~15W模式下可以被动散热这个功耗区间内推理性能足够跑量化后的视觉语言模型是常见选择。树莓派5也能无风扇跑但推理7B参数模型会很吃力适合只做语音交互的原型机。再说续航。底盘方案直接影响功耗。四轮全向底盘操控性好但四个电机待机损耗高两驱差速底盘加万向轮更省电家庭场景地面平整完全够用。电池容量按6小时连续运行设计取峰值功耗和待机功耗的加权值计算后面第5章会给出具体公式。第三是安全。家庭环境有老人、有宠物机器人移动速度必须限制在0.5m/s以内电机扭矩要有限流碰撞传感器和急停按钮不能省。这些不是锦上添花是进入家庭的基本门槛。2.2 分层硬件架构传感层、决策层、执行层怎么配合硬件架构建议分三层避免“一个主控干所有事”导致的实时性灾难。层级模块选型建议职责传感层麦克风阵列4麦线性阵列声源定位、语音增强、唤醒词识别传感层视觉模组Intel RealSense D435 或同等RGB-D人体姿态估计、避障、距离感知传感层活动监测24GHz毫米波雷达夜间无光场景活动检测不产生图像决策层主控Jetson Orin Nano 8GB运行ASR、LLM、视觉模型决策层底层控制STM32F4系列MCU电机控制、舵机控制、传感器读取执行层底盘两驱差速 万向轮移动、避障执行层头部云台2自由度舵机云台头部转向、表情表达执行层显示/音频7寸触摸屏 全频喇叭交互反馈、信息展示主控和MCU之间走UART或USB通信主控负责“思考”MCU负责“动作”。这个分离很重要视觉模型推理偶尔卡顿没问题但电机控制如果卡顿机器人可能撞到老人。底层运动控制必须实时。2.3 最小可复现的硬件清单如果你准备两周内搭一台原型机我建议这样采购主控板Jetson Orin Nano 8GB 开发者套件约2000元左右底层控制板STM32F407 核心板约100元语音模组任意4麦USB麦克风阵列约300元视觉模组RealSense D435二手约800元雷达模组24GHz毫米波雷达模块约150元电机驱动TB6612 两个带编码器的N20电机约200元底盘结构3D打印一个类似“圆盘 两个驱动轮 万向轮”的结构电源3节18650锂电池串联加降压模块总容量约10Ah注意不要一开始就上机械臂。陪伴场景里移动底盘 头部云台已经能完成70%的交互动作机械臂带来的安全风险和成本都高后续迭代再加不迟。3. 交互软件链路让智能机器人听得懂、看得见还能接上大模型3.1 语音链路怎么搭唤醒、识别、生成、播报四步陪伴机器人的语音交互关键技术指标是“端到端延迟”和“误唤醒率”。老人讲话慢但机器回答如果超过2秒老人就会觉得“坏了”然后不再使用。所以语音链路要做流式处理。完整链路是麦克风阵列 → 唤醒词检测 → 语音活动检测VAD→ 流式ASR → LLM大语言模型→ TTS → 喇叭播放。每一环节的延迟都要单独压测。常见做法是唤醒词用 openWakeWord 这类本地模型跑在Jetson上ASR用 FunASR 的流式中文模型LLM用量化后的 Qwen2.5-7B-InstructTTS用 Edge-TTS 或本地 CosyVoice。下面是一个典型的调用顺序示意如何在主控上把环节串起来import asyncio from funasr import AutoModel from openwakeword import Model as WakeModel # 1. 唤醒词模型常驻内存阈值调高避免误唤醒 wake_model WakeModel(wakeword_models[alexa]) WAKE_THRESHOLD 0.8 # 0.8以上才判定为唤醒0.5容易误报 # 2. ASR模型加载启用流式模式 asr_model AutoModel(modelparaformer-zh-streaming) async def voice_loop(): while True: # 持续从麦克风读取16kHz音频块 audio_chunk mic.read_frames() wake_score wake_model.predict(audio_chunk) if wake_score[alexa] WAKE_THRESHOLD: # 唤醒后录制10秒语音交给ASR user_audio mic.record_until_silence(timeout10) text asr_model.generate(inputuser_audio, is_finalTrue) print(fASR结果: {text}) # 调用LLM并播报 response await llm.chat(text) await tts.say(response)逻辑说明唤醒模型和ASR模型常驻内存避免每次唤醒都重新加载导致响应延迟。唤醒阈值0.8意味着只有明确喊出唤醒词才触发误唤醒率可以控制在每天0.5次以下。record_until_silence用静音检测自动停止录音比固定时长录音体验好老人在10秒内没说完话会被截断。参数建议ASR解码用贪心搜索不要用beam search延迟从1.8秒降到0.9秒牺牲少量准确率在陪伴场景完全可接受。LLM的温度参数设到0.7较好太随机会让老人觉得“乱说话”太低又显得机械。3.2 视觉感知链路跌倒检测和姿态估计不能全指望大模型老人陪伴场景里最刚需的视觉能力是跌倒检测。这里有个常见坑直接把视频帧丢给视觉语言模型VLM问“这个人是不是跌倒了”推理一次要2到3秒延迟不可接受。工程上建议分层判断先用轻量级姿态估计算法如MediaPipe Pose提取关键点再用规则判断是否跌倒只有规则判断模棱两可时才把图像升级给VLM复核。import mediapipe as mp import numpy as np mp_pose mp.solutions.pose pose mp_pose.Pose( min_detection_confidence0.6, min_tracking_confidence0.5 ) FALL_FRAMES 5 # 连续5帧满足跌倒条件才触发告警 fall_count 0 def check_fall(landmarks) - bool: 根据人体关键点判断跌倒状态 if not landmarks: return False # 取关键点0鼻尖11左肩12右肩23左髋24右髋 nose_y landmarks[0].y hip_y (landmarks[23].y landmarks[24].y) / 2 shoulder_y (landmarks[11].y landmarks[12].y) / 2 # 如果鼻尖高度低于髋部高度说明躯干已经放平疑似跌倒 if nose_y hip_y: return True # 如果肩膀和髋部的高度差小于身高的15%躯干接近水平也可能是跌倒 if abs(shoulder_y - hip_y) 0.15 * (hip_y - landmarks[23].y 1e-6): return True return False # 在主循环中调用 for frame in frames: results pose.process(frame) if check_fall(results.pose_landmarks): fall_count 1 else: fall_count 0 if fall_count FALL_FRAMES: print(触发跌倒告警) fall_count 0 # 重置等待下次逻辑说明MediaPipe姿态估计单帧推理大约10~20ms可以实时跑。跌倒判断用两个几何条件第一是鼻尖头部低于髋部说明人已经躺平第二是肩部与髋部几乎水平说明躯干接近地面角度。连续5帧都满足才触发避免老人弯腰捡东西被误判。min_detection_confidence0.6时检测概率越高但遮挡环境下会漏检调到0.4会增加召回率伴随更多的抖动误报需要按现场环境权衡。3.3 隐私模式设计夜间自动降级为雷达感知这里有个容易被忽略的设计点。摄像头在夜间卧室不关机老人心理压力很大觉得“被看着睡觉”这是导致设备被拔电源的主要原因之一。所以软件上要设计隐私模式晚上10点到早上7点之间自动关闭RGB摄像头只保留毫米波雷达检测活动状态。雷达输出的是点云数据不是图像老人在心理上更容易接受。实现方式是夜间把视觉推理进程挂起只保留雷达信号处理# 通过时间调度关闭视觉任务 import schedule, datetime def enable_privacy_mode(): 夜间隐私模式停用摄像头启用雷达监听 pose.pause() # 暂停姿态检测任务 camera.stop_stream() # 关闭摄像头流 radar.start_detect() # 毫米波雷达开始工作 schedule.every().day.at(22:00).do(enable_privacy_mode) schedule.every().day.at(07:00).do(disable_privacy_mode)这段代码本身不难难在检测到雷达活动异常比如夜间频繁起夜时要不要唤醒摄像头确认我的做法是夜间不主动唤醒但记录频率。如果起夜次数超过正常范围比如一晚超过3次第二天早上主动问一句“昨晚休息得怎么样”既保护隐私又实现健康观察。老人对这种“有分寸的关心”接受度明显更高。4. 具身智能机器人行为决策从“应答器”升级为“会做事的助手”4.1 为什么传统规则系统在陪伴场景里“讨人嫌”早期陪伴机器人普遍采用“意图识别 规则响应”的架构。用户说“播放新闻”机器人就打开新闻说“设置提醒”机器人就定个闹钟。这种架构的问题在于完全没有“场景意识”机器人分不清老人是在自言自语还是在跟它说话也分不清老人此刻是忙碌还是空闲。典型的失败场景是老人在阳台上打电话机器人溜达过来提醒“该吃药了”。老人觉得在客人面前被机器人管着很没面子转头就把机器人关了。规则系统察觉不到这个尴尬因为它的世界里没有“社交场景”这个概念。具身智能Embodied Intelligence要解决的正是这个问题机器人不仅有嘴和耳朵还有身体和环境交互能力它需要把多模态感知信息和自身行为状态放在同一个上下文里做决策。2024年之后大量团队开始把视觉语言动作模型VLAVision-Language-Action引入陪伴机器人目的就是让机器人“眼里有活、心里有数”。4.2 行为决策架构感知融合、意图识别、任务规划三层拆分具身智能机器人的行为决策不能把整个逻辑丢给大模型需要分层。这样做的原因是大模型擅长规划不擅长控制而底层控制代码擅长执行不擅长判断分层后每层只做自己擅长的事情。第一层是感知融合。机器人的输入不只有文本指令还有视觉画面、雷达数据、时间上下文、历史交互记录。这些信息要先统一成结构化格式{ timestamp: 2025-01-15 14:23:05, user: {name: 张奶奶, distance_m: 1.2, face_visible: True, is_sitting: True}, voice: {text: 我有点头晕, emotion: neutral}, context: {last_interaction_min: 47, today_medication_taken: True} }统一格式的目的是让上层模型能一次性读入所有信息而不是分多次调不同模型判断那样延迟会叠加决策也会碎片化。第二层是意图识别。这里用轻量级大模型比如Qwen2.5-3B量化版做判断。意图类别不需要设太多陪伴场景90%的交互落在六类闲聊、服务请求倒水/拿东西、健康异常报告、情绪倾诉、指令执行播放/提醒/拨号、无效对话。prompt 你是陪伴机器人的意图识别模块请从以下文本和情境中判断用户意图。 文本: {user_text} 情境: 老人正在{activity}距离机器人{dis}米 输出格式: {intent: health_issue, urgency: 0.5, action: notify_family} .format(user_text我有点头晕, activity沙发上休息, dis1.2)第三层是任务规划。意图识别只回答“用户要什么”不回答“机器人怎么做”。任务规划层把意图转成动作序列这层才用得上7B参数的视觉语言模型。举例来说如果意图是“health_issue”规划层要决定第一步是移动到老人身边、第二步是播放安抚语音、第三步是测量基本健康参数、第四步是判断是否需要通知家人。用VLM的好处是它可以做“不预设场景”的规划碰到训练数据里没有的情况也能组合出合理动作序列。查询表现为结构化输出response vlm.chat( user_input老人说头晕并坐下我作为陪伴机器人应该怎么做, system_prompt你是一个具身智能机器人的任务规划器只输出合法动作序列JSON不要解释。, formatjson ) # 输出: {action_sequence: [ # {move_to: elderly, speed: slow}, # {play_voice: 我已在你身边需要帮你拿药吗}, # {sense: face_color}, # {condition: {face_pale: True}, call: family, via: volte} # ]}4.3 动作执行导航与云台控制怎么对接规划层输出了动作序列执行层要把这些“抽象动作”翻译成具体的电机指令。导航用ROS 2的Navigation2栈全局规划器用NavFn局部规划器用TEBTimed Elastic BandTEB更适合家庭场景因为它在窄通道和障碍物中能生成更平滑的轨迹。云台控制相对简单。头部云台的两个舵机分别控制偏航和俯仰收到“move_to elderly”指令后底盘移动到位云台舵机再转动使摄像头对准人脸。舵机控制一般走串口给STM32发指令# 通过串口发送云台角度指令 import serial ser serial.Serial(/dev/ttyUSB0, 115200, timeout0.1) def move_head(yaw_angle: int, pitch_angle: int, speed: int): 发送头部云台控制指令 角度范围yaw -60~60, pitch -30~30 速度范围1(慢)~255(快) data bytes([0xAA, 0x55, yaw_angle 0xFF, pitch_angle 0xFF, speed, 0x00]) ser.write(data) def move_base(linear_speed: float, angular_speed: float): 底盘速度指令单位m/s和rad/s cmd fCMD_VEL {linear_speed:.2f} {angular_speed:.2f}\n ser.write(cmd.encode())这两个函数是执行层的核心接口。上层规划器只调用move_base和move_head完全不关心电机怎么转、轮子怎么分配力矩这个抽象能显著降低后续维护和二次开发成本。4.4 安全冗余分层硬件、系统、应用三级兜底具身智能引入了移动和动作能力安全问题随之变得复杂。决策层规划的动作再合理也不能排除模型幻觉导致的风险因此安全不能只放在应用层要做硬件和系统的冗余接管。安全层级实现方式响应时间异常场景硬件层机械急停按钮、电机限流、保险丝毫秒级老人恐慌、机械故障、碰撞系统层STM32看门狗、障碍物急停、底盘速度上限10ms主控死机、通信超时、传感器失效应用层VLM决策复核、行为日志审计秒级规划决策异常、意图误判关键参数是运动速度上限。ROS 2中设置max_vel_x: 0.5加速度0.2m/s²保证在任何情况下机器人的动能都在安全范围。注意应用层可以做“决策复核”但不能依赖它作为唯一安全手段。模型推理有延迟如果只靠VLM判断“前面是老人还是障碍物”再决定制动来不及。碰撞急停必须放在系统层由MCU直接处理不经过主控。5. 真实家庭部署调优续航、延迟、误唤醒和“老人是否愿意用”5.1 续航估算不能只看电池容量要看“功耗分布”很多原型机死在续航翻车上。电池选小了运行3小时就没电选大了机器人又重又贵。续航计算的关键是把功耗按运行模式拆分而不是简单用额定功耗乘时间。陪伴机器人一天的状态大致分为三种待机监听、主动交互、移动巡航。假设电池组用3节18650锂电池串联3S标称电压10.8V容量10Ah总能量108Wh。参考功耗待机10W语音唤醒DSPMCU、交互35WASRLLM推理屏幕显示、移动55W两个电机启动峰值。一天内交互约120分钟移动约60分钟其余时间为待机。日耗电约10W×14.5h 35W×2h 55W×1h 145 70 55 270Wh108Wh电池根本撑不到一天。这意味着两种解法一是把电池加大到6S约216Wh二是把耗电大头“移动”充电式化——机器人只在固定时段巡航其余时间停在充电桩上。行业通常选择后者因为移动本身在陪伴场景中的价值密度低于待机交互。底盘大部分时间不动等于把移动功耗转移给充电桩机器人日耗电降到约180Wh一组108Wh电池配合每天充电两次也够用。5.2 延迟预算端到端1.5秒是陪伴机器人的“生死线”语音交互的响应速度直接决定产品生死。这里给一个参考延迟预算表功能模块时间预算备注唤醒词识别100msopenWakeWord一次推理约30~50ms预留缓冲语音活动检测 录音1.2s~1.8s老人讲话慢通常要完整说完才能识别ASR流式识别首个结果300msFunASR流式模式不需要等整句结束LLM首Token250ms7B量化模型在Jetson Orin Nano上约20~30 token/sTTS流式播放首个音频块150msCosyVoice首包延迟可接受其他系统开销100ms任务调度、IO等待、日志写入整体从老人说完到机器人开口说话预算在2~2.5秒内。如果超过3秒老人会重复提问重复提问又会叠加延迟形成糟糕的体验闭环。优化手段是把LLM和TTS流水线并行ASR还没识别完第一句话时TTS就已经预加载了问候音频老人的第一句话结束后常用意图吃药提醒、讲新闻走预设回复模板不经过LLM这部分能省掉400ms左右。5.3 验证指标不止测延迟还要测“误唤醒”和“漏唤醒”陪伴机器人的验收标准建议单一指标不要只追准确率要看三个参数而且这三个参数的优先级从高到低是误唤醒率、端到端延迟、意图识别准确率。误唤醒是头号敌人比漏唤醒更伤体验。机器人半夜自己说了一句“好的我这就去”老人被吵醒一次第二天就会关掉语音功能。误唤醒率的目标是每天不超过0.5次。调整方案唤醒阈值提到0.8或者设置双词唤醒比如“小乐”必须连续说两遍才触发虽然牺牲了一点便利性但在实际部署中误唤醒带来的伤害大于便利。测试方法也很朴素不用自建测试集把机器人放在客厅正常生活一周记录触发日志统计24小时内唤醒次数和实际对话次数的比例。低于5%的唤醒是机器发出的合格高于10%说明阈值要调了。5.4 一个调优技巧让大模型的“主动说话”频率降下来这是部署中最容易踩的坑。工程师调试时喜欢让机器人主动聊天、主动提醒但真实老人对“话痨”机器人的耐心极短。调优技巧是给LLM接一个“主动说话控制器”判断依据是四项条件都满足才允许主动开口老人处于空闲状态没有在打电话/和邻居聊天、距离机器人1.5米以内、上次交互超过30分钟、当前不是深夜。这四条用规则代码实现不交给LLM判断因为大模型对时间敏感度低会忘记现在是凌晨两点。def should_proactively_speak(is_idle, distance_m, minutes_since_last_talk, is_night): proactive条件: - 老人空闲 - 距离 1.5m - 上次交互已过30分钟 - 不是深夜(22:00-07:00) if not is_idle or distance_m 1.5 or is_night: return False if minutes_since_last_talk 30: return False return True这个控制器上线后机器人的主动打扰投诉几乎为零而老人主动交互的频率反而提高了因为机器人不再“烦人”老人才愿意把它留在身边。本文还有配套的精品资源点击获取