1. 先把“机器人乘梯”这件事拆明白做移动机器人落地的人应该都有同感地面导航再卷一到电梯口就卡住。单位里跑得再好的AMR出了实验室、进了写字楼碰见电梯就得认怂。为什么因为电梯本质上是一个“外部系统”它不是你机器人地图里的一部分它有自己的控制逻辑、自己的门、自己的调度优先级。你让机器人自己按按钮它按不到你让它等人开门它不知道门什么时候开你让它挤进去它怕被夹。所以“机器人乘梯”从来不是一个导航问题而是一个跨系统协同问题。标题里提到的这套“场景版”解决的就是这件事机器人、AGV、AMR、机器狗这类移动设备通过梯控协议跟电梯控制系统直接对话完成外呼在电梯厅召唤电梯、内呼进轿厢后选择楼层、位置校验、开门保持这一整套动作。目标就三个——安全、效率、通用。安全是底线不能被夹、不能踏空效率是价值电梯不是自家专梯等一轮电梯可能要几分钟能快一秒是一秒通用是前提不管你是轮式的、履带的还是四足的协议层面得统一。这篇内容适合谁看主要是三类人一是做机器人调度系统或底盘开发的工程师需要把乘梯模块接到自己的系统里二是做智慧楼宇、物流配送项目集成的人需要评估梯控对接方案三是刚入行、想搞清楚“机器人和电梯到底怎么说话”的开发者。我不会只讲概念会把协议交互的细节、调试流程和踩坑记录都摊开来讲。有人可能会问为什么不让机器人用物理按钮红外发射器按电梯按钮的方案确实存在但它有三个致命问题第一不知道电梯是否真的响应了没有状态反馈第二不知道电梯到了没有只能靠视觉猜第三无法控制开门时间电梯门3秒就关机器人还没进去就被夹。梯控协议对接则完全不同电梯的楼层、方向、门状态都能实时读到还能主动要求电梯“别关门等我进去”。这才是真正可落地的方案。2. 一个完整的乘梯流程要拆成几个阶段2.1 外呼阶段在电梯厅里“叫梯”外呼英文叫Hall Call就是机器人在电梯厅按下上/下按钮告诉电梯“我在某一层要坐电梯”。对机器人来说外呼的核心难点不是发出命令而是确认命令被正确执行了。想象一下这个场景一台配送机器人停在3楼电梯厅调度系统下发任务让它去10楼。机器人通过梯控模块发送一条外呼指令“请派一台电梯到3楼方向向上”。指令发出后机器人面临三个未知一是电梯有没有收到指令网络可能抖动指令可能丢失梯控板可能忙。二是电梯愿不愿意响应如果电梯处于检修模式、消防模式或者被更高优先级的人为呼叫抢占指令就会排队或作废。三是电梯来了没有光知道“指令已发送”没用必须知道“电梯已到达3楼门已打开”。所以外呼阶段必须有一个状态轮询或状态订阅机制。推荐的实现方式是在机器人端维护一个“电梯呼叫状态机”从“CALL_SENT”指令已发到“ELEVATOR_ARRIVED”电梯已到再到“DOOR_OPENED”门已开只有状态推进到“DOOR_OPENED”才算外呼成功。这个阶段还有一个容易被忽略的细节——方向匹配。电梯厅的上下行按钮是分开的机器人要坐电梯上楼就必须呼叫上行梯如果发成下行召唤电梯可能先向下走再折返白白多等一两分钟。协议交互时要把“目标楼层”和“期望方向”一起传给梯控系统让梯控自动分配最合适的电梯。2.2 内呼阶段进轿厢后“选层”内呼英文叫Car Call是机器人进入轿厢后选择目标楼层的动作。听起来简单但实际涉及一个前置条件机器人必须知道自己已经安全进入了轿厢。这里就要说到“位置校验”了。机器人不能靠猜必须靠信号确认。常规做法是组合校验梯控系统返回“电梯到达3楼、门已完全打开”的状态同时机器人底盘上的传感器比如激光雷达、光电传感器、视觉相机检测到前方轿厢地板的特征两者都满足才判断“可以进入”。单靠任何一方都不可靠——梯控说门开了但可能门开了一半机器人进去就会被卡视觉看到地板但电梯其实停在2.9楼的位置轿厢地板和楼层地面有台阶差轮子会卡住。内呼阶段的协议交互相对简单一条“CALL_CAR target_floor10”指令就够了。但这里的难点在于时序把控机器人进入轿厢的瞬间光幕可能会被触发电梯门会尝试重新打开这正好给了机器人一个“进门窗口”但机器人不能磨蹭必须在门保持时间内完成转身、定位、发送内呼指令。我见过不少项目机器人在轿厢里慢慢悠悠调整姿态结果门关了电梯直接走了。所以内呼指令的发送时机很讲究机器人本体完全进入轿厢、并且前方无遮挡后立刻发送内呼指令不要等底盘完全静止。发送内呼的同时要请求梯控系统把门的保持时间延长给机器人留出调整位姿的时间。2.3 高频开门与防夹机制安全的核心屏障“高频开门”这个词听起来像是在说电梯门开关很频繁其实不是。在机器人乘梯场景里高频开门指的是电梯到达后快速执行开门动作并在机器人进出期间持续保持开门状态防止门在机器人通过时关闭。为什么要强调“高频”因为普通电梯的开门逻辑是按“人”设计的。人从电梯厅走进轿厢大约需要1到2秒所以电梯默认开门保持时间通常在3到8秒。但机器人不一样尤其是AGV或大型AMR车体长、速度慢、还需要激光雷达扫描确认路径从停稳到完全进入轿厢可能需要10到20秒。如果沿用默认开门时间机器人走到一半门就开始关光幕触发后门虽然会重开但那种反复“关一半、开一半”的状态对机器人是极大的安全威胁——可能撞到门板也可能被门夹住。协议层面的解决思路是“开门锁定”也叫Door Hold。机器人到达电梯厅并确认电梯已到后可以发送一条开门锁定指令比如设置“保持开门30秒”。梯控系统收到指令后会持续给电梯门发出开门信号直到锁定时间到期或被主动解除。但这里有一个很微妙的点开门锁定时间不能太长。电梯不是你家专梯长时间占用会对楼内其他人造成困扰而且很多楼宇的电梯管理系统有超时检测锁定时间过长会被系统强制复位。我建议把开门锁定时间设成一个动态值根据机器人当前速度、距离电梯口的距离实时计算。比如机器人距离电梯口还有15米、速度为1米每秒那开门锁定时间至少要留出“15秒行走 5秒进入轿厢 3秒余量 23秒”取整可以设到25秒。至于防夹除了依赖电梯自带的红外光幕和力矩检测机器人自己也要做一层保护。最实用的做法是在机器人前后加装安全触边或激光避障一旦碰到门板或光幕区域有障碍物机器人立即急停并后退重新规划进入路径。把“防夹”当成一个双方共同承担的任务而不是只靠电梯一方。3. 梯控协议交互的底层逻辑3.1 多奥梯控协议的命令与状态体系之所以很多项目选多奥梯控协议来做机器人乘梯对接是因为它把复杂的电梯控制逻辑封装成了相对标准的接口。这类协议往上走有TCP、HTTP版本往下走有串口、RS485版本不管底层的电梯是哪个品牌梯控板都会把这些差异吞掉对外暴露统一的命令和状态。我以一个典型的对接实现为例来说明协议交互是怎么组织的。整套协议大概分成三组命令组外呼、内呼、开门锁定、解除锁定、查询状态。状态组电梯当前楼层、运行方向、门状态完全打开/完全关闭/正在打开/正在关闭、故障码、检修模式标志。事件组电梯到达某层、门状态变化、超时未响应、通信断开。协议交互的基本流程就是机器人端发命令 - 梯控板执行 - 机器人端查状态/收事件 - 判断下一步动作。下面是我在模拟项目X里用过的简化版协议交互格式字段做了脱敏但结构和真实对接基本一致# 外呼命令示例 # 请求电梯到5楼上行原因标记为ROBOT CALL_HALL {floor:5, direction:up, caller:robot_001, source:AMR} # 梯控响应 CALL_HALL_ACK {code:0, msg:success, elevator_id:2} # 查询电梯状态 QUERY_STATUS {elevator_id:2} STATUS_RESPONSE {floor:5, direction:stationary, door:opened, mode:normal} # 内呼到3楼 CALL_CAR {elevator_id:2, target_floor:3, caller:robot_001} CALL_CAR_ACK {code:0, msg:success} # 保持开门15秒方便机器人完全进入轿厢 HOLD_DOOR {elevator_id:2, duration:15000, action:start} HOLD_DOOR_ACK {code:0, msg:success}这个交互过程里最能体现“严谨”的点是什么是所有的命令都必须有ACK应答。你不能发了命令就当它成功必须等ACK发了ACK也不代表最终成功只是说明“梯控收下了”真正的结果要看后续的状态推送。所以机器人端写代码时一个简单的“发指令”函数背后要跟一串状态机转换逻辑。3.2 外呼/内呼如何映射到不同梯控版本多奥协议在长期维护过程中不同版本、不同梯控板固件对命令的支持程度是不一样的。有的老版本梯控板支持外呼和内呼但不支持开门锁定这就很麻烦——机器人可能进去了但门很快关了下一次就被关在轿厢里。有的梯控板支持HTTP接口有的只支持串口通信物理链路都不一样。所以对接前有一个能力探测动作。我的习惯做法是先发一条QUERY_CAPABILITY查询能力集命令看梯控板回复的能力列表再根据能力决定采用哪种乘梯策略。支持HOLD_DOOR优先使用“开门锁定”方案流程最安全。不支持HOLD_DOOR启用备用方案机器人到达电梯厅后先发内呼让电梯停在本层趁门开的窗口快速进出同时用机器人自带的光电传感器辅助检测门的状态。这个方案效率低一些但至少能跑。连外呼都不支持只能走“盲呼”方案——机器人到电梯厅后通过IO控制物理按按钮的方式呼梯基本不推荐因为完全没有状态反馈。这里多说一句能力探测本身也可能失败。如果梯控板没有实现这个命令不要反复重试直接降级到“最保守方案”以免把梯控板搞死。我在一个项目里遇到过QUERY_CAPABILITY发多了之后梯控板直接重启的情况从那以后我在所有对接代码里加了一个限制能力探测最多发两次两次无响应就降级。3.3 关键参数的计算与配置协议交互里有几个参数很关键直接决定乘梯体验我逐个说。第一个是命令超时时间。电梯梯控板不是实时操作系统一条命令的响应时间可能从几十毫秒到几秒不等。超时设太短容易误判失败设太长机器人卡在电梯口等半天。经验值是串口链路超时设3秒TCP链路设5秒HTTP链路设8秒。因为HTTP要经过网关转发链路更长。超过这个时间就可以判定命令失败进入重试流程。第二个是状态轮询间隔。乘梯过程中机器人需要知道电梯实时状态。轮询太频繁给梯控板造成压力轮询太稀疏状态更新不及时。常见做法是每秒轮询一次如果电梯正在运行中楼层在变化可以改成500毫秒一次但不要低于这个值。如果梯控板支持事件订阅电梯主动推送状态优先用事件订阅省心很多。第三个是重试次数与退避策略。外呼失败是家常便饭网络抖动、梯控忙都可能导致命令失败。但重试不是越猛越好。我的策略是连续失败3次后退避时间从1秒线性增加到5秒最多重试8次。超过8次直接上报调度系统让机器人“放弃乘梯”步行方案或人工介入避免卡死在电梯厅里。这种“有限重试 最终放弃”的策略在真实楼宇环境里比无限重试可靠得多。第四个是开门锁定的最短与最长时间。最短不要低于10秒因为机器人从检测到门开到开始移动还有一段反应时间最长不要超过60秒因为梯控系统通常有超时保护超过60秒会强制关门。推荐区间是20到40秒具体根据机器人尺寸和速度动态调整。4. AGV、AMR、机器狗在乘梯适配上的差异4.1 AGV货架搬运场景的调度特征AGV自动导引车在制造业仓库里最常见特点是载荷大、路径固定、运行速度慢。这类设备乘梯的场景通常是跨楼层搬运物料比如从1楼仓库往3楼产线送配件。AGV乘梯有几个特殊性。第一车体宽大对轿厢尺寸要求高进入前必须要做一次通过性校验——根据轿厢的实际内宽、内深以及AGV自身的长宽、转弯半径算出能否进入。第二AGV往往是重载惯性大在轿厢里刹车距离明显变长要求机器人进入轿厢后不急着转向而是保持直行一段距离再调整方向。第三AGV的导航方式多为磁条或二维码对位置精度要求高梯控系统的楼层定位精度至少要达到±2厘米。实际对接中的经验是AGV乘梯时要把速度降到额定速度的30%到50%接近电梯口时逐渐减速完全停止后先确认门状态再低速驶入。这一套动作在协议层面并不复杂命令还是一样的但对机器人端的控制逻辑和运动学约束要求很高。我见过一个案例AGV以0.8米每秒的速度直接冲进轿厢结果车轮打滑撞到轿厢壁整个任务失败。速度从来不是AGV乘梯的第一优先级安全才是。4.2 AMR柔性导航场景的响应要求AMR自主移动机器人跟AGV最大的区别是“自主性”。AMR不依赖磁条或二维码用激光SLAM或视觉导航路径实时规划这也让它在乘梯场景里的表现更灵活。AMR乘梯的典型场景是楼宇配送、仓储拣选、医院物流。这类场景的特点是人机混行、环境动态变化电梯口可能有行人、可能有推车、可能门被临时挡住。所以AMR乘梯协议交互的一个重要环节是动态避让和重新规划。举个例子机器人通过外呼叫来电梯电梯门开了但机器人检测到电梯厅里有行人正要进电梯。此时不能硬挤应该让行人优先机器人向后退出电梯厅等待同时向梯控系统发送“保持当前楼层、暂时不要关门”的指令。行人和机器人都在轿厢里也没关系不影响机器人执行任务但需要重新评估轿厢内的可用空间。AMR对协议交互的响应速度要求更高。因为AMR的路径规划是实时更新的乘梯过程里如果电梯状态发生变化比如门关了、电梯走了AMR要能快速调整任务策略。这意味着协议交互的失败处理要做得更细不能简单重试而要结合机器人当前的全局任务来做决策。比如电梯走了AMR是留在原地重新等下一班还是绕路走楼梯需要调度系统综合判断。4.3 机器狗与特殊形态机器人的处理机器狗四足机器人乘梯是我觉得整个场景里最有意思、也最考验细节的部分。四足机器人跟轮式机器人有个本质差异它不是靠轮子滚动而是靠腿迈步步态的对外部环境要求完全不同。首先是地缝问题。电梯轿厢和楼层地面之间有一条缝隙宽度通常在2到5厘米。轮式机器人对这个缝隙基本无感直接把轮子碾过去就行但四足机器人每一步都会踩进缝隙里轻则绊一下重则伤到腿部关节。所以机器狗乘梯的协议交互之外还要有一个“步态切换”动作——进入轿厢前把行走步态切换成小步幅、低抬腿、慢速度的“谨慎步态”保证每一步都稳稳踩在轿厢地板上。其次是姿态稳定。四足机器人站立时四个支撑点都在独立控制电梯启动、停止的瞬间会有加速度变化机器人需要主动调整站姿来保持平衡。协议层面能做的是让梯控系统在电梯启动前给机器人一个“PRE_MOTION”通知事件机器人收到后先降低重心、收紧步态做好抗冲击准备。再有就是空间感知。机器狗的体积比AGV、AMR小很多能进更小的轿厢但它对周围环境的感知要求反而更高。四足机器人的机身姿态复杂视觉传感器的视场角容易被腿部遮挡进入轿厢后需要更密集的传感器数据完成自身定位。协议交互上没有额外命令但在机器人端要把定位频率提高比如从10Hz提高到20Hz同时开启轿厢壁的激光避障。不同类型机器人的参数差异我整理了一个常用参考表机器人类型典型速度m/s进入轿厢耗时推荐开门保持时长特殊关注点AGV0.3~0.58~15秒20~30秒重载惯性、通过性校验AMR0.5~1.25~10秒15~25秒动态避让、人机混行机器狗0.3~0.84~8秒15~20秒步态切换、地缝、姿态稳定这张表不是拍脑袋定的是基于我多个实际项目的联调数据。你们做方案设计的时候可以直接拿去当初始参数再根据现场实测微调。开门保持时长宁多勿少——多几秒只是稍微影响电梯使用效率少几秒就是机器人被夹的事故。5. 实操链路从硬件准备到联调落地5.1 对接前的硬件与网络准备写代码之前先把物理链路搞清楚。机器人跟电梯说话不是靠WiFi直接连的。常规的链路是机器人跑梯控客户端 - 网络/串口 - 梯控网关 - 梯控板 - 电梯控制器。中间每一环都可能出问题所以对接前要做一轮链路连通性检查我一般按这个顺序排查一是确认梯控网关的IP地址、端口号、协议版本号这些信息一般在项目的弱电图纸或梯控供应商的技术文档里。二是用网络工具先测连通性比如直接Ping网关IP这一步能排除网络不通的初级问题。三是在不接入机器人的情况下用调试工具直接连梯控网关发一条查询命令确认梯控板本身是活着的。四是确认通信权限——很多梯控系统会限制访问来源比如只允许特定的IP段或MAC地址访问机器人端的工控机要提前把IP报给梯控供应商加到白名单里。这些听起来像废话但实际项目里80%的联调问题都出在这一层。我接过一个项目机器人端代码写得一点问题没有但就是连不上梯控查了两天发现是办公楼防火墙挡住了TCP端口。所以对接前别急着写代码先把链路打通后面就顺畅很多。5.2 联调过程的分步推进联调不要上来就跑完整流程。我的习惯是分五个阶段推进每个阶段都有明确的验收标准通过才进入下一阶段。阶段一单命令验证。用调试工具逐个测试外呼、内呼、查询状态、开门锁定命令确认每一条命令的响应都是预期的。这个阶段最枯燥也最重要。阶段二状态订阅验证。确认梯控系统的状态推送或者轮询能正常工作机器人能实时收到电梯楼层、门状态的更新。阶段三半自动乘梯。机器人停在电梯厅人工在后台触发乘梯任务机器人执行“外呼 - 等待 - 识别门开 - 进入 - 内呼 - 等待到达”的完整流程。这个阶段不追求速度重点是验证安全逻辑。阶段四全自动乘梯。调度系统自动下发任务机器人自主乘梯连续跑10次以上统计成功率。低于90%就继续调达到95%以上才算是基本可用。阶段五异常场景演练。人为制造一些异常情况——电梯故障、网络断开、门被挡住、有人抢电梯——看机器人系统怎么应对能不能安全退出乘梯流程。我特别想提一下阶段三里面的一个细节机器人识别“门已完全打开”的方式。梯控系统返回DOOR_OPENED状态当然可以但这个状态下门可能只开了80%还有20%在继续打开中。如果机器人检测到开门状态就往前冲可能撞到正在运动的门板。所以更稳妥的判据是“梯控状态 传感器确认”双重条件梯控状态已为DOOR_OPENED且机器人前方传感器连续3帧检测到电梯门中间没有障碍物才下发进入指令。5.3 高频开门与防夹的配置落地高频开门和防夹机制在实操中怎么配置我以模拟项目X里的一套参数为例。开门保持时间采用动态计算hold_time expected_walk_time entering_time safety_margin。机器人距离电梯口10米、速度1米/秒expected_walk_time算10秒进入轿厢需要8秒安全余量5秒总计23秒配置为25秒。发送HOLD_DOOR指令的时机也有讲究。不能在外呼阶段就锁定开门因为电梯还没到锁定指令可能被梯控忽略。正确做法是收到电梯到达事件后先发一次HOLD_DOOR然后机器人开始接近电梯口机器人进入轿厢后再视情况延长一次锁定时长。这样既保证了机器人进入时有充足的开门时间又避免电梯空等太久。防夹机制分两级。一级是电梯本身的光幕和力矩检测这个不用我们管。二级是机器人自身的检测前后安全触边 激光避障。安全触边一旦碰撞就触发急停激光避障在机器人行进方向上检测到前方30厘米内有障碍物就减速、20厘米内就停止。这两级机制配合起来就算梯控系统的门保持逻辑失效机器人也有自保能力。6. 常见问题与排查技巧实录6.1 高频问题速查表机器人乘梯项目在实际运行中问题主要集中在这几个方面。我整理了一张速查表按“现象 - 可能原因 - 解决动作”来排查现象可能原因解决动作外呼指令发送后电梯无响应网络不通、指令格式错误、梯控板忙先Ping网关再用调试工具手动发指令确认电梯响应了但门一直不开电梯处于检修模式/消防模式/高峰期管制查询梯控状态确认mode字段等模式恢复正常门开了但很快关闭机器人进去被夹开门锁定指令未生效或时长不足检查HOLD_DOOR命令是否被ACK动态延长锁定时长内呼指令发送成功但电梯不执行目标楼层设置错误、电梯满员、权限不足确认target_floor数值检查梯控的楼层权限配置机器人位置校验频繁失败楼层传感器精度不足、电梯平层不准增加视觉校验结合轿厢地板特征做二次确认轿厢内无法稳定定位轿厢金属环境干扰激光/磁导航切换定位模式使用视觉定位或增加反光板/二维码标记乘梯过程中通信断开电梯轿厢内信号屏蔽、无线漫游切换改用有线或工业WiFi确保轿厢内覆盖这个表直接打印出来贴在调试台旁边出问题先对着表查能省一半排查时间。6.2 那些文档里不会写的坑第一个坑电梯的状态上报不一定实时。梯控系统上报“电梯到达5楼”时电梯可能刚进入平层区还有几厘米的爬行距离。如果机器人根据这个状态就往前冲很可能撞上还在移动的轿厢地板。解决办法是在状态上报后加一个固定延时比如500毫秒再执行开门确认和进入动作。第二个坑开门锁定时间不是越长越好。电梯系统的超时保护机制五花八门有的电梯在“无人在轿厢内按按钮”的情况下开门锁定超过30秒就会强制关门并取消所有呼叫。遇到过这种情况后我的方案是开门锁定尽量分两段执行第一段用于机器人进门第二段在机器人完全进入轿厢且发送内呼指令后再请求一次短时锁定用于机器人调整姿态。不用一次性锁满60秒。第三个坑重复命令的幂等性问题。梯控板收到重复的外呼指令有的会正常忽略有的会重新执行有的会直接报错。机器人端如果因为超时重发了两次外呼可能导致电梯在楼层间来回跑。解决方式是在指令里加上唯一标识比如指令ID并且记录已发送的指令ID重发时带上同一个ID让梯控板能做去重处理。如果协议不支持指令ID那只能靠状态机控制——明确“已收到ACK才允许发下一条同类型指令”。第四个坑机器人和人对电梯的使用权冲突。同一个电梯厅机器人发了外呼同时一个行人按了同方向的按钮电梯到了之后人先走了进去。此时机器人面临一个尴尬局面电梯门开着但轿厢被人占了。正确做法是机器人检测到轿厢内有人的情况下不强行进入而是发指令撤销本次呼叫退到旁边等待下一班。这里“撤销呼叫”这条指令很多协议文档里写得很少但实际项目里非常常用。6.3 排查思路的底层逻辑排查问题的时候有一个底层思维很重要分清是通信问题、协议问题还是物理解问题。通信问题最典型现象是“指令发出没有任何回应”基本套路就是抓包、Ping、看网络链路。协议问题通常是“指令有回应但行为不对”比如外呼ACK返回成功但电梯没动这种情况要去查指令参数、查梯控板的日志看指令是否被正确解析。物理解问题最隐蔽比如电梯实际到了但传感器没检测到或者门开了但机器人视觉识别不了这时跟协议没关系纯靠传感器和物理环境排查。把这三个层面分清楚排查效率会高很多。别在物理层的问题上反复重发协议指令那是南辕北辙。7. 个人实操中的几点体会做了一整轮机器人乘梯对接之后我个人对“梯控协议对接”这件事的理解更落地了一些。首先是别高估协议也别低估环境。协议能解决“机器人和电梯怎么说话”的问题但解决不了“电梯厅的地面是否平整”“轿厢里是否有反光”“门开了一半是否被卡住”这些物理世界的问题。协议是必要条件不是充分条件。真正稳妥的方案永远是“协议 传感器 控制逻辑”三者配合缺一不可。其次是对接前先摸底比写代码重要一百倍。拿到梯控文档后先花半天时间把协议能力、命令格式、状态定义看清楚跟梯控供应商确认清楚“你们这个版本支持哪些命令”再做技术方案。我发现很多项目翻车不是代码写得烂而是方案阶段就没搞清楚梯控板的能力边界。最后分享一个实用小技巧在机器人端的地图上把每个电梯口标记成“特殊导航点”进入电梯厅前10米就开始减速并切换到“乘梯模式”——关闭普通避障、提高传感器采样频率、开启梯控状态监听。这个小改动能让乘梯的成功率明显提升因为很多失败都是因为机器人在电梯口还在用普通导航的“心态”在跑反应速度跟不上。乘梯这件事本质上就是让一个移动机器人在一个“不属于自己的空间”里安全地借道通行。把协议交互做好把物理校验做扎实把失败处理做周全这个流程就能从“勉强能跑”变成“稳定可靠”。后续你们如果要做多梯协同调度、高峰期梯群优化也是在这个基础上往上搭底子打好了上层就稳了。
