RMF Core Overview
本章介绍了 RMF，它是一系列开放规范和软件工具的总称，旨在简化机器人系统、建筑基础设施和用户界面的集成和互操作性。rmf_core 包括：
- rmf_traffic: Core scheduling and traffic management systems
- rmf_traffic_ros2: rmf_traffic for ros2
- rmf_task: Task planner for rmf
- rmf_battery: rmf battery estimation
- rmf_ros2: ros2 adapters and nodes and python bindings for rmf_core
- rmf_utils: utility for rmf
Traffic deconfliction
避免移动机器人交通冲突是 rmf_core 的一项关键功能。
交通冲突解决有两个层次：(1) 预防，(2)
解决。
Prevention
尽可能地防止交通冲突是最好的情况。
为了促进交通冲突预防，我们实施了一个与平台无关的交通时间表数据库。交通时间表是一个动态数据库，其内容将随时间变化，以反映延误、取消或路线变更。所有集成到 RMF 部署中的车队经理都必须向交通时间表报告其车辆的预期行程。借助时间表上提供的信息，合规的车队经理可以为他们的车辆规划路线，避免与任何其他车辆发生冲突，无论它们属于哪个车队。rmf_traffic 提供了一个 Planner
类，以帮助为表现得像标准 AGV（自动导引车）的车辆提供便利，严格遵循预定网格的路线。未来，我们打算为 AMR（自主移动机器人）提供类似的实用程序，使其能够针对意外障碍物执行临时运动规划。
Negotiation
并非总能完美地防止交通冲突。
移动机器人可能会因为其环境中的意外障碍而遇到延误，或者预测的时间表可能由于多种原因而存在缺陷。
在发生冲突的情况下，rmf_traffic 有一个协商方案。
当交通时间表数据库检测到两个或多个时间表参与者之间即将发生冲突时，它将向相关车队经理发送冲突通知，车队经理之间的协商将开始。每个车队经理将提交其首选行程，并且每个车队经理都将以可以容纳其他行程的行程做出回应。第三方法官（由系统集成商部署）将选择一组被认为更可取的提案，并通知车队经理他们应该遵循哪些行程。
可能会出现需要执行突然的紧急任务（例如，应对紧急情况）的情况，而当前的交通时间表无法及时满足该任务。在这种情况下，交通参与者可能会故意将交通冲突发布到时间表上并强制进行协商。通过实施第三方法官始终偏向高优先级参与者，可以强制协商选择有利于紧急任务的行程安排。
Traffic Schedule
交通时间表是设施内所有预期机器人交通轨迹的集中数据库。请注意，它包含预期轨迹；它正在展望未来。时间表的工作是识别不同机器人车队意图中的冲突，并在发现冲突时通知车队。收到通知后，车队将开始交通协商，如上所述。
Fleet Adapters
参与 RMF 部署的每个机器人车队都应有一个车队适配器，用于将其特定于车队的 API 连接到核心 RMF 交通调度和协商系统的接口。车队适配器还负责处理车队与各种标准化智能基础设施接口之间的通信，例如开门、召唤电梯和唤醒分配器。
不同的机器人车队具有不同的特性和能力，这取决于它们的设计和开发方式。交通调度和协商系统不会对车队的能力做出任何假设。然而，为了最大限度地减少集成工作的重复，我们确定了 4 种不同的控制类别，我们预计现实世界中各种车队经理可能会遇到这些类别。
| Fleet adapter type | Robot/Fleetmanager API feature set | Remarks |
|---|---|---|
Full Control |
| RMF is provided with live status updates and full control over the paths that each individual mobile robot uses when navigating through the environment. This control level provides the highest overall efficiency and compliance with RMF, which allows RMF to minimize stoppages and deal with unexpected scenarios gracefully. (API available) |
Traffic Light |
| RMF is given the status as well as pause/resume control over each mobile robot, which is useful for deconflicting traffic schedules especially when sharing resources like corridors, lifts and doors. *(API available) |
Read Only |
| RMF is not given any control over the mobile robots but is provided with regular status updates. This will allow other mobile robot fleets with higher control levels to avoid conflicts with this fleet. Note that any shared space is allowed to have a maximum of just one "Read Only" fleet in operation. Having none is ideal. (Preliminary API available) |
No Interface | Without any interface to the fleet, other fleets cannot coordinate with it through RMF, and will likely result in deadlocks when sharing the same navigable environment or resource. This level will not function with an RMF-enabled environment. (Not compatible) |
简而言之，舰队与 RMF 的协作性越高，所有舰队和系统就能越和谐地协同运行。 请再次注意，共享空间中只能有一个“只读”舰队，因为任何两个或更多这样的舰队都将几乎不可能避免死锁或资源冲突。
目前，我们提供了可重复使用的 C++ API（以及 Python 绑定），用于集成车队管理的 完全控制 类别。 初步的 ROS 2 消息 API 可用于 只读 类别，但该 API 将在未来版本中弃用，转而使用 C++ API （Python 绑定 可用）。 交通灯 控制类别与核心 RMF 调度系统兼容，但我们尚未为其实现可重复使用的 API。 要实现 交通灯 车队适配器，系统集成商必须直接使用核心交通调度和协商 API，以及实现与各种基础设施 API（例如门、电梯和分配器）的集成。
完全控制 类别的 API 在“集成”章节的 移动机器人舰队 部分中描述，只读 类别的 API 在“集成”章节的 只读舰队 部分中描述。