JP2016533277A - ロボットシステムにおける障害応動、障害分離、及びグレースフル・デグラデーション - Google Patents

Abstract

ロボットシステムは、アーム、アームプロセッサ、アーム監視プロセッサ、及びシステム監視プロセッサを有する。各アームは、アームのモーターを制御するためのノードを含む。それぞれアームプロセッサを含む各ノードは、ノードに影響を及ぼす障害を検出し、障害を検出すると、ノードを安全な状態に置き、障害通知を伝達し、障害を診断してその障害を分類し、監視プロセッサにエラーメッセージを送る。アーム監視プロセッサは、アームに影響を及ぼす障害を検出し、また障害応動動作も実行することができる。システム監視プロセッサは、その分類に応じて、その障害をシステム障害又はローカル障害のいずれかとして処理する。システム障害の場合に、故障していないアームが安全な状態に配置されるように、障害通知が、故障していないアームのアームプロセッサに送られる。ローカル障害の場合に、機能低下動作オプションがユーザに提供され、障害が回復可能として分類される場合に、回復オプションがユーザに提供される。

Description

本発明は、概して、ロボットシステムに関し、具体的には、ロボットシステムにおける障害応動(fault reaction)、障害分離、及びグレースフル・デグラデーション(graceful
degradation)に関する。

ユーザ制御の１つ又は複数のロボットアームを有するロボットシステムが、多くの用途で使用されている。一例として、”Cooperative Minimally Invasive Telesurgical System”という標題の特許文献１を参照されたい。この文献は、参照することにより本明細書に組み込まれる。更なる例は、製造現場、建設現場、危険物処理、及び遠隔操作を用いたロボットシステムの他の用途において見受けられる。

それらロボットアームの動作中に故障や障害がロボットアームで発生することがあり、完全な制御が失われる。このような損失を回避するために、障害を容易に判定することができるように、三重の冗長性を提供するような耐障害性システムが用いられており、１つのコンポーネントに故障が発生した場合に、生き残ったコンポーネントが依然として機能を提供することができる。しかしながら、冗長コンポーネントを提供することは、システムのコストを増大させる。あるいはまた、予防保全技術を用いて、このような障害の発生を最小限にすることができる。しかしながら、予期しない障害が、依然として発生し得る。

障害又は故障がロボットシステムで検出された場合に、システム全体は、障害が修正されるまで、安全上の理由のためにオフ状態にされ得る。しかしながら、時には、ロボットシステムは、機能が低下した状態でも一次又は二次のタスクを達成するために依然として使用可能であり得る。この場合には、システムを、機能が低下した状態(degraded)で動作を継続可能にすることが有利となり得る。他の場合には、障害が永続的ではないことがあり得る。この場合には、障害をクリアにし、ロボットシステムの完全な使用を継続することが可能であり得る。

米国特許第７，８６５，２６６号

従って、本発明の１つ又は複数の態様の１つの目的は、故障を検出すると、システムを安全な状態に自動的に置くことを確実にする障害処理スキームを提供することである。
本発明の１つ又は複数の態様の別の目的は、クリアにすることができない障害を検出した後で、ロボットシステムのグレースフル・デグラデーションを促進する障害処理スキームを提供することである。

これらの及び更なる目的は、本発明の様々な態様によって達成される。簡潔に述べると、一態様は、複数のロボットアームを有するロボットシステムにおける障害応動、障害分離、及びグレースフル・デグラデーションのための方法である。この方法は、複数のロボットアームのうちの故障が発生したアームの障害を検出するステップと；故障が発生したアームを安全な状態に置くステップと；障害をシステム障害又はローカル障害として処理すべきかどうかを判定するステップと；障害をシステム障害として処理すべき場合のみ、複数のロボットアームのうちの故障していないアームを安全な状態に置くステップと；を含む。

別の態様は、複数のロボットアームと、複数のアームプロセッサと、監視プロセッサとを含むロボットシステムである。各アームプロセッサは、複数のロボットアームの対応する１つに動作可能に結合される。各ロボットアームは、ロボットアームの運動の自由度で作動させるための複数のモーターを有する。各ロボットアームは、ロボットアームの対応するモーターを制御するための１つ又は複数のノードを有する。各ノード及びアームプロセッサは、ノード又はアームプロセッサに影響を及ぼす障害の発生を検出し、障害の発生を検出すると、ノード又はアームプロセッサを安全な状態に置き、ノードを含む又はアームプロセッサに動作可能に結合された故障が発生したアームを介して障害通知を伝達し、障害を診断し、障害の情報を含むエラーメッセージを監視プロセッサに送るように構成される。各ノード及びアームプロセッサは、別のソースから障害通知を受信すると、ノード又はアームプロセッサを安全な状態に置くようにも構成される。監視プロセッサは、故障が発生したノード又はアームプロセッサからエラーメッセージを受信し、エラーメッセージ内の情報を使用することにより、検出した障害をシステム障害又はローカル障害として処理すべきかどうかを判定し、検出した障害をシステム障害として処理すべき場合のみ、複数のロボットアームのうちの故障していない全てのアームに対応するアームプロセッサに障害通知を送信するように構成される。

本発明の様々な態様の更なる目的、特徴及び利点は、添付図面と併せて解釈すべき以下の詳細な説明から明らかになるであろう。

複数のロボットアームを有するロボットシステムの斜視図である。 協調的に相互作用し、ロボットシステムにおける障害応動、障害分離、及びグレースフル・デグラデーションの態様を提供するロボットシステムの構成要素のブロック図である。 障害応動、障害分離、及びグレースフル・デグラデーションを提供する方法のフロー図である。 好ましくは、ロボットシステムのロボットアームのノードによって実行される障害応動、障害分離、及びグレースフル・デグラデーションを提供するための方法の態様のフロー図である。 好ましくは、ロボットシステムのロボットアームに動作可能に結合されるアームプロセッサによって実行される障害応動、障害分離、グレースフル・デグラデーションを提供するための方法の態様のフロー図である。 好ましくは、ロボットシステムのシステム監視プロセッサによって実行される障害応動、障害分離、及びグレースフル・デグラデーションを提供するための方法の態様のフロー図である。 好ましくは、ロボットシステムのアーム監視プロセッサによって実行される障害応動、障害分離、グレースフル・デグラデーションを提供するための方法の態様のフロー図である。

図１は、一例として、ケーブル１８１、１８２を介して互いに通信するユーザコンソール１００、ロボットアームカート１１０、及びビジョンカート１７０を含むロボットシステム１０００の斜視図を示す。ユーザコンソール１００は、ステレオビューア１０１、手操作可能なマスタコントローラ１０２、１０３、及び少なくとも１つのフットペダル１０４を含む。ロボットアームカート１１０は、ベース１２０、このベース１２０に取り付けられるカラム１２１、及びカラム１２１に取り付けられ且つ取付け可能な器具１１２、１１４、１１６、１１８を保持、移動、及び操作するように構成されるロボットアーム１１１、１１３、１１５、１１７を含む。

図１の例では、ロボットアーム１１１、１１３、１１７は、ツール器具１１２、１１４、１１８を保持し、ロボットアーム１１５は、立体カメラ装置１１６を保持する。あるいはまた、ロボットアーム１１１、１１３、１１５、１１７のそれぞれは、作業処置が行われている間に、様々なタイプの器具を保持することができ、又は器具を全く保持しないことがある。一例として、異なる撮像モダリティを用いる第２の画像取込装置は、ロボットアーム１１１によって保持されるツール器具１１２と交換することができる。別の例として、ロボットアーム１１１は、作業処置の全て又は一部の間に、そのアームに器具が取り付けられていない状態で使用されないままにすることができる。

立体カメラ装置１１６は、ビデオストリームとしてビジョンカート１７０に連続的に送信されるような立体画像を取り込む。ビジョンカート１７０は、その立体画像を受信したい際に立体画像の各ペアを処理し、処理した立体画像のペアをステレオビューワ１０１上にリアルタイムで表示するためにユーザコンソール１００に送信する。こうして、ユーザは、マスタコントローラ１０２、１０３及び／又はフットペダル１０４のうちの関連するものを操作することによってツール器具１１２、１１４、１１８及び／又は立体カメラ装置１１６を遠隔操作によって操作しながら、立体カメラ装置１１６によって取り込まれた作業部位の立体画像を見ることができる。このような遠隔ロボット操作を容易にするために、マスタ／スレーブ制御システムが、ロボットシステム１０００に設けられる。

ロボットアーム１１１、１１３、１１５、１１７を、垂直方向に上下に（例えば、天井に向かって又は床に向かって）移動させることができる。ロボットアーム１１１、１１３、１１５、１１７のそれぞれは、好ましくは、マニピュレータ及びセットアップアームを含む。マニピュレータは、器具を保持し、その器具を旋回点の回りで操作するように構成される。セットアップアームは、マニピュレータを空間内で水平方向に平行移動するように構成され、それによって、マニピュレータの保持器具及び器具の旋回点も空間内で水平方向に平行移動される。

図２は、一例として、協調的に相互作用し、ロボットシステム１０００における障害応動、障害分離、及びグレースフル・デグラデーションの様々な態様を実行するロボットシステム１０００の構成要素のブロック図を示す。ロボットアーム１１１、１１３、１１５、１１７のそれぞれは、１つ又は複数のノードを含む。各ノードは、１つ又は複数のモーターを制御し、ロボットアームにおける関節及び／又はリンク機構を作動してロボットアームの運動の自由度をもたらす。各ノードは、モーターの回転を停止させるための１つ又は複数のブレーキも制御する。

一例として、ロボットアーム１１１は、複数のモーター（例えば、２１、２３、２５、２７）、複数のブレーキ（例えば、２２、２４、２６、２８）、及び複数のノード（例えば、２１１、２１２、２１３）を有する。ノード２１１、２１２のそれぞれは、単一のモーター／ブレーキのペアを制御する。これに対して、ノード２１３は、２つのモーター／ブレーキのペアを制御する。他のノード（図示せず）が、２つ以上のモーター／ブレーキのペアを制御してもよい。センサ処理ユニット２１４が、制御目的のために、モーター変位のセンサ情報をノード２１３に提供するために含まれる。３つのノードがロボットアーム１１１に示されているが、ロボットアーム１１１の運動の自由度をもたらすのに必要なモーターの数と、各ノードによって制御されるモーターの数との両方に依存して、これより多い又は少ないノードを使用してもよいことを理解されたい。ロボットアーム１１３、１１５、１１７は、モーター、ブレーキ、及びノードを含むロボットアーム１１１として同様に構成される。

各ロボットアームは、アームプロセッサに動作可能に結合される。具体的には、アームプロセッサ２１０は、ロボットアーム１１１のノードに動作可能に結合され、アームプロセッサ２２０は、ロボットアーム１１３のノードに動作可能に結合され、アームプロセッサ２３０は、ロボットアーム１１５のノードに動作可能に結合され、アームプロセッサ２４０は、ロボットアーム１１７のノードに動作可能に結合される。本明細書で説明する様々な処理タスクを実行することに加えて、各アームプロセッサは、その動作可能に結合したロボットアームの所望の関節位置θ^＾ _ｃを、その動作可能に結合したロボットアームのモーターを駆動させるための電流コマンドＩ^＾ _ｃに変換して、それぞれの関節を所望の関節位置に作動させるための関節位置コントローラを含む。

システム監視プロセッサ２０１（本明細書では、単に「システム監視」とも呼ぶ）が、アームプロセッサ２１０、２２０、２３０、２４０に動作可能に結合される。本明細書で説明する様々な処理タスクを実行することに加えて、システム監視プロセッサ２０１は、ロボットアームに関連した入力装置のユーザ操作を所望の関節位置θ^＾ _ｃに変換する。別個のユニットとして示されているが、アームプロセッサ２１０、２２０、２３０、２４０は、プログラムコードによってシステム監視プロセッサ２０１の一部として実装してもよい。

アーム監視プロセッサ２５０（本明細書では、単に「アーム監視」とも呼ぶ）が、システム監視プロセッサ２０１及びアームプロセッサ２１０、２２０、２３０、２４０に動作可能に結合される。アーム監視プロセッサ２５０は、システム監視プロセッサ２０１を協調動作を行うことから解放するように、アームの特定の協調動作を開始、制御、及び／又は監視する。別個のユニットとして示されているが、アーム監視プロセッサ２５０は、プログラムコードによってシステム監視プロセッサ２０１の一部として実装してもよい。

プロセッサ及びノードとして説明したが、プロセッサ及びノードのそれぞれは、ハードウェア、ファームウェア、及びソフトウェアのプログラミングの組合せによって、本明細書で説明する様々なタスクを実行するように構成してもよいことを理解されたい。また、本明細書で説明するようなそれら機能は、１つのユニットによって実行してもよく、又は複数のサブユニットの間で分割してもよく、次に、各機能は、ハードウェア、ファームウェア、及びソフトウェアのプログラミングの組合せによって実施することができる。さらに、システム監視プロセッサ２０１は、システム１０００全体に亘って、ユーザコンソール１００、ビジョンカート１７０、及びロボットアームカート１１０のベース１２０等のサブユニットとして分散させてもよい。さらに、システム監視プロセッサ２０１、アーム監視プロセッサ２５０、及びアームプロセッサ、２１０、２２０、２３０、２４０のそれぞれは、本明細書で説明する様々な処理及び／又は制御タスク及び機能を実行するために複数のプロセッサを含んでもよい。

各ノード及びセンサ処理ユニットは、そのロボットアームの他のノード及びそのロボットアームに動作可能に結合されたアームプロセッサとの通信を容易にするために、送信機／受信機（ＴＸ／ＲＸ）のペアを含む。ＴＸ／ＲＸは、この例では、デイジーチェーンでネットワーク化されている。このようなデイジーチェーンの構成では、各ノードのＲＸが隣接するノードのＴＸから情報のパケットを受信した場合に、ＲＸは、そのパケットがそのノードを宛先としているかどうかを判定するために、そのパケット内の宛先フィールドをチェックする。パケットがそのノードを宛先としている場合に、そのノードは、そのパケットを処理する。一方、パケットが別のノードを宛先としている場合に、ノードのＴＸは、受信したパケットをそのパケットが入来したノードとは反対方向の隣接するノードのＲＸに渡す。情報は、好ましくは、パケット交換プロトコルを使用するパケットでデイジーチェーンネットワークを介して通信される。このようなパケット交換プロトコルに関する更なる詳細については、例えば、”Synchronous Data Communication”という標題の米国特許第８，０５４，７５２号を参照されたい。この文献は、参照することにより本明細書に組み込まれる。

障害通知がアームを介して迅速に伝達されるように、障害応動ロジック（FRL）ラインが、各ロボットアームに設けられる。一例として、ロボットアーム１１１は、アームプロセッサ２１０及びロボットアーム２１１のノード２１１、２１２、２１３のそれぞれに結合されるＦＲＬライン２１５を含む。アームプロセッサ２１０及びノード２１１、２１２、２１３のいずれかがそれに影響を及ぼす障害を検出する場合に、アームプロセッサ又はノードは、ＦＲＬライン２１５をＨＩＧＨ（高）状態に引き上げ、このライン２１５に結合した他のコンポーネントに障害通知を迅速に伝達することができる。逆に、アームプロセッサ２１０が回復通知をロボットアーム１１１のノードに送信すべき場合に、そのアームプロセッサ又はノードは、ＦＲＬライン２１５をＬＯＷ（低）状態に引き下げ、ライン２１５に結合した他のコンポーネントに回復通知を迅速に伝達することができる。

現実のＦＲＬライン２１５について本明細書で説明しているが、代替的に、このような障害通知及び回復通知を含むようにパケットの１つ又は複数のフィールドを指定することにより、仮想ＦＲＬライン２１５を使用してもよいことを理解されたい。例えば、パケットの指定したビット中の「１」の存在によって、障害通知を示すことができ、パケットの指定したビット中の「１」の不存在（すなわち、「０」）（又は異なるビット）によって、回復通知を示すことができる。このような仮想ＦＲＬラインに関する更なる詳細については、例えば、先に参照した、”Synchronous Data Communication“という標題の米国特許第８，０５４，７５２号を参照されたい。この文献は、参照することにより本明細書に組み込まれる。

図３は、一例として、複数のロボットアームを有するロボットシステムにおいて実施することができる障害応動、障害分離、及びグレースフル・デグラデーションのための方法を示す。ブロック１００１では、この方法は、複数のロボットアームのうちの故障が発生したアームの障害を検出し、そのロボットアームは、検出した障害によって「故障が発生したアーム」となる。ブロック１００２では、この方法は、次に、故障が発生したアームを安全な状態に置く。ここで、「安全な状態」とは、故障が発生したアームの更なる運動を防止することによって検出した障害を隔離するような故障が発生したアームの状態を指す。ブロック１００３では、この方法は、障害をシステム障害又はローカル障害として処理すべきかどうかを判定する。ここで、「システム障害」とは、複数のロボットアームのうちの少なくとも１つの他のロボットアームの性能に影響を及ぼす障害を指し、「ローカル障害」とは、故障が発生したアームのみの性能に影響を及ぼす障害を指す。具体的には、ローカル障害は、障害がクリアにされるまで故障が発生したアームのみを安全な状態に維持するので、このタイプの障害は、故障していないロボットアームの危険な動作をもたらすことはない。従って、障害が、故障していないアームの危険な動作を生じさせるタイプの障害である場合に、次に、この方法は、検出した障害が、システム内の全てのロボットアームを安全な状態に置くべきシステム障害であるとの判定をもたらす。ブロック１００４では、本方法は、障害をシステム障害として処理すべき場合にのみ、複数のアームのうちの故障していないアームを安全状態に置く。ここで「故障していないアーム」とは、複数のロボットアームのうち、障害が検出されなかったロボットアームを指す。

この方法は、様々なオプションのタスクも実行することができる。ブロック１００５では、この方法は、必要に応じて、検出した障害が回復可能なシステム障害又は回復不能なシステム障害として分類されているかどうかを判定する。ブロック１００６では、この方法は、障害が回復可能なシステム障害として分類される場合に、必要に応じて、回復オプションをシステムのユーザに提示する。これに対して、ブロック１００７では、この方法は、障害が回復不能なシステム障害として分類される場合に、必要に応じて、システムのシャットダウンを待つ。

さらに、ブロック１００３での判定が、障害をローカル障害として処理すべき判定である場合に、次にブロック１００８では、この方法は、必要に応じて、障害が回復可能なローカル障害又は回復不能なローカル障害として分類されるかどうかを判定する。ブロック１００９では、この方法は、故障が回復可能なローカル障害として分類される場合に、必要に応じて、回復オプション及び機能低下(degraded)動作オプションをシステムのユーザに提示する。これに対して、ブロック１０１０では、この方法は、障害が回復不能なローカル障害として分類される場合に、必要に応じて、機能低下動作オプションのみを提示する。

追加のオプションの態様は、以下のフロー図で説明するように、ロボットアームのノードの協調的な相互作用、ロボットアームに関連したアームプロセッサ、アーム監視プロセッサ、システム監視プロセッサに従ったロボットシステムの障害応動及びグレースフル・デグラデーションのための方法を含めることもできる。

図４は、一例として、好ましくはロボットシステム１０００の複数のロボットアームのノード（例えば、２１１、２１２、２１３）のそれぞれによって実行される、障害応動、障害分離、及びグレースフル・デグラデーションを行うための方法の態様のフロー図を示す。

ブロック４０１では、各ノードは、従来の障害検出方法を使用してノードに影響を及ぼす障害を検出するためにノードの信号及び／又は情報を継続的に監視する。このタイプの検出した障害は、その障害がノードに特有なものであるため、本明細書では「ローカル障害」と呼ぶ。ノードは、そのアームプロセッサ又はそのロボットアームの別のノードによって発行された障害通知について（現実又は仮想の）ＦＲＬラインも監視する。このタイプの検出した障害は、その障害がノードに特有なものではないので、本明細書では「リモート障害」と呼ぶ。検出した障害は、ハードウェア、ファームウェア、ソフトウェア、環境、又は通信に関連することができる。説明目的のために、障害が検出されたノードは、本明細書では「故障が発生したノード」と呼び、先に説明したように、そのロボットアームは、本明細書では「故障が発生したアーム」と呼ぶ。障害が検出されなかったノードは、本明細書では「故障していないノード」と呼び、先に説明したように、障害が検出されなかったロボットアームは、本明細書では「故障していないアーム」と呼ぶ。

ブロック４０２では、障害がブロック４０１で検出されると、そのノードは、それ自体を安全な状態に置く。これは、例えば、ノードによって制御される１つ又は複数のモーターを無効にする（例えば、電圧信号を１つ又は複数のモーターに供給するのを中止する）ことにより行ってもよい。代替的に又は追加的に、これは、ノードによって制御される１つ又は複数のブレーキを係合させる（例えば、ノードの１つ又は複数のブレーキに通電して、ノードの１つ又は複数のモーターの回転を抑制する）ことにより行ってもよい。ブロック４０３では、ノードは、検出した障害がローカル障害又はリモート障害であるかどうかを判定する。以前にブロック４０１を参照して説明したように、障害の発生源によって、その障害をローカル障害又はリモート障害として処理すべきかどうかを判定する。障害がローカル障害であると判定された場合に、そのノードは、故障が発生したノードとなる。この第１のケースでは、故障が発生したノードは、以下で説明するように、ブロック４０４〜４０７及びブロック４０９〜４１０を実行することによって継続する。これに対して、障害がリモート障害であると判定された場合に、そのノードは、故障していないノードである。この第２のケースでは、故障していないノードは、以下で説明するように、ブロック４０８〜４１０を実行することによって継続する。

ブロック４０４では、故障が発生したノードは、故障が発生したロボットアームの上流及び下流方向の両方に隣接するノードに障害通知を伝達する。本明細書で使用される場合に、「下流」方向とは、情報のパケットがそのノードのアームプロセッサから離れる方向に移動する方向を指し、「上流」方向は、情報のパケットがそのノードのアームプロセッサに向けて移動する方向を指す。先に説明したように、ノードがこれを行い得る１つの方法は、（現実の又は仮想の）ＦＲＬラインをＨＩＧＨ状態に引き上げることである。

ブロック４０５では、次に、故障が発生したノードは、障害を診断し、エラーメッセージをシステム監視プロセッサ２０１に送る。エラーメッセージは、好ましくは、そのエラーコード、エラークラス、及び原点等の障害の情報を含む。ノードに影響を与え得るエラーの種類毎にエラーコードが割り当てられる。エラーコードは、エラークラスに分類される。好ましくは、少なくとも４つのエラークラス：回復可能なアーム障害（本明細書では、「回復可能なローカル障害」とも呼ぶ）、回復不能なアーム障害（本明細書では、「回復不能なローカル障害」とも呼ぶ）、回復可能なシステム障害、及び回復不能なシステム障害がある。本明細書で使用される「回復可能な」という用語は、障害からの回復を試みるためのオプションがユーザに提供されることを意味する。本明細書で使用される「回復不能な」という用語は、障害からの回復を試みるためのオプションがユーザに提供されないことを意味する。障害の原因には、ノードを特定するための情報及び必要に応じてノードの障害の発生源の更なる情報を含む。

ブロック４０６では、故障が発生したノードは、検出した障害が回復可能なローカル障害であるか否かを判定する。先に説明したように、障害のエラークラスによりこの判定を行う。ブロック４０６での判定が「いいえ」である（例えば、検出した障害が回復不能なローカル障害である）場合に、次にブロック４０７では、故障が発生したノードは、その安全な状態に留まり、その後（現実又は仮想の）ＦＲＬラインで受信される回復通知を無視する。これに対して、ブロック４０６での判定が「はい」である（例えば、検出した障害が回復可能なローカル障害である）場合に、次に、故障が発生したノードは、ブロック４０９に進む。

ブロック４０３での判定が、検出した障害をリモート障害として処理すべきである（すなわち、そのノードは、故障していないノードである）場合に、次にブロック４０８では、故障していないノードは、仮想ＦＲＬラインを用いた場合に、その障害通知が入来したノードとは反対方向に受信した障害通知を伝達する（例えば、ノード２１２が障害通知をノード２１１から受信した場合に、次にノード２１２は、その障害通知をノード２１３に伝達する）。現実のＦＲＬラインの場合には、故障していないノードは、障害通知の伝達のような動作を行う必要がない。

ブロック４０９では、故障が発生したノード及び故障していないノードの両方は、回復通知を受信するのを待つ。ブロック４１０では、回復通知を受信すると、ノードは、それ自体を安全な状態から再びその通常の動作状態に戻す。典型的には、これは、急激な変化を回避しながら、ブロック４０２で行われる動作を逆転することによって行うことができる。ノードは、次に、ブロック４０１を参照して説明したその障害検出タスクの実行に戻る。

図５は、一例として、ロボットシステム１０００のロボットアームに動作可能に結合される、好ましくは各アームプロセッサ（例えば、２１０、２２０、２３０、２４０）によって実行される障害応動、障害分離、及びグレースフル・デグラデーションを行うための方法の態様のフロー図を示す。

ブロック５０１では、各アームプロセッサは、その通常の動作タスクを実行しながら、それ自体の動作を継続的に監視し、その動作可能に結合したロボットアームにおいて故障が発生したノードによって伝達される障害通知を見付け出す。それ自体の動作を監視しながら障害を検出した場合に、次に、その障害は、本明細書では「ローカル障害」であると呼ぶ。これに対して、障害が、その動作可能に結合したロボットアームにおいて故障が発生したノードから障害通知を受信することにより検出した場合に、次に、その障害は、本明細書では「リモート障害」であると呼ぶ。この場合のリモート障害は、アームプロセッサが動作可能に結合されるロボットアームで故障が発生したノードによって、（現実又は仮想の）ＦＲＬラインに沿って伝達される障害通知を指す。

障害がブロック５０１で検出された場合に、次にブロック５０２では、アームプロセッサは、そのモーターの出力電流コマンドＩ^＾ _ｃをゼロにラッチすることにより、その関節位置コントローラを安全な状態に置く。これは、それぞれのノードの安全な状態を強化するのに役立つ。

ブロック５０３では、アームプロセッサは、検出した障害がローカル障害又はリモート障害であるかどうかを判定する。以前にブロック５０１を参照して説明したように、障害の発生源によって、ローカル障害又はリモート障害として処理すべきかどうかを判定する。障害がローカル障害であると判定された場合に、次に、アームプロセッサは、故障が発生したノードとして扱われる。この第１のケースでは、アームプロセッサは、以下で説明するようにブロック５０４〜５０７及びブロック５０９〜５１０を実行することによって継続する。これに対して、障害がリモート障害であると判定された場合に、次に、アームプロセッサは、故障していないノードとして扱われる。この第２のケースでは、アームプロセッサは、以下で説明するようにブロック５０８〜５１０を実行することによって継続する。

ブロック５０４では、アームプロセッサは、下流側のその動作可能に接続されたロボットアームの全てのノードに障害通知を伝達する。先に説明したように、アームプロセッサがこれを行い得る１つの方法は、（実際又は仮想の）ＦＲＬラインをＨＩＧＨ状態に引き上げることである。

ブロック５０５では、次に、アームプロセッサは、障害を診断し、エラーメッセージをシステム監視プロセッサ２０１に送る。エラーメッセージには、好ましくは、そのエラーコード、エラークラス、及び原点等の障害の情報が含まれている。アームプロセッサに影響を及ぼし得るエラーの種類毎にエラーコードが割り当てられる。エラーコードは、エラークラスに分類される。好ましくは、少なくとも４つのエラークラス：回復可能なプロセッサ障害、回復不能なプロセッサ障害、回復可能なシステム障害、及び回復不能なシステム障害がある。「回復可能な」及び「回復不能な」という用語は、図４のブロック４０５を参照して説明したのと同様に使用される。障害の原因には、アームプロセッサを特定する情報と、必要に応じてアームプロセッサの障害の発生源の追加情報とが含まれる。

ブロック５０６では、アームプロセッサは、検出した障害が回復可能なローカル障害であるか否かを判定する。先に説明したように、障害のエラークラスによりこの判定を行う。ブロック５０６での判定が「いいえ」である（例えば、検出した障害が回復不能なローカル障害である）場合に、次にブロック５０７では、故障が発生したアームプロセッサの関節位置コントローラは、その安全な状態に留まり、アームプロセッサは、その後（実際又は仮想の）ＦＲＬラインで受信される回復通知を無視する。これに対して、ブロック５０６での判定が「はい」である（例えば、検出した障害が回復可能なローカル障害である）場合に、次に、アームプロセッサは、ブロック５０８に進む。

ブロック５０３での判定が、検出した障害をリモート障害として処理すべきである場合に、次にブロック５０８では、アームプロセッサは、システム監視プロセッサ２０１から回復通知を受信するのを待つ。ブロック５０９では、回復通知を受信すると、アームプロセッサは、例えば（実際又は仮想の）そのＦＲＬラインをＬＯＷ状態に引き下げることによって、その動作可能に結合されたロボットアーム内の全てのノードに回復通知を伝達する。ブロック５１０では、次に、アームプロセッサは、その関節位置コントローラを安全な状態からその通常の動作状態に再び戻す。典型的には、これは、急激な変化を回避しながら、その動作可能に結合されたロボットアームの所望の関節位置を再び反映するようにそのモーターの出力電流コマンドＩ^＾ _ｃをリリースすることによって行うことができる。次に、アームプロセッサは、ブロック５０１を参照して説明したその障害検出タスクの実行に戻る。

図６は、一例として、好ましくはロボットシステム１０００のシステム監視プロセッサ２０１によって実行される障害応動、障害分離、グレースフル・デグラデーションを実行するための方法の態様のフロー図を示す。

ブロック６０１では、システム監視プロセッサは、その通常の動作タスクを実行しながら、ロボットシステム１０００の他のコンポーネントから送信されたエラーメッセージを受信するのを待つ。例えば、このようなエラーメッセージは、図４のブロック４０５を参照して説明したように、故障が発生したノードにより送信されるものであり、又は図５のブロック５０５を参照して説明したように、故障が発生したアームプロセッサによって送信されるものである。

エラーメッセージをブロック６０１で受信すると、ブロック６０２では、システム監視プロセッサは、例えば、ロボットシステム内の全てのアームプロセッサ（例えば、２１０、２２０、２３０、２４０）の関節位置コントローラに命令して、それぞれの出力をそれらの電流値にラッチすることにより、安全のためシステムを停止する。この方法では、関節位置コントローラの出力がラッチ解除されるまで、新しい電流のコマンド入力が、ロボットアームに提供されない。関節位置コントローラの出力のこのラッチは、本明細書では、関節位置コントローラを「ソフトロックする」と呼ぶ。次に、この方法は、ブロック６０３に進む。

ブロック６０３では、システム監視プロセッサは、検出した障害をシステム障害又はアーム障害として処理すべきかどうかを判定する。好ましくは、システム監視プロセッサは、エラーメッセージに提供されたエラークラス情報を検査することにより、この判定を行う。この場合には、システム障害には、回復可能なシステム障害又は回復不能なシステム障害のいずれかとして分類される全ての障害が含まれる。それは、これらの障害が、故障が発生したロボットアーム以外にも当てはまるからである。逆に、アーム障害には、回復可能なローカル障害又は回復不能なローカル障害のいずれかとして分類された全ての障害が含まれる。それは、これらの障害が、故障が発生したロボットアームにのみ当てはまるからである。

ブロック６０４〜６１２は、アーム障害として処理すべきとされた全ての障害について実行される。ブロック６０４では、システム監視プロセッサは、ロボットシステム１０００の機能低下動作を受け入れるためのオプションをロボットシステム１０００のユーザに提供する。また、ローカル障害が回復可能なローカル障害である場合に、システム監視プロセッサは、障害から回復するためのオプションもユーザに提供する。好ましくは、各提供オプションに加えて、検出した障害の情報は、オプションを受け入れるか否かを決定する際にユーザを支援するためにシステム監視プロセッサによって提供してもよい。好ましくは、オプション及び障害情報は、ユーザコンソール１００のステレオビューワ１０１等のユーザによって確認することができる表示画面上に提供される。しかしながら、そのようなオプションや情報をユーザに提供する従来の手段は、本明細書では、システム監視プロセッサがそのタスクを実行する際に使用可能であるように企図されている。

ブロック６０５では、システム監視プロセッサは、ユーザがブロック６０４で提供されるオプションを選択するのを待つ。ユーザがオプションを選択すると、ブロック６０６では、システム監視プロセッサは、選択されたオプションが、機能低下動作オプション又は回復オプションであったかどうかを判定する。

回復オプションが提供され、且つユーザがこの回復オプションを選択した場合に、次にブロック６０７では、システム監視プロセッサは、故障が発生したロボットアームのアームプロセッサに回復通知を送る。故障が発生したロボットアームのアームプロセッサは、以前に図５のブロック５０８〜５１０を参照して故障が発生したアームの全てのノードに回復通知を伝達するステップを含むことを説明したように、回復通知を処理することになる。故障が発生したアームのノードは、以前に図４のブロック４０９〜４１０を参照して説明したように、回復通知を処理することになる。ブロック６０８では、次に、システム監視プロセッサは、その出力をラッチ解除することにより、全てのアームプロセッサの関節コントローラのソフトロックを解除し、それによって、それら関節コントローラは、それらに動作可能に結合したロボットアームの所望の関節位置を反映するモーター電流コマンドＩ^＾ _ｃを再び発することができる。次に、システム監視プロセッサは、ブロック６０１を参照して説明したそのタスクの実行に戻る。

ブロック６０７〜６０８を参照して上述したように障害を回復するように試みた後に、障害が永続的な障害である（すなわち、障害が解決しない）場合に、次に、障害の原因によって、図４のブロック４０１又は図５のブロック５０１のいずれかで検出した障害が再びトリガされることに注意されたい。この場合には、恐らくシステムのユーザは、障害から回復するために繰り返される試みが繰り返し失敗する場合に、その後ブロック６０４〜６０５をパスし、回復オプションを選択しないことを選ぶだろう。

しかしながら、ユーザが機能低下動作オプションを選択した場合に、次にブロック６０９では、システム監視プロセッサは、障害から回復するためのオプションをユーザに提供する。この場合の障害からの回復は、故障が発生したアームを回復させるための試みが行われないという点で、ブロック６０７〜６０８を参照して説明した回復とは異なる。回復は、故障していないアームの正常な作動を回復するためにのみ適用される。ブロック６１０では、システム監視プロセッサは、ユーザがブロック６０９で提供されるオプションを選択するのを待つ。ユーザがオプションを選択すると、ブロック６１１では、システム監視プロセッサは、故障が発生したアームのアームプロセッサにメッセージを送信し、障害に対して強化する。この場合の障害に対する強化は、故障が発生したロボットアームの動作を完全シャットダウンするために追加のステップが行われることを意味する。このような強化対策の一例は、その動作可能に結合したロボットアームの所望の関節位置θ^＾ _ｃを生成するマスタ／スレーブ制御システムの他の部品から、アームプロセッサの関節位置コントローラを動作可能に切断することである。別の強化対策は、故障が発生したロボットアームへの電源をオフにすることでもよい。次にブロック６１２では、システム監視プロセッサは、その出力をラッチ解除することにより、故障していない全てのアームのアームプロセッサの関節コントローラのソフトロックを解除し、それによって、それら関節コントローラは、それら動作可能に結合したロボットアームの所望の関節位置θ^＾ _ｃを反映するモーター電流コマンドＩ^＾ _ｃを再び発することができる。システム監視プロセッサは、次に、ブロック６０１を参照して説明したそのタスクの実行に戻る。

ブロック６１３〜６１８は、システム障害として処理すべきとされた全ての障害について実行される。ブロック６１３では、システム監視プロセッサは、ロボットシステム１０００内の全てのノードに対してシステムＦＲＬ状態をアサートする。好ましく、それは、（現実又は仮想のラインであってもよい）ＦＲＬライン２１５、２２５、２３５、２４５をＨＩＧＨ状態に引き上げることによりこれを行い、それによって、障害通知が、ロボットアーム１１１、１１３、１１５、１１７のアームプロセッサ及びノードに同時に提供される。

ブロック６１４では、次に、システム監視プロセッサは、システム障害が回復可能なシステム障害であるか否かを判定する。先に説明したように、受信したエラーメッセージ内のエラークラスの検査によって、これを行うことができる。ブロック６１４での判定が「いいえ」である（すなわち、システム障害が、回復不能なシステム障害である）場合に、次にブロック６０９では、システム監視プロセッサは、更なる動作を実行せず、システムがシャットダウンされるのを待つ。

これに対して、ブロック６１４での判定が「はい」である（すなわち、システム障害が回復可能なシステム障害である）場合に、次にブロック６１５では、システム監視プロセッサは、障害から回復するためのオプションをユーザに提供する。ブロック６１６では、システム監視プロセッサは、ユーザが回復オプションを選択するのを待つ。ユーザがオプションを選択すると、ブロック６１７では、システム監視プロセッサは、ロボットシステム１０００の全てのロボットアームのアームプロセッサに回復通知を送る。アームプロセッサは、以前に図５のブロック５０８〜５１０を参照してそれぞれのアームの全てのノードに回復通知を伝達するステップを含むことを説明したように、回復通知を処理することになる。次に、ノードは、以前に図４のブロック４０９〜４１０を参照して説明したように、回復通知を処理することになる。ブロック６１８では、システム監視プロセッサは、関節コントローラのアームをその通常の動作状態で操作するための要求又はアクションをユーザから受信すると、各関節コントローラのソフトロックを解除し、それによって、解除された関節コントローラは、その動作可能に結合したロボットアームの所望の関節位置θ^＾ _ｃを反映するモーター電流コマンドＩ^＾ _ｃを再び発することができる。次に、システム監視プロセッサは、ブロック６０１を参照して説明したそのタスクの実行に戻る。

ブロック６１４〜６１８を参照して上述したように障害を回復するように試みた後に、障害が永続的な障害である（すなわち、障害が解決しない）場合に、次に、障害の原因によって、図４のブロック４０１又は図５のブロック５０１のいずれかで検出した障害が再びトリガされることに注意されたい。この場合には、恐らくシステムのユーザは、障害から回復するために繰り返される試みが繰り返し失敗する場合に、その後ブロック６１５〜６１６をパスし、回復オプションを選択しないことを選ぶだろう。

図７は、一例として、ロボットシステム１０００のシステム監視プロセッサ（例えば、２０１）及びアームプロセッサ（例えば、２１０、２２０、２３０、２４０）に動作可能に結合したアーム監視プロセッサ（例えば、２５０）によって好ましくは実行される障害応動、障害分離、グレースフル・デグラデーションを行うための方法の態様のフロー図を示す。

前述したように、アーム監視プロセッサ２５０は、ロボットシステム１０００のアーム１１１、１１３、１１５、１１７の特定の協調動作を開始し、制御し、及び／又は監視することができる。一例として、アーム監視プロセッサ２５０は、起動ブレーキ試験を開始し且つ監視することができ、ここでアーム監視プロセッサ２５０は、アームプロセッサ２１０、２２０、２３０のそれぞれと通信し、それによって異なるトルク値を有する特定のブレーキシーケンスが、それぞれのロボットアームのブレーキに適用される。各アームプロセッサにこの協調動作を符号化するためのオーバーヘッドが過剰となり得るので、この動作のコーディネートは、この場合にはアーム監視プロセッサ２５０によって行われる。各シーケンスの終了時に、各アームプロセッサによって計算された最大トルク値が、アーム監視プロセッサ２５０に戻され、範囲外のエラーが発生した場合に、アーム監視プロセッサ２５０は、故障が発生したアームへの障害通知を掲載(post)する。そのためこの例では、アーム監視プロセッサは、アームプロセッサに命令してアーム動作を実行させ、その結果を監視し、動作結果がアーム障害を示すかどうかを決定する。

ブロック７０１では、アーム監視プロセッサは、ロボットアームの協調動作を監視し、それぞれのアームプロセッサによって報告される際に、複数のアームのうちの１つの障害を検出する。典型的には、アーム監視プロセッサは、報告された測定値が期待値を閾値量だけ超えた場合に、障害が発生したと判定する。この場合に検出される障害は、ロボットアームのノード又はアームプロセッサのいずれかによって通常検出されない障害である。

障害がブロック７０１で検出された後に、次にブロック７０２では、アーム監視プロセッサは、故障が発生したアームへの更なるコマンドを抑止する。具体的には、回復通知がシステム監視プロセッサから受信されるか、又はシステムが再起動されるまで、更なるコマンドが、アーム監視プロセッサから故障が発生したアームのアームプロセッサに送信されない。

ブロック７０３では、アーム監視プロセッサは、故障が発生したアームのＦＲＬラインをＨＩＧＨ状態に引き上げることによって、故障が発生したアームに障害通知を伝達する。仮想ＦＲＬラインの場合には、アーム監視プロセッサは、故障が発生したアームのノード又はアームプロセッサのいずれかによる障害通知の送信に指定された同じパケットフィールドに又は異なるパケットフィールドに障害通知を送信してもよい。

ブロック７０４では、アーム監視プロセッサは、エラーコード、エラークラス、及び原点等の障害の利用可能な詳細を含むエラーメッセージをシステム監視プロセッサに送る。アーム監視プロセッサによって検出され得る障害の種類毎にエラーコードが割り当てられ、このエラーコードは、回復可能なアーム障害、回復不能なアーム障害、回復可能なシステム障害、及び回復不能なシステム障害等のエラークラスに分類される。障害の原因には、故障が発生したアームを特定する情報、及び利用可能な場合に、必要に応じて故障の発生源の追加情報が含まれる。次に、システム監視プロセッサは、図６のブロック６０１を参照して説明したように、エラーメッセージを処理するために進む。

ブロック７０５では、アーム監視プロセッサは、検出した障害が回復可能な障害であるか否かを判定する。先に説明したように、障害のエラークラスに応じて、この判定が行われる。ブロック７０５での判定が「いいえ」である（例えば、検出した障害が回復不能アーム又はシステム障害である）場合に、次にブロック７０６では、アーム監視プロセッサは、故障が発生したアームへの更なるコマンドを抑止し続け、その後システム監視プロセッサから受信され得る回復通知を無視する。

これに対して、ブロック７０５での判定が「はい」である（例えば、検出された障害が回復可能なアーム障害又は回復可能なシステム障害である）場合に、次にブロック７０７では、アーム監視プロセッサは、監視プロセッサから受信される回復通知を待つ。ブロック７０８では、回復通知を受信すると、アーム監視プロセッサは、故障が発生したアームに対するコマンドを抑止するのを停止し、その通常の作動モードに戻り、ブロック７０１を参照して説明したその障害検出タスクを実行する。

本発明の様々な態様について上述した実施例に関して説明してきたが、本発明は、添付の特許請求の範囲の全範囲内で完全な保護を受ける権利があることが理解されるであろう。特に、ある特定の具体例について本明細書で説明しているが、本発明の範囲は、これらの具体例に限定されるものではない。例えば、障害分離及びグレースフル・デグラデーションは、故障したノードのレベルにまで拡張することができ、それによって、ユーザには、故障が発生したアームの故障していないノードを使用し続けるオプションを提供することができる。別の例として、故障していないノード又は故障が発生したアームのアームプロセッサは、故障が発生したアームの故障したノードの障害を検出し、その故障が発生したアームの他のノードに障害通知を伝達し、システム監視プロセッサにエラーメッセージを送るように構成し得る。本明細書で説明した教示を拡張する、ロボット技術分野の当業者によって想起され且つ実現される他の実施例は、依然として本発明の完全な範囲内にあると考えられる。

Claims (18)

1. 複数のロボットアームを有するロボットシステムにおける障害応動、障害分離、及びグレースフル・デグラデーションのための方法であって、当該方法は：
   前記複数のロボットアームのうちの故障が発生したアームの障害を検出するステップと；
   前記故障が発生したアームを安全な状態に置くステップと；
   前記障害をシステム障害又はローカル障害として処理すべきかどうかを判定するステップと；
   前記障害をシステム障害として処理すべき場合のみ、前記複数のロボットアームのうちの故障していないアームを安全な状態に置くステップと；を含む、
   方法。
2. 前記障害がローカル障害であると判定された場合に、機能低下動作オプションを前記ロボットシステムのユーザに提供するステップと；
   前記障害が回復可能なローカル障害又は回復可能なシステム障害であると判定された場合に、回復オプションを前記ユーザに提供するステップと；を含む、
   請求項１に記載の方法。
3. 前記複数のロボットアームのそれぞれは、前記ロボットアームの対応する自由度で作動させるための複数のモーターを有し、
   前記故障が発生したアームを安全な状態に置くステップは、前記故障が発生したアームについての複数のモーターを無効にするステップを含む、
   請求項１に記載の方法。
4. 前記複数のロボットアームのそれぞれは、前記ロボットアームの対応する自由度の運動を停止させるための複数のブレーキを有し、
   前記故障が発生したアームを安全な状態に置くステップは、前記故障が発生したアームについて複数のブレーキを係合させるステップを含む、
   請求項１に記載の方法。
5. 前記複数のロボットアームのそれぞれは、前記ロボットアームの対応する自由度の運動を生じさせる１つ又は複数のモーターを制御するための１つ又は複数のノードを有し、
   前記複数のロボットアームのうちの故障が発生したアームの障害を検出するステップは、前記故障が発生したアームのノードのいずれかの障害を検出するステップを含み、
   前記故障が発生したアームを安全な状態に置くステップは、前記故障が発生したアームの各ノードを前記安全な状態に置くステップを含む、
   請求項１に記載の方法。
6. 前記複数のロボットアームのそれぞれは、前記ロボットアームに動作可能に結合されたアームプロセッサを有し、
   前記複数のロボットアームのうちの故障が発生したアームの障害を検出するステップは、前記アームプロセッサのいずれかの障害を検出するステップを含み、
   前記故障が発生したアームを安全な状態に置くステップは、前記アームプロセッサを前記安全な状態に置くステップを含む、
   請求項１に記載の方法。
7. 前記複数のロボットアームのうちの故障が発生したアームの障害を検出するステップは、前記複数のロボットアームの協調動作を監視するステップを含み、
   前記故障が発生したアームを安全な状態に置くステップは、前記故障が発生したアームへのコマンドを抑止するステップを含む、
   請求項１に記載の方法。
8. 前記障害をシステム障害又はローカル障害として処理すべきかどうかを判定するステップは：
   前記障害を診断するステップと；
   前記障害の診断が故障していないアームを作動させるには安全でないことを示す場合に、前記障害をシステム障害として処理すべきであると判定するステップと；を含む、
   請求項１に記載の方法。
9. ロボットシステムであって、当該ロボットシステムは：
   複数のロボットアームと；
   複数のアームプロセッサであって、該複数のアームプロセッサのそれぞれは、前記複数のロボットアームの対応する１つに動作可能に結合される、複数のアームプロセッサと；
   システム監視プロセッサと；を含み、
   各ロボットアームは、前記ロボットアームの自由度の運動で作動させるための複数のモーターを有し、
   各ロボットアームは、前記ロボットアームの対応するモーターを制御するための１つ又は複数のノードを有し、
   各ノード及びアームプロセッサは、前記ノード又はアームプロセッサに影響を及ぼす障害の発生を検出し、該障害の発生を検出すると、前記ノード又はアームプロセッサを安全な状態に置き、前記ノードを含む又は前記アームプロセッサに動作可能に結合される故障が発生したアームを介して障害通知を伝達し、前記障害を診断し、前記障害の情報を含むエラーメッセージを前記システム監視プロセッサに送るように構成され、
   前記複数のロボットアームの各ノード及び複数のロボットアームに動作可能に結合された各アームプロセッサは、別のソースから障害通知を受信すると、前記ノード又はアームプロセッサを安全な状態に置くように構成され、
   前記システム監視プロセッサは、前記故障が発生したノード又は前記アームプロセッサから前記エラーメッセージを受信し、該エラーメッセージの情報を使用することにより、前記検出した障害をシステム障害又はローカル障害として処理すべきかどうか判定し、前記検出した障害がシステム障害として処理すべき場合のみ、複数のロボットアームのうち故障していないアームのアームプロセッサに障害通知を送信するように構成される、
   ロボットシステム。
10. 前記システム監視プロセッサは、前記障害がローカル障害であると判定された場合に、前記ロボットシステムのユーザに機能低下動作オプションを提供し、前記障害が回復可能なローカル障害又は回復可能なシステム障害であると判定された場合に、回復オプションを前記ユーザに提供するように構成される、
    請求項９に記載のロボットシステム。
11. 前記システム監視プロセッサは、前記機能低下動作オプションが選択された場合に、前記故障が発生したアームの動作を完全にシャットダウンすることにより、前記故障が発生したアームに動作可能に結合されたアームプロセッサにメッセージを送って、前記障害に対して強化するように構成される、
    請求項１０に記載のロボットシステム。
12. 前記システム監視プロセッサは、前記回復オプションが選択され且つ前記障害が前記ローカル障害であると判定された場合に、前記故障が発生したアームのアームプロセッサに回復通知を送るように構成される、
    請求項１０に記載のロボットシステム。
13. 前記システム監視プロセッサは、前記回復オプションが選択され且つ前記障害が前記システム障害であると判定された場合に、前記複数のロボットアームの各アームプロセッサに回復通知を送るように構成される、
    請求項１０に記載のロボットシステム。
14. 各ノードは、前記ノードによって制御される前記１つ又は複数のモーターを少なくとも無効にすることにより、前記ノードを安全な状態に置く、
    請求項９に記載のロボットシステム。
15. 前記複数のロボットアームのそれぞれは、前記ロボットアームの対応するモーターの運動を停止させるための複数のブレーキを有し、
    各ノードは、前記ノードによって制御される１つ又は複数のブレーキを少なくとも係合することにより、前記ノードを安全な状態に置く、
    請求項９に記載のロボットシステム。
16. 前記複数のノード及び前記故障が発生したアームの前記アームプロセッサは、前記複数のノードの各ノード及び前記故障が発生したアームの前記アームプロセッサを前記安全な状態に置くことにより、前記故障が発生したアームを前記安全な状態に置くように構成される、
    請求項９に記載のロボットシステム。
17. 各アームプロセッサは、関節位置コントローラを含み、該関節位置コントローラは、前記アームプロセッサの障害を検出する又は別のソースからの障害通知を受信すると、前記関節位置コントローラの出力をゼロ値にラッチすることにより、前記アームプロセッサを安全な状態に置く、
    請求項９に記載のロボットシステム。
18. 前記システム監視プロセッサ及び前記複数のアームプロセッサに動作可能に結合されアーム監視プロセッサをさらに含み、該アーム監視プロセッサは、前記複数のロボットアームの協調動作を監視し、前記協調動作中に前記複数のロボットアームの故障が発生したアームに影響を及ぼす障害の発生を検出し、コマンドを抑止して前記故障が発生したアームに障害通知を伝達し、前記システム監視プロセッサによる処理のために、前記障害の情報を含むエラーメッセージを前記システム監視プロセッサに送るように構成される、
    請求項９に記載のロボットシステム。

Images