1. 项目背景与整体架构思路做四足巡检机器人这件事在工业场景里已经不算新鲜了但真正让它从“实验室demo”走向“能稳定值班”的往往是那些看起来不起眼的边缘细节。举个例子一座化工厂有六层楼巡检机器人白天在一楼配电房、二楼泵区转悠晚上得自己上四楼查看仪表盘电梯是唯一通道——这时候问题就来了机器人怎么自己坐电梯有人会说这有什么难的给电梯装个物联网模块让机器人发个指令不就行了。真到现场你就会发现电梯厂商的协议千奇百怪老旧电梯可能连RS485接口都不完整梯控系统动一下都要签安全协议。更现实的情况是电梯属于特种设备很多厂区不允许你在电梯控制系统上做任何改动。那怎么办最靠谱的路线就是用“视觉边缘计算MQTT通讯”的方案在电梯外和电梯内各部署一个边缘计算盒子通过识别电梯楼层显示数字和运行方向让机器人像人一样“看懂”电梯来了没、往哪走、到没到。这个项目要解决的就是用边缘计算盒子配合MQTT协议让四足机器人具备完整的自主乘梯能力自动呼叫电梯、判断电梯到达、确认梯内状态、进入电梯、选层、出电梯整个过程不依赖电梯本身的开放性接口完全靠外部感知来完成。1.1 为什么必须上边缘计算而不是全靠云端第一版方案我们其实试过纯云端识别机器人端摄像头拍下电梯楼层照片通过4G传到服务器识别识别完再告诉机器人下一步动作。听起来可行一实测就露馅。电梯门从打开到关上的时间一般是3到5秒如果机器人恰好在电梯到达楼层时才收到识别结果还要留出运动规划时间根本来不及。加上厂区网络偶发抖动一张图片传上去1秒、识别200毫秒、结果传回来500毫秒整个链路算下来已经逼近机器人动作响应的极限。所以边缘计算的核心理由就一条能省的网络延迟必须省掉能本地化的判断绝不依赖远端。在电梯厅和轿厢内部署的边缘盒子图像识别、状态判断都在本地完成一次识别耗时控制在80到150毫秒这个量级机器人完全等得起。与此同时边缘盒子之间、边缘盒子和机器人之间用MQTT协议做状态同步保证整个乘梯过程中各方对“电梯状态”的理解是一致的。另一个关键原因在数据量上。一台四足机器人执行一次乘梯动作摄像头可能要连续录制3到5分钟的视频按1080p 25fps算原图数据量约1.5GB全传云端既不现实也没必要。边缘计算盒子只上传识别结果和关键帧——类似“电梯到1层门开机器人进入”——单次乘梯的上行数据量可以压到几百KB。1.2 整体架构谁在听、谁在说、谁来做决策整个乘梯系统涉及三个角色四足机器人本体负责运动控制包括在电梯厅等待时的站立姿态、进入电梯的步态规划、轿厢内的原地转身等。它是执行者也是最终决策方。边缘计算盒子A电梯厅外固定在电梯门斜对面负责识别电梯运行方向、楼层指示数字、电梯门开关状态。识别结果通过MQTT实时广播出去。边缘计算盒子B轿厢内安装在轿厢内部角落负责识别楼层按钮面板、轿厢当前楼层、轿厢内是否拥挤这个对四足机器人特别重要空间不够是挤不进去的。三个角色之间的通信链路全部走MQTT协议。MQTT在这里起到的是“轻量级消息总线”的作用——边缘盒子A发现电梯到达1层发布消息机器人订阅了这个主题收到消息就开始往电梯门方向调整位姿机器人进入轿厢后边缘盒子B确认轿厢内位置足够再发布一条“可以关门”的消息让机器人自己操作选层按钮。选边缘计算和MQTT这套组合还有一个务实原因整个系统是弱耦合的。任何一个边缘盒子掉线了机器人不会死机只是会切换为保守策略——原地等待并语音告警而不是贸然行动。这在工业场景里至关重要因为机器人一旦进了电梯又被门夹住就不是软件问题了是安全事故。2. 边缘计算盒子的选型与部署要点项目的热搜词里有一条“边缘计算盒子选型指南”说明选型是很多人实践时第一道坎。我拿我们实际项目里的配置来当参照但先说明一下不同场景的算力需求差异很大如果只是识别电梯楼层数字和门状态其实不需要上特别夸张的配置。2.1 算力配置看着选不如算着选我们的边缘盒子核心参数是CPU选用四核Cortex-A55级别的处理器NPU算力在2到3 TOPS之间内存4GB起步支持双路千兆网口和一个USB3.0接口。这套配置放在2024年的市场里属于中端偏下但乘梯识别场景完全够用为什么先算算要跑哪些模型。楼层数字识别本质上是一个轻量级OCR任务输入图像分辨率1280×720模型参数量不到5MB单帧推理在NPU上的耗时大约40到60毫秒。电梯门状态识别是一个二分类或三分类模型——开、关、半开——处理起来更快。真正吃算力的是轿厢内拥挤程度判断需要跑一个人体检测模型但也不需要实时跑每300毫秒抽一帧就够了。对比一下边缘盒子A只要同时运行楼层识别和门状态识别两个模型CPU占用率控制在50%左右就够边缘盒子B要额外跑人体检测建议算力往上加一档3 TOPS起步比较稳妥。如果梯内空间特别小想用深度相机做三维空间占用判断那算力需求得再往上走至少6 TOPS。顺便说说为什么不用工控机替代边缘盒子。工控机性能确实强但功耗、体积、安装方式都不适合电梯厅这种场景。电梯厅的安装空间通常非常有限有的甚至只有墙角一小块位置边缘盒子巴掌大小的体积和导轨安装方式优势明显。更重要的是边缘盒子通常支持12V或24V直流供电可以直接从电梯厅的检修插座取电不需要额外拉220V线路。2.2 传感器配套摄像头角度决定成败边缘盒子本体只是算力平台真正影响识别效果的是配套的摄像头。我们的第一版方案在摄像头选择上就吃过亏。电梯厅外的摄像头建议安装在电梯门斜上方约2.5米高度俯视角度在30度到45度之间。这个角度有两个好处第一能看到完整的电梯门框门开关状态不会误判第二能看到电梯上方的楼层数字显示器。但要提醒的是很多老旧电梯的楼层指示器是七段数码管相比液晶屏数码管在摄像头高曝光下会出现明显的笔画粘连识别难度会大不少。所以选摄像头时优先挑支持手动调节曝光时间的型号而不是全靠自动曝光。轿厢内摄像头的位置更讲究。四足机器人在轿厢内行动时如果摄像头安装过低会被机器人本体遮挡安装过高又很难看清楼层按钮面板。我们最终的安装位置是轿厢顶部靠近按钮面板一侧的角落高度在2.2米左右斜向下30度。这样既可以看到按钮面板也可以看到轿厢大部分地面空间。2.3 部署时容易忽略的三个物理细节第一供电稳定性。电梯厅的检修插座通常和电梯共用电源回路电梯启动时电压跌落可能达到10%以上。边缘盒子如果直接用开关电源供电一旦电压跌落可能触发重启。建议在供电线路上加一个电容保持模块或者小型UPS哪怕只能撑2到3秒也能避免电梯频繁启停导致盒子反复重启。第二散热。边缘盒子长年挂在电梯厅墙壁上夏天环境温度可能接近40度盒子自身发热如果散不出去NPU会触发降频识别速度直接翻倍变慢。选择金属外壳的盒子不要选塑料壳必要时在盒子底部加一片导热硅胶垫帮助散热。第三网络。电梯厅和轿厢之间的网络环境很恶劣轿厢是一个移动的金属笼子Wi-Fi信号衰减非常严重。我们在项目里用的是边缘盒子自带4G模块的方案两个盒子各插一张物联网卡通过公网MQTT服务器中转消息。虽然多了一层公网延迟但实测下来局域网和4G两种方式在乘梯场景下的延迟差距不大——电梯开关门周期是秒级的而4G往返延迟通常是50到100毫秒完全能接受。3. MQTT协议在乘梯场景中的具体设计与级联策略MQTT协议在这个项目里承担的角色可以用一句话说清楚它让三位各司其职的“同事”能够用同一种语言同步状态。但直接用MQTT默认配置肯定不行必须针对乘梯场景重新设计消息主题、服务质量等级和心跳机制。3.1 消息主题设计从业务反推出来的命名规范我们的MQTT消息主题设计遵循“层级化、职责单一、关键事件独立主题”三个原则。举几个实际的例子robot/{robotId}/status # 机器人状态上报 robot/{robotId}/event # 机器人关键事件比如已进入轿厢 elevator/{groupId}/status # 电梯状态汇总比如到达1层门开 elevator/{groupId}/command # 电梯控制指令比如呼叫到1层 edge/{edgeId}/health # 边缘盒子心跳与健康状态主题设计看似简单但有三个细节要特别注意通配符的粒度要控制好。机器人和边缘盒子订阅时尽量订阅精确主题避免用#通配符一次性订阅整个层级。因为工业场景下MQTT服务器上可能同时跑着其他业务——门禁、照明、环境监测——通配符过大会让机器人收到大量无关消息挤占带宽和处理资源。事件主题和状态主题要分开。事件是一次性的“电梯到达1层”这个消息发完就过去了订阅方收到后要做动作状态是持续性的“当前楼层是3层”会每隔几百毫秒发一次订阅方只需要用最新状态覆盖旧状态。如果混在一个主题里很容易出现事件漏处理或状态过期的问题。主题里带上groupId而不是deviceId。这里考虑的是多电梯场景的扩展性。如果一个厂区有4部电梯机器人呼叫某部电梯后只需要关注这一部电梯的状态。groupId对应“某栋楼某区域的一组电梯”可以做到业务隔离。3.2 QoS等级选择在可靠性和实时性之间找平衡MQTT协议有三种消息服务质量等级QoS 0最多一次、QoS 1至少一次、QoS 2恰好一次。选错了要么消息丢要么消息重复处理。我们的经验是电梯状态上报用QoS 1。这类消息允许重复但不允许丢。比如“电梯到达1层”如果丢了机器人会一直在电梯厅里傻等直到超时告警。QoS 1虽然可能产生重复消息但我们的消息体里带了时间戳字段接收方可以通过比较时间戳丢弃1秒内的重复消息。控制指令用QoS 1且必须带消息唯一ID。“呼叫电梯到1层”如果被重复执行虽然电梯控制系统一般有幂等处理但保险起见还是用消息ID做一次去重。边缘盒子心跳消息用QoS 0。心跳几百毫秒就发一次丢几包无伤大雅用成本更低的QoS 0反而合理。如果用QoS 1心跳消息大量确认回执反而会挤占带宽。这里要特别提醒一个坑不要把QoS 2用在乘梯流程上。QoS 2的握手协议需要多轮确认单条消息端到端延迟可能到200毫秒以上而且会占用大量会话状态。在电梯门3秒就关完的场景里消息多等200毫秒可能就错过了乘梯窗口。可靠性不是无限堆协议等级换来的而是靠业务层的确认与重试机制兜底。3.3 断线重连与边缘自治MQTT会话机制的巧妙应用乘梯场景有大量时间机器人处于电梯轿厢内——这是信号屏蔽最严重的区域。4G信号在轿厢内可能从满格跌到两格MQTT长连接动不动就断。MQTT协议的“持久会话”机制在这里非常有用。我们把机器人和边缘盒子的MQTT客户端都设置为cleanSessionfalse这样在断线重连期间服务器会为客户端缓存未确认的消息重连后自动补发。但对于电梯状态这类高频消息补发反而可能造成状态滞后——等机器人重连成功收到的是30秒前的“门开了”消息——所以要配合消息里的时间戳做过期判断超过5秒的消息直接丢弃重新等新消息。更关键的是整个乘梯流程不能因为网络断了就完全停摆。我们把边缘盒子设计成了“自治节点”即使机器人和边缘盒子之间的MQTT链路断了边缘盒子依然可以自行判断电梯状态然后通过本地IO口输出一个开关量信号触发电梯厅的声光提示器。机器人本体虽然收不到消息但可以通过自身的激光雷达感知电梯门开关状态来兜底。这就是边缘自治和云端依赖之间的差别——边缘计算保证的是即使通信断了局部系统还能按预设逻辑运行。4. 机器人自主乘梯逻辑状态机设计与核心实现乘梯逻辑听起来简单——“等电梯进去按楼层出去”——但每一步都有坑。我建议把整个乘梯过程建模成一个有限状态机每个状态定义清楚“进入条件、执行动作、超时处理、异常跳转”而不是用if-else写流水账。4.1 乘梯状态机的核心状态定义我们的状态机包含7个核心状态IDLE - CALLING - WAITING_ELEVATOR - BOARDING - RIDING - EXITING - DONE每个状态内部的逻辑是这样的IDLE空闲机器人完成当前楼层巡检任务收到乘梯任务。此时第一步不是直接呼叫电梯而是先做乘梯自检边缘盒子A是否在线、边缘盒子B是否在线、电梯当前状态是否已知、机器人电量是否足够支撑乘梯。CALLING呼叫电梯机器人通过MQTT发布“呼叫电梯”指令。这里有个关键参数呼叫之后不立即往电梯门走因为电梯响应时间不确定可能3秒就到也可能30秒才到。如果机器人太早站在电梯门口电梯门一开它还没调整好姿态就容易卡住。我们的策略是呼叫后在距离电梯门2.5米的安全位置等待收到“电梯到达”事件后再运动到门前。WAITING_ELEVATOR等待电梯机器人缓慢移动到电梯正前方约1.2米处。此时边缘盒子A持续上报楼层和门状态。机器人要判断两件事第一目标楼层是否有电梯到达第二电梯内剩余空间是否足够。轿厢拥挤度数据由边缘盒子B提供如果连续3次检测都判定为拥挤机器人会原地等待并提醒。BOARDING进入电梯电梯门全开后机器人开始进入。这里有一个大多数方案不会考虑到的细节——四足机器人在进入电梯时需要一个“停顿点”。因为轿厢和楼层之间存在约2到3厘米的缝隙和微小高度差机器人步态规划时必须先迈一只脚试探确认支撑面稳定后再完全进入。如果直接按照常规步态往前走很容易在门槛处打滑或踏空。RIDING乘梯运行机器人进入轿厢后第一件事不是按楼层按钮而是先转身面向轿厢门方向。为什么因为电梯启动和停止时会有明显的加减速晃动四足机器人如果不面向门方向四条腿在晃动中容易乱步。为了保持稳定我们给机器人加了一个乘梯姿态指令四腿微曲重心降低保持站立不执行任何运动命令。EXITING出电梯到达目标楼层后电梯门打开机器人等待1秒再出发。这1秒是为了确认电梯门开到位防止走到一半门开始关。出门时同样要走“试探步”。4.2 视觉识别如何判断“电梯到了”电梯状态感知是整套逻辑的耳目。我们用了两路信号做交叉验证避免单一视觉判断出错第一路信号是楼层数字识别。边缘盒子A通过OCR识别电梯上方楼层指示器当识别结果从“3”变成“1”时判定电梯正在下行。但单独依靠楼层数字是不够的——如果识别偶尔丢帧可能漏掉中间楼层。第二路信号是电梯运行方向判断。这个判断不是靠数字变化推算而是直接通过光流法分析电梯运行指示灯的亮灭状态。很多电梯在轿厢上方有“上行/下行”箭头灯亮灯的瞬间说明电梯开始移动。光流法对箭头灯的闪烁检测非常敏感——这是视觉方案里少有的“事件驱动型”感知。两路信号在边缘盒子A本地做加权融合楼层数字识别结果的权重是0.7方向灯状态的权重是0.3。融合结果通过MQTT发布。只有楼层数字和目标楼层匹配且方向正确时才判定“电梯到达”。如果两路信号冲突比如楼层数字显示1楼但方向灯显示上行盒子会判定为异常状态发布“未知”状态机器人收到后不会行动等待下一帧识别结果。4.3 基于MQTT消息的乘梯状态同步机制乘梯过程中机器人、边缘盒子A、边缘盒子B三方需要保持状态一致性。我们设计了一套基于MQTT消息序列的“状态同步握手”机制1. 机器人 - 边缘盒子Aelevator/{groupId}/command CALL:target1 2. 边缘盒子A - 机器人elevator/{groupId}/status ARRIVED:floor1,directiondown,dooropen 3. 机器人 - 边缘盒子Brobot/{robotId}/event BOARDING 4. 边缘盒子B - 机器人edge/{edgeId}/status SPACE_OK,positionleft_back_corner 5. 机器人 - 边缘盒子Brobot/{robotId}/command SELECT_FLOOR:floor4 6. 边缘盒子B - 机器人elevator/{groupId}/status FLOOR_CONFIRMED:floor4 7. 机器人 - 边缘盒子Arobot/{robotId}/event EXITED这套机制保证的不仅是信息传递更重要的是一种“确认-反馈”的闭环。例如第4步机器人在收到“SPACE_OK”之前不会执行按楼层按钮的动作因为如果轿厢内空间异常机器人可能无法转身去操作按钮面板。4.4 异常处理与安全兜底工业场景里异常不是万一而是必然。这里我把乘梯过程常见的异常和兜底策略列一下异常情况检测方式兜底策略电梯呼叫超时机器人等待超过90秒无响应重新呼叫一次连续3次超时则放弃乘梯改走楼梯或上报任务失败电梯门开但未开到位边缘盒子A识别门开度90%机器人不行动等待3秒重新识别持续异常则退回到安全位置进入电梯时碰到门四足机器人腿部力传感器触发立即后退半米重新调整朝向降低前进速度电梯内站不稳IMU检测到较大倾斜角降低重心腿距调宽仍不稳定则贴墙支撑乘梯中通信中断超过2秒未收到心跳消息机器人保持当前状态等待通信恢复5秒仍失败则按下紧急呼救按钮目标楼层被跳过边缘盒子B检测到楼层变化未经过目标楼层保持乘梯状态在到达最近停靠层后重新呼叫目标层其中最容易忽视的是“乘梯中通信中断”这个场景。电梯井里4G信号非常不稳定我们实测轿厢运行时MQTT断连概率在15%到20%之间。如果在乘梯过程中断连机器人不能贸然开门出电梯——它可能正处在非目标楼层。我们的处理是保持站立不动等通信恢复后再确认当前楼层这样最安全。5. 现场部署实录与参数调优过程前面讲的大部分是设计层面的内容真正到了现场你才会见识各种“实验室里想象不到的问题”。5.1 第一轮现场测试几乎全军覆没的教训我们第一次在现场联调时系统完全不工作。问题出在楼层数字识别上——项目现场的电梯是老式七段数码管在摄像头里闪个不停OCR识别结果从“1”跳到“7”再跳到“4”完全没法用。后来排查发现是数码管的PWM调光频率和摄像头自动曝光频率产生了差拍效应导致每一帧的亮度都在变化笔画时亮时灭。解决方法是把摄像头的曝光时间固定为2毫秒同时关掉自动增益。这样虽然画面整体偏暗一些但每一帧的显示内容都是稳定的。识别准确率从不到50%直接提升到97%以上。如果遇到更严重的情况——数码管闪到连固定曝光都救不回来——还有一个笨办法在摄像头前加一片偏振镜消除部分反射和眩光。5.2 MQTT参数调优从丢消息到稳定运行的三个关键参数部署初期我们频繁遇到“机器人发布了呼叫指令但边缘盒子没反应”的问题。排查了一圈发现MQTT参数设置有三处没过关keepalive间隔。默认的60秒心跳间隔在电梯井这种恶劣网络环境下太长了。边缘盒子刚断网时服务器要等60秒才能发现连接已死期间消息一直积压。我们把keepalive调整为15秒服务器能在15秒内发现断线快速触发重连。maxInflight。MQTT协议允许客户端并行发送多个未确认消息但如果并行度太高在弱网环境下会频繁触发重传风暴。我们把这个参数限制在10实测在4G网络抖动时稳定性明显提升。消息大小限制。边缘盒子发布的消息里如果带了Base64编码的识别帧图片单条消息可能超过100KB。MQTT最怕这种大消息会阻塞后续消息通道。解决方法是把图片上传到边缘盒子的本地FTP服务MQTT消息里只放图片URL接收方按需拉取。5.3 四足机器人乘梯姿态参数调整四足机器人在平地上健步如飞进了电梯就变成另一个物种——空间太窄转身困难地面还有轻微坡度。我们花了大量时间在参数调试上进入电梯前的等待位姿距离电梯门1.2米正面朝向门中心。太近会阻挡电梯门传感器导致门关不上太远进入时间过长。转身策略进入电梯后如果空间够大优先采用原地小步旋转每次旋转5度分多次完成180度转身。如果空间小直接放弃转身用倒走方式出电梯。轿厢站立姿态四腿间距调至默认宽度的1.2倍重心高度降低15%关节刚度增加20%。这样即使电梯启停晃动机器人躯干倾角最大也只偏移3度。5.4 网络架构的最终形态经过现场调试最终的通信架构是边缘盒子A和边缘盒子B各带一个4G模块通过公网MQTT服务器互通机器人通过工业Wi-Fi接入厂区网络。Wi-Fi信号在电梯厅内强度尚可进入轿厢后会明显衰减因此机器人本体在乘梯过程中不依赖Wi-Fi与边缘盒子保持长连接而是走MQTT的持久会话机制断线后自动重连。通信链路方式延迟可靠性盒子A - 盒子B4G - 公网MQTT80-150msQoS 1盒子A - 机器人4G - 公网MQTT80-150msQoS 1盒子B - 机器人4G - 公网MQTT80-150msQoS 1机器人 - 盒子A/B工业Wi-Fi - 公网MQTT50-120msQoS 0/1这种全公网中转的方案在初期看起来有点“土”但运行三个月后证明非常稳定。相比自建局域网它少了很多网络配置的麻烦——厂区IT不会为你的机器人单独开放VLAN但允许你走4G。6. 常见问题与排查技巧实录整理一下这个项目运行半年多以来遇到的高频问题希望能帮有类似需求的人少走弯路。6.1 边缘盒子长期运行后的识别漂移边缘盒子连续运行几天后楼层数字识别准确率会明显下降。排查发现是摄像头镜片积灰导致图像模糊厂区环境粉尘比较大。解决方法是给摄像头加一个透明防护罩并在边缘盒子上做了一个简单的图像清晰度评估脚本——如果连续100帧的拉普拉斯方差低于阈值就通过MQTT发布一条“镜头需要清洁”的告警消息。实测下来这个告警机制特别有用因为它把“被动发现识别不准”变成了“主动提醒维护”避免了很多次乘梯任务失败。6.2 电梯门传感器对四足机器人的误触发工业电梯的门传感器大多是光幕式或雷达式四足机器人的高度和形态有时候会触发光幕的盲区判断——门关到一半突然反弹重新打开导致边缘盒子A识别到“门开→门关→门开”的状态抖动机器人因此在电梯口反复进退。这个问题比较头疼因为我们不可能去改电梯的门传感器。最后的方案是在机器人等待时尽量贴近电梯门一侧站立减少在门中央的投影面积。同时在软件上增加了“门状态稳定确认”逻辑连续3帧识别结果一致才更新状态避免单帧抖动触发误动作。6.3 MQTT消息积压导致的“幽灵指令”在弱网环境下QoS 1消息未收到确认就会一直重发。有一次边缘盒子A断线了3分钟重连后服务器把积压的几百条“呼叫电梯”指令一口气发给了机器人机器人直接进入混乱状态。解决方法是给每条控制指令加上“有效时间戳”字段接收方在处理前先判断指令是否在有效期内。过期指令直接丢弃不做任何响应。同时服务器端配置了消息过期时间让积压的旧消息在服务器上就被清理掉。6.4 雷雨天气下的通信中断项目所在地区夏季雷雨频繁4G基站在雷雨天气可能出现短暂拥塞导致边缘盒子A/B频繁断连。我们加了一个业务层的应对策略检测到边缘盒子B掉线时机器人自动切换为“保守模式”——不进入电梯原地等待通信恢复。这个策略看起来很消极但实际运行中非常有效与其在通信不稳时冒险乘梯不如多等两分钟。6.5 误识别电梯楼层数字的最终防线虽然视觉识别精度已经做到97%以上但工业场景不允许机器人坐错楼层。我们设计了一个简单的校验机制机器人进入电梯后边缘盒子B通过读取电梯轿厢内的楼层按钮面板来判断当前楼层。按钮面板上的楼层数字比电梯外部的指示器更容易识别因为它在轿厢内固定不闪而且只有一组LED灯亮起。两路识别结果做交叉比对如果不一致机器人立刻语音告警并放弃乘梯。这套“双视觉校验”机制看似简单但真正做到代码层面其实需要不少工程细节两路识别的时间戳要对齐、状态机要能处理不一致的分支、异常告警要能准确传达给运维人员。但从实际效果来看它把乘梯坐错楼层的概率几乎降到了零。7. 写在最后的个人经验这个项目从设计到稳定运行前后花了将近五个月时间。回过头来看最让我感慨的不是技术本身有多深而是很多“坑”都藏在工程细节里——电梯门传感器对机器人的误触发、数码管闪烁导致的识别失效、MQTT消息积压引发的指令风暴这些都不在书本上只能靠现场一点点踩出来。如果让我给后来者三条建议第一尽早把整个乘梯逻辑拆成状态机来设计不要在流程代码里堆if-else第二边缘盒子的算力不要省因为你永远不知道现场会不会增加新的识别需求第三MQTT的主题设计和QoS策略一定要在项目一开始就定清楚后期改起来牵一发动全身。技术上还有一个方向我觉得后续值得做就是在乘梯过程中加入更丰富的环境感知——比如用深度相机检测轿厢地面的微小障碍物或者通过声音传感器识别电梯运行异常。这些都能让机器人的自主乘梯从“能坐电梯”进化到“安全地坐好每一步电梯”。这个项目只是开始真正的工业落地还有很长的路要走。