JP7290293B2 - 動作環境で作業するロボットに関するターゲット情報を生成及び表示するためのシステム及び方法 - Google Patents

Description

本明細書の実施形態は、動作環境（operating environment）で作業する（working）複数のロボットに関連するターゲット情報（targeted information）を生成及び表示すること、より詳細には、動作環境で遭遇する故障又はエラーを修正又は診断するためのターゲット情報を生成すること及びターゲット情報を表示することに関する。

産業におけるロボットの使用は指数関数的に増加している。ロボットは現在、パーソナルユースと商業スペースの両方で使用されている。ロボットのポテンシャルを引き出すために、特定の動作環境、例えば、倉庫フロアにおいて、多数の異なる種類のロボットが使用されている。既存のシステムは、動作環境におけるロボットに関連する問題を処理する又は解決策を見つける間に、エンドユーザに関連するライブのターゲット情報を提供しない。

ターゲット情報を生成及び表示するために、システム、方法、コンピュータプログラム、及びユーザインターフェースが提供される。一実施形態では、ターゲット情報は、少なくとも、システムによって取得されたコンテキスト情報（contextual information）に基づいて生成され得る。システムは、動作環境で作業する複数のロボットを含み、各ロボットは、命令を実行するプロセッサと、命令を格納するメモリとを含む。複数のサーバノードが複数のロボットと通信し、１つ又は複数のロボットで実行する複数のノードが複数のサーバノードと通信する。複数のロボットが動作環境で動作している間に、アクティブプラン（active plan）に関連する１つ又は複数の行動（behaviors）が実行される。１つ又は複数のスナップショット（Snapshots）が、実行している行動（executing behaviors）に関連して作成され、スナップショットは、複数のフィールドを含み、各フィールドは値が割り当てられる。値は、数字、テキスト、文字列、文字、又は関連し得る他の任意の形式であり得る。情報は、実行している行動に関連する親（parent）コンテキストに基づいてキャプチャされ（captured）、親コンテキストは、アクティブプランの親情報を含む。複数のフィールドは、少なくとも１つ又は複数のキャプチャされた情報、動作環境、及び１つ又は複数のロボットに関連する値が入力される。スナップショットは、１つ又は複数の行動の実行の結果として後で閉じられる。スナップショットは集約され、集約されたスナップショットは、１つ又は複数のロボットで動作しているレポートノードによってターゲット情報の一部として報告される。

一実施形態では、システム、方法、コンピュータプログラム、及びユーザインターフェースが提供されて、ロボットが動作環境で動作している間又は動作していない間に発生し得るエラー／故障を、ライブデバッガ、トレーサ、又は推奨システム、又はパターン認識装置が修理又は診断することを可能にする。ユーザは、システムによって生成されるターゲット情報に基づいて、動作環境における生産性を向上する解決策を見つけるために、カスタマイズされた検索クエリを提供することができる。システムは、システムの能力を高めるために複数のプラグイン又はライブラリがインポートされることを可能にする；例えば、ロスバッグ（rosbag）又はログ収集モジュールがリアルタイムでエラーを診断するために統合され得る。ユーザは、エラーを診断するための開始及び終了時間を提供し得る。その結果に基づいて、システムは、エラーを診断するための関連情報を抽出するためにロスバッグの分析を可能にすることによって、エラーを診断するための視覚的表現を提供し得る。

一実施形態では、システム、方法、コンピュータプログラム、及びユーザインターフェースが提供されて、動作環境における複数のロボット間のコラボレーション(協力)（collaboration）に関連するターゲット情報を生成及び表示する。複数のロボットから第１のロボット（例えばフォークリフト）を支援するために第２のロボット（例えばＡＧＶ）が利用可能であるという入力が受信される。スナップショットが、受信した入力に応じて第１のロボットによって実行されている行動（例えば、フォークリフトを支援するＡＧＶ）に関連して閉じられる。後に、新しいスナップショットが、第２のロボットを支援する第１のロボットによって実行されるプラン、行動、及びプランタイプの少なくとも１つ又は複数に関連して作成される。次に、要約（Summary）情報が、両ロボットが行動を実行している値を持つ関連フィールドに入力される。タスク割当て関連フィールドについての両ロボットのロボットＩＤ及びタスク詳細が更新される。ロボットＩＤ及びタスク詳細を更新することに応じて、第１のロボットを支援する第２のロボットのために、達成されたゲイン（gain）が検証される。検証に応じて、ゲイン関連フィールドに、行動の実行のパフォーマンスを示す値が入力される。両ロボット間のコラボレーションは、少なくとも１つ又は複数のロボット上で動作しているノードを有するシステムによって処理され得る。

一実施形態では、システム、方法、コンピュータプログラム、及びユーザインターフェースが提供されて、動作環境における複数のロボット間のコラボレーションに関連するターゲット情報を生成及び表示する。例えば、倉庫内の通路列、ダイナミックゾーン、狭いコーナー、充電ポイントなどの動作環境における１つ又は複数のロボットの位置が、スナップショットの関連フィールド、及び、例えば、パレットピックアップ又はドロップ、アシストロボットなどのタスク関連情報に入力される。次いで、信頼スコアが、行動の実行の結果に関連するフィールドの値として提供され、信頼スコアは、成功又は失敗を示すスケール（scale）によって表される。さらに、第２のロボットの移動距離及び向き（orientation）がキャプチャされ、これは、第１のロボットを支援することができる。キャプチャすることに応じて、新しいスナップショットのフィールドに入力する前に、第１のロボットとの適切なアライメント（alignment）を可能にするために、第２のロボットの向き及び移動距離が検証される。

一実施形態では、システム、方法、コンピュータプログラム、及びユーザインターフェースが提供されて、動作環境における複数のロボット間のコラボレーションに関連するターゲット情報を生成及び表示し、時間ウィンドウのサブセット内で複数のロボットによって実行される行動、プラン、及びプランタイプのうちの少なくとも１つに関連する入力を受信し、時間ウィンドウは、動作環境で動作する複数のロボットによって費やされる時間を含み；集約されたスナップショットのフィールドの値を、時間ウィンドウのサブセット内の且つロボットによって実行される行動、プラン、及びプランタイプのうちの少なくとも１つに関連するターゲット情報の一部として報告する。システムは、時間ウィンドウのサブセット内の複数のロボットによって実行される行動、プラン、及びプランタイプのうちの少なくとも１つに関連する入力を受信し、時間ウィンドウは、動作環境で動作する複数のロボットによって費やされる時間を含み；時間ウィンドウのサブセット内の且つロボットによって実行される行動、プラン、及びプランタイプのうちの少なくとも１つに関連するターゲット情報の一部として集約されたスナップショットのフィールドの値を報告する。さらに、システムは、第１のロボット又は第２のロボットによって実行される行動、プラン、及びプランタイプのうちの少なくとも１つに関する入力を受信し；受信した入力に関連する関連フィールドの値を報告して、デバッグに関するエラーを修正するか、第１のロボット又は第２のロボットのパフォーマンスゲインを測定する。

一実施形態では、システム、方法、コンピュータプログラム、及びユーザインターフェースが提供されて、動作環境における複数のロボット間のコラボレーションに関連するターゲット情報を表示し、第２のロボットの第１のロボットへの支援に関連するエラーを受信し；集約されたスナップショットの値に基づいて故障ロボットを識別し、第２のロボットが故障ロボットであり；他のロボットが第１のロボットを支援するために利用可能であるかどうかを検証する修復プロセスを自動的に開始し；利用できること（availability）に基づいて、他のロボットによって実行されるプラン、行動、及びプランタイプのうちの少なくとも１つ又は複数を再トリガする（retriggering）。修復プロセスは、１つ又は複数のロボット上で動作している１つ又は複数のノード及び／又は１つ又は複数のサーバ上で動作している１つ又は複数のサーバノード上で操作しているノードによって共同で処理され得る。

本明細書に開示される実施形態は、図面を参照して以下の詳細な説明からよりよく理解されるであろう。

一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なシステムを示す。 一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なプロセスを示すフロー図である。 一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための別の例示的なプロセスを示すフロー図である。 一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なプロセスを示す状態図である。 一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なプロセスを示す状態図である。 一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なプロセスを示す状態図である。 一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成し表示するための例示的なプロセスを示すトレース図である。 一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成し表示するための例示的なプロセスを示すトレース図である。 一実施形態による、ターゲット情報を生成及び表示するための別の例示的なシステムを示すシステム図である。

本明細書の実施形態、及びその種々の特徴及び有利な詳細が、添付の図面に示され、以下の説明で詳細に説明される非限定的な実施形態を参照して、より完全に説明される。よく知られたコンポーネント及び処理技術の説明は、本明細書の実施形態を不必要に不明瞭にしないように省略される。本明細書で使用される例は、本明細書の実施形態が実施され得る方法の理解を促進し、当業者が本明細書の実施形態を実施することをさらに可能にすることを意図するに過ぎない。従って、例は、本明細書の実施形態の範囲を限定するものと解釈されるべきではない。

本明細書の非限定的な実施形態は、用語「プラン」、エージェント、「行動」、均一及び異種の移動ロボット間のコラボレーション、システムレベルのコンポーネント、ロボットレベルのタスク、プランの実行又は行動などを指し、これらは、本明細書にその全体が組み込まれる、同時係属中の米国特許出願第16/994,556号に記載されている。

動作環境における異なるタイプのロボットが直面する問題を診断／修正することができる、又は、生産性を改善する若しくは動作環境で作業するロボットに関連した解決策を見つけることができる最適化情報を提供することができる、ライブデバッガ、トレーサ、推薦、パターン認識器、及び他の関連システムが必要とされている。現在、このようなシステムでは、ターゲットを絞った（targeted）、きめ細かい（granular）、状況に応じた（コンテキスト（contextualized））、関連性のある情報をエンドユーザに提供することが課題である。

本発明は、ロボットシステムの分野における技術的問題（例えば、ライブデバッガ、トレーサ、推薦（recommendation）、パターン認識器、最適化器など）を解決する。既存のシステムでは、障害が発生した場合、ロボットシステムは、ワールドモデル（world model）情報をそのままストリーミングし、システムは、ワールドモデルから情報を外挿する。このようなシステムでは、ロボットの数が例えば１００個に増えるとき、スケール変更する（scale）ことが難しくなる。このようなシナリオでは、ワールドモデルを分析し、後にワールドモデルのデータを使って障害の背後にある問題を特定し、修正することが困難になる。これらのシステムは、膨大なデータをストリーミングする結果となる大量の情報を含むワールドモデルを報告しているにすぎない。次いで、既存のシステムは、バルクデータに対して事後分析を実行し、そのため、システムは、関連する解決策を提供する立場にない。加えて、ロボット工学の専門家は、大量のデータの詳細を理解するのに時間を費やさなければならず、問題を特定し、修正する前に、この膨大なデータに意味を提供することが必要とされる。既存のシステムと比較して、本発明は、トレース及びリアルタイムデバッグのために使用され得るきめ細かいレベルのターゲットを絞ったコンテキスト（状況に応じた）診断データを提供することを含む技術的解決策を提供する。なお、動作Ｘ（ロボットのナビゲーション等）が失敗する又は成功しなかった又は時間がかかりすぎる場合を想定すると、本発明では、調査は、動作を分析すること及び障害が発生した場合のインスタンスをチェックすることに縮小される。エンドユーザは、大量の無関係なデータを心配する必要はなく、失敗したロボットの特定の行動に焦点を当てる必要がある。このシステムは、ロボットの行動レベルでの障害の要約を提供する。そこで、システムは、ユーザにワールドモデルを比較させる又はユーザに無関係なデータの分析に時間を費やさせるのではなく、障害に至った実際のイベントを公開する（exposes）。

さらに、このシステムは、他の技術的解決策を提供する。既存のシステムでは、スナップショットが作成されて閉じられ、スナップショットが閉じられると、スナップショットはトレースコレクタノードに報告される。既存のシステムのこのアプローチの問題は、長時間実行される動作やプランがる場合且つシステムのクラッシュやエラーが発生した場合又はシステムのハードリブートがあった場合には、そのような情報がエンドユーザに決して中継されない又は公開されないことである。これは、既存のシステムがリアルタイムデバッグに適さないことを示す。このようなシステムは、有用ではない事後検討の種類の分析を提供するに過ぎない。しかし、本発明は、イベントのリアルタイムデバッグを提供する。イベントが報告されると、システムはリアルタイムデバッグ機能をサポートするためのイベントの階層（hierarchy）を提供する。

加えて、システムは、動作環境で報告されたすべてのイベントの直接表現（direct representation）を提供し、追加のコンテキストは、－どこでエラーが報告され、なぜエラーが報告されたのかを含む。この情報は、ネットワークにやさしい環境関連のイベントと統合され、報告及び収集されることができ、これは、全体の履歴（entire history）を構築するために使用され得る。多くのユーザ（例えば、倉庫マネージャ、ソフトウェア開発者、システムインテグレータなど）の時間は、システムが、ユーザへの簡単なアクセスのために、単一のダッシュボード内に全ての関連する詳細を提供するので、ユーザがログ、ロスバッグ、又は種々のイベントのタイムスタンプの統合に時間を費やす必要がないので、節約される。

「プラン」という用語は、複数の方法で定義することができ、それが限定的であると解釈されるべきではない。プランを記述する最も簡単な方法は、次々に実行される行動のリストである。これは、より複雑なレシピ（recipes）やサブプランを定式化するために使用される構造である。このようなレシピ又はポリシーの様々な表現があり、これらはこの単純な記述を拡張する。プランの基本概念は有限オートマトンに強く関係しており、これは動作のシーケンスの定式化だけでなく、ループ及び条件付き実行の定式化も可能にする。したがって、プランのセットＰにおけるプランｐは、状態の構造とそれらの間の移行（transitions）である。実施形態の１つでは、プラン「充電（charging）」は２つのタスクを含み得る：１つは充電のために順番を待つ（queue）ロボットのセットためのものであり、もう１つはドッキングして充電される別のロボットのセットのためのものである。一実施形態では、プランはまた、「ロボット行動」を含み得る。ロボット行動は、ある条件下でロボットによって実行されるプラン内の低レベルアトミック（atomic）活動である。本発明の別の実施形態では、「充電」プランは、３つの状態：ロボット待機状態、ロボットドッキング状態、及びロボット充電状態を含む。一実施形態では、プランは、プランの実行中の段階を表す状態の集合である。

プランツリーは、充電プラン、ナビゲーションプラン、自律モードプラン、ピックアンドプレースオブジェクトプラン、リフティングプランなどのプランを含み得る。ロボットは、プランの状態に従って移行される。時には、ロボットは、「充電」状態であり得、その後、「充電」状態から引き出され、パレットを運搬し、ピックする（picking）「自律モード」状態に移行され得る。従って、これらの２つのプラン、すなわち「充電」プランと「自律的なピックアンドキャリ」プランについては、「ナビゲーション」プランと呼ばれるサブプランが使用され得る。サブプランは、１つ又は複数の目標又はプランによって達成される目標の一部を達成するプランの一部である。

プラン内の各状態は、移行によってリンクされ得る。移行は、ロボットが現在の状態から次の状態に進むために満たされる必要がある条件である。各状態において、１つ又は複数のロボットは、プラン内のサブプランのセットを実行する。１つ又は複数のロボットは、サブプランの実行が成功した後、タスクが失敗したとき、又はサブプランの実行が無関係になったときのいずれかで、次の状態に移行し得る。移行条件は、次のプラン状態に移行するために満たされる必要がある異なるプラン変数及びプラン変数値を含むブール式として定義され得る。

システムは、プランを実行し、１つ又は複数の異種ロボット及び／又はサーバによってタスクを割り当てるためのロジックをさらに含むプラン実行エンジンを含み得る。プランは、組み合わせてプランを形成するいくつかのサブプランを含み得る。ロボット行動は、ある条件下でロボットによって実行されるプラン内の低レベルアトミック活動である。例えば、「ロボット充電」プランは、３つの状態：ロボット待機状態、ロボットドッキング状態、及びロボット充電状態を含み得る。ユーザが、自動誘導車両（ＡＧＶ）のチームの実行とフォークリフトのチームの実行のためのプランとタスク割当戦略を開発したと考える。このプランは、ルートプランニング、ナビゲーション、局所的障害物回避、ライダー（LiDAR）スキャナなどの機能を含み、これらはフォークリフトのチームでは一般的であり得、フォークリフトでは異なり得る機能がいくつかあり得る。倉庫環境では、このシステムは、プラン実行エンジンの助けを借りて、例えば、フォークリフトのチームを支援する自動誘導車両（ＡＧＶ）のチームのような異種装置間の調整を処理する。

図1は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なシステムを示す。このシステムは、動作環境におけるロボットのナビゲーション中に取得される少なくとも１つ以上のコンテキスト、履歴、パターン、訓練されたデータなどに関連する情報を含む、様々な要因に基づいてターゲット情報を生成する。このシステムは、ターゲット情報を生成及び表示し、これは、ロボットが動作環境においてナビゲーションしている間又は他の任意の状態（アイドル、充電、他のロボットを待っている、動かない、中断、終了など）の間に、コンテキスト情報を取得すること、及び関連データ、例えば、コンテキスト情報、履歴情報、パターンなどに基づいて、ユーザの要求を解決するためのターゲット情報を生成することを含む。システム１００は、１つ又は複数のサーバ１３０、ロボット１０１、１０２、１０３を含む。サーバノード、DebTrace（デブトレース）（Debug & Trace（デバッグ＆トレース）の略）サーバ１３０は、ソフトウェアコンポーネントDebTrace（デブトレース）コレクタ（Collector）１３１、ロスバッグ（Rosbag）コレクタ１３４、Log（ログ）コレクタ１３７、インテリジェントフィルタリングモジュール１４０、ＵＩ１２１などを実行し、一方、ロボット１０１～１０３は、各々、ノード又はソフトウェアコンポーネントDebTrace（デブトレース）アプリケーション１０４、DebTrace（デブトレース）エンジン１０９、DebTrace（デブトレース）レポータ１１５、ロスバッグレコーダ１１９、ログ（Logs）コレクタ１２２などを実行する。一実施形態では、システム１００は、様々な時間間隔で、履歴等において、アプリケーションメタデータと共に、ロボット（エージェントとも呼ばれる）の様々な状態を示すライブ視覚デバッグ体験を提供する。デブトレースエンジン１０９は、デブトレースアプリケーション１０４を実行するソフトウェアモジュールである。デブトレースエンジン１０９は、分散タスク割当１１０、行動協調１１１、分散ソルバ１１２、及び外部トレースクライアント（例えば、ＲＯＳトレースクライアント１１３、オープントレースクライアント１１４）などの複数のコンポーネントを含む。デブトレースエンジン１０９は、すべてのプラン、動作の一貫した状態を維持し、デブトレースエンジンを実行する他のロボットと状態情報を共有する。ロボットセンサから受信される情報は、画像処理やセンサフュージョンなどの様々なタスクを実行する単一又は複数のコンポーネントによって処理される。抽象情報（Abstract information）は、ワールドモデル１０５に送られる。行動コンポーネント１０６、１０７、１０８は、すべてのドメイン固有の行動を含む。各行動は、後にロボットのハードウェア又はソフトウェアアクチュエータと通信する作動コントローラと通信する。ＵＩモジュール１２１は、検索クエリを入力して、システムから状況に応じた、きめ細かい、及び／又はターゲットを絞った情報を抽出するために使用することができる。

分散タスク割当てコンポーネント１１０は、異なるロボットに対する異なるタスクのタスク割当てを決定する。ロボットへのタスク割当は、プラン実行の異なる段階で、又はリアルタイムで決定され得、例えば、特定のタスクに割り当てられるロボットのいずれかが故障した場合、分散タスク割当１１０コンポーネントは、故障しておらず（利用可能であり）且つタスクを実行することが可能である他のロボットに再割り当てしなければならない。トレース（Trace）レポータ１１５は、サーバ１３０のトレースコレクタノード１３１に収集され格納されるトレースを報告する。同様に、ロスバッグレポータ１１９、ログレコーダ１２２は、それぞれ、ロスバッグコレクタノード１３４及びログコレクタノード１３７によってサーバエンドで収集されるロスバッグ及びログを報告する。ロスバッグ及びログはサーバエンドに格納され、システム１００による分析のために常に利用可能である。

一実施形態では、ロスバッグレコーダ１１９及びログレコーダ１２２は、ターゲット情報を生成し、デバッグ経験を向上させるシステムの能力を高める。デバッグのために、ロボット経路トレース要求に何らかのエラーがあり、ユーザが要求に関係するロスバッグ及びログをダウンロードすることのみに関心があり得るシナリオを考える。ＵＩモジュール１４１は、ユーザがロスバッグ及び／又はログをダウンロードすることができるダウンロードオプションを提供する。サーバ１３０は、ＵＩモジュール１４１と通信するサーバノード－インテリジェントフィルタリングモジュール１４０を提供する。所与のトレースデータ又はターゲット情報に対して、インテリジェントフィルタリングモジュール１４０は、ユーザが入力時間範囲内のログを検索するための時間ウィンドウを選択することを可能にする。コンテキストの観点から、モジュール１４０は、ユーザが、複数のロボット、サーバ、プロセス、システム内の異なるマシンから関与し得るトレースについて、全てのロスバッグ及びログをダウンロードすることを可能にし得る。さらに、モジュール１４０は、システムが、どのトレースがどのマシンにどの機関レポートするかを識別するために、異なるログ及びロスバッグを分類することを可能にする。識別処理の後、モジュール１４０はログ及びロスバッグを自動的にダウンロードする。例えば、３つのロボットがある場合、インテリジェントフィルタリングモジュール１４０によるＵＩモジュール１４１は、ユーザが３つの異なるロボット、サーバ等の３つのロスバッグファイルを異なる期間にわたって自動的にダウンロードすることを可能にする。同様に、インテリジェントフィルタリングモジュール１４０の制御を伴うＵＩモジュール１４１は、ログに対して同様の機能を実行し得る。既存のシステムでは、ロボットのルーティングプロセスに関連するエラーが発生する場合は方法がなく、ユーザは、複数のロボットで発生し得るエラーをデバッグするために関連するロスバッグ又はログを使用することができない。本発明は、この問題を克服し、ロボットが動作環境で作業している間に発生するエラーについて、関連するロスバッグ及び／又はログ等をダウンロードするための単一のダッシュボードを提供することによって、ユーザに豊富なデバッグ経験を提供する。

一実施形態では、ターゲット情報はまた、ロボットの詳細、例えば、マシンＩＤ、プロセス名、ホスト名などを含み得る。この情報は、ターゲット情報の一部としてロボットに利用可能であり、また、追加の機能のためにサーバに格納され得る。インテリジェントフィルタリングモジュール１４０は、ホスト名を使用し得、ホスト名に関連するロスバッグを識別し、検索し、トレースが入力された期間関連情報をフィルタリングし得る。本発明は、トレースデータをフィルタリングするためのロスバッグのフィルタリング又は利用のこの例に限定されない。サーバ１３０は、関連するデータ（例えば、ロスバッグ／ログ）及びデバイスコンテキスト情報（マシンＩＤ、ホスト名、プロセス名など）が収集され、格納される異なるノードを提供する。インテリジェントフィルタリングモジュール１４０は、関連するターゲット情報をフィルタリングし、ＵＩモジュール１３０を介してユーザに出力を提供する。

一実施形態では、トレースデータは、ロスバッグでも使用されるデバイスコンテキスト情報を有する。この情報は、特定のロボットに適切なロスバッグをフィルタリングするために使用される。ロスバッグは、例えば、データが収集された時点など、タイムスタンプに関する情報を保持する。システムは、トレースがアクティブになったときのタイムスタンプ（開始時間から終了時間まで）のような関連情報を有する。フィルタリングモジュール１４０は、タイムスタンプ及びデバイスコンテキスト情報に基づいて関連するロスバッグデータをフィルタリングすることができる。

図２は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なプロセスを示すフロー図である。簡潔さ及び理解する目的のために、フロー図は、スナップショットの作成、終了、及びレポートのプロセスを表すシーケンスダイアグラムの形態である。プロセスは、１つ又は複数のロボット上で動作している１つ又は複数のノード上で動作し得る、又は、複数のロボットと１つ又は複数のサーバ上で動作しているサーバノードとの間で協力して動作し得る。例えば、倉庫内のロボットのナビゲーションなど、ロボット行動を起動する決定をシステムが下すシナリオを考える。デブトレースエンジンは、「ルールブック（Rule Book）」２０１と呼ばれるコンポーネントを有し、これは、プランの変更があるとき又は行動がアクティブにされる（activated）ときにトリガされる（triggered）。ルールブック２０１は、システムの動作ルールを含み、ルールに従って定期的にプランを更新する。基本行動Ｘ２０２は、システムのコンポーネントであり、Ｘは「ナビゲート」行動であり得、これは、倉庫内のロボットをナビゲートすることに責任を負い得る。システムはデブトレースエンジン２０１をインスタンス化し、デブトレースエンジン２０１を「ナビゲート」の親プランを実行するように指示する。行動とプランは、本質的に階層的であり、例えば、ツリー構造であり、従って、常に親を有することが理解される。例えば、倉庫でナビゲートしている移動ロボットについて、子供を持ち得る親プラン「タスク」があり得、これは、行動、例えば、「ForkRise（フォーク上昇）」、「Navigation（ナビゲーション）」、「PickUp（ピックアップ）」、「Drop（ドロップ）」、「MobileRackUnblock（モバイルラックブロック解除）」である。行動インスタンスがインスタンス化される２０７とき、システムは、各行動の親の詳細を決定し、レポートする。ナビゲーション行動又はプランは、異なるコンテキストの下で異なる親に関連し得、例えば、ロボットは、チャージスポットにナビゲートするように又はオブジェクトをピック／ドロップするためにナビゲートするように要求され得る。したがって、親コンテキストのようなコンテキスト情報に依存して、ロボットの行動が異なり得る（チャージスポットに行くか、オブジェクトをピック／ドロップする）。

最初に、デブトレースエンジン２０２は、「オペレーション（Operation）」、「親（Parent）」などのようなパラメータを有するイベント（「CreateSnapshot（スナップショットを作る）」）２０８をトリガする。オペレーションパラメータは、開始された行動を示す。システムは、スナップショットをイベントとして扱う。行動Ｘの親として「ParentPlanContext（親プランコンテキスト）」を考える。ParentPlanContextから、ルールブックモジュール２０１は、デブトレースベーシック行動Ｘ（DebTrace Basic Behavior Ｘ）インスタンス２０２を作成する。次に、デブトレースエンジン２０２は、イベントがトリガされたことをリアルタイムトレースクライアントモジュール２０４と通信し得る。行動の周囲のメタデータは、例えば、周波数、ロボットが動作している状態、エントリポイントは何かなどのクエリに対する回答を含む。トレースクライアントモジュール２０４によって受信されたキー値のペアは、空のままであるか、又はブランク（例えば、Operation=<>、Parent=<>）であるため、トレースクライアントモジュール２０４は、関連するメタデータと共にキー値のペアを入力し得る。例えば、トレースクライアント２０４は、スナップショットのメタデータに追加され得、スナップショットＩＤにユニークＩＤを追加し得、エージェントＩＤは、詳細をレポートするエージェントの識別子、イベントの開始時間などを含み得る。この入力された情報は、トレースレポータモジュール２０５と共有される２０９。デブトレースエンジン２０１からトレースレポータ２０５までのエンティティは、システム境界レベル（ロボット１０１のプロセス境界として示されている）の一部であるロボットモジュールとみなされ得、一方、エンティティトレースコレクタモジュール２０６は、クラウド、ビーコン、エッジサーバなどの形態であり得るバックエンド、デブトレースサーバ１１９の一部として動作し得る。ＵＩモジュール１２３は、トレースコレクタ２０６と通信してトレースを収集し得る。したがって、高レベルでは、プロセスフローは１つ又は複数の行動のアクティベーションで始まり得、行動周辺のメタデータはリアルタイムトレースクライアントと共有され、更新されたメタデータを含む行動がトレースレポータに報告される。次いで、システム又はエンドユーザの要件に従って、詳細な、状況に応じた、及び／又はターゲットを絞られた情報がＵＩモジュール１２３に公開され得る。

一実施形態では、行動が開始された後、デブトレースエンジン２０２は、エンティティデブトレースアプリケーション２０３によって表されるアプリケーションレベルコードについて、ループ２１０においてAPI run()２１１を繰り返し呼び出す。全フェーズにおいて、デブトレースアプリケーション２０３は、AddTags()（タグを追加する（））を呼び出すこと２１２によって、カスタム情報を追加し得る。例えば、システムは、少なくとも１つ又は複数のパラメータを計算し得、例えば、ロボットがナビゲートしている速度を計算し、最大速度又は最小速度、システムがキャプチャしようとしている任意の他のメタデータ、エージェントがとるであろう他のルートなどを追加し得る。システム２００は、デブトレースアプリケーションモジュール２０３が、トレースレポータ２０５にエクスポートされる２１３大量の情報を共有することを可能にする。AddTags()を呼び出すことによってデータをエクスポートする２１３間に追加される例示のタグは、アプリケーション２０３によって追加されるカスタムタグと共に、snapshot_id（スナップショットid）を含む。このプロセスは、CloseSnapshot（スナップショットを閉じる）（snapshot_id）を呼び出すこと２１５によって、デブトレースエンジンが行動を終了する２１４まで、反復して繰り返される２１０。終了２１４の後、デブトレースエンジン２０２は、追加のタグ、例えば、特定の行動の成功又は失敗を追加し、その情報をリアルタイムトレースクライアントモジュール２０４にレポートする２１５。その後、トレースクライアントモジュール２０４は、スナップショットを閉じ得る２１６。システムは、そのようなスナップショットのセットを収集し得、集約されたスナップショット２１７は、次いで、トレースコレクタモジュール２０６にレポートされる２１８。

図３は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための別の例示的なプロセスを示すフロー図である。デブトレースエンジンコンポーネント「ルールブック」２０１は、初期化３０１し、コンテキストを「ParentPlanContext（親プランコンテキスト）」に設定した親インスタンスを作成する。エンティティ「デブトレースアプリケーション」（プランＡ）３２３は、デブトレースエンジン（プランＡ）３２２から継承する。プランＡを、任意の他の親プランのもとでインスタンス化されたプランとして考える。次いで、デブトレースエンジン３２２は、アクティブプランとしての特定のプラン、例えば、プランＡを持つCreateSnapshot（）を呼び出すことによって、スナップショットを作成する３０２。CreateSnapshotの他のパラメータは、親ＩＤ、アクティベーションの理由を含み得るタグ等を含む。例えば、パラメータ－アクティベーションの理由（reasons for activation）は、当てはまり得る又は所与の状態に移行され得る、プランがアクティブになり得る、タスク割り当ての変更、又はシステムが障害回復を試みているなどの移行条件（transition conditions）のような理由を含み得る。デブトレースエンジン３２２は、メタデータの一部として、上記の情報又はその他の関連するカスタマイズされた情報をスナップショットに追加する。

シーケンス図において、リアルタイムトレースクライアントモジュール２０４は、先に説明したように、パラメータを持つCreateSnapshot（）を呼び出すことによって、スナップショットを生成する３０３ことが示されている。プランがアクティブにされると、デブトレースエンジン３２２は、Initialize（）を呼び出すこと３０４によってデブトレースアプリケーション（プランＡ）３２３を呼び出す。デブトレースアプリケーションは、AddTags（）によってカスタムタグを追加し得３０５、リアルタイムトレースクライアントモジュール２０４は、タグにsnapshot_id及び他のカスタムタグを入力し得る３０６。エージェントがプランを実行している間、エージェントはまた、エージェントに割り当てられたさまざまなタスクを実行できるように、タスク割り当てを継続的に評価している３０７。デブトレースエンジン３２２は、タスクマッピングにおけるエントリポイント、ユーザが診断を希望する所望の周波数を評価するためのユーティリティ機能などを含む追加のメタデータを追加する。一例として、現在のプランＡに１０のエージェントがあり、現在のプランへの３のエントリポイントがあるとすると、システムに対するクエリは、どのエージェントがどのエントリポイントに進むかについての詳細を提供することになり得る。この機能は、タスクを連続的に評価すること３０７によってデブトレースエンジン３２２によって処理され、タスク割り当て変更があるときはいつでも、デブトレースエンジン３２２は、プランＡに割り当て変更があるとする別のスナップショットを作成する３０８。親パラメータは、スナップショットの階層を維持するための親のsnapshot_idを含む。他の関連情報は、例えば、エージェント２３２、１１１、及び４３４が、タスク割当てが変更されたときにもプランＡを実行していたように、現在のロボットと共にプランＡを実行していたロボットの数に関係し得る。したがって、エージェントはプランの中でチームメイトとみなされる。加えて、active_entrypointパラメータの一部として、データはエージェントが割り当てられたアクティブエントリポイントを含む。次のパラメータは、特定のエントリポイントで作業しているエージェントを含むnew_arlocationであり得る。フォークリフトＩＤ及びＡＧＶ ＩＤが更新され、タスクの詳細がタスク割当関連フィールドで更新される。また、このシステムは、フォークリフトを支援するＡＧＶによって達成されたゲインの検証に基づいて、再割り当てによって達成されたゲインをパラメータutility_inclusionに入力する。これらのパラメータに関連する詳細は、適当な非限定的な例を用いて説明される。

シーケンス図におけるリアルタイムトレースクライアントモジュール２０４からトレースレポータモジュール２０５へのフローは、単純なレポートの例である。リアルタイムトレースクライアント２０４は、レポートの一部として、スナップショットの関連フィールドに、タグフィールド内のsnapshot_id、agent_id（エージェントｉｄ）、start_time（スタート時間）などを入力する３０９。デブトレースエンジン３２２は、CloseSnapshot（）を呼び出すことによってスナップショットを閉じるために通信要求３１０を送信する。スナップショットは、タスクのステータスが更新されてタスク割り当てが受諾されると閉じられる。例えば、ステータス更新は、タスクが受け取られた（honored）かどうか、又は競合（conflict）があったかどうかである。競合がある場合、例えば、チームメイト間でエージェント４３４が同意しなかったという要約が生成される。時間の経過中に、このステータスは、リアルタイムトレースクライアントモジュール２０４によってトレースレポータモジュール２０５に報告される３１１。このプロセスの間のある段階で、親プランは、終了され得３１２、これはCloseSnapshot（）の呼び出し３１３を導き、成功又は失敗の結果のいずれかのタグが生成され、前記スナップショットに入力される。次いで、親スナップショットは、リアルタイムトレースクライアントモジュールによって閉じられ、スナップショットは集約される３１５。次に、集約されたスナップショットは、リアルタイムレポータモジュール２０５によってリアルタイムトレースコレクタモジュール２０６にレポートされる３１６。

一実施形態では、システムは、故障又はエラー、又は動作環境で発生した可能性のある任意のアクティビティの診断又は解決策として、ライブターゲット情報を生成する。また、デブトレースエンジン１０９は、きめ細かいレベルのターゲット情報を生成するために、その機能の一部を外部トレースクライアント１１３、１１４などの他のノードにアウトソースする。プランを実行しているそれぞれのフォークリフトで動作している４のエージェントがあり、特定の時点でフォークリフトの場所を切り替える必要があるとシステムが決定するシナリオを考える。さらに、フォークリフト１がパレット１００１に取り組んでおり、フォークリフト２がパレット２００２に取り組んでいる等で、フォークリフトが切り替え（switch）を行うと仮定する。ここで、ユーザがライブスイッチングの後で又はライブスイッチング（切り替え）中にトレース及びデバッグしたい場合、システムはターゲット情報を生成及び表示する。切り替えが発生すると、システムは、倉庫フロア上の動作活動に関連する複数のロボットからのコンテキスト情報、例えば、切り替えがなぜ発生したか、以前の割り当ては何であったか、新しい割り当て、ゲインは何であったか、競合があったか、及びその他の関連情報のアカウンティングなどの説明を取り出す（retrieves）。例えば、競合シナリオでは、エージェントの１つ、例えば、エージェント４３４が同意しなかったことを知ることのように、より細かい情報を有することがさらに適切であろう。この情報は、エージェント４３４が実行したアクションをエンドユーザが分析及びチェックするためのターゲット情報である。また、システムがレポートした（system-reported）ターゲット情報は、エージェント４３４が特定のプランを実行すると想定されていなかったことを示し得る。このシステムが提供した情報に基づいて、診断は、ワールドモデル情報（ワールドモデル１０５に格納されている）が期待通りでなかった可能性があることであり得る。この種の分析は、エンドユーザが、大量のデータの代わりに、ターゲット情報を受け取る逆分析に類似しており、ターゲット情報に基づいて、ユーザは、大量のデータを分析する必要があるかどうかを決定し得る。

一実施形態では、ＵＩモジュール１２３が４つのフォークリフトのうちの１つについてエラーを表示することを考える。エラーメッセージは「詳細」パラメータに含まれる「ナビゲーションプランタイムアウト（Navigation plan timeout）」であり得、したがってフォークリフトがナビゲーションすることができない。メタデータは、どのシステムコンポーネントがエラーをレポートしたか（例えば、分散タスク割り当て１１０）、エラーコード（例えば６４３）、agent_id（例えば、１００１）、エラーに応じて取ったアクション（例えば１）例えば、（「リトライ（Retry）」又は「アボート（Abort）」）のような他の詳細を含む。加えて、他の情報は、ロボットが動作していた倉庫の地図を示すmap_idを含む。これらの情報はすべて、無関係な大量のデータを共有するのではなく、エンドユーザのためのターゲット情報である。さらに、情報はまたコンテキスト情報、例えば、単にそれがエラーであったと言うだけではなく、「タスク」の下のナビゲーションプランのような特定の情報を含む。この親子階層関係は、エラーを診断する間に、すべてのコンテキスト情報を持ち込むように維持される。しかし、エラー情報が「ナビゲーションプランタイムアウト」のみであった場合、ユーザは、ロボットが特定のゾーン又は倉庫の一部で何を行っていたかのように、必要なコンテキストを得られない可能性がある。ＵＩモジュール１２３を用いて、システムは、エンドユーザに詳細なコンテキスト情報を提供し得る。ＵＩモジュールは、ペイン（panes）、ヒートマップ（heat maps）のような視覚的表現、関連するフィールドを含み得るドロップボックス、例えば、デバッガ、推薦者、トレーサ、プラグイン、ライブラリ、ロスバッグなどのような種々の機能を選択するためのメニューのような種々のインターフェースを含むように設計され得る。ビジュアルインタフェースは、ユーザがタスクに関する折りたたみ可能な矢印をクリックすると、タスクに関する情報を提供し得る。矢印をクリックすると、タスク関連情報が表示される。例えば、snapshot_idは、エージェントによって実行されるスナップショットの詳細を提供し、map_idはマップ固有の情報を提供し、result（結果）パラメータはスナップショットの結果に関する詳細を提供する。スナップショット情報はさらに、typeパラメータで示されるスナップショットのタイプと、どこにエージェントがナビゲートするように求められたかの目的地を含む。これらすべての関連情報は、アプリケーション又は設計者からの入力なしに、システムによって有機的に提供される。

一実施形態では、システムは、トレースデータの視覚的表現のためのタスクのヒートマップを提供する。円の半径は、エージェントがタスクを実行するのにかかった時間を示す。円が大きいほど、エージェントがタスクを実行するのにかかる時間が長くなる。ヒートマップのＹ軸は継続時間を表し得、一方、Ｘ軸はタイムラインを表し得る。ＵＩモジュール１２３はまた、タスクを選択し、タスクの詳細を分析するためのオプションをユーザに提供する。さらに、ユーザは特定のタスク、例えば「ピックアップ（Pickup）」に絞り込む又はフィルタリングすることができ、ユーザは、ロボットによってパレットピックアップの大部分が完了した場所を識別するために検索クエリを入力し得る。「ピックアップ」タスクをクリックすると、ＵＩはタスク「ピックアップ」に関連するメタデータを表示する。また、ビジュアルインタフェースは、特定の情報、例えば、パレットピックアップが行われた可能性のある動作環境内の場所を含み得る。

一実施形態では、システムは、ボトルネック識別、リアルタイムデバッグ又はライブデバッグ、エラーに関連するコンテキストを識別するために取られるべきアクションのために使用され得る。システムは、いつエラーが発生したか、どこでエラーが発生したのか、なぜエラーが発生したのか、及びエラーに関連する詳細に関して、エンドユーザに重要情報を答える。このシステムは、エンドユーザに対して、エラー又は故障の診断に関連する勧告を提供し、システムを最適化して生産性を向上させるためにロバストである。

一実施形態では、システムは、複数のモジュールの統合を可能にし、ユーザがリアルタイムでエラーを診断するための豊富な経験を提供する。ある時間2021年1月12日の午前10時30分に開始され、ある時間インターバルの後2021年1月13日の11時25分に終了したことをタスクがレポートされるシナリオを考える。ユーザは、指定されたインターバルの間にロスバッグを分析することに関心があり得る。従って、システムは、例えば、エラーがレポートされたときに、ユーザが時間インターバルを選択することを可能にする。その後、ユーザはヒートマップインタフェースを使用し、特定のタスクを選択できる。タスクを選択した後、システムは、発生した可能性のあるエラーを表示する。ユーザ選択を受信した後、システムはロスバッグ収集を統合し、デバッグインタフェースを提示する。ユーザは、エラーをリアルタイムで診断するために必要に応じて、ログ、ロスバッグ、及びその他の関連情報をダウンロードすることを可能にされる。一実施形態では、システムは、他のモジュールは他のイベントがレポートされるのと同じインターフェースでユーザが利用できるので、ユーザが他のモジュールを使用して関連情報を引き出す必要がない完全な単一のダッシュボードを提供する。モジュールは、ユーザの要求に応じて関連情報を抽出するためにＵＩによって使用され得るＡＰＩを提供するロスバッグ、及び他のログに関連し得る。

一実施形態では、パレットを動かすために一緒に作業するフォークリフト及びＡＧＶのチームを考える。ＡＧＶが利用可能である場合、フォークリフトはパレットをピックしてＡＧＶに載せ、ＡＧＶは目的地に向かう。目的地では別のフォークリフトがＡＧＶと出会い、パレットをドロップする（おろす）。しかし、チーム内でＡＧＶが利用可能でない場合、フォークリフトはすべてのＡＧＶ作業を行わなければならず、フォークリフトは目的地に行き、パレットを目的地にドロップし得る。このアプリケーションは、複数の側面、どのロボットがどのアクティビティを行うかに関するタスクアロケーション、ＡＧＶ及びフォークリフトが互いに近接した場合に関連する行動調整を有し、必要に応じてフォークリフトがＡＧＶにアイテムをピック及びドロップできるように、両ロボットが協力する（collaborate）必要がある。行動協調モジュール１１１は、ＡＧＶにアイテムをピック及びドロップするためにフォークリフトがＡＧＶと共に機能することができるように、フォークリフトとの一定の距離閾値を維持するＡＧＶを取り扱う。planType（プランタイプ）は、プランのリストを含む。タスク割当機能及びユーティリティ機能は、システムがどのプランを実行されなければならないかを決定するのに役立つ。

図４（Ａ）は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための別の例示的なプロセスを示す状態図である。MovePallet（パレットを動かす） Plan４０１は、PickPallet（パレットをピックする）４０３とDropPallet（パレットをドロップする）４０４の２つの状態で示されている。簡潔さ及び理解する目的のために、フォークリフトがパレットをうまくピックアップし、現在はDropPallet状態４０４にあるDropPallet状態４０４を考える。フォークリフトがDropPallet状態になると、システムはDropPalletpt planType（プランタイプ）４０６を起動する。システムがDropPalletpt planType４０６を起動するとき、スナップショットの下にDropPalletpt planType４０６が生成される。以下の詳細は、非限定的であり、表現及び理解のためのものであることに留意されたい。以下のスナップショットの詳細は、アプリケーション又はシステム要件に従ってさらにカスタマイズされ得る。

このスナップショットでは、オペレーションフィールドは、プランタイプDropPallet Plan Type４０６を示し、これは、「DropPallett（パレットをドロップする）」である。Parent（親）フィールドは、DropPallet Plan Type４０６の親を示し、これはMovePallet Plan４０１である。ActivatedInStateフィールドは、Snapshotが作成されたときにシステムによってアクティブにされた状態を示し、これはDropPallet State４０４である。Typeフィールドは、タイプがプラン又は行動の代わりにPlanTypeであることを示す。その他の有用な情報は、Tagsフィールドにキャプチャされる。最初のフィールド「reason_for_activation」は、DropPallet Plan４０４をアクティブにする理由を示す。このフィールドの値は、フォークリフトが「transition_conditions（移行条件）」のためにこの状態に到達したことを示す。次のフィールド「activation_summary（アクティベーションサマリ）」は、以前の子PickPallet４０３が成功したことを示し、したがって、フォークリフトは、PickPallett４０５からの成功した移行後に、DropPallet state４０４に移行したことを示す。次のフィールド「teammates_in_plan（プラン内のチームメイト）」は、現在のプランを実行しているエージェントのＩＤを示し、これは、この例では、ＩＤ「１２１」を持つエージェントである。次のフィールド「app_tag_pallet_id」は、アプリケーションによって追加されたカスタムタグである。アプリケーションがプランをアクティブにすると、アプリケーションは独自のカスタム情報を追加できる。例えば、前記フィールドに対して、パレットＩＤがカスタム情報として追加される。以前のフィールド情報はシステムによって提供されると理解されるが、デバッグの間の追加情報として「app_tag_pallet_id」フィールドがアプリケーションによって提供されている。これは、エンドユーザ又はデバッガのニーズに応じて、システムをロバストにかつ柔軟にアプリケーションによってカスタマイズされることを可能にする。agent_id、snapshot_id、start_timeなどの他のフィールドは、スナップショット生成の一部としてシステムによって提供される。プロシージャはCreateSnapshot（）及びCloseSnapshot（）を含むことが理解される。CloseSnapshot（）は、成功したか失敗したかにかかわらず、プロセスの最終状態の詳細を含む結果を与える。CreateSnapshot（）が実行されるとき、start_timeフィールドはTracingClient（クライアントをトレースする）によってキャプチャされ、CloseSnapshot（）が実行されるとき、end_timeフィールドはまた、スナップショットがアクティブであった期間の間、入力され得る。

図４（Ｂ）は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための別の例示的なプロセスを示す状態図である。planType DropPallett４０６は、複数のプラン、DropPalletAlone（パレットを単独でドロップする）４０７及びDropPallet４０４を含み得る。DropPalletAlone PlanType４０７は、タスクに関して単独で作業する（パレットをそれ自身によって移動する）フォークリフトを含み、DropPallet PlanType４０４は、他のロボット、例えばパレットを移動する作業を行うＡＧＶと協力するフォークリフトを含む。図４（Ｂ）に示すように、DropPalletAlone PlanType４０７について、MoveToDropPallet（パレットをドロップするために移動する）４０９及びDropOnDestination（目的地にドロップする）４１０の２つの状態が示されている。このタスクは、パレットドロップを処理しなければならないフォークリフトのためのものである。システムがDropPalletAloneプラン４０７をアクティブにすると、以下のスナップショットが生成される。Parentフィールドは、親の名前を"DropPalletpt_type_snapshot_id"として含み、ActiveInStateは、親がここではまだアクティブであるため、該当なし（Not applicable）として示される。DropPalletAloneプラン４０７は、「プラン」としてのタイプを持つその親の状態では利用可能である。

タグフィールドでは、アクティベーションの理由が、「task_evaluation（タスク評価）」として示され、activation_summaryフィールドは、「フォークリフト１２１のみがプランを実行するために利用可能である」というより多くのコンテキスト情報を提供する。これは、１つのフォークリフト１２１のみがパレットをピックする及びドロップするタスクを実行するために利用可能であるため、システムがDropPalletAlone状態を選択する理由である。これは、agent_id１２１を持つフォークリフトがプランの唯一のエージェントである次のフィールドでさらに詳しく説明する。システムは、snapshot_id、agent_id、start_timeなどの残りのフィールドを埋める。この種の非限定のターゲット情報は、実行時に障害又はエラーを修正するためにデバッグする間、エンドユーザにとって重要な役割を果たす。

一実施形態では、フォークリフトがプランDropPalletAlone４０７を実行している間に、フォークリフトを支援するためにＡＧＶが利用可能になるシナリオを考える。したがって、ＡＧＶが自由にフォークリフトを支援できるようになるとすぐに、システムはオペレーションDropPalletAlone４０７のためのスナップショットを閉じることをトリガし、更新されたアクティベーションの理由を備える「DropPallet」のための新しいスナップショットが作成される。

図４（Ｃ）は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための別の例示的なプロセスを示す状態図である。ＡＧＶはフォークリフトを支援するために利用可能であるので、タスク割当のためのシステムモジュールは、フォークリフトとＡＧＶの両方にプランDropPallet４１４を実行させ得る。以前のプランDropPalletAlone４０７は、システムによって閉じられる。図４（Ｃ）に示される状態マシンは、「DropPalletAlone」（図４（Ｂ））に関して先に示されたものとは異なる。フォークリフトタスクは固有のタスクマシン（ForkliftDefaultTask４０８）を有し、一方、ＡＧＶタスクは固有のタスクマシン（ＡＧＶDefaultTask４１５）を有する。そこで、最初に、フォークリフトとＡＧＶの両方が動いてパレットをドロップする（４０９）。ＡＧＶがフォークリフトを支援する４１８ためにドロップ点に到着すると、フォークリフトは、目的地でドロップされる４２０必要があるパレットをＡＧＶからピックする４１６。これは、図４（Ｃ）に、フォークリフトとＡＧＶの両方によって実行される機能に応じて、異なる状態で示されている。

図４（Ｃ）に示すように、システムはDropPalletプラン４１４をアクティブにし、親はDropPalletAlone４０７と同じままである。DropPallet４１４の下記のスナップショットとDropPalletAlone４０７の以前のスナップショットの大きな変更点は、「activation_summary（アクティベーションサマリ）」である。現在の事例では、アクティベーションサマリはフォークリフトとＡＧＶ（フォークリフト１２１とＡＧＶ２２３）の両方がプランを実行していることを示す。フィールド「teammates_in_plan」は、複数のエージェントがプランを実行するために利用可能であることを示す。デバッグの目的では、システムは、この情報を中継して、２つのエージェントを含むチームが他のプランと比較してなぜこのプランを実行しているのかに関する情報を入手する。「teammates_in_plan」フィールドは、プラン４１４を実行しているすべてのチームメンバーに関する情報を提供する。他の有用な情報の１つは、フィールド「new_association」の割り当ての詳細である。例えば、ピックアンドドロップパレットに関連するタスクを実行する５つのフォークリフトと５つのＡＧＶのチームを考える。「new_assolvation」は、エージェント番号とエージェントに割り当てられた特定のタスクを提供する。したがって、「121：ForkliftDefaultTask」は、すべてのチームメイトのうち、だれが様々なタスクで協力しているか－フォークリフト１２１がForkliftDefaultTask４０８で作業していることを示す。フィールド「new_assignment」は、システムがタスクアロケーションモジュールをトリガすると入力される。次のフィールド「utility_increase」は、フォークリフトと共にＡＧＶを導入したことによってなされる変更によるユーティリティの達成などの有用な情報を提供する。システムは、すべての異なるタスク割り当てを１～１０のスケールで評価し、値が高いほど、実行されたプランのパフォーマンスが良好であることを示す。この値は、単一のフォークリフトがタスクを実行することから、ＡＧＶにフォークリフトを支援させることへの切り替えによるシステムによって達成されるゲインを示す。残りのフィールドは、複数の非限定的な実施形態で議論されているように、システムによって満たされるフィールドである。

上記の例及び図４（Ａ）～４（Ｃ）から、DropPalletプラン４１４では、フォークリフトは、ForkliftDefaultTask（フォークリフトデフォルトタスク）４０８にリンクされた状態マシンを実行し得、同様に、ＡＧＶは、AGVDefaultTask（ＡＧＶデフォルトタスク）４１５にリンクされたその１つの状態マシンを実行し得ることが理解される。したがって、状態図に示されるように、システムは、MoveToDropPallet行動４０９から始まり、次にPickPalletFromAGV（ＡＧＶからパレットをピックする）４１６からDropOnDestination４２０へと、異なる時間に異なる行動を、フォークリフトに対してアクティブにし得る。同様に、システムは、MoveToDropPallet４０９及びAssistForklift（フォークリフトを支援する）４１８のような異なる行動で、ＡＧＶに対してアクティブにし得る。

フォークリフトとＡＧＶの両方は、それぞれの行動の実行のために異なるスナップショットをレポートし得る。例えば、フォークリフトがPickPalletFromAGV行動４１６を終了するとき、スナップショットは以下のようになる：

一実施形態では、上記スナップショットのタイプは、アクティベーションフィールドの理由を「transition_condition」とする「Behavior（行動）」である。要約は、依然の行動MoveToDropPallet４０９が成功し、フォークリフトが次の状態PickPalletfromAGV４１６を実行するために到着したことを示す。リアルタイムデバッグに役立つ可能性がある中継される複数のアプリケーション固有の入力があることに留意されたい。例えば、パレットがＡＧＶからピックアップされた場所は「app_tag_location」フィールドによって表され、次のフィールド「app_tag_confidence」は、パレットピックアップがどれだけ成功したかである関数の結果を示すために入力される。これは、パレットがフォークに正しく取り付けられているかどうかを判断するために、カメラのフィードデータ、センサ入力などの様々なパラメータに基づいてシステムによって更新される。「app_tag_confidence」の情報は、デバッグの間又は機械学習若しくは推奨システムのために後に使用され得るように、アプリケーションによって中継される信頼スコアである。次のフィールドは、オペレーションが成功したか失敗に至ったかの尺度を与える。残りのフィールドは、start_timeやend_timeなどの他のスナップショットと似ている。

一実施形態では、以下のコードスニペットは、フォークリフトを支援することに関連する行動AssistForklift４１８を完了したときのＡＧＶのスナップショットを表す。前のスナップショットと同様に、ほとんどの情報は埋められており、追加のフィールドは"app_tag_distance_travelled_present_assisting"であり得る。このフィールドは、ＡＧＶがフォークリフトのパレットのピックを支援するシナリオに関する情報－例えば、ＡＧＶがフォークリフトを支援するために移動する距離のようなターゲット情報を含む。１ｍ、２３度の値は、フォークリフトを支援するために適切に位置合わせする（align）又は回るようにＡＧＶが１ｍ走行し、２３度回転しなければならないことを示す。これは、アプリケーションがデバッグや機械学習／推薦システムのために中継することを望み得る情報の別の例である。

一実施形態では、フォークリフトを支援するＡＧＶに関連する行動が、アクティブにされ、AsistForklift行動４１８によって表される間、システムの分散ソルバモジュール１１２が、解決策を提供するためにトリガされる。フォークリフトが移動し、ＡＧＶからパレットをピックアップするシナリオ（PickPalletFromAGV行動４１６）を考える。パレットをピックアップされるときＡＧＶは静止したままであると予想され得る、又は互いに対して変わった（weird）角度にある又はＡＧＶが遠く離れていてフォークリフトがピックアップする位置にない場合に、フォークリフトがパレットを正確にピックアップできるように、ＡＧＶがフォークリフトに適切に位置合わせされると予想され得る。このような状況では、システムの分散ソルバモジュール１１２がトリガされる。フォークリフトの位置とＡＧＶの自身の位置を考慮すると、ソルバモジュールはフォークリフトが到着しなければならない最適な位置又はＡＧＶが現在の位置に留まる方がよいかどうかを決定し得る。これは、「Events（イベント）」フィールドによって上のブロック内で表現される。したがって、分散ソルバモジュール１１２が計算している間に、システムは、時間のインターバルの間に起こったかもしれないインシデント又はストーリーのリアルタイムデバッグにおいてエンドユーザを助けるために、任意の数の「Events」フィールドを追加することができる。したがって、システムは、ソルバモジュールの結果を用いて継続的なイベント（continuous events）でスナップショットを更新する。例えば、エージェント１２１は、位置（12、13）で３ｍ離れているため、分散ソルバモジュールの結果により、エージェント１２１は、（12、11.2）で２ｍ以内に到着している。同様に、別のイベントは、エージェント１２１の向きがゴールで２３度ずれている可能性があることであり得、ソルバモジュールは、エージェント１２１が９０度に位置合わせされる結果をもたらす。これらは、別々のスナップショットとしてではなく、異なる時間間隔、例えば１２秒及び１８秒でキャプチャされるイベントとして記録される分散ソルバモジュール１１２の非限定的な例である。スナップショットは、一定期間実行しなければならず、一定期間有効である論理ユニットであり、前述の例に示すように、独自のメタデータを持つことができる。スナップショットは、例えば、AssistForklift４１８のようなオペレーションの表現である。しかし、イベントは、オペレーション又はスナップショットがアクティブなときに非常に頻繁に発生する。イベントは、デバッグ目的で有用な情報として中継又は格納される必要のあるインシデントのログを含み得る。

一実施形態では、スナップショットを作成する間、システムはフィールド及び値に限定されないが、ロボットの作業中に、例えばロボットが倉庫内をナビゲートしている間にキャプチャされ得るタイムスタンプ付きイベント（time-stamped events）を含み得る。スナップショットは、特定のメタデータ又はフォーマットに限定されず、動作環境で遭遇する異なるシナリオに応じてカスタマイズされ得る。ターゲット情報は、よりきめ細かくされ得、スナップショットがキャプチャされているときに倉庫の環境内で何が行われていたか、どのチェックポイント又は倉庫内のどの位置がクリアされたか、何時に、いつ「ナビゲーション」行動が実行されていたか、などのクエリに対する解決策を提供し得る。このシステムは、協力して作業する１つ又は複数のロボット上で動作するノードに基づいて、及びサーバ上で動作するサーバノードとの通信に基づいて、きめ細かいターゲット情報を提供する。このターゲット情報は、単純なＵＩ、コマンドライン、ビデオエンコーダプラグイン、シミュレータインターフェイス、ビデオを使用した再生機能などに基づいて可視化され得る。

一実施形態では、システムは、スナップショットに加えて、タイムスタンプ付きイベントをキャプチャするための追加のメタデータを含む。ロボット上で動作しているノードがメタデータ（例えば、route_response）を受信し得る倉庫内のロボットのルーティングに関連するＵＩにトレースが生成されることを考える。route_responseメタデータは、詳細なきめ細かいコンテキスト情報を含み得る：例えば、ナビゲーションがアクティブである間に、システムが２分の時間間隔で３０秒の期間ログを取得したと仮定すると、上記のログ情報は、３０秒において、ラック、シートシャッターなどの外部デバイスに対してロックが取得されたことを示し得る。４５秒において、経路内の第５のチェックポイントがクリアされ、５５秒において、経路内の第１０のチェックポイントがクリアされた。したがって、高レベルのスナップショットにおけるタイムスタンプ付きイベントがキャプチャされる。上表の「AssistForklift」オペレーションでは、「Events」フィールドは、更新されている同様のログエントリ（例えば、１２秒：エージェント１２１が３ｍ離れているなど）を備えて示される。このシステムは、「イベント」メタデータの形式で、よりきめ細かい情報を追加する。

図５（Ａ）は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なプロセスを示すトレースの可視化である。トレースの可視化では、異なるスナップショット間の関係が強調される。例として、「DropPallet」プランタイプは、以前の実施形態との一貫性を維持すると考えられる。各ボックスは、プランの種類、プラン、実行時の行動のいずれかの表現である。

図５（Ａ）では、最初のボックスは、「MovePallet」プラン５０１がアクティブであることを示す。例として、「DropPallett」プランタイプ５０３は、理解及び単純化のために詳細に説明されている。図中の矢印は、親子関係を示す。同じレベルのボックスは、それらがツリー型の階層の一部として互いに兄弟姉妹であることを示す。「MovePallet」プラン５０１がアクティブである間、初めは、ドロップする前にパレットが最初にピックされなければならないので、タイムラインに示されるように、プランタイプ「PickPallett」５０２が最初にアクティブであり、これは、次に「DropPallett」プランタイプ５０３がアクティブになることに続く。「DropPallett」プランタイプがアクティブである間、「DropPallettAlone」５０４が最初に実行され、フォークリフトがドロップ位置に移動する際に、フォークリフトを支援するためのＡＧＶが利用可能である場合はタスクを終了し、「DropPallet」プラン５０５を呼び出す。「DropPallet」プラン５０５がアクティブであるとき、これは、利用可能である、フォークリフトとＡＧＶの２つのエージェントがあるシナリオをもたらす。したがって、ＡＧＶ５０７の「MoveToDrop」及びフォークリフト５０９の「MoveToDrop」の２つの行動があり、いずれも親「DropPallet」５０５の子供であると考えられる。ＡＧＶ及びフォークリフトの行動は、エージェントＡＧＶ及びフォークリフトはそれぞれの位置にあり得、パレットをドロップするのにそれぞれの時間を要し得るため、異なるスナップショット及び異なる期間を有し得る（「MoveToDrop」フォークリフトボックス５０９は「MoveToDrop」ＡＧＶ５０７に比べてタイムラインで長くなる）。しかし、「AssistForklift」５０８及び「PickPalletFromAGV」５１０の行動は同時に開始する。したがって、図に示されるように、ＡＧＶは、アイドル状態であり得る又はフォークリフトが行動「MoveToDrop」５０９が完了するのを待ち得、その後、フォークリフト５０８を支援することを開始する。フォークリフトはまた、その後、ＡＧＶがフォークリフト５０８を支援すると、ＡＧＶ５１０からのパレットのピックを開始する。ＡＧＶ動作が完了すると、フォークリフトは、続いて「DropPallet」５１１に関連する次のアクションを行う。

一実施形態では、ユーザは、スナップショットのいずれかをクリックし得、メタデータの詳細を取得し得る。ここで、「MoveToDrop」プラン５０６がアクティブであったこと、つまり、これらの行動は全てナビゲーションプランの一部であるため、ナビゲーションプランがアクティブであったことを考える。ＵＩでは、ユーザはナビゲーションプランをクリックして、チェックポイント、ノード、場所などのリストをドロップダウンすることができる。これらは、「MoveToDrop」プラン５０６を実行する間にロボットがドロップ位置に到着するために移動しなければならない倉庫内の様々なポイント又は場所である。ユーザは、デバッグするためにリストアイテムのいずれかを選択することができる。加えて、ユーザは、特定のプラン、例えば「MoveToDrop」プラン５０６をクリックすることができ、スナップ詳細が、フォークリフトが取った経路、カバーすることを予定されていた経路、又はフォークリフトに割り当てられたルートのような情報とともに、デバッグの間に問題を解決するためにユーザに表示され得るタイムスタンプ、ノード、チェックポイント、及びその他の細部レベルと合わせて、視覚的に表示される。ユーザはまた、視覚的表現、例えば、「MoveToDrop」プランをクリックするとフォークリフトが取るパス全体のマップを得ることができる。フォークリフトによって取られたルートはマップ上に示され得、例えば、ユーザは、時間ウィンドウ、例えば、3月23日23:00時から3月12日02:00までを選択し、クエリ、例えば、特定のフォークリフト、例えば、エージェント１２３が与えられた時間ウィンドウ内で何をしていたかをトリガすることができる。ユーザは、このようなカスタムクエリを発することができ、これらのクエリを受信すると、種々のシステムモジュールをトリガして、デバッグユーティリティを可能にするためにユーザに視覚的表現を与え得る。クエリの別の形式は、キー：値形式であり得、ユーザは、エージェント（フォークリフト、ＡＧＶ、アーム、ＡＭＲ、他のタイプのロボットなど）が特定の瞬間に何を行っていたことを可視化することができる。クエリが発せられると、関連するスナップショットがポップアウトし得る。例えば、「PickPalletFromAGV」５１０に関連するスナップショットについて、クエリは、どの位置でパレットがピックされたか、又は「DropPallet」５０５について、どの位置でパレットがドロップされたかであり得る。ユーザは、スナップショットのリストを提供されるか、或いは、デバッグする及び／又はフォークリフトに対するＡＧＶの支援に関連するパフォーマンスゲインをトレース若しくは測定するの間にユーザが問題を解決することを可能にするカスタムクエリを発することができる。

一実施形態では、システムにプラグインされ得るロスバッグモジュールに加えて、システムはまた、ログを収集することができるように、ログモジュールが統合されることを可能にし、システムは、ログに関連するユーザが望むターゲット情報を提供し得る。ロスバッグ、ログなどのモジュールは、ターゲット情報を得るために、エンドユーザに豊富なデバッグ経験を提供する。

一実施形態では、システムは、システムの一部としてインテリジェントフィルタリングモジュールを提供する。インテリジェントフィルタリングモジュールは、ユーザが、時間に制限されるだけでなく、他の要因も考慮して、ターゲット情報に関連するイベントをフィルタリングすることを可能にする。要因は、ユーザ（例えば、ロボット開発者）が関心を持つエージェント、ユーザ（例えば、倉庫マネージャ）が焦点を当てている動作環境の空間領域などであり得る。

一実施形態では、システムは、ユーザがビデオを再生して、任意の特定の時間に各エージェントによって実行されたアクションをトレースすることを可能にするビジュアライザモジュールを含む「リプレイ（replay）」機能を提供する。ユーザはイベント全体において任意の時点にジャンプすることができ、可視化インターフェースを提供できる。可視化インターフェースは、ビデオを再生するために使用され得る、又は所与の時間間隔、例えば午後９時～午前６時の間の倉庫の状態を見て、ターゲット情報を可視化するためにシミュレーションインターフェースを使用し得る。

一実施形態では、システムはまた、ＵＩ、例えば、ヒートマップを呼び出し得、ここでは、ユーザは「DropPallet（ドロップパレット）」スナップショットを選択し得、次いで、システムは、ドロップ位置を表示する。その後、ユーザはドロップ位置をクリックすることができる、又は、任意の他の形式の入力（右クリックなど）を提供し、ヒートマップを表示することができる。システムは、倉庫マップ全体を表示し、最近のドロップ位置、頻繁なドロップ位置、或いはあるパターンを有するドロップ位置、或いは所与の日のドロップ位置、或いは倉庫の特定のゾーン近傍のドロップ位置などのカスタマイズされた情報を提供する。同様に、クエリが「picklocation（ピック位置）」に関連している場合には、システムは異なる結果の組み合わせをカスタマイズして表示し得る。他の例は、ユーザが「Navigation（ナビゲーション）」プランを選択し得る場合であり得る。「ナビゲーション」プラン自体が巨大で複雑であるため、前提条件：各ロボットが待っていたチェックポイントを表示する；又は、特定のロボット（例えば、エージェント１２１）が他のロボットが通過するのを待っていたチェックポイントを表示するなどを伴うよりカスタマイズされた検索クエリがあり得る。検索クエリに基づいて、システムは、視覚的に表示され得るヒートマップを生成し得る。ヒートマップでは、ユーザは、ロボットが互いを待っている特定の重大な交差点（critical junction）（例えば、ゾーン０通路１）があることを観察し得る。

これらは、ユーザが視覚的又はコマンドライン表現においてきめ細かい情報を検索することを可能にするシステムのロバスト性を示す一種の非限定的な例である。そのような情報は、ユーザが、パフォーマンスを向上させ、コスト削減を可能にするために、ビジネス及び／又はソリューション中心の決定を行うのに有用であり得る。この視覚的表現はまた、デバッグの間にユーザにロボットの動作環境の実際の体験をさせるシミュレートされたマップ内に積み重ねられ得る又は表示され得る異なる表現を可能にするプラグインをインポートすることによって、ユーザのニーズに応じてカスタマイズされ得る。ライブトレースデータは、倉庫レイアウト条件を改善する、ロボット設計パラメータを設定する、システムインテグレータのために複雑な協力シナリオに対するソリューションを提供する、ロボットの行動におけるパターンを観測する及び履歴データに基づいてパフォーマンスを改善するなどのためにユーザによって使用され得る。

図５（Ｂ）は、一実施形態による、動作環境で作業する複数の異なるタイプの移動ロボットに関連するターゲット情報を生成及び表示するための例示的なプロセスを示すトレース可視化である。フォークリフト（例えばフォークリフト１）又はＡＧＶが所与のタスクを実行しなかったシナリオを考える。図では、以下のタイムラインのように、異なるイベントが発生する：デバッグ中、ユーザは障害を起こしているロボットを知ることに興味があるだけでなく、そのようなエラーが発生したコンテキスト情報にも関心があり得る。フォークリフト１及びＡＧＶが協力している場合、行動「MoveToDrop」は両方のロボットが一緒に実行し得、ここでは、フォークリフト１がパレットをＡＧＶからピックしなければならない間にＡＧＶはパレットをドロップするために移動する。ここで、フォークリフト１の「MoveToDrop」動作がアクティブであるとき、フォークリフト１がエラー、例えば、ナビゲーションプランのタイムアウト又はナビゲーションプランが長すぎるに遭遇し得るシナリオを考える。このようなシナリオでは、フォークリフト１についての「MoveToDrop」行動のスナップショットは、結果フィールドが「failure（障害）」５１２の値を有することが含まれ得る。システムモジュール、デブトレースエンジンは、障害が発生した原因となったプランを修復することを試み得る。タスク割当フィールドについての両ロボットのロボットＩＤ及びタスク詳細が更新される。更新に応じて、修復プロセス中に、ＡＧＶが利用可能であるがフォークリフト１は利用できない可能性があることを、システムが検証し得る。したがって、システムの最初のチェックは、利用可能なフォークリフトのリストを調べ、エラーのある（erred）フォークリフト１に依存するのではなく、フォークリフト２が利用できるかどうかを決定することである。デブトレースエンジンは、次に、フォークリフト２が利用可能である場合（図中でハイライトされている）、別のフォークリフト２を使用して「MoveToDrop」プランを再トリガし得る。トレース中に、ＡＧＶ５０７の行動「MoveToDrop」がフォークリフト１の「MoveToDrop」行動と共にアクティブになっている可能性があることをユーザは見出し得る。後に、フォークリフト１がエラーに遭遇した場合、別のフォークリフト（例えばフォークリフト２）に対する「MoveTopDrop」行動５０９がアクティブになっている。このシステムは、「MoveTopPallet」行動が失敗し、タスク割り当ての変更につながり、したがって、新しいフォークリフトが完成するために、ＡＧＶを支援するために加わることのユーザのための視覚的表現を可能にし得る。

図６は、一実施形態による、ターゲット情報を生成及び表示するための例示的なシステムを示すシステム図である。システム６００は、動作環境で作業する複数のロボットを有する。簡略化のために、ロボット６０１と６１１の２台のみを示す。各ロボット（例えば、ロボット６０１）は、ノード、例えば、デブトレースアプリケーション６０２、デブトレースエンジン６０３、デブトレースレポータ６０４、ローカルセンサ及びロボットの異なる状態（アイドル、準備完了、待機、アクティブ、サスペンド、終了など）の間にロボットセンサによってキャプチャされるとともにロボットによって処理されるデータ値を格納するための実行ストアを含む。各ロボットは、命令を実行するプロセッサと、命令を格納するストレージを有する。各ロボットは、倉庫でのナビゲーション行程の間、互いに通信し、協力する。複数のロボットはまた、ユーザインターフェース（ＵＩ）モジュール６２２、デブトレースコレクタモジュール６２５、プラグインライブラリストア６２３、ロスバッグコレクタノード６２４、ログコレクタノード６２６、インテリジェントフィルタリングモジュール６２７を含むサーバノード６２１と通信する。ＵＩモジュール６２２を介して視覚インターフェースが提供され、ユーザがライブラリ及び／又はプラグインをインポートすることを可能にして、故障又はエラーの場合にシステムを修復すること、生産性を向上させるための最適なソリューションを推奨すること、機械学習モデルを利用して学習すること、パターンを識別するためにシステムを訓練すること、及びシステムを改善することなどの追加機能を含むために、システム６００の能力を向上させる。ノードは、ライブラリ若しくはＡＰＩ若しくはデーモン若しくはスクリプト、又はノードを実行するための１つ以上のプロセッサを有する１つ以上のコンピューティングシステム上で動き得るソフトウェアモジュールであり得る。ノードは、コンピューティングシステムの機能を達成するために互いにインタラクトするための相互通信プロセスを含み得る。また、システム６００は、ユーザが、本発明の目的を達成するためにターゲット情報を取り出すために、カスタマイズされた検索クエリを入力することを可能にする。システム６００は、結果を提供するために、サーバノード、ＵＩモジュール６２２を利用する。

本明細書に開示される実施形態は、動作環境における複数のロボットのナビゲーションに関連するターゲット情報を生成及び表示するための方法及びシステムを記述する。従って、保護の範囲は、そのようなプログラム及び、加えて、その中にメッセージを有するコンピュータ読取可能な記憶手段に拡張されることが理解され、そのようなコンピュータ読取可能な記憶手段は、プログラムがサーバ又はモバイルデバイス又は任意の適切なプログラマブルデバイス上で動くときに、本方法の１つ以上のステップの実装のためのプログラムコード手段を含む。一実施形態では、１つのロボット上で動くノードは、他のロボット上で動くノードと機能を分散させ得る、及び／又は、それらの間で及び／又はサーバノードと協力して、本明細書に記載の機能及び実施形態を実装し得る。デバイス上で動くノードは、例えば、超高速集積回路ハードウェア記述言語（ＶＨＤＬ）、別のプログラミング言語で書かれたソフトウェアプログラムを介して、又はそれと共に、少なくとも１つの実施形態で実施されるか、又は少なくとも１つのハードウェアデバイス上で実行される１つ以上のＶＨＤＬ又はいくつかのソフトウェアモジュールによって実装される。ハードウェアデバイスは、例えば、サーバ又はパーソナルコンピュータなどの任意の種類のコンピュータ、又はそれらの任意の組み合わせ、例えば、１つのプロセッサ及び２つのＦＰＧＡを含む、プログラムされることができる任意の種類のデバイスであることができる。また、デバイスは、例えば、ＡＳＩＣのようなハードウェア手段、又は、ハードウェア及びソフトウェア手段の組み合わせ、例えば、ＡＳＩＣ及びＦＰＧＡ、又は、少なくとも１つのマイクロプロセッサ及びその中に位置するソフトウェアモジュールを有する少なくとも１つのメモリであることができる手段を含み得る。したがって、手段は、少なくとも１つのハードウェア手段及び／又は少なくとも１つのソフトウェア手段である。本明細書に記載される方法の実施形態は、純粋なハードウェアで、又は部分的にハードウェア及び部分的にソフトウェアで実装することができる。また、デバイスは、ソフトウェア手段のみを含んでもよい。代替的に、本発明は、異なるハードウェアデバイス上で、例えば複数のＣＰＵを使用して、実装され得る。

特定の実施形態の前述の説明は、本明細書における実施形態の一般的な性質を十分に明らかにするものであり、現在の知識を適用することにより、他の者は、一般的概念から逸脱することなく、そのような特定の実施形態を容易に修正する及び／又は種々の用途に適応させることができ、従って、そのような適応及び修正は、開示された実施形態の均等物の意味及び範囲内で理解されるべきであり、かつ理解されることを意図する。本明細書で使用される語句又は用語は、説明の目的のためであり、限定のためではないことが理解されるべきである。従って、本明細書の実施形態は、実施形態及び例に関して説明されたが、当業者は、本明細書の実施形態は、本出願に記載された特許請求の範囲の精神及び範囲内の修正を伴って実施されることができることを認識するであろう。

Claims (20)

1. 動作環境で作業する複数のロボットに関連するターゲット情報を生成し、報告するためのコンピュータ実装方法であって、前記方法は：
   １つ又は複数のロボット上で動作するノードが：
   前記１つ又は複数のロボットのアクティブプランに関連する１つ又は複数の行動を実行することと；
   実行する前記行動に関連する１つ又は複数のスナップショットを作成することであって、前記スナップショットは複数のフィールドを含み、各前記フィールドは値が割り当てられる、スナップショットを作成することと；
   前記実行する行動に関連する親コンテキストに基づいて情報をキャプチャすることであって、前記親コンテキストは、前記１つ又は複数のロボットの前記アクティブプランの親情報を含む、キャプチャすることと；
   キャプチャされた前記情報、前記動作環境、及び前記１つ又は複数のロボットのうちの少なくとも１つ又は複数に関連する値を前記１つ又は複数のスナップショットの前記複数のフィールドに入力することと；
   前記１つ又は複数の行動の実行の結果として、前記１つ又は複数のスナップショットを閉じることと；
   を実行し、
   前記１つ又は複数のロボット上で動作するレポータノードが；
   閉じられた前記スナップショットを集約し、前記ターゲット情報を表示するために前記ターゲット情報の一部として集約された前記スナップショットをレポートすることと、を実行する、
   コンピュータ実装方法。
2. 前記１つ又は複数のスナップショットの前記複数のフィールドに入力することは：
   前記１つ又は複数のロボット上で動作する前記ノードが、前記複数のロボット上で実行されるエージェントに割り当てられるアクティブエントリポイント、ユーティリティ機能、前記アクティブプランを実行するロボット、前記ロボット間のスイッチング、競合、及び前記１つ又は複数のスナップショットの関連フィールドへのゲインを含むメタデータを追加することと；
   前記ターゲット情報に基づいた診断を提供することと；を含む、
   請求項１に記載のコンピュータ実装方法。
3. 前記１つ又は複数のロボット上で動作する前記ノードが、前記１つ又は複数のロボットに関連するエラーを受信し；
   前記１つ又は複数のロボット上で動作する前記レポータノードが、前記エラーに関連するターゲット情報をレポートすることであって、前記ターゲット情報は、前記複数のロボットに関連する前記エラーを解決することを可能にする、レポートすること；
   をさらに含む、
   請求項１に記載のコンピュータ実装方法。
4. 前記ターゲット情報をレポートすることは：
   前記１つ又は複数のロボット上で動作する前記ノードが、エラーに関連するコンテキスト情報を取得することを含み、前記コンテキスト情報は、前記ロボットの位置、スナップショットＩＤ、マップＩＤ、エラー情報、及び前記動作環境でナビゲートされることになる目的地のうちの少なくとも１つ又は複数を含む、
   請求項１に記載のコンピュータ実装方法。
5. 前記ターゲット情報をレポートすることは：
   １つ又は複数のロボット上で動作する前記ノードが、前記１つ又は複数の行動を実行する間に前記複数のロボットに割り当てられたタスクを評価することと；
   前記タスクの評価に応じて、評価された前記タスクのコンテキストで前記１つ又は複数の行動を実行するのに費やされる時間を決定することと；
   前記評価されたタスクを実行するのにかかる時間及び前記１つ又は複数の行動を実行するのに費やされる決定された前記時間のうちの少なくとも１つ又は複数に関するクエリを受信すること；
   及び
   前記１つ又は複数のロボット上で動作する前記レポータノードが、前記評価されたタスクを実行するのにかかる前記時間及び前記１つ又は複数の行動を実行するのに費やされる前記決定された時間のうちの少なくとも１つ又は複数を視覚的にレポートすることであって、前記視覚的にレポートすることは形状を含み、前記形状の大きさは、前記評価されたタスクを実行するのにかかる前記時間及び前記１つ又は複数の行動を実行するのに費やされる前記決定された時間のうちの少なくとも１つ又は複数を示す、レポートすること；
   を含む、
   請求項１に記載のコンピュータ実装方法。
6. 前記１つ又は複数のロボット上で動作する前記ノードが、リアルタイムでエラーを診断するためのプラグインを統合することであって、前記プラグインはロスバッグ収集モジュールを含む、統合することと；
   開始時間と終了時間内にトリガされる前記エラーを診断するための前記開始時間と前記終了時間を受信することと；
   前記エラーを診断するために視覚的表現を提供することと；
   前記エラーを診断するための関連する情報を抽出するために、ロスバッグの分析を可能にすることと；
   をさらに含む、
   請求項１に記載のコンピュータ実装方法。
7. ターゲット情報を生成及び表示するためのシステムであって、前記システムは：
   動作環境で作業する複数のロボットであって、各前記ロボットは、命令を実行するプロセッサ及び前記命令を記憶するメモリを含む、複数のロボットと；１つ又は複数のサーバ上で動作する複数のサーバノードと；前記複数のサーバノードと通信する前記１つ又は複数のロボットで実行する複数のノードであって：
   前記動作環境で作業する前記複数のロボットの、アクティブプランに関連する、１つ又は複数の行動を実行することと;
   実行する前記行動に関連する１つ又は複数のスナップショットを作成することであって、前記スナップショットは複数のフィールドを含み、各前記フィールドは値が割り当てられる、スナップショットを作成することと；
   前記実行する行動に関連する親コンテキストに基づいて情報をキャプチャすることであって、前記親コンテキストは、前記アクティブプランの親情報を含む、キャプチャすることと；
   キャプチャされた前記情報、前記動作環境、及び前記１つ又は複数のロボットのうちの少なくとも１つ又は複数に関連する値を前記１つ又は複数のスナップショットの前記複数のフィールドに入力することと；
   前記１つ又は複数の行動の実行の結果として、前記１つ又は複数のスナップショットを閉じることと；
   閉じられた前記スナップショットを集約し、前記ターゲット情報の一部として集約された前記スナップショットをレポートすることと；
   前記動作環境で作業する前記複数のロボットに関連する前記ターゲット情報を表示すること；を含む、
   複数のノードと；を含む、
   システム。
8. 前記複数のロボットから第１のロボットを支援するために第２のロボットが利用可能であるという入力を受信することと；
   受信した前記入力に応じて前記第１のロボットによって実行されている動作に関連するスナップショットを閉じることと；
   前記第２のロボットを支援している前記第１のロボットによって実行されているプラン、行動、及びプランタイプのうちの少なくとも１つ又は複数に関連する新しいスナップショットを作成すること；をさらに含む、
   請求項７に記載のシステム。
9. 前記第１のロボット及び前記第２のロボットが前記行動を実行している値を要約情報関連フィールドに入力することと；
   タスク割当関連フィールドについて両方の前記ロボットのロボットＩＤ及びタスク詳細を更新することと；
   前記ロボットＩＤ及び前記タスク詳細を更新することに応じて、前記第１のロボットを支援する前記第２のロボットによって達成されたゲインを検証することと；
   前記検証に応じて、前記行動の実行のパフォーマンスを示す値をゲイン関連フィールドに入力することと；をさらに含む、
   請求項８に記載のシステム。
10. 前記第２のロボットによって実行されるプラン、行動、及びプランタイプのうちの少なくとも１つ又は複数に関連する追加のスナップショットを作成することと；
    作成された前記スナップショットを集約し、集約された前記スナップショットをレポートすることと；をさらに含む、
    請求項８に記載のシステム。
11. 前記新しいスナップショットの関連フィールドに、前記第１のロボット及び前記第２のロボットの位置並びにタスク関連情報を入力することと；
    前記行動の実行の前記結果に関連するフィールドの値として信頼スコアを決定することであって、前記信頼スコアを成功又は失敗を示すスケールによって表される、決定することと；
    前記新しいスナップショットを集約し、集約された前記スナップショットを前記ターゲット情報の一部としてレポートすることと；をさらに含む、
    請求項８に記載のシステム。
12. 前記第１のロボットを支援する前記第２のロボットの移動した距離及び向きをキャプチャすることと；
    前記キャプチャすることに応じて、前記新しいスナップショットの前記フィールドに入力する前に、前記第２のロボットの前記向き及び前記移動した距離が前記第１のロボットとの適切な位置合わせを可能にしたことを検証することと；をさらに含む、
    請求項８に記載のシステム。
13. 前記第２のロボットの前記第１のロボットへの支援のリアルタイムデバッグに関連するクエリを受信することと；
    前記第２のロボットが前記第１のロボットを支援している間にキャプチャされるライブイベントをレポートすることと；をさらに含む、
    請求項８に記載のシステム。
14. 時間ウィンドウのサブセット内で前記複数のロボットによって実行される行動、プラン、及びプランタイプのうちの少なくとも１つに関連する入力を受信することであって、前記時間ウィンドウは、前記動作環境で作業する前記複数のロボットによって費やされる時間を含む、受信することと；
    前記集約されたスナップショットのフィールドの値を、前記時間ウィンドウのサブセット内の且つ前記ロボットによって実行される行動、プラン、及びプランタイプの少なくとも１つに関連する前記ターゲット情報の一部としてレポートすることと；をさらに含む、
    請求項７に記載のシステム。
15. 前記第１のロボット又は前記第２のロボットによって実行される行動、プラン、及びプランタイプのうちの少なくとも１つに関連する入力を受信することと；
    デバッグに関連するエラーを修正する又は前記第１のロボット若しくは前記第２のロボットのパフォーマンスゲインを測定するために、受信した前記入力に関連する関連フィールドの値をレポートすることと；をさらに含む、
    請求項８に記載のシステム。
16. 前記第２のロボットの前記第１のロボットへの支援に関連するエラーを受信することと；
    前記集約されたスナップショットの値に基づいて障害のある前記ロボットを識別することであって、前記第２のロボットが前記障害のあるロボットである、識別することと；
    前記第１のロボットを支援するために他のロボットが利用可能かどうかを検証するために、修理プロセスを自動的に開始することと；
    利用できることに基づいて、前記他のロボットによって実行されているプラン、行動、及びプランタイプの少なくとも１つ以上を再トリガすることと；をさらに含む、
    請求項８に記載のシステム。
17. 命令を記憶した非一時的コンピュータ読取可能記憶媒体であって、前記命令は、コンピュータによって実行されるときに、前記コンピュータに：
    動作環境で作業する複数のロボットの、アクティブプランに関連する、１つ又は複数の行動を実行させ；
    前記行動を実行することに関連する１つ又は複数のスナップショットを作成させ、前記スナップショットは複数のフィールドを含み、各フィールドは値が割り当てられ；
    前記行動を実行することに関連する親コンテキストに基づいて情報をキャプチャさせ、前記親コンテキストは前記アクティブプランの親情報をみ；
    前記スナップショットの前記複数のフィールドに、キャプチャされた前記情報、前記動作環境、及び前記ロボットのうちの少なくとも１つ又は複数に関連する値を入力させ；
    前記１つ又は複数の行動の実行の結果として前記１つ又は複数のスナップショットを閉じさせ；
    閉じた前記スナップショットを集約し、集約された前記スナップショットをターゲット情報の一部としてレポートさせ；
    前記動作環境で動作する前記複数のロボットに関連する前記ターゲット情報を表示させる；
    命令を記憶した非一時的コンピュータ読取可能記憶媒体。
18. 前記命令は、前記コンピュータによって実行されるときに、さらに、前記コンピュータに：
    前記複数のロボットから第１のロボットを支援するために第２のロボットが利用可能であるという入力を受信させ；
    受信した前記入力に応じて前記第１のロボットによって実行されている行動に関するスナップショットを閉じさせ；
    前記第２のロボットを支援する前記第１のロボットによって実行されているプラン、行動、及びプランタイプの少なくとも１つ又は複数に関連する新しいスナップショットを作成させる；
    請求項１７に記載の命令を記憶した非一時的コンピュータ読取可能記憶媒体。
19. 前記命令は、前記コンピュータによって実行されるときに、さらに、前記コンピュータに：
    前記第１のロボットへの前記第２のロボットの支援に関連するエラーを受信させ;
    前記集約されたスナップショットの値に基づいて障害のある前記ロボットを識別させ、前記第２のロボットは前記障害のあるロボットであり；
    前記第１のロボットを支援するために他のロボットが利用可能かどうかを検証するために修理プロセスを自動的に開始させ；
    利用できることに基づいて、前記他のロボットが実行しているプラン、行動、及びプランタイプの少なくとも１つ又は複数を再トリガさせる；
    請求項１８に記載の命令を記憶した非一時的コンピュータ読取可能記憶媒体。
20. 前記命令は、前記コンピュータによって実行されるときに、さらに、前記コンピュータに：
    前記第１のロボットへの前記第２のロボットの支援のリアルタイムデバッグに関連するクエリを受信させ；
    前記第２のロボットが前記第１のロボットを支援している間にキャプチャされるライブイベントをレポートさせる；
    請求項１８に記載の命令を記憶した非一時的コンピュータ読取可能記憶媒体。

Images