Roadmap

本页描述了我们目前正在研究的主题，并预计在未来 12 个月内取得进展。 我们无法承诺具体的开发时间表，但社区对哪些主题最受关注的反馈是可以帮助影响我们工作队列优先级的一个因素。 与任何研发项目一样，我们将对事物在多个维度上的发展做出反应。

Open-RMF 是一个开源项目。 我们将继续公开开发，以便社区成员可以实时看到正在发生的事情。 让我们一起努力吧！ 除了我们自己的努力之外，我们鼓励（并且非常乐意看到！）来自社区的贡献，因此如果您看到您感兴趣的内容，请[通过 GitHub 与我们合作]（https://github.com/open-rmf/rmf/discussions）！

可扩展性

谈到多机器人协调，可扩展性是一个复杂的话题，有许多不同的方面，每个方面对整个故事都至关重要。 可扩展性的担忧可以从变量及其产生的成本的角度来看待。

变量

  • A. 共享空间的移动机器人数量
  • B. 每个移动机器人的能力
  • C. 共享空间的大小
  • D. 狭窄通道和瓶颈的严重程度
  • E. 系统网络拓扑（LAN、有线、Wi-Fi、远程/云）

成本

  • 1. 计算资源（CPU 负载、RAM）
  • 2. 寻找解决方案的时间
  • 3. 解决方案的质量（接近全局最优、帕累托效率 或其他标准）
  • 4. 操作质量（响应性、执行流畅性）

下表列出了为提高可扩展性而做出的持续努力，并指明了哪些变量将得到更好的扩展以及哪些成本将得到改善。请参阅下表了解每项改进的详细说明。

ImprovementABCDE1234
Reservation System✅✅✅✅✅
Queuing System✅✅✅✅✅✅
Hierarchical Planning✅✅✅✅✅
Custom Negotiation✅✅✅✅
Zenoh✅✅✅✅✅

预订系统

最初在 此处 中描述，预订系统将以全局最优的方式将相关资源分配给机器人。该系统最初是为停车位设计的，但也适用于电梯和工作单元。

排队系统

最初在 此处 中描述，当多个机器人需要按顺序使用一种资源（例如穿过一扇门）时，排队系统将管理严格定义的排队程序，而不是依赖交通协商系统来解决狭窄走廊的使用问题。

分层规划

分层交通规划将把整体规划空间分解为由阻塞点分隔的区域。每个阻塞点将由一个队列管理。交通协商系统只会考虑机器人从一个队列转换到另一个队列时发生的交通冲突。减少冲突范围将使协商更快、更少地频繁进行，并且 CPU 占用更低。

自定义协商

并非所有移动机器人或用例都适合“完全控制”、“交通灯”和“只读”这三个现成的类别。让系统集成商完全自定义车队适配器为其机器人规划和协商的方式将使 Open-RMF 能够支持更多类型的机器人并获得更好的结果。

Zenoh

ROS 2 中 Open-RMF 的实现存在各种效率低下的问题，与 DDS 发现机制以及 ROS 2 中缺乏消息密钥支持有关。直接使用 Zenoh 或将其作为 ROS 2 的 RMW 实现，将实现更高效的通信，尤其是通过 Wi-Fi 网络以及大量代理和子系统。

工具

管理和理解大型复杂系统需要能够全面洞察系统运行方式和原因的工具。我们正在努力将 站点编辑器 开发为可视化、事件模拟和数字孪生工具的基线，该工具可以帮助开发人员和最终用户了解 Open-RMF 系统（无论是模拟还是部署）中正在发生的事情及其原因。计划的功能包括：

  • 大规模事件驱动模拟（实时或超实时模拟数百个移动机器人和其他 Open-RMF 系统）
  • 实时部署的数字孪生 3D 视图，可视化正在做出的决策
  • 调试工具以查看计划和协商，可视化解释每个解决方案产生的原因

功能

为了扩大 Open-RMF 的使用范围和使用方式，我们还计划推出新功能：

  • 自由空间交通协商
  • 通过绘制行为图来描述任务
  • 支持具有并行活动线程的多代理任务
  • 允许在任务之间定义约束

开发者体验

为了更广泛地采用和更快地部署，我们希望改善系统集成商的开发者体验。

*​​ 更简单的 API，允许对机器人行为进行更大程度的自定义

  • 更简单的集成选项，例如与 ROS 2 Nav Stack 的“本机”集成
  • 我们将提供一个 ROS 2 nav stack 插件，使使用它的任何机器人都具有 Open-RMF 兼容性
  • 更多文档，包括更新本书
  • 站点编辑器中的交互式教程