1. 项目缘起一个总在身边的状态哨兵做机器人这些年我折腾过机械臂、折腾过小车但说实话真正让我觉得机器人能改变生活的不是那些炫技的抓取演示而是一个很朴素的念头——当我不在家的时候谁来帮我盯着那个空间谁能在温度异常、老人在家摔倒、宠物拆家、水管漏水这些事发生的第一时间告诉我Kite就是从这个念头里长出来的项目。它是一台陪伴守护型的移动机器人定位很简单不是帮你扫地、不是帮你端茶倒水而是替你在某个空间里守着。它为什么叫Kite因为风筝。风筝在天上飞但线始终在你手里你时刻能感觉到它在那里它也在某种程度上看着你。我想做的这个机器人也是这种关系——它是漂浮在你生活边缘的一个守护者安静、持续、可靠不打扰你但你随时需要它随时在。这个项目我非常推荐三类人重点参考一是独居的年轻人一个人住加班晚归家里有没有异常你完全不知道二是有老人或小孩需要照看的家庭你不能24小时守在旁边但机器人可以三是喜欢折腾开源硬件、对ROS和嵌入式开发有基础的玩家。接下来我会把这个项目的需求分析、硬件选型、导航算法、守护逻辑和踩坑实录全部摊开来聊你能直接照着复现一版。2. 需求解构陪伴机器人到底在陪什么2.1 为什么不做全能管家只做无声陪伴做这类机器人的时候功能膨胀是最容易掉进去的坑。很多人一听说陪伴机器人就想着让它会聊天、会跳舞、会逗宠物、会打灯泡结果做出来一个四不像每个功能都稀烂稳定性还特别差。我在定义Kite功能边界的时候砍掉了一堆花哨功能只保留一条主线感知异常、即时推送、持续在线。这三件事的核心逻辑是机器人的价值密度取决于它能不能在关键时刻给你一条救命信息而不是平时陪你消磨多少时间。比如老人独居时在卫生间摔倒比起一个会说笑话的机器人一个能识别跌倒姿态并在30秒内把消息推送给你妹妹的机器人才是真正有用的机器人。所以我们把Kite定义为状态哨兵而非管家。它不做任何物理干预比如不会去关煤气、不会去浇水它只负责建立一条从物理世界到你手机的通知链路。这个取舍背后是对安全和可靠性的考量——机器人做物理操作一旦误动作反而容易造成二次伤害但纯粹的感知加推送就算误报警最多让家人虚惊一场。2.2 桌面式还是地面移动式确定守护这个核心功能后紧接着就要决定产品形态。我试过两个版本桌面固定式和地面移动式。第一版是桌面式就是把传感器固定在一个位置通过广角摄像头覆盖一个房间。它的优点很明显不需要导航不会没电成本低结构简单。但实际测试下来问题也很明显——卧室和客厅没法兼顾卫生间更是完全覆盖不到一旦老人从沙发上滑坐到地上可能就出了摄像头的视野。后来我改成地面移动式也就是Kite现在的形态。好处是第一一台机器人可以覆盖整个家的多个房间第二移动带来了巡更的能力可以定时定点检查第三也是我没预料到的地面移动让机器人在家里有一种存在感宠物会跟着它跑老人也会习惯它的巡游路线把它当成一个活物而不是一个摄像头。当然移动形态的代价也很现实需要导航、需要续航、需要处理轮子噪音、需要更复杂的机械结构。但从实际使用场景来看这几点代价都可以通过成熟的方案化解自由度带来的价值远远大于成本。2.3 守护的三个核心场景拆解watches over you这句话其实包含三个层次我在设计Kite的时候把它们拆成了具体的功能模块。第一个场景是环境异常。温度骤升、烟雾浓度异常、漏水、二氧化碳超标这些环境传感器数据是可以量化检测的。Kite在巡更到不同房间的时候轮询采集传感器数据一旦发现超出阈值就标记异常并推送。第二个场景是人体突发状态。老人摔倒、久卧不起、长时间没有活动迹象这些需要用视觉或者毫米波雷达来感知。视觉方案对人脸和姿态识别的精度要求高但隐私压力大毫米波雷达保护隐私但识别不了摔倒后的静止状态。Kite最终选择了毫米波雷达为主、摄像头为辅的双模方案稍后我会详细说。第三个场景是行为陪伴。独居的人其实很需要一种被惦记着的感觉。Kite可以学习你的日常作息规律比如你每天早晨七点半出门、晚上七点半到家它就知道在那个时间点等你当你比平时晚了两个小时还没回家它会提前给你推一条消息还在忙吗家里一切正常。这种看起来简单的功能实测下来给用户的情绪价值非常巨大。机器人在某种程度上替代了家人之间的互相惦记这个行为。3. 硬件选型与系统架构实录3.1 主控算力怎么选别盲目上高配Kite的主控我经历了三次迭代。第一版用的是ESP32省电是真省电但跑不了摄像头连基础的实时语音交互都做不了只能做做环境传感器的采集当个会跑的温湿度计还勉强凑合。第二版替换为树莓派4B算力够用但一个致命的毛病是它本质上不是实时操作系统跑运动控制和视觉处理的时候偶尔出现调度抖动轮子会肉眼可见地卡顿这在小车上特别明显。最终我定下来的方案是分体式架构底层用ESP32做运动控制顶层用树莓派CM4做感知和决策两者通过UART串口通信。这样分开了以后电机的实时控制交给ESP32的FreeRTOS去调度20ms的控制周期稳定得很好而摄像头、语音、路径规划这些对实时性要求不高的任务交给Linux系统跑Python脚本就够了。这个架构有点像人的小脑和大脑——小脑管肌肉反射大脑管思考决策两者各司其职。3.2 传感器组合Kite的五感是怎么配的Kite的保护逻辑依赖一套多模态传感器组合我把它称为五感。首先是视觉一个110度广角的USB摄像头装在云台上用来负责识别大范围的动态物体和姿态异常。然后是测距底部前向装了一个激光雷达用来建图和避障定位。第三是近场感知三个ToF传感器分布在机器人前侧和左右两侧负责补充雷达盲区比如床头柜旁的缝隙。第四是环境嗅觉集成了一颗温湿度传感器和一颗烟雾/空气质量传感器前者管冷热干湿后者管异常颗粒物。第五是毫米波雷达装在机身正前方频率24GHz能穿透人体衣物检测微动这解决了摄像头看不清被子下面有没有人起伏的问题。这组传感器里如果只让我留两个我会留激光雷达和毫米波雷达。视觉在家庭环境里受光线影响太大了白天阳光直射会过曝晚上关了灯就基本瞎眼而雷达是主动感知不管白天黑夜都稳定这在守护场景里是决定生死的可靠性差异。3.3 供电与续航机器人渴了怎么办移动机器人绕不开续航问题。Kite用的电池是一块12V/6800mAh的锂电池组满电状态下以0.3m/s的巡更速度可以跑大概2.5小时但如果频繁加减速、频繁启停续航会掉到1.5小时左右。这说明运动规划对续航的影响远大于电池容量本身。我做了一个简单的续航管理策略把家里的巡更点分成高优先级和低优先级默认每小时完成一次全屋巡更但电量低于35%之后自动降级成只巡卧室和卫生间电量低于15%就不再巡更而是主动回到充电桩。这套策略不能让电池容量变大但能把关键时刻有电的概率拉满。另外充电寻址用的不是红外对管而是激光雷达匹配充电桩的反光板坐标准确度比红外高很多适合家里地面有杂物的场景。4. 从机器人走格子到家庭自主巡更4.1 把家变成一张网格地图说到Kite在家庭环境里的运动就不得不提一个特别经典的算法问题机器人走格子。网上很多题目描述是这样的有一个r行c列的格子地图机器人从左上角出发每个格子只能走一次问有多少种不同的走法。这看起来像是竞赛题但它其实就是移动机器人导航的抽象版本——家可以被看成一个由无数个小方格组成的网格地图机器人的任务就是在地图上找到一条从当前位置到目标点的可行路径。Kite在建图阶段用激光雷达跑一遍Gmapping算法把家的平面结构转化为占据栅格地图。每个格子有三种状态空闲、占据、未知。空闲的格子允许通过占据的格子是被墙壁或者家具挡住的未知的格子是还没有探测过的区域。激光雷达每扫描一圈就能更新一圈格子的状态。家里不是一成不变的比如椅子上放了个包、地上多了个快递箱这些都会让某些格子从空闲变成占据所以Kite的地图需要实时增量更新一旦发现局部格子状态变化就触发局部重规划。4.2 最短路径搜索从BFS到A*的演化走格子问题中最基础的做法是宽度优先搜索也就是BFS一层一层往外扩展直到找到目标。BFS求出来的路径一定是步数最短的但缺点是很傻——它不区分方向不管目标在哪个方位都是一圈一圈均匀向外搜。我最早给Kite写路径规划就用的是BFS在8x8的小格子里跑得很好但放到真实的家庭地图上一个客厅就有几十上百个格子BFS的搜索效率就不够看了。后来我换成了A算法。A在BFS的基础上加了一个启发式函数比如当前格子到目标格子的曼哈顿距离这样搜索就会有方向感地朝目标扩展而不是盲目地四周转。实测效果非常明显在一个大约60平方米的两室一厅环境里划分出500个可达格子BFS平均需要遍历400多个格子才能找到路径而A*通常只需要100个左右。搜索步数少了路径规划的时间就从几百毫秒降到了几十毫秒机器人应对动态障碍物的反应速度就快了一个量级。对于走格子问题本身我还想多提一句如果题目里加了每个格子只能走一次这个条件那就不是简单的寻路问题了而是变成了哈密顿路径问题从P问题跳到了NP完全问题。Kite在真实场景里不需要这种约束但如果你在做一些高级巡逻算法需要让机器人覆盖完所有区域那就得换一套思路比如用覆盖路径规划算法让机器人走类似扫帚路径来回扫过整个区域。4.3 动态避障与局部重规划室内的障碍物不是静止不动的。人走过来挡住了路、猫咪躺在地上甚至门被突然关上这些都会让原本规划的全局路径瞬间失效。Kite的避障设计分两层全局规划用A*算出一条大方向上的路径局部规划用动态窗口法实时调整线速度和角速度。动态窗口法的思路特别直观在每个控制周期里把机器人当前能达到的线速度和角速度组合成一个速度窗口在这个窗口里采样很多组速度然后分别模拟用这些速度往前跑一小段时间看看会不会撞到障碍物再看看是不是朝目标方向走、是不是偏得太厉害最后选一个不撞墙且最接近目标的速度输出给电机。这个算法写起来不复杂也就几百行代码但工程细节特别多。比如采样步长太大会漏掉最优速度太小又算不过来再比如对地图膨胀半径设置不当机器人会离墙太近轮子会蹭到踢脚线实测久了容易把线材磨破。5. 守护功能的实现链路与联动机制5.1 毫米波雷达与视觉的双模人体检测Kite最核心的守护逻辑是判断屋子里有没有人、人处于什么状态。我最早用的是纯摄像头方案用OpenCV的全身检测器加姿态估计模型效果不太理想。首先是环境光影响大晚上的暗光场景检测率直线下降其次是隐私问题浴室、卧室这些场景放摄像头家里的长辈心理负担很重总觉得被监视了。后来我引入了毫米波雷达作为主检测源摄像头退居为辅助确认。毫米波雷达的原理是发射电磁波并接收人体反射的回波能检测到微小的胸腔起伏——也就是呼吸。只要人活着哪怕一动不动睡觉雷达都能感知到这里有生命体。Kite用的24GHz雷达可以同时跟踪最多8个目标输出目标的距离、角度、速度和微动能量。这些数据不需要读取任何生物特征识人不可识面对隐私敏感的用户来说接受度高很多。检测逻辑是这样的雷达如果判定某区域有人体微动但摄像头在光线好的情况下又能看到人形就标记为有人且正常如果雷达能检测到呼吸但摄像头看不到人形大概率是人被被子盖住了或者人在床上了标记为有人但不可见如果连续10分钟雷达和目标区域的摄像头都检测不到任何人体存在而根据作息规律此时应该有人就触发一次失联告警。5.2 异常事件的定义与分级推送不是所有异常都应该立刻推消息给用户否则机器人会变成狼来了的制造者。Kite把事件分成三个等级。一级是普通提醒比如室温超过30度、门外探测器感应到有人徘徊会推送到手机App的消息中心用户有空查看就行。二级是关注提醒比如老人长时间待在卫生间超过40分钟、宠物呕吐物被视觉模型识别到这类会直接推送通知栏并且响一声提示音。三级是紧急告警比如检测到跌倒姿态、烟雾浓度超标、连续12小时没有检测到任何人的呼吸这类会立刻推送短信和电话呼叫用户可以在App里预设3个紧急联系人。分级推送的背后其实是信噪比管理。如果一个守护机器人一天推30条消息用户用不了一周就会把通知权限关掉。我的经验是宁可漏掉一些不痛不痒的事件也绝不能因为垃圾告警让用户形成看到也不点开的习惯。报警信息必须在最关键的时候出现在屏幕最显眼的位置这远比所有情况都通知有价值。5.3 联动场景举实例凌晨三点的漏水检测讲一个真实发生过的联动场景。有天凌晨三点Kite在巡更时发现卫生间地面区域的ToF测距数据出现异常波动——它反射回来的距离比平时短了几厘米DataType显示不是人形而是一大片平整的平面。我把这个信号和湿度传感器数据叠加发现卫生间区域湿度在短时间内从45%飙升到70%这就形成了一个高置信度的推定地面有积水。Kite的处理流程是这样的先做一次局部重规划靠近卫生间门口再启动摄像头抓取一张照片然后通过本地目标分类模型判断照片里有没有明显的水渍反光确认后立刻推送二级关注给用户消息附带照片和湿度变化曲线。整个过程从发现异常到推送消息用了不到40秒。用户醒来看到照片和曲线赶在楼下邻居天花板湿掉之前关了水龙头。这就是watches over you这件事的价值——不需要机器人自己会拧水龙头但需要它能在最合适的时间把最需要的信息送到最合适的人手上。6. 实操复盘两个月的测试和那些让人头秃的Bug6.1 雷达误报窗帘飘动被识别成有人跌倒测试阶段最多的问题就是误报。有一天下午系统连续给测试手机推了三次跌倒告警我赶回家一看发现是客厅的落地窗开着风吹着窗帘鼓起来又落下雷达把窗帘的微动误判成了人体动作。这个问题的根源在于我的跌倒识别算法只看目标的速度突变高度骤降而飘动的窗帘恰好具备快速位置变化的特征。解决思路是在算法里加一个形状连续性的判断——人体跌倒后虽然位置下降但它的回波轮廓会保持一个整体而窗帘飘起来的时候回波是分散的、边缘不规则的。我在毫米波雷达的数据流上加了轮廓聚类只有当一个目标的回波点数量超过阈值且分布紧凑时才进入姿态识别流程。改完之后误报率从每天五六次降到了每周不到一次。6.2 地图漂移轮子打滑导致撞墙的假象有一次Kite在跑巡更任务时行为特别诡异——它在走廊里走着走着突然原地转圈然后一头朝墙冲过去。排查了半天才发现问题出在地毯上。客厅入口有一块厚地毯轮子在上面打滑编码器计算的里程就会累积误差导致机器人以为自己已经走到了走廊尽头但实际才走了一半。导航系统基于错误的里程数据做了重定位地图偏移了大约20厘米它眼中的世界和真实世界就对不上了。解决办法有两个层面。硬件上我把轮子从普通橡胶轮换成了带花纹的聚氨酯轮抓地力强了不少软件上我加了扫码重定位功能用激光雷达匹配当前扫描与地图的局部特征做校正。小打小闹的误差靠里程计推算误差大到雷达都匹配不上的时候就启用重定位。这套策略后来在多次搬家具后的场景里也表现得不错。6.3 续航焦虑充电桩永远差两厘米移动机器人最阴间的时刻就是它转了十来圈才找到充电桩然后离充电桩两厘米的位置停下了试了好几次都怼不进去。我前前后后调了将近两周最后发现是充电桩的电极和机器人侧电极的接触角度问题——机器人停靠时左右偏差很小但前后距离的判断不够准导致电极没有完全接触。最后我加了一个接触检测的微调逻辑机器人先根据激光雷达的定位停到充电桩前方大约五厘米处然后切换成低速蠕动模式以每秒一厘米的速度缓慢前进同时检测充电电路里的电压有没有变化。电压一抬升就说明电极接触上了立即停止前进并锁住轮子。另外在充电桩前面加了两条塑料导向槽就算机器人歪了十几度轮子滑进去也能被强制修正方向。这个物理加软件双重保险的方案在后来的测试里再也没有翻过车。7. 后续还能怎么玩两个我认为值得扩展的方向Kite目前的版本已经稳定跑了两个月日常巡更、异常告警、跌倒识别、远程查看这些功能都处于可靠状态。在写这篇文章的时候我又在盘算两个新的扩展方向。第一个方向是双向语音对讲。现在Kite能检测到异常并推送给用户但用户如果想跟家里的老人对话还得通过手机App单独拨号体验是断裂的。我在硬件上预留了麦克风阵列和扬声器的接口下一步计划把这些集成到守护链路里一旦触发二级以上告警可以一键在App里发起语音通话让机器人的摄像头转过来当视频电话机这样用户能直接从手机上看到现场情况也能直接跟在现场的家人说话。第二个方向是学习型行为建模。Kite现在已经能记录什么时候家里有人、什么时候没人这样的作息规律但我希望它还能学习异常作息。比如一位老人通常早上六点起床如果某个早晨到九点雷达都没有检测到起身的动作那就应该自动触发一次晨起异常提醒给家属。这其实是一个时间序列预测问题我打算在树莓派上用轻量级的LSTM模型跑模型每小时更新一次用最近两周的数据做输入。目前我已经在边缘设备上跑通了一个简化版本误差大约在15分钟以内。陪伴机器人的价值不在于堆了多少炫酷的技术而在于它是否真的能感知到你生活的微小波动并在那些波动的瞬间给你一个确定的回应。这是Kite这个项目最重要的设计哲学也是我在整个开发过程中最大的体会。如果你也想做一个类似的守护机器人我给你的最核心的建议是先把稳定发现一次异常并成功推送给用户跑通再考虑加功能。所有其他花哨的能力都构建在这条最朴实、也最需要打磨的链路之上。做机器人没有捷径但把每一步走稳了你真的能在某个关键的时刻感受到这个风筝牵着你生活另一端的线。