特開2022-33095プラン及びタスク割り当て戦略を更新するためのソリューションの動的な生成
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022033095
(43)【公開日】2022-02-28
(54)【発明の名称】プラン及びタスク割り当て戦略を更新するためのソリューションの動的な生成
(51)【国際特許分類】
G06Q 10/08 20120101AFI20220218BHJP
G06Q 10/04 20120101ALI20220218BHJP
【ＦＩ】
G06Q10/08
G06Q10/04
【審査請求】有
【請求項の数】15
【出願形態】ＯＬ
(21)【出願番号】P 2021044300
(22)【出願日】2021-03-18
(31)【優先権主張番号】16/994,556
(32)【優先日】2020-08-15
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】517175046
【氏名又は名称】ラピュタロボティックス株式会社
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】アビシェーク シャルマ
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049AA04
5L049AA16
(57)【要約】 （修正有）
【課題】既存のプラン及び既存のタスク割り当て戦略を更新するソリューションを動的に生成する。
【解決手段】方法は、クラウド及び複数の異種の自律モバイル装置のうちの少なくとも１つ以上のプラン及びタスク割り当て戦略を動的に更新する。システム又はプラットフォームは、様々なイベントを内部及び外部にて継続的に監視する。プラットフォームは、既存のプラン及びタスク割り当て戦略の更新又は置き換えの必要性の通知又はトリガを分析し、様々な要因に応じてソリューションを生成し、更新が必要である関連プラン及びタスク割り当て戦略を特定する。生成されたソリューションに基づき、既存のプラン及び割り当てられたタスク割り当て戦略を更新又は置き換える。プラン及びタスク割り当て戦略の更新が行われると、プラットフォームは更新したプラン及びタスク割り当て戦略をクラウド及び複数の異種の自律モバイル装置のうちの少なくとも１つ以上に展開する。
【選択図】図３
【解決手段】方法は、クラウド及び複数の異種の自律モバイル装置のうちの少なくとも１つ以上のプラン及びタスク割り当て戦略を動的に更新する。システム又はプラットフォームは、様々なイベントを内部及び外部にて継続的に監視する。プラットフォームは、既存のプラン及びタスク割り当て戦略の更新又は置き換えの必要性の通知又はトリガを分析し、様々な要因に応じてソリューションを生成し、更新が必要である関連プラン及びタスク割り当て戦略を特定する。生成されたソリューションに基づき、既存のプラン及び割り当てられたタスク割り当て戦略を更新又は置き換える。プラン及びタスク割り当て戦略の更新が行われると、プラットフォームは更新したプラン及びタスク割り当て戦略をクラウド及び複数の異種の自律モバイル装置のうちの少なくとも１つ以上に展開する。
【選択図】図３
【特許請求の範囲】
【請求項1】
クラウド及び複数の異種の自律モバイルロボットのうちの少なくとも１つ以上で展開される１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を動的に更新するコンピュータ実装方法であって、
クラウド及び複数の異種の自律モバイルロボット上での少なくとも１つ以上のイベントを監視することと、
前記監視することに基づいて、１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を更新のために分析することと、
１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を更新のために、前記分析することに基づいて１つ以上のソリューションを生成することと、
生成された前記１つ以上のソリューションに基づいて、１つ以上のプラン及び１つ以上のタスク割り当て戦略を特定することと、
前記１つ以上の既存のプランを特定された１つ以上のプランで更新し、前記１つ以上の既存のタスク割り当て戦略を特定された１つ以上のタスク割り当て戦略で更新することと、
更新された前記１つ以上のプラン及び更新された前記１つ以上のタスク割り当て戦略を、前記クラウド及び前記複数の異種の自律モバイルロボットのうちの少なくとも１つ以上に展開することと、
を含むコンピュータ実装方法。
クラウド及び複数の異種の自律モバイルロボット上での少なくとも１つ以上のイベントを監視することと、
前記監視することに基づいて、１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を更新のために分析することと、
１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を更新のために、前記分析することに基づいて１つ以上のソリューションを生成することと、
生成された前記１つ以上のソリューションに基づいて、１つ以上のプラン及び１つ以上のタスク割り当て戦略を特定することと、
前記１つ以上の既存のプランを特定された１つ以上のプランで更新し、前記１つ以上の既存のタスク割り当て戦略を特定された１つ以上のタスク割り当て戦略で更新することと、
更新された前記１つ以上のプラン及び更新された前記１つ以上のタスク割り当て戦略を、前記クラウド及び前記複数の異種の自律モバイルロボットのうちの少なくとも１つ以上に展開することと、
を含むコンピュータ実装方法。
【請求項2】
前記既存のプラン及び既存のタスク割り当て戦略を更新のために分析することは、
前記異種の自律モバイルロボットのうちの１つ以上が新たな能力を獲得したことを示す受信した通知を分析することと、
生成された１つ以上のソリューションを獲得された前記新たな能力に対して調整することと、
調整された前記１つ以上のソリューションに基づいて、１つ以上の新たなプラン及び１つ以上の新たなタスク割り当て戦略を特定することと、
を含む、請求項１に記載のコンピュータ実装方法。
前記異種の自律モバイルロボットのうちの１つ以上が新たな能力を獲得したことを示す受信した通知を分析することと、
生成された１つ以上のソリューションを獲得された前記新たな能力に対して調整することと、
調整された前記１つ以上のソリューションに基づいて、１つ以上の新たなプラン及び１つ以上の新たなタスク割り当て戦略を特定することと、
を含む、請求項１に記載のコンピュータ実装方法。
【請求項3】
特定された前記１つ以上の新たなプランが１つ以上の既存のプランと互換性があり、特定された１つ以上の新たなタスク割り当て戦略が１つ以上の既存のタスク割り当て戦略と互換性があるかを検証することと、
前記検証することに基づいて、特定された前記新たなプランのプラン変数及び特定された前記新たなタスク割り当て戦略のタスク割り当て戦略変数に新たな値をマッピングすることと、
をさらに含む、請求項２に記載のコンピュータ実装方法。
前記検証することに基づいて、特定された前記新たなプランのプラン変数及び特定された前記新たなタスク割り当て戦略のタスク割り当て戦略変数に新たな値をマッピングすることと、
をさらに含む、請求項２に記載のコンピュータ実装方法。
【請求項4】
前記１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を更新のために１つ以上のソリューションを生成することは、
１つ以上の自律モバイルロボットに関連するプラットフォーム変数、プラン変数及びタスク割り当て戦略変数のうちの少なくとも１つ以上の１つ以上の値を閾値と比較することと、
１つ以上の自律モバイルロボット上に展開されているプラン及びタスク割り当て戦略を更新するために、前記比較することに基づいて新たなプラン及び新たなタスク割り当て戦略を特定することと、
特定された新たなプランの変数及び特定された新たなタスク割り当て戦略の変数に新たな値をマッピングすることと、
を含む、請求項１乃至３のいずれか一項に記載のコンピュータ実装方法。
１つ以上の自律モバイルロボットに関連するプラットフォーム変数、プラン変数及びタスク割り当て戦略変数のうちの少なくとも１つ以上の１つ以上の値を閾値と比較することと、
１つ以上の自律モバイルロボット上に展開されているプラン及びタスク割り当て戦略を更新するために、前記比較することに基づいて新たなプラン及び新たなタスク割り当て戦略を特定することと、
特定された新たなプランの変数及び特定された新たなタスク割り当て戦略の変数に新たな値をマッピングすることと、
を含む、請求項１乃至３のいずれか一項に記載のコンピュータ実装方法。
【請求項5】
新たな自律モバイルロボットの新たな能力を、１つ以上の異種の自律モバイルロボットに拡大することであって、該新たな自律モバイルロボットは異なる種類のロボットである、ことと、
前記新たな能力と互換性がある１つ以上の新たなプラン及び１つ以上の新たなタスク割り当て戦略を特定することと、
前記特定されたプラン及び特定されたタスク割り当て戦略を前記１つ以上の異種の自律モバイルロボット上に展開することと、
をさらに含む、請求項１乃至４のいずれか一項に記載のコンピュータ実装方法。
前記新たな能力と互換性がある１つ以上の新たなプラン及び１つ以上の新たなタスク割り当て戦略を特定することと、
前記特定されたプラン及び特定されたタスク割り当て戦略を前記１つ以上の異種の自律モバイルロボット上に展開することと、
をさらに含む、請求項１乃至４のいずれか一項に記載のコンピュータ実装方法。
【請求項6】
前記展開されたプラン及び前記展開されたタスク割り当て戦略を更新するために、プランカタログ及びタスク割り当てカタログを検索して新たなプラン及び新たなタスク割り当て戦略をそれぞれ見つけることと、
エージェントカタログを用いて、前記プランカタログ及び前記タスク割り当てカタログの検索を狭めることと、
前記狭めることに基づいて、前記新たなプラン及び前記新たなタスク割り当て戦略を特定することと、
プランレベル及びタスク割り当て戦略レベルのうちの少なくとも１つ以上でマッピングを行うべきか判定することと、
前記判定することに基づいて、前記特定されたプラン及び前記特定されたタスク割り当て戦略の静的変数及び一時変数のうちの少なくとも１つ以上に新たな値をマッピングすることと、
をさらに含む、請求項１乃至５のいずれか一項に記載のコンピュータ実装方法。
エージェントカタログを用いて、前記プランカタログ及び前記タスク割り当てカタログの検索を狭めることと、
前記狭めることに基づいて、前記新たなプラン及び前記新たなタスク割り当て戦略を特定することと、
プランレベル及びタスク割り当て戦略レベルのうちの少なくとも１つ以上でマッピングを行うべきか判定することと、
前記判定することに基づいて、前記特定されたプラン及び前記特定されたタスク割り当て戦略の静的変数及び一時変数のうちの少なくとも１つ以上に新たな値をマッピングすることと、
をさらに含む、請求項１乃至５のいずれか一項に記載のコンピュータ実装方法。
【請求項7】
異なる種類の新たな自律モバイルロボットが一群の複数の異種の自律モバイルロボットに加わったとの通知を分析することと、
前記通知を分析することに基づいて、前記１つ以上の追加のソリューションを生成することと、
生成された前記追加のソリューションに基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、
前記異なる種類の新たな自律モバイルロボットのために前記新たなプラン及び新たなタスク割り当て戦略のプラン変数に新たな値をマッピングすることと、
前記異なる種類の自律モバイルロボット上に前記新たなプラン及び前記新たなタスク割り当て戦略を展開することと、
をさらに含む、請求項１乃至６のいずれか一項に記載のコンピュータ実装方法。
前記通知を分析することに基づいて、前記１つ以上の追加のソリューションを生成することと、
生成された前記追加のソリューションに基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、
前記異なる種類の新たな自律モバイルロボットのために前記新たなプラン及び新たなタスク割り当て戦略のプラン変数に新たな値をマッピングすることと、
前記異なる種類の自律モバイルロボット上に前記新たなプラン及び前記新たなタスク割り当て戦略を展開することと、
をさらに含む、請求項１乃至６のいずれか一項に記載のコンピュータ実装方法。
【請求項8】
前記自律モバイルロボットのうちの少なくとも１つ以上に関連する親和性要因を決定することと、
決定された前記親和性要因に基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、
特定されたプラン及び特定されたタスク割り当て戦略で前記展開されたプラン及び展開されたタスク割り当て戦略を更新することと、
前記自律モバイルロボットのうちの１つ以上に前記更新されたプラン及び更新されたタスク割り当て戦略を展開することと、
をさらに含む、請求項１乃至７のいずれか一項に記載のコンピュータ実装方法。
決定された前記親和性要因に基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、
特定されたプラン及び特定されたタスク割り当て戦略で前記展開されたプラン及び展開されたタスク割り当て戦略を更新することと、
前記自律モバイルロボットのうちの１つ以上に前記更新されたプラン及び更新されたタスク割り当て戦略を展開することと、
をさらに含む、請求項１乃至７のいずれか一項に記載のコンピュータ実装方法。
【請求項9】
自律モバイルロボット及びクラウド上で実行される少なくとも１つ以上のプラン実行エンジンからの通知を分析することと、
前記通知を分析することに基づいて、前記自律モバイルロボット上で実行される既存のプラン及び既存のタスク割り当て戦略が新たな挙動をサポートするかを検証することと、
前記検証することに基づいて、前記新たな挙動をサポートする新たなプラン及びタスク割り当て戦略を特定することと、
前記自律モバイルロボットのために、前記特定されたプランの新たなプラン変数に新たな値をマッピングし、前記特定されたタスク割り当て戦略の新たなタスク割り当て戦略変数に新たな値をマッピングすることと、
を含む、請求項１乃至８のいずれか一項に記載のコンピュータ実装方法。
前記通知を分析することに基づいて、前記自律モバイルロボット上で実行される既存のプラン及び既存のタスク割り当て戦略が新たな挙動をサポートするかを検証することと、
前記検証することに基づいて、前記新たな挙動をサポートする新たなプラン及びタスク割り当て戦略を特定することと、
前記自律モバイルロボットのために、前記特定されたプランの新たなプラン変数に新たな値をマッピングし、前記特定されたタスク割り当て戦略の新たなタスク割り当て戦略変数に新たな値をマッピングすることと、
を含む、請求項１乃至８のいずれか一項に記載のコンピュータ実装方法。
【請求項10】
前記１つ以上のソリューションを生成することは、
１つ以上の自律モバイルロボットの役割を特定することと、
前記特定することに基づいて、前記カタログストアの他のプランよりも親和性要因の優先度が高い新たなプラン及び新たなタスクを特定することと、
特定されたプランの新たなプラン変数に新たな値をマッピングし、特定されたタスクを前記自律モバイルロボットに割り当てることと、
を含む、請求項１乃至９のいずれか一項に記載のコンピュータ実装方法。
１つ以上の自律モバイルロボットの役割を特定することと、
前記特定することに基づいて、前記カタログストアの他のプランよりも親和性要因の優先度が高い新たなプラン及び新たなタスクを特定することと、
特定されたプランの新たなプラン変数に新たな値をマッピングし、特定されたタスクを前記自律モバイルロボットに割り当てることと、
を含む、請求項１乃至９のいずれか一項に記載のコンピュータ実装方法。
【請求項11】
クラウド及び複数の異種の自律モバイル装置のうちの少なくとも１つ以上で展開される１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を動的に更新するシステムであって、
複数のプラン及びタスク割り当て戦略を含むカタログストアと、
前記クラウド及び複数の異種の自律モバイル装置上で実行される１つ以上のプラン実行エンジンと、
を含み、
前記１つ以上のプラン実行エンジンは、前記クラウド内の１つ以上のモジュールと通信して、
前記クラウド及び複数の異種の自律モバイル装置上で少なくとも１つ以上のイベントを監視すること、
前記監視することに基づいて、１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を更新のために分析することと、
１つ以上の既存のプラン及び１つ以上のタスク割り当て戦略を更新するために、前記分析することに基づいて１つ以上のソリューションを生成することと、
生成された前記１つ以上のソリューションに基づいて、前記カタログストアから１つ以上のプラン及び１つ以上の既存のタスク割り当て戦略を特定することと、
前記１つ以上の既存のプランを１つ以上の特定されたプランで更新し、前記１つ以上の既存のタスク割り当て戦略を１つ以上の特定されたタスク割り当て戦略で更新することと、
更新された１つ以上のプラン及び更新された１つ以上のタスク割り当て戦略を、前記クラウド及び前記複数の異種の自律モバイル装置のうちの少なくとも１つ以上に展開することと、
を含む命令を実行する、システム。
複数のプラン及びタスク割り当て戦略を含むカタログストアと、
前記クラウド及び複数の異種の自律モバイル装置上で実行される１つ以上のプラン実行エンジンと、
を含み、
前記１つ以上のプラン実行エンジンは、前記クラウド内の１つ以上のモジュールと通信して、
前記クラウド及び複数の異種の自律モバイル装置上で少なくとも１つ以上のイベントを監視すること、
前記監視することに基づいて、１つ以上の既存のプラン及び１つ以上の既存のタスク割り当て戦略を更新のために分析することと、
１つ以上の既存のプラン及び１つ以上のタスク割り当て戦略を更新するために、前記分析することに基づいて１つ以上のソリューションを生成することと、
生成された前記１つ以上のソリューションに基づいて、前記カタログストアから１つ以上のプラン及び１つ以上の既存のタスク割り当て戦略を特定することと、
前記１つ以上の既存のプランを１つ以上の特定されたプランで更新し、前記１つ以上の既存のタスク割り当て戦略を１つ以上の特定されたタスク割り当て戦略で更新することと、
更新された１つ以上のプラン及び更新された１つ以上のタスク割り当て戦略を、前記クラウド及び前記複数の異種の自律モバイル装置のうちの少なくとも１つ以上に展開することと、
を含む命令を実行する、システム。
【請求項12】
前記クラウド内の１つ以上のモジュールと通信する前記１つ以上のプラン実行エンジンが実行する前記命令は、
前記クラウド及び複数の異種の自律モバイル装置のうちの１つ以上に展開されたプラン及びタスク割り当て戦略のうちの少なくとも１つ以上の変数の値の変化を分析することと、
前記変化を分析することに基づいて、前記異種の自律モバイル装置のうちの１つ以上に少なくとも１つ以上のプラン及びタスク割り当て戦略を展開することと、
前記１つ以上の異種の自律モバイル装置上で新たな動作を開始することと、
をさらに含む、請求項１１に記載のシステム。
前記クラウド及び複数の異種の自律モバイル装置のうちの１つ以上に展開されたプラン及びタスク割り当て戦略のうちの少なくとも１つ以上の変数の値の変化を分析することと、
前記変化を分析することに基づいて、前記異種の自律モバイル装置のうちの１つ以上に少なくとも１つ以上のプラン及びタスク割り当て戦略を展開することと、
前記１つ以上の異種の自律モバイル装置上で新たな動作を開始することと、
をさらに含む、請求項１１に記載のシステム。
【請求項13】
前記クラウド内の１つ以上のモジュールと通信する前記１つ以上のプラン実行エンジンが実行する前記命令は、
トラッキングすべき１つ以上の変数を受信することであって、該１つ以上の変数は１つ以上の自律モバイル装置に関連する、ことと、
１つ以上の新たなプラン及び１つ以上の新たなタスク割り当て戦略を（ａ）受信した前記変数を閾値と比較すること及び（ｂ）該新たなプラン及び新たなタスク割り当て戦略の互換性を展開されたプラン及び展開されたタスク割り当て戦略と比較することのうちの少なくとも１つに基づいて特定することと、
前記比較のうちの１つ以上に少なくとも基づいて、前記受信した変数が閾値を下回り、前記互換性が一致しないことの警告通知を送ることと、
をさらに含む、請求項１１又は１２に記載のシステム。
トラッキングすべき１つ以上の変数を受信することであって、該１つ以上の変数は１つ以上の自律モバイル装置に関連する、ことと、
１つ以上の新たなプラン及び１つ以上の新たなタスク割り当て戦略を（ａ）受信した前記変数を閾値と比較すること及び（ｂ）該新たなプラン及び新たなタスク割り当て戦略の互換性を展開されたプラン及び展開されたタスク割り当て戦略と比較することのうちの少なくとも１つに基づいて特定することと、
前記比較のうちの１つ以上に少なくとも基づいて、前記受信した変数が閾値を下回り、前記互換性が一致しないことの警告通知を送ることと、
をさらに含む、請求項１１又は１２に記載のシステム。
【請求項14】
前記クラウド内の１つ以上のモジュールと通信する前記１つ以上のプラン実行エンジンが実行する前記命令は、
前記複数の異種の自律モバイル装置により実行されるべき１つ以上のタスクを受信することと、
１つ以上の展開されたプラン及び１つ以上の展開されたタスク割り当て戦略に関連する変数を閾値と比較することと、
前記変数を比較することに基づいて、タスクを拒絶するか又はタスクを前記複数の異種の自律モバイル装置に割り当てることと、
タスクが割り当てられた場合、１つ以上の既存プラン及び１つ以上の既存のタスク割り当て戦略を更新することと、
を含む、請求項１１乃至１３のいずれか一項に記載のシステム。
前記複数の異種の自律モバイル装置により実行されるべき１つ以上のタスクを受信することと、
１つ以上の展開されたプラン及び１つ以上の展開されたタスク割り当て戦略に関連する変数を閾値と比較することと、
前記変数を比較することに基づいて、タスクを拒絶するか又はタスクを前記複数の異種の自律モバイル装置に割り当てることと、
タスクが割り当てられた場合、１つ以上の既存プラン及び１つ以上の既存のタスク割り当て戦略を更新することと、
を含む、請求項１１乃至１３のいずれか一項に記載のシステム。
【請求項15】
コンピュータにより実行された場合に、該コンピュータに請求項１乃至１０のいずれか一項に記載の方法を実行させる命令を含むコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は概して異種の自律モバイル装置及びクラウドデバイスシステムによるプラン実行及びタスク割り当て戦略（task allocation strategies）の分野に関連し、より具体的には既存のプラン及び既存のタスク割り当て戦略を更新するためのソリューション（solutions）を動的に生成することに関する。
【背景技術】
【0002】
モノのインターネット(ＩｏＴ)及びロボット工学は、過去数年間に指数関数的に成長した２つの分野である。ＩｏＴは、特定のタスクを行うために協調して動作するデバイスのネットワークを含む。同様に、ロボット工学では、複数の多様なタスクを行うために複数のロボットが協調して作業を行う。
【0003】
過去１０年間でロボットの使用は指数関数的に増加した。ロボットは倉庫の自動化を含む全ての分野で現在用いられている。今日、複数のロボットの協調には複数の課題がある。複数のロボットの協調の必要性はシステムを複雑にし、維持を困難なものにする。これらのシステムは倉庫のような動作環境でランタイム又は動的な決定を効果的に行うことができない。
【発明の概要】
【発明が解決しようとする課題】
【0004】
以下は、本明細書でより詳細に説明する主題の短い概要である。本概要は、特許請求の範囲を限定することを意図するものではない。本発明のこれらの及び他の特徴は、添付の図面とそれらの図面の以下の詳細な説明及び本発明の現在の好ましい実施形態と他の実施形態を考慮することでより容易に理解されるであろう。
【0005】
クラウド及び複数の異種の自律モバイル装置（例えば、ロボット）の少なくとも１つ以上にあるプラン及びタスク割り当て戦略を動的に更新することに関連する様々な技術を本明細書で説明する。システム又はプラットフォームは、複数のプラン及びタスク割り当て戦略を含むカタログストアと、クラウド及び複数の異種の自律モバイル装置上で実行されるプラン実行エンジンと、を含み、プラン実行エンジンは、クラウド内のモジュールと通信して命令を実行する。システム又はプラットフォームは、様々なイベントを内部的及び外部的に継続的に監視する。プラットフォームは、更新又は置き換えが必要であり得る既存のプラン及びタスク割り当て戦略を分析する。プラットフォームは様々な要因に応じてソリューションを生成し、更新が必要であり得る関連プラン及びタスク割り当て戦略を特定する。生成されたソリューションに基づいて、既存のプラン及びタスク割り当て戦略が更新又は置き換えられ得る。プラン及びタスク割り当て戦略の更新が行われると、プラットフォームは更新されたプラン及びタスク割り当て戦略をクラウド及び複数の異種の自律モバイル装置のうちの少なくとも１つ以上に展開する。
【0006】
本発明の一実施形態によれば、システムは、異種の自律モバイルロボットが新たな能力を獲得したことを示す受信した通知を分析することと、生成されたソリューションを獲得された新たな能力に対して調整することと、調整された１つ以上のソリューションに基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、を含む既存のプラン及び既存のタスク割り当て戦略の分析を行う。さらに、ソリューションを生成することは、自律モバイルロボットの役割を特定することと、特定することに基づいて、カタログストアの他のプランよりも親和性要因（affinity factor）の優先度が高い新たなプラン及び新たなタスクを特定することと、特定されたプランの新たなプラン変数に新たな値をマッピングし、特定されたタスクを自律モバイルロボットに割り当てることと、を含む。
【0007】
本発明の別の実施形態によれば、システムは、特定された新たなプランが既存のプランと互換性があり、特定された新たなタスク割り当て戦略が１つ以上の既存のタスク割り当て戦略と互換性があるかを検証し、検証することに基づいて、特定された新たなプランのプラン変数及び特定された新たなタスク割り当て戦略のタスク割り当て戦略変数に新たな値をマッピングする。さらに、システムは、自律モバイルロボットに関連するプラットフォーム変数、プラン変数及びタスク割り当て戦略変数のうちの少なくとも１つ以上の値を閾値と比較することと、自律モバイルロボット上に展開されているプラン及びタスク割り当て戦略を更新するために、前記比較することに基づいて新たなプラン及び新たなタスク割り当て戦略を特定することと、特定された新たなプランの変数及び特定された新たなタスク割り当て戦略の変数に新たな値をマッピングすることと、を含むソリューションを生成する。さらに、ソリューションの生成は、１つ以上の自律モバイルロボットに関連するプラットフォーム変数、プラン変数及びタスク割り当て戦略変数のうちの少なくとも１つ以上の１つ以上の値を閾値と比較することと、自律モバイルロボット上に展開されているプラン及びタスク割り当て戦略を更新するために、前記比較することに基づいて新たなプラン及び新たなタスク割り当て戦略を特定することと、特定された新たなプランの変数及び特定された新たなタスク割り当て戦略の変数に新たな値をマッピングすることと、を含む。
【0008】
本発明の別の実施形態によれば、システムは、新たな自律モバイルロボットの新たな能力を、異種の自律モバイルロボットに拡大することであって、該新たな自律モバイルロボットは異なる種類のロボットである、ことと、新たな能力と互換性がある新たなプラン及び新たなタスク割り当て戦略を特定することと、特定されたプラン及び特定されたタスク割り当て戦略を異種の自律モバイルロボット上に展開することと、をさらに含む。
【0009】
本発明の別の実施形態によれば、システムは、展開されたプラン及び展開されたタスク割り当て戦略を更新するために、プランカタログ及びタスク割り当てカタログを検索して新たなプラン及び新たなタスク割り当て戦略をそれぞれ見つけることと、エージェントカタログを用いて、プランカタログ及びタスク割り当てカタログの検索を狭めることと、狭めることに基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、プランレベル及びタスク割り当て戦略レベルのうちの少なくとも１つ以上でマッピングを行うべきか判定することと、判定することに基づいて、特定されたプラン及び特定されたタスク割り当て戦略の静的変数及び一時変数のうちの少なくとも１つ以上に新たな値をマッピングすることと、をさらに含む。システムは、異なる種類の新たな自律モバイルロボットが一群の複数の異種の自律モバイルロボットに加わったとの通知を分析することと、通知を分析することに基づいて、１つ以上の追加のソリューションを生成することと、生成された追加のソリューションに基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、異なる種類の新たな自律モバイルロボットのために新たなプラン及び新たなタスク割り当て戦略のプラン変数に新たな値をマッピングすることと、異なる種類の自律モバイルロボット上に新たなプラン及び新たなタスク割り当て戦略を展開することと、をさらに含む。
【0010】
本発明の別の実施形態によれば、システムは、自律モバイルロボットのうちの少なくとも１つ以上に関連する親和性要因を決定するステップと、決定された親和性要因に基づいて、新たなプラン及び新たなタスク割り当て戦略を特定することと、特定されたプラン及び特定されたタスク割り当て戦略で展開されたプラン及び展開されたタスク割り当て戦略を更新することと、自律モバイルロボットに更新されたプラン及び更新されたタスク割り当て戦略を展開することと、をさらに含む。システムは、自律モバイルロボット及びクラウド上で実行される少なくとも１つ以上のプラン実行エンジンからの通知を分析することと、通知を分析することに基づいて、自律モバイルロボット上で実行される既存のプラン及び既存のタスク割り当て戦略が新たな挙動をサポートするかを検証することと、検証することに基づいて、新たな挙動をサポートする新たなプラン及びタスク割り当て戦略を特定することと、自律モバイルロボットのために、特定されたプランの新たなプラン変数に新たな値をマッピングし、特定されたタスク割り当て戦略の新たなタスク割り当て戦略変数に新たな値をマッピングすることと、をさらに含む。
【0011】
本発明の別の実施形態によれば、システムは、クラウド及び複数の異種の自律モバイル装置上で展開されたプラン及びタスク割り当て戦略のうちの少なくとも１つ以上の変数の値の変化を分析することと、変化を分析することに基づいて、異種の自律モバイル装置のうちの１つ以上に少なくとも１つ以上のプラン及びタスク割り当て戦略を展開することと、１つ以上の異種の自律モバイル装置上で新たな動作を開始することと、をさらに含む。システムは、履歴データに基づいて、プランカタログ及びタスク割り当てカタログからプラン及びタスク割り当て戦略をそれぞれ検索することと、履歴データの分析に基づいて、プランカタログ内の検索したプランから新たなプランを選択し、タスクカタログ内の１つ以上の検索したタスク割り当て戦略から新たなタスク割り当て戦略を選択することと、をさらに含む。
【0012】
本発明の別の実施形態によれば、システムは、トラッキングすべき変数を受信することであって、該変数は自律モバイル装置に関連する、ことと、新たなプラン及び新たなタスク割り当て戦略を（ａ）受信した変数を閾値と比較すること及び（ｂ）該新たなプラン及び新たなタスク割り当て戦略の互換性を展開されたプラン及び展開されたタスク割り当て戦略と比較することのうちの少なくとも１つに基づいて特定することと、比較のうちの１つ以上に少なくとも基づいて、受信した変数が閾値を下回り、互換性が一致しないことの警告通知を送ることと、をさらに含む。さらに、システムは、複数の異種の自律モバイル装置により実行されるべき１つ以上のタスクを受信することと、展開されたプラン及び展開されたタスク割り当て戦略に関連する変数を閾値と比較することと、変数を比較することに基づいて、タスクを拒絶するか又はタスクを複数の異種の自律モバイル装置に割り当てることと、タスクが割り当てられた場合、既存プラン及び既存のタスク割り当て戦略を更新することと、を含む。
【0013】
本発明の別の実施形態によれば、システムは、自律モバイル装置の能力の変化を分析することと、変化を分析することに基づいて、エージェントカタログ内でソフトウェアコードを検索することと、１つ以上の自律モバイル装置の能力と互換性があるソフトウェアコードをエージェントカタログから特定することと、１つ以上の自律モバイル装置の既存のソフトウェアコードを特定したソフトウェアコードで更新することと、をさらに含む。システムは、プラン及びタスク割り当て戦略における更新を複数の異種の自律モバイル装置に通知することと、更新の通知に反応して、新たな能力を獲得した自律モバイル装置を他の異種の自律モバイル装置より優先することと、優先することに基づいて、新たな能力を獲得した自律モバイル装置に新たなタスクを割り当てることと、をさらに含む。システムは、展開されたプラン及び展開されたタスク割り当て戦略に対する新たなプラン及び新たなタスク割り当て戦略の互換性を確認することと、互換性の確認に基づいて、複数の異種の自律モバイル装置で展開されたプラン及びタスク割り当て戦略を中止することと、をさらに含む。
【0014】
本発明の別の実施形態によれば、システムは、輸入された独自のプランの人気、コミュニティによる使用、レビューコメント、ソフトウェアコードの使い勝手の良さ、プラン、タスク割り当て戦略、複数のコア機能及びレビュースコアのうちの少なくとも１つ以上に基づいて、ユーザの人気を高めるか又は高いライセンス料を受け取ることができるようにするポピュラリティモジュールをさらに含む。システムは既存のプラン及び既存のタスク割り当て戦略のうちの少なくとも１つ以上に関連する変数を分析することと、分析した変数の値を閾値と比較することと、値を比較することに基づいて、カタログストア内で少なくとも１つ以上のプラン及び１つ以上のタスク割り当て戦略を検索することと、履歴データ、ロボットの役割、ロボットの種類及びロボットの機能を含む少なくとも１つ以上の要因に基づいて、検索したプラン及び検索したタスク割り当て戦略から新たなプラン及びタスク割り当て戦略を特定することと、をさらに含む。
【0015】
本明細書に記載の技術は、職場での最適なパフォーマンスを確実にするために、動作環境においてアクティブ又はアイドルの間にランタイムでの動的な意思決定を可能にする堅牢なプラットフォーム又はシステムに関連する。例示の実施形態では、プラットフォームは、既存のプラン及び既存のタスク割り当て戦略を更新するために適切な新たなプラン及びタスク割り当て戦略を特定するために、履歴データ、ロボットに関連する特徴、環境に関連する特徴、文脈固有の特徴、カスタム化された特徴、システム／プラットフォーム、タスク割り当て戦略及びプランのうちの少なくとも１つ以上に関連する変数のうちの少なくとも１つ以上に依拠し得る。
【0016】
上述の主題はまた、コンピュータ制御装置、コンピュータプロセス、コンピュータシステム又はコンピュータ読み取り可能媒体等の製品として実施され得ることを理解されたい。これらの及び様々な他の特徴は、以下の詳細な説明を読み、関連する図面の再考することによって明らかになるであろう。
【0017】
上記の要約は、本明細書で議論されるシステムおよび/または方法のいくつかの態様の基本的な理解を提供するために、簡略化された要約を提示する。
【図面の簡単な説明】
【0018】
本明細書で説明する、プラン及びタスク割り当て戦略を更新するためのソリューションの動的な生成の特定の特徴、態様及び利点は、以下の説明、添付の特許請求の範囲及び添付の図面に関連してよりよく理解されるであろう。
【図6】図６は、一実施形態に係る、プラン及びタスク割り当て戦略を更新するためのプロセスステップを示す例示のフロー図である。 本発明の特定の特徴を一部の図面には示し、他の図面には示していないが、各特徴は、本発明に従って他の特徴のいずれか又は全てと組み合わされ得るため、便宜上そのようにしている。図中のブロックの順序は限定されず、本発明に従って任意の順序に代えることができる。図中の開始ブロック及び終了ブロックは、それらがソフトウェアコード開発の一部として多くの表現のうちの１つを示し得るため限定的に解釈すべきでない。上記の図は、本明細書で説明するシステム及び／又は方法の一部の態様の基本的な理解を提示する。図面は、本明細書で説明するシステム及び／又は方法の広範な概観ではない。主要な／重要な要素を特定するか又はそのようなシステム及び／又は方法の範囲を線引きすることを意図していない。後に述べるより詳細な説明の序文としていくつかの概念を簡略化した形で提示することがその唯一の目的である。
【発明を実施するための形態】
【0019】
ロボット等の異種の装置に対するプラン及びタスク割り当てを更新又は切り替えるために、ソリューションを動的に生成するためのプラットフォーム又は動作環境においてランタイムでソリューションを生成すること提供する技術の実施形態を本明細書で説明する。本明細書全体を通して、「一実施形態」、「本実施形態」及び類似の表現への言及は、その実施形態に関連して説明される特定の特徴、構造又は特性が少なくとも１つ以上の実施形態に含まれることを意味する。そのため、本明細書全体を通した様々な箇所でのこれらの表現の出現の全てが同じ実施形態を参照しているわけではない。さらに、特別な特徴、構造又は特性は１つ以上の実施形態で任意の好適な形で組み合わせられ得る。
【0020】
１つ以上のコンピュータ読み取り可能媒体の任意の組み合せが利用され得る。コンピュータ読み取り可能媒体は、コンピュータ読み取り可能信号媒体又はコンピュータ読み取り可能記憶媒体であり得る。コンピュータ読み取り可能記憶媒体は、例えば、限定されないが、電子、磁気、光学、電磁若しくは半導体システム、装置若しくはデバイス又はこれらの任意の好適な組み合わせであり得る。コンピュータ読み取り可能記憶媒体のより具体的な例（包括的でないリスト）は、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、中継器を備えた適切な光ファイバ、ポータブルコンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、光記憶装置、磁気記憶装置又はこれらの任意の好適な組み合わせを含む。本願の文脈では、コンピュータ読み取り可能記憶媒体は、命令実行システム、装置又はデバイスに関連する又はそれらにより用いるためのプログラムを収容又は記憶可能な任意の有形媒体であり得る。
【0021】
コンピュータ読み取り可能信号媒体は、例えばベースバンドに又は搬送波の一部としてコンピュータ読み取り可能プログラムコードが盛り込まれた伝搬データ信号を含み得る。そのような伝搬信号は、限定されないが、電磁、光又はそれらの任意の好適な組み合わせを含む様々な形態のいずれかを取り得る。コンピュータ読み取り可能信号媒体は、命令実行システム、装置又はデバイスに関連するか又はそれらにより用いられるプログラムを通信、伝搬又は搬送可能なコンピュータ読み取り可能記憶媒体ではない任意のコンピュータ読み取り可能媒体であり得る。コンピュータ読み取り可能信号媒体に盛り込まれたプログラムコードは、限定されないが、無線、有線、光ファイバケーブル、ＲＦ又はそれらの任意の好適な組み合わせを含む任意の適切な媒体を用いて送信され得る。
【0022】
本開示の態様のための動作を行うためのコンピュータプログラムコードは、１つ以上のプログラム言語の任意の組み合わせで書かれ得る。プログラムコードは、スタンドアローンソフトウェアパッケージとしてユーザのコンピュータ上で全体的に、ユーザのコンピュータ上で部分的に実行され得るか、ユーザのコンピュータ上で部分的に且つリモートコンピュータ上で部分的に、又はリモートコンピュータ又はサーバ上で全体的に実行され得る。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続され得るか又は外部コンピュータに（例えば、インターネットサービスプロバイダを用いてインターネットを介して）接続され得るか又はクラウドコンピューティング環境にあるか又はソフトウエアアズサービス（ＳａａＳ）、プラットフォームアズサービス（ＰａａＳ）、インフラストラクチャーアズサービス（ＩａａＳ）、ロボティクスアズサービス（ＲａａＳ）、ウェアハウスアズサービス（ＷａａＳ）、コラボレーティブロボット（コボット）アズサービス又は他のサービスモデル等のサービスとして提供され得る。
【0023】
本開示の実施形態に係る方法、装置（システム）及びコンピュータプログラム製品のフロー図及び／又はブロック図を参照して本開示の態様を本明細書で説明する。フロー図及び／又はブロック図の各ブロック及びフロー図及び／又はブロック図のブロックの組み合わせは、コンピュータプログラム命令により実施できることが分かる。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ又は他のプログラマブルデータ処理装置のプロセッサに提供されてマシンを作り、コンピュータ又は他のプログラマブル命令実行装置のプロセッサを介して実行される命令が、フロー図及び／又はブロック図のブロックで特定される機能／動作を実行するための機構を作り出す。
【0024】
これらのコンピュータプログラム命令は、実行された場合にコンピュータ、他のプログラマブルデータ処理装置又は他の装置に特定の方法で機能させることができるコンピュータ読み取り可能媒体に記憶されてもよく、命令は、コンピュータ読み取り可能媒体に記憶された場合に製品を生み出し、該製品は、実行された場合にフロー図及び／又はブロック図のブロックで特定される機能／動作をコンピュータに実行させる命令を含む。コンピュータプログラム命令は、コンピュータ、他のプログラム可能な命令実行装置又は他の装置にロードされて、コンピュータ、他のプログラム可能な装置又は他の装置で一連の動作ステップを実行させてコンピュータ実施プロセスを作り出して、命令がコンピュータ又は他のプログラム可能な装置で実行された場合に、フロー図及び／又はブロック図のブロックで特定される機能／動作を実施するためのプロセスを提供する。
【0025】
当業者に理解されるように、本開示の態様は、新規で有用なプロセス、機械、製造若しくは物質の組成又はそれらの新規で有用な改善を含む、多数の特許可能な分類又は文脈のいずれかで本明細書において図示説明され得る。したがって、本開示の態様は、全体的にハードウェア、全体的にソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコード又は他の好適な種類のソフトウェアを含む）として又は本明細書で概して「回路」、「モジュール」、「コンポーネント」又は「システム」又は「プラットフォーム」又は「装置」と呼び得るソフトウェア及びハードウェアの実装の組み合わせとして実施され得る。さらに、本開示の態様は、コンピュータ読み取り可能プログラムコードが盛り込まれた１つ以上のコンピュータ読み取り可能媒体（例えば、有形の非一時的なコンピュータ読み取り可能媒体）で具現化されるコンピュータプログラム製品の形態を取り得る。本開示は、「ユーザ」、「開発者」、「デザイナー」、「第三者」、「倉庫所有者」、「ロボットソリューションプロバイダ」等の用語に言及し、いくつかの又は特定の実施形態で用いられるが、これらの用語は、それらの特定の実施形態に限定されず、本発明はこれらの用語に制限又は限定されないため他の用語に置き換えることができる。
【0026】
装置は、固有の識別子と、インターネットを介してデータを転送する能力とを有する物体又は物理的なエンティティである。一実施形態では、装置はモノのインターネットにおける「モノ」である。ＩｏＴの文脈において、モノとは、固有の識別子と、埋め込みシステムと、ネットワークを介してデータを転送する能力とを有するエンティティ又は物理的な物体を意味する。これらの装置は、物理的装置、家電製品、車両、エッジ装置、フォグデバイス等を含み得る。装置は、他の装置の機能と共に作動及び検知を行うことができるロボットも含む。
【0027】
「プラン」という用語は複数の形で定義でき、制限的に解釈すべきでない。最も簡単に説明すると、プランとは次々に実行されるべき行動のリストである。それは、より複雑な方策及びサブプランを策定するために用いられる構造である。方策及びポリシーの様々な表現が存在し、この簡単な説明を広げる。プランの基本概念は有限オートマトンに強く関係し、一連の動作の策定だけでなく、ループ及び条件付き実行の策定も可能にする。そのため、一式のプランＰにおけるプランｐは状態の構造であり、それらの間の遷移である。実施形態のうちの１つでは、「充電」プランは２つのタスクを含み得る。１つのタスクは一式のロボットが充電のために行列に並ぶこと（queue）であり、１つのタスクは別の一式のロボットをドッキングして充電することである。一実施形態では、プランは「ロボットの挙動」も含み得る。ロボットの挙動は、プラン内の、所定の条件下でロボットにより実行される低レベルのアトミックな動作（low level atomic activity）である。本発明の別の実施形態では、「充電」プランは、ロボット待機状態、ロボットドッキング状態及びロボット充電状態の３つの状態を含む。一実施形態では、プランは、プランの実行の間の段階を表す一連の状態である。
【0028】
プランツリー（plan tree）は、充電プラン、ナビゲーションプラン、自律モードプラン、物の拾い上げ及び配置（pick and place objects）プラン、持ち上げプラン等のプランを含み得る。ロボットはプランの状態に従って移行される。時折、ロボットは「充電」状態にあり、その後に「充電」状態から引き出され、パレットを運搬及び選択する「自律モード」状態に移行され得る。そのため、これらの２つのプラン、すなわち「充電」プラン及び「自律的な選択及び保持」プランという２つのプランのために、「ナビゲーション」プランと呼ばれるサブプランが用いられ得る。サブプランは、１つ以上の目標を実現するプランの一部であるか又はプランにより実現されるべき目標の一部である。
【0029】
プラン内の状態の各対は、遷移によりリンク付けされ得る。遷移とは、ロボットが現在の状態から次の状態に進むために満たさなければならない条件である。各状態では、１つ以上のＡＭＲがプラン内の一連のサブプランを実行する。１つ以上のＡＭＲは、サブプランの実行が成功した後、タスクが失敗した場合又はサブプランの実行が無関係になった場合のいずれかで次の状態に遷移し得る。遷移条件は、次のプラン状態に遷移するために満たす必要がある異なるプラン変数及びプラン変数値を含むブール式として定義され得る。
【0030】
プラン実行エンジンは、１つ以上の異種の装置及び／又はクラウドによるタスクを割り当てる、プランを実行するためのロジックを含む。プランは、組み合わせて該プランを形成する複数のサブプランを含み得る。ロボットの挙動は、プラン内の、所定の条件下でロボットにより実行される低レベルのアトミックな動作である。例えば、「ロボット充電」プランは、ロボット待機状態、ロボットドッキング状及びロボット充電状態の３つの状態を含み得る。
【0031】
ユーザが、一群の無人搬送車（ＡＧＶ）の実行及び一群のフォークリフトの実行のためのプラン及びタスク割り当て戦略を開発した場合を考えてみる。プランは、一群のフォークリフトでは一般的であり得る、ルートプラニング、ナビゲーション、局所的な障害物回避、ＬｉＤＡＲスキャナ等の機能を含んでもよく、フォークリフトの場合とは異なり得るいくつかの機能もあり得る。設計時に、ユーザ又はサードパーティの開発者は、ユーザインターフェース上でプランをドラッグアンドドロップすることができる。倉庫の環境では、プラットフォームは、例えば、一群の無人搬送車（ＡＧＶ）及び一群のフォークリフトといった異種の装置間の調整を扱う。加えて、ＡＧＶの代わりにピッキング支援ロボットのためにプラン及びタスク割り当て戦略を置き換えなければならない場合、概して異なる様々な機能の調整及び実施のプロセス全体はプラットフォームによって対処される。そのため、本開示は、一群のＡＧＶ及び一群のフォークリフトのための１つ以上のプラン及び１つ以上のタスク割り当て戦略を、ピッキング支援ロボット等の他の装置群のために機能する１つ以上のプラン及びタスク割り当て戦略に置き換えることができる包括的なプラットフォームを含む。
【0032】
例えば、４フィートのロボット（4ft robot）又は半径が１メートルのロボットのためのナビゲーションシナリオを考えてみる。このために、開発者は埋め込みコードを書き、ミドルウェア、ナビゲーションスタック、レーザスキャナ、ローカライズ、障害物回避アルゴリズム等を構築しなければならない。これらの複雑さに対処するアプリケーションを構築するのに、開発者又は開発者のチームは何年間もの努力が必要となる。本開示は、ユーザがかなりの労力を費やすことなく、異なるロボット及び異なるシナリオのために容易に利用可能なプラン及びタスク割り当て戦略を用いることができるようにすることに加えて、ロボットが作業環境で航行している間にロボットのバッテリレベルが臨界閾値を下回るといった動的な状況に対処するために、ロボットが自身たちの間で調整できるようにする。プラットフォームは、ユーザが個々のロボットに加えてマルチロボット汎用シナリオを設計及び展開できるようにする。調整プリミティブは汎用であるため、フォークリフト作業、衝突回避、ピッキング等の異なるタスクがプラットフォームによってシームレスに扱われる。
【0033】
本発明は、クラウド及び／又は複数の異種自律ロボットによるプラン及びタスク割り当て戦略の更新の分野における技術的な課題を解決する。本発明は、複数の自律ロボットが航行している間の意思決定の問題に対処し、カスタム化されたプラン、プラットフォーム、タスク割り当て戦略変数（例えば、航行時間、ピッキング時間、タスク毎のロボットの最大数、フリート内のロボットの最大数、ロボットの種類、能力、役割、挙動等）等の少なくとも１つ以上の要因に基づいて実行するための代替的な関連プラン及びタスク割り当て戦略を提供する。さらに、ランタイムの課題に対処するために生成されるソリューションは、一式の自律ロボットに与えられたミッションに基づいて、一式のロボットが通常の機能を継続できるようにする。プラットフォームの目的の１つは、ユーザがシステムを構築するための労力を大幅に低減して、プランレベル又はタスク割り当て戦略レベルで最小限の情報を提供するだけでよくすることである。プラットフォームは、タスク（例えば、ホイールがどれだけ回転するべきか、ブレーキを何時かけるべきか等）を識別するのに十分なインテリジェント性を有し、本明細書で説明される予め定義された又は動的なソリューションに従って代替プラン及びタスク割り当て戦略を展開すると共に、ＡＭＲ上のタスクを実施し得る。
【0034】
本発明は、代替可能であるとともに、１つ以上の実施形態で代替可能に用いられる様々な用語に言及することが分かる。例えば、一実施形態では、「既存のプラン」という用語は、動作環境におけるその用途の１つの通り、本発明の範囲又は実施を何ら変更することなく、１つ以上の実施形態では「展開されるプラン」という用語で代替され得る。このような代替は限定的とはみなされず、そのような代替は本発明の範囲内にあるとみなされる。
【0035】
一実施形態では、クラウドデバイス管理システム又はクラウドデバイスシステムは、クラウド又はデバイスでのアプリケーションの構築、プロビジョニング及び展開を可能にするいくつかのソフトウェア及びハードウェアコンポーネントを含むプラットフォームアズアサービス（ＰａａＳ）フレームワークであり得る。
【0036】
図１は、一実施形態に係る、プラン及びタスク割り当て戦略を更新するためのソリューションを動的に生成するためのシステム１００を示すブロック図である。「動的に」という用語は、ランタイム若しくは展開後の動作又は自律モバイル装置が動作環境においてアクティブ又はアイドル等の異なる状態にある間を含み得ることが理解される。「動的」又は「ランタイム」という用語は制限的又は限定的と解釈されず、本発明の範囲内で解釈され得る。一実施形態では、カタログストア１０１は、プランカタログ１１１、タスク割り当てカタログ１１２、エージェントカタログ１１３等の複数のカタログを含む。タスク割り当てカタログ１１２は、例えば、最短距離に基づく順序の決定又は発注を処理するのに必要な全体の時間を減らすことに基づく順序の決定等の異なるタスク割り当て戦略を読み出すためにプラットフォームによって用いられ得る。プランカタログ１１１は複数の個別のプラン及びサブプランを含む。一実施形態では、プランとタスクカタログとの間に依存又は関係があり得る。これらのカタログは、１つ以上のプラン及び／又はタスク割り当て戦略の更新を助けるソリューションを生成するために展開及びランタイム（ＤＲ）モジュール１０２によって用いられる。この更新は、フリート内の異種ＡＭＲ間の新たな挙動の実施につながる。ＤＲモジュール１０２は、ロボット固有のコード又はファームウェア／埋め込みコードについてエージェントカタログ１１３を参照し得る。ロボット固有のコード又はファームウェア／埋め込みコードは、代替プラン及びタスク割り当て戦略を、１つ以上の異種ＡＭＲ上で実行される既存のプラン及びタスク割り当て戦略と切り替えなければならない場合に読み出され得る。一実施形態では、このエージェントカタログ１１３とＤＲモジュール１０２との間の通信は、関連するプラン及びタスク割り当て戦略を識別するための検索範囲を狭めるために用いられ得る。エージェントカタログ１１３は、例えば、３駆動ロボット、単輪フォークリフト又はＡＧＶといった異なる種類のロボットのソフトウェアコード、異なる種類ロボットの定義、ローカルナビゲーションプラン及び特定の種類のロボットに対してＬｉＤａｒスキャナが利用可能かといった情報を含み得る。プランカタログ１１１、タスク割り当てカタログ１１２及びエージェントカタログ１１３という３つのカタログは、変数を公開し、メタデータを記憶及び維持するＤＲモジュール１０２によって用いられるエンティティである。メタデータは、様々な変数（プラン変数、タスク割り当て戦略変数）に関する詳細をＤＲモジュール１０２に与え、例えばフォークリフトのために変数のマッピング（フォークリフト寸法は何か、どの車輪が駆動車輪か等）を指示する。これらのカタログは標準パッケージとして定義され、プラットフォーム上で利用可能にされる。
【0037】
一実施形態では、クラウド及び異種ＡＭＲ上でのプラン及びタスク割り当て戦略の実行の間にデータが生成され得る。例えば、生成されたデータは、装置により収集されたセンサデータ、任意の装置の挙動の実行の結果、新たな装置との通信等を含み得る。一実施形態では、プラン及びタスク割り当て戦略の実行の間に生成されたデータは、センサ及び実行データストア１０６に記憶される。センサ及び実行データストアは、後で図２に開示されるクラウドデバイス管理システムに記憶され得る。ＡＭＲ１０４ｂ、１０４ｃ、・・・１０４ｎ上で動作してプラン及びタスク割り当て戦略を実行する１つ以上のプラン実行エンジン１０３ｂ、１０３ｃ・・・１０３ｎは、ロボットにより捕捉されたセンサデータ、ロボット又はクラウド上で動作するプラン実行エンジンによるプラン及び／又はタスク割り当て戦略の動作を実行することの実行結果でセンサ及び実行データストア１０６を更新する。ＤＲモジュール１０２は、プラン実行エンジン１０３ａ・・・１０３ｎと、カタログストア１０１及びセンサ実行データストア１０６との間のインターフェースである。一実施形態では、センサ及び実行データストア１０６は、１つ以上のプラン及びタスク割り当て戦略を実行する１つ以上のプラン実行エンジン１０３ａ・・・１０３ｎとの双方向通信に基づいて、ＤＲモジュール１０２から制約ソリューション（constraint solution）を受け取る。制約ソリューションは、プラン実行エンジン１０３ａ及び他のプラン実行エンジン１０３ｂ・・・１０３ｎと協働してＤＲモジュール１０２により決定されたソリューションであり、ロボットの現在の状況又は現在実行中のタスクに依存する。一実施形態では、異なるプラン実行エンジンは、他の自律モバイルロボットのプラン実行エンジンにより購読される、対応する自律モバイルロボットの状態を公開又は送信し得る。通信はロボットオペレーティングシステム、データディストリビューションサービスにより提供される通信機構を用いて又は単純なＵＤＰプロキシ等を用いて確立される。プラン実行エンジンは、特定の通信周波数範囲内で、例えば１５Ｈｚ～３０Ｈｚで互いに通信し得る。
【0038】
一実施形態では、図１に開示のプラットフォーム１００は、譲受人のプラットフォームである「Ｒａｐｙｕｔａ．ｉｏ」プラットフォームと同様であってもよく、ロボット１０４ｂは、譲受人であるＲａｐｙｕｔａ Ｒｏｂｏｔｉｃｓ社によって開発されたロボットのうちの１つである「Ｓｏｏｔｂａｌｌｓ」と呼ばれるピッキング支援ＡＭＲと同様であってもよい。他のロボット１０４ｃ・・・１０４ｎは譲受人又は他の装置製造者により開発された他の種類のロボットであり得る。一実施形態では、自律モバイルロボットは命令を実行するためのプロセッサ及び記憶のためのメモリを含む。別の実施形態では、ＤＲモジュール１０２は異種のＡＭＲ群が倉庫等の動作環境で航行し得る間に、潜在的な困難又は機会を予期するコンテキストベースのソリューションを積極的に提供し得る。最適な決定を行うためのソリューションを生成するためにプラットフォームにより扱われる、ワークスペース又は動作環境でＡＭＲが直面する本明細書で説明される様々のシナリオが存在する。モジュール１０２により提供されるソリューションの一部は、倉庫内でのＡＭＲの充電の管理（一式のＡＭＲのうちで最初に充電すべきＡＭＲを特定すること）又は複数のスロットがある場合に、特定のスロットに高い優先度が与えられ得る特定種類のＡＭＲを選好すること又はルートプラン決定において又はソフトウェアのスタック又はソフトウェアの更新を得るために優先されるロボットを特定すること又は例えば、適所で回転できる能力、小回りできる能力、ナビゲーション時間、充電時間等の他のロボット関連プラン又はタスク割り当て戦略変数に基づく等のシナリオに関連し得る。ＤＲモジュール１０２は全てのプリミティブを扱い、例えば、充電、ナビゲーション、マルチロボット調整タスク又はロボット待ち行列、狭い通路での回転、デッドロック回避、障害物回避等の複雑なタスクのためのプランを生成し、そのような複雑且つ様々なタスクを扱うために包括的なインターフェースを提供する。プラン及びタスク割り当て戦略が展開された場合、全てのタスクはパッケージに統合され、異種の装置上に展開され得る。
【0039】
一実施形態では、プラットフォームは複数の異種の装置、例えば、フォークリフト、ＡＧＶ、グリッパ、ピッキング支援ＡＭＲ、ドローン（１０４ｂ、１０４ｃ・・・１０４ｎ）といった異種自律モバイルロボット（ＡＭＲ）上でのプラン及びタスク割り当て戦略の動的又はランタイム更新を管理し得る。単純化のために、ＡＭＲを用いるさらなるシナリオを説明するが、任意の他の種類の自動化車両（例えば、自動運転車両等）又はモバイルロボット又は自動化されたハードウェア装置又はＩｏＴ又はドローンが用いられ得ることが分かる。システムは、複数の異種のＡＭＲ１０４ｂ～１０４ｎ、クラウド１０４ａ、展開のための１つ以上のプラン及び１つ以上のタスク割り当て戦略を含むカタログストア１０１を含む。クラウドは複数の自律モバイルロボット１０４ｂ～１０４ｎとの双方向通信を維持し、ＡＭＲは様々なメッセージングプロトコルを介して互いに通信する。システムは、複数のＡＭＲ及びクラウド上で実行される複数のプラン実行エンジン１０３ａ・・・１０３ｎをさらに含む。これらの１つ以上のプラン実行エンジンは、ＤＲモジュール１０２から受信する命令に基づいて、複数のＡＭＲ１０４ｂ・・・１０４ｎで、展開された１つ以上のプラン及びタスク割り当て戦略を協働して実行する。ＤＲモジュール１０２は、実行エンジン、クラウド、デバイス、カタログストア及びデータストア間の双方向通信を調整するプラットフォームマネージャのように動作し得る。プラン実行エンジン１０３ａ・・・１０３ｎは様々なメッセージングプロトコルを介して互いに通信する。双方向通信チャネル１０５ａ、１０５ｂ、１０７ａ・・・１０７ｎ、１０８ａ・・・１０８ｎ及びプラン実行エンジン１０３ａ、１０３ｂ、１０３ｃ・・・１０３ｎ（単純化のために示されていない）間は、プラットフォームのコンポーネント又はモジュール間の高速且つ効率的な通信を保証し得る１つ以上のメッセージングプロトコルとみなされ得る。これらのメッセージングプロトコルは当業者に知られている。
【0040】
一実施形態では、３つのＡＭＲ（１０４ｂ、１０４ｃ、１０４ｄ（図示せず））があり、それらのうちの１つを最初に充電する必要があるシナリオを考えてみる。そのため、「充電」プランがどのように構成されているかにより全てが決まる。ＤＲモジュール１０２は構成を分析して、ＡＭＲ１０４ｂ、１０４ｃ及び１０４ｄ上で動作するプラン実行エンジン１０３ｂ、１０３ｃ及び１０３ｄ（図示せず）のそれぞれがそれらの間で決定できるかどうかを確認し、それが可能であれば、プラン実行エンジンはそれ自身で決定を行う（例えば、ＡＭＲの位置情報を送信する）。しかしながら、一部のシナリオでは、処理には重い計算負荷（例えば、航行の間の倉庫のマップ作製又はルートマップ分析及び生成）がかかるため、実行エンジンが重いコストを負うことからモジュール１０２がそれを決定し得る。そのようなシナリオでは、ＤＲモジュール１０２はクラウド１０４ａ上で動作するプラン実行エンジン１０３ａと協働して又はＤＲモジュール１０２と、クラウド１０４ａ、ＡＭＲ１０４ｂ、１０４ｃ及び１０４ｄ上で動作する実行エンジン１０３ａ、１０３ｂ、１０３ｃ、１０３ｄのうちの１つ以上とが協働して決定を行う。ＤＲモジュール１０２は、最適なパフォーマンスのためにプラン実行エンジン間のシームレスな機能の遷移を確かなものにする。
【0041】
一実施形態では、エージェントカタログ１１３は、プラットフォーム１００よりサポートされる異種のロボット１０４ｂ、１０４ｃ・・・１０４ｎ、例えばフォークリフト、ＡＧＶ、ＰＡ－ＡＭＲ、アーム、ドローン等のメタリポジトリである。メタリポジトリ情報は装置の特定の詳細、例えば、装置製造業者、ベンダー、モデル情報、寸法（サイズ、能力、ピック可能なペイロード）、ハードウェア情報、ソフトウェア情報、関連するファームウェア、コード等を含む。カタログストア１０１及びそのコンポーネント（プランカタログ１１１、タスク割り当てカタログ１１２、エージェントカタログ１１３）の役割を説明するために、ＡＭＲが倉庫内で航行している例を考えてみる。ランタイムでは、ＤＲモジュール１０２は、クラウド装置システム及び異種のロボット群の双方でのイベントを監視している。イベントを監視する間に、ＤＲモジュール１０２は、ロボット１０４ｂ又はシステムのために追跡されているプラットフォーム又はプラン若しくはタスク割り当て戦略変数が閾値（例えば、バッテリ全体の１０％未満のバッテリレベル）を超えたことを及びパフォーマンス値（ピッキング支援ＡＭＲのピッキングの数（８０ピック）が所定基準（毎時１００ピック）を下回る）が閾値範囲内にないことの通知を受ける。そのため、通知を受けた後に、ＤＲモジュール１０２は、プランカタログ１１１内の一式のナビゲーションプランから代替のナビゲーションプラン及びタスク割り当て戦略を特定しなければならない。ロボット１０４ｂが、ピッキング支援ＡＭＲである譲受人のロボット「Ｓｏｏｔｂａｌｌ」である場合を考えてみる。プラン実行エンジン１０３ｂにより実行されるナビゲーションプランは、プランカタログ１１１からの代替ナビゲーションプランで置き換える必要があり、タスク割り当てカタログ１１２からの別の一式のタスク割り当て戦略を切り替える必要があり得る。ここで、異なるロボット型フォークリフトであるロボット１０４ｂのための代替ナビゲーションプランがあることを考えてみる。一実施形態では、このロボットの代替プランは、ＰＡ－ＡＭＲに必要とされるものとは異なる種類のロボットのものであるため、異なるハードウェア構成、例えば、異なるドライブ、それらが動き回る方法の周りに異なる方向制約がある等の理由から既存のプランは新たなプランで置き換えられない場合がある。そのため、ＤＲモジュール１０２は、利用可能な選択肢からＰＡ－ＡＭＲ１０４ｂと互換性のある対応するナビゲーションプランを分析しなければならない。ナビゲーションプランが最初にプランカタログ１１１に追加されると、プランのオーナーは、ナビゲーションプランが適用されるロボットの広義の分類を記述できるか又はナビゲーションプランと互換性のあるロボットの分類を選択できる。例えば、ナビゲーションプランは、差動駆動ロボット又は全ての３サイクルコントローラタイプ又は所定の位置で回転できない車に類似するものに適用されるものと記述され得る。これは、図１ａ及び図１ｂで詳細がさらに説明され得る。
【0042】
図１において、ＤＲモジュール１０２は、先ずプランカタログ１１１、タスク割り当てカタログ１１２を検索し、プランカタログ１１１におけるナビゲーションプラン及びタスク割り当てカタログ１１２からのタスク割り当て戦略と、ロボット１０４ｂとの互換性を確認する。分かりやすくするために、プランカタログ１１１からのナビゲーションプランの更新に焦点を当ててみる。一般に、プランカタログ１１１内には少なくとも１００のナビゲーションプランが存在し得る。そのため、ＤＲモジュール１０２は、プランカタログ内でナビゲーションプランのリストを検索し、所定のロボット１０４ｂと互換性のある代替プランを特定し得る。互換性の確認はＡＰＩの互換性、ロボット種類の互換性、ハードウェア又はソフトウェアの互換性等に基づき得る。次に、プランカタログ及びタスク割り当てカタログの検索を狭めるために、エージェントカタログ１１３を、ＤＲモジュール１０２は、特定のロボット１０４ｂが分類され得る広義のカテゴリ又はカテゴリのサブセットについて確認する。このエージェントカタログ１１３の確認は、ＤＲモジュール１０２が検索範囲を絞り込み、関連するナビゲーションプラン及び／又はタスク割り当て戦略を特定するための追加フィルタとして考えることができる。ここで、ＤＲモジュール１０２がプランカタログ１１１から新たなナビゲーションプランを引き出し、プランがロボット１０４ｂ上で展開されなければならない場合、展開は、例えば、ロボットの寸法、最低速度又は最高速度等のロボット１０４ｂの既存のナビゲーションプランのプラン変数を新たなプランのプラン変数に更新又はマッピングすることにより補強されなければならない。ＤＲモジュール１０２は、既存のナビゲーションプランのプラン変数（例えば、フォークリフトの寸法、最低及び最高速度）からのデータが、展開されるべき新たなナビゲーションプランのプラン変数にマッピングされたカタログストア１０１から取り出されることを確かなものにする。そのため、カタログストア１０１で利用可能なカタログから読み出されたプラン変数のマッピングは、プラン又はタスク割り当て戦略が最初に展開されるか又はランタイムで後に再展開されたときには毎回行われる。
【0043】
一実施形態では、ＤＲモジュール１０２は、プラットフォーム変数、タスク割り当て戦略変数、及び／又はプラン変数を監視又は分析することを含み得るイベントの監視を継続し、通知又はトリガを受信した場合に通知を分析し、プラットフォーム、タスク割り当て戦略及び／又はプラン変数がそれらの閾値を超えて、それらが１つ以上のプランを更新することを正当化するかどうか及び／又は通知が少なくとも１つ以上のクラウド及び異種のロボット１０３ｂ・・・１０３ｎ上で展開された１つ以上のタスク割り当て戦略のみを更新することに関係するかを確認する。プラットフォーム、タスク割り当て戦略及び／又はプラン変数は、ＤＲモジュール１０２が、更新又はマッピングをプランレベル及び／又はタスク割り当て戦略レベルで行う必要があるかどうかについての決定を行う際に役立つ。これは、図１ａ及び図１ｂのスキーマ表現からも理解できる。
【0044】
一実施形態では、プランレベルで行われた更新を考え、プランがＮ個の変数（静的又は一時型）を有し得るシナリオを考えてみる。静的変数はロボット１０３ｂの最低又は最高速度、ロボット１０３ｂの寸法、ロボット１０３ｂのサイズであり、一時変数はロボット１０３ｂと他の隣接するロボット１０３ｃ・・・１０３ｎとの間でどれだけの距離が維持されているか等である。ここで、プランを展開又はインスタンス作成しなければならない場合、変数（例えばロボットのサイズ）の値は、エージェントカタログ１１３から新たなプランの変数にマッピングする必要がある。そのため、更新されたプラン及びタスク割り当て戦略を展開する前に、一時変数及び／又は静的変数は、特定されたプラン及びタスク割り当て戦略の新たな値とマッピングされる。
【0045】
一実施形態では、ロボット１０３ｃの一時的な能力が追加又は除去され得る例を考えてみる。この例では、通知の分析は、ロボット１０３ｃのためにプラン及びタスク割り当て戦略の双方を更新する必要があることを示し得る。分かりやすくするために、１つのプラン及び１つのタスク割り当て戦略を一例として考えるが、範囲は限定されず、複数のプラン及び複数のタスク割り当て戦略の更新を含む。そのために、ロボットが航行して、展開後に新たな機能を得るシナリオを考えてみる。ロボット１０３ｃはＡＧＶであってもよく、このＡＧＶは所定の位置で回転でき、差動駆動ロボットであり、３６０度の回転を行うことができ、任意の方向に航行でき、ルートプランに従って拾い上げ又は荷下ろしのタスクを行うことができる。ここで、倉庫内の特定の領域を航行する間、ＡＧＶ１０３ｃはトロリ又はシャトルを取得し得るため、３６０度の回転を行うことはできないが、代わりに３サイクルコントローラのような新たな能力を取得する。この新たな機能により、ＡＧＶ１０３ｃは自動車のように航行できる。一度ＡＧＶ１０３ｃとトロリ又はシャトルとが連携されると、この連携はＤＲモジュール１０２への通知をトリガし、本明細書で説明するＡＧＶ１０３ｃの新たなに取得した能力を扱うためにカスタム化されたソリューションを生成する。ＤＲモジュール１０２は通知を分析し、本明細書で説明するようにソリューションを生成する。そのため、このシナリオでは、ＤＲモジュール１０２により異なるタスク割り当て戦略が実行される必要があり得る。ＡＧＶ１０３ｃのために先に実施されていたナビゲーションプランは、３サイクルコントローラ機能に対応するタスクを有するナビゲーションプランで更新される必要があり得る。そのため、ルートプランニングでは、ＡＧＶ１０３ｃは以前特定の場所に航行するように指示され、３６０度回転して拾い上げを行うことができた。しかしながら、現在、ＡＧＶ１０３ｃがトロリ又はシャトルと連携されるシナリオに変更されたことにより、ＡＧＶ１０３ｃがトロリの後方にある場合、ＡＧＶ１０３ｃは３６０度回転できず、反対方向に進むことができない場合がある。そのため、ここでは、ＤＲモジュール１０２は、ＡＧＶ１０３ｃの方向制約及びルートの後処理を解決するために１つ以上のソリューションを生成する。一実施形態では、ＤＲモジュール１０２はプラン実行エンジン１０３ａ、１０３ｂ、・・・１０３ｎと協働してソリューションを生成する。ＤＲモジュール１０２は、既存のナビゲーションプランが更新され、ＡＧＶ１０３ｃによる能力のランタイム取得を考慮するために新たな関連タスク割り当て戦略が割り当てられることを確実にする。次いで、ＤＲモジュール１０２は、プランカタログ１１１からの新たな関連するナビゲーションプラン及びＡＧＶ１０３ｃのためのルートプランニングに関連するタスク割り当てカタログ１１２から更新され得る新たなタスク割り当て戦略で既存のナビゲーションプランを更新し得る。新たな更新されたプラン及びタスク割り当て戦略はＡＧＶ１０３ｃが新たに獲得した機能で所定のタスクセットを継続して行うことができるようにする。そのため、更新されたプラン及びタスク割り当て戦略を展開する前に、一時変数及び／又は静的変数は、ＡＧＶ１０３ｃにより獲得された新たな能力を反映するために特定されたプラン及びタスク割り当て戦略の新たな値でマッピングされる。一実施形態では、プランレベル及び／又はタスク割り当て戦略レベルでマッピングが行われるかどうかのこの決定は、プラン及びタスク割り当て戦略変数の値を分析することによりＤＲモジュール１０２により行われる。値に基づいて、ＤＲモジュール１０２は新たな値を決定しプラン及びタスク割り当て戦略の静的変数及び／又は一時変数にマッピングして、生成されたソリューションをＡＧＶ１０３ｃの新たに獲得された能力に合わせる。
【0046】
一実施形態では、ロボットの新たな機能の追加により、プラン及びタスク割り当て戦略の双方を更新する必要があり得る。例えば、タスク割り当て戦略及びプランの変更は、ロボットへの新たな能力の追加に関連するイベントに基づいてＤＲモジュール１０２によって開始され得る。以前は、ロボットは１００ｋｇしか拾い上げることができなかったが、トロリ又はシャトルの拡張機能の新たな能力を獲得したため、２００ｋｇ前後のものを拾い上げることができ、新たな一式のタスクを割り当てることが正当化され得る。そのため、ＤＲモジュール１０２は、更新を行うためにプラン及びタスク割り当て戦略を分析する必要があり得る。以前、獲得の前にはロボットの性能に違いはなく、全てのＡＧＶは１００ｋｇの拾い上げ及び荷下ろしに関する作業を行うことができるというのが一般原則であった。しかしながら、ここで、ＤＲモジュール１０２は、１０ｋｇを超えることが必要なタスクが存在する場合は、ＡＧＶ１０３ｃは上述したように拡張機能を有するため、新たなタスクが割り当てられ得るランタイムシナリオを考えなければならない。
【0047】
そのため、展開後、先のシナリオでは、ＡＧＶ１０３ｃがトロリ又はシャトルと連携されて、新たな能力を獲得したことがＤＲモジュール１０２に通知されると、これは、ＤＲモジュール１０２にシステムの性能レベルを高める機会を与える。通知を分析した後、ＤＲモジュール１０２は、本明細書で説明したように、ＡＧＶ１０３ｃのためのプラン及びタスク割り当て戦略の双方を更新する必要があることを示すプラットフォーム、タスク割り当て戦略及び／又はプラン変数を確認する。ＤＲモジュール１０２は、新たな能力に合わせるために割り当てられるべき関連プラン及びタスクを特定するための複数のソリューションを生成する。割り当てられるべき関連プラン及びタスクを特定した後、ＤＲモジュール１０２はそれらをＡＧＶ１０３ｃ上に展開する。本発明は、プラン及び／又はタスク割り当て戦略を更新するためのソリューションを生成するための要因として、この装置の能力のシナリオによって限定されず、本発明の範囲は、異種の装置の動作環境内でのランタイムで遭遇し得る他の要因を考慮するのに十分に広い。
【0048】
一実施形態では、ロボットの能力はエージェントカタログ１１３に記憶され得る。エージェントカタログ１１３はロボット固有コード又はファームウェアコードも含む。ロボット１０４ｂ上で動作するプラン実行エンジン１０３ｂがロボット１０４ｂの能力ＸがＹに変わったことを報告し得る場合を考えてみる。この変化はＤＲモジュール１０２に通知される。そのため、通知を受け取った後、ＤＲモジュール１０２は先ず既存のプラン及びタスク割り当て戦略がこの能力Ｙの変化に対応できるか（account for）どうかを検証する。しかしながら、現在のプラン及びタスク割り当て戦略に互換性がない場合、ＤＲモジュールは、タスク割り当て戦略のためにその能力がパラメータ化されているかどうかを確認する。これは、新たな値がタスク割り当て戦略にマップされているかどうか、新たなプランを正当化するかどうかを意味する。例えば、ロボットが拾い上げ及び荷下ろしできるかどうかは、拾い上げ及び荷下ろし機能があるか又は適切なプランをプランカタログが与えることを正当化する。ＤＲモジュールは、プランカタログ及びタスク割り当てカタログを調査し、展開され得る互換性のあるプラン及びタスク割り当て戦略を探す。また、一実施形態では、能力が変更されているため、ＤＲモジュールはエージェントカタログを参照して、既存のコードがロボット１０４ｂの能力の変化と互換性がない可能性があるため、新たなファームウェアコード（例えば、ロボットの駆動機能の変化）を引き出す。新たなファームウェアコードはロボット１０４ｂの能力と互換性があり得る。例えば、ロボット１０４ｂは全方向ロボットであってもよく、ロボットがどのように駆動されるかに関連する現在の機能のためのファームウェア及び関連コードを有する。能力の変化により、ロボット１０４ｂは３サイクルコントローラ駆動機能を有することにつながり得る。新たな能力に基づいて、ＤＲモジュールは、ロボット１０４ｂの新たな能力と互換性のある新たなに特定されたソフトウェアコードでファームウェア及び／又はソフトウェアコードをアップグレードし得る。しかしながら、能力の変更は常にファームウェアの更新を必要とするわけではないので、ＤＲモジュールは、能力の変更がファームウェアのアップグレードを正当化し得るか及びその結果としてエージェントカタログと通信する必要があるかどうか判定しなければならない。
【0049】
一実施形態では、タスク割り当て戦略のサンプルメタデータを示す例示の非限定的スキーマが提供される。
タスク割り当て戦略例
SingleTaskPerAmr.tas
{
"id" : 1542881176278,
"author" : "tas_writer@domain.com",
"license" : "RR.LICENSE.OnDeployment",
"spec" : 0.9.2,
"version" : v1.2.12
"allocationType" : "RR.ALLOCATIONTYPE.Batch"
"compatibleRoles" : ["RR.ROLE.AMR.* ", "RR.ROLE.AMR.FORKLIFT", "RR.ROLE.AMR.AGV"]
"minAgentCardinality" : 1
"maxAgentCardinality" : 50
"maxTaskCardinality" : 50000
"maxAgentsPerTask" : 1
"comment" : "Task allocation strategy to assign single amr per task based on euclidean or manhattan distance"
"deploymentTarget" : ["RR.DEPLOYTARGET.Cloud", "RR.DEPLOYTARGET.Agent"],
"cloudNodeExePath" : "https://path.rapyuta.platform/tas/jghdf732_io.so",
"agentSummandsExePath" : "https://path.rapyuta.platform/tas/jghdf732_agent.so",
"supportedCostMaps": ["RR.DISTANCE.EUCLIDEAN", "RR.DISTANCE.MANHATTAN"],
"parameters" : [ "maxFrequency" : 30,
"preemptable" : True,
"preemptionThreshold" : 0.2
"costMap" : "RR.DISTANCE.EUCLIDEAN",
"timeout":30],
"trackingVariables":["rr.taskThroughputPerAgent":["min":12, "max": 1000,
"throughputBreachInterval" : 300]
"custom.randomVariable" : ["min" : 11, "max" : 123] ]
上述のスキーマに示される変数の一部を以下で説明する。タスク割り当て戦略例におけるこれらの変数のカウント又は名称は、それらはカスタム化でき、動作要件に応じて異なる名称又は値が用いられ得るため、限定的又は特定的とみなすべきでない。最初の「ｉｄ」という変数は固有の識別子を示し、「ａｕｔｈｏｒ」はアプリケーション所有者又は開発者であり得る。次の「ｌｉｃｅｎｓｅ」という変数は特定のタスク割り当て戦略に対するライセンスの種類を示す。「ＲＲ．ＬＩＣＥＮＳＥ．ＯｎＤｅｐｌｏｙｍｅｎｔ」という値は、タスク割り当て戦略の展開の回数に基づいて課金され得ることを示す。「ｖｅｒｓｉｏｎ」という変数は特定のタスク割り当て戦略のバージョンを示す。この変数の用法の１つは既存のタスク割り当て戦略を展開又は更新する前の互換性チェックであり得る。「ａｌｌｏｃａｔｉｏｎＴｙｐｅ」という変数は、タスク割り当て戦略により行われるタスク割り当ての種類を示す。例えば、「ＲＲ.ＡＬＬＯＣＡＴＩＯＮＴＹＰＥ.Ｂａｔｃｈ」という値は、割り当てがタスク毎の処理ではなくバッチ型の処理であることを示す。次の「ｃｏｍｐａｔｉｂｌｅＲｏｌｅｓ」という変数は、タスク割り当て戦略と互換性があるロボットの種類を示す。そのため、最初の値「ＲＲ．ＲＯＬＥ．ＡＭＲ．＊」は全てのＡＭＲに互換性があることを示し、「＊」記号で表される。同様に、他の値「ＲＲ．ＲＯＬＥ．ＡＭＲ．ＦＯＲＫＬＩＦＴ」、「ＲＲ.ＲＯＬＥ.ＡＭＲ.ＡＧＶ」は、フォークリフト及びＡＧＶがそれぞれ互換性のあるロボットであることを示す。次の「ｍｉｎＡｇｅｎｔＣａｒｄｉｎａｌｉｔｙ」という変数は、タスク割り当て戦略が扱うことができるエージェント又はロボットの数であり、その値は示されるように１である。同様に、次の「ｍａｘＡｇｅｎｔＣａｒｄｉｎａｌｉｔｙ」という変数は、タスク割り当て戦略が最大５０個のロボットを扱えることを示す。５０個以上のロボットがある場合は、タスク割り当ての計算はＮＰ困難な問題となり、このアプローチを用いてタスク割り当て計算を解くことは実現不可能であり得る。そのため、上記の５０を超える値では、５０よりも多いロボットを必要としている倉庫又は動作環境の場合、ＤＲモジュールがデフォルト又は所定の条件と互換性チェック及び／又は比較チェックを行った場合、このタスク割り当て戦略は互換性がない可能性がある。次の「ｍａｘＴａｓｋＣａｒｄｉｎａｌｉｔｙ」は、タスク割り当て戦略が扱うことができるタスクの数を示す。ここでは、その値は５００００であり、戦略は５００００タスク扱うことができる。上記の変数の値でタスク割り当て戦略を実行した結果、次の「ｍａｘＡｇｅｎｔｓＰｅｒＴａｓｋ」という変数は、タスク毎に割り当てられるエージェントの数（例えば、１）を示す。「エージェント」という用語は、本明細書で説明するように「ロボット」という用語又は任意の他の異種装置で置き換えられ得ることが分かる。「ｃｏｍｍｅｎｔ」という変数は特定のタスク割り当て戦略のための包括的なコメントを含まれる。「ｄｅｐｌｏｙｍｅｎｔＴａｒｇｅｔ」という変数は「ｌｉｓｔ」タイプであり、タスク割り当て戦略を展開できる異なる種類の装置を示す。前述の例では、「ＲＲ．ＤＥＰＬＯＹＴＡＲＧＥＴ．Ｃｌｏｕｄ」という値は、タスク割り当て戦略がクラウドデバイスシステムにより実行されてもよく、クラウドデバイスシステムのＤＲモジュールは、エージェント又はロボットにタスク割り当て戦略の実行結果を行うよう指示し得ることを示し得る。「ＲＲ.ＤＥＰＬＯＹＴＡＲＧＥＴ.Ａｇｅｎｔ」という値は、これがロボット上で実行可能な軽量のタスク割り当て戦略であり、実行のためにクラウドデバイスシステムを必ずしも必要としないことを意味する。「ＲＲ．ＤＥＰＬＯＹＴＡＲＧＥＴ．Ｃｌｏｕｄ」、「ＲＲ.ＤＥＰＬＯＹＴＡＲＧＥＴ.Ａｇｅｎｔ」という値が割り当てられた場合、タスク割り当て戦略はクラウド、ロボット及びその両方での実行と互換性があり得る。この値のために、ＤＲモジュールは、タスク割り当て戦略がクラウド、ロボット又はその両方で実行され得るかを決定し得る。タスク割り当て戦略をクラウドノード上で実行しなければならない場合、変数「ｃｌｏｕｄＮｏｄｅＥｘｅＰａｔｈ」という変数はタスク割り当て戦略のソースコードのＵＲＬを含む。タスク割り当て戦略がロボット上で実行されなければならない場合、「ａｇｅｎｔＳｕｍｍａｎｄｓＥｘｅＰａｔｈ」という変数は、ロボット上で実行されるタスク割り当て戦略のそれぞれのソースコードのＵＲＬを含む。ここで、タスク割り当て戦略を展開しなければならない場合、ＤＲモジュールはタスク割り当て戦略をどこで実行すべきかを決定する。そのため、ＵＲＬでのソースコードは、タスク割り当て戦略を実行すべきクラウドデバイスシステム及び／又はロボットと互換性を有してなければならない。次の「ｓｕｐｐｏｒｔｅｄＣｏｓｔＭａｐｓ」という変数は、距離計算がＥＵＣＬＩＤＥＡＮ又はＭＡＮＨＡＴＴＡＮ距離に基づくかを示す。これまで説明してきた変数は静的変数であってもよく、次の「ｐａｒａｍｅｔｅｒｓ」という変数は要件に従って設定可能な動的変数であってもよい。例えば、「ｐａｒａｍｅｔｅｒｓ」変数の値は、タスク割り当て戦略の展開の間に上書きされ得るデフォルト値又はカスタム値を示す。展開の間、値が「Ｔｒｕｅ」のパラメータ変数「ｐｒｅｅｍｐｔｉｂｌｅ」は、アプリケーションがタスクをプリエンプト可能（preemptible）にしたいかどうかを示す。例えば、ロボットにタスクが既に割り当てられており、より良いタスク割り当て戦略が利用可能である場合、このロボットをプリエンプトすべきかどうかである。値が「Ｔｒｕｅ」の場合、ロボットはプリエンプトされる。「ｐｒｅｅｍｐｔｉｏｎＴｈｒｅｓｈｏｌｄ」というパラメータ変数は、ロボットがプリエンプトされる閾値を示し得る。この変数は、マイナーな性能の向上のためにロボットをプリエンプトすることによりタスク割り当て戦略による新たなタスクの割り当てが継続されないことを確かなものにする。「０．２」という単位は、プリエンプトが起こるために、少なくとも０．２単位の性能の向上が得られ得ることを示す。残りの変数はコストマップ及びタイムアウトを示す。タイムアウトは、タスク割り当て戦略が最適なタスク割り当て計算を行うために与えられる時間の単位を示す。
タスク割り当て戦略例
SingleTaskPerAmr.tas
{
"id" : 1542881176278,
"author" : "tas_writer@domain.com",
"license" : "RR.LICENSE.OnDeployment",
"spec" : 0.9.2,
"version" : v1.2.12
"allocationType" : "RR.ALLOCATIONTYPE.Batch"
"compatibleRoles" : ["RR.ROLE.AMR.* ", "RR.ROLE.AMR.FORKLIFT", "RR.ROLE.AMR.AGV"]
"minAgentCardinality" : 1
"maxAgentCardinality" : 50
"maxTaskCardinality" : 50000
"maxAgentsPerTask" : 1
"comment" : "Task allocation strategy to assign single amr per task based on euclidean or manhattan distance"
"deploymentTarget" : ["RR.DEPLOYTARGET.Cloud", "RR.DEPLOYTARGET.Agent"],
"cloudNodeExePath" : "https://path.rapyuta.platform/tas/jghdf732_io.so",
"agentSummandsExePath" : "https://path.rapyuta.platform/tas/jghdf732_agent.so",
"supportedCostMaps": ["RR.DISTANCE.EUCLIDEAN", "RR.DISTANCE.MANHATTAN"],
"parameters" : [ "maxFrequency" : 30,
"preemptable" : True,
"preemptionThreshold" : 0.2
"costMap" : "RR.DISTANCE.EUCLIDEAN",
"timeout":30],
"trackingVariables":["rr.taskThroughputPerAgent":["min":12, "max": 1000,
"throughputBreachInterval" : 300]
"custom.randomVariable" : ["min" : 11, "max" : 123] ]
上述のスキーマに示される変数の一部を以下で説明する。タスク割り当て戦略例におけるこれらの変数のカウント又は名称は、それらはカスタム化でき、動作要件に応じて異なる名称又は値が用いられ得るため、限定的又は特定的とみなすべきでない。最初の「ｉｄ」という変数は固有の識別子を示し、「ａｕｔｈｏｒ」はアプリケーション所有者又は開発者であり得る。次の「ｌｉｃｅｎｓｅ」という変数は特定のタスク割り当て戦略に対するライセンスの種類を示す。「ＲＲ．ＬＩＣＥＮＳＥ．ＯｎＤｅｐｌｏｙｍｅｎｔ」という値は、タスク割り当て戦略の展開の回数に基づいて課金され得ることを示す。「ｖｅｒｓｉｏｎ」という変数は特定のタスク割り当て戦略のバージョンを示す。この変数の用法の１つは既存のタスク割り当て戦略を展開又は更新する前の互換性チェックであり得る。「ａｌｌｏｃａｔｉｏｎＴｙｐｅ」という変数は、タスク割り当て戦略により行われるタスク割り当ての種類を示す。例えば、「ＲＲ.ＡＬＬＯＣＡＴＩＯＮＴＹＰＥ.Ｂａｔｃｈ」という値は、割り当てがタスク毎の処理ではなくバッチ型の処理であることを示す。次の「ｃｏｍｐａｔｉｂｌｅＲｏｌｅｓ」という変数は、タスク割り当て戦略と互換性があるロボットの種類を示す。そのため、最初の値「ＲＲ．ＲＯＬＥ．ＡＭＲ．＊」は全てのＡＭＲに互換性があることを示し、「＊」記号で表される。同様に、他の値「ＲＲ．ＲＯＬＥ．ＡＭＲ．ＦＯＲＫＬＩＦＴ」、「ＲＲ.ＲＯＬＥ.ＡＭＲ.ＡＧＶ」は、フォークリフト及びＡＧＶがそれぞれ互換性のあるロボットであることを示す。次の「ｍｉｎＡｇｅｎｔＣａｒｄｉｎａｌｉｔｙ」という変数は、タスク割り当て戦略が扱うことができるエージェント又はロボットの数であり、その値は示されるように１である。同様に、次の「ｍａｘＡｇｅｎｔＣａｒｄｉｎａｌｉｔｙ」という変数は、タスク割り当て戦略が最大５０個のロボットを扱えることを示す。５０個以上のロボットがある場合は、タスク割り当ての計算はＮＰ困難な問題となり、このアプローチを用いてタスク割り当て計算を解くことは実現不可能であり得る。そのため、上記の５０を超える値では、５０よりも多いロボットを必要としている倉庫又は動作環境の場合、ＤＲモジュールがデフォルト又は所定の条件と互換性チェック及び／又は比較チェックを行った場合、このタスク割り当て戦略は互換性がない可能性がある。次の「ｍａｘＴａｓｋＣａｒｄｉｎａｌｉｔｙ」は、タスク割り当て戦略が扱うことができるタスクの数を示す。ここでは、その値は５００００であり、戦略は５００００タスク扱うことができる。上記の変数の値でタスク割り当て戦略を実行した結果、次の「ｍａｘＡｇｅｎｔｓＰｅｒＴａｓｋ」という変数は、タスク毎に割り当てられるエージェントの数（例えば、１）を示す。「エージェント」という用語は、本明細書で説明するように「ロボット」という用語又は任意の他の異種装置で置き換えられ得ることが分かる。「ｃｏｍｍｅｎｔ」という変数は特定のタスク割り当て戦略のための包括的なコメントを含まれる。「ｄｅｐｌｏｙｍｅｎｔＴａｒｇｅｔ」という変数は「ｌｉｓｔ」タイプであり、タスク割り当て戦略を展開できる異なる種類の装置を示す。前述の例では、「ＲＲ．ＤＥＰＬＯＹＴＡＲＧＥＴ．Ｃｌｏｕｄ」という値は、タスク割り当て戦略がクラウドデバイスシステムにより実行されてもよく、クラウドデバイスシステムのＤＲモジュールは、エージェント又はロボットにタスク割り当て戦略の実行結果を行うよう指示し得ることを示し得る。「ＲＲ.ＤＥＰＬＯＹＴＡＲＧＥＴ.Ａｇｅｎｔ」という値は、これがロボット上で実行可能な軽量のタスク割り当て戦略であり、実行のためにクラウドデバイスシステムを必ずしも必要としないことを意味する。「ＲＲ．ＤＥＰＬＯＹＴＡＲＧＥＴ．Ｃｌｏｕｄ」、「ＲＲ.ＤＥＰＬＯＹＴＡＲＧＥＴ.Ａｇｅｎｔ」という値が割り当てられた場合、タスク割り当て戦略はクラウド、ロボット及びその両方での実行と互換性があり得る。この値のために、ＤＲモジュールは、タスク割り当て戦略がクラウド、ロボット又はその両方で実行され得るかを決定し得る。タスク割り当て戦略をクラウドノード上で実行しなければならない場合、変数「ｃｌｏｕｄＮｏｄｅＥｘｅＰａｔｈ」という変数はタスク割り当て戦略のソースコードのＵＲＬを含む。タスク割り当て戦略がロボット上で実行されなければならない場合、「ａｇｅｎｔＳｕｍｍａｎｄｓＥｘｅＰａｔｈ」という変数は、ロボット上で実行されるタスク割り当て戦略のそれぞれのソースコードのＵＲＬを含む。ここで、タスク割り当て戦略を展開しなければならない場合、ＤＲモジュールはタスク割り当て戦略をどこで実行すべきかを決定する。そのため、ＵＲＬでのソースコードは、タスク割り当て戦略を実行すべきクラウドデバイスシステム及び／又はロボットと互換性を有してなければならない。次の「ｓｕｐｐｏｒｔｅｄＣｏｓｔＭａｐｓ」という変数は、距離計算がＥＵＣＬＩＤＥＡＮ又はＭＡＮＨＡＴＴＡＮ距離に基づくかを示す。これまで説明してきた変数は静的変数であってもよく、次の「ｐａｒａｍｅｔｅｒｓ」という変数は要件に従って設定可能な動的変数であってもよい。例えば、「ｐａｒａｍｅｔｅｒｓ」変数の値は、タスク割り当て戦略の展開の間に上書きされ得るデフォルト値又はカスタム値を示す。展開の間、値が「Ｔｒｕｅ」のパラメータ変数「ｐｒｅｅｍｐｔｉｂｌｅ」は、アプリケーションがタスクをプリエンプト可能（preemptible）にしたいかどうかを示す。例えば、ロボットにタスクが既に割り当てられており、より良いタスク割り当て戦略が利用可能である場合、このロボットをプリエンプトすべきかどうかである。値が「Ｔｒｕｅ」の場合、ロボットはプリエンプトされる。「ｐｒｅｅｍｐｔｉｏｎＴｈｒｅｓｈｏｌｄ」というパラメータ変数は、ロボットがプリエンプトされる閾値を示し得る。この変数は、マイナーな性能の向上のためにロボットをプリエンプトすることによりタスク割り当て戦略による新たなタスクの割り当てが継続されないことを確かなものにする。「０．２」という単位は、プリエンプトが起こるために、少なくとも０．２単位の性能の向上が得られ得ることを示す。残りの変数はコストマップ及びタイムアウトを示す。タイムアウトは、タスク割り当て戦略が最適なタスク割り当て計算を行うために与えられる時間の単位を示す。
【0050】
一実施形態では、ＤＲモジュールが、一群の異種のＡＭＲ上に展開された上記のタスク割り当て戦略に関連する動作を行うシナリオを考えてみる。上記の例では、「ｍａｘＡｇｅｎｔＣａｒｄｉｎａｌｉｔｙ」の値は５０であり、現在の一群のロボットのサイズ５０にランタイムで新たなロボットが追加されている。新たなロボットの追加によりイベントがトリガされ、該イベントは、新たなロボットが追加されたことを示すＤＲモジュールに通知することである。ＤＲモジュールは、一群のロボットのカウントが「ｍａｘＡｇｅｎｔＣａｒｄｉｎａｌｉｔｙ」の値と一致しないため、閾値超えを探すためにイベント又は通知を分析する。ＤＲモジュールは、タスク当たりのエージェントの数(「ｍａｘＡｇｅｎｔｐｅｒＴａｓｋ」変数)を２に増やす必要があり得るか又は他の変数を更新する必要があり得るかを計算し得る。これらは静的変数であるため、ＤＲモジュールは、タスク割り当て戦略を、タスク割り当てカタログからの新たなタスク割り当て戦略と切り替えるためのソリューションを生成する。「ｔｒａｃｋｉｎｇＶａｒｉａｂｌｅｓ」という変数は、ＤＲモジュールがタスク割り当て戦略レベルで変数を監視できるようにする。同様に、ＤＲモジュールがプランレベルで変数を監視できるようにするトラッキング変数がプラン内にある。第１の変数は「ｔａｓｋＴｈｒｏｕｇｈｐｕｔｐｅｒＡｇｅｎｔ」であり、最小値１２及び最大値１０００を有する。一実施形態では、これは、１時間毎に実行されるタスクの数を示してもよく、最小が１２で、最大が１０００である。ロボットにタスク割り当て戦略を展開する間、これらの値をロボットの仕様、役割及び能力に従って更新できる。これらの値が超えられると、ＤＲモジュールに代替案を探すよう通知するイベントが生成される。トラッキングすべき次の変数は、「ｔｈｒｏｕｇｈｐｕｔＢｒｅａｃｈＩｎｔｅｒｖａｌ」であり、ＤＲモジュールが代替案を探す前にこれらの値がどれだけの期間超えられてもよいかを示す。そのため、一実施形態では、トラッキングすべき変数が３００単位の時間にわたって一貫して超えられた場合、ＤＲモジュールはイベントに反応し、そうでない場合はタスク割り当て戦略の切り替え又は置き換えのためのステップをＤＲモジュールがとる必要がない。次の「ｃｕｓｔｏｍ.ｒａｎｄｏｍ Ｖａｒｉａｂｌｅ」：「ｍｉｎ：１１, ｍａｘ：１２３」という変数は、トラッキングのためにタスク割り当て戦略の要件に従ってランダム又はカスタム化された変数を開発者又はアプリケーションの所有者が定義できることを示す。
【0051】
一実施形態では、ＤＲモジュールは、タスク割り当て戦略におけるメタデータ又は変数に基づいてソリューションを生成し得る。メタデータ又は変数に関連するデータの実際の収集は、クラウド及びロボット上で動作するプラン実行エンジンによりなされ得る。例えば、タスク割り当て戦略がロボット上で実行される場合、「ａｇｅｎｔＳｕｍｍａｎｄｓＥｘｅＰａｔｈ」変数で示されるライブラリ又はソフトウェアコードがロボット上に展開され、ロボット上で動作するプラン実行エンジンが「ａｇｅｎｔＳｕｍｍａｎｄｓＥｘｅＰａｔｈ」で示されるライブラリと通信し得る。ライブラリは所望の周波数で実行され、プラン実行エンジンは変数のためのデータをＤＲモジュールに送り返し得る。
【0052】
一実施形態では、タスク割り当て戦略レベルでトラッキングされている変数は、システムのパフォーマンスが低下していること又は期待されるパフォーマンス範囲に値が近づいていないことを示し得る。「ｃｏｓｔＭａｐ」の値が「ＲＲ.ＤＩＳＴＡＮＣＥ.ＥＵＣＬＩＤＥＡＮ」であり、これに基づいてタスク割り当てがなされた場合を考えてみる。ＤＲモジュールにより生成される１つ以上のソリューションは、「ｃｏｓｔＭａｐ」の値が「ＲＲ.ＤＩＳＴＡＮＣＥ.ＭＡＮＨＡＴＴＡＮ」であるか又は他の同様の値を有し得る新たなタスク割り当て戦略を選択するためのものであり得る。ここで、タスク割り当て戦略が複数の距離値のリストを含む場合、ＤＲモジュールは「ｃｏｓｔＭａｐ」の値のうちの１つの履歴パフォーマンスに基づいてタスク割り当て戦略を特定することを含み得るソリューションを生成し得る。そのため、生成されたソリューションに基づいて、ＤＲモジュールは、他のタスク割り当て戦略の履歴パフォーマンスが現在のパフォーマンスよりも優れているかどうか確認し、タスク割り当て戦略がより良好なパフォーマンスを示している場合には、既存のタスク割り当て戦略が更新され得る。同様に、生成されたソリューションは、関連するタスク割り当て戦略を、更新及び後でクラウド及び異種のＡＭＲ上で展開するために特定するために考慮可能な変数の値の様々な置換及び組み合わせに基づき得る。生成されたソリューションは、要求されるスループット又はパフォーマンスの向上が得られるまでＤＲモジュールにより繰り返し分析され得る。同様のアプローチは、本明細書で説明するように、既存のプラン及びタスク割り当て戦略の双方を更新するためのソリューションを生成するために適用され得る。
【0053】
一実施形態では、プランのサンプルメタデータを示す例示の非限定的スキーマを以下で提供される。
プランカタログにおけるプランの例
"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" : "https://path.rapyuta.platform/plan/ghfg323hj.so",
"parameters" : [ "requestForDestination" : False,
"pickLocation" : [ “x”: 0, “y”: 0, “theta”: 0 ],
"dropLocation" : [ “x”: 0, “y”: 0, “theta”: 0 ] ],
"states" : [ {
"id" : 1542881176280,
"name" : "MoveToPickup",
"comment" : "",
"entryPoint" : null,
"abstractPlans" : [ "Behaviours/Navigate.beh#1542881969548" ],
"variableBindings" : [ ],
"outTransitions" : [ 1542881645594 ],
"inTransitions" : [ 1542881648973 ]
},
{
"id" : 1542881176380,
"name" : "Pickup",
"comment" : "",
"entryPoint" : null,
"abstractPlans" : [ "Behaviours/Pickup.beh#1542881969548" ],
"variableBindings" : [ ],
"outTransitions" : [ 1542881645666],
"inTransitions" : [ 1542881645594 ]
} ..]
"trackingVariables" : [ ["rr.navigationTime" : ["min" : 12, "max" : 1000,
"throughputBreachInterval" : 300]],
["rr.pickTime" : ["min" : 12, "max" : 1000,
"throughputBreachInterval" : 300]],
["rr.dropTime" : [“min” : 12, “max” : 1000,
"throughputBreachInterval" : 300]] ]}
一実施形態では、プランは「ＰｉｃｋＡｎｄＤｒｏｐ」プランであり得る。上記に示す変数の一部を以下で説明する。プラン例におけるこれらの変数のカウント又は名称は、それらはカスタム化でき、動作要件に応じて異なる名称又は値が用いられ得るため、限定的又は特定的とみなすべきでない。このプランには、タスク割り当てカタログと機能の点で類似した変数を有する。繰り返しを避け、分かりやすくするために、変数の例を説明するが、他の変数の機能は別段説明がないかぎり、タスク割り当て戦略について説明したものと同様又は広げられる。「ＰｉｃｋＡｎｄＤｒｏｐ」プランは、ＡＭＲが作業環境の周りを航行する間にＡＭＲにより実行され得る。変数「ｉｄ」：１５４２８８１１３２４３５、「ａｕｔｈｏｒ」:「ｐｌａｎ＿ｗｒｉｔｅｒ@ｄｏｍａｉｎ.ｃｏｍ」、「ｌｉｃｅｎｓｅ」: 「ＲＲ.ＬＩＣＥＮＳＥ.ＯｒｇＯｎｅＴｉｍｅ」、「ｒｒ＿ｓｐｅｃ」：０．９.２、「ｖｅｒｓｉｏｎ」：ｖ２．０.１、「ｃｏｍｐａｔｉｂｌｅＲｏｌｅｓ」:「ＲＲ．ＲＯＬＥ．ＡＭＲ．＊」、「ＲＲ.ＲＯＬＥ.ＡＭＲ.ＦＯＲＫＬＩＦＴ」、「ＲＲ.ＲＯＬＥ.ＡＭＲ.ＡＧＶ」、「ｅｘｅＰａｔｈ」:「ｈｔｔｐｓ：//ｐａｔｈ.ｒａｐｙｕｔａ.ｐｌａｔｆｏｒｍ/ｐｌａｎ/ｇｈｆｇ３２３ｈｊ.ｓｏ」は、タスク割り当て戦略について説明したものと機能の面で同様であり得る。「ｌｉｃｅｎｓｅ」変数は、課金が当該プランについての１回限りの価格であり得ることを示す。プランが実行されると、ＡＭＲはピックアンドドロップロケーション変数に格納されたデータを探す。パラメータ変数「ｒｅｑｕｅｓｔＦｏｒＤｅｓｔｉｎａｔｉｏｎ」：Ｆａｌｓｅは、ロボットが目的地を要求しないことを示しており、目的地をプランにおいて提供されたものと考え得る。「ｒｅｑｕｅｓｔＦｏｒＤｅｓｔｉｎａｔｉｏｎ」変数は、ドロップロケーションが利用可能でない場合にＴｒｕｅあり、アイテムが拾い上げられた後に、ＡＭＲは目的地を問い合わせるか、目的地が提供されない場合にアイテムを拾い上げないか、エラーを表示し得る。次の変数は、プランの実行の異なる段階にある状態である。状態は、「ＭｏｖｅＴｏＰｉｃｋｕｐ」又は「Ｐｉｃｋｕｐ」であり、それらの変数は「ｉｄ」、「ｃｏｍｍｅｎｔ」等である。変数「ｅｘｅＰａｔｈ」により示されるソースコードは、遷移、挙動等の確認が含まれる。次の変数は「ｔｒａｃｋｉｎｇＶａｒｉａｂｌｅｓ」であってもよく、これにはプランレベルでＤＲモジュールによりトラッキングされる変数を含む。そのため、トラッキングすべき第１の変数は、倉庫等の作業環境で移動する最小及び最大時間を示す「ｒｒ.ｎａｖｉｇａｔｉｏｎＴｉｍｅ」であり得る。「ｐｉｃｋＴｉｍｅ」及び「ｄｒｏｐＴｉｍｅ」という他の変数は、アイテムの拾い上げ及び荷下ろしの最小時間及び最大時間をそれぞれ提供する。他の例では、充電のために行列で待つこと又はトラッキングされ得るアイドリング後に目的地へのナビゲーションを待つこと等の変数が存在し得る。
プランカタログにおけるプランの例
"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" : "https://path.rapyuta.platform/plan/ghfg323hj.so",
"parameters" : [ "requestForDestination" : False,
"pickLocation" : [ “x”: 0, “y”: 0, “theta”: 0 ],
"dropLocation" : [ “x”: 0, “y”: 0, “theta”: 0 ] ],
"states" : [ {
"id" : 1542881176280,
"name" : "MoveToPickup",
"comment" : "",
"entryPoint" : null,
"abstractPlans" : [ "Behaviours/Navigate.beh#1542881969548" ],
"variableBindings" : [ ],
"outTransitions" : [ 1542881645594 ],
"inTransitions" : [ 1542881648973 ]
},
{
"id" : 1542881176380,
"name" : "Pickup",
"comment" : "",
"entryPoint" : null,
"abstractPlans" : [ "Behaviours/Pickup.beh#1542881969548" ],
"variableBindings" : [ ],
"outTransitions" : [ 1542881645666],
"inTransitions" : [ 1542881645594 ]
} ..]
"trackingVariables" : [ ["rr.navigationTime" : ["min" : 12, "max" : 1000,
"throughputBreachInterval" : 300]],
["rr.pickTime" : ["min" : 12, "max" : 1000,
"throughputBreachInterval" : 300]],
["rr.dropTime" : [“min” : 12, “max” : 1000,
"throughputBreachInterval" : 300]] ]}
一実施形態では、プランは「ＰｉｃｋＡｎｄＤｒｏｐ」プランであり得る。上記に示す変数の一部を以下で説明する。プラン例におけるこれらの変数のカウント又は名称は、それらはカスタム化でき、動作要件に応じて異なる名称又は値が用いられ得るため、限定的又は特定的とみなすべきでない。このプランには、タスク割り当てカタログと機能の点で類似した変数を有する。繰り返しを避け、分かりやすくするために、変数の例を説明するが、他の変数の機能は別段説明がないかぎり、タスク割り当て戦略について説明したものと同様又は広げられる。「ＰｉｃｋＡｎｄＤｒｏｐ」プランは、ＡＭＲが作業環境の周りを航行する間にＡＭＲにより実行され得る。変数「ｉｄ」：１５４２８８１１３２４３５、「ａｕｔｈｏｒ」:「ｐｌａｎ＿ｗｒｉｔｅｒ@ｄｏｍａｉｎ.ｃｏｍ」、「ｌｉｃｅｎｓｅ」: 「ＲＲ.ＬＩＣＥＮＳＥ.ＯｒｇＯｎｅＴｉｍｅ」、「ｒｒ＿ｓｐｅｃ」：０．９.２、「ｖｅｒｓｉｏｎ」：ｖ２．０.１、「ｃｏｍｐａｔｉｂｌｅＲｏｌｅｓ」:「ＲＲ．ＲＯＬＥ．ＡＭＲ．＊」、「ＲＲ.ＲＯＬＥ.ＡＭＲ.ＦＯＲＫＬＩＦＴ」、「ＲＲ.ＲＯＬＥ.ＡＭＲ.ＡＧＶ」、「ｅｘｅＰａｔｈ」:「ｈｔｔｐｓ：//ｐａｔｈ.ｒａｐｙｕｔａ.ｐｌａｔｆｏｒｍ/ｐｌａｎ/ｇｈｆｇ３２３ｈｊ.ｓｏ」は、タスク割り当て戦略について説明したものと機能の面で同様であり得る。「ｌｉｃｅｎｓｅ」変数は、課金が当該プランについての１回限りの価格であり得ることを示す。プランが実行されると、ＡＭＲはピックアンドドロップロケーション変数に格納されたデータを探す。パラメータ変数「ｒｅｑｕｅｓｔＦｏｒＤｅｓｔｉｎａｔｉｏｎ」：Ｆａｌｓｅは、ロボットが目的地を要求しないことを示しており、目的地をプランにおいて提供されたものと考え得る。「ｒｅｑｕｅｓｔＦｏｒＤｅｓｔｉｎａｔｉｏｎ」変数は、ドロップロケーションが利用可能でない場合にＴｒｕｅあり、アイテムが拾い上げられた後に、ＡＭＲは目的地を問い合わせるか、目的地が提供されない場合にアイテムを拾い上げないか、エラーを表示し得る。次の変数は、プランの実行の異なる段階にある状態である。状態は、「ＭｏｖｅＴｏＰｉｃｋｕｐ」又は「Ｐｉｃｋｕｐ」であり、それらの変数は「ｉｄ」、「ｃｏｍｍｅｎｔ」等である。変数「ｅｘｅＰａｔｈ」により示されるソースコードは、遷移、挙動等の確認が含まれる。次の変数は「ｔｒａｃｋｉｎｇＶａｒｉａｂｌｅｓ」であってもよく、これにはプランレベルでＤＲモジュールによりトラッキングされる変数を含む。そのため、トラッキングすべき第１の変数は、倉庫等の作業環境で移動する最小及び最大時間を示す「ｒｒ.ｎａｖｉｇａｔｉｏｎＴｉｍｅ」であり得る。「ｐｉｃｋＴｉｍｅ」及び「ｄｒｏｐＴｉｍｅ」という他の変数は、アイテムの拾い上げ及び荷下ろしの最小時間及び最大時間をそれぞれ提供する。他の例では、充電のために行列で待つこと又はトラッキングされ得るアイドリング後に目的地へのナビゲーションを待つこと等の変数が存在し得る。
【0054】
図２は、一群の異種のロボットのためにプラン及びタスク割り当て戦略の更新を動的に管理するシステム２００を示すブロック図である。一実施形態では、システム２００は、クラウド及び異なる装置でソフトウェア（例えば、プラン）を展開及び実行するためのプラットフォームであるクラウドデバイス管理システム２０２を含む。クラウドデバイス管理システム２０２は、ロボットを含む装置を管理するためにも用いられる。クラウドデバイス管理システム２０２は、クラウドロボットソリューションプロバイダのためのプラットフォームアズアサービスフレームワークである。クラウドデバイス管理システム２０２は、クラウドデバイス管理システムで受信されるデータ及びクラウドデバイス管理システムと通信する装置からのデータを処理するために１つ以上のプロセッサを含む。簡略化のために２つのロボット２１４及び２１６のみを示すが、本発明は限定されず、異なる組み合わせ及び種類の装置を含み得る。
【0055】
クラウドデバイス管理システム２０２はセンサ及び実行データストア２０４も含む。センサ及び実行データストア２０４は、ロボット及びクラウドデバイス管理システムにより実行される挙動の実行データを記憶する。また、センサ及び実行データストアは、ロボットによりキャプチャーされたセンサデータも記憶する。ロボットの挙動は、状態内の特定の条件下でロボットにより実行される低レベルのアトミックな動作である。
【0056】
一実施形態では、クラウドデバイス管理システム２０２はプランを表示するユーザインターフェース２０６も含む。クラウドデバイス管理システム２０２は、複数のプランをプランカタログ（図示せず）に記憶するカタログストア２０８を含む。カタログストア２０８に記憶された異なる既存のプランがユーザインターフェース２０６でユーザに表示される。ユーザは、ユーザがロボット実行プランに追加したいと考える１つ以上の新たなサブプラン又はプランをカタログストア２０８から選択できる。一実施形態では、クラウドデバイス管理システム２０２は新たなプランと現在実行中のロボット実行プランとの互換性を確認する。この確認に基づいて、クラウドデバイス管理システム２０２は、既存のプランをロボット実行プランに追加できるようにする。これは、既存のプランをプラン実行エンジンに追加又は更新する間にプラットフォームが積極的に行うステップと同様である。
【0057】
一実施形態では、選択された既存のプランは、ロボット又はクラウドデバイス管理システムによる実行のために展開される前に、実行可能コードに変換され得る。ロボットプラン実行システム２０２は、既存のプランを実行可能コードに変換するビルドエンジン２１０を含む。プランを実行可能コードに変換するために、ビルドエンジン２１０はプランにビルダイメージコードを注入する。ビルダイメージは、ソースの特徴（フレームワーク、言語等）の検出を支援するためにソースコードの展開されたインスタンス及びソフトウェアを実行するために必要な様々なソフトウェアコンポーネントを含み得る。例えば、ビルダイメージは、オペレーティングシステムライブラリ、言語ランタイム、ミドルウェア及びソーストゥイメージツールを含み得る。ビルダイメージが実行されると、開発者のソースコードをビルダイメージに注入し、ソフトウェア実行可能イメージを生成する。ビルダイメージはクラウド及びデバイス側の双方で利用可能である。
【0058】
クラウドデバイス管理システム２０２は、クラウドデバイス管理システム２０２とロボット２１４、２１６との間の通信を管理する展開及びランタイムモジュール２１２を含む。一実施形態では、ＤＲモジュール２１２は、ロボット２１４、２１６からセンサデータ及び実行データを受信するメッセージブローカ２１８を含む。ロボット２１４、２１６はコミュニケータ２２０、２２２をそれぞれ含み、メッセージブローカ２１８との双方向通信を確立する。メッセージブローカ２１８は、ロボット２１４、２１６上で実行される新たな代替プラン及び既存のプランの実行結果及びセンサデータを受信する。一実施形態では、ロボットのコミュニケータ２２０、２２２は、ロボットにより収集されたセンサデータ及びロボット２１４、２１６によるプランの実行結果を共有するために、互いにピアツーピア通信を行うこともできる。ＤＲモジュール２１２は、図２のデバイスマネージャ２１２、メッセージブローカ２１８及びビルドエンジン２１０等のサブコンポーネントを含む。
【0059】
一実施形態では、既存のプラン及びタスク割り当て戦略が選択されると、クラウドデバイス管理システム２０２は、既存のプランを実行するために新たなプラン実行エンジン２２４を起動する。一実施形態では、クラウドデバイス管理システム２０２は、クラウドデバイス管理システム又はロボットで新たなプラン実行エンジンをさらに展開する。一実施形態では、新たなプラン実行エンジンは実行及びセンサデータストアに接続される。
【0060】
一実施形態では、クラウドデバイス管理システム２０２及び自律モバイルロボット２１４、２１６は、プラン実行エンジン２２４、２２６、２２８をそれぞれ含む。ロボット２１４、２１６は、クラウドデバイス管理システムとの協働環境で動作する異種の自律モバイルロボットであり得る。異種の装置は、少なくとも１つ以上の異なる装置種類又は同じ装置であるが能力が異なるか、異なるバージョンのソフトがインストールされているか又はオペレーティングシステム（例えば、ロボットオペレーティングシステム）のバージョンが異なるか、ハードウェアの種類が異なるか、製造業者が異なる装置又は装置の種類の他の可能な組み合わせを含み得る。プラン実行エンジン２２４、２２６及び２２８は、プラン実行エンジン上に展開されたプラン及びタスク割り当て戦略に応じて、プラン及びタスク割り当て戦略のうちの１つを実行する。プラン実行エンジンは、プラン実行を制御するために必要な異なる動作を実行するためのロジックを含むソフトウェアモジュールである。例えば、プラン実行エンジンは、異なる自律ロボットへのプランに含まれるタスクの割り当ての決定、プランに関する異なる制約問題の解決、プランの実行の同期等のためのロジックを記憶する。各自律ロボット及びクラウドデバイス管理システムは、プランを実行するためのプラン実行エンジンを実行する。
【0061】
プラン実行エンジン２２４、２２６及び２２８は単独で又は他のプラン実行エンジンと協働して、プラン及びタスク割り当て戦略を実行する。一実施形態では、プランを実行することは、いくつかのプラン実行値を決定することを含むプラン実行のライフサイクル全体を管理することを含む。例えば、プラン及びタスク割り当て戦略を実行することは、異なる自律ロボットへのプラン内の異なるタスクのタスク割り当てを決定することを含む。これらのプラン実行値は、環境又はロボットの状態の変化に基づいて、プラン実行の異なる段階で及びリアルタイムに決定され得る。例えば、特定のタスクに割り当てられた自律ロボットのいずれかが故障し、故障しておらず且つそのタスクを実行できる他のロボットにそのタスクを再割り当てしなければならない場合に、ロボットへのタスク割り当てはプラン実行の異なる段階で又リアルルタイムに決定され得る。
【0062】
一実施形態では、プラン実行エンジン２２４、２２６及び２２８によって決定される異なるプラン実行値と、ロボット２１４、２１６により収集されるセンサデータはセンサ及び実行データストア２０４に記憶される。一実施形態では、クラウドデバイス管理システム２０２は、ロボット実行プランに対応するセンサ及び実行データストアを含む。例えば、クラウドデバイス管理システム２０２は、ロボット実行プランに対応するセンサ及び実行データストア２０４、２３０を含む。センサ及び実行データは、センサ及び実行データストア２０４、２３２及び２３４は、クラウドデバイス管理システム２０２で実行されるプラン実行エンジン２２４、２２６及び２２８のそれぞれから、ロボット実行プランに対応するプラン実行値と、ロボット２１４、２１６からセンサ及び実行データとを受け取る。
【0063】
一実施形態では、センサ及び実行データストア２０４、２３０は、センサ及び実行データをお互いで更新するために互いに通信する。一実施形態では、ロボット２１４及び２１６は、ローカルセンサ及び実行データストア２３２、２３４をそれぞれ含む。ローカルセンサ及び実行データストア２３２、２３４は、ロボット２１４及び２１６からのセンサデータと、プラン実行エンジン２２６、２２８からの実行データでそれぞれ更新される。ローカルセンサ及び実行データストア２３２、２３４内のデータは、センサ及び実行データストア２３０と周期的に同期される。
【0064】
説明したように、センサ及び実行データストア２０４、２３２及び２３４は、クラウドデバイス管理システム２０２又はロボット２１４及び２１６で実行されるプラン実行エンジン２２４、２２６及び２２８と協働したＤＲモジュール２１２によるプランの実行の実行結果で更新される。ＤＲモジュール２１２は、センサ及び実行データストア２３２及び２３４からプラン実行データ及びセンサデータを読み出すためにセンサ及び実行データストア２３０への接続を用いる。ＤＲモジュール２１２は、プラン実行データ及びセンサデータの読み出しに基づいて、プラン実行の状態を決定する。
【0065】
プラン実行データ及びタスク割り当て戦略を読み出すことにより、ＤＲモジュール２１２は、新たな代替プラン及びタスク割り当て戦略が何時プラン実行エンジン２２４に又は他のプラン実行エンジン２２６及び２２８によって実行され得るかを決定できる。ＤＲモジュール２１２は、特定の条件が満たされた後、特定のプラン挙動が実行された後又は他のプラン実行結果の後に、新たな代替プラン及びタスク割り当て戦略を推し進め得る。例えば、現在のプランが「ロボット充電」プランで、新たな代替プランが「ソフトウェア更新」の場合、「ソフトウェア更新」プランは、「ロボット充電」プランが「ロボット充電」プランの「充電」状態に入ったときに実行されるように定義され得る。ＤＲモジュール２１２は、「ロボット充電」プランを実行するプラン実行エンジンからの「ドッキング」状態でセンサ及び実行データストアが何時更新されるかを決定する。その決定に基づいて、ＤＲモジュール２１２は、既存プランを新たな代替プランで更新し、プラン実行エンジンは、新たな代替プランである「ソフトウェア更新」を実行する。
【0066】
一実施形態では、「ロボット駐車」プランを実行するプラン実行エンジン２２６は、ロボット２１４の現在の位置、例えば「待機位置」、「駐車位置」等で実行及びセンサデータストア２３２を更新し得る。ローカルセンサ及び実行データストア２３２及び２２８内のデータは、クラウドデバイス管理システム２０２のセンサ及び実行データストア２３０と同期される。ＤＲモジュール２１２は、プラットフォーム変数、例えば位置を連続的に監視し、ロボット２１４の現在位置に変化があった場合に、実行及びセンサデータストア２３０から取り出され、その変化がＤＲモジュール２１２に通知される。変化に関する通知に際して、ＤＲモジュール２１２はプラットフォーム変数を分析し、ロボットの現在の位置が「駐車」位置であるかどうかを検証することを含むソリューションを特定する。ロボットの位置が「駐車」位置に変化した場合、ＤＲモジュール２１４はソリューションの一部として、「ソフトウェア更新」挙動プランを推し進めてロボット２１４上でソフトウェア更新動作を開始し、タスクが「ソフトウェア更新タスク」に更新される。
【0067】
一実施形態では、クラウドデバイスシステム２０２はポピュラリティモジュール２４０を含む。ＤＲモジュールはポピュラリティモジュール２４０と通信して、輸入された独自のプランの人気、コミュニティによる使用、レビューコメント、ソフトウェアコードの使い勝手の良さ、プラン、タスク割り当て戦略、複数のコア機能、レビュースコア等のうちの少なくとも１つ以上に基づいてユーザの人気を高めるか又は高いライセンス料を受け取ることができるようにする。
【0068】
図３は、一実施形態に係る、更新されたプラン及びタスク割り当て戦略を実行のために展開するプロセスを示す例示の非限定的なフロー図である。最初に、開発者又はユーザはプランをインポートするか又はユーザインターフェースを用いてプランを定義する。システムは、カタログストアから１つ以上のプランを展開するための要求を受け取り得る。プランは、装置（ＡＭＲ等）が設置されているシナリオに応じたタスクを含み、例えば、自律倉庫では、典型的なタスクはＬｉＤＡＲナビゲーション、ビジョンベースナビゲーション等のナビゲーション、在庫品目のピックアンドドロップ、仕分け、物体の把持等に関連し得る。要求を受け取った後、プラットフォームは、一群のＡＭＲで実行されるべきプラン及びタスク割り当て戦略を展開する。そして、既存のプランがクラウドデバイスシステム及びＡＭＲのうちの１つ以上で実行される。
【0069】
展開後、一式のＡＭＲは割り当てられたタスク（例えば、ピックアンドドロップ、仕分け、把持、人の追跡、人に物品を運ぶ等）を実行する。本明細書で説明するように、プラットフォームは、再構成可能なプラン及びタスク割り当て戦略を介して複数の異種の装置の動作能力を適合し得る。倉庫のような環境では、ＡＭＲがプラットフォームからのガイダンス又はサポートを必要とする数多くのシナリオがある。そのため、プラットフォームのＤＲモジュールは、プラットフォームに関連する様々なイベント又はプラットフォームに登録された一群のＡＭＲのパフォーマンス又は機能を示す値を含むプラン又はタスク割り当て戦略変数を継続的に監視する（３０１）。通知又は動作のためのトリガは、ＡＭＲ自体に由来するイベントを介して又はプラットフォームにより内部的に起こり得る。通知は、ＡＭＲ上で動作するプラン実行エンジンからＤＲモジュールへの信号又はメッセージの形態であり得る。通知は、クラウド及び／又はＡＭＲのうちの１つで展開されている１つ以上のプラン及びタスク割り当て戦略に関連し得る。通知がＤＲモジュールに送られた場合、通知は、特定のプラン（例えば、充電及び／又はナビゲーションプラン）及びタスク割り当て戦略を特定する。一実施形態では、ＤＲモジュールは、クラウドノード上で動作するプラン実行エンジン及び／又はＡＭＲ上で動作するプラン実行エンジンにより実行される協調ステップに基づいてトリガ又は通知を行う。さらに、ＤＲモジュールは、ＡＭＲ上で起きているイベント及びプラン自体から収集された情報に基づいて通知又はトリガを行う。一実施形態では、通知又はトリガは複数のシナリオに対して開始され得る（例えば、ロボットが新たな能力を獲得するか又は新たな挙動をサポートして特定のタスク、例えば、ＡＧＶがロボットアーム能力を獲得し、異なる形で航行できるため、ＡＧＶの能力を高める必要があることを示すトリガがＤＲモジュールにより受信される）。ＤＲモジュールは、更新のために既存のプラン及び既存のタスク割り当て戦略を分析する。通知の分析に基づいて、ＤＲモジュールは本明細書で説明するように１つ以上のソリューションを特定する。ソリューショニングの一部として、ＤＲモジュールは、プランカタログからアーム能力のための適切なプラン及びタスク割り当て戦略を読み出し、本明細書で説明したようにそれらを展開する。加えて、ＤＲモジュールは、新たなプラン及びタスク割り当て戦略から異種のロボットに新たな一式のタスクを割り当てる。別の実施形態では、一群の装置に異なる種類の装置が加わるために通知が提起されてもよい。例えば、「グッズツーパーソン」ロボットが一群の装置に加わり得る。これにより、一群の装置に新たな装置が加わることに対処するためのソリューションを特定するために、ＤＲモジュールへの通知がトリガされ得る。ソリューションはシナリオに基づいて動的に特定され、ＤＲモジュールにより生成される様々なソリューションについて本明細書で説明した様々な例が存在する。生成されたソリューションに基づいて、ＤＲモジュールは、本明細書で説明したように、展開するための関連する１つ以上のプラン及びタスク割り当て戦略を特定する（３０４）。関連するプラン及びタスク割り当て戦略は新たなロボット挙動と整合するか又はサポートし得る。これらの例は限定的なものではなく、プラン及びタスク割り当て戦略の切り替え又は更新につながり得る任意の潜在的なシナリオは本発明の範囲内に含まれる。そのようなシナリオは、代替的な機構をトリガするか又は用いてプラットフォームが意思決定を行って、動的な要件に従ってプラン及びタスク割り当て戦略を切り替えることができるようにする。
【0070】
一群のＡＭＲに関連するイベントを積極的に監視している間に、特定のＡＭＲ若しくは複数のＡＭＲから又は内部的に通知を受信した後、ＤＲモジュールは、トラッキングする必要がある１つ以上のプラットフォーム、タスク割り当て戦略及びプラン変数（例えば、ロボットの待機時間、システムダウンタイム、ＡＭＲ上のエージェントのＣＰＵ消費時間等）のために通知されたプラン及びタスク割り当て戦略を分析する（３０２）。そのため、そのようなシナリオでは、実施形態のうちの１つは、カタログストアを分析して、本明細書で説明したように、変数のうちの１つに基づいて代替の又はより関連性の高いプラン及びタスク割り当て戦略を特定することを含む。例えば、プラン変数の１つは「システムパフォーマンス」であり得る。次に、特定のプランのために監視又はトラッキングされ得るプラン変数が包括的な方法で、例えばシステムのダウンタイムで定義され得る。プラン変数はａ）他のロボット（同様の種類のロボット又は他の種類）が通過できるように、ロボットが交差点でどれだけの時間待機するか、ｂ）充電ステーションに行く前に、ロボットは実際にどれだけの時間行列で待つかとしてカスタム化又は定義されうる。次いで、プランのパフォーマンスを分析するために、状態又は挙動がタグを付けるか又はマークされる。関連するプラン及びタスク割り当て戦略が特定された後、既存のプラン及び既存のタスク割り当て戦略は、関連するプラン及びタスク割り当て戦略で更新される（３０５）。
【0071】
別の実施形態では、ＤＲモジュールは、複数の要因を介して、例えば、履歴データを考慮して、代替的なより良いプラン及びより良いタスク割り当て戦略を抽出することに関連するソリューションを生成する。これらのソリューションは、通知を含み得るイベントの分析に基づいて生成される。「充電ステーションに行って所定の時間（例えば３秒間）並び、充電のための所定の時間ドッキングする」といったタスクを含む充電プランがあるシナリオを考えてみる。このプランでは、待機時間とは、フォークリフト／ＡＧＶ／ＡＭＲ又は一式のＡＭＲがドッキングのための充電スロットに至るために待つ時間である。そのため、このシナリオでは、プラットフォームの「バッテリの％レベル」という変数に基づいてゴーアンドチャージについての決定をするのにプラットフォームが影響を受けるか又はプランを再構成できる。そのため、包括的な方法で、プラットフォーム、具体的にはＤＲモジュールは「システムのダウンタイム」というプラットフォーム変数をトラッキングし、バッテリレベルが所定の閾値、例えばバッテリレベル６５％を下回った場合に、既存のプランは新たなプランにより置き換えられ、既存のタスク割り当て戦略は新たなタスク割り当て戦略で置き換えられて、ロボットに充電されに行くために所定の期間列で待ち、その後所定の期間充電されるようにする。プラン及びタスク割り当て戦略が置き換えられるか又は更新されると、プラットフォームは、更新されたプラン及びタスク割り当て戦略をクラウドデバイスシステム及び／又は複数のＡＭＲ上に展開する（３０６）。
【0072】
図４は、一実施形態に係る、自律モバイル装置のためにプラン及びタスク割り当て戦略を更新するためのプロセスステップを示す例示のフロー図である。一実施形態では、エージェントカタログにおいて、現在の状態を示すためにロボットの変数を更新できる。例えば、特定のＡＧＶは、変数「Ｍａｘｌｏａｄｆａｃｔｏｒ」の値が１００ｋｇであり得る。ＡＧＶがトロリ又はシャトルに接続されると、能力が増大して、変数「Ｍａｘｌｏａｄｆａｃｔｏｒ」の値は新たな総重量に、例えば２００ｋｇに増加する。ＡＧＶとトロリ又はシャトルとのこの接続から、ａ）ＡＧＶが所定の位置で回転する能力又は全方位ロボットが３サイクル駆動コントローラのように駆動できる単一方向ロボットで置き換えられ得ること及びｂ)ＡＧＶはピックアンドドロップのために当初の能力の二倍のものを扱つかうことができる、という２つの変化がシステムで反映される。ロボットはプラン実行エンジンに変更を報告し、次に、これらがロボットによって獲得された新たな能力であることをＤＲモジュールに通知する。そのため、通知は、これらの新たな能力のための１つ以上のプラン及び１つ以上のタスク割り当て戦略の更新につながる新たな能力に整合するソリューションを生成するためのＤＲモジュールのためのトリガがである（４０２）。ＤＲモジュールは、本明細書で説明するように新たに獲得された能力と整合するための追加のソリューションを生成し得る。
【0073】
ａ）ロボットのプラン及び役割が置き換えられ得る。例えば、譲受人のＰＡ－ＡＭＲロボット「Ｓｏｏｔｂａｌｌｓ」が「アーム」機能を獲得し、新たな役割を有する。ＤＲモジュールはプランカタログ及びタスク割り当て戦略カタログを検索して新たなプラン及び新たなタスクア割り当て戦略を探す（４０３）。特定されたプラン及びタスク割り当て戦略は先ず互換性の確認のために検証する必要がある。この互換性の確認は、正確なプラン及びタスク割り当て戦略がロボット上に展開されることを確実にするために、プラットフォームによりなされる積極的な方策であると考えることができる。互換性の確認は、ＡＰＩ、ロボットの種類、ロボットの能力、ロボットの挙動、ハードウェア、ソフトウェアの互換性チェック等のうちの少なくとも１つ以上を含み得る（４０４）。ＤＲモジュールにより、一群のロボット全体にプランの置き換えが通知される。
【0074】
ｂ）タスク割り当て戦略は、倉庫で展開された戦略が、一群のロボットからの１つ以上のロボットにより獲得された追加の能力のために構成する必要があることを示すために置き換えられ得る。これを詳細に説明する。ロボットが能力を獲得すると、ロボットは又はより高位のレベルで言えばロボット上で動作するプラン実行エンジンは先ずＤＲモジュールに通知する。次に、ＤＲモジュールはプランカタログ及びタスク割り当てカタログを調べ、関連するタスク割り当て戦略及び関連するプランを引き出す。互換性の確認により関連プラン及びタスク割り当て戦略を検証した後、これらのプラン及びタスク割り当て戦略を更新できる（４０５）。タスク割り当て戦略に焦点を当て、ＤＲモジュールがどのようにタスク割り当て戦略を更新するかを理解する。先ず、タスク割り当て戦略は、倉庫内の全てのロボットの最大耐荷力を１００ｋｇと定義する。プラットフォームがタスクのペイロード容量が１８０ｋｇのタスクを受信した場合、ＤＲモジュールはタスクを拒絶し、その能力が現在存在しないためタスクを実行することができないことを示す。しかしながら、ロボットが後にトロリ又はシャトルと連携されると、ＤＲモジュールは、そのイベント監視プロセスの間に、１８０ｋｇの負荷に耐えることができるロボットを特定する。そのため、１８０ｋｇのタスクペイロードを扱う能力が利用可能となったため、ＤＲモジュールは、１８０ｋｇのタスクペイロードを有するタスクを実行するために、タスク割り当てカタログから関連するタスク割り当て戦略を引き出す。特定の状況では、タスク割り当て戦略全体を引き出して現在のタスク割り当て戦略を置き換える代わりに、ＤＲモジュールは、ペイロードがより高い新たなタスクが確実に実行されるようにするために、効率を目的として、特定のロボットについて最大負荷計数（max load factor）という変数を１８０ｋｇにマッピングするだけでよい。ために、特定のロボットについての可変最大負荷率を１８０ｋｇにマッピングするだけでよい。その後、一群のロボット全体にこのイベントが通知される。他のシナリオでは、プラン変数及びタスク割り当て戦略変数が新たな値でマッピングされる。例えば、最大負荷計数が１００ｋｇから１８０ｋｇに増加されて、ペイロードがより高い新たなタスクが確実に実行されるようにする（４０６）。更新されたプラン及びタスク割り当て戦略は、クラウド及び／又は異種のＡＭＲ上で展開される準備ができている。このシナリオでは、ＤＲモジュールは更新されたプラン及びタスク割り当て戦略を、トロリに接続されたロボット上に展開する（４０７）。そのため、ワークロードの共同機能として、ペイロードが１８０を超える以前のタスクが拒否されたことをＤＲモジュールが全てのロボットに通知するが、新たな拡張された機能により重量のタスクを拒否する必要がない。そのため、トロリ又はシャトルに連携されたロボットは、負荷より高いタスクを行うためにより高い重み又は優先度を得る。ここで、トロリ又はシャトルを獲得した別のロボットを考えてみる。このシナリオはプラットフォームの堅牢性及び効率性を示す。一群のロボットが拡大されたペイロード容量を有することをシステム全体が認識しているため、ＤＲモジュールはより高い容量を示すために変数をマッピングする必要も、第２のロボットの新たな追加能力の獲得を更新するために新たなタスク割り当て戦略を引き出す必要もない。ＤＲモジュールは、一群のロボットから２つのロボットが追加の容量を有することを維持するだけでよい。そのため、複数の新たな重量タスクがある場合、２つのロボットは、これらのタスクを行うためにより高い重みを与えられる。
【0075】
ｃ）ＡＧＶ型のロボットのみが現在展開されているプランを扱うことができる場合を考えてみる。ＤＲモジュールは、システムで起きているイベントを監視しながら、フォークリフト型のロボットが一群のロボットに加わり、システムは新たなロボットとの連携の仕方を知らないことを検知する。一群のロボット上で展開されているプランは、ＡＧＶ型のロボットがそのデフォルトの支援任務となっており、フォークリフトには何の役割も与えられていないことから、ＡＧＶ型のロボットだけのために構成されている。この場合、フォークリフトが一群のロボットに加わる前に展開された現在プラン及びタスク割り当て戦略は、ＡＧＶがパレットの下に行って拾い上げ、目的地に行ってパレットを降ろすというものになり得る。この場合のタスク割り当て戦略では、パレットを移動し、持ち上げ、降ろすことに関連するタスクについて、アイテム毎に１つのロボット（ＡＧＶ）にしか割り当てられていなかった。しかしながら、１つ以上のフォークリフトが一群のロボットに加わることにより、フォークリフト及びＡＧＶの協働を確かなものにするためにタスク割り当て戦略及びプランを更新する必要がある。プラン及びタスク割り当て戦略は、フォークリフトがＡＧＶ上にあるアイテムを拾い上げ且つ荷下ろしし、ＡＧＶが目的地に航行し、別のフォークリフトが割り当てられてその目的地に到達し、その目的地でＡＧＶがアイテムを降ろすのを助けるというタスクがフォークリフト及びＡＧＶに割り当てられるように更新され得る。第１のシナリオでは、ＡＧＶはパレットの下を行ってそれを拾い上げる必要があるが、第２のシナリオでは、ＡＧＶは一定の半径内でフォークリフトの近くにある必要があり、フォークリフトが重労働を行って、ＡＧＶが荷下ろしするのを助け得る。
【0076】
ｄ）ハイブリッド型のシナリオでは、一部のロボットは拾い上げ及び荷下ろしを行う能力を失う反面、他のロボットは拾い上げ及び荷下ろしを行う能力を有する。ＡＧＶは拾い上げ及び荷下ろしができていたが、故障により拾い上げ及び荷下ろしができなくなった場合を考えてみる。フォークリフトが一群のロボットの一部である場合、ＤＲモジュールは、残りのロボットがフォークリフトと協働し、パフォーマンスが何ら低下することなしに倉庫内での作業を行うための利用可能な最小限の能力を用いることを強制し得る。そのため、高位のレベルで、プラン及びタスク割り当て戦略がどのように更新されるかを考えてみる。最初に、プラットフォームは各ロボットにタスクを割り当てる。ロボットにタスクが割り当てられると、ＤＲモジュールは適切なプランを特定する。このプランは、プラン実行のライフサイクルの間にロボットが実行する必要がある様々な状態及び挙動の概要を記述する。ＤＲモジュールが特定のイベントの通知又はトリガを受け取ると、プラン及びタスク割り当て戦略を更新する必要があり得る。このトリガは、ロボットの役割又は能力と、ロボットの能力がどのように追加又は除去されたかとを示す。そのため、追加又は削除により拡張又は低減された能力は、例えば、ＡＧＶがバーコードを検出する能力があるかどうか、ＳＬＡＭナビゲーション又は磁気ストリップナビゲーションを用いて航行できるか、フォークリフトはパレットを移動し、持ち上げ、降ろすことができる能力を有することができるかであり得る。そのため、一実施形態では、ロボットは一式の能力を有する装置とみなすことができる。これらの能力の追加又は削除に関連するイベントが発生した場合には常にイベントによってＤＲモジュールへの通知がトリガされる。そして、ＤＲモジュールは通知を分析し、現在のプラン及びタスク割り当て戦略が新たな能力の追加又は新たなロボットの追加のために構成されているかを検証するソリューションを生成する。検証の結果が負の場合、ＤＲモジュールは適切なプラン及びタスク割り当て戦略を見つけるためにカタログストアを検索する。そして、これらの新たなプラン及びタスク割り当て戦略がクラウド及び一群の異種の自律モバイルロボットにわたって展開される。
【0077】
一実施形態では、プラン及びタスク割り当て戦略の双方は互いに独立している。時折、プランは過去のプランの使用履歴に基づき正常であり、同様に、過去にはうまく機能したかもしれないタスク割り当て戦略があり得る。しかしながら、特定のシナリオで実施される上でそれらに互換性がなければ、ＤＲモジュールは現在の既存のタスク割り当て戦略及びプランは恐らく現在の状況で実施するのに最適であると判定し得るため、変更が要求されない。そのようなシナリオでは、ＤＲモジュールは、本明細書で説明する新たなプラン及びタスク割り当て戦略の更新又は置き換えを中止し得る。
【0078】
図５は、一実施形態に係る、プランを更新するためのプロセスステップを説明する例示のフロー図である。読みやすさ及び簡略化のために、プランのためのプロセスフローの場合を考えてみるが、プロセスフローはタスク割り当て戦略にも適用可能である。本発明は、ＡＰＩの互換性を判定することのみに限定されない。何故なら、互換性を判定するために他の要因、例えば、ロボットの種類、ロボットの挙動、ロボットの役割、ロボットの能力、ロボットのハードウェア、ロボットのソフトウェア、動作環境の要因、本明細書で論じた他の要因等も考慮されるからである。そのため、説明において、ＡＰＩの互換性は本明細書で説明される要因で置き換えられ得る。簡略化のために１つのプランのみを説明するが、本発明は１つのプランの比較に限定されず、本発明の範囲は複数のプランも含む。同様のアプローチが互換性の確認のためにタスク割り当て戦略にも適用可能であり得る。一実施形態では、展開されたプランを新たなプランで更新する前のプロセスステップを考え（５０１）、プラットフォーム又はＤＲモジュールは展開されたプラン及び新たなプランとの間のＡＰＩの互換性を判定するために確認又は検証を行い得る（５０２）。一実施形態では、ＡＰＩの互換性を判定することは、展開されたプランのＡＰＩのソフトウェアバージョンが新たなプランのＡＰＩのソフトウェアバージョンと一致するかを判定することを含む。一実施形態では、クラウドデバイス管理システムも、展開されたプランと新たなプランとのコードバージョンが一致することの確認を含む。展開されたプランのＡＰＩと新たなプランとが一致しないと判定された場合（５０２の条件はＮＯ）、クラウドデバイス管理システムはユーザインターフェース上に代替プランを表示する（５０３）。提案されるソリューションは、説明したソリューション又は本発明の範囲内でカバーされ得るソリューションに基づき得る。このステップは、ユーザ入力が必要とされ得る手動のものであるか又は本発明のより広い範囲内で想定される様々なシナリオに基づいてプラットフォームが自動的に決定する自動化されたものでもよい。
【0079】
次に、新たなプランと既存のプランとがＡＰＩ互換性を有する場合（５０２の条件が真の場合）、新たなプランの露出変数（exposed variables）及びタスクと、展開されたプランの露出変数及びタスクとをマッピングするために変数マッピングユーザインターフェースが表示される（５０４）。新たなプラン及び展開されたプランの１つ以上の露出変数及びタスクをマッピングするためにユーザ入力が受信される（５０５）。展開されたプランを実行するプラン実行エンジンが、新たなプランの露出変数に対応するロボット実行プランの変数の値を取り出せるように、露出変数名がマッピングされる。例えば、展開されたプランは、露出変数「速度」を有し、新たなプランは露出変数「速さ」を有し得る。変数マッピングユーザインターフェースで、露出変数「速度」が露出変数「速さ」にマッピングされる。展開されたプランを実行するプラン実行エンジンは、センサ及び実行データストアで「速度」の値を更新する（５０７）。新たなプラン実行エンジンは「速度」パラメータの値を取り出し、それを新たなプラン「速さ」変数に割り当てる。同様に、展開されたプランの「フォークリフトタスク」及び新たなプランの「車両タスク」がマッピングされる。
【0080】
次に、新たなプランがセンサ及び実行データストアにマッピングされる（５０６）。そして、展開されたプランを実行するためにプラン実行エンジンが起動される（５０７）。新たなプラン実行エンジンがクラウドデバイス管理システム及び自律モバイルロボットのうちの１つで展開される（５０８）。一実施形態では、新たなプラン実行エンジンは、プランの定義に基づいてクラウドデバイス管理システム及び自律ロボットのうちの１つで展開される。
【0081】
一実施形態では、既存のプランを実行するプラン実行エンジンは新たなプランの露出変数に対応するデータを取り出す（５０９）。一実施形態では、展開されたプランを実行するプラン実行エンジンは、展開されたプラン及び新たなプランのマッピングに基づいて新たなプランの露出変数に対応するデータを取り出す。最後に、取り出されたプランデータに基づいて、プラン実行エンジンは新たなプランを実行する（５１０）。新たなプランを実行した結果はセンサ及び実行データストアで更新される。
【0082】
図６は、一実施形態に係る、プラン及びタスク割り当て戦略を更新するためのプロセスステップを示す例示のフロー図である。一実施形態では、ＤＲモジュールは、本明細書で説明したようにプラットフォームレベル及びロボットレベルで起こるイベントを監視する（６０１）。ＤＲモジュールは、トラッキングされ得るプラットフォーム、プラン及びタスク割り当て戦略の全ての変数の値を分析し且つ記録する（６０２）。トラッキングされるべきこれらの値は、設計時に又はプラン及びタスク割り当て戦略自体において提供される所定の基準と比較され得る。所定の基準は様々な要因、例えば、倉庫で期待されるスループット（例えば、ピッキング支援ロボットによる毎時１００回のピッキング）に従ってカスタム化又は定義することができる。変数は、本明細書で説明した種々の要因に基づいて設定され得る閾値と比較され得る（６０３）。分析されたプラットフォーム変数、タスク割り当て戦略変数及び／又はプラン変数のうちの１つと、所定の基準又は所定の閾値とが比較された後、プラットフォームは、変数の値が閾値又は所定の基準よりも大きい場合は通知を無視するか又はイベントの監視を継続する（６０４）。しかしながら、値が閾値又は所定の基準を下回る場合、プラットフォームは、より良い代替プランに基づいて１つ以上のソリューションを生成、例えば、履歴データを分析してより良いプラン及びタスク割り当て戦略を特定する。ソリューションは、所定のインスタンスに対して過去にうまくいった、有効な、人気のある又は効率的なプラン及び／又はタスク割り当て戦略を特定することであり得る（６０６）。ＤＲモジュールのための次のステップは、より良い代替プラン及びタスク割り当て戦略が、クラウド及び／又は複数の異種デバイス上で展開されたプラン及びタスク割り当て戦略と互換性があるかどうかを検証することである（６０７）。互換性チェックは、本明細書で説明したように複数の実施を用いてなされる。プラン及び／又はタスク割り当て戦略に互換性がないか又は一致しない場合、ＤＲモジュールは、一式の次善のプラン及びタスク割り当て戦略を特定するための追加ソリューションを生成することに戻る（６０８）。互換性の確認の結果が肯定的であって場合、展開されたプラン及び展開されたタスク割り当て戦略は、より良い代替プラン及びタスク割り当て戦略で更新され得る（６０９）。そして、更新されたプラン及びタスク割り当て戦略は、少なくともクラウド及び／又は複数の異種の自律モバイルデバイス上に展開される（６１０）。
【0083】
一実施形態では、充電の目的のためのスロット管理又はロボットの行列待ちについて判定がなされるシナリオを考えてみる。プラットフォームは、履歴データに焦点を当てたソリューションを生成し得る。ＤＲモジュールは、より効率的な結果をもたらし且つタスクが正常に実行されることを確かにし得る１つ以上のプラン及び１つ以上のタスク割り当て戦略を取り出し得る。一実施形態では、生成されたソリューションは、履歴データの検索範囲を１つ以上の要因に、例えば、ナビゲーションの間に無線接続の問題又は照明の問題があった場合や、限定的なダウンタイムで特定のナビゲーションプラン及び／又はタスク割り当て戦略が成功裏に実行された可能性があるため、同じナビゲーションプラン及びタスク割り当て戦略が新たなソリューションの一部として再び取り出される、過去の、特定のクライアントの倉庫における装置又は倉庫レベルに狭めることを含み得る。
【0084】
一実施形態では、プラットフォームは、異なる種類のロボットのためのプラン及びタスク割り当て戦略の高い利用可能性を呈する。ナビゲーションプランの設計者がプランがある製品に対して、例えば、差動ドライブ又は他の同等のドライブを有する、譲受人であるＲａｐｙｕｔａ Ｒｏｂｏｔｉｃｓ社のフォークリフト製品に対してとりわけ有効であると述べるシナリオを考える。そのため、この種の情報は非常に特定的であり、一般的ではない。しかしながら、そのようなシナリオでは、プラットフォームは、元のプランと互換性があり且つ置き換えるために用いることができるプランの形態の追加の情報をユーザに提供する。例えば、プラットフォームは、特定の寸法を有する他社Ｘのフォークリフトのための別のナビゲーションプランを推奨し得る。そのため、そのようなシナリオでは、新たなナビゲーションプランは、新たなナビゲーションプランが旧プランと互換性があり、特定のプラン変数の不一致があっても旧ナビゲーションプランを置き換えることができるように定義され得る。この同じ戦略は、既存のプランの代替案を特定し、一群の異種のＡＭＲ上のタスク割り当て戦略を更新する間に、プラットフォームによって適用され得る。
【0085】
一実施形態では、プラットフォーム変数、プラン変数、タスク割り当て戦略変数のうちの少なくとも１つ以上と、所定の基準又は定義された閾値（例えば、ロボットのバッテリレベル全体の１０％未満のバッテリレベル、最小及び最大範囲内のナビゲーション時間、最小及び最大範囲内の拾い上げ時間及び荷下ろし時間等）との間の比較の後、プラットフォームはより良い代替案に基づいて、例えば、装置に対して割り当てられるか又は割り当てられるべきタスクに関連するタスク割り当て戦略に基づいてソリューションを生成し得る。例えば、「待機を続ける」こと及び「注文を処理する」ことという２つのタスクがある。そのため、ロボットはタスク割り当て戦略に従って注文を処理するか又は待機を続ける。倉庫内にフォークリフトが２台あり、２つの注文が発表された場合を仮定する。２つのフォークリフトが等距離にある場合、最適なパフォーマンスを得るために、適用され得るソリューションは注文を処理するためにバッテリレベルがより高いをフォークリフトを考慮し得る。そのため、ここでは、ソリューションは、注文を処理するタスクを行うためにバッテリレベルがより高いロボットに対してより高い親和性要因を含む。したがって、親和性要因を考慮して、関連する１つ以上のプラン及びタスク割り当て戦略が展開され、関連するタスクが展開され得る。別のシナリオでは、別のロボットのバッテリレベルが所定の基準又は閾値を下回る場合、ＤＲモジュールは、摩耗及び損傷を回避し、装置の寿命を延ばすために、ロボットに対して「待機を続ける」というタスク割り当て戦略が実行されることが最適であると考え得る。
【0086】
一実施形態では、倉庫内の特定の領域の注文を処理することを上記のタスクが含むことを考える。倉庫は、特定の種類のフォークリフト、例えば、よりスリムなフォークリフトしか狭い設計及び限定された作業領域で注文を処理することができない、複数のフロアレイアウトの領域又は倉庫の狭い区画を含み得る。そのため、ここでは、ＤＲモジュールにより生成されるソリューションは、一般的な種類のロボットの機能を制限する特殊な作業設計を有する困難な環境で動作可能なロボットの種類に依存して、適切なプラン及びタスク割り当て戦略を特定する追加の要因を含み得る。プラットフォームは、本明細書で説明した環境の問題、動作環境の問題等を解決するためにカスタム化された、関連するプラン及びタスク割り当て戦略を特定する。
【0087】
一実施形態では、プラットフォーム、プラン又は戦略内の変数を、閾値又はベースラインプラットフォーム変数でトラッキングされるようにユーザ、開発者又は第三者が定義できるようにする最優先の選択肢をプラットフォームが提供する。一実施形態では、開発者又はユーザは、トラッキングされるべきプラットフォーム変数は、特定のＡＭＲ又は一式のＡＭＲの実行される間の装置のパフォーマンス、装置の待機期間中に費やされた時間、装置が特定の段階（例えば、環境内のオブジェクトをトラッキング）にある場合の装置のＣＰＵ消費量又はロボット上で実行されるプラン実行エンジンが特定の状態（例えば、ピッキング、待機を続ける等）を何回訪問したかであり得る。プラットフォーム変数をカスタム化でき、例えば、ユーザがトラッキングを望み得るプラットフォーム変数のうちの１つは利用、システムダウンタイム、ＣＰＵ消費であり得る。トラッキングされ得るプラン又はタスク割り当て戦略のために同様の動作を行うことができる。
【0088】
一実施形態では、プランはインテリジェントで、再構成可能であり、要求されるタスクに応じて一式のＡＭＲを実行できるように一式のＡＭＲを動作させる能力を有する。例えば、ＡＭＲを充電するプランを考えてみる。プラン及び関連するタスク割り当て戦略がＡＭＲ上に展開された後、バッテリレベルが所定の閾値を下回る、例えばバッテリ寿命の６０％を下回るＡＭＲ又は一式のＡＭＲ上の特定の問題に関連するイベントについてＤＲモジュールがトリガされるか又は通知され得る。プラットフォームは常に一群のＡＭＲについて常に包括的に見ることができるため、プラットフォームは、特定のＡＭＲ又は一式のＡＭＲが充電に行く必要があるかどうか動的に決定し得る。プラットフォームは、ロボットの種類に基づいてロボットを優先するために、高いパフォーマンス及び効率を確かなものにするために適用され得る複数のソリューションを生成し得る。例えば、ロボットを直ちに充電のために移動させる代わりに行列で待つことができるか又は別のソリューションは、特定の種類の特定の組のロボット（例えば、フォークリフト）が最初に待ち行列に入るようにし、二番目に次の組のロボット（例えば、ＡＧＶ）を、そして後にロボットの残りを待ち行列に入るようにする。生成され得る他のソリューションは、在庫注文の優先順位（例えば、同日注文）に基づいてロボットを順序付けること又は特定のグループを実行可能なロボットの種類又は在庫注文の類似性に基づく、例えば、一群のロボット内の他のものよりも付加的なウェイトピッキング能力を有するロボットの能力等に基づく在庫注文のグループ化に関連し得る。順序付け又は優先化に関するこのソリューションは、倉庫所有者又はロボットソリューションプロバイダにより与えられる注文履行基準に従って変更できるか又は在庫注文自体により駆動され得る。プラットフォームによって確定されたソリューションに基づいて、代替案又は一連の代替案及び１つ以上のタスク割り当て戦略が適用されて、現在のプラン又は一式のプランを置き換えて、特定のＡＭＲ又は一式のＡＭＲが充電されに行くことを確かなものにする。同様に、割り当てられる必要がある一式のタスクが新たな一式のプランから特定され、その後、一群のＡＭＲに割り当てられる。プラットフォームは、ロボットが取り扱っている在庫注文優先順位、優先度の高い注文を処理するロボットを最初に充電すること、混雑又は障害回避、チーム又は一群のロボット内の他のロボットとの協調等の追加要因を考慮し得る。本発明はこれらの実施形態に限定されず、本発明の範囲は広範囲に及び、要求される最適結果を得るために１つ以上のプラン及びタスク割り当て戦略を更新するための関連ソリューションをプラットフォームが特定できるようにする他のシナリオを含む。
【0089】
他の実施形態では、プラットフォーム変数「システムダウンタイム」が充電プランのためにトラッキングされ得るユーザケースシナリオを考えてみる。プラットフォームは、この文脈で、どのロボットを最初に充電させるべきか決定しなければならない。先ず、ユーザは、トラッキングすべきプラットフォーム変数として、充電プロセスに伴う全体的な時間を定義する。これは、システムのダウンタイムに帰結し得る特定のＡＭＲ又は一連のＡＭＲが充電で消費する全体的な時間を示す測定すべきパフォーマンス変数であり得る。システム管理者、プロジェクトマネージャー又は倉庫所有者のために、プラットフォームは、例えば、一群のＡＭＲ全体の包括的な観点と、倉庫全体の「充電」の統計又は自動運転車両のための運転の全ルートを提供する。これは、「充電」プランの「システムダウンタイム」に関する情報がもたらされる。
【0090】
一実施形態では、ＤＲモジュールにより生成される、スイッチングプラン、タスク割り当て戦略及び意思決定のためのソリューションは、ロボットの異なる役割に基づいて決定され得る。特定のロボット、例えばフォークリフトのナビゲーションプランについては１つの役割しかない場合がある。しかしながら、Ｔｕｒｔｌｅｓｉｍのようなロボットの場合には、リーダ及びフォロワの２つの役割があり得る。前述したように、既存のプランの代替案として代替的な１つ以上のプランを特定するためにプラットフォームがソリューションを生成するシナリオを考えてみる。そのようなシナリオでは、プラットフォームは、ロボットの新たなナビゲーションプランをフォークリフトにマッピングする包括的なタスク割り当て戦略を適用し得る。主プランは、太った亀（fat turtle）と痩せた亀（lean turtle）の役割を有するのに対して、サブプランはリーダ及びフォロワの役割を有する場合を考えてみる。したがって、太った亀の役割のために、プラットフォームが既存のプランを置き換えるための代替プランとしてサブプランを特定した場合、その戦略は、リーダの役割に対しては親和性が高く、フォロワの役割に対しては親和性が低いサブプランにより高い優先度を与えることを含み得る。対照的に、痩せた亀の場合、プラットフォームがサブプランを代替案として特定した場合、その戦略は、リーダの役割よりもフォロワの役割に高い親和性を有するサブプランを検討することが含み得る。そのため、関連する１つ以上のプラン及びタスク割り当て戦略が展開され、関連するタスクが割り当てられ得る。この種の意思決定により、プラットフォームは、異なるレベルでプラットフォームが行う役割マッピング及びタスクマッピングに基づいて、堅牢で汎用性のあるものとなる。
【0091】
一実施形態では、堅牢且つ柔軟なプラットフォームは、ユーザがよりクリエイティブとなり、要件に従ってプラン、タスク割り当て戦略を定義できるようにする。例えば、プランがあり、ユーザは、ルートの待ち時間、実際のナビゲーションに費やされた時間、総走行距離のカウント、ナビゲーションが行われた回数、経路から外れた回数（最大偏差、最小偏差、ロボットが回転した回数）等のタスクに費やされた時間に焦点を当てプラン変数をトラッキングしたいと考え得る。これらは、開発者がプラン、例えばナビゲーションプラン固有にトラッキングを望むプラン又はタスク割り当て戦略変数の例である。プラン及び／又はタスク割り当て戦略をカタログストアに追加する間に、ユーザは、本明細書で説明するようにプラットフォームによるトラッキングを望む変数を指定することができる。
【0092】
本発明の実施形態のうちの１つでは、ユーザがプラットフォーム変数を指定した後に、プラットフォームは、古いプランを置き換えるための新たなプランを動的に決定する機能を開発者が可能にすることを必要とし得る。プラットフォームは所定の基準に基づいて、新たなプランで古いプランを動的に置き換えることができるようにすることを希望することに対して同意するよう開発者に通知し得る。例えば、倉庫内を航行している間に、プラットフォームが積極的に動作（例えば、ロボットのバッテリがなくなる前又は所定の閾値レベルを下回る前にロボットのバッテリを充電するリスク軽減ステップ）を行ってソリューションを生成し得るか又はユーザの許可に従ってプラットフォーム変数をトラッキングして、閾値を下回った場合に代替するための代替プラン又は関連プランを見つけるシナリオがあり得る。
【0093】
一実施形態では、既存のプランが、挙動が異なるロボットのために既存のプランを代替プランで置き換えるために、ＤＲモジュールにより生成され得る追加のソリューションを考えてみる。ＤＲモジュールは、新たな代替プラン及びタスク割り当て戦略がロボットの新たな役割又は挙動又は能力をサポートするか又は整合するかどうかについて、新たな代替プラン及びタスク割り当て戦略を検証し得る。プラットフォームは、ＡＭＲ内の既存のプランを置き換えるために代替プラン（例えば、ナビゲーション）を特定し得る。既存のプランに存在するプラン変数の値は、新たなプランのプラン変数により且つ新たなプランが展開されるＡＭＲの種類に基づいて更新する必要がある。例えば、ナビゲーションプランの場合、更新する必要のあるプラン変数のうちの１つはＡＭＲの寸法であり得る。この情報は、実際のプランが展開された場合に動的にマッピングされなければならない。そのため、フォークリフトのためのナビゲーションプランが展開された場合、プラットフォームは、カタログストアからの互換性のある製品タイプとプランとの適切なマッピングを確実にしなければならない。別の代替プランは、特定の種類のロボットが定義されていなくても、差動駆動のナビゲーションプランで置き換えられるべき円形ホイール駆動のＡＭＲ種類のロボットのためのナビゲーションプランである。
【0094】
一実施形態では、倉庫所有者は、サードパーティの開発者からプランをインポートする間に、トラッキングすべきプラットフォーム変数を示し得る。このプラットフォーム変数は「充電」プランに関連し、プラットフォーム変数は「時間」であり得る。これは、ロボットが「充電」と呼ばれる状態でどれだけの時間が費やされるかについてトラッキングする必要があるパフォーマンス変数であり得る。そのため、倉庫所有者は、ロボットの充電に費やされる時間がシステムダウンタイムにつながることに関心を有し得る。そのため、これは、システムダウンタイム及びシステムの全体的なパフォーマンスに影響を及ぼす非生産的なタスクで費やされる時間につながる。毎月の又は四半期毎のシステムのパフォーマンスを算出するために後で用いることができる一群の車両全体のための生産的な活動及び非生産的な活動の双方につながるこれらの種類のタスクを測定する方法をプラットフォームが提供する。
【0095】
高位のレベルでは、プラットフォームは、倉庫内でのロボットの全体的な状態及び充電の複合的な観点を提供する。この種の観点は、システム管理者又は倉庫のマネージャーがシステムのダウンタイムを計算し、是正措置を講じるために用いることができる。バッテリレベルが特定の閾値（バッテリー充電全体の１０％）を超えた場合に、状態が「危機的（critical）」となり、ロボットを充電のための行列に並ぶようにさせられ得る、タスク割り当て戦略に基づいて充電プランが構築されたシナリオを考えてみる。別のシナリオは、バッテリレベルが「危機的」でなく且つ倉庫内の作業負荷が最小である場合である。充電の決定を行うために生成される様々なソリューションは以下のようなものであり得る。
ａ）バッテリレベルが「危機的」状態の場合は、タスクを「充電のために行列に並ぶ」に更新する。
ｂ）作業負荷が最小で、バッテリレベルが「危機的」状態ではない場合、充電タスクが「Ｙｅｓ」に高められ、バッテリレベルが「危機的」状態に達した場合、ロボットのタスクは「行列に並んで充電」に更新される。
ｃ）代替的なソリューションは、タスクを更新して、積極的な充電を推し進めることであり得る。そのため、バッテリレベルが「危機的」状態（例えば、バッテリレベルが１０％以下）ではないが、倉庫内の作業負荷が低い場合でも、システムはより多くのタスクが来ることを予期しない。このようなシナリオでは、タスクは「ロボットは充電のために行列に並ぶことを進める」に更新され得る。
ｄ）状態が「危機的」ではなく、作業負荷（低、中、高）に基づいて、プラットフォームはどのロボットを充電に行かせるかを決定する。この戦略は、ロボットの種類及びメーカ（例えば、フォークリフトモデル対ＡＧＶモデル）等を含み得る。
そのため、ここで生成されたソリューションを考えると、「充電」の実際の挙動は同じであるが、意思決定を行うために必要なソリューションは、文脈、環境、ロボットのハードウェア、ロボットの状態によって異なる。そのため、ＤＲモジュールが通知を受け取るか又はトリガされると、ＤＲモジュールはプラットフォーム変数又はプラン実行エンジン若しくはＡＭＲのいずれかにより共有された情報を分析し、次に、ＤＲモジュールは、本明細書で説明した様々なソリューションに基づいて「充電」プランが置き換えられる必要があることを認識する。一実施形態では、タスクはソリューションに基づいてロボットにも割り当てられ得る。ここで、プラットフォームがなすべき決定は、倉庫がどのように運営されるか、その勤務時間（午前９時～午後５時又は夜勤）、そのようなシナリオを実施するための顧客の要求についての様々な関数に応じて特定のソリューションを生成することであり得る。例えば、ソリューションは、プロセスを自動化するための顧客のニーズに従って適合され得る。加えて、通常の就業日に、倉庫内の作業負荷が平常である場合、プラットフォームにより確定され且つ生成される充電タスク割り当て戦略は、プラットフォームが、リスク軽減ステップ又は防災を取るか又は最適なパフォーマンスメトリックのために、ロボットが充電のために行列に並ぶようにすることが確実になるよう充電タスクを実行し、プランを展開するソリューション（ｃ）となり得る。
ａ）バッテリレベルが「危機的」状態の場合は、タスクを「充電のために行列に並ぶ」に更新する。
ｂ）作業負荷が最小で、バッテリレベルが「危機的」状態ではない場合、充電タスクが「Ｙｅｓ」に高められ、バッテリレベルが「危機的」状態に達した場合、ロボットのタスクは「行列に並んで充電」に更新される。
ｃ）代替的なソリューションは、タスクを更新して、積極的な充電を推し進めることであり得る。そのため、バッテリレベルが「危機的」状態（例えば、バッテリレベルが１０％以下）ではないが、倉庫内の作業負荷が低い場合でも、システムはより多くのタスクが来ることを予期しない。このようなシナリオでは、タスクは「ロボットは充電のために行列に並ぶことを進める」に更新され得る。
ｄ）状態が「危機的」ではなく、作業負荷（低、中、高）に基づいて、プラットフォームはどのロボットを充電に行かせるかを決定する。この戦略は、ロボットの種類及びメーカ（例えば、フォークリフトモデル対ＡＧＶモデル）等を含み得る。
そのため、ここで生成されたソリューションを考えると、「充電」の実際の挙動は同じであるが、意思決定を行うために必要なソリューションは、文脈、環境、ロボットのハードウェア、ロボットの状態によって異なる。そのため、ＤＲモジュールが通知を受け取るか又はトリガされると、ＤＲモジュールはプラットフォーム変数又はプラン実行エンジン若しくはＡＭＲのいずれかにより共有された情報を分析し、次に、ＤＲモジュールは、本明細書で説明した様々なソリューションに基づいて「充電」プランが置き換えられる必要があることを認識する。一実施形態では、タスクはソリューションに基づいてロボットにも割り当てられ得る。ここで、プラットフォームがなすべき決定は、倉庫がどのように運営されるか、その勤務時間（午前９時～午後５時又は夜勤）、そのようなシナリオを実施するための顧客の要求についての様々な関数に応じて特定のソリューションを生成することであり得る。例えば、ソリューションは、プロセスを自動化するための顧客のニーズに従って適合され得る。加えて、通常の就業日に、倉庫内の作業負荷が平常である場合、プラットフォームにより確定され且つ生成される充電タスク割り当て戦略は、プラットフォームが、リスク軽減ステップ又は防災を取るか又は最適なパフォーマンスメトリックのために、ロボットが充電のために行列に並ぶようにすることが確実になるよう充電タスクを実行し、プランを展開するソリューション（ｃ）となり得る。
【0096】
本発明の他の実施形態では、顧客は、デフォルトのソリューションが（ａ）「充電」のシナリオに関連する状況が生じたときは常にプラットフォームが選択するように生成されることを望み得る。クライアントは、バッテリが閾値レベル又は危機的な段階を超えるまで、ロボットが倉庫内で作業を続けることを望み得る。呼び出すべきこのデフォルトのソリューションは、バッテリ寿命の低下又はロボットの他の磨耗や破損等の結果をもたらし得る。同様に、プラットフォームが生成し得る他の代替ソリューションは、充電スロットが倉庫内で限られているため、作業負荷が少ない中での最良のソリューションは、ソリューション（ｂ）であり得ると顧客が考え得るものである。プラットフォームはソリューションを生成し、ソリューションに基づいて関連プランを読み出し、更新されたプランを適用し、更新されたプランをロボット上で展開する。ＤＲモジュールにより生成されたソリューション（ｂ）で定義されているように、ロボットを行列に並ばせて充電させるためにタスクが更新され得る。このソリューションでは、ロボットは危機的なバッテリレベルに達するのを待たず、顧客により指定された他の所定のプラットフォーム変数を用いて、割り当てられるべきタスクはロボットが所定のスロット内で積極的に充電されることを確実にする。
【0097】
一実施形態では、何時充電に行くかについての動的な意思決定自体も、ＡＭＲ及び／又はクラウドデバイスシステムにより見られる在庫作業負荷、充電スロットのタイミング、充電スロットの可用性等の他のプラットフォーム変数に依存する。加えて、ＡＭＲ上で実行されるプラン実行エンジンは、しばらくそれらをナビゲートし、ロボットのパフォーマンス及び倉庫で動作しているソリューションに基づいて適用すべきソリューションを決定し得る。このアプローチはどちらかと言えば、ロボットがパフォーマンスを見て代替的なソリューションをテストする「学習」メカニズムであり得る。ＡＭＲ及び／又はクラウドデバイスシステムはパフォーマンスを比較し、この学習は、ＤＲモジュールが最適なソリューションを選択するために変化するシナリオに自動的に適合するのを助ける。ここで考慮したシナリオは、意思決定が本明細書で説明するようにクラウドノードからの共同作業を伴い得るため限定されない。
【0098】
一実施形態では、プラットフォームは充電プランを取り除き、それを本明細書で説明するように最適なソリューションに基づく代替プランで置き換え得る。そのため、トラッキングされ得るプラットフォーム変数のうちの１つは、ロボットが充電の間に又は充電を待つ間に費やす時間のための最適なソリューションを決定する間の「全体的なシステムのダウンタイム」であり得る。監視されるイベントに基づいて、ＤＲモジュールは行動を起こすようトリガされて、プラットフォームは、本明細書で説明するように新たな充電タスク割り当て戦略を決定し得る。プラットフォームは各タスク割り当て戦略のパフォーマンスを分析し、比較に基づいてパフォーマンスの低下がある場合に最良のタスク割り当て戦略を特定する。本発明の一実施形態では、ナビゲーション又は充電プランに関するシナリオを考えてみる。ユーザは、倉庫の営業日の間にプラグ可能であり得るか又は選択され得る戦略Ｘ、戦略Ｙ又は戦略Ｘ、Ｙ及びＺの組み合わせを行うことを望み得る。これらのシナリオでは、プラットフォームは、タスク割り当てカタログから様々な利用可能なタスク割り当て戦略からタスク割り当て戦略を選択し得る。加えて、プラットフォームは、実際の在庫注文について実際のロボットがシミュレーションで動作するシミュレーションのオプションをユーザに提供する。ユーザは、シミュレーションに基づいて一部のタスク割り当て戦略を承認できる。ＤＲモジュールはタスク割り当て戦略、ロボットのパフォーマンスを監視し、全体的なパフォーマンスを改善するために戦略を考慮できるように、最適に動作するタスク割り当て戦略を生成する。
【0099】
一実施形態では、特定の決定に達する前に考慮され得る他の潜在的なソリューションが存在し得る。一群のＡＭＲが航行しているシナリオを考えてみる。プラットフォームはパフォーマンス及び挙動を継続的に監視するため、プラットフォームはロボットが別のロボット又は一式のロボットが通過するのを待つのに費やす時間を観察し得る。そのため、非効率性又はシステムのダウンタイムを低減するために、ＤＲモジュールはプラットフォーム変数、通知情報、ロボットから受け取った情報を積極的に分析し、衝突又は混雑の最小化又はシステムダウンタイムの状況を回避するための最適なソリューションを生成し得る。一実施形態では、ＤＲモジュールは、新たなプラン及びタスク割り当て戦略を特定して動作環境におけるランタイムイベントに対処することを含み得るソリューションを生成する。そのため、衝突を避けるために、生成され得るソリューションは、（ａ）信号と同様に、ロボットのうちの１つは他のロボットが通過できるように停止し得ること、（ｂ）特定の地点では停止する必要はないが、衝突経路に近づくとロボットが減速する一方、他のロボット又は一式のロボットは速度を上げることができること、であり得る。ここで、考慮され得るプラットフォーム変数は「速度」であってもよく、これは、速度の違いに基づいてロボットは単純に互いを通過することができることを示してもよく、（ｃ）例えば、倉庫のような環境における倉庫レイアウト、特定の要因（ＷｉＦｉ接続、電源供給負荷、航行の間の照明の問題、より良い航行のためのインフラのカスタム化等)といった外的要因が意思決定に何らかの役割を果たし得る。プラットフォームは様々なシナリオ、歴史的傾向、文脈、状況、プラン及び／又はタスク割り当て戦略間の互換性の問題、倉庫環境要因、ロボットの挙動若しくは能力又は役割等の狭い特徴を考慮した上で適切なソリューションを考慮し得る。
【0100】
一実施形態では、プラットフォームは、倉庫所有者、ソリューションプロバイダ及び顧客が直面するリアルタイムの問題、例えば、販売促進、１日又は数時間の販売オファー等に対処する。そのようなシナリオでは、倉庫は大量の在庫注文を受け取るか又は要求が急増し得る。これらは、年間を通してトラッキングできる通常のシナリオではない。これらのオファーは短期間にユーザに提供され得るものであるため、注文処理タスクはあまりにも煩わしく且つ複雑であり、リアルタイムの意思決定が必要となる。この間、倉庫は作業の急増、混雑につながるナビゲーションマップの急激な変化、フォークリフトの迂回、充電にロボットがより多くの時間を費やす等の問題に直面する。プラットフォームの観点からは、これがプラットフォーム変数の変化に反映されるためにプラットフォームは自己意識するため、システムはこの変化に適応する必要がある。この変化に適応するために、プラットフォームは、最終的にＡＭＲ上で実行されるプラン実行エンジンに切り替えを行わせ、新たなプランを検討させる指示につながるソリューションを生成する。例えば、システムは生成された戦略に基づいて、例えば、ロボットのスピンターン又はロボットが取るべき方向を低減するために、より良いナビゲーションプラン、より良い在庫順序割り当てプラン等を引き出して、要求の突然の急増に対処するための代替プランを見つけなければならない。
【0101】
一実施形態では、プラットフォームは、要求の急増を、遭遇したことがあり且つ既に処理された問題とみなす。プラットフォームは、カタログストアの一部であるプランカタログ及びタスク割り当てカタログで利用可能な代替プラン及びタスク割り当て戦略を探す。これらの代替プランは、他のロボット、例えばフォークリフトとタスク割り当て戦略がどのように行われたか、特定のタスク割り当て戦略が異なる種類の倉庫で他のロボットとどのように作用したか等の過去のプラン変数に基づいて、１つ以上のソリューションに基づき特定される。プラットフォームはこれらのタスクを自動的に行い、プランは「積極的（aggressive）」と呼ばれるモードにフラグされる（flagged）。このモードでは、システムは、システムダウンタイムを減らすためのタスクを最適化して全てが機能することを確かなものにする。
【0102】
一実施形態では、システムは、作業負荷が低いこと又は次の数時間は在庫注文が少ないことを検出するため、プラットフォームは、ロボットの部品の摩耗及び破損を回避するために最適になるようにソリューションをインテリジェントに生成する。本明細書で説明したように、プラットフォームは、プラットフォーム、プラン及びタスク割り当て戦略変数のうちの１つと、所定の基準値又は閾値との間の比較に基づいて、最適なソリューションを特定し得る。プラットフォームは、本明細書で説明したように、顧客が定義したプラットフォーム変数及び歴史的なプラットフォーム変数も考慮し得る。プラットフォームは、閾値が満たされたか又はまだ満たされていないこと（例えば、バッテリ充電のベースラインプラン変数はバッテリレベル全体の１０％であり得る）に対抗するために代替プランが特定されることを確実にし得る。プラットフォームは、最適なパフォーマンスのための代替的な又はより良いプランを特定しながら、特定されたプランは、本明細書で説明したように分析されたプラットフォーム変数と所定の基準との間の比較に基づいて生成された最適なソリューションに基づくプラン変数を有すること確かなものにし得る。
【0103】
一実施形態では、プラットフォームは、故障又は倉庫の異なる階の間の移動（例えば、１階から２階へ）等のシナリオに直面し得る。ＤＲモジュールは、航行の間のフォーク上昇ダウンタイム（fork rise downtime）等のタスクのための最適化を含む戦略を考慮し得る。他の同様のシナリオでは、ＤＲモジュールは、ロボットの磨耗及び破損を回避することを考え、ロボットが行うスピンターンを最適化するか又はロボットを待たせ、航行のためのより良好な経路を取らせるよう最適化されることを望み得る。これは、本明細書で説明したように、パフォーマンスプラン変数又は閾値を含めることにより行うことができる。ＤＲモジュールは一群のＡＭＲを監視しているため、ＤＲモジュールはプラットフォーム変数を記録し、一部のプラン変数のパフォーマンスが閾値以下になったことが報告されたこと又は故障があった場合、ＤＲモジュールに緊急措置をとるよう通知される。なお、ＤＲモジュールは、本明細書で説明するように、プラットフォーム、プラン又はタスク割り当て戦略変数の閾値が超えられることにより通知され得る。このシナリオでは、ロボットはそれ自体でリカバリできない可能性があるため、ＤＲモジュールはタスク割り当てカタログから関連する代替的なタスク割り当て戦略を抽出する。例えば、ナビゲーションプランオプションを最適化し、例えば、ＡＧＶ又はフォークリフトの種類といったエージェントのためのプランを抽出し、そのプランが、リカバリが必要であり得る現在のロボットのプランと互換性があることを確かなものにすることが目的の１つであり得る。ここで、一実施形態では、プラットフォームは、ＡＭＲ及び／又はクラウドノード上で実行される１つ以上のプラン実行エンジンにより実行されている現在のものよりも良好に動作したプランを記録する。プラットフォームは、高いパフォーマンスのプランをリアルタイムで取り出すタスク割り当て戦略を適用し、それらを展開してそれらのパフォーマンスの監視を続ける。
【0104】
一実施形態では、ハイブリッドなロボットのチーム（例えば、ＡＧＶ及びフォークリフト）が存在し、ナビゲーションプランが実行されているシナリオを考えてみる。設計の間、ユーザは、プランを実行し得る異なる種類のロボット又はＡＧＶ又はフォークリフトの数を言及できる。プランを定義する間、プラットフォームは単にナビゲーションのためのプランを引き出す代わりに、特定のチームに２つの特定種類のロボットが存在し得ることを示すためにカタログストアからエージェントカタログも引き出すことができる。フォークリフトの場合、プラン変数は、フォークリフトの寸法、ターンイン半径（turn-in radius）、フォークリフト最大容量等として定義され得る。ナビゲーションプラン及びエージェントカタログは、ロボットがどのように展開され、どのような制約が置かれ得るかの点でプラットフォームに柔軟性を与える。例えば、エージェントカタログは検索範囲を狭めるのに役立ち、フォークリフトが単一の車輪で動力を与えられ、特定のターンイン半径を有するため、ナビゲーションプランがさらにロボットが所定の位置で回転できるか否かをさらに示し得ることを示し得る。これらのプラン変数は、異なる２種類のロボット（ＡＧＶ及びフォークリフト）が展開され得る場合に動的にマッピングできる。ロボットが展開されると、プラン変数は自動的にマッピングされる。ここで、一実施形態では、ＤＲモジュールは、ナビゲーションプランがフォークリフトに行くので、ロボットはインプレースナビゲーションを行うことができず、プラン変数がこの定義に従ってマッピングされることを確実にするソリューションを生成し得る。そのため、プラットフォームは正確なプランを読み出し、プラン変数を正確にマッピングし、プランに従ってそれらを特定のロボットに展開することを決定する。
【0105】
一実施形態では、展開された各プラン及びタスク割り当て戦略は、代替案を探すステップを行うために、新たな能力が追加されているか又は取り除かれているかを検証するためにＤＲモジュールによりチェックされる変数を有し得る。同様に、ロボットの寿命の間に起こる多くのイベントがあり、それらはＤＲモジュールによる即時の又はスケジュールされた注意を必要とし得る。これらのイベントは能力の変化、１つ以上のロボットの追加、ハードウェア／ソフトウェアの故障、倉庫内のインフラの変更、ナビゲーションの問題、充電の問題、前例のない新たな又は歴史的な問題等様々であり得る。本発明の範囲は限定されず、異種の装置の作業環境内で起こり得る他のイベントであって、ＤＲモジュール及びより高位のレベルではデバイスプラットフォームの注意を要し得るイベントを含み得る。
【0106】
一実施形態では、動作環境でリアルタイムシナリオを取り扱うプロセスのためのソリューションを生成する際の複雑さに関連する以下の詳細を考えてみる。タスクの数がＸであると仮定して、ＤＲモジュールのタスクはロボットの数をカウントし、移動すべき距離を最小にすることに基づいてタスクを割り当てることであり得る。１０個のタスク及び５つのロボットがある場合を考えてみると、第１のステップは、５つのロボットに割り当てられるべき５個のタスクを先ず選択することであり得る。問題は、どの順番でそれらを取り上げられ得るかである。実施され得る複雑なタスク割り当て戦略は、費やされる時間全体を最小限にするために取ることができるルート上の「巡回セールスマン問題」であるか又は最も近くの拾い上げタスクにロボットを割り当てるより単純なタスク割り当て戦略を考える。次に、別のタスク割り当て戦略は、一晩中に処理すべきタスクが１０００個あり得るため、タスク割り当て戦略をタスクレベルではなくバッチレベルで最適化することであり得る。そのため、一実施形態では、適切なタスク割り当て戦略を選択するために、要因のうちの１つはロボットが取り扱い可能な最大負荷要因を計算することであり得る。１０００台のロボットを扱ういくつかのタスク割り当て戦略があり得る。４０００以上の注文（４つの注文／ロボット）があり得るため、バッチ全体の秒単位の連続計算（continuous per second calculation）を行うことは実行可能ではなく、最適化は複雑なタスクであり得る。実施され得る別のタスク割り当て戦略は、ロボットの種類を区別することであり得る。そのため、ソリューションは、ＡＧＶとフォークリフトとを一緒に作業させ、１：１の係数で同じタスクに割り当てることを伴い得る。そのため、各タスクは、タスクを処理するために割り当てられた１つのＡＧＶ及び１つのフォークリフトを有し得る。そして、タスク割り当て戦略は、ＡＧＶが初期状態（ＡＧＶがピックアップロケーションに近づく）にある場合に別のフォークリフトを割り当ることを伴い得る。フォークリフトは、ＡＧＶが最終状態に達した場合に、すなわちＡＧＶが荷下ろしの目的地に到達した場合に、目的地に到達するタスクが割り当てられ得る。
【0107】
そのため、第１のタスク割り当て戦略は、ロボット間に区別がない一般化された戦略であり得る。そのため、このタスク割り当て戦略でサポートされる役割は、先に開示したように、全てのロボットがサポートされることを意味する「＊」で表され得る。一実施形態では、タスク割り当て戦略のうちの１つは、タスクを行うために２つの種類のロボット（ＡＧＶ及びフォークリフト）のみがサポートされ得る。しかしながら、倉庫のある領域にピッキング支援ＡＭＲがある場合、ＤＲモジュールのために生成されるソリューションは、一式のＡＧＶ及びフォークリフトを含む一群にピッキング支援ＡＭＲを搭載することを含む。そのため、ＤＲモジュールは、ピッキング支援ＡＭＲとアームとが協働することを伴うタスク割り当て戦略をタスク割り当てカタログから特定するためにスキャンする。そのようなタスク割り当て戦略が見つかった場合、特定されたタスク割り当て戦略は、ＡＧＶ及びフォークリフトのみに有効な他のタスク割り当て戦略と共に用いられ得る。このソリューションにより、ＤＲモジュールは、ＡＧＶ、フォークリフト、ＡＲＭ機能に拡張されたピッキング支援ＡＭＲのような完全に異なる種類のロボット間の協調を実行し得る。これにより、倉庫等の動作環境で遭遇する任意の種類のランタイムシナリオに対して、プラットフォームをカスタム化でき且つ堅牢なものにする。
【0108】
一実施形態では、タスク割り当て戦略は、ナビゲーションプランは移動可能な全てのＡＭＲをサポートし得ることを示し得る。これらのうちのいくつかはＮＰ困難な問題であるため、ほとんどの場合、最良のソリューションが見つかる保証がない。時間枠を考えれば、得られる最良のソリューションは、ＤＲモジュールによるプラン及び／又はタスク割り当て戦略を検討するための選択されたソリューションと考えられる。そのため、最良のソリューションを見つけるために、本明細書で説明の要因に加えて、他の要因はカットオフ時間、何が予想されるか、タスク割り当て戦略が対象とするスケールに基づいて通常どれだけ要するか又は最大負荷率が１００の場合にタスク割り当てのために通常どれだけの時間が費やされるか等を含み得る。
【0109】
一実施形態では、プランは複数の状態、例えば１００の状態を含み得る。プラットフォームは、ユーザが各状態又は特定の一式の状態をトラッキングしなければならないかを設計時に定義できるようにする機能を提供する。プラットフォームは、例えば、ＡＭＲが倉庫内を航行する間に、ユーザが展開後に意思決定を先延ばし（push back）できるようにする。ユーザは、プランランタイム、航行の間又は展開後の任意の時に全ての状態をトラッキングする必要があると包括的に言うことができる。プラットフォームは、デフォルトで、一般的なプラットフォーム変数又は特定のプラン変数又はタスク割り当て戦略変数をトラッキングする。このトラッキングのため、ユーザは、プラン内で特定のプラットフォーム変数を有効にし得る。一般的なプラットフォーム変数は、「ロボットがどれだけの時間をプランに費やしたか」又は「プランを実行するのに実行エンジンはどれだけの時間を費やしたか」又は「プランの特定の状態で実行エンジンはどれだけの時間を費やしたか」であり得る。本明細書で説明するように、一般的なプラン変数は、ナビゲーション若しくは充電プラン又はピッキング若しくは仕分けタスク等の全てのプラン又はタスク割り当て戦略にわたって適用可能な変数であり得る。プラットフォームはこれらの変数をユーザ又は開発者に公開し、ユーザ又は開発者は特定の又は一式の一般的なプラン変数をＤＲモジュールでトラッキングする必要があると後で指定し得る。挙動又はプラン固有の変数の場合、変数の一部は「航行の間に何回回転したか」又は「ロボットが通るべき経路からロボットは何回外れたか」であり得る。一実施形態では、プラン固有変数をトラッキングするために、プラットフォームは、ユーザが最初に構成を具体的に行うことを期待し得る。さもなければ、プラットフォームはプラン固有変数をトラッキングすることができないことがある。
【0110】
一実施形態では、プラットフォーム変数のトラッキングは２つのレベル（ロボットレベルで又はプラットフォームレベルのより高位のレベルで）で行われる。ロボットレベルでは、低位レベルの詳細にはロボットの挙動のより多くの文脈があるため、ロボットは依然として低位レベルの詳細を収集する必要がある。ロボットが行う決定毎に全ての詳細がクラウドデバイスシステムに必ずしも送られるわけではない。これは、クラウドデバイスシステムのレベルで分析される膨大なデータにつながり得るからである。そのため、ロボットが航行の間に回転又は移動又は停止した場合、細部レベルの詳細を有するのはロボットである一方、抽象レベルの詳細はクラウドデバイスシステムに伝達される。そのため、トラッキングの第１のレベルは常にロボットレベルで行われる。ここで、先ず、トラッキングされ得る変数がロボットに伝えられる。これらの変数はクラウドデバイスシステムのＤＲモジュールによってもトラッキングされる。そのため、ロボット及びクラウドデバイスシステムの双方は、変数をトラッキングするための互いの能力を高め合う。そのため、クラウドデバイスシステムのＤＲモジュールは、一群の異種のロボットから変数の値を受け取る。異種のロボット全体で実行されるプラン実行エンジンはロボット変数の処理を行って、その値を、処理のためにクラウドデバイスシステムのＤＲモジュールと共有する。ＤＲモジュールは、様々なロボットにより報告される変数の全ての値の意味を理解しなければならない。一群の１０台の異種のロボットを考えてみる。特定のロボットが所定の閾値基準を超え、このことがクラウドデバイスシステムのＤＲモジュールに通知される。その後、ＤＲモジュールは通知を分析してプラン又はタスク割り当て戦略を更新するためのソリューションを生成する。一実施形態では、プラットフォームの目的の１つはマルチロボット協調であり、一式のロボットはチームとして機能するため、行われ得るタスク割り当ては一群のロボット全体のために行われる。そのため、ＤＲモジュールは、ロボットのチームが同期され、タスクが実行され得るかを全てのロボットが知ることを確実にする。新たなプランは、特定のロボットだけのために更新されるのではなくロボット全体のために更新されるため、一群のロボットの全てがチームとして働き、プラットフォームがマルチロボット協調を確実にすることができる。例えば、ＡＭＲのチーム内に新たな能力を獲得するＡＭＲ、例えば、アーム能力を獲得するＡＧＶが１つある場合を考えてみる。依然、ＡＧＶはＡＭＲのチームと協力しなければならない。ここで、ＤＲモジュールが能力を獲得したＡＧＶのためだけにプランを置き換えた場合、マルチロボット協調を維持することが困難となる。そのため、ＤＲモジュールは、各チームメンバーがそれらの能力に従ってタスクを行うことができるようにすることにより、マルチロボット協調を確実にする。そのため、このチームレベルの能力を得るために、ＤＲモジュールは、異種の装置のチーム上でタスク割り当て戦略及びプランの更新の展開を推し進め得る。
【0111】
一実施形態では、上記の例のために実施されるべきタスク割り当て戦略を考えてみる。生成されたタスク割り当て戦略は、この、一群のロボット内の一ロボットにより獲得された新たな能力の変化を構成し得る。生成されたソリューションに基づいて同じタスクがチームに割り当てられるが、新たな能力を獲得したロボットが優先される。例えば、ＡＧＶはアーム能力を獲得したか又はシャットル若しくはトロリと提携され、タスクを行う上で他のロボットよりも好ましい場合がある。このように、プラットフォームは、異なる種類のロボット間のマルチロボット協調を確実にする。これには、そのようなシナリオを扱うためにロボットとクラウドデバイスシステムのＤＲモジュールとの間でメッセージ通信が行われる協調的なアプローチが必要となる。
【0112】
例えば、「充電」プランは「特定の種類のロボット（例えば、フォークリフト）にどれだけの時間が費やされたか」又は「ロボットが航行していたとき、ロボットは何回ターンしたか若しくは何回回転したか又はロボットはスピンターンしたか」等のプラットフォーム変数を有し得る。ルートナビゲーションの別のシナリオを考え、ロボットはより低い第１のターン（lower first turn）をとり、その後通路から外れ得る。そのため、プラットフォームは経路を計算する間に経路の距離に基づいて計算し、異なる段階で回転するロボットを不利にしない。これらの段階は、航行の間に９０度ターンすることであり、相当なもの（substantial）であり得る。そのため、開発者又はユーザは、一般レベルのプラン変数の定義又は非常に特定のレベルの詳細のいずれかをトラッキングのために用いることができる。ユーザは、本発明の実施形態のうちの１つにおいて、各ＡＭＲ又は一群のＡＭＲ上のエンドエンドステータス（end-end status）更新、パフォーマンス、トラッキングされたプラン変数の状態のレポートをエクスポートするか又はユーザインターフェースで見られ得る。
【0113】
一実施形態では、プランが展開された後、プラットフォームは一群のＡＭＲを監視し、倉庫内の現在の用途のために、ＡＭＲが特定のタスクを行うこと、例えば倉庫内で人の後を追うことができるか又はより効率である場合（別のシナリオでは、ロボットは動き回っておらず、特定の場所で人が来て荷下ろしすべき物体を置くのを待っていてもよい）にソリューションを生成し得る。そのため、後者の場合、ＤＲモジュールはプランからロボットを撤退させることを決定し得る。人とロボットとの協調、ミッションからロボットを撤退させること、タスク割り当てに関するこれらの全ての機能はプラットフォームによって扱われる。
【0114】
一実施形態では、プラン及びタスク割り当て戦略のモデリングの間に、ユーザ又は開発者は、ランタイムで決定が行われる方法に影響を及ぼすために様々なプラットフォーム変数を選択し得る。しかしながら、一部の状況では、最終的な決定はクラウドデバイスシステムエンジンに委ねられ得る。例えば、ＡＭＲのバッテリレベルが危機的な閾値４０３を下回るようなシナリオでは、優先順位プラン変数が「Ｈｉｇｈ」に設定された充電プランがＡＭＲ上に展開され、ＡＭＲがバッテリインターフェースにドッキングされて再充電され得ることを確実にする。
【0115】
一実施形態では、プラットフォームの検証モジュールは、展開要求が特定の装置（ＡＧＶ又はフォークリフト）上にあるかどうか、ナビゲーションプランについてナビゲーションスタックが装置上にロードされているかどうかを判定し、関連するプラットフォーム変数がチェックされる。別の実施形態では、プラットフォームは、プランの互換性スコアを検証するための互換性モジュールを含む。例えば、代替プランが、装置上で実行される既存のプランの代替として特定された場合、特定の一式のロボット（ＡＧＶ）のためのプランが別の種類のロボット、例えばフォークリフトにも互換性があるかどうかに基づいて互換性スコアが算出される。プラットフォームは、プランの機能（例えば、ナビゲーション）が現在の種類のロボット（フォークリフト）と互換性があるかどうかも検証し得る。別の互換性スコアの算出は、プラン実行エンジンの先のバージョンでプランがサポートされているかどうかに基づき得る。例えば、プラン実行の先のバージョンはバージョン１．５であるのに対して、プラン実行エンジンの新たなバージョンは２．０であり得る。互換性スコアは異なるモデルに基づくスコアリング機構を有し得る。モデルのうちの１つは、＋１～５又は－１～－５の範囲を有し得る。正のスコアはプランに互換性があることを示し、装置上で実行される既存のプランの代替となり得る。高い正のスコアは、本明細書で説明したように、限定されないが同様のシナリオにおける効果的な機能、成功率、人気等のプラン変数に基づいて、プラットフォームが新たなプランに対して高い支持率を有することを示し得る。負のスコアは互換性がないことを示し得る。また、スコアは様々な種類の装置に対してより高い負の評点を有し得る。これは、装置の種類が一般的な機能又は仕様から逸脱しているため、プランに互換性がないことを示し得る。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
