特開 2023-3124 ロボット支援システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023003124

(43)【公開日】2023-01-11

(54)【発明の名称】ロボット支援システム

(51)【国際特許分類】

   G05B 19/418 20060101AFI20221228BHJP

   B25J 9/16 20060101ALI20221228BHJP

   G05B 23/02 20060101ALI20221228BHJP

【ＦＩ】

G05B19/418 Z

B25J9/16

G05B23/02 T

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2021104104

(22)【出願日】2021-06-23

(71)【出願人】

【識別番号】714008031

【氏名又は名称】株式会社キビテク

(74)【代理人】

【識別番号】100123858

【弁理士】

【氏名又は名称】磯田 志郎

(72)【発明者】

【氏名】行村 隆志

(72)【発明者】

【氏名】林 摩梨花

(72)【発明者】

【氏名】菊嶋 久光

【テーマコード（参考）】

3C100

3C223

3C707

【Ｆターム（参考）】

3C100AA25

3C100AA38

3C100AA48

3C100AA59

3C100BB12

3C100BB13

3C100BB17

3C100BB21

3C100BB33

3C100CC02

3C100CC14

3C223AA12

3C223BA03

3C223CC02

3C223DD03

3C223EA07

3C223EB02

3C223EB04

3C223FF02

3C223FF12

3C223FF33

3C223FF48

3C223GG01

3C223HH02

3C223HH08

3C223HH29

3C707AS01

3C707AS04

3C707AS14

3C707AS34

3C707BS09

3C707CS00

3C707JS02

3C707JS03

3C707JS07

3C707JU02

3C707JU12

3C707JU13

3C707LV13

3C707LV15

(57)【要約】      （修正有）

【課題】多種、多数のロボットを支援するシステムにおいて、複数のオペレータを割り当てる場合、支援タスクの処理時間、通信時間が異なる中で、適正で効率的なタスクの割り当てを提供する。
【解決手段】ロボットと、支援管理サーバと、複数のＵＩ端末とがネットワークを介して接続可能であり、ロボットは、支援が必要なタスクのタスク情報を支援管理サーバに提供可能であり、支援管理サーバは、タスク情報に応じて担当ＵＩ端末を選択する担当ＵＩ選択手段と、ロボットとＵＩ端末との間の総予測通信遅延時間を推定する通信状況推定手段と、タスク情報に関連付けられた遅延許容情報を取得する許容度取得手段とを含み、遅延許容情報と、総予測通信遅延時間とを用いて、担当ＵＩ端末を選択し、ＵＩ端末は、入力手段を含み、入力手段によって入力された情報をロボットに提供可能である。
【選択図】図１

【特許請求の範囲】

【請求項1】

ロボットと、支援管理サーバと、複数のユーザインターフェース端末とを含むロボット支援システムであって、
前記ロボットと、前記支援管理サーバと、前記複数のユーザインターフェース端末とは、ネットワークを介して接続可能であり、
前記ロボットは、前記支援管理サーバに支援要請を実行可能な支援要請手段と、当該ロボットが実行するタスクを特定するタスク情報を記憶した記憶手段とを含み、前記支援要請手段は、支援が必要なタスクのタスク情報を前記支援管理サーバに提供可能であり、
前記支援管理サーバは、前記ロボットからのタスク情報に応じて前記複数のユーザインターフェース端末から担当ユーザインターフェース端末を選択する担当ＵＩ選択手段と、ロボットとユーザインターフェース端末との間の総予測通信遅延時間を推定する通信状況推定手段と、タスク情報に関連付けられた遅延許容情報を取得する許容度取得手段とを含み、前記ロボットから提供されたタスク情報に関連付けられた遅延許容情報と、ロボットとユーザインターフェース端末との間の総予測通信遅延時間とを用いて、前記担当ユーザインターフェース端末を選択し、
前記ユーザインターフェース端末は、前記ロボットを指示又は操作可能な入力手段を含み、前記入力手段によって入力された情報を前記ロボットに提供可能である、ロボット支援システム。

【請求項2】

前記通信状況推定手段は、支援管理サーバとロボットとの間のロボット側予測通信遅延時間と、支援管理サーバとユーザインターフェース端末との間のＵＩ側予測通信遅延時間とを組み合わせてロボットとユーザインターフェース端末との間の総予測通信遅延時間を推定する、請求項１に記載のロボット支援システム。

【請求項3】

前記支援管理サーバは、一つ又は複数のロボットから提供された複数のタスク情報について、各タスク情報に関連付けられた遅延許容情報を取得し、前記一つ又は複数のロボットについて、それぞれ複数のユーザインターフェース端末と組み合わせて、複数の総予測通信遅延時間又は支援管理サーバと各ユーザインターフェース端末との間の複数のＵＩ側予測通信遅延時間を推定し、前記複数のタスク情報の全てにおいて遅延許容情報に適合するように、前記複数の総予測通信遅延時間又は複数のＵＩ側予測通信遅延時間を用いて、担当ユーザインターフェース端末を選択する、請求項１又は２に記載のロボット支援システム。

【請求項4】

前記支援管理サーバは、タスク情報に関連付けられた処理予測時間又はユーザインターフェース端末から各タスク情報に関連付けられたユーザ処理時間を取得し、前記処理予測時間又は前記ユーザ処理時間を用いて前記担当ユーザインターフェース端末を選択する、請求項１～３の何れか１項に記載のロボット支援システム。

【請求項5】

前記支援管理サーバは、順番に提供された複数のタスク情報について、前記処理予測時間又は前記ユーザ処理時間を用いて複数のタスク情報の順番を設定する、請求項４に記載のロボット支援システム。

【請求項6】

前記管理支援サーバは、タスク情報に関連付けられたタスク中待ち時間を用いて、当該タスク情報に対する担当ユーザインターフェース端末を別のタスク情報に対する担当ユーザインターフェース端末に選択する、請求項１～５の何れか１項に記載のロボット支援システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ロボット支援システムに関し、特に、ロボットと支援管理サーバとユーザインターフェース端末で構成され、ロボット、支援管理サーバ及びユーザインターフェース端末がネットワークを介して接続可能であり、ロボットが支援を必要な状況において、オペレータがユーザインターフェース端末から、ロボットの動作を支援することが可能なロボット支援システムに関する。

【背景技術】

【0002】

近年、様々な分野において自律的に作業するロボットによる自動化が進んでいるが、ロボットにトラブルが生じた場合、ロボット自体に自動的にトラブルを解消する手段を設けたり、オペレータ等によってロボットを支援したりすることが行われている。また、ロボットの種類によっては自動化にも限界があり、オペレータによるロボットの支援が必要とされることもある。

【0003】

従来から、手術支援ロボットを遠隔支援する遠隔支援システムが知られていた（特許文献１）。特許文献１には、手術支援ロボットの稼働に関する稼働情報の少なくとも１つを、手術支援ロボットの遠隔支援業務を行うためのサーバ装置にて受信し、所定のイベントが検出されると、サーバ装置から手術支援ロボットおよび端末装置の少なくとも１つに対して、音声、画像、およびテキストの少なくとも１つを配信する手術支援ロボットの遠隔支援方法が開示されている。

【0004】

また、従来から、遠隔制御システムの応答性の低下を抑制することができる遠隔制御システムが知られていた（特許文献２）。特許文献２には、制御対象の機器が設置された環境に関する情報を示す環境情報と、機器の状態を示す状態情報とのいずれかを含む検知信号に基づいて機器を制御するための制御信号を生成する制御処理を実行可能な第１の制御装置と、第１の制御装置から検知信号を取得し、制御処理を実行可能な第２の制御装置とを持ち、負荷情報と、処理時間と、ネットワーク応答時間に基づいて、検知信号に対する制御処理の実行を、通信装置とサーバとで分配する分配部を持つことにより、遠隔制御システムの応答性の低下を抑制することができる遠隔制御システム、遠隔制御方法、制御装置及びコンピュータプログラムが開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０２０－６０８８０号公報

【特許文献2】特開２０１６－１１９５１４号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

特許文献１では、手術支援ロボットの稼働に関する稼働情報を、手術支援ロボットの遠隔支援業務を行うためのサーバ装置にて受信し、所定のイベントが検出されると、サーバ装置から手術支援ロボットおよび端末装置の少なくとも１つに対して、音声、画像、およびテキストの少なくとも１つを配信することにより、手術支援ロボットを用いた手術等を行う遠隔支援システムが開示されている。手術支援ロボットにイベントが発生した場合、手術支援ロボットの撮影した画像、手術室の画像等の稼働情報をサーバ装置経由で端末装置に通知し、オペレータは、そのイベントの内容、画像の内容を基に、端末装置からサーバ装置経由で手術支援ロボットにイベントに対応する情報を配信する遠隔支援システムが開示されているが、複数のロボットが稼働している現場で発生する複数種類のタスク情報をそれぞれ異なる複数のユーザインターフェース端末に割り当てる際にロボット稼働現場やユーザインターフェース端末ごとにネットワークの遅延が様々あり、また、支援するタスクごとに所要時間も異なる中で、適正でかつ効率的な支援タスクの割り当てを行うことについては開示されていない。

【0007】

また、特許文献２では、制御対象の機器が設置された環境に関する情報を示す環境情報と、機器の状態を示す状態情報とのいずれかを含む検知信号に基づいて機器を制御するための制御信号を生成する制御処理を実行可能な第１の制御装置と、第１の制御装置から検知信号を取得し、制御処理を実行可能な第２の制御装置とを持ち、負荷情報と、処理時間と、ネットワーク応答時間に基づいて、検知信号に対する制御処理の実行を、通信装置とサーバとで分配する分配部を持つことにより、遠隔制御システムの応答性の低下を抑制することができる遠隔制御システム、遠隔制御方法、制御装置及びコンピュータプログラムが開示されているが、特許文献１と同様に、複数のロボットが稼働している現場で発生する複数種類のタスク情報をそれぞれ異なる複数のユーザインターフェース端末に割り当てる際にロボット稼働現場やユーザインターフェース端末ごとにネットワークの遅延が様々あり、また、支援するタスクごとに所要時間も異なる中で、適正でかつ効率的な支援タスクの割り当てを行うことについては開示されていない。

【0008】

本発明は、前述した課題を解決することを目的とするものであり、複数のロボットが稼働している現場で発生する複数種類のタスク情報をそれぞれ異なる複数のユーザインターフェース端末に割り当てる際に、オペレータによる適正でかつ効率的な支援が可能なロボット支援システムを提供することを目的の一つとする。

【課題を解決するための手段】

【0009】

上記の課題を解決するため、本発明のロボット支援システムは、ロボットと、支援管理サーバと、複数のユーザインターフェース端末とを含むロボット支援システムであって、前記ロボットと、前記支援管理サーバと、前記複数のユーザインターフェース端末とは、ネットワークを介して接続可能であり、前記ロボットは、前記支援管理サーバに支援要請を実行可能な支援要請手段と、当該ロボットが実行するタスクを特定するタスク情報を記憶した記憶手段とを含み、前記支援要請手段は、支援が必要なタスクのタスク情報を前記支援管理サーバに提供可能であり、前記支援管理サーバは、前記ロボットからのタスク情報に応じて前記複数のユーザインターフェース端末から担当ユーザインターフェース端末を選択する担当ＵＩ選択手段と、ロボットとユーザインターフェース端末との間の総予測通信遅延時間を推定する通信状況推定手段と、タスク情報に関連付けられた遅延許容情報を取得する許容度取得手段とを含み、前記ロボットから提供されたタスク情報に関連付けられた遅延許容情報と、ロボットとユーザインターフェース端末との間の総予測通信遅延時間とを用いて、前記担当ユーザインターフェース端末を選択し、前記ユーザインターフェース端末は、前記ロボットを指示又は操作可能な入力手段を含み、前記入力手段によって入力された情報を前記ロボットに提供可能である。

【0010】

さらに、上記ロボット支援システムにおいて、前記通信状況推定手段は、支援管理サーバとロボットとの間のロボット側予測通信遅延時間と、支援管理サーバとユーザインターフェース端末との間のＵＩ側予測通信遅延時間とを組み合わせてロボットとユーザインターフェース端末との間の総予測通信遅延時間を推定してもよい。

【0011】

さらに、上記ロボット支援システムにおいて、前記支援管理サーバは、一つ又は複数のロボットから提供された複数のタスク情報について、各タスク情報に関連付けられた遅延許容情報を取得し、前記一つ又は複数のロボットについて、それぞれ複数のユーザインターフェース端末と組み合わせて、複数の総予測通信遅延時間又は支援管理サーバと各ユーザインターフェース端末との間の複数のＵＩ側予測通信遅延時間を推定し、前記複数のタスク情報の全てにおいて遅延許容情報に適合するように、前記複数の総予測通信遅延時間又は複数のＵＩ側予測通信遅延時間を用いて、担当ユーザインターフェース端末を選択してもよい。

【0012】

さらに、上記ロボット支援システムにおいて、前記支援管理サーバは、タスク情報に関連付けられた処理予測時間又はユーザインターフェース端末から各タスク情報に関連付けられたユーザ処理時間を取得し、前記処理予測時間又は前記ユーザ処理時間を用いて前記担当ユーザインターフェース端末を選択してもよく、さらに、前記支援管理サーバは、順番に提供された複数のタスク情報について、前記処理予測時間又は前記ユーザ処理時間を用いて複数のタスク情報の順番を設定してもよい。

【0013】

さらに、上記ロボット支援システムにおいて、前記管理支援サーバは、タスク情報に関連付けられたタスク中待ち時間を用いて、当該タスク情報に対する担当ユーザインターフェース端末を別のタスク情報に対する担当ユーザインターフェース端末に選択してもよい。

【発明の効果】

【0014】

本発明のロボット支援システムによれば、ロボットにオペレータ支援の要請のイベントが発生した場合、支援管理サーバは、ロボットから提供されたタスク情報に関連付けられた遅延許容情報と、ロボットとユーザインターフェース端末（以下、ＵＩ端末ともいう）との間の総予測通信遅延時間とを用いて、担当ユーザインターフェース端末を選択できるため、オペレータによる適正でかつ効率的な支援が可能となる。例えば、ロボットとＵＩ端末との間の総予測通信遅延時間が、遅延許容情報に含まれる支援が必要な作業について許容できる時間の範囲内であれば、オペレータからの支援を適切に受けることができる。また、例えば、遅延許容情報に含まれる支援が必要な作業について許容できる緊急度が高い場合は、総予測通信遅延時間が短いＵＩ端末を優先的に選択し、緊急度が低い場合は、総予測通信遅延時間が長いＵＩ端末を選択することもできる。

【0015】

さらに、支援管理サーバとロボットとの間のロボット側予測通信遅延時間と、支援管理サーバとＵＩ端末との間のＵＩ側予測通信遅延時間とを組み合わせてロボットとＵＩ端末との間の総予測通信遅延時間を推定する場合、支援管理サーバは、事前にロボット及び／又はＵＩ端末と通信しておくことで、ロボット側予測通信遅延時間と、ＵＩ側予測通信遅延時間とを取得することができ、支援要請の際に、速やかに総予測通信遅延時間を推定することができ、担当ＵＩ端末を選択できる。

【0016】

また、支援管理サーバは、複数のロボットから提供された複数のタスク情報について、各タスク情報に関連付けられた遅延許容情報及び当該タスク情報を提供したロボットとの間のロボット側予測通信遅延時間を取得し、複数のＵＩ端末について、各ＵＩ端末との間のＵＩ側予測通信遅延時間を取得し、全てのタスク情報において、総予測通信遅延時間が遅延許容情報の範囲内となるようにＵＩ側予測通信遅延時間の担当ＵＩ端末を選択することで、複数のタスク情報に対する担当ＵＩ端末の割り当てを全体として効率化できる。

【0017】

また、タスク情報に関連付けられた処理予測時間（タスク情報の支援作業を処理するのに要する概算の時間）又はＵＩ端末から各タスク情報に関連付けられたユーザ処理時間を取得し、処理予測時間又はユーザ処理時間を用いて担当ＵＩ端末を選択することにより、遅延許容情報と処理予測時間又はユーザ処理時間とから必要な支援要請に対して的確に支援作業を提供できる。さらに、支援管理サーバは、順番に提供された複数のタスク情報について、処理予測時間又はユーザ処理時間を用いて複数のタスク情報の順番を変更することができ、複数のタスク情報を全体として効率化できる。

【0018】

加えて、管理支援サーバは、タスク情報に関連付けられたタスク中待ち時間を用いて、当該タスク情報に対する担当ＵＩ端末を別のタスク情報に対する担当ＵＩ端末に選択することも可能であり、ＵＩ端末（オペレータ）という有限のリソースを有効に利用することができる。

【図面の簡単な説明】

【0019】

【図1】支援管理サーバが担当ＵＩ端末を選択するまでのフローチャートの一例。

【図2】本発明のロボット支援システムの構成要素を示す図。

【図3】本発明の各構成要素（支援管理サーバ）とデータ構造を示す図。

【図4】本発明の各構成要素（ＵＩ端末及びロボット）とデータ構造を示す図。

【図5】支援管理サーバが複数の支援要請により複数のタスク情報を取得した場合のフローチャートの一例。

【図6】支援管理サーバが複数の支援要請により複数のタスク情報を取得した場合のフローチャートの他の一例

【図7】担当ＵＩ端末でオペレーション中に発生する待ち時間を利用するためのフローチャートの一例。

【発明を実施するための形態】

【0020】

そもそも、ロボットによって全ての作業及びトラブルを自動的に処理できるのが理想であるが、全ての作業及びトラブルに対して完璧な対応を準備するのは技術的にも費用的にも困難である。そこで、一部の作業又はトラブルについてはオペレータによる支援を前提としてロボットを設計するという現実的な思想を新たに提案する。例えば、通常時には自律して作業を処理するが、自律処理できない場合（例えば異常時又は人の判断が必要な処理時）にはオペレータの支援を求め、オペレータからの支援（例えば指示又は操作）によって作業できるようにロボットを設計する。

【0021】

例えば、工場や倉庫内では、効率化、コスト削減の意味から、人手に代わりロボットに作業を実施させる形態が実施されつつある。搬送ロボットは、工場や倉庫で部品や商品を運んでいるが、自律走行の失敗からの復帰、プログラムすることが困難な狭路の走行、搬送先の変更等のタスクにおいて、オペレータからの支援を要請してもよい。設備点検ロボットは、工場等の施設を巡回し、稼働設備の点検、メータの検針等を行うが、自律走行からの復帰、プログラムすることが困難な狭路の走行、オペレータの判断が必要な点検、及び点検箇所のカメラ合わせ等のタスクにおいて、オペレータからの支援を要請してもよい。アームロボットは、商品等のピッキングを行うが、対象の商品が認識できない場合等のタスクにおいて、オペレータからの支援を要請してもよい。外観検査ロボットは、製造ラインを流れている商品に異常がないか検査するが、オペレータが画像を見て良品、不良品の判断が必要な場合等のタスクにおいて、オペレータからの支援を要請してもよい。施設案内ロボットは、商業施設等において利用者に対して案内を行うが、案内先の認識不可、自律走行からの復帰、人が密集する場所の走行等のタスクにおいて、オペレータからの支援を要請してもよい。

【0022】

このような設計は、複数の稼働場所に配置され、様々なタスクを実行する多種多様な複数のロボットに対して適用することが可能である。そして、この設計思想では、オペレータの介在を前提としており、ネットワークを通じてオペレータがロボットに支援できるようにして、異なる複数の作業場所で作業している複数のロボットに対して、また、同種のタスクを実行する複数のロボットだけではなく、様々なタスクを実行する多種多様な複数のロボットに対して支援するシステムとすることもできる。加えて、ユーザインターフェース端末（ＵＩ端末）が配置され、オペレータが支援作業を実施する拠点（オペレータがＵＩ端末を携帯して移動する場合のオペレータの居場所を含む）についても、一つの拠点において多数のＵＩ端末が配置され、多数のオペレータが作業する態様も、多数のオペレータが作業する拠点を複数設ける態様も、様々な拠点において個別のオペレータが個別又は複数のＵＩ端末で作業する態様であってもよい。その場合、多種多様なロボットに対して、又は複数の異なるタスクに対して、それぞれ専用のオペレータを配置してもよいが、多種多様なロボットの複数の異なるタスクを支援可能なオペレータを配置できれば、オペレータの支援作業量を均一化することができ、迅速な支援が実現できる。つまり、ロボット及び／又はタスクの種類によって支援を必要とする頻度にばらつきがあるが、専用のオペレータを配置した場合は、頻度の少ない支援を担当するオペレータが、頻度の多い支援作業を手伝うことができず、結果として頻度の多い支援については適切なタイミングで支援するのが難しくなる。この点、オペレータが多種多様なロボットの複数の異なるタスクを支援可能であれば、支援作業を分担して処理することができる。

【0023】

本発明は、このようなロボット支援システムにおいて、ロボットからの支援要請に対し、担当するＵＩ端末（担当ＵＩ端末）を効率よく適切に選択するためのものである。例えば、様々なロボットが実行している様々なタスクについて支援要請が生じ得るが、オペレータの指示や操作が直ちに必要なものもあれば、比較的時間的な余裕のあるものもあり、単に順番に支援要請を処理しただけでは十分なサポートができない可能性がある。また、複数のロボットについて、稼働場所が日本全国の様々な場所であったり、海外の様々な場所であったり、通信設備についても高速ＬＡＮを採用している施設もあれば、低速のＬＡＮにしか対応していない施設もあり得る。さらに、複数のＵＩ端末についても、日本全国の様々な場所又は海外の様々な場所に配置されることが想定され、通信環境は一律ではない。そこで、本発明においては、支援要請の対象であるタスク情報に関連付けて、支援が必要なタスクについて許容できる時間又は緊急度を含む遅延許容情報を設定し、ロボットとＵＩ端末との間の総予測通信遅延時間を推定して、遅延許容情報と、総予測通信遅延時間とを用いて担当ＵＩ端末を選択するものである。担当ＵＩ端末のオペレータは、ロボットからのタスク情報に応じた支援作業をＵＩ端末に入力し、入力された支援作業情報はネットワークを介してロボットに提供される。

【0024】

タスク情報は、ロボットが実行するタスクに関する情報であり、タスクの内容を特定するタスク種別を含み、タスク種別に関連付けられたタスク識別情報（以下、識別情報を「ＩＤ」と記載することもある）を含む。例えば、タスクＩＤ：１－１に関連付けられたタスク種別が「自律走行失敗からの復帰」であった場合、ロボットから支援管理サーバにタスク情報としてタスクＩＤを送信して支援管理サーバにおいてタスク情報データベース（以下、データベースを「ＤＢ」と略すこともある）によってタスク種別を特定してもよいし、ロボットから支援管理サーバにタスク情報としてタスク種別を送信してもよい。さらに、タスク情報に関連付けてロボットの稼働場所情報（場所ＩＤ）を含めてもよく、「工場Ａでの搬送における自律走行失敗からの復帰」のようにタスク種別を細分化してもよい。この場合、例えば、ロボットから支援管理サーバに場所ＩＤを送信してもよいし、ロボットＩＤを送信して支援管理サーバにおいてロボット情報ＤＢから場所ＩＤを特定してもよいし、支援要請の通信情報から場所ＩＤを特定してもよい。

【0025】

遅延許容情報は、タスク情報に関連付けられており、支援対象のタスクの緊急度やリアルタイム性によって決まり、例えば、オペレータが支援作業を入力してからロボットに届くまでの許容遅延度、ロボットが支援要請してから支援を受けて実際にタスクを実行するまでの許容待ち時間を含む。許容遅延度は通信回線による遅延だけではなく、各ロボットにおける処理能力による遅延、担当ＵＩ端末の処理能力等による遅延を含めてもよい。ここで、ロボットが遅延許容情報を保持している場合、自己の処理能力による遅延は把握できるが、担当ＵＩ端末は特定されていないため、例えば、ＵＩ端末の処理能力による遅延の平均等を用いてもよい。支援管理サーバが遅延許容情報を取得する際には、各ＵＩ端末の処理能力による遅延も把握できる。さらに、遅延許容情報は、支援要請する際のロボットの現状に応じて変更してもよい。例えば、自律走行失敗からの復帰において、通常、遅延許容度は緩く、許容待ち時間も長いが、近くに他の搬送ロボットが存在する場合は、例えば、他の搬送ロボットとの衝突を回避するために遅延許容度を厳しくしたり、他の搬送ロボットの進路を妨害しないように許容待ち時間を短くしたりしてもよい。遅延許容情報は、例えば、１０秒、１分、５分、１０分、１時間、１日等の具体的な時間であってもよいし、緊急度の大小を多段階（例えば１～５）で定性的に評価してものであってもよい。例えば、緊急度の高いタスクとしては、「カメラ画像を見て非常停止ボタンを押すかどうかの判断をしなければならない」場合等であり、リアルタイム性が要求されるタスクとしては、「ロボットからの動画を見ながらロボットの移動を操縦」、「動画を見ながらロボットのカメラの向きの調整」等である。

【0026】

総予測通信遅延時間は、ロボットとＵＩ端末との間の通信が遅延する時間に関する予測であり、支援管理サーバの通信状況推定手段によって推定される。通信状況推定手段は、各ロボットと各ＵＩ端末間、各ロボットと支援管理サーバ間、又は支援管理サーバと各ＵＩ端末との間の過去の通信記録から学習した分類器等のモデルを利用して総予測通信遅延時間を推定してもよいし、実際にデータを送受信して往復時間をソフトウェア（例えばｐｉｎｇ）で測定して総予測通信遅延時間を推定してもよい。また、総予測通信遅延時間は、ロボットとＵＩ端末間を直接通信した場合でもよいし、支援管理サーバを介在させてもよい。例えば、支援管理サーバとロボットとの間のロボット側予測通信遅延時間と支援管理サーバとＵＩ側予測通信遅延時間との合計でもよいし、ロボットからＵＩ端末又はＵＩ端末からロボットへの過去の通信状態から推定してもよい。

【0027】

図１は、本発明のロボット支援システムにおいて、支援管理サーバが、担当ＵＩ端末を選択するまでのフローチャートの一例である。本発明のロボットは、一つ又は複数の作業を実行可能な制御手段により動作可能であり、必要に応じてロボットは支援管理サーバに支援を要請する。または、支援管理サーバからロボットに対して支援作業開始を通知する。図１のＳ１において、支援管理サーバは、ロボットからタスク情報を取得する。取得する際にロボットを特定するロボット識別情報を併せてロボットから取得してもよい。Ｓ２において、支援管理サーバは、タスク情報に関連付けられた遅延許容情報を取得する。遅延許容情報は、支援が必要な作業について許容できる遅延許容度（緊急度）又は許容待ち時間を含む情報であり、タスク情報と併せてロボットから取得してもよいし、支援管理サーバの記憶手段又は他の記憶サーバ等からタスク情報と関連付けられた遅延許容情報を取得してもよい。Ｓ３において、支援管理サーバは、支援を要請したロボットとＵＩ端末の一つとの間の総予測通信遅延時間を推定する。Ｓ４において、総予測通信遅延時間が遅延許容情報の条件を満たすかどうか判断し、満たせばＳ５において、そのＵＩ端末を担当ＵＩ端末として選択する。Ｓ４において、条件を満たさない場合は、支援管理サーバは、Ｓ３に戻り、別のＵＩ端末について、総予測通信遅延時間を推定し、Ｓ４において、遅延許容情報の条件を満たすかどうか判断する。なお、Ｓ１において、ロボットからタスク情報だけではなく、遅延許容情報も取得した場合は、Ｓ２は不要となる。また、Ｓ３において予め複数のＵＩ端末の総予測通信遅延時間を推定しておけば、Ｓ４においてあるＵＩ端末の総予測通信遅延時間が条件を満たさなかった場合に、Ｓ３に戻らずに別のＵＩ端末の総予測通信遅延時間について判断してもよい。

【0028】

図２は、本発明のロボット支援システム１を実現するハードウェアの一例であり、図３及び図４は、本発明を実現するためのロボット支援システム１に必要な構成要素、データ構造のブロック図の一例である。本実施形態におけるロボット支援システム１は、支援管理サーバ２がネットワーク３を介して、複数のユーザインターフェース端末４１、４２、及び異なる作業を実行する種類の異なる複数のロボット５１、５２、５２と接続されている。支援システム１は、必要に応じてネットワーク３を介して接続可能な記憶サーバ６を含んでいてもよい。複数のロボット５１、５２、５２は、例えば、指示を受け付ける受付ロボット５１、指示された対象物を選択して把持することができるアームロボット５２、自己位置を推定しつつ目的地まで自律して移動できる自律式の搬送ロボット５３を含む。本実施形態のロボット支援システム１は、受付ロボット５１が指示対象物の選定ができない場合、アームロボット５２がピッキング対象物を判別できない場合、搬送ロボット５３が自己位置を喪失して復帰できない場合等に、ネットワーク３を介してＵＩ端末４１、４２と接続してオペレータのサポートによって作業を実施する。例えば、オペレータは、支援作業として、受付ロボット５１に対する対象物選定の指示や客との会話、アームロボット５２に対するピッキング対象物の指示や操作、搬送ロボット５３に対する暫定目的地の指示や移動操作等を行う。受付ロボット５１、アームロボット５２、搬送ロボット５３は、自律処理できない場合（例えば異常時又は人の判断が必要な処理時）に、支援管理サーバ２に支援要請を行って、タスク情報を提供する。支援管理サーバ２は、受付ロボット５１、アームロボット５２、搬送ロボット５３からのタスク情報に関連付けられた遅延許容情報を取得し、タスク情報を取得したロボットと各ＵＩ端末との間の総予測通信遅延時間を推定し、遅延許容情報と総予測通信遅延時間とを用いて、担当ＵＩ端末を選択し、必要な情報を担当ＵＩ端末に提供する。担当ＵＩ端末のオペレータは、要請を求められた作業について、受付ロボット５１、アームロボット５２、搬送ロボット５３に対して、適切な指示を与えたり、操作したりする。図２において、各要素を連結する線は情報を相互に又は一方に提供可能に接続されていることを意味し、両者が同一機器内部に実装されて内部バスによって接続されている場合も、別々の機器に実装されて有線又は無線のネットワークによって接続されている場合も含む。

【0029】

支援管理サーバ２は、図３に示すように、担当ＵＩ選択手段２１、通信状況推定手段２２、及び許容度取得手段２３を含んでいる。図３においては、各情報については、記憶サーバ６に蓄積されており、記憶サーバ６は、ロボット情報データベース（ＤＢ）６１、タスク情報データベース（ＤＢ）６２及びＵＩ端末情報データベース（ＤＢ）６３を含んでいる。ロボット情報ＤＢ６１は、ロボットに関する情報、例えば各ロボットを特定するロボット情報と、ロボット情報に関連付けられた各種情報とを含むデータベースであり、図３ではロボット識別情報（識別情報を「ＩＤ」と記載することもある）６１１、ロボット種別情報６１２、ロボット稼働場所情報６１３、ロボット側予測通信遅延時間６１４を含んでいる。タスク情報ＤＢ６２は、各タスクに関する情報、例えばタスクの内容を特定するタスク情報と、タスク情報に関連付けられた遅延許容情報とを含むデータベースであり、図３では、タスク識別情報（ＩＤ）６２１、タスク種別情報６２２、遅延許容度６２３、許容待ち時間６２４、タスク中待ち時間６２５、処理予測時間６２６を含んでいる。ＵＩ端末情報ＤＢ２６は、ＵＩ端末に関する情報、例えば各ＵＩ端末及び／又は各オペレータを特定する情報と、それらに関連付けられた情報とを含むデータベースであり、図３では、端末ＩＤ６３１、オペレータ情報６３２、ＵＩ側予測通信遅延時間６３３を含んでいる。これらの情報は、必要に応じて支援管理サーバ２がネットワーク３を介して記憶サーバ６に接続して取得することができるように構成されているが、記憶サーバ６ではなく、支援管理サーバ２の記憶手段に記憶してもよい。なお、記憶サーバ６は、支援管理サーバ２と一緒に設けられてもよいし、各ＵＩ端末４１，４２に設けられていてもよいし、別途設けられていてもよい。支援管理サーバ２は、ロボットからのオペレータ支援要請に対し、支援作業を行う担当オペレータを選択し、担当オペレータに対し支援作業に必要な情報（例えば、ロボット識別情報、タスク情報等）を提供する。なお、支援管理サーバ２は、図示しないが制御手段やネットワークと通信するための通信手段を含んでいる。

【0030】

担当ＵＩ選択手段２１は、ロボットからの支援要請に対して担当ＵＩ端末を選択する手段であり、担当ＵＩ選択プログラムを実行することによって実現され、例えば、支援管理サーバ２のＣＰＵ（Central Processing Unit）及び作業用メモリなどによって、或いは集積回路（Integrated Circuit）によって実現される。担当ＵＩ選択手段２１は、ロボットから提供されたタスク情報に関連付けられた遅延許容情報と、ロボットとユーザインターフェース端末との間の総予測通信遅延時間とを用いて、担当ＵＩ端末を選択してもよい。また、担当ＵＩ選択手段２１は、ロボットから提供されたタスク情報に関連付けられた遅延許容情報と、タスク情報に関連付けられたタスク中待ち時間、処理予測時間及び／又はユーザ処理時間を用いて、担当ＵＩ端末を選択してもよい。さらに、担当ＵＩ選択手段２１は、ロボットから提供されたタスク情報に関連付けられた遅延許容情報と、総予測通信遅延時間とに加えて、タスク中待ち時間、処理予測時間及び／又はユーザ処理時間とを用いて、担当ＵＩ端末を選択してもよい。例えば、担当ＵＩ選択手段２１は、総予測通信遅延時間、処理予測時間又はユーザ処理時間が遅延許容情報の範囲内になるＵＩ端末を担当ＵＩ端末に選択してもよいし、総予測通信遅延時間と処理予測時間又はユーザ処理時間との合計が遅延許容情報の範囲内になるＵＩ端末を担当ＵＩ端末に選択してもよいし、処理予測時間又はユーザ処理時間がタスク中待ち時間内に処理可能なＵＩ端末を担当ＵＩ端末に選択してもよい。

【0031】

さらに、担当ＵＩ選択手段２１は、一つ又は複数のロボットから提供された複数のタスク情報について、各タスク情報に関連付けられた遅延許容情報を取得し、当該タスク情報を提供したロボットと複数のＵＩ端末との間の総予測通信遅延時間又はＵＩ側予測通信遅延時間を取得し、全てのタスク情報において、総予測通信遅延時間又はＵＩ側予測通信遅延時間が遅延許容情報の範囲内となるように担当ＵＩ端末を選択してもよい（図５）。また、担当ＵＩ選択手段２１は、順番に提供された複数のタスク情報について、タスク情報に関連付けられた処理予測時間又はユーザ処理時間を取得し、処理予測時間又はユーザ処理時間を用いて担当ＵＩ端末を選択してもよい（図６）。さらに、担当ＵＩ選択手段２１は、タスク情報に関連付けられたタスク中待ち時間を用いて、当該タスク情報に対する担当ＵＩ端末を別のタスク情報に対する担当ＵＩ端末に選択してもよい（図７）。

【0032】

通信状況推定手段２２は、ロボットとＵＩ端末との間の総予測通信遅延時間を推定する手段であり、通信状況推定プログラムを実行することによって実現可能であり、例えば、支援管理サーバ２のＣＰＵ（Central Processing Unit）及び作業用メモリなどによって、或いは集積回路（Integrated Circuit）によって実現可能である。通信状況推定手段２２は、各ロボットと各ＵＩ端末間、各ロボットと支援管理サーバ間、又は支援管理サーバと各ＵＩ端末との間の過去の通信記録から学習した分類器等のモデルを利用して総予測通信遅延時間を推定してもよい。また、通信状況推定手段２２は、各ロボットと各ＵＩ端末間、各ロボットと支援管理サーバ間、又は支援管理サーバと各ＵＩ端末との間において実際にデータ（例えばロボットＩＤ又は端末ＩＤ等）を送受信して通信時間をソフトウェア（例えばｐｉｎｇ）で測定して総予測通信遅延時間を推定してもよい。総予測通信遅延時間は、ロボットとＵＩ端末間を直接通信した場合でもよいし、支援管理サーバを介在させてもよい。さらに、通信状況推定手段２２は、記憶サーバ６のロボット情報ＤＢ６１及びＵＩ端末ＤＢ６３にアクセスして支援管理サーバとロボットとの間のロボット側予測通信遅延時間と、支援管理サーバとＵＩ端末との間のＵＩ側予測通信遅延時間とを取得し、それらを組み合わせて総予測通信遅延時間を推定してもよい。総予測通信遅延時間は、通信路における遅延を含み、さらに、各ロボットの処理能力に応じた遅延、ＵＩ端末の処理能力に応じた遅延を含んでもよい。さらに、総予測通信遅延時間は、このようなハードウェアに応じた遅延だけではなく、タスク情報の対象となる作業に応じて、変動させてもよい。例えば、ＵＩ端末における支援作業にロボットからのリアルタイムの動画情報が必要となる場合は、データの送受信量が多くなり、通信回線への負担も大きくなるため、データ通信量の少ない作業に比べて、総予測通信遅延時間を増加させてもよい。この場合、例えば、通信状況推定手段２２は、タスク情報に応じて重み付け係数を取得し、ハードウェアに応じた予測通信遅延時間に重み付け係数を乗じて総予測通信遅延時間を推定してもよい。予測又は測定した総予測通信遅延時間、ロボット側予測通信遅延時間又はＵＩ側予測通信遅延時間を各データベースに蓄積することが好ましい。

【0033】

許容度取得手段２３は、タスク情報に関連付けられた遅延許容情報を取得する手段であり、許容度取得プログラムを実行することによって実現可能であり、例えば、支援管理サーバ２のＣＰＵ（Central Processing Unit）及び作業用メモリなどによって、或いは集積回路（Integrated Circuit）によって実現可能である。図３においては、記憶サーバ６のタスク情報ＤＢ６２にアクセスして、ロボットから取得したタスク情報に関連付けられた遅延許容情報を取得する。遅延許容情報は、タスク情報に関連付けられており、支援対象の作業が許容できる遅延許容度６２３又は許容待ち時間６２４を含んでいる。遅延許容情報は、ロボットの記憶媒体に記憶されており、タスク情報と併せて支援管理サーバ２に提供されて取得してもよいし、支援管理サーバ２の記憶媒体に記憶されており、タスク情報から検索して取得してもよいし、記憶サーバ６に記憶して、必要に応じて支援管理サーバ２がネットワーク３を介して接続して取得するように構成してもよい。

【0034】

ロボット情報ＤＢ６１は、ロボットに関する情報（ロボット情報）のデータベースであり、ロボット識別情報６１１と関連付けて、当該ロボットに関するロボット種別情報６１２、稼働場所情報６１３、ロボット側予測通信遅延時間６１４等が記録されている。さらに各ロボットが提供可能なタスク情報（例えばタスクＩＤ等）を関連付けてもよい。ロボット識別情報６１１は、各ロボットに一対一で対応するロボットを一意に識別する情報であり、例えば、製造番号や整理番号である。ロボット種別情報６１２は、ロボットの種類を特定する情報であり、例えば、「受付ロボット」、「アームロボット」、「搬送ロボット」というロボットの目的や用途による抽象的な大分類でもよいが、より具体的な分類とすることが好ましく、例えば、ロボットが具備する機能、性能、装備としてもよいし、既製品のロボットであれば製造メーカ、モデル名、型番等としてもよいし、注文品のロボットであれば製造メーカ、稼働場所、使用設備等としてもよい。稼働場所情報６１３は、ロボットが稼働している場所、施設等に関する情報である。稼働場所情報６１３としては、各ロボットが動作している工場や倉庫のＩＤ、工場や倉庫内における接続中のローカルエリアネットワーク（ＬＡＮ）のＩＤ、工場や倉庫のある国、地域のＩＤなどを含む。ロボット側予測通信遅延時間６１４は、支援管理サーバ２と各ロボットとの間の通信遅延、及び支援が必要なタスク処理中の遅延を含む時間であり、通信状況推定手段２２又はその他の手段によって予測又は測定した結果が記録される。

【0035】

タスク情報ＤＢ６２は、各タスクに関する情報が蓄積されたデータベースであり、タスク識別情報（ＩＤ）６２１、タスク種別情報６２２、遅延許容度６２３、許容待ち時間６２４、タスク中待ち時間６２５、処理予測時間６２６を含んでいる。さらに各ロボットの種別や稼働場所もタスク情報の一部に含まれていてもよい。タスクＩＤ６２１は、各タスクに一対一で対応する情報であり、例えば、複数桁の数字、文字、記号の組み合わせでもよい。タスク種別情報６２２は、具体的なタスクの内容を示す情報であり、例えば、タスクの種類（例えば、自律走行失敗からの復帰、狭路走行、経路変更等）だけでもよいし、タスクの種類に加えて、ロボットの具体的な種別や稼働場所等を含んでいてもよい（例えば、型番○○の狭路走行、工場Ａにおける経路変更等）。遅延許容度６２３は、当該タスクにおけるオペレータの指示の緊急性やリアルタイム性に関する要素であり、例えば、緊急性を１～５の５段階で分類してもよいし、緊急性が高い、普通、低いと３段階で分類してもよいし、緊急、急ぎ、やや急ぎ、通常、やや許容、許容等のように分類してもよい。許容待ち時間６２４は、当該タスクで許容できる待ち時間であり、オペレータからの指示がいつまでに受信すればよいのかの目安である。緊急性が高いタスクは、許容待ち時間は短く、緊急性が低いタスクは許容待ち時間は短い。タスク中待ち時間６２５は、タスクを処理している間に生じる待ち時間の目安であり、例えば、オペレータがロボットに対してある動作を入力した場合に、ロボットが動作を完了するまでの待ち時間等である。タスク中待ち時間として、例えば、経路を指定して走行させた時、経路の長さに応じた待ち時間が発生する。この場合、タスク中待ち時間は、固定値ではなく、オペレータの指示によって可変の数値であり、例えば、経路長（ｍ）×速さ（秒／ｍ）のような数式で特定してもよい。処理予測時間６２６は、オペレータがタスク情報の支援作業を処理するのに要する概算の時間であり、例えば、全オペレータの過去の平均値、中央値でもよい。タスク中待ち時間６２５は、動作が完了するまでオペレータの手が空いている状態であるため、担当ＵＩ選択手段２１は、タスク中待ち時間に別のタスクの支援作業を処理できるように、タスク中待ち時間の長いタスクの担当ＵＩ端末に対して、タスク中待ち時間よりも処理予測時間６２６が短い別のタスクの担当に選択してもよい。

【0036】

ＵＩ端末情報ＤＢ２６は、各ＵＩ端末及び／又は各オペレータに関する情報が蓄積されたデータベースであり、端末ＩＤ６３１、オペレータ情報６３２、ＵＩ側予測通信遅延時間６３３を含んでいる。端末ＩＤ６３１は、各ＵＩ端末に一対一で対応する情報であり、例えば、各ＵＩ端末の製造番号や整理番号である。さらに、端末ＩＤ自体に又は関連付けてＵＩ端末が存在している場所、国、地域情報、ＵＩ端末の機種情報などを含んでいてもよい。オペレータ情報６３２は、各オペレータに関する情報全般であり、例えばオペレータＩＤ、氏名、処理可能なタスク、各タスクの熟練度、使用言語等である。ＵＩ側予測通信遅延時間６３３は、支援管理サーバ２と各ＵＩ端末との間の通信遅延、及び支援が必要なタスク処理中の遅延を含む時間であり、通信状況推定手段２２又はその他の手段によって予測又は測定した結果が記録される。このタスク処理中の遅延には、当該ＵＩ端末を使用するオペレータのタスク処理の習熟度が加味されてもよい。

【0037】

ユーザインターフェース端末４１、４２は、図４に示すように、出力手段４３、入力手段４４、記憶手段４５を含んでおり、記憶手段４５には、端末ＩＤ４５１、オペレータ情報４５２、ユーザ処理時間４５３等が記憶されている。ＵＩ端末には、図示していないが、ネットワークと通信するための通信手段等が含まれており、支援管理サーバ２に対して、端末ＩＤ４５１、オペレータ情報４５２、ユーザ処理時間４５３等を送信可能とされている。１台のＵＩ端末に対し複数人のオペレータが使用してもよいし、１台のＵＩ端末に対し１人のオペレータの専用としてもよいし、１人のオペレータが複数台のＵＩ端末を同時に又は時と場合に応じて使用してもよい。

【0038】

出力手段４３は、様々な情報を表示する手段であり、例えば、液晶ディスプレイ（ＬＣＤ）、有機ＥＬディスプレイ、プロジェクタ、スピーカ等を含む。出力手段４３としてタッチパネル式のディスプレイを使用すれば、入力手段４４としても使用できる。また、複数のロボット５１、５２、５３に対応して、複数の出力手段４３を設けてもよいし、一つの出力手段４３に複数のロボット５１、５２、５３の情報を同時に又は順次表示するようにしてもよい。出力手段４３には、例えば、ロボットから取得したロボットの周囲の環境情報、音声情報及び／又は画像情報や、ロボットの稼働場所の地図情報が表示されてもよいし、入力手段４４で入力した内容やロボットへの操作内容が表示されてもよい。

【0039】

入力手段４４は、ロボットからの支援要請に対する支援作業を入力するものであり、例えば、キーボード、ポインティングデバイス（マウス、タッチパッド等）、タッチパネル（タッチスクリーンを含む）、コントローラ、マイク等を含む。例えば、搬送ロボットを所定の位置まで操作する場合には、例えば、キーボードで目的地の座標を入力してもよいし、ポインティングデバイスやタッチパネルで環境情報又は画像情報上の点を選択することにより、選択した座標を暫定目的地に選択してもよい。また、例えば、コントローラで搬送ロボットの前進、後退等を操作してもよい。

【0040】

記憶手段４５には、ＵＩ端末に接続されたメモリ、ＨＤＤなどの記録媒体であり、端末ＩＤ４５１、オペレータ情報４５２、ユーザ処理時間４５３等が記憶されている。端末ＩＤ４５１は、その端末に一対一で対応する情報であり、例えば、そのＵＩ端末の製造番号や整理番号である。オペレータ情報４５２は、その端末を操作するオペレータに関する情報である。ユーザ処理時間４５３は、各タスクに関連付けられたオペレータによる支援作業の時間に関する情報である。ユーザ処理時間４５３は、平均的なオペレータの処理時間でもよいが、当該ＵＩ端末を使用するオペレータの処理時間であることが好ましい。オペレータによって得意な支援作業や、苦手な支援作業があり、特異な支援作業であれば平均よりも短い時間で処理できる場合もあり、逆に苦手な支援作業であれば平均よりも長い時間が必要となる場合もある。担当ＵＩ端末を選択する際に、ユーザ処理時間４５３を用いることによって、使用するオペレータの技量を考慮できる。

【0041】

ロボット５１、５２、５３は、例えば、工場や倉庫で部品や商品を運搬する搬送ロボット、工場で設備の点検、メータの検針などを行う設備点検ロボット、工場でライン上を流れている製品のピッキング、ばら積みされた商品のピッキングを行うアームロボット、工場で製品を撮影し、異常がないか検査をする外観検査ロボット、商業施設などの利用者に対して案内を行う案内ロボットなどを含む。このロボット５１、５２、５３は、図４に示すように、自律制御手段５４、支援要請手段５５、記憶手段５６を含み、さらにエラー検出手段５７、環境情報取得手段５８、位置情報検出手段５９等を含んでいてもよい。記憶手段５６には、ロボット情報５６１、タスク情報５６２、動作状況情報５６３を含み、動作状況情報５６２には、エラー情報５６４、環境情報５６５、位置情報５６６等を含んでいてもよい。

【0042】

自律制御手段５４は、ロボットが動作するための制御手段であり、ＣＰＵ（Central Processing Unit）及び作業用メモリなどによって、或いは集積回路（Integrated Circuit）によって実現される。例えば、搬送ロボットの場合は、要求待ち、積み込み場所への移動、待ち、自律搬送、積み下ろし待機、復帰移動などを行うための動作がプログラムされている。設備点検ロボットの場合は、点検箇所までの自律移動、メータ等の数値情報の自動収集などの動作がプログラムされている。アームロボットの場合は、要求待ち、対象物のピックアップ、関節機能による対象物の把持、把持の解放、などの動作がプログラムされている。外観検査ロボットの場合は、製造現場のカメラで製品を撮影し、異常がないかを検査するなどの動作がプログラムされている。施設案内ロボットの場合は、顧客等の要望があるまで待機、顧客の要望を得るために移動、巡回、顧客の要望を受け付けて認識、顧客の要望を他のロボットに転送などの動作がプログラムされている。

【0043】

支援要請手段５５は、自律処理できない場合（例えば異常時又は人の判断が必要な処理時）に、支援管理サーバ２に支援要請を行う手段であり、少なくとも支援を必要とするタスクのタスク情報を支援管理サーバ２に提供する。さらに、支援要請手段５５は、必要に応じて、ロボット情報５６１や、動作状況情報５６３（エラー情報５６４、環境情報５６５、位置情報５６６等）も支援管理サーバ２又は担当ＵＩ端末に提供してもよい。支援要請手段５５は、実行するタスクに人の判断が必要な場合や、エラー検出手段５７でエラーを検出した場合に支援要請を行う。例えば、搬送ロボットであれば、自己位置を喪失した場合、設備点検ロボットであれば、設備のひびなどを発見した場合、アームロボットであれば、ピッキングする対象物が判断できない場合、外観検査ロボットであれば、はんだ付け部の正常/異常を判断できない場合、施設案内ロボットであれば、受付内容が認識できない場合に支援要請を行ってもよい。

【0044】

記憶手段５６は、ロボット内に設けられたメモリ、ＨＤＤなどの記録媒体であり、必要な情報、プログラム等が記録されており、また、逐次取得した情報が記録される。ロボット情報５６１は、ロボットを特定する情報であり、例えば、ロボット識別情報、ロボット種別情報、稼働場所情報等を含む。タスク情報５６２は、当該ロボットが実施可能なタスクの内容を特定する情報であり、例えば、当該ロボットが実施可能なタスクのタスクＩＤ、タスク種別、稼働場所情報等を含み、さらに遅延許容情報を含んでいてもよい。タスク種別としては、例えば、待ち状態、受付け中、対象物の選定中、対象物の把持中、搬送中、積み下ろし等である。動作状況情報５６３は、ロボットの動作状況に関する情報であり、例えば、エラー検出手段５７で検出したエラー情報５６４、環境情報取得手段５８で取得した周囲の環境情報５６５、位置情報検出手段５９で検出した位置情報５６６等を含んでいてもよい。

【0045】

エラー検出手段５７は、ロボットに生じた障害や異常を検出するものであり、障害や異常が発生した際に予め決められた障害や異常の種類に分類してエラー情報５６４を取得する。エラー情報５６４は、障害や異常の種類を特定する情報（エラーコードを含む）でもよいし、障害や異常の内容（例えば、自己位置ロスト等）を含む情報でもよい。

【0046】

環境情報取得手段５８は、ロボットの周囲の環境情報５６５を取得するものであり、ロボットの周囲の障害物の存在と位置（相対的な位置又は絶対的な位置）を検出する手段、周囲の画像を取得する手段、又は音声を取得する手段等を含む。環境情報取得手段５８として、例えば、レーザ光を使用したＬｉＤＡＲ（Light Detection and Ranging又はLaser Imaging Detection and Ranging）や測域センサ、複数のカメラを使用したステレオカメラ、パターンプロジェクションカメラ、電波（ミリ波）を使用したレーダ、磁気センサ、２次元画像を取得するカメラ（ＣＣＤカメラ、ＣＭＯＳセンサ、赤外線カメラ）、音声を取得する音声取得手段などを使用することができる。

【0047】

位置情報検出手段５９は、地図情報におけるロボット５１～５３の位置を推定したり、ロボットの関節、アーム等の位置を検出したりする手段であり、それらの位置情報５６６を取得する。自己位置を推定する場合は、例えば、位置推定プログラムを実行することによって実現され、例えば、ＣＰＵ（Central Processing Unit）及び作業用メモリなどによって、或いは集積回路（Integrated Circuit）によって実現される。位置情報検出手段５９としては、地図情報における移動体の位置が特定できればよく、特に手段を問うものではないが環境情報取得手段５８で取得した環境情報（周囲の障害物の配置）５６５と、予め用意された地図情報とを照合して、照合結果に基づきロボットの位置を算出してもよい。他の位置情報推定手段５９としては、ＧＰＳで特定した座標を地図情報の座標に変換したり、通信アンテナや基地局で特定した座標を地図情報の座標に変換したり、周囲の壁、天井、床に位置を示す記号を表記してそれを画像認識し、地図情報と対応させることで特定したりしてもよい。また、関節、アーム等の位置を検出する場合は、例えば、関節やアームを駆動するアクチュエータによる変位量から位置を検出してもよいし、ロボット又は周囲の壁、天井、床等に設置されたカメラやセンサによって駆動後のアームの状態を検知して位置を検出してもよい。なお、位置情報検出手段５９は、ロボット５１～５３ではなく、支援管理サーバ２に設けられてもよい。

【0048】

図５は、本発明のロボット支援システムにおいて、支援管理サーバが複数の支援要請により複数のタスク情報を取得した場合のフローチャートの一例である。図５のＳ５１において、支援管理サーバは、一つ又は複数のロボットから提供された複数の支援要請により複数のタスク情報を取得する。なお、複数のタスク情報を同時に所得した場合だけではなく、所定期間内に順次取得した場合も含む。Ｓ５２において、支援管理サーバは、複数のタスク情報について、各タスク情報に関連付けられた遅延許容情報を取得することにより、複数のタスク情報に対応する複数の遅延許容情報を取得する。Ｓ５３において、支援管理サーバは、複数のタスク情報を提供した一つ又は複数のロボット（すなわち、一つ又は複数の支援要請したロボット）について、それぞれ複数のＵＩ端末と組み合わせて、複数の総予測通信遅延時間を推定し、各タスク情報に対して複数のＵＩ端末との組み合わせを取得する。または、Ｓ５３において、各タスク情報に対して総予測通信遅延時間ではなく、複数のＵＩ端末のＵＩ側予測通信遅延時間を取得してもよい。そして、支援管理サーバの担当ＵＩ選択手段は、Ｓ５４において、複数のタスク情報について、それぞれ複数のＵＩ端末の中らか一つのＵＩ端末を選択し、Ｓ５５において、複数のタスク情報の全てにおいて、選択したＵＩ端末との総予測通信遅延時間（又はＵＩ側予測通信遅延時間）が各タスク情報に関連付けられた遅延許容情報に適合するか否かを判断する。Ｓ５４において、複数のタスク情報について、それぞれ異なるＵＩ端末を選択することが好ましいが、タスクの内容によっては、二つ以上のタスク情報を一つのＵＩ端末に選択してもよい。複数のタスク情報の全てにおいて適合した場合（Ｓ５５のＹｅｓ）は、選択したＵＩ端末を担当ＵＩ端末に選択する。適合しなかった場合（Ｓ５５のＮｏ）は、Ｓ５４に戻り、再度別のＵＩ端末を選択する。本フローチャートによれば、支援が必要な全タスクについて、遅延許容情報を満足するＵＩ端末を割り当てることが可能となる。例えば、ロボット側予測通信遅延時間が速いロボットと遅いロボットの２か所のロボットから中程度の緊急度の支援要請があった場合、ＵＩ側予測通信遅延時間が速いＵＩ端末と遅いＵＩ端末について、ロボット側予測通信遅延時間が速いロボットに対してＵＩ側予測通信遅延時間が速いＵＩ端末を選択すれば、中程度の緊急度の支援要請に適合するが、ロボット側予測通信遅延時間が遅いロボットについては、ＵＩ側予測通信遅延時間が遅いＵＩ端末が選択されるため、中程度の緊急度の支援要請に適合しなくなる。これに対し、本フローチャートであれば、ロボット側予測通信遅延時間が速いロボットに対してＵＩ側予測通信遅延時間が遅いＵＩ端末を選択し、ロボット側予測通信遅延時間が遅いロボットに対してＵＩ側予測通信遅延時間が速いＵＩ端末を選択することにより、両方の遅延許容情報に適合する場合もありえる。なお、Ｓ５４及びＳ５５において、全ての組み合わせを試しても、全てのタスク情報について適合しなかった場合は、タスク情報の優先順位や受付順で適合する担当ＵＩ端末を選択してもよい。

【0049】

図６は、本発明のロボット支援システムにおいて、支援管理サーバが複数の支援要請により複数のタスク情報を取得した場合のフローチャートの他の一例である。図６のＳ６１において、支援管理サーバは、一つ又は複数のロボットから提供された複数の支援要請により複数のタスク情報を取得する。なお、複数のタスク情報を同時に所得した場合だけではなく、所定期間内に順次取得した場合も含む。Ｓ６２において、支援管理サーバは、複数のタスク情報について、各タスク情報に関連付けられた遅延許容情報を取得することにより、複数のタスク情報に対応する複数の遅延許容情報（特に許容待ち時間を含むことが好ましい）を取得する。Ｓ６３において、支援管理サーバは、複数のタスク情報について、各タスク情報に関連付けられた処理予測時間又はユーザ処理時間を取得する。処理予測時間は、例えばタスク情報ＤＢから取得してもよいし、ロボットの記憶手段に記憶されたタスク情報から取得してもよい。ユーザ処理時間は、ＵＩ端末から取得してもよいし、ＵＩ端末情報ＤＢ６３のオペレータ情報６３２から取得してもよい。そして、支援管理サーバの担当ＵＩ選択手段は、Ｓ６４において、複数のタスク情報についてＵＩ端末に割り当てる仮の順番を設定し、Ｓ６５において、複数のタスク情報の全てにおいて、設定した順番で各タスク情報に関連付けられた遅延許容情報に適合するか否かを判断する。Ｓ６４において、仮の順番は、例えば、複数のタスク情報のうち処理予測時間又はユーザ処理時間が短い順に設定してもよいし、許容待ち時間が短い順に設定してもよい。複数のタスク情報の全てにおいて適合した場合（Ｓ６５のＹｅｓ）は、設定した順番でタスク情報の担当ＵＩ端末に選択する。適合しなかった場合（Ｓ６５のＮｏ）は、Ｓ６４に戻り、仮の順番として別の順番を設定する。本フローチャートによれば、支援が必要な全タスクについて、遅延許容情報を満足するようにＵＩ端末を割り当てることが可能となる。例えば、先に処理予測時間が短く、許容待ち時間が長い第１のタスクの支援要請があり、次に、処理予測時間が短く、許容待ち時間も短い第２のタスクの支援要請があった場合、支援要請の順番で一つのＵＩ端末に割り当てると、第１のタスクを処理するための時間によって、第２のタスクの許容待ち時間を越えてしまう可能性がある。しかし、本フローチャートによれば、後から届いた第２のタスクを先に割り当てることで、許容待ち時間が長く、処理予測時間が短い第１のタスクを後から処理しても、許容待ち時間内に処理できる場合がありえる。なお、速いタスクの例としては、外観検査ロボットの外観検査での正常／不良の判定などがあり、遅いタスクとしては、ロボットを移動させるための操縦などがある。

【0050】

図７は、本発明のロボット支援システムにおいて、担当ＵＩ端末でオペレーション中に発生する待ち時間を利用するためのフローチャートの一例である。図７のＳ７１において、支援管理サーバは、担当ＵＩ端末に発生したタスク中待ち時間を取得する。タスク中待ち時間は、担当ＵＩ端末が処理しているタスク情報に関連付けられており、タスク情報ＤＢから取得してもよいし、担当ＵＩ端末から取得してもよい。例えば、アームロボットに把持点を指示するタスクは、オペレータの指示入力は一瞬だが、アームロボットが動作完了まで動くのに時間がかかり、タスク中待ち時間が発生する。担当ＵＩ端末は、オペレータの指示をロボットに送信すると共に、指示を入力したことを支援管理サーバに通知し、支援管理サーバがタスク情報ＤＢからタスク中待ち時間を取得してもよいし、担当ＵＩ端末がタスク中待ち時間を支援管理サーバに通知してもよい。Ｓ７２において、支援管理サーバは、まだ担当ＵＩ端末が選択されていない待ちタスク情報の有無を判断し、待ちタスク情報が無い場合（Ｓ７２のＮｏ）は処理を終了する。待ちタスク情報がある場合（Ｓ７２のＹｅｓ）、支援管理サーバは、Ｓ７３において、待ちタスク情報に関連付けられた処理予測時間又はユーザ処理時間を取得し、Ｓ７４において、処理予測時間又はユーザ処理時間がタスク中待ち時間よりも短いか否かを判断する。Ｓ７４において、処理予測時間又はユーザ処理時間と総予測通信遅延時間との合計をタスク中待ち時間よりも短いか否か判断してもよい。処理予測時間又はユーザ処理時間が短い場合（Ｓ７４のＹｅｓ）は、タスク中待ち時間が発生しているＵＩ端末を待ちタスク情報の担当ＵＩ端末に選択する。長い場合（Ｓ７４のＮｏ）は処理を終了する。本フローチャートによれば、ある支援要請について支援作業中の担当ＵＩ端末に対して、作業中に発生したタスク中待ち時間を利用して別のタスク情報を割り込みで処理させることができる。

【0051】

以下の実施例において、各種のロボットについて、具体的なタスク情報、遅延許容情報等について説明するが、一実施形態における例示であり、本発明の内容を限定するものではない。実施例の遅延許容情報は、遅延許容度及び許容待ち時間を含んでいるが、いずれか一方でもよい。遅延許容度、許容待ち時間、タスク中待ち時間、処理予測時間については、実際の具体的なロボットの状況や支援作業の内容によっても異なるため、定性的に記載されているが、個別の状況において検証することにより平均値などで定量化（数値化）することも可能である。

【実施例0052】

［搬送ロボット］
搬送ロボットは、物又は人を搬送するロボットであり、例えば、工場や倉庫内で部品や商品等を運ぶ作業を実行する。搬送ロボットのタスク情報（タスクＩＤ：タスク種別）には、例えば、「１－１：自律走行失敗からの復帰」、「１－２：狭路走行」、「１－３：現場の指示による経路変更」等がある。さらに、搬送ロボットは、稼働場所に応じて地図情報、搬送対象等が異なるため、タスク情報に稼働場所を示す稼働場所情報（場所ＩＤ）を含めることが好ましく、タスク種別として稼働場所を含めて「工場Ａでの搬送における自律走行失敗からの復帰」のように細分化してもよい。場所ＩＤとしては、倉庫、工場等の施設毎に識別してよいし、各施設内のローカルネットワーク毎に識別してもよい。さらに、場所ＩＤを用いて担当ＵＩ端末を選択してもよいし、場所ＩＤから紐づけられた地図情報、搬送対象等を担当ＵＩ端末に提供してもよい。

【0053】

［タスクＩＤ１－１］
「自律走行失敗からの復帰」とは、通常は自律走行している搬送ロボットが、移動中、経路が塞がれる、自己位置が分からなくなる等の理由で自律走行に失敗した際に支援要請されるタスクである。オペレータは、支援作業として、目標地点や経由点を指定してもよいし、マップ上での正しい自己位置の指示を行ってもよいし、「狭路走行」と同様にロボットを直接操縦してもよい。オペレータは、例えば、ＵＩ端末のディスプレイ（出力手段）に地図情報やロボットからの環境情報を表示しつつ、ポインティングデバイス、十字キー、ジョイスティック等（入力手段）によって目的地等を指示する。また、担当ＵＩ端末のオペレータの能力値による係数（例えば、熟練者であれば１より小さい係数、平均者であれば１、初心者であれば１より大きい係数等）を乗じて算出してもよい。
・遅延許容度：操作にリアルタイム性が不要なため、比較的許容される（緊急度が低い）。
・許容待ち時間：ロボットの現場における周囲の状況にもよるが、数分（例えば、１分～９分）であれば許容される。
・タスク中待ち時間：支援作業内容によっても異なるが、例えば、経路を指定して走行させた時、経路の長さに応じた待ち時間が発生する。この場合、タスク中待ち時間は、固定値ではなく、オペレータの指示によって可変の数値となり、例えば、経路長（ｍ）×速さ（秒／ｍ）のような数式で算出するようにしてもよい。
・処理予測時間：支援作業内容、経路の長さによっても異なるが、過去の「自律走行失敗からの復帰」タスクの平均的な処理時間であってもよい。

【0054】

［タスクＩＤ１－２］
「狭路走行」とは、搬送ロボットの自律走行では困難な狭い通路や凹凸のある悪路を走行させる場合等、オペレータによって操作を要求する際に支援要請されるタスクである。オペレータは、例えば、ＵＩ端末のディスプレイ（出力手段）に地図情報やロボットからの環境情報を出力しつつ、ポインティングデバイス、十字キー、ジョイスティック等（入力手段）によってロボットの姿勢なども調整しながら操縦する。また、担当ＵＩ端末のオペレータの能力値による係数（例えば、熟練者であれば１より小さい係数、平均者であれば１、初心者であれば１より大きい係数等）を乗じて算出してもよい。
・遅延許容度：操作にリアルタイム性が必要であり、比較的厳しい（緊急度が高い）。
・許容待ち時間：ロボットの現場における周囲の状況にもよるが、数分（例えば、１分～９分）であれば許容される。遅延許容情報は周囲の状況に応じて変更してもよい。例えば、近くで他の搬送ロボットが走行しており、他の搬送ロボットの進路を妨害する可能性がある場合には、遅延許容度を厳しくし、許容待ち時間を短くしてもよい。
・タスク中待ち時間：基本的に発生しない。
・処理予測時間：実際にはばらつきがあるが、例えば平均的な時間（例えば５分）を設定してもよい。

【0055】

［タスクＩＤ１－３］
「現場の指示による経路変更」とは、搬送ロボットは通常は自律走行したり、予め設定した経路上を走行するが、搬送先が柔軟に変わる状況には対応できない場合に支援要請されるタスクである。オペレータは、例えば、現場と通話したり、現場の環境情報を取得したりして現場とコミュニケーションを取りながら、状況に合わせた新たな経路を指示する。実際の操作としては、例えば、ＵＩ端末のディスプレイ（出力手段）に表示された現場の地図情報上の目的地をクリック等で指示してもよい。
・遅延許容度：現場とのコミュニケーション等のリアルタイム性が求められるため、比較的厳しい（緊急度が高い）。
・許容待ち時間：現場とのコミュニケーションに即応答する必要があるため、数秒程度と短い。
・タスク中待ち時間：基本的には発生しない。
・処理予測時間：経路をクリックするだけなので、数秒～１分程度である。

【実施例0056】

［設備点検ロボット］
設備点検ロボットは、工場等の施設を巡回し、施設や稼働設備の点検（ひび、劣化等）、メータの検針等を行う。設備点検ロボットのタスク情報（タスクＩＤ：タスク種別）には、例えば、「２－１：自律走行失敗からの復帰」、「２－２：狭路走行」、「２－３：点検箇所のカメラ合わせ」、「２－４：点検」等がある。さらに、設備点検ロボットは、稼働場所に応じて地図情報、点検対象等が異なるため、タスク情報に稼働場所を示す稼働場所情報（場所ＩＤ）を含めることが好ましく、場所ＩＤとしては、倉庫、工場等の施設毎に識別してよいし、ロボットが担当する巡回ルート毎に識別してもよい。さらに、場所ＩＤを用いて担当ＵＩ端末を選択してもよいし、場所ＩＤから紐づけられた地図情報、点検対象等を担当ＵＩ端末に提供してもよい。タスクＩＤ２－１及び２－２は、基本的には搬送ロボットのタスクＩＤ１－１及び１－２と共通であるが、点検作業は搬送ロボットによる搬送作業よりもさらに緊急性が低いため、タスクＩＤ１－１及び１－２とよりも許容度は大きく、許容待ち時間も長い。

【0057】

［タスクＩＤ２－３］
「点検箇所のカメラ合わせ」とは、施設や稼働設備の点検、メータの検針等のため、点検箇所を高倍率ズームで撮影する際に、自己位置やカメラ向き調整の精度が足りず、自動で点検箇所を撮影するのが難しい場合に支援要請されるタスクである。オペレータは、支援作業として、設備点検ロボットの位置や向き及び／又は環境情報取得手段の一つであるカメラの向きを調整する。
・遅延許容度：調整にはリアルタイム性が必要となるため、許容度は低い。
・許容待ち時間：緊急性は低く、許容待ち時間は長めである。
・タスク中待ち時間：基本的に発生しない。
・処理予測時間：実際検証して決定すればよいが、例えば、調整だけであれば１～２分程度である。

【0058】

［タスクＩＤ２－４］
「点検」とは、設備点検ロボットが施設内を巡回し、点検箇所まで移動した後、ひびなどの点検、あるいはメータの検針などを実際にオペレータが見て判断する場合に支援要請されるタスクである。点検についても自動化は可能であるが、設備点検ロボットでは判別できないことがあり得る。タスクＩＤ２－３の「点検箇所のカメラ合わせ」と併せて又は連続して実施してもよい。オペレータは、例えば、ＵＩ端末のディスプレイ（出力手段）に表示された画像を適宜拡大、縮小して判断し、点検結果を入力手段で記録する。
・遅延許容度：画像を見て記録するだけであり、リアルタイム性の要求は低いので、許容度は大きい。
・許容待ち時間：緊急性は低いので長い。
・タスク中待ち時間：基本的に発生しない。
・処理予測時間：対象物や記録する項目の量に依存するが、例えば数分程度である。