AGV/AMR电梯调度采用外呼+内呼组合方案，兼顾效率与灵活性，适合高频次物流场景。
📊 有外呼 vs 无外呼方案对比表
| 维度 | 有外呼方案 | 无外呼方案 |
|---|---|---|
| 成本 | 高（外呼按钮、传感器、布线成本） | 低（仅需内召接口或梯控协议对接） |
| 施工复杂度 | 高（需在各楼层安装外呼设备） | 低（仅需电梯机房或轿厢内改造） |
| 呼梯精准性 | 高（直接指定目标楼层召唤） | 低（需通过电梯运行状态反推可用性） |
| 业务逻辑复杂度 | 低（外呼指令直接对应目标楼层） | 高（需解析电梯方向、当前楼层等状态） |
| 适用场景 | 高频率、多楼层调度（如智能工厂、仓库） | 低频率、固定路线（如办公楼配送、巡检） |
结合项目经验和行业通用的实施标准，多奥为你详细对比这两种模式，并分析各自的优缺点。
可以只有内召（无外呼）或只有外呼（无内召），但需结合场景适配，两种单一模式均有局限性，无外呼更依赖逻辑补偿，只有外呼则需电梯内召权限兜底。
| 维度 | 有外呼招梯模式 | 无外呼招梯模式 |
|---|---|---|
| 招梯逻辑 | AGV 直接发送外呼指令（如 “X 楼上行 / 下行”），电梯响应后精准到层 | 无物理外呼按钮触发，AGV 通过读取电梯状态（当前楼层、运行方向），结合任务目标层，通过内召指令间接 “招梯”（如电梯在 3 楼，AGV 在 1 楼要上行，需判断电梯是否下行到 1 楼，再发内召） |
| 精准度 | 高（直接指定外呼方向 / 楼层，电梯优先响应） | 中（需通过电梯状态反推位置，依赖实时数据交互，易因电梯中途接单偏差） |
| 设备成本 | 高（需加装外呼梯控模块、布线，适配原有外呼面板） | 低（仅需读取电梯内召状态 / 电梯本体数据，无需改造外呼） |
| 施工成本 | 高（需破拆外呼面板、布线调试，影响现场使用） | 低（仅对接电梯控制柜或内召梯控，施工量小） |
| 逻辑复杂度 | 低（直接发外呼→等电梯到→发开门指令） | 高（需实时解析电梯运行方向 / 当前楼层 / 门状态，判断电梯是否可响应、是否到达目标层） |
| 依赖的电梯数据 | 基础状态（当前楼层、门状态）+ 外呼指令反馈 | 全量状态（运行方向、当前楼层、门状态、速度、工作模式等） |
🤔 1. 只有“内呼”（无外呼）的模式
这种模式通常被称为“盲等”或“碰运气”模式。
工作原理：
机器人不具备远程呼叫电梯的能力。它只能移动到电梯厅门口，然后“被动”等待电梯因为其他人的呼叫而随机停靠在当前楼层。
当电梯门打开时，机器人通过传感器（如激光雷达、视觉或红外）判断轿厢内是否为空闲（无人才能进，避免夹人），如果空闲则驶入。
进入后，通过“内呼”点亮目标楼层。
你的描述分析：
你提到的“每隔10-15秒发送一次开门指令”，实际上是在模拟一种“软外呼”逻辑。但在纯内呼物理接线的系统中，这通常是无效的。除非你的“内呼”板卡具备特殊的逻辑处理能力（即通过内呼按钮模拟外呼登记），否则物理上无法触发电梯的外召逻辑。
AGV目标楼层：5楼（当前在1楼） 1. 查询电梯状态：运行方向=2（上行），当前楼层=3楼 2. 判定电梯即将经过1楼，AGV移动至电梯厅等待 3. 电梯到达1楼，前门状态变为1（开门到位） 4. AGV进入轿厢，发送内召指令（通过梯控协议或物理触发） 5. 电梯开始上行，当前楼层更新为5楼，AGV触发开门指令离开
{ "Session": 0, "Command": "CALL_FLOOR", "Floor": 5, "DeviceID": "ID_S1" }
优缺点对比：
✅ 优点：成本极低，施工简单。不需要在电梯厅外呼面板上接线，只需要在轿厢内的操作面板（COP）接线即可。
❌ 缺点：
效率极低：机器人需要长时间在电梯口等待，无法预测电梯何时到达，严重影响物流周转效率。
逻辑复杂：正如你所说，“业务判断复杂”。需要复杂的算法来判断电梯是否是“响应了自己的需求”停下的，还是别人按下的。
安全隐患：如果电梯门打开，里面有人或大件货物，机器人很难判断是否能挤进去，容易造成拥堵或碰撞。
🚀 2. 只有“外呼”（无内呼）的模式
这种模式在特定场景下是最标准的做法。
工作原理：
机器人具备远程呼叫电梯的能力（外呼），但不具备在轿厢内选择目标楼层的能力。
场景限制：这种模式通常用于单向物流，例如：机器人只需要从1楼运货到2楼。
逻辑实现：电梯被呼叫到1楼后，电梯控制系统（梯控）默认该次“外呼”就是为了去2楼（或者通过刷卡/协议预设了该外呼对应的目标楼层）。机器人进入后，电梯直接关门上行，不需要机器人再去按2楼。
{ "Command": "EXTERNAL_CALL", "Direction": 2, // 上行 "TargetFloor": 1 }
优缺点对比：
✅ 优点：呼叫精准，响应快。机器人可以像人一样“按电梯”，大大缩短等待时间。
❌ 缺点：灵活性差。如果机器人需要去不同的楼层（比如一会儿去2楼，一会儿去3楼），只有外呼没有内呼是无法实现的，除非配合电梯的“目的楼层控制系统”（COP）。
| 维度 | 外呼+内召（推荐） | 仅内召（无外呼） |
|---|---|---|
| 响应时间 | <30秒（主动召唤） | 不确定（被动等待） |
| 硬件成本 | 外呼控制器+协议开发（约￥8000/梯） | 无额外硬件 |
| 故障率 | <0.5%（闭环控制） | >5%（状态误判） |
| 安全机制 | 方向+楼层+门状态三重校验 | 仅楼层+门状态校验 |
📊 3. 核心对比总结表
为了让你更直观地看清区别，我整理了下表：
对比维度 只有“内呼” (无外呼) 只有“外呼” (无内呼) 推荐：外呼+内呼 (全功能)
呼叫方式 被动等待 (盲等) 主动呼叫 (精准) 主动呼叫 + 精准选层
施工难度 低 (只接轿厢内) 中 (只接厅外) 高 (需同时接厅外和轿厢)
设备成本 低 中 高
运行效率 极低 (不可控等待) 中 (可控制到达，但不能控制去向) 极高 (全流程可控)
适用场景 极低频次、测试环境、或者电梯本身就停在当前层的情况 单向物流、楼层固定、或者电梯自带目的楼层调度系统 多楼层、多任务、高频率的复杂物流场景
技术实现基础
无外呼方案依赖于对电梯状态的精准监测，主要包括：
| 监测内容 | 字节 | 说明 |
|---|---|---|
| 运行方向 | 1 | 0=未知, 1=停止, 2=上行, 3=下行 |
| 当前楼层 | 2 | 红外U型感应器或RFID模式 |
| 前门状态 | 1 | 1=开门到位, 2=正在开关门, 3=关门到位 |
| 后门状态 | 1 | 1=开门到位, 2=正在开关门, 3=关门到位 |
| 电梯速度 | 2 | 单位：厘米/秒 (150=1.5米/秒) |
# 伪代码：无外呼场景下的乘梯决策逻辑 def can_enter_elevator(status): # 状态包含：运行方向/当前楼层/前门状态/速度 return (status.direction in [1, target_direction] and # 停止或同向 status.current_floor == current_floor and status.front_door == 1 and # 开门到位 status.speed == 0) # 完全静止
💡 4. 针对你描述的“无外呼”逻辑的补充建议
逻辑：
“AGV查询到了楼层以后，就每隔10秒到15秒发送一次开门指令...梯控必须在确保开门（呼梯）按钮被按住的情况下发送门开状态”
这在技术上其实是在尝试用“内呼”信号线去模拟“外呼”功能。这在部分品牌的电梯（如通力、迅达等部分型号）上是可行的，因为它们的内外呼逻辑在主板上是互通的。
如果采用这种“伪外呼”方案：
你需要确保电梯梯控板支持这种“跨逻辑”触发。
风险点：如果机器人在1楼按下了“内呼2楼”，电梯可能会直接关门上行，导致机器人还没来得及进去就被关在门外。
建议：如果你追求低成本且必须实现“主动呼叫”，建议使用继电器模拟外呼按钮的物理接线方式，或者使用支持MQTT/HTTP协议的无线梯控模块，直接通过网络下发指令给电梯主板，这样比单纯拉线按按钮更稳定。
电梯状态解析关键字段
| 字段 | 字节 | 作用 |
|---|---|---|
| 当前楼层 | 2 | 判断电梯是否停靠AGV所在楼层（如红外模式下1～128对应楼层） |
| 运行方向 | 1 | 预测电梯可达性（如AGV需上行时，优先选择方向为2的电梯） |
| 前门/后门状态 | 1 | 确认电梯门是否打开（状态1表示开门到位） |
| 消防信号 | 1 | 紧急情况处理（信号1时需暂停乘梯任务） |
对比总结
| 对比项目 | 只有外呼 | 只有内召 |
|---|---|---|
| 成本 | 设备成本高，施工成本高 | 设备成本低，施工成本低 |
| 呼梯精准度 | 高，能精准控制电梯到达指定楼层并开门 | 相对较低，业务判断复杂，精准控制难度大 |
| 安全性 | 高，梯控确保开门按钮被按住才告知门开状态 | 相对较低，需更复杂逻辑保障安全 |
| 适用场景 | 对乘梯精准度和安全性要求高，且预算充足的场景 | 对成本敏感，且能接受一定精度和安全性妥协的场景 |
结论建议：
如果你的项目对时效性要求高（如工厂产线配送、医院急送），强烈建议配置“外呼”（哪怕是协议对接的软外呼），因为“盲等”模式在实际运营中往往是不可接受的。
