Open-RMF 协调机器人车队与设施资源之间的作业。调度负责选择车队，车队适配器在RMF与供应商系统间转换，交通时刻表共享时间依赖行程，门或升降机适配器将移动意图与建筑设备连接起来。每个边界都有其自身责任。
它不能替代机器人的定位、 SLAM、障碍避让或低级别运动控制。如果地图、帧、航点或时间不一致，连接的适配器仍可能将机器人送往错误位置。成功集成需要状态一致和恢复，而不仅仅是消息交换。
本指南应与 机器人车队分配指南 及 机器人框架指南一起使用。先进行模拟和单一资源测试，再扩展到设施。
在编排层放置Open-RMF
官方 Open-RMF 库 描述了一个多车队机器人管理平台。它协调任务、流量和供应商导航系统之上共享基础设施。在分配故障或承诺RMF修复机器人本地感知缺陷之前，先划定这一层边界。
列出所有主记录系统：任务、机器人状态、地图、门、电梯和用户权限。定义哪个组件可以下令，哪个只负责观察。同一机器人或设施会话不应存在两个可写入状态的主数据源，即使每个API正常工作，仍会导致恢复冲突。
追踪从调度到机器人执行的任务
任务请求进入调度器，候选车队评估，再通过任务授予选择执行方。车队适配器随后将任务转换为供应商专属的计划或命令并报告进度。在每次转换中保持任务身份和状态。
记录请求时间、投标或估算、授予、适配器验收、机器人执行和完成情况。对重复或过期的授予进行幂等性拒绝。只有物理流程完成并取得所需的交付证据后，调度器成功才可判定为最终任务成功。
| 边界 | 输入 | 输出 | 主失效 |
|---|---|---|---|
| 调度员对机器人车队 | 任务与约束 | 任务授予 | 没有可行或陈旧的竞标 |
| RMF到适配器 | 计划与行程 | 供应商请求 | 平移不匹配 |
| 机器人适配器 | 供应商命令 | 机器人状态 | 被拒绝或过时的命令 |
| RMF向门口报告 | 访问请求 | 门会话/状态 | 弄错主人或没有回应 |
| RMF要提升 | 地板与客舱会议 | 提升状态 | 会议或占用冲突 |
把车队适配器当作合同边界
适配器在RMF与供应商车队API之间映射机器人名称、姿态、电池、模式、路径进度和任务命令。为每个字段、单元、状态和错误编写转换规则。不要从心跳推断活动动作，也不要将未知供应商状态转换为空闲状态。
Free Fleet 仓库为支持系统的集成路径提供服务，但生产合同仍依供应商而定。测量适配器更新率、使用时间和重连行为。保留原始供应商错误，同时保留归一化的 RMF 状态。
了解交通时刻表的时间维度
RMF交通协调使用计划中的轨迹和时间，而不仅仅是占用的地图点。延误、路径变更和暂停应更新行程，使其他参与者能够与当前意图进行协商。若机器人在本地偏离且未更新时间表，可能会使冲突预测失效。
在所选的调度容差范围内同步时钟并监控数据年龄。测试延迟更新和重新连接。使用 机器人时间同步指南 将时钟偏移与网络或适配器延迟区分开来。
将门的意图与设施状态连接起来
门适配器将请求的访问会话转换为实际的建筑控制和状态。模型请求器、目标模式、当前模式、超时和释放。机器人不应因发送了打开命令而越过阈值；它需要验证门状态和路由许可。
测试拒绝进入、开门缓慢、阻塞、手动覆盖、控制器重启以及机器人停在门口。定义RMF是等待、改道还是取消。设施安全和门禁控制保持对门的控制权。
| 设施测试 | 注射状态 | 预期配器 | 所需证据 |
|---|---|---|---|
| 门铃延迟 | 晚期开放状态 | 机器人在门槛前等待 | 请求与验证状态 |
| 拒绝入门 | 访问被拒绝 | 重新路由或失败任务 | 理由与权限 |
| 提升工作段损失 | 老板失踪 | 有界清理 | 驾驶舱与机器人入住情况 |
| 走错楼层了 | 州级不匹配 | 没有出口命令 | 地板传感器与会话 |
| 手动覆盖 | 人体变换设备 | 暂停自动化 | 模式与操作员身份 |
把电梯使用当作一个会话和占用性问题来对待
电梯工作流程包括呼叫、获取舱室会话、验证正确的舱室和楼层、进入、选择或请求目的地、乘坐、确认到达、出站和放行。单个按钮命令无法代表这些所有权和占用状态。
测试其他用户进入、门重新打开、地板错位、机器人定位丢失以及小屋内通讯中断。决定谁可以释放陈旧会话。在将小屋分配给另一台机器人之前，先使用物理占用证据。
对齐地图名称、框架和航点语义
RMF地图、供应商地图和设施楼层名称可能使用不同的原点、比例尺、轴和标识符。校准包含多个测量点的变换，并验证航向，而非仅一个平移。数值有效的转换可以镜像或旋转路线。
版本地图变换和航点。测试每个门的进出点，并从两个方向升降。明确拒绝未知地图名称；静默使用默认楼层可能会让机器人移动到错误的物理位置。
跟踪一个工作流程中的组件状态
每个任务都要关联调度器状态、适配器状态、供应商任务、机器人姿态和模式、流量行程、设施请求和资源会话。将时间戳和标识符放在一个跟踪线中。这样最早的分歧就能显现出来。
避免出现单一绿色集成指示器。暴露过时数据、会话所有者和最后成功切换。当机器人在门前停下时，操作员应知道它是在等待交通、访问、门状态、导航还是适配器确认。
在自动追偿前先分配责任归属
将故障分类为机器人本地、供应商车队、适配器、 RMF核心、网络或设施。定义哪些层会重试，哪些层只报告。多层重试同一命令可能导致复制、路线频繁变更或重复门操作。
保留第一次故障和每次恢复尝试。限制重试并要求更改证据。报告持续故障的楼宇控制器应升级到设施运营，而非无休止的机器人重新规划。
一次从仿真集成到一个资源
利用 Open-RMF 演示 理解流程，然后连接模拟车队适配器。先切换到一个实体机器人、一条走廊、一扇门和一个电梯层，然后启用多个并发任务。
在每个阶段，重复正常和失败的工作流程，取消、重启和手动接管。冻结 ROS 2、 Open-RMF 包、适配器和设施API的版本。仅在证据和回滚可复现时扩展。
保持 VDA 5050 和 Open-RMF 在明确的界限上
VDA 5050 规定了中央控制与移动机器人之间的通信接口，而 Open-RMF 则提供了更广泛的多车队和设施协调。它们可以通过适配器相交，但两者名称并不定义映射或责任。
记录哪个组件作为主控，命令和状态如何映射，以及谁拥有交通和设施资源。使用 VDA 5050 指南 独立测试协议行为。
严密安保、人工回收与操作
认证控制接口，分段网络，限制谁可以调度、开放设施或覆盖会话。记录操作员操作。定义为卡在正常状态之间的机器人或升降机的安全手动恢复，包括物理访问和任务对照。
放行时有界限清单。
评估“Open-RMF 车队、门和电梯架构”时，还应保存模型版本、机器人配置、标定文件、测试日期和全部试验记录。把成功、失败、恢复与人工介入放在同一份数据中，才能区分模型能力、系统接口和现场流程造成的差异。
成本评估除了设备与算力，还要记录数据采集、工程调试、安全措施、维护、停机和人员培训。只有把这些持续投入与单位成功任务的价值比较，才能判断方案是否适合扩大。
上线后仍要持续检查分布变化、传感器漂移、机械磨损和人工接管原因。监测结果应能触发降级、停止与重新验证流程，并为下一轮数据采集和模型更新留下可追溯记录。
- 为每个任务、机器人和设施状态分配一个权限。
- 用测量证据验证地图和时间换算。
- 将门和电梯作为自有会话进行测试。
- 绑定在一个负责的层重试。
- 证明重启、手动接管和状态对账。
常见问题
Open-RMF能取代机器人SLAM和导航吗？
不是。它协调车队、交通和资源，而供应商或机器人系统则保留定位和运动控制。
仅凭厂商API来构建车队适配器够用吗？
只有当它暴露了集成合同要求的命令、状态、时序、取消和错误语义时才会被限制。
每个门和电梯都必须用同一个协议吗？
不。资源专用适配器可以转换不同协议，但状态和会话语义必须一致。
项目必须在 Open-RMF 和 VDA 5050之间做选择吗？
不一定。它们占据不同的范围，可以通过定义的适配器和权限模型连接。
应该先测试哪种故障？
在每个边界处从“陈旧”或“失效状态”开始，因为这能快速揭示权限、超时和恢复假设。
编排与设施控制边界
Open-RMF 编排不会覆盖机器人安全、建筑门禁控制、电梯安全或紧急程序。这些系统保留其所需的权限。