动态生成用于更新计划和任务分配策略的解决方案

技术领域

本发明一般地涉及由异构自主移动设备和云设备系统进行的计划执 行和任务分配策略的领域，并且更具体地涉及动态地生成用于更新现有 计划和现有任务分配策略的解决方案。

背景技术

物联网(IoT)和机器人技术是在过去几年中呈指数增长的两个领域。 IoT包括协作工作以执行特定任务的设备的网络。类似地，在机器人技 术中，若干机器人协作工作以执行多个不同的任务。

在过去十年中机器人的使用呈指数增长。机器人当前用于所有领域， 包括仓库自动化。今天，对于多机器人协调，存在多个挑战。对多机器 人协调的需要使得系统复杂且难以维护。这些系统也不能够在操作环境 (例如仓库)中进行有效的运行时或动态决策。

发明内容

以下是对在此更详细描述的主题的简要概述。本发明内容概述并非 旨在限制权利要求的范围。在考虑附图和以下对这些附图的详细描述以 及本发明的当前优选和其它实施例时，将更容易理解本发明的这些和其 它特征。

本文描述了与动态地更新云和多个异构自主移动设备(例如，机器 人)中的至少一个或多个上的计划和任务分配策略有关的各种技术。该 系统或平台包括目录存储(包括多个计划和任务分配策略)、在云和多个 异构自主移动设备上运行的计划执行引擎，以及与云中的模块通信的计 划执行引擎执行指令。系统或平台在内部和外部连续地监视各种事件。 平台分析可能需要更新或替换的现有计划和任务分配策略。平台根据各 种因素生成解决方案，并且识别可能需要更新的相关计划和任务分配策 略。基于所生成的解决方案，可以更新或替换现有计划和任务分配策略。 一旦执行了计划和任务分配策略的更新，平台就在云和多个异构自主移 动设备中的至少一个或多个上部署更新的计划和任务分配策略。

根据本发明的实施例，该系统执行现有计划和现有任务分配策略的 分析，包括分析接收到的指示异构自主移动机器人已经获取新能力的通 知，将生成的解决方案对准到新获取的能力，以及基于一个或多个对准 的解决方案识别新计划和新任务分配策略。此外，解决方案的生成包括： 识别自主移动机器人的角色；基于该识别，确定新计划和新任务，该新 计划和新任务对于亲和度因子(affinity factor)的优先级比目录存储的 其它计划高；将新值映射到所确定的计划的新的计划变量，并将所确定 的任务分配给自主移动机器人。

根据本发明的另一实施例，系统验证所识别的新计划与现有计划兼 容，并且所识别的新任务分配策略与一个或多个现有任务分配策略兼容， 以及基于该验证，用新值映射所识别的新计划的计划变量和所识别的新 任务分配策略的任务分配策略变量。此外，该系统生成解决方案，包括： 将与自主移动机器人相关的平台变量、计划变量和任务分配策略变量中 的至少一个或多个的值与阈值进行比较，基于该比较，识别用于更新自 主移动机器人上的部署的计划和部署的任务分配策略的新计划和新任务 分配策略；以及用新值映射所识别的新计划的变量和所识别的新任务分 配策略的变量。此外，解决方案的生成包括：将与自主移动机器人中的 一个或多个相关的平台变量、计划变量和任务分配策略变量中的至少一 个或多个的一个或多个值与阈值进行比较；基于该比较，识别用于更新 一个或多个自主移动机器人上的部署的计划和部署的任务分配策略的新 计划和新任务分配策略；以及用新值映射所识别的新计划的变量和所识 别的新任务分配策略的变量。

根据本发明的另一实施例，该系统还包括：将新自主移动机器人的 新能力扩展到一个或多个异构自主移动机器人，其中新自主移动机器人 具有不同的机器人类型；识别与新能力兼容的一个或多个新计划和一个 或多个新任务分配策略；以及在一个或多个异构自主移动机器人上部署 所识别的计划和所识别的任务分配策略。

根据本发明的另一实施例，该系统还包括：在计划目录中搜索新计 划并且在任务分配目录中搜索新任务分配策略，更新部署的计划和任务 分配策略；使用代理目录缩小计划目录和任务分配目录的搜索；基于该 缩小，识别新计划和新任务分配策略；确定是否要在计划级和任务分配 策略级中的至少一个或多个上进行映射；以及基于该确定，用新值映射 所识别的计划和所识别的任务分配策略的静态和瞬态变量中的至少一个 或多个。该系统还包括：分析不同类型的新的自主移动机器人已经加入 多个异构自主移动机器人的机群(fleet)的通知；基于对通知的分析来 生成一个或多个附加解决方案；基于所生成的附加解决方案，识别新计 划和新任务分配策略；对新计划的计划变量映射新值，并且对不同类型 的新自主移动机器人映射新任务分配策略；在不同类型的自主移动机器 人上部署新计划和任务分配策略。

根据本发明的另一实施例，该系统还包括：确定与自主移动机器人 中的至少一个或多个相关的亲和度因子；基于所确定的亲和度因子来识 别新计划和新任务分配策略；利用所识别的计划和所识别的任务分配策 略更新部署的计划和部署的任务分配策略；以及在自主移动机器人中的 一个或多个上部署更新的计划和更新的任务分配策略。该系统还包括： 分析来自云、自主移动机器人和自主移动机器人上运行的计划执行引擎 中的至少一个或多个的通知；基于对通知的分析，验证在自主移动机器 人上执行的现有计划和现有任务分配策略支持新行为；基于该验证来识 别用于支持新行为的新计划和任务分配策略；以及对自主移动机器人将 新值映射到所识别的计划的新计划变量并且将新值映射到所识别的任务 分配策略的新任务分配策略变量。

根据本发明的另一实施例，该系统还包括：分析部署在云和多个异 构自主移动设备中的一个或多个上的计划和任务分配策略中的至少一个 或多个的变量的值的变化；基于对变化的分析，将至少一个或多个计划 和任务分配策略部署到异构自主移动设备中的一个或多个上；以及在一 个或多个异构自主移动设备上发起新操作。该系统还包括：基于历史数 据在计划目录中搜索计划并且在任务目录中搜索任务分配策略；分析与 计划目录中的一个或多个搜索到的计划和任务目录中的搜索到的任务分 配策略相关的历史数据；以及基于对历史数据的分析，从计划目录中的 一个或多个搜索到的计划中选择新计划，并且从任务目录中的一个或多 个搜索到的任务分配策略中选择新任务分配策略。

根据本发明的另一实施例，该系统还包括：接收要被跟踪的一个或 多个变量，其中一个或多个变量与一个或多个自主移动设备相关；识别 一个或多个新计划和一个或多个新任务分配策略，该识别至少基于(a) 将所接收的变量与阈值进行比较中以及(b)新计划和新任务分配策略与 部署的计划和部署的任务分配策略的兼容性的一个或多个；以及至少基 于兼容性不匹配和比较所接收的变量低于阈值中的一个或多个来发送警 告通知。此外，该系统包括：接收要由多个异构自主移动设备执行的一 个或多个任务；将与一个或多个部署的计划和一个或多个部署的任务分 配策略相关的变量与阈值进行比较；基于该变量的比较，向多个异构自 主移动设备分配任务或拒绝任务；以及如果任务被分配，则更新与一个 或多个现有计划和一个或多个现有任务分配策略相关的变量。

根据本发明的另一实施例，该系统还包括：分析一个或多个自主移 动设备的能力的变化；基于分析该变化，在代理目录中搜索一个或多个 软件代码；从代理目录中识别与一个或多个自主移动设备的能力兼容的 软件代码；以及用所识别的软件代码更新一个或多个自主移动设备的现 有软件代码。该系统还包括：将计划和任务分配策略中的更新通知给多 个异构自主移动设备；响应于通知该更新，使获取新能力的自主移动设 备优先于其它异构自主移动设备；以及基于该优先，向获取新能力的自 主移动设备分配新任务。该系统还包括：检查新计划和任务分配策略与 部署的计划和部署的任务分配策略的兼容性；以及基于该兼容性检查， 中止对多个异构自主移动设备上的部署的计划和部署的任务分配策略的 更新。

根据本发明的另一实施例，该系统还包括：流行度模块，用于基于 用户的导入的专有计划的流行度、团体的使用、评论、软件代码的用户 友好度、计划、任务分配策略、多核特征以及评论分数中的至少一个或 多个，使得用户能够变得流行或接收增加的许可费用。该系统还包括： 分析与现有计划和现有任务分配策略中的至少一个或多个相关的变量；将分析的变量的值与阈值进行比较；以及基于值的比较，在目录存储中 搜索至少一个或多个计划和一个或多个任务分配策略；以及基于包括历 史数据、机器人的角色、机器人的类型和机器人的能力的至少一个或多 个因素，从搜索到的计划和搜索到的任务分配策略中识别新计划和任务 分配策略。

本文描述的技术涉及一种稳健的平台或系统，其允许在运行时或在 操作环境中活动或空闲时进行动态决策，以确保工作场所的最优性能。 在示例性实施例中，平台可以依赖于历史数据、机器人相关特征、环境 相关特征、上下文特定特征、定制特征、与系统/平台、任务分配策略和 计划等中的至少一个或多个相关的变量中的至少一个或多个，以生成用 于识别适当的新计划和任务分配策略的解决方案，用于更新现有计划和 现有任务分配策略。

应当理解，上述主题也可被实现为计算机控制的装置、计算机处理、 计算系统、或诸如计算机可读介质等制品。通过阅读以下详细描述并查 看相关联的附图，这些和各种其它特征将是显而易见的。

以上概述呈现了简化的发明内容，以便提供对本文所讨论的系统和/ 或方法的一些方面的基本理解。该概述不是对本文所讨论的系统和/或方 法的广泛综述。其并非旨在限制权利要求的范围，或者并非旨在识别关 键/重要元素，或者描绘这样的系统和/或方法的范围。其唯一目的是以简 化形式呈现一些概念，作为稍后呈现的更详细描述的序言。

附图说明

参照以下描述、所附权利要求书和附图，将更好地理解动态生成用 于更新计划和任务分配策略实现的解决方案的具体特征、方面和优点， 其中：

图1是示出根据实施例的用于动态生成用于更新计划和任务分配策 略的解决方案的系统100的框图。

图2是示出用于动态管理异构机器人机群的计划和任务分配策略的 更新的系统200的框图。

图3是示出根据实施例的部署更新的计划和任务分配策略以供执行 的处理的示例性和非限制性流程图。

图4是示出根据实施例的用于更新自主移动设备的计划和任务分配 策略的处理步骤的示例性流程图。

图5是示出根据实施例的用于更新计划的处理步骤的示例性流程图。

图6是示出根据实施例的用于更新计划和任务分配策略的处理步骤 的示例性流程图。

尽管本发明的具体特征在一些附图中示出而在其它附图中未示出， 但是这样做仅仅是为了方便，因为根据本发明，每个特征可以与任何或 所有其它特征组合。附图中的块的顺序不是限制性的，并且可以根据本 发明以任何顺序互换。图中的开始和结束块不应被解释为限制性的，因 为它们可以指示许多表示中的一个表示作为软件代码开发的一部分。以 上附图呈现了对本文所讨论的系统和/或方法的一些方面的基本理解。附 图不是对本文所讨论的系统和/或方法的广泛概述。它并非旨在标识关键 /重要元素或描绘这些系统和/或方法的范围。其唯一目的是以简化形式呈 现一些概念，作为稍后呈现的更详细描述的序言。

具体实施方式

本文描述了用于提供平台的技术的实施例，该平台用于在操作环境 中动态地生成解决方案或在运行时生成解决方案以更新或切换诸如机器 人的异构设备上的计划和任务分配策略。在整个说明书中，对“一个实 施例”、“该实施例”和类似短语的引用意味着结合该实施例描述的特定 特征、结构或特性被包括在至少一个或多个实施例中。因此，在本说明 书中的各个地方出现的这些短语不一定都指相同的实施例。此外，特定 特征、结构或特性可以以任何合适的方式组合在一个或多个实施例中。

可以利用一个或多个计算机可读介质的任何组合。计算机可读介质 可以是计算机可读信号介质或计算机可读存储介质。计算机可读存储介 质可以是，例如但不限于，电、磁、光、电磁或半导体系统、装置或设 备，或前述的任何合适的组合。计算机可读存储介质的更具体的示例(非 穷举列表)将包括以下：便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或 闪存)、具有中继器的适当光纤、便携式光盘只读存储器(CD-ROM)、 光存储设备、磁存储设备、或前述的任何合适的组合。在本文的上下文 中，计算机可读存储介质可以是任何有形介质，其可以包含或存储由指 令执行系统、装置或设备使用或与指令执行系统、装置或设备结合使用 的程序。

计算机可读信号介质可以包括例如在基带中或者作为载波的一部分 传播的数据信号，其中传播的数据信号具有在其中体现的计算机可读程 序代码。这种传播信号可以采取多种形式中的任何一种，包括但不限于 电磁、光或其任何合适的组合。计算机可读信号介质可以是任何计算机 可读介质，其不是能够传送、传播或传输由指令执行系统、装置或设备 使用或与指令执行系统、装置或设备结合使用的程序的计算机可读存储 介质。可以使用任何适当的介质来传输在计算机可读信号介质上包含的 程序代码，所述介质包括但不限于无线、有线、光纤电缆、RF或前述的 任何适当组合。

用于执行本公开的各方面的操作的计算机程序代码可以以一种或多 种编程语言的任何组合来编写。程序代码可以完全在用户的计算机上执 行，部分在用户的计算机上执行，作为独立的软件包执行，部分在用户 的计算机上并且部分在远程计算机上执行，或者完全在远程计算机或服 务器上执行。在后一种情况下，远程计算机可以通过任何类型的网络连 接到用户的计算机，包括局域网(LAN)或广域网(WAN)，或者可以 连接到外部计算机(例如，使用因特网服务提供商通过因特网)或在云 计算环境中进行连接，或者作为诸如软件即服务(SaaS)、平台即服务 (PaaS)或基础设施即服务(IaaS)或机器人即服务(RaaS)或仓库即 服务(WaaS)或协作机器人(Cobots)等服务来提供连接，作为服务或 其它服务模型。

本文参考根据本公开的实施例的方法、装置(系统)和计算机程序 产品的流程图图示和/或框图来描述本公开的方面。将理解，流程图和/ 或框图的每个框以及流程图和/或框图中的框的组合可以由计算机程序 指令实现。这些计算机程序指令可以被提供给通用计算机、专用计算机 或其它可编程数据处理装置的处理器以产生机器，使得经由计算机或其 它可编程指令执行装置的处理器执行的指令创建用于实现流程图和/或 框图的一个或多个框中指定的功能/动作的机制。

这些计算机程序指令还可以存储在计算机可读介质中，当被执行时， 这些计算机程序指令可以引导计算机、其它可编程数据处理装置或其它 设备以特定方式工作，使得当存储在计算机可读介质中时，这些指令产 生包括指令的制品，当被执行时，这些指令使计算机实现流程图和/或框 图的一个或多个框中指定的功能/动作。计算机程序指令还可以被加载到 计算机、其它可编程指令执行装置或其它设备上，以使得在计算机、其 它可编程装置或其它设备上执行一系列操作步骤，以产生计算机实现的 过程，使得在计算机或其它可编程装置上执行的指令提供用于实现流程 图和/或框图的一个或多个框中指定的功能/动作的过程。

如本领域技术人员将理解的，本公开的各方面可以在许多可授予专 利的类别或背景中的任何类别或背景中示出和描述，包括任何新的和有 用的过程、机器、制造或物质组成，或其任何新的和有用的改进。因此， 本公开的方面可以被实现为完全硬件、完全软件(包括固件、驻留软件、 微代码或其它合适类型的软件)或组合软件和硬件实现，其可以全部在 本文中被一般地称为“电路”、“模块”、“组件”或“系统”或“平台” 或“装置”。此外，本公开的方面可以采取在一个或多个计算机可读介质 (例如，有形的、非暂时性计算机可读介质)中体现的计算机程序产品 的形式，所述计算机可读介质具有在其上体现的计算机可读程序代码。 本公开涉及诸如“用户”、“开发者”、“设计者”、“第三方”、“仓库所有 者”、“机器人解决方案提供者”等的术语，并且在若干或特定实施例中 使用，然而，这些术语不限于那些特定实施例，并且可以由其它术语替 换，因为本发明不受这些术语限制或局限。

设备是具有唯一标识符和通过因特网传输数据的能力的对象或物理 实体。在一个实施例中，该设备是物联网(IoT)中的“事物”。在IoT 上下文中，事物是指具有唯一标识符、嵌入式系统以及通过网络传输数 据的能力的实体或物理对象。这些设备可以包括物理设备、家用电器、 车辆、边缘设备、雾设备等。该设备还包括能够执行致动和感测以及其 它设备功能的机器人。在一种

术语“计划”可以以多种方式定义，并且不应将其解释为限制性的。 描述计划的最简单方式是一个接一个执行的行为列表。它是用于制定更 复杂的配方或子计划的结构。存在这样的配方或策略的各种表示，其扩 展了该简单描述。计划的基本概念与有限自动机密切相关，有限自动机 不仅允许动作序列的公式化，而且允许循环和条件执行的公式化。因此， 计划P的集合中的计划P是状态和它们之间的转变的结构。在一个实施 例中，计划“充电”可以包含两个任务：一个用于一组机器人排队充电， 一个用于另一组机器人对接并充电。在一个实施例中，计划还可以包括 “机器人行为”。机器人行为是在某些条件下由机器人执行的计划内的低 级原子活动。在本发明的另一实施例中，“充电”计划包括三个状态：机 器人等待状态、机器人对接状态和机器人充电状态。在一个实施例中， 计划是表示在计划执行期间的阶段的状态的集合。

计划树可以包括诸如充电计划、导航计划、自主模式计划、拾取和 放置对象计划、提升计划等的计划。机器人按照计划的状态移动。有时， 机器人可能处于“充电”状态，并且稍后，它们可能被拉出“充电”状 态并转换到携带和拾取托盘的“自主模式”状态。因此，对于这两个计 划即“充电”计划和“自主拾取和携带”计划，可以使用被称为“导航” 计划的子计划。子计划是实现一个或多个目标的计划的一部分或计划要 实现的目标的一部分。

计划中的每对状态可以通过转变来链接。转换是为了使机器人从其 当前状态移动到下一状态而需要满足的条件。在每个状态中，一个或多 个AMR执行计划内的一组子计划。在子计划成功执行之后、当任务失 败时、或者当子计划的执行变得不相关时，一个或多个AMR可以转换 到下一状态。转换条件可以被定义为布尔表达式，其包括不同的计划变 量和为了转换到下一个计划状态而需要满足的计划变量值。

计划执行引擎包括用于执行计划、由一个或多个异构设备和/或云分 配任务的逻辑。计划可以包括组合形成计划的若干子计划。机器人行为 是在某些条件下由机器人执行的计划内的低级原子活动。例如，“机器人 充电”计划可以包括三个状态：机器人等待状态、机器人对接状态和机 器人充电状态。

考虑用户已经开发了用于执行自动导引车辆(AGV)组和用于执行 叉车组的计划和任务分配策略。该计划包括像路线计划、导航、本地障 碍物回避、LiDAR扫描仪的功能，这些功能对于叉车团队而言可能是常 见的，并且可能存在对于叉车而言可能不同的一些功能。在设计时，允 许用户或第三方开发者在用户界面上拖放计划。在仓库环境中，平台处理异构设备之间的协调，例如，一组自动引导车辆(AGV)和一组叉车。 另外，如果计划和任务分配策略必须被拾取辅助机器人而不是AGV代 替，则协调和实现通常不同的变化的功能的整个过程由平台处理。因此， 本公开包括通用平台，该通用平台使得用于AGV和叉车的团队的一个或 多个计划和一个或多个任务分配策略能够被替换为用于其它设备团队的 一个或多个计划和任务分配策略，所述其它设备团队例如为拾取辅助机 器人。

考虑例如4英尺机器人或具有1米半径的机器人的导航情形。为此， 开发者必须编写嵌入式代码、构建中间件、导航栈、激光扫描器、定位、 障碍物避免算法等。这需要开发者或开发者团队多年努力来构建处理这 些复杂性的应用。本公开涉及一种通用平台，其允许用户在不花费大量 努力的情况下针对不同机器人并且在不同场景中使用容易获得的计划和 任务分配策略，并且另外允许机器人在它们之间协调以处理动态情况， 如机器人的电池水平在工作环境中导航时下降到临界阈值以下等。该平 台允许用户设计和部署各个机器人以及多机器人通用场景。协调原语是 通用的，使得平台无缝地处理诸如铲叉提升、碰撞避免、拣选等的不同 任务。

本发明解决了云和/或多个异构自主机器人更新计划和任务分配策 略的领域中的技术问题。本发明解决了在多个自主机器人导航时的决策 问题，并且基于至少一个或多个因素提供了备选的相关计划和任务分配 策略以用于执行，所述因素例如是定制计划、平台、任务分配策略变量， 例如导航时间、拾取时间、每个任务的最多机器人、机群中的最多机器 人等、机器人类型、能力、角色、行为等。此外，所生成的用于解决运 行时问题的解决方案允许该组自主机器人基于给予该组机器人的任务继 续常规的功能。该平台的目的之一是显著地减少用户构建系统的工作， 使得需要他们在计划级或任务分配策略级提供最少的信息。平台足够智 能以识别任务(例如，车轮应旋转多少、应何时应用制动器等)，并且可 以在AMR上执行任务，以及按照本文讨论的预定义或动态解决方案部 署备选计划和任务分配策略。

应当理解，本发明涉及可互换的各种术语，并且可以在一个或多个 实施例中互换地使用。例如，在一个实施例中，术语“现有计划”可以 由一个或多个实施例中的“部署的计划”互换，而不用根据其在操作环 境中的使用情况之一来改变本发明的范围或实现。这种互换不应被认为 是限制性的，并且这种互换被认为在本发明的范围内。

在一个实施例中，云设备管理系统或云设备系统可以是包括允许在 云或设备处构建、供应和部署应用的若干软件和硬件组件的平台即服务 (PaaS)框架。

图1是示出根据实施例的用于动态生成用于更新计划和任务分配策 略的解决方案的系统100的框图。应当理解，术语“动态地”可以包括 运行时或部署后操作，或者当自主移动设备处于不同状态时，例如操作 环境中的活动或空闲。术语“动态”或“运行时”不应被解释为约束性 的或限制性的，并且可以被解释为在本发明的范围内。在一个实施例中， 目录存储101可以包括多个目录，如计划目录111、任务分配目录112、 代理目录113等。任务分配目录112可由平台使用以检索不同的任务分 配策略，例如，基于最短距离来分配订单，或基于减少处理订单所需的 总时间来分配订单。计划目录111包括多个单独计划和子计划。在一个 实施例中，在计划和任务目录之间可以存在依赖性或关系。这些目录由 部署和运行时(DR)模块102使用，以生成帮助更新一个或多个计划和 /或任务分配策略的解决方案。这种更新导致在群组中的异构AMR之间 实现新的行为。DR模块102可以参考用于机器人特定代码或固件/嵌入 代码的代理目录113，如果替代计划和任务分配策略必须与在一个或多个 异构AMR上执行的现有计划和任务分配策略交换，则可以检索所述机 器人特定代码或固件/嵌入代码。在一个实施例中，代理目录113和DR 模块102之间的这种通信可以用于缩小用于识别相关计划和任务分配策 略的搜索范围。代理目录113可包括不同类型的机器人的软件代码，例 如3轮驱动机器人、单轮叉车或AGV、不同类型的机器人的定义、本地 导航计划和诸如LiDar扫描仪是否可用于特定类型的机器人等的信息。 三个目录-计划目录111、任务分配目录112和代理目录113是暴露DR 模块102使用的变量、存储和维护元数据的实体。元数据向DR模块102 给出关于各种变量(计划变量、任务分配策略变量)的细节，并且还指 导变量的映射，例如对于叉车、叉车的尺寸、哪个车轮是动力车轮等。 这些目录被定义并作为平台上的标准包可用。

在一个实施例中，可以在云和异构AMR上执行计划和任务分配策 略期间生成数据。例如，所生成的数据可以包括由设备收集的传感器数 据、任何设备行为的执行结果、与新设备的通信等。在一个实施例中， 在计划和任务分配策略的执行期间生成的数据被存储在传感器和执行数 据存储106中。传感器和执行数据存储还可以被存储在云设备管理系统中，如稍后在图2中所公开的。在AMR 104b、104c…104n上运行的执 行计划和任务分配策略的一个或多个计划执行引擎103b、103c…103n， 用机器人捕获的任何传感器数据或由运行在机器人或云上的计划执行引 擎执行计划和/或任务分配策略的动作的执行结果来更新传感器和执行 数据存储106。DR模块102是计划执行引擎103a…103n和目录存储101 以及传感器执行数据存储106之间的接口。在一个实施例中，传感器和 执行数据存储106还基于与执行一个或多个计划和任务分配策略的一个 或多个计划执行引擎103a…103n的双向通信从DR模块102接收约束解 决方案。约束解决方案是由DR模块102与计划执行引擎103a和其它计 划执行引擎103b…103n协作并且取决于机器人的当前状态或当前执行 的任务确定的解决方案。在一个实施例中，不同的计划执行引擎可以公 布或广播由其它自主移动机器人的计划执行引擎订阅的其对应的自主移 动机器人的状态。可以使用由机器人操作系统、数据分发服务提供的通 信机制或使用简单的UDP代理等来建立通信。计划执行引擎可以在特定 的通信频率范围内，例如15Hz到30Hz内彼此通信。

在一个实施例中，图1中公开的平台100可以类似于申请人的平台 “Rapyuta.io”平台，并且机器人104b可以类似于由申请人Rapyuta Robotics公司开发的其中一个机器人，即名为“Sootball”的拾取辅助 AMR。其它机器人104c…104n可以是由申请人或其它设备制造商开发 的任何其它类型的机器人。在一个实施例中，自主移动机器人包括用于 执行指令的处理器和用于存储的存储器。在另一实施例中，DR模块102 可以主动地提供基于上下文的解决方案，其预期在一组异构AMR可以 在操作环境(如仓库)中导航时的潜在挑战或机会。这里讨论的在工作 空间或操作环境中的AMR面临的各种场景由平台处理以生成用于做出 最优决定的解决方案。模块102提供的一些解决方案可以涉及诸如管理 仓库中AMR的充电的场景—在AMR集合中识别首先充电的AMR，或 者如果存在多个时隙，则优选可以针对特定时隙或在路线规划决策中获 得更高优先级的特定类型的AMR，或者识别优先得到软件或软件更新的 堆栈的机器人，或者基于其它机器人相关的计划或任务分配策略变量，例如原地旋转、转弯半径、导航时间、充电时间等的能力。DR模块102 可以处理所有基元，生成计划，即例如充电、导航、多机器人协调任务 或其它任务，如机器人等待队列、狭窄的通道转弯、复杂任务如死锁避 免、障碍物避免等，并且提供通用接口以处理这样的复杂和变化的任务。 当计划和任务分配策略要被部署时，所有任务可以被集成到包中并且被 部署到异构设备上。

在一个实施例中，平台可以管理多个异构设备上的计划和任务分配 策略的动态或运行时更新，所述异构设备例如异构自主移动机器人 (AMR)，如叉车、AGV、抓具、拣选辅助AMR、无人机(104b、104c… 104n)等。为了简单起见，我们讨论使用AMR的进一步场景，然而， 应当理解，可以使用任何其它种类的自动车辆(例如，自驾汽车等)或 移动机器人或自动硬件设备或IoT或无人机。该系统包括多个异构AMR 104b-104n、云104a、包括一个或多个计划和一个或多个用于部署的任务 分配策略的目录存储101。云维持与多个自主移动机器人104b-104n的双 向通信，并且AMR也通过各种消息传送协议彼此通信。该系统还包括 多个计划执行引擎103a…103n，其在多个AMR和云上执行。这些一个 或多个计划执行引擎协作地执行在多个AMR 104b…104n处部署的一个 或多个计划和任务分配策略。基于从DR模块102接收的指令。DR模块 102可以充当平台管理器，其协调执行引擎、云、设备、目录存储和数据 存储之间的双向通信。计划执行引擎103a…103n通过各种消息协议互相 通信。双向通信信道105a、105b、107a…107n、108a…108n之间，以及 计划执行引擎103a、103b、103c…103n之间(为了简化未示出)可被认 为是确保平台的组件或模块之间的快速和有效通信的一个或多个消息协 议。这些消息协议对于本领域普通技术人员是公知的。

在一个实施例中，考虑存在3个AMR(104b、104c、104d(未示 出))并且其中一个需要首先充电的情形。因此，它都取决于如何配置计 划“充电”。DR模块102分析配置以确保在AMR 104b、104c和104d 上运行的计划执行引擎103b、103c和103d(未示出)是否可以分别在它们自身之间进行决定，并且如果这是可能的，则计划执行引擎自己做 出决定(例如发送AMR的位置信息)，然而，在一些场景中，模块102 可以决定由于处理需要繁重的计算负荷(例如在导航时的仓库地图创建 或路由图分析和生成)并且因此导致执行引擎的繁重成本，在这样的场 景中，由DR模块102与在云104a上运行的计划执行引擎103a协作或 者在DR模块102与在云104a和AMR 104b、104c和104d上运行的执 行引擎103a、103b、103c、103d中的一个或多个之间协作地做出决定。 DR模块102确保在计划执行引擎之间的功能的无缝转换以获得最佳性 能。

在一个实施例中，代理目录113是异构机器人104b、104c…104n的 元储存库，其由平台100(例如叉车、AGV、PA-AMR、臂、无人机等) 支撑。元储存库信息包括设备的特定细节，例如设备制造商、供应商、型 号信息、尺寸(大小、能力、可被挑选的有效载荷)、硬件信息、软件信 息、相关联的固件、代码段等。为了解释目录存储101及其组件的角色- 计划目录111、任务分配目录112和代理目录113，让我们考虑AMR在 仓库中导航的示例。在运行时，DR模块102监视云设备系统和异构机器 人机群上的事件。在监视事件时，DR模块102得到通知，即，正被跟踪 用于机器人104b或用于系统的平台或计划或任务分配策略变量已经突破阈值(例如，电池水平低于总电池的10％)，并且性能值(拾取辅助 AMR的拾取(80次拾取)的次数小于100次拾取/小时的预定标准)不 在阈值范围值内。因此，在被通知之后，DR 102模块然后必须从计划目 录111中的导航计划的集合中识别(一个或多个)替代导航计划和任务 分配策略。考虑机器人104b是申请人的机器人“Sootball”，它是拾取 辅助AMR。因此，由计划执行引擎103b执行的导航计划需要被来自计 划目录111的替代导航计划替换，并且来自任务分配目录112的单独的 任务分配策略集合可能需要被切换。现在，考虑对于不同机器人型叉车 的机器人104b存在替代导航计划。在一个实施例中，由于机器人的备选 计划与PA-AMR所需的不同机器人类型，所以现有计划可能或者可能由 于不同的硬件配置而不被新计划替换，例如，不同的驱动器在它们移动 的路线周围具有不同的方向约束等。因此，DR模块102必须从可用选项 分析与PA-AMR 104b兼容的匹配导航计划。当计划目录111最初被填充 导航计划时，则计划的所有者可以描述导航计划应用于的机器人的宽泛 类别，或者选择与导航计划兼容的机器人的类别。例如，导航计划可以被 描述为应用于差速驱动机器人或所有三循环控制器类型或类似于不能原 地旋转的汽车的导航计划。这可以在图1中进一步详细讨论。

在图1中，DR模块102首先在计划目录111、任务分配目录112中 搜索，并且检查计划目录111中的导航计划和来自任务分配目录112的 任务分配策略与机器人104b的兼容性。为了简单起见，让我们集中在从 计划目录111更新导航计划。通常，在计划目录111中可以存在至少100 个导航计划，因此，DR模块102可以在计划目录中搜索导航计划的列 表，并且识别与给定机器人104b兼容的替代计划。兼容性检查可以基于 API兼容性、机器人型兼容性、硬件或软件兼容性等。然后，为了缩小计 划目录和任务分配目录的搜索范围，DR模块102检查代理目录113以寻 找可以对特定机器人104b进行分类的宽泛类别或类别子集。代理目录 113的这种检查可以被认为是DR模块102缩小搜索范围并识别相关导 航计划和/或任务分配策略的附加过滤器。现在，当DR模块102从计划 目录111中提取新的导航计划并且该计划必须被部署在机器人104b上 时，必须通过利用新计划的计划变量映射或更新机器人104b的现有导航 计划的计划变量，例如机器人的尺寸、最小或最大速度等，来增加部署。DR模块102确保来自现有导航计划的计划变量(例如，叉车的尺寸、最 小和最大速度)的数据可以从目录存储101检索，该数据被映射到必须 被部署的新导航计划的计划变量。因此，从目录存储101中可用的目录 中检索的计划变量的映射每次都发生，而不管计划或任务分配策略是第 一次被部署还是在运行时稍后被重新部署。

在一个实施例中，DR模块102连续地监视事件，所述事件可以包括 监视或分析平台变量、任务分配策略变量和/或计划变量，并且在接收到 通知或触发时，分析通知以检查平台、任务分配策略和/或计划变量是否 已经违反它们的阈值，并且因此，它们可以保证更新一个或多个计划和/ 或通知是否与更新部署到云和异构机器人103b…103n中的至少一个或 多个的仅一个或多个任务分配策略有关。平台、任务分配策略和/或计划 变量帮助DR模块102做出关于是否必须在计划层和/或任务分配策略层 做出更新或映射的决定。这也可以从图1的模式表示中理解。

在一个实施例中，考虑在计划级进行的更新，让我们考虑计划可以 具有N个变量(静态或瞬态类型)的场景，例如，静态变量可以是机器 人103b的最小或最大速度或机器人103b的尺寸、机器人103b的大小、 瞬态变量，如机器人103b与其它相邻机器人103c保持多少距离。103N 等。现在，当必须部署或实例化计划时，变量的值，比如机器人的大小， 需要从代理目录113映射到新计划的变量。因此，在部署更新的计划和 任务分配策略之前，将瞬态和/或静态变量与识别的计划和任务分配策略 的新值进行映射。

在一个实施例中，考虑可以添加或移除机器人103C的瞬态能力的示 例。在该示例中，通知的分析可以指示需要为机器人103C更新计划以及 任务分配策略。为了简单起见，我们将一个计划和一个任务分配策略作 为示例，然而，范围不限于此，并且包括多个计划和多个任务分配策略 的更新。为此，考虑机器人可以在部署后导航并获取新能力的场景。机 器人103c可以是AGV，其可以原地旋转，是差动驱动机器人，并且可 以进行360度旋转，在任何方向上导航，并且按照路线计划执行拾取或 放下的任务。现在，当导航至仓库中的特定区域时，AGV 103c可获得手 推车或梭，因此现在不能进行360度旋转，而是获得像新能力的三循环 控制器。由于这一新的能力，AGV 103c现在可以像汽车一样导航。一旦 完成AGV 103c与手推车或梭的对准，该对准触发对DR模块102的通 知，以产生定制的解决方案来处理AGV 103c的新获取的能力，如本文 所讨论的。DR模块102分析通知并且生成如本文所讨论的解决方案。因 此，对于这种情况，可能需要DR模块102实施不同的任务分配策略。先前为AGV 103c实施的导航计划可能需要以具有对应于三循环控制器 能力的任务的导航计划来更新。因此，对于路线规划，更早地，AGV 103c 的任务是导航至特定位置且能够做360度旋转并拾取。然而，现在由于 AGV 103c已经与手推车或梭对准的情形的改变，AGV103c可能不能够 进行360度旋转，并且当AGV 103c位于手推车后面时将不能够反向行 驶。因此，此处DR模块102产生一个或多个解来求解AGV 103c的定 向约束及路线的后处理。在一个实施例中，DR模块102与计划执行引擎103a、103b…103n协作反应生成解决方案。DR模块102确保现有导航 计划被更新，且新的相关任务分配策略被分配以考虑AGV 103c的能力的运行时获取。DR模块102然后可以用来自计划目录111的新的相关导 航计划和新的任务分配策略来更新现有导航计划，该新的相关导航计划 和新的任务分配策略可以从与AGV103c的路线计划相关的任务分配目 录112更新。新的更新计划和任务分配策略使AGV 103c能够以新获取 的能力继续执行给定的任务集。因此，在部署更新的计划和任务分配策 略之前，将瞬态和/或静态变量与识别的计划和任务分配策略的新值映 射，以反映由AGV103c获取的新能力。在一个实施例中，DR模块102 通过分析计划和任务分配策略变量的值来确定映射是否可以在计划级和 /或任务分配策略级别进行。基于这些值，DR模块102确定计划和任务 分配策略的静态和/或瞬态变量并将其映射为新值，以将所生成的解决方 案对准到与AGV 103c的新获取的能力。

在一个实施例中，由于在机器人中添加了新的能力，计划和任务分 配策略可能都需要更新。例如，任务分配策略和计划的改变可以由DR 模块102基于与机器人中的新能力的添加有关的事件来发起。更早的时 候，机器人仅能够拾取100kg，现在，在获得手推车或穿梭装置的扩展 功能的新能力之后，机器人现在能够拾取大约200kg，因此，可以保证 分配新的一组任务。因此，现在DR模块102可能必须分析计划和任务 分配策略用于更新。更早的时候，在获取之前机器人的能力之间没有区 别，一般原理是所有AGV将能够执行仅100kg的与拾取和放下相关的 任务。然而，现在DR模块102必须考虑运行时情形，其中如果存在需要超过100kg的任务，则可分配新任务，因为AGV 103c具有如本文所 述的扩展功能。

因此，在较早的情况下，在部署后，当DR模块102被通知AGV 103c 已经与手推车或穿梭车对准并获得新的能力时，这给DR模块102提高 系统性能水平的机会。在分析通知之后，DR模块102检查平台、任务分 配策略和/或计划变量，其指示AGV 103c的计划和任务分配策略都需要 如本文所讨论的那样被更新。DR模块102生成用于识别要分配的相关计 划和任务以与新能力对准的多个解决方案。在识别出待分配的相关计划 和任务之后，DR模块102将它们部署在AGV 103c上。本发明不受作为 用于生成更新计划和/或任务分配策略的解决方案的因素的设备能力的 这种场景的限制，但是范围足够宽泛以考虑在异构设备的操作环境内的 运行时可能遇到的其它因素。

在一个实施例中，机器人的能力可以存储在代理目录113中。代理 目录113还包括机器人专用代码或固件代码。考虑到在机器人104b上运 行的计划执行引擎103b可以报告机器人104b的能力X已经随着Y改变。 因此，在接收到通知之后，DR模块102最初验证现有计划和任务分配策 略是否能够考虑能力Y的这种改变，如果它们能够考虑能力Y的改变或 者与能力Y兼容，则不需要改变。然而，如果当前计划和任务分配策略 不兼容，则DR模块检查能力是否对于任务分配策略被参数化，这意味 着新值是否被映射到任务分配策略，它是否保证新的计划。例如机器人 是否可以拾取或放下保证了计划目录给出具有拾取和放下功能的适当计 划。DR模块插入计划目录和任务分配目录，并找到可被部署的兼容计划 和任务分配策略。而且，在一个实施例中，由于能力已经改变，DR模块 可以参考代理目录并且拉出新的固件代码(例如，机器人的驱动功能的 改变)，因为现有代码可能与机器人104b的能力的改变不兼容。新的固 件代码可以与机器人104b的能力兼容。例如，机器人104b可以是全向 机器人，并且具有用于其与如何驱动机器人有关的当前功能的固件和关 联代码。能力的改变可以导致机器人104B现在具有三循环控制器驱动功 能。基于新的能力，DR模块可以利用与机器人104b的新的能力兼容的 新的识别的软件代码来升级固件和/或软件代码。然而，能力的改变也可 能不总是需要固件更新，因此，DR模块必须对能力的改变何时可能保证 固件升级做出决定，并且因此需要与代理目录通信。

在一个实施例中，提供了示出任务分配策略的样本元数据的示例性 非限制方案：

样本任务分配策略

/>

现在在此讨论上述模式中所示的一些变量。应当理解，样本任务分 配策略中的这些变量的计数或名称可以不被认为是限制性的或特定的， 因为它们可以被定制并且可以根据操作要求而与不同的名称或值一起使 用。第一变量“id”指示唯一标识符，而“author”可以是应用所有者 或开发者。下一个变量“license”指示用于特定任务分配策略的许可证的类型。值“RR.LICENSE.OnDeployment”表示可以基于任务分配策 略的部署的计数来完成充电。变量“version”指示特定任务分配策略的 版本。该变量的用途之一可以是在部署或更新现有任务分配策略之前进 行兼容性检查。变量“allocationType”指示由任务分配策略完成的任务 分配的类型。例如，值“RR.ALLOCATIONTYPE.Batch”指示分配是 批处理类型处理而不是每个任务处理。下一个变量“compatibleRoles” 指示与任务分配策略兼容的机器人的类型。因此，第一值 [“RR.ROLE.AMR.*”]指示所有AMR均可兼容，由“*”符号标出。类似地，其它值["RR.ROLE.AMR.FORKLIFT","RR.ROLE.AMR.AGV"] 分别表示叉车和AGV作为兼容的机器人。下一个变量 “minAgentCardinality”表示任务分配策略能够处理的代理或机器人的 数量，其值为1，如图所示。类似地，下一个变量“maxAgentCardinality”： 50表示任务分配策略最多可以处理50个机器人。如果存在多于50个机 器人，则任务分配计算成为NP难题，并且然后使用这种方法求解任务 分配计算可能是不可行的。因此，对于需要多于50个机器人的仓库或操 作环境，当DR模块进行兼容性检查和/或与默认或预定标准的比较检查 时，该任务分配策略可能不兼容。下一个变量“maxTaskCardinality”： 50000表示任务分配策略能够处理的任务的数量。这里，该值是策略可以 处理的50000个任务。作为利用上述变量值运行任务分配策略的结果， 下一个变量“maxAgentsPerTask”：1表示每个被分配的任务的代理的数 量(例如1)。应当理解，术语“代理”可以由术语“机器人”或任何其 它异构设备来代替，如本文所讨论的。变量“comment”包括对特定任 务分配策略的一般注释。变量“deploymentTarget”是“list”类型，表 示可以在其上部署的任务分配策略的不同类型的设备。在所述示例中， 值["RR.DEPLOYTARGET.Cloud"]指示任务分配策略可以由云设备系 统执行，并且云设备系统的DR模块可以指示代理或机器人执行任务分 配策略的执行结果。值["RR.DEPLOYTARGET.Agent"]意味着这是轻量 级任务分配策略，其可以在机器人上执行并且不必需要云设备系统来执 行。当["RR.DEPLOYTARGET.Cloud","RR.DEPLOYTARGET.Agent"] 赋值时，那么，任务分配策略可以与在云、机器人、以及两者上执行兼 容。对于该值，DR模块决定任务分配策略是否可以在云、机器人或两者 上执行。如果任务分配策略必须在云节点上执行，则变量 “cloudNodeExePath”包括任务分配策略的源代码的URL。如果任务分 配策略必须在机器人上运行，则变量“agentSummandsExePath”包括用 于在机器人上运行的任务分配策略的相应源代码的URL。现在，当必须 部署的任务分配策略时，DR模块决定任务分配策略必须在哪里运行。因 此，URL处的源代码必须与云设备系统和/或机器人兼容，任务分配策略 必须在所述云设备系统和/或机器人上执行。任务分配策略的下一个变量 “supportedCostMaps”指示距离计算是否基于EUCLIDEAN ORMANHATTAN距离。到目前为止所讨论的变量可以是静态变量，而下一 个变量“parameters”可以是动态变量，其可以根据需要来设置。例如， “parameters”变量中的值指示在部署的任务分配策略时可以被覆盖掉 的默认值或定制值。在部署期间，具有值“True”的参数变量“preemptible” 指示应用程序是否希望任务可抢占。例如，如果机器人已经被指派给任 务并且存在可用的更好的任务分配策略，则该机器人是否被抢占。对于 值“True”，机器人可以被抢占。参数变量指示机器人可以被抢占的阈值。 该变量可以确保任务分配策略不继续通过使机器人抢占较小的性能增益 来分配新任务。单位0.2指示对于要发生的抢占可以存在至少0.2个单位 的所得性能增益。剩余的变量指示CostMap和超时。超时指示为任务分配策略给出的进行最优任务分配计算的时间单位。

在一个实施例中，考虑DR模块开始与部署在异构AMR组上的上 述任务分配策略相关的动作的场景。在上述示例中， “maxAgentCardinationy”值是50，并且在运行时已经将新机器人添加 到当前50号机器人队列中，由于添加了新机器人，触发了一个事件，该 事件是对DR模块的通知，指示添加了新机器人。DR模块分析事件或通 知以发现阈值的破坏，因为机队中的机器人的计数与 “maxAgentCardinationy”值不匹配。DR模块可计算每个任务的代理 的数量(“maxAgentPerTask”变量)可能需要增加到2或者其它变量可 能需要被更新。由于这些是静态变量，DR模块产生解决方案以利用来自 任务分配目录的新任务分配策略切换任务分配策略。变量 “trackingVariables”允许变量可以由DR模块在任务分配策略层监视。 类似地，在计划中存在跟踪变量，其允许DR模块在计划级监视变量。 第一变量可以是“task_throughputPerAgent”，其最小值为12，最大值 为1000。在一个实施例中，这可以指示每小时执行的任务的数量，其中 最少为12，并且最多为1000。当在机器人上部署的任务分配策略时，可 以按照机器人的规范、角色和能力来更新这些值。当这些值被突破时，产生通知DR模块寻找替代物的事件。下一个要跟踪的变量可以是“throughputBreachInterval”：300，其表示在DR模块找出替换物之前 突破这些值多长时间。因此，在一个实施例中，如果要跟踪的变量在300 个时间单位内被一致地违反，则DR模块对事件作出反应，否则可能不 需要DR模块采取任何步骤来切换或替换任务分配策略。下一个变量“定 制”。随机变量“custom.randomVariable”:[“min”:11,“max”:123]描 绘了开发者或应用所有者可以根据他们在用于跟踪的任务分配策略中的 要求来定义随机或定制的变量。

在一个实施例中，DR模块可以基于任务分配策略中的元数据或变量 来生成解决方案。与元数据或变量相关的数据的实际收集可以由在云和 机器人上运行的计划执行引擎完成。例如，如果任务分配策略要在机器 人上执行，则在“agentSummandsExePath”变量处指示的库或软件代码 可以被部署在机器人上，并且在机器人上运行的计划执行引擎可以与在 变量“agentSummandsExePath”中指示的库通信。

在一个实施例中，在任务分配策略层上被跟踪的变量可以指示系统 的性能已经下降或者值不接近期望的性能范围。考虑“costMap”的值是 “RR.DISTANCE.EUCLIDEAN”，并且基于此，任务分配正在进行。DR 模块产生的一个或多个解决方案可以是选择新的任务分配策略，其 “costMap”值为“RR.DISTANCE.MANHATTAN”或其它类似的值。 这里，如果任务分配策略包括多个距离值的列表，则DR模块可以生成 解决方案，该解决方案可以包括基于“costMap”的值之一的历史性能来 识别任务分配策略。因此，基于所产生的解决方案，DR模块检查任何其 它任务分配策略的历史性能是否优于当前性能，并且如果任务分配策略 表现出较好的性能，则可以更新现有的任务分配策略。类似地，所生成 的解决方案可以基于变量的值的各种排列和组合，可以考虑这些变量以 识别用于更新和稍后部署在云和异构AMR上的相关任务分配策略。所 产生的解可以由DR模块重复地分析，直到实现所需的吞吐量或性能增 益。如本文所讨论的，可以应用类似的方法来生成用于更新现有计划和 任务分配策略的解决方案。

在一个实施例中，以下提供了示出计划的样本元数据的示例性非限 制性方案：

计划目录中的样本计划：

在一个实施例中，计划可以是“PickAndDrop”计划。现在可以在 此讨论所示的一些变量。应当理解，样本计划中的这些变量的计数或名 称可以不被认为是限制性的或特定的，因为它们可以被定制并且可以根 据操作要求而与不同的名称或值一起使用。该计划具有一些功能类似于 任务分配目录的变量。为了避免可重复性和为了简单起见，讨论了样本变量，然而，除非本文另有说明，否则其它变量的功能可以与针对任务 分配策略所讨论的类似或扩展。当AMR在工作环境中导航时，AMR可 以执行“PickAndDrop”计划。变量“id”：1542881132435、“author”： plan_writer@domain.com、“license”：RR.LICENSE.OrgOneTime、 “rr_spec”：0.9.2、“version”：v2.0.1、“compatibleRoles”：[“RR.ROLE.AMR.*”,"RR.ROLE.AMR.FORKLIFT", "RR.ROLE.AMR.AGV"]、“exePath”：“

图2是示出用于动态管理异构机器人机群的计划和任务分配策略的 更新的系统200的框图。在一个实施例中，系统200包括云设备管理系 统202，其是用于在云和不同设备处部署和执行软件(例如，计划)的平 台。云设备管理系统202还用于管理包括机器人的设备。云设备管理系 统202是用于云机器人解决方案提供商的平台即服务框架。云设备管理系统202包括一个或多个处理器，用于处理在云设备管理系统处接收的 以及来自与云设备管理系统通信的设备的数据。为了简单起见，仅示出 了两个机器人214和216，然而，本发明不限于此，并且可以包括不同组 合和类型的设备。

云设备管理系统202还包括传感器和执行数据存储204。传感器和执 行数据存储204存储由机器人执行的行为的执行数据和云设备管理。传 感器和执行数据存储还存储由机器人捕获的传感器数据。机器人行为是 在该状态内的某些条件下由机器人执行的低级别原子活动。

在一个实施例中，云设备管理系统202还包括显示计划的用户界面 206。云设备管理系统202包括目录存储208，其在计划目录(未示出) 中存储若干计划。在用户界面206处向用户显示存储在目录存储208中 的不同现有计划。用户可以从目录存储208选择用户想要添加到机器人 执行计划的一个或多个新的子计划或计划。在一个实施例中，云设备管理系统202检查新计划和当前运行机器人执行计划的兼容性。基于该检 查，云设备管理系统202允许将现有计划添加到机器人执行计划。这类 似于平台在向计划执行引擎添加或更新现有计划时主动采取的步骤。

在一个实施例中，在机器人执行时或在云设备管理系统处部署所选 择的现有计划之前，所选择的现有计划可以被转换成可执行代码。机器 人计划执行系统202包括构建引擎210，其将现有计划转换成可执行代 码。为了将计划转换成可执行代码，构建引擎210将构建器图像代码注 入到计划中。构建器映像可以包括运行源代码的部署实例所需的各种软 件组件以及帮助检测源特征(框架、语言等)的软件。例如，构造器映 像可以包括操作系统库、语言运行时、中间件和源到映像工具。当执行 构造器图像时，它将开发者的源代码注入到构造器图像中，并产生软件 可执行图像。构造器图像可用于云和设备侧。

云设备管理系统202还包括部署和运行时(DR)模块212，其管理 云设备管理系统202与机器人214和216之间的通信。在一个实施例中， DR模块212包括从机器人214和216接收传感器数据和执行数据的消息 代理218。机器人214和216可以分别包括通信器220和222，其建立与 消息代理218的双向通信。消息代理218接收传感器数据和在机器人214 和216上运行的新的可选计划和现有计划的执行结果。在一个实施例中， 机器人处的通信器220和222还可以具有彼此的对等通信，以共享由机 器人收集的传感器数据和由机器人214和216执行计划的执行结果。DR 模块212包括子组件，如图2中的设备管理器212、消息代理218和构建 引擎210。

在一个实施例中，当选择现有计划和任务分配策略时，云设备管理 系统202调用新计划执行引擎224以执行现有计划。在一个实施例中， 云设备管理系统202还在云设备管理系统或机器人处部署新计划执行引 擎。在一个实施例中，新计划执行引擎连接到执行和传感器数据存储。

在一个实施例中，云设备管理系统202和自主移动机器人214和216 分别包括计划执行引擎224和226、228。机器人214和216可以是在与 云设备管理系统的协作环境中工作的异构自主移动机器人。异构设备可 以包括至少一个或多个不同的设备类型或相同的设备，但是具有不同的 能力或安装了不同的软件版本，或不同的操作系统(例如机器人操作系 统)版本，不同的硬件类型，不同的制造商，或设备类型的其它可能的 组合等。计划执行引擎224、226和228根据在计划执行引擎上部署的计 划和任务分配策略来执行计划和任务分配策略之一。计划执行引擎是包 括执行控制计划执行所需的不同操作的逻辑的软件模块。例如，计划执 行引擎存储用于确定将计划中包括的任务分配给不同的自主机器人的逻辑、解决与计划有关的不同约束问题、使计划的执行同步等。每个自主 机器人和云设备管理系统执行用于执行计划的计划执行引擎。

计划执行引擎224、226和228单独地或与其它计划执行引擎协作地 执行计划和任务分配策略。在一个实施例中，执行计划包括管理计划执 行的整个生命周期，包括确定若干计划执行值。例如，执行计划和任务 分配策略包括确定计划内的不同任务到不同自主机器人的任务分配。这 些计划执行值可以在计划执行的不同阶段确定，也可以基于环境或机器 人条件的变化实时确定。例如，当被指派给特定任务的自主机器人中的 任何一个发生故障并且任务必须被重新指派给尚未发生故障并且能够执 行该任务的其它机器人时，可以在计划执行的不同阶段或实时地确定对 机器人的任务分配。

在一个实施例中，由计划执行引擎224、226和228确定的不同计划 执行值以及由机器人214和216收集的传感器数据被存储在传感器和执 行数据存储204中。在一个实施例中，云设备管理系统202包括传感器 和对应于机器人执行计划的执行数据存储。例如，云设备管理系统202 包括与机器人执行计划相对应的传感器和执行数据存储204和230。传感器和执行数据存储204、232和234分别从在云设备管理系统202处执行 的计划执行引擎224、226和228接收与机器人执行计划相对应的计划执 行值，并从机器人214和216接收传感器和执行数据。

在一个实施例中，传感器和执行数据存储204和230彼此通信以在 彼此处更新传感器和执行数据。在一个实施例中，机器人214和216分 别包括本地传感器和执行数据存储器232和234。本地传感器和执行数据 存储器232和234分别用来自机器人214和216的传感器数据以及来自 计划执行引擎226和228的执行数据来更新。本地传感器和执行数据存 储232和234中的数据周期性地与传感器和执行数据存储230同步。

如所讨论的，传感器和执行数据存储204、232和234与在云设备管 理系统202或机器人214和216处执行的计划执行引擎224、226和228 协作，利用DR模块212执行计划的执行结果来更新。DR模块212使用 到传感器和执行数据存储230的连接来从传感器和执行数据存储232和 234检索计划执行数据和传感器数据。DR模块212基于读取计划执行数 据和传感器数据来确定计划执行的状态。

读取计划执行数据和任务分配策略允许DR模块212确定新的替代 计划和任务分配策略何时可以由计划执行引擎224或其它计划执行引擎 226和228执行。DR模块212可以在满足特定条件、执行特定计划行为 或任何其它计划执行结果之后，推送新的一个或多个可选计划和任务分 配策略以用于执行。例如，在当前计划是“机器人充电”计划并且新的替代计划是“软件更新”时。“软件更新”计划可以被定义为当“机器人 充电”计划进入“机器人充电”计划的“充电”状态时被执行。DR模块 212确定何时用来自执行“机器人充电”计划的计划执行引擎的“对接” 状态更新传感器和执行数据存储。基于该确定，DR模块212用新的替代 计划更新现有计划，并且计划执行引擎执行新的替代“软件更新”计划。

在一个实施例中，执行“机器人停车”计划的计划执行引擎226可 以用机器人214的当前位置，例如“等待位置”、“停车位置”等，来更 新执行和传感器数据存储232。本地传感器和执行数据存储232和228 中的数据与云设备管理系统202中的传感器和执行数据存储230同步。 DR模块212连续地监视平台变量，比如位置，并且当从执行和传感器数 据存储230检索的机器人214的当前位置存在改变时，DR模块212被通 知该改变。在通知关于改变时，DR模块212分析平台变量并且识别包括 验证机器人的当前位置是否是“停放”位置的解决方案。如果机器人位 置已经改变为“停放”位置，则作为解决方案的一部分，DR模块214推送“软件更新”行为计划以启动机器人214上的软件更新操作，并且 任务被更新为“软件更新任务”。

在一个实施例中，云设备系统202包括流行度模块240.DR模块与 流行度模块240通信，并且使得用户能够变得流行或者基于他们导入的 专有计划的流行度、社区的使用、评论、软件代码的用户友好性、计划、 任务分配策略、多核特征、评论分数等中的至少一个或多个来接收增加 的许可费用。

图3是示出根据实施例的部署更新的计划和任务分配策略以供执行 的过程的示例性和非限制性流程图。最初，开发者或用户导入计划或使 用用户界面来定义计划。系统可以从目录存储接收部署一个或多个计划 的请求。该计划包括取决于设备(例如AMR)正被安装的情形的任务。 例如，在自主仓库中，典型任务可以涉及导航，如LiDAR导航、基于视觉的导航、拣选和放下库存物品、分类、抓取物体等。在接收到请求之 后，平台部署要在一队AMR上执行的计划和任务分配策略。然后在云 设备系统和AMR中的一个或多个上执行现有计划。

部署后，AMR组继续执行所分配的任务，例如拾取和放下、分类、 抓取、跟随人、将货物带给人等。如本文所述，平台可以通过可重新配 置的计划和任务分配策略来适配多个异构设备的操作能力。在仓库类型 的环境中，存在AMR可能需要来自平台的引导或支持的多种情况。因 此，平台的DR模块连续地监视与平台或计划或任务分配策略变量相关 的各种事件，所述变量包括指示注册到平台的一队AMR的性能或功能 的值(301)。动作的通知或触发可以经由源自AMR本身的事件或者由 平台内部地发生。该通知可以是从在AMR上运行的计划执行引擎到DR 模块的信号或消息的形式。该通知可以与部署在云和/或AMR之一上的 一个或多个计划和任务分配策略相关。如果通知被发送到DR模块，则 通知识别特定计划(例如，充电和/或导航计划)和任务分配策略。在一 个实施例中，DR模块基于由在云节点上运行的计划执行引擎和/或在 AMR上运行的计划执行引擎采取的协作步骤来触发或通知。此外，DR 模块基于AMR上发生的事件和从计划本身收集的信息来通知或触发。 在一个实施例中，可以针对多种场景启动通知或触发—例如，机器人可 以获取新的能力或者可以支持新的行为以执行特定任务，例如，AGV获 得机器人臂能力，并且因此可以不同地到处航行，因此，DR模块可以接 收到触发，该触发指示需要增强AGV的能力。DR模块分析现有计划和 现有任务分配策略用于更新。基于对通知的分析，DR模块识别如本文所 讨论的一个或多个解决方案。作为解决方案的一部分，DR模块从计划目 录检索用于ARM能力的合适的计划和任务分配策略，并且如本文所述 部署它们。此外，DR模块将新的任务集从新的计划和任务分配策略分配 到异构机器人上。在另一实施例中，通知还可以由于不同类型的设备加入设备群而被发出。例如，“Goods to person(货物到人)”机器人可以 加入该组设备，其然后可以触发到DR模块的通知以识别解决方案来处 理加入该组设备的该新设备。基于场景动态地识别解决方案，并且这里 讨论了关于DR模块生成的各种解决方案的各种示例。基于所生成的解 决方案，DR模块识别用于如本文所讨论的部署的相关的一个或多个计划 和任务分配策略(304)。相关计划和任务分配策略可以与新的机器人行 为对准或支持新的机器人行为。这些示例不是限制性的，并且可能导致 计划和任务分配策略的切换或更新的任何潜在场景都包含在本发明的范 围内。这样的场景可以触发或使用替代机制来使得平台能够根据动态需 求来做出决定并切换计划和任务分配策略。

在从特定AMR或多个AMR接收到通知之后，或者在内部，在主 动监视与AMR队列相关的事件的同时，DR模块分析需要被跟踪的一个 或多个平台、任务分配策略和计划变量(例如机器人的等待时间、系统 停机时间、代理在AMR上的CPU消耗时间等)的通知的计划和任务分 配策略(302)。因此，在这样的场景中，如本文所讨论的，实施例之一 包括分析目录存储以基于变量之一来标识替代的或更多相关计划和任务 分配策略。例如，计划变量之一可以是“系统性能”。然后，可以以一般 的方式定义可以针对特定计划而被监视或跟踪的计划变量，例如针对系 统停机时间。计划变量可以被定制或定义为：a)机器人在十字路口等待 花费多少时间以便其它机器人(类似机器人类型或其它类型)可以通过？ b)机器人在去充电站之前实际上在队列中等待多长时间？然后，标记或 标注状态或行为以分析计划中的表现。在识别了相关计划和任务分配策 略之后，利用相关计划和任务分配策略来更新现有计划和现有任务分配 策略(305)。

在另一个实施例中，DR模块产生与通过多个因素，例如考虑历史数 据，提取替代的更好的计划和更好的任务分配策略相关的解决方案。这 些解决方案是基于对可能包括通知的事件的分析而生成的。考虑一种场 景，其中可能存在包括任务的充电计划，如该计划中的“在充电站处前 往并排队一段特定时间(例如3秒)以及对接充电一段特定时间”，排队 时间是铲车/AGV/AMR或AMR组等待到达用于对接的充电插槽的时 间。因此，在这种情况下，平台可能受到影响，或者可以重新配置计划 以基于平台变量“％电池水平”做出去和充电的决定。因此，以一般的 方式，平台或具体地DR模块跟踪平台变量“系统停机时间”，并且所生 成的解决方案之一可以与场景相关，当电池水平降到预定阈值(例如65％ 的电池水平)以下时，则现有计划可以由新计划代替，并且现有任务分 配策略可以由新任务分配策略代替，以迫使机器人在特定时间段内前进 并排队进行充电，然后，稍后停靠以在特定时间段内进行充电。一旦计 划和任务分配策略被替换或更新，平台就在云设备系统和/或多个AMR 上部署更新的计划和任务分配策略(306)。

图4是示出根据实施例的用于更新自主移动设备的计划和任务分配 策略的处理步骤的示例性流程图。在一个实施例中，在代理目录中，可 以更新机器人的变量以表示当前状态。例如，对于变量“最大负载系数”， 特定的AGV可以具有100kg的值。一旦AGV与小车或梭件连接，则能 力增加，并且变量“最大负载系数”的值增加到新的总重量，例如200kg。由于AGV和小车或穿梭车之间的这种连接，系统中已经反映了两个变 化：a)AGV原地旋转的能力或全向机器人可以由能够以三循环驱动控 制器方式驱动的单向机器人代替，以及b)AGV能够处理其先前拾取和 放下能力的两倍。机器人将这些变化报告给计划执行引擎，计划执行引 擎又通知DR模块这些是机器人所获取的新能力(401)。因此，该通知 是DR模块生成与新能力对准的解决方案的触发，该新能力导致用于这 些新能力的一个或多个计划和一个或多个任务分配策略的更新(402)。 DR模块可以生成用于与新获取的能力对准的附加解决方案，如本文所讨 论的：

a)机器人的计划和角色可以被替换，例如申请人的PA-AMR机器 人，“Sootballs”获得“手臂”能力，并且现在具有新的角色。DR模块 在计划目录和任务分配策略目录中搜索新的计划和新的任务分配策略(403)。需要首先验证所识别的计划和任务分配策略以进行兼容性检查。 这种兼容性检查可以被平台视为主动措施，以确保准确的计划和任务分 配策略被部署在机器人上。兼容性检查可以包括API、机器人类型、机 器人能力、机器人行为、硬件、软件兼容性检查等中的至少一个或多个 (404)计划中的替换由DR模块通知给整个机器人组。

b)任务分配策略可以被替换以指示部署在仓库中的策略需要考虑由 机器人中的一个或多个从机器人队列中获取的额外能力。这将进一步详 细描述：当机器人获得机器人或更高级别的能力时，运行在机器人上的 计划执行引擎首先通知DR模块。DR模块然后查看计划目录和任务分配 目录，拉出相关任务分配策略和相关计划。在通过兼容性检查验证了相 关计划和任务分配策略之后，可以更新这些计划和任务分配策略(405)。 现在，让我们集中于任务分配策略，并理解DR模块如何执行任务分配 策略的更新。最初，任务分配策略指示仓库中的所有机器人的最大负载 承受能力被定义为100kg。如果平台接收到任务有效载荷能力为180kg 的任务，则DR模块拒绝该任务，该任务指示到目前为止该能力不存在，因此该任务不能被执行。然而，稍后，一旦机器人与台车或穿梭装置对 准，DR模块在其事件监视过程期间识别可以承受180kg负载的机器人。 因此，现在可以获得处理180kg任务负载的能力，DR模块从任务分配目 录中提取相关的任务分配策略，以执行具有180kg任务负载的任务。在 某些情况下，为了效率的目的，DR模块可以仅需要将可变最大负载因子 映射到用于特定机器人的180kg，以确保执行具有较高有效载荷的新任 务，而不是拉取整个任务分配策略并替换当前任务分配策略。然后，将 该事件通知给整个机器人队列。在其它情况下，计划变量和任务分配策 略变量被映射有新值，例如最大负载因子现在从100kg增加到180kg， 以确保执行具有更高有效负载的新任务(406)。现在，已更新的计划和 任务分配策略准备好被部署在云和/或异构AMR上。在这种情况下，DR 模块将更新的计划和任务分配策略部署在连接到手推车的机器人上 (407)。因此，对于工作负荷的协作功能，DR模块通知所有机器人有效 负荷超过180kg的较早任务被拒绝，然而，利用新扩展的能力，不需要 拒绝较重的任务。因此，与台车或梭车对准的机器人获得较高的权重或 优先级以执行较高的负载任务。现在，考虑也获取台车或穿梭车的另一 机器人。这种情况展示了平台的鲁棒性和效率。由于整个系统知道机器 人队列具有扩展的有效载荷能力，因此DR模块不需要映射变量来指示 更高的能力或者制定新的任务分配策略来更新第二机器人的附加能力的 新获取。DR模块只需要保持来自机器人队列的两个机器人具有额外的能 力。因此，当存在多个新的繁重任务时，可以给予两个机器人较高的权 重以执行任务。

c)现在，考虑当前正在部署的仅能够处理AGV类型的机器人的计 划。当监视系统上发生的事件时，DR模块检测到铲车类型的机器人已经 加入机群，并且系统不知道如何与新的机器人协作。原因在于，在机器 人队列上部署的计划仅可以考虑AGV类型的机器人，因为其是默认的支 持角色，并且不包括叉车的任何角色。在这种情况下，在叉车进入画面 之前部署的当前计划和任务分配策略可以如下：AGV在托板下方行进、 拾取、到达目的地并下降。在这种情况下，任务分配策略对于与调色板 移动、拾取和放下相关的任务，每个项目只有一个机器人(AGV)要被 分配。然而，在一个或多个叉车加入机群的情况下，需要更新任务分配 策略和计划以确保叉车和AGV协同工作。该计划和任务分配策略可以被 更新，以使得该叉车和AGV可以如下被分配任务-该叉车可以拾取物品 并将其放在AGV上，AGV然后可以导航到目的地，并且在该目的地， 可以分配另一叉车到达该目的地并帮助AGV卸载该物品。在第一种情况 下，AGV必须在托板下方移动并将其拾取，然而，在第二种情况下，AGV 必须在一定半径内靠近叉车，并且叉车可能进行重型提升并帮助AGV卸 载物品。

d)在混合类型的场景中，一些机器人失去拾取和放下的能力，而其 它机器人具有执行拾取和放下的能力。考虑到较早的AGV能够进行拾取 和放下，然而，由于一些故障，AGV已经失去了进行拾取和放下的能力。 如果叉车也是机器人机群的一部分，则DR模块可以强制其余机器人与 叉车协作并且使用可用的最小能力来执行仓库中的任务而不出现任何性能下降。因此，在高层，让我们考虑如何更新计划和任务分配策略。在 开始时，平台将任务分配给每个机器人。一旦机器人被分配了任务，DR 模块就识别适当的计划。该计划概述了机器人在计划执行的生命周期期 间需要经历的不同状态和行为。一旦DR模块接收到某些事件的触发或 通知，则可能需要更新计划和任务分配策略。触发指示机器人的角色或 能力以及如何添加或移除机器人的能力。因此，通过添加或移除而可能 被扩展或减少的能力可以是，例如，AGV可以具有检测条形码或检测不 到条形码的能力，能够使用SLAM导航或磁条导航来导航，叉车可以具 有拾取、放下和托板移动的能力。因此，在一个实施例中，机器人可以 被认为是具有一组能力的设备。每当存在与那些能力的添加或移除相关 的事件时，该事件触发对DR模块的通知。DR模块然后分析该通知并且 生成解决方案，该解决方案验证当前计划和任务分配策略是考虑新的能 力添加还是新的机器人添加。如果验证结果为否定，则DR模块在目录 存储中搜索适当的计划和任务分配策略。然后，这些新计划和任务分配 策略跨云和自主移动机器人的异构机群来部署。

在一个实施例中，计划和任务分配策略彼此独立。有时，基于计划 的过去历史使用，计划可能是好的，并且类似地，可能存在过去可能已 经很好地工作的任务分配策略，然而，如果它们彼此不兼容以在特定场 景中实现，则DR模块可以做出当前现有任务分配策略和计划可能最适 于在当前情况下执行的决定，并且因此不需要改变。在这样的情况下， DR模块可以中止如本文所讨论的新计划和任务分配策略的更新或替换。

图5是示出根据实施例的用于更新计划的处理步骤的示例性流程图。 为了可读性和简单的目的，已经考虑了用于计划的处理流程，然而，该 处理流程也适用于任务分配策略。应当理解，本发明不限于仅确定API 兼容性，因为还可以考虑其它因素来确定兼容性，例如机器人类型、机 器人行为、机器人角色、机器人能力、机器人硬件、机器人软件、操作环境因素、本文讨论的其它因素等。因此，在讨论中，API兼容性可由 如本文所讨论的因素来替换。为了简单起见，仅讨论一个计划，然而， 本发明不限于一个计划的比较，而是范围也包括多个计划。类似的方法 可适用于兼容性检查的任务分配策略。在一个实施例中，考虑在用新计 划更新部署的计划(501)之前的处理步骤，平台或DR模块可以执行检 查或验证以确定部署的计划和新计划之间的API兼容性(502)。在一个 实施例中，确定API兼容性包括确定所部署的计划API的软件版本是否 与新计划API的软件版本匹配。在一个实施例中，云设备管理系统还包 括检查以匹配部署的计划和新计划的代码版本。在确定部署的计划和新 计划的API不匹配的情况下(502中的条件是“否”)，云设备管理系统 在用户界面上显示替代计划(503)。所建议的替代方案可以基于所讨论 的解决方案或者可以被包括在本发明的范围内的那些解决方案。该步骤 可以是手动的，其中可能需要用户输入，或者可以是自动的，其中平台 基于在本发明的更宽泛范围内设想的各种场景作出自动决定。

接下来，在新计划和现有计划具有API兼容性的情况下(502中的 条件为真)，则显示变量映射用户界面以映射新计划的暴露变量和任务以 及所部署的计划的暴露变量和任务(504)。接收用户输入以映射新计划 和部署的计划的一个或多个暴露变量和任务(505)。映射所展示的变量 名，以便允许执行所部署的计划执行引擎检索与新计划的所展示的变量 相对应的机器人执行计划的变量值。例如，部署的计划可以具有暴露变 量“速度”，并且新的计划可以具有暴露变量“速度”。在变量映射用户 界面处，暴露变量“速度”被映射到暴露变量“速度”。执行所部署的计 划执行引擎更新传感器和执行数据存储处的“速度”值(507)。新计划 执行引擎检索“速度”参数的值，并将其分配给新计划的“速度”变量。 类似地，映射部署的计划的“叉车任务”和新计划的“车辆任务”。

接下来，将新计划映射到传感器和执行数据存储(506)。然后调用 计划执行引擎以执行所部署的计划(507)。新计划执行引擎被部署在云 设备管理系统和自主移动机器人中的一个处(508)。在一个实施例中， 基于计划的定义，新计划执行引擎被部署在云设备管理系统和自主机器 人之一处。

在一个实施例中，执行现有计划的计划执行引擎检索对应于新计划 的暴露变量的数据(509)。在一个实施例中，执行部署的计划的计划执 行引擎基于部署的计划和新计划的映射来检索与新计划的暴露变量相对 应的数据。最后，基于所检索的计划数据，计划执行引擎执行新计划 (510)。执行新计划的结果用传感器和执行数据存储来更新。

图6是示出根据实施例的用于更新计划和任务分配策略的处理步骤 的示例性流程图。在一个实施例中，DR模块如本文所讨论的那样监测在 平台级和机器人级发生的事件(601)。DR模块分析并跟踪可被跟踪的平 台、计划和任务分配策略的所有变量的值(602)。可以将这些要被跟踪 的值与在设计时或在计划中提供的预定标准以及任务分配策略本身进行 比较。预定标准可以根据各种因素定制或定义，例如基于仓库中预期的 吞吐量，比如由拾取辅助机器人每小时100次拾取。变量还可以与可以 基于如本文所讨论的各种因素而设置的阈值进行比较(603)。在所分析 的平台变量、任务分配策略和/或计划变量中的一个与预定标准或预定义 阈值之间进行比较之后，如果变量具有高于阈值或预定标准的值，则平 台可以继续监视事件或忽略通知(604)。然而，在值落在阈值或预定标 准以下的情况下，平台可以基于更好的备选方案生成一个或多个解决方 案(605)，例如分析历史数据以识别更好的备选计划和任务分配策略。 解决方案可以是识别在过去已经成功地为给定实例工作的成功的、流行 的或高效的计划和/或任务分配策略(606)。DR模块的下一步骤可以是 验证更好的替代计划和任务分配策略是否与云和/或多个异构设备上部 署的计划和任务分配策略兼容(607)。兼容性检查是使用如本文所讨论 的多个实现来完成的。在计划和/或任务分配策略不兼容或不匹配的情况 下，DR模块返回以生成用于识别下一个最佳计划和任务分配策略集合的 附加解决方案(608)。在兼容性检查返回肯定的情况下，则可以用更好 的备选计划和任务分配策略来更新所部署的计划和所部署的任务分配策 略(609)。然后，在至少云和/或多个异构自主移动设备上部署更新的计 划和任务分配策略(610)。

在一个实施例中，考虑其中要做出的决定是用于槽管理或为了充电 目的而对机器人排队的场景。平台可以生成集中于历史数据的解决方案。 DR模块可以检索给出有效结果并且还可以确保任务被成功执行的一个 或多个计划和一个或多个任务分配策略。在一个实施例中，所生成的解 决方案可以包括将历史数据的搜索范围缩小至一个或多个因素，例如设 备或在仓库级，例如在过去，在特定客户仓库中，其中在导航时存在无 线连接挑战或照明问题，特定导航计划和/或任务分配策略可能已经以有 限的停机时间成功执行，因此，相同的导航计划和任务分配策略可以作 为新的解决方案的一部分被再次检索。

在一个实施例中，平台呈现用于不同类型的机器人的计划和任务分 配策略的高可用性。考虑导航规划的设计者认为该规划对于申请人 Rapyuta Robotics的具有差动驱动器或其它等效驱动器的产品比如叉车 特别有效。因此，这种信息是非常具体的，而不是通用的。然而，在这 样的场景中，平台以可以兼容并且可以用于替换原始计划的那些计划的 形式例如向用户提供附加信息。例如，平台可以推荐用于具有特定尺寸 的另一公司X的铲车的另一导航计划。因此，在这种情况下，可以以新 的导航规划与旧的规划兼容的方式定义新的导航规划，并且即使存在某 些规划变量的不匹配，新的导航规划也可以替换旧的导航规划。在识别 异构AMR组上的现有计划的替换和更新任务分配策略时，平台可以应 用该相同的策略。

在一个实施例中，在平台变量、计划变量、任务分配策略变量和预 定标准或定义的阈值(例如，低于机器人的总电池水平的10％的电池水 平、在最小和最大范围内的导航时间、在最小和最大范围内的拾取时间 和放下时间等)中的至少一个或多个之间进行比较之后，平台可以基于 更好的备选方案(例如，与为设备分配或要分配的任务有关的任务分配 策略)来生成解决方案。例如，可以有两个任务即“空闲”和“处理订 单”。因此，根据任务分配策略，机器人可能必须工作以处理订单或处于 空闲。现在，假设仓库中有2台叉车并且要通告2个订单。如果两个叉 车处于相等的距离，则为了最佳性能，可以应用的解决方案可以考虑具 有较高电池水平的叉车来处理订单。因此，这里的解决方案包括对具有 较高电池水平的机器人的较高亲和力因子以执行处理订单的任务。因此， 相应地，可以部署相关的一个或多个计划和任务分配策略，并且可以考 虑密切关系因子来分配相关任务。在不同的情况下，如果另一个机器人 的电池水平低于预定标准或阈值，则DR模块可以考虑避免磨损和撕裂， 并且为了增加设备的寿命，如果针对机器人执行任务分配策略“空闲”， 则这可能是最佳的。

在一个实施例中，考虑上述任务包括处理仓库内的特定区域的订单。 仓库可以包括多层布局的区域或仓库的狭窄部分，其中仅特定类型的叉 车(比如说更纤细的叉车)可以在狭窄的设计和有限的工作区域中处理 订单。因此，这里，DR模块产生的解决方案可以包括根据能够在困难环 境中工作的机器人的类型来识别适当计划和任务分配策略的附加因素， 所述困难环境可能具有限制一般类型的机器人的功能的特殊工作设计。 平台识别被定制以解决环境、操作环境问题等的相关计划和任务分配策 略，如本文所讨论的。

在一个实施例中，平台提供了覆盖选项，其允许用户或开发者或第 三方定义平台中的变量或要利用阈值或基准平台变量来跟踪的计划或策 略。在一个实施例中，开发者或用户可以声明要跟踪的平台变量可以是 在特定或AMR组上运行时的设备性能、在等待时段期间所花费的时间 或当设备处于特定阶段时设备的CPU消耗(例如跟踪环境中的对象)或者在机器人上运行的计划执行引擎访问特定状态(例如拾取、保持空闲 等)多少次，也可以定制平台变量，例如，用户可能想要跟踪的平台变 量之一可以是利用率、系统停机时间、CPU消耗等。

在一个实施例中，计划是智能的、可重新配置的，并且具有使AMR 组以使得它们可以按照所需任务来实现的方式来工作的能力。例如，考 虑用于对AMR充电的计划。在AMR上部署的计划和相关任务分配策 略之后，DR模块可被触发或通知与电池电平降到预定阈值(例如电池寿 命的60％)以下的AMR或AMR组上的特定问题相关的事件。平台总 是具有AMR的整个队列的全局视图，并且因此，平台动态地做出关于 特定或一组AMR是否需要进行充电的决定。平台产生多个解决方案， 其可以被应用以确保高性能和效率，用于基于机器人的类型来优先化机 器人，例如，机器人可以排队等待而不是立即移动以进行充电，或者另一解决方案可以是特定类型的一组特定机器人(例如，铲车)可以首先 进行排队，其次是下一组机器人(例如，AGV)，并且之后是剩余的一组 机器人。可以生成的其它解决方案可以涉及基于库存订单(例如，同一 天订单)的优先级的机器人的订购，或者基于可以执行特定组的机器人 的类型或库存订单的相似性的库存订单的分组，机器人的能力，例如具 有比队列中的其它机器人更多的重量拣选能力等。与排序或优先化相关 的这种解决方案可以按照仓库所有者或机器人解决方案提供者给出的订 单履行标准而改变，或者也可以由库存订单本身驱动。基于由平台最终 确定的解决方案，应用备选计划或备选计划集合以及一个或多个任务分 配策略来替换当前计划或计划集合，以确保特定AMR或AMR集合可 以进行充电。类似地，需要被分配的任务集从新的计划集中被识别，然 后被分配在AMR队上。平台可以考虑附加因素，如机器人正在处理的 库存订单优先级、首先处理要充电的高优先级订单的机器人、拥塞或障 碍物避免、与团队或机群中的其它机器人的协调等。本发明不限于这些 实施例，并且范围广泛地包括使得平台能够识别用于更新一个或多个计 划和任务分配策略以获得所需的最优结果的相关解决方案的其它场景。

在其它实施例中，考虑用户情况场景，其中可针对充电计划跟踪平 台变量“系统停机时间”。平台必须在这种情况下决定哪个机器人可以首 先去并充电。最初，用户将充电过程中所涉及的总时间定义为要跟踪的 平台变量。这也可以是要测量的性能变量，其指示特定AMR或AMR 组在充电中花费的总时间，其可以转换为系统停机时间。对于系统管理 员或项目经理或仓库所有者，平台给出例如整个AMR机群的全局视图 以及整个仓库或整个驾驶路线的自动自驾车辆中的“充电”统计。这转 化为与用于“充电”计划的“系统停机时间”相关的信息。

在一个实施例中，DR模块产生的用于切换计划、任务分配策略和用 于决策的解决方案也可以基于机器人的不同角色来确定。对于特定机器 人(比如叉车)的导航计划，可能只有一个角色。然而，对于像Turtlesim 的机器人，可以有两个角色-引导者和跟随者。考虑其中平台可生成如上 所述的解决方案以将替换的一个或多个计划标识为现有计划的替换的场 景。在这种情况下，平台可以应用将机器人的新导航计划映射到叉车的 一般任务分配策略。现在，让我们考虑具有领导者角色和跟随者角色的 子LAN，而主要计划可以具有胖龟和瘦龟角色。因此，对于肥龟角色， 当平台将子LAN识别为用于替换现有计划的替代计划时，策略可以涉及 向对领导者角色具有较高亲和力因子而对随从者角色具有较低亲和力因 子的子LAN给予较高优先级。相反，对于瘦龟，当平台将子LAN识别 为替代计划时，则策略可以涉及考虑对跟随者角色比对领导者角色具有 更高亲和力因子的子LAN。因此，相应地，可以部署相关的一个或多个 计划和任务分配策略，并且可以分配相关的任务。这种决策使得平台基 于由平台在不同级别完成的角色映射和任务映射而具有鲁棒性和通用 性。

在一个实施例中，稳健且灵活的平台允许用户更有创造性，并根据 要求定义计划、任务分配策略。例如，考虑计划，并且用户可能喜欢跟 踪集中在任务上花费的时间的计划变量，所述任务例如等待路线、实际 导航花费的时间、行进的总距离的计数、导航完成的次数的计数、路径 偏离的次数-最大偏离、最小偏离、机器人必须旋转的次数。这些是开发者可能想要跟踪计划(例如导航计划)的特定部分的一些计划或任务分 配策略变量的示例。在向目录存储添加计划和/或任务分配策略时，用户 可以指定他们可能喜欢平台跟踪的变量，如本文所讨论的。

在本发明的一个实施例中，在用户指定平台变量之后，平台可能需 要开发者启用动态地决定新计划以替换较旧计划的特征。基于预定标准， 平台可以通知开发者同意她想要新计划动态地替换较旧计划。例如，当 在仓库中导航时，可能存在平台可以生成主动采取行动(例如，用于在 机器人的电池停用或跨过预定义阈值水平之前对机器人的电池充电的风 险减轻步骤)的解决方案或者根据来自用户的批准，跟踪平台变量以在 突破阈值时找到用于替换的替代或相关计划的场景。

在一个实施例中，考虑可以由DR模块生成的附加解决方案，用于 利用针对具有不同行为的机器人的替代计划来替换现有计划。DR模块可 以验证新的可选计划和任务分配策略是否支持或对准机器人的新的角色 或行为或能力。平台可以识别替换计划(例如导航)以替换AMR中的 现有计划。在现有规划中存在的规划变量值需要由新规划的规划变量并 且基于必须在其上部署新规划的AMR的类型来更新。例如，对于导航 计划，需要更新的计划变量之一可以是AMR的尺寸。当部署实际计划 时，必须动态地映射该信息。因此，当部署用于铲车的导航计划时，平 台必须确保计划与来自目录存储的兼容产品类型的适当映射。另一替代 计划可以是用于AMR类型的机器人的导航计划，其具有圆形轮驱动， 以被具有差动驱动的导航计划所替代，即使没有定义特定类型的机器人。

在一个实施例中，仓库所有者可以在从第三方开发者导入计划时指 示要跟踪的平台变量。该平台变量可以与计划“充电”相关，并且平台 变量可以是“时间”。这可以是需要被跟踪的关于机器人在被称为“充电” 的状态下花费了多少时间的性能变量。因此，仓库所有者可能对花费在 对机器人充电上的时间感兴趣，这可转化为系统停机时间。因此，这导 致系统停机时间和花费在非生产性任务上的时间，这对系统的整体性能 有影响。该平台提供了测量导致整个机群的生产性和非生产性活动的这 些类型的任务的方法，其可以在以后用于计算系统的每月或每季度的性 能。

在高层，平台提供机器人的总体状态和仓库中的充电统计的组合视 图。这种视图可由系统管理员或仓库管理员用来计算系统停机时间并采 取补救动作。考虑充电计划建立在任务分配策略上的情形，当电池电平 超过特定阈值(总电池电荷的10％)时，状态可以是“关键的”，并且机 器人可以被强制去并站立在充电队列中。另一种情况可以是当电池水平 “不是关键的”并且仓库中的工作负荷也是最小的。为作出充电决定而 生成的各种解决方案可以如下给出：

a)如果电池电量处于“临界”状态，则将任务更新为“排队充电”；

b)如果工作负荷最小并且电池水平不处于“临界”状态，则充电任 务可以被扩充为“是”，并且如果电池水平达到“临界”状态，则机器人 的任务可以被更新为“排队并充电”。

c)替代解决方案可以是更新任务以推送主动充电。因此，即使电池 水平不处于“临界”状态(即电池水平低于10％)，但仓库中的工作负荷 低，则系统不能预见更多的任务进入。在这种情况下，任务可以被更新 为“机器人可能仍然前进并且排队进行充电'

d)状态不是“临界”，并且基于工作负荷(低、中或高)，平台决定 哪个机器人可以去并且充电。该策略可以包括机器人的类型和构造(例 如，叉车模型对AGV模型)等。

因此，如果考虑这里生成的解决方案，“充电”的实际行为是相同的， 然而，需要被利用来做出决定的解决方案随着上下文、环境、机器人硬 件和机器人的状态而变化。因此，一旦DR模块接收到通知或被触发， DR模块就分析由计划执行引擎或AMR共享的平台变量或信息，然后， DR模块意识到需要基于所讨论的各种解决方案来替换计划“充电”。在 一个实施例中，任务还可以基于解决方案而被分配在机器人上。现在， 平台要做出的决定可以是生成一个或多个特定解决方案，该解决方案取 决于关于仓库如何操作、其工作时间(上午9点-下午5点或夜班)、客 户对要实现的这种场景的要求的各种功能。例如，可以根据客户对自动 化过程的需要来调整解决方案。另外，在正常工作日，如果仓库中的工 作负荷正常，则由平台最终确定和生成的充电任务分配策略可以是解决 方案(c)，其中平台通过实施充电任务和部署的计划以确保机器人被排 队以进行充电，来采取风险减轻步骤或灾难预防或用于最佳性能度量。

在本发明的其它实施例中，客户可能希望(a)每当与“充电”场景 相关的情况出现时为平台生成默认解决方案以进行选择，其中客户可能 喜欢机器人继续在仓库中工作，直到电池越过阈值水平或临界阶段。要 调用的这种默认解决方案可能具有其后果，如减少电池寿命或机器人的 其它磨损。类似地，平台可以生成的其它替代解决方案可以是，客户可以认为，由于充电时隙在仓库中是有限的，因此在较低工作负荷期间， 最佳解决方案可以是解决方案(b)。平台生成解决方案，基于解决方案 检索相关计划，应用更新的计划，并在机器人上部署更新的计划。可以 更新任务以强制机器人如DR模块生成的解决方案(b)中所定义的那样 排队和充电。在该解决方案中，机器人不等待达到临界电池水平，而是 使用由客户指定的其它预定平台变量来确保要分配的任务将是机器人在 给定的槽内主动地充电。

在一个实施例中，关于何时进行和何时充电做出的动态决定本身还 取决于其它平台变量，如AMR和/或云设备系统所经历的库存工作负荷、 充电时隙定时、充电时隙可用性等。此外，在AMR上运行的计划执行 引擎可以在一段时间内导航它们，并且基于机器人的性能来决定应用哪 种解决方案以及哪种解决方案在仓库中工作。这种方法可能更像是机器 人看到性能并测试替代解决方案的“学习”机制。AMR和/或云设备系 统比较性能，并且该学习帮助DR模块自动适应变化的场景以选择最优 解决方案。这里考虑的场景不是限制性的，因为如这里所讨论的，决策 的做出可以涉及来自云节点的协作努力以及AMR。

在一个实施例中，平台可以移除充电计划，并且基于最优解决方案 用替代计划来替换它，如本文所讨论的。因此，可以被跟踪的平台变量 之一可以是“总系统停机时间”，同时决定机器人在充电期间花费时间或 等待充电的最优解决方案。基于所监视的事件，DR模块可被触发以采取 行动，因此，平台可决定如本文所讨论的新的充电任务分配策略。平台分析每个任务分配策略的性能，并且如果存在性能的降低，则基于比较 来识别最佳任务分配策略。在本发明的实施例中，考虑与导航或充电计 划有关的场景。用户可能希望实施X策略、Y策略或X、Y和Z策略的 组合，其可以是可插入的或在仓库中的工作日期间选择的。对于这些情 形，平台可以从来自任务分配目录的各种可用任务分配策略中挑选任务 分配策略。此外，该平台还向用户提供模拟的选项，其中真实机器人正 在对实际库存订单进行模拟。用户可以基于模拟批准一些任务分配策略。 DR模块监控任务分配策略和机器人的性能，生成最优运行的任务分配策 略，以便考虑该策略来提高整体性能。

在一个实施例中，在得出特定决定之前，可以考虑其它可能的解决 方案。考虑有一队AMR导航的场景。当平台连续地监视性能和行为时， 平台可以观察机器人等待另一个机器人或一组机器人通过所花费的时 间。因此，为了减少低效率或系统停机时间，DR模块可以主动地分析平 台变量、通知信息、从机器人接收的信息，并且生成最优解以避免碰撞或拥塞最小化或系统停机时间的情况。在一个实施例中，DR模块生成解 决方案，该解决方案可以包括识别新计划和任务分配策略以解决操作环 境中的运行时事件。因此，为了避免碰撞，可以生成的解决方案可以是 (a)机器人之一可以停止，而另一机器人可以经过，这与交通信号非常 类似，(b)可能不需要在特定点处停止，但是机器人在接近碰撞路线时 可以减慢，而另一机器人或另一组机器人可以加快。这里，可以考虑的 平台变量可以是“速度”，其可以给出基于速度的差异机器人可以简单地 彼此经过的指示，(c)外部因素可以在决策中起作用，例如在仓库类型 的环境、仓库布局和特定因素(WiFi连接、电源负载、导航时的照明问 题、用于更好导航的基础设施定制等)中，平台可以考虑各种场景、历 史趋势、上下文、计划和/或任务分配策略之间的兼容性问题、诸如仓库 环境因素的窄特征、机器人行为或能力或角色等来考虑适当的解决方案。

在一个实施例中，该平台解决仓库所有者、解决方案提供商和客户 面对的实时问题，例如促销、1天或几小时的销售报价等。在这种情况 下，仓库接收大量的库存订单，或者可能存在请求激增。这些不是可以 全年跟踪的常规场景。这些报价可以在短时间内提供给用户，因此订单 履行任务可能太麻烦、复杂并且需要实时决策。在此期间，仓库面临任 务的尖峰，导航地图的剧烈变化导致拥堵，叉车走更长的绕路，机器人 花费太多时间充电等。从平台的角度来看，平台变得自我感知，因为这 反映在平台变量的变化中，因此系统需要适应该变化。为了适应这种变 化，平台生成最终导致指示在AMR上运行的计划执行引擎进行切换并 考虑新计划的解决方案。例如，系统可能必须基于所生成的策略来找到 替代计划，比方说用于减少机器人的自旋转向或机器人必须采取的定向、 制定更好的导航计划、更好的库存订单分配计划等，以解决请求中的突 然尖峰。

在一个实施例中，平台将请求中的这些尖峰视为已经遇到并且已经 处理的问题。平台寻找在作为目录存储的一部分的计划目录和任务分配 目录中可用的替换计划和任务分配策略。这些替代计划基于一个或多个 解决方案来识别，或者基于历史计划变量，如任务分配策略如何与其它 机器人(例如叉车)一起执行，或者特定任务分配策略如何与不同类型 仓库中的其它机器人一起工作。平台自动执行这些任务，并且将计划标 记为称为“积极”的模式。在这种模式下，系统优化任务以减少系统停 机时间并确保一切都在工作。

在一个实施例中，系统检测到存在低工作负荷或者对于接下来的几 个小时，库存订单较少，并且因此，平台智能地生成用于优化以避免机 器人的部件的磨损和撕裂的解决方案。如本文所讨论的，平台可以基于 平台、计划和任务分配策略变量之一与预定标准或阈值之间的比较来识 别最优解决方案。平台还可以考虑历史平台变量和客户定义的平台变量， 如本文所讨论的。平台可以确保替代计划被识别以对抗可能满足或可能 不满足阈值。例如，电池充电基线计划变量可以是总电池电平的10％。 在识别用于最佳性能的备选或更好的计划时，平台可以确保所识别的计 划具有基于最佳解决方案的计划变量，该最佳解决方案是基于所分析的 平台变量和预定标准之间的比较而生成的，如本文所讨论的。

在一个实施例中，平台可能必须面对诸如故障或仓库的不同层之间 的移动(例如，从底层到第一层)的场景。DR模块可以考虑包括任务优 化的策略，例如在导航期间的岔口上升停机时间。在其它类似的情况下， DR模块可以考虑避免机器人的磨损和破损，并且可以优化机器人所进行 的自旋转向，或者可以希望优化机器人以等待并获得更好的路径用于导 航。这可以通过包括如本文所讨论的性能计划变量或阈值来完成。当DR 模块正在监视AMR群时，DR模块保持跟踪平台变量，并且当DR模块 观察到某个计划变量的性能被报告为低于阈值时或者如果存在故障，则 DR模块被通知采取紧急措施。应该理解，DR模块可以由于平台、计划 或任务分配策略变量的阈值的破坏而得到通知，如这里所讨论的。在这种情况下，机器人可能不能恢复其自身，然后，DR模块从任务分配目录 中提取相关的备选任务分配策略。例如，目标之一是优化导航计划选项 并提取代理的计划，比如AGV或叉车类型，并确保计划与可能需要恢复 的当前机器人的计划兼容。在此，在一个实施例中，平台跟踪已经比当 前由在AMR和/或云节点上运行的一个或多个计划执行引擎执行的计划 执行得更好的计划。平台应用实时检索高性能计划的任务分配策略，并 且部署它们并继续监视它们的性能。

在一个实施例中，考虑存在混合机器人组，例如AGV和叉车，并且 导航计划正在被执行的情形。在设计时，用户可以提及AGV或叉车的计 数或者可以执行计划的不同类型的机器人。在定义计划时，平台也可以 从目录存储中拉取代理目录以指示在特定团队中可能存在两种特定类型 的机器人，而不是仅仅拉取计划以供导航。在叉车的情况下，则计划变量可以被定义为叉车尺寸、转弯半径、叉车最大容量等。导航计划和代 理目录给予平台关于如何部署机器人以及可以设置什么约束的灵活性。 例如，代理目录可以帮助缩小搜索范围并且指示由于铲车是单个车轮供 电的并且具有特定的转弯半径，所以导航计划可以进一步指示机器人是 否可以原地旋转。当可以部署两种不同类型的机器人(AGV和叉车)时，可以动态地映射这些计划变量。当部署机器人时，自动映射计划变量。 现在，在一个实施例中，DR模块可以生成解决方案，因为导航计划将进 入叉车，所以机器人不能进行原地导航，并且确保计划变量根据该定义 被映射。因此，平台检索准确的计划，准确地映射计划变量，并且根据 计划决定将它们部署在特定机器人上。

在一个实施例中，已经部署的每个计划和任务分配策略可以具有变 量，DR模块检查这些变量以验证是添加还是移除新的能力，以采取步骤 来寻找替代方案。类似地，在机器人的生命周期期间发生的许多事件可 能需要DR模块的立即或预定的注意。这些事件可以从能力的改变、一 个或多个机器人的添加、硬件/软件的故障、仓库基础设施的改变、导航 问题、充电问题、空前的、新的或历史的问题等而变化。本发明的范围 不受限制，并且可以包括可能在异构设备的工作环境中出现的其它事件， 这些事件可能需要DR模块的注意，并且在更高级别上需要设备平台的 注意。

在一个实施例中，考虑以下与在操作环境中生成用于处理实时场景 的过程的解决方案的复杂性有关的细节。给定X个任务，DR模块的任 务可以是对机器人的数量进行计数，并且基于最小化要行进的距离来分 配任务。考虑有10个任务和5个机器人，则第一步骤可以是挑选最初要 分配给5个机器人的5个任务。问题是它们可以以什么顺序被拾取。可以实现的复杂任务分配策略是他们可以采取以最小化所花费的总时间的 路线上的“旅行商问题”，或者考虑可以将机器人分配给最近的拾取任务 的更简单的任务分配策略。然后，另一任务分配策略可以是在整晚可能 存在要处理的1000个任务，因此，任务分配策略可以是在批处理级别而 不是在任务级别优化。因此，在一个实施例中，解决方案可以基于手头的任务而不同。因此，在一个实施例中，为了选择适当的任务分配策略， 因素之一可以是计算机器人可以处理的最大负载因子。可以存在处理 1000个机器人的一些任务分配策略；由于可能存在4000或更多订单(4 个订单/机器人)，并且优化可能是复杂的任务，因此进行整个批次的连 续每秒计算是不可行的。可以实现的另一任务分配策略可以在机器人的 类型之间进行区分。因此，该解决方案可以涉及使AGV和叉车一起工作 并以1:1的因子被分配到同一任务。因此，每个任务可以具有1个AGV 和1个被分配来处理该任务的叉车。然后，任务分配策略可以包括当AGV 处于初始状态(AGV接近拾取位置)时分配另一叉车，并且当AGV到达最终状态时，即AGV到达目的地以便放下时，要分配的叉车执行到达 目的地的任务。

因此，第一任务分配策略可以是机器人之间没有区别的一般化策略， 因此，该任务分配策略所支持的角色可以被表示为“*”表示，这意味着 所有机器人都被支持，如先前所公开的。在一个实施例中，任务分配策 略之一可以是仅支持两种类型的机器人AGV和叉车来执行任务。然而， 如果在仓库的区域中存在拣选辅助AMR，则DR模块的所生成的解决方案包括在包括一组AGV和叉车的机群中登上拣选辅助AMR。因此，DR 模块扫描以从任务分配目录中识别涉及要一起工作的挑选辅助AMR和 ARM的任务分配策略。一旦找到了这样的任务分配策略，则所识别的任 务分配策略可以与仅对AGV和叉车起作用的其它任务分配策略一起使 用。利用这种解决方案，DR模块可以在完全不同类型的机器人之间实施 协作，所述机器人例如AGV、叉车和已经扩展到ARM能力的拾取辅助 AMR。这使得平台对于在操作环境(如仓库)中遇到的任何种类的运行 时场景是可定制和稳健的。

在一个实施例中，任务分配策略可以指示导航计划可以支持可以移 动的所有AMR。通常，由于这些问题中的一些是NP难题，所以不能保 证找到最佳解决方案，因此，给定时间帧，所获得的最佳解决方案被认 为是DR模块考虑计划和/或任务分配策略时所选择的解决方案。因此， 为了找到最佳解决方案，除了本文讨论的因素之外，其它因素可以包括截止时间、预期的、任务分配策略基于其所针对的规模通常采取多少、 或者假设最大负载因子是否为100，然后任务分配通常消耗多少时间等。

在一个实施例中，计划可以包括多个状态，例如100个状态。该平 台提供了允许用户定义在设计时是否必须跟踪每一状态或特定状态集的 特征。该平台还允许用户在部署后推回决策，同时AMR例如在仓库中 导航。用户一般可以说在计划执行时或在导航期间或部署后的任何时间 需要跟踪所有状态。默认地，平台跟踪通用平台变量或特定计划或任务分配策略变量。对于该跟踪，用户可以启用计划中的特定平台变量。通 用平台变量可以是“机器人在计划中花费了多少时间？”或“执行引擎 在执行计划中花费了多少时间？或者”执行引擎在计划的特定状态中花 费了多少时间？如这里所讨论的，一般计划变量可以是可应用于所有计 划或任务分配策略的变量，例如导航或充电计划或拣选或分类任务等。 平台将这些变量暴露给用户或开发者，用户或开发者可以稍后指定需要 由DR模块跟踪特定的或一组通用计划变量。对于行为或计划特定变量， 变量中的一些可以是“在导航时，进行了多少次转弯？”或“机器人应 该遵循的路径偏离多少次？在一个实施例中，为了跟踪计划特定变量， 平台可以期望用户在开始时专门进行配置，否则平台可能不能跟踪任何 计划特定变量。

在一个实施例中，平台变量的跟踪在两个级别上完成，即在机器人 级别上或在平台级别上的更高级别上。在机器人级别，机器人仍然需要 收集更低级别的细节，因为它具有机器人行为的更多上下文。对于机器 人所做出的每个决定，所有细节不一定被传输到云设备系统，因为这可 能导致要在云设备系统级分析的巨大数据。因此，在导航时，当机器人转动或移动或停止时，机器人具有粒度级细节，而细节的抽象级被传达 到云设备系统。因此，第一级跟踪总是发生在机器人级。这里，最初， 可以被跟踪的变量被传送到机器人。这些变量也由云设备系统的DR模 块跟踪。因此，机器人以及云设备系统两者都增强了彼此跟踪变量的能 力。因此，云设备系统的DR模块从所述一组异构机器人接收所述变量 的值。跨异构机器人运行的计划执行引擎对机器人变量进行处理，以与 云设备系统的DR模块共享值以用于其处理。DR模块必须感测由各个机 器人报告的变量的所有值。考虑一组10个异构机器人，并且特定机器人 违反预定阈值标准，并且这被通知给云设备系统的DR模块。DR模块然 后分析该通知以生成更新计划或任务分配策略的解决方案。在一个实施 例中，由于平台的目标之一是多机器人协调，并且机器人组充当团队， 因此，可以完成的任何任务分配是针对整个机器人团队完成的。因此， DR模块确保在机器人团队之间存在同步，并且每个机器人知道可以执行 哪个任务。不仅针对特定机器人，而且针对整个机器人更新新计划，使 得群组内的每个机器人作为团队工作，并且使得平台能够确保多机器人 协调。考虑一个示例，在一组AMR内，有一个AMR获取新的能力， 比如AGV获取臂能力。AGV仍然必须与AMR组一起工作。现在，如 果DR模块仅为获得该能力的AGV替换计划，则难以维持多机器人协调。 因此，DR模块通过允许每个团队成员根据他们的能力执行任务来确保多 机器人协调。因此，为了实现这个组级别的能力，DR模块可以在异构设 备组上推进计划的更新以及任务分配策略的部署。

在一个实施例中，考虑要为上述示例实现的任务分配策略。所生成 的任务分配策略可以考虑到由机器人队列中的机器人所获得的新能力的 这种变化，尽管基于所生成的解决方案向团队分配了相同的任务，然而， 已经获得新能力的机器人被优先化，例如，AGV已经获得手臂能力或者 与穿梭车或手推车对准，可以优先于其它机器人来执行任务。这样，平 台确保了不同类型的机器人之间的多机器人协调。这需要协作方法，其 中在机器人和云设备系统的DR模块之间存在消息通信以处理这样的场 景。

例如，计划“充电”可以具有平台变量，如“在特定类型的机器人 (例如，叉车)上花费了多少时间？”或“机器人何时在导航，它进行 了多少次转弯，或者它旋转了多少次或者机器人进行了旋转-转弯？考虑 路线导航的另一场景，机器人可能正在进行较低的第一次转弯，然后关 闭过道。因此，在计算路径时，平台可基于路径的距离进行计算，并且 不会不利于机器人在不同阶段中旋转。这些阶段在导航时可以是90度转 弯，并且可以是相当大的。因此，开发者或用户可以使用一般级别的计 划变量定义或非常具体级别的细节来跟踪。在本发明的一个实施例中， 用户还具有输出关于每个AMR或AMR组的被跟踪的计划变量的状态、 性能、终端状态更新的报告的选项，或者可以在用户界面中查看。

在一个实施例中，在部署的计划之后，平台可以监视一队AMR，并 且可以生成对于仓库中的当前应用而言可行的或者更有效的解决方案， 如果AMR执行特定任务-例如跟随仓库中的人，或者在另一场景中，机 器人可能不在四处移动而是在特定位置等待人到来和放置要放下的对 象。因此，在后一种情况下，DR模块可以决定从计划中拉出机器人。与 人机器人协调、将机器人从任务中拉出、任务分配相关的所有这些功能 由平台来处理。

在一个实施例中，在计划和任务分配策略的建模期间，用户或开发 者可以选择各种平台变量以影响在运行时采取决策的方式。然而，在一 些情况下，最终决定可以由云设备系统引擎来决定，例如，在诸如AMR 的电池电平低于临界阈值403的场景中，然后，将优先级计划变量设置 为“高”的充电计划部署在AMR上，以确保AMR可以对接到电池接 口并且被再充电。

在一个实施例中，平台的验证模块可以确定部署请求是否在特定设 备(AGV或叉车)上，并且对于导航计划，确定导航栈是否被装载在设 备上并且相关的平台变量被检查。在另一个实施例中，平台包括兼容性 模块，以验证计划的兼容性得分。例如，当替代计划被识别为在设备上 运行的现有计划的替代时，基于用于特定机器人组(AGV)的计划是否 也与另一类型的机器人(例如叉车)兼容来计算兼容性得分。平台还可 以验证计划的功能(例如导航)是否也与当前类型的机器人(叉车)兼 容。另一兼容性得分计算可以基于该计划是否被较早版本的计划执行引 擎支持。例如，计划执行的较早版本可以是版本1.5，而计划执行引擎的 新版本可以是2.0。兼容性得分可具有基于不同模型的评分机制。模型之 一可以具有+1到5或-1到-5的范围。正的分数指示计划是兼容的，并且 可以是在设备上运行的现有计划的替代。较高的正分数可以指示平台可 以基于如本文所讨论的计划变量而具有对新计划的较高批准评级，而不 限于流行度、成功率、在类似场景中的有效运作等。负分可以指示不兼 容性，并且该分也可以对变化的设备类型具有更高的负评级，这可以指 示当设备类型偏离一般功能或规范等时计划是不兼容的。

应当理解，上述实施例仅仅是可以构成本发明原理的应用的许多和 各种其它实施例的说明。本领域技术人员可以容易地设计出这些其它实 施例，而不脱离本发明的精神或范围，并且我们的意图是将它们视为在 本发明的范围内。

上述图表示用于描述根据一些实施例的过程的逻辑架构，并且实际 实现可以包括以其它方式布置的一个或多个组件。其它拓扑可以与其它 实施例结合使用。此外，本文描述的每个组件或设备可以由经由任何数 量的其它公共和/或专用网络进行通信的任何数量的设备来实现。两个或 多个这样的计算设备可以彼此远离，并且可以经由任何已知方式的网络 和/或专用连接彼此通信。每个组件或设备可以包括适于提供这里描述的 功能以及任何其它功能的任何数量的硬件和/或软件元件。例如，在根据 一些实施例的系统的实现中使用的任何计算设备可以包括执行程序代码 的处理器，使得计算设备如本文所述地操作。

这里讨论的所有系统和过程可以体现为从一个或多个非暂时性计算 机可读介质读取的程序代码，所述非暂时性计算机可读介质诸如软盘、 CD-ROM、DVD-ROM、闪存驱动器、磁带和固态随机存取存储器(RAM) 或只读存储器(ROM)存储单元，并且然后以压缩、未编译和/或加密格 式存储。在一些实施例中，可以使用硬连线电路来代替或结合用于实现 根据一些实施例的过程的程序代码。因此，实施例不限于硬件和软件的 任何特定组合。

图1-6中的流程图和框图示出了根据本公开的各个方面的系统、方 法和计算机程序产品的可能实现的架构、功能和操作。在这点上，流程 图或框图中的每个框可以表示代码的模块、段或部分，其包括用于实现 指定的逻辑功能的一个或多个可执行指令。还应当注意，在一些备选实 现中，框中所标注的功能可以不按图中所标注的顺序发生。例如，连续示出的两个框实际上可以基本上同时执行，或者这些框有时可以以相反 的顺序执行，这取决于所涉及的功能。还将注意，框图和/或流程图图示 的每个框以及框图和/或流程图图示中的框的组合可以由执行指定功能 或动作的基于专用硬件的系统或专用硬件和计算机指令的组合来实现。

本文所使用的术语仅用于描述特定方面的目的，而不旨在限制本公 开。如本文所用，单数形式“一”、“一个”和“该”旨在也包括复数形 式，除非上下文另有明确指示。还将理解，术语“包括”和/或“包含” 在本说明书中使用时，指定所陈述的特征、整数、步骤、操作、元件和/ 或组件的存在，但不排除一个或多个其它特征、整数、步骤、操作、元 件、组件和/或其群组的存在或添加。

以下权利要求中的任何装置或步骤加功能元件的对应结构、材料、 动作和等效物旨在包括用于与如具体要求保护的其它要求保护的元件组 合执行功能的任何公开的结构、材料或动作。已经出于说明和描述的目 的呈现了本公开的描述，但是其不旨在是穷尽的或限于所公开的形式的 公开。在不背离本公开的范围和精神的情况下，许多修改和变化对于本 领域普通技术人员将是显而易见的。选择和描述本公开的方面以便最佳 地解释本公开的原理和实际应用，并且使得本领域的其它普通技术人员 能够理解具有适合于所设想的特定使用的各种修改的本公开。

本文描述的实施例仅用于说明目的。本领域技术人员将认识到，可 以对上述实施例进行修改和变更来实践其它实施例。