JP2005515903A - ロボット用センサおよびアクチュエータのハードウェア抽象化層内における抽象化および集合化 - Google Patents

Abstract

本発明は、ロボット用のハードウェア抽象化層（ＨＡＬ）（２０２）を提供する方法および装置に関する。ＨＡＬ（２０２）が、ロボット制御ソフトウェア（１５７、１５８、１６０、１６２）と、下層のロボットハードウェア（１５２、１５４）および／またはハードウェア用のオペレーティングシステム（１５６）との間に、ソフトウェア層またはファームウェア層として存在し得る。ＨＡＬ（２０２）は、下層のハードウェアの集合体に比較的一様な抽象化を提供して、その結果、下層のロボットハードウェアが、知覚および制御ソフトウェア（１５７、１５８、１６０、１６２）、すなわちロボット制御ソフトウェア（１５７、１５８、１６０、１６２）にとって透明となる。これによって、ロボット制御ソフトウェア（１５７、１５８、１６０、１６２）が、ロボットとは無関係に記述可能になることが好ましい。したがって、ロボット制御ソフトウェアの開発者は、退屈で重要でない仕事から解放される。移植できることが、別の利点である。例えば、ＨＡＬ（２０２）によって、１つのロボット用に開発されたロボット制御ソフトウェア（１５７、１５８、１６０、１６２）の別のロボットへの移植が効率よく可能になる。一例では、ＨＡＬ（２０２）によって、同じナビゲーションアルゴリズムを、車輪付きロボット（１０４）から移植することと脚のついた人間型ロボット（１０６）において使用することとが、可能になる。

Description

本発明は、概ねロボット工学に関する。特に、本発明は、制御または振る舞いソフトウェアのの移植性を高めるハードウェア抽象層に関する。

ロボットは、多くの目的に使用可能である。例えば、ロボットは、反復仕事への工業上の応用、あるいは危険な環境における使用が可能であり、娯楽用玩具および同様のものとして構成可能である。ロボット用のハードウェアおよびロボット用の制御ソフトウェアは、常に複雑化している。ロボットは、構造体に取り付けられる種々のセンサおよびアクチュエータを含み得る。

既存のロボットおよびロボットソフトウェアの１つの欠点が、制御ソフトウェアに対する透明性の不足である。既存のロボットでは、ソフトウェアは、新しい各ロボット構成に念入りに適合される。例えば、典型的なロボットソフトウェアアーキテクチャでは、ロボットソフトウェアは、低レベルのデバイスドライバを介してロボットハードウェアと相互作用する。これらの低レベルのデバイスドライバは、対応のハードウェアデバイスに特有であり、低レベルのデバイスドライバは、ハードウェアデバイスの物理的性質について一般に送受信されるコマンドおよびフィードバック情報をサポートする。例えば、ドライブシステムモータ用の低レベルのデバイスドライバは、ロボットソフトウェアから、特定の毎分回転数など特定の速度でモータを回転させるコマンドを受信可能である。しかしながら、ドライブシステム全体は、モータだけではなく、同様にギヤおよび車輪も含み得る。したがって、歯車比および／または車輪の直径を変更する時、ソフトウェア開発者は、ロボットに所望の振る舞いをさせるために特定の毎分回転数を変更するようなロボットソフトウェアの変更を行わなければならない場合がある。

取るに足りないこれらのプログラム変更は、時間の浪費であり、ロボットのソフトウェアおよびハードウェア開発の両方に効率が悪い。本発明の実施形態は、好ましいことに、ロボットハードウェアからロボットソフトウェアを切り離し、先行技術の欠点を克服する。

本発明の実施形態は、ロボット用のハードウェア抽象化層（ＨＡＬ）を提供する方法および装置に関する。ＨＡＬは、ロボット制御ソフトウェアと、下層のロボットハードウェアおよび／またはハードウェア用のオペレーティングシステムとの間に、ソフトウェア層またはファームウェア層として存在し得る。ＨＡＬは、下層のハードウェアの集合体に比較的一様な抽象化を提供して、その結果、下層のロボットハードウェアが、知覚および制御ソフトウェア、すなわちロボット制御ソフトウェアにとって比較的透明となる。これによって、好ましいことに、ロボット制御ソフトウェアが、ロボットとは無関係に記述可能になる。

したがって、ロボット制御ソフトウェアの開発者は、退屈で重要でない仕事から解放される。さらに、ロボット制御ソフトウェアを移植できることが、別の利点である。例えば、ＨＡＬによって、１つのロボット用に開発されたロボット制御ソフトウェアの別のロボットへの移植が効率よく可能になる。一例では、ＨＡＬによって、同じナビゲーションアルゴリズムを、車輪付きロボットから移植することと脚のついた人間型ロボットにおいて使用することとが、可能になる。

本発明の一実施形態は、ロボットソフトウェアアーキテクチャ内にハードウェア抽象化層（ＨＡＬ）を含む。ＨＡＬは、以下のものを備える。より高レベルのソフトウェアに対するソフトウェアインターフェースであって、当該ソフトウェアインターフェースが、ロボットと環境との相互作用に関連した現実世界の測定値を伴って、より高レベルのロボットソフトウェアと通信するように構成されたソフトウェアインターフェースと、より高レベルのソフトウェアに、利用可能なリソースの表示を提供するリソース構成と、複数のリソースドライバであって、当該リソースドライバの少なくとも一部分が、リソース構成内の利用可能なリソースに相当し、リソースドライバの少なくとも２つが、機能性において部分的に重なっており、少なくとも２つのリソースドライバの１つのみが、利用可能な対応のリソースを有し、利用可能なリソース用のリソースドライバが、ロボット用の現実世界の測定値と、デバイス用のデバイスレベルの測定値との間の変換を行うように構成されている複数のリソースドライバと、より低レベルのデバイスドライバに対するインターフェースであって、当該より低レベルのデバイスドライバが、デバイスレベルにおいて対応のハードウェアと通信し、より低レベルのデバイスドライバに対するインターフェースが、リソースドライバを介して、より高レベルのソフトウェアと通信する、より低レベルのデバイスドライバに対するインターフェースとを、ＨＡＬは備える。

本発明の一実施形態は、ロボットに、ロボット制御ソフトウェアのハードウェア抽象化を提供する方法に関する。本方法は、以下のステップを含み得る。対応のハードウェアがロボットに存在しないリソースドライバを含む、ロボット用の複数のリソースドライバを設けるステップと、ロボット用のハードウェア構成を検出するステップと、検出されたハードウェア構成に基づき、ロボットにおいて利用可能なリソースを自動的に検出するステップと、ロボット制御ソフトウェアから、１つのタイプのリソースを使用する要求を受信するステップと、ロボット制御ソフトウェアにより要求されたタイプのリソースに相当するリソースを、利用可能なリソースから自動的に選択するステップと、選択されたリソースの使用に関連するとともに、ロボットに関連する測定単位で提供される第１の情報を前記ロボット制御ソフトウェアと交換するステップと、第２の情報であって、ロボット制御ソフトウェアによる使用要求に関連し、対応のデバイスに関連する測定単位で提供され、第１の情報とは異なる、リソースに対応する第２の情報を、より低レベルのデバイスドライバと交換するステップと、ロボットの検出された構成に基づき、第１の情報と第２の情報との間において変換を行うステップとを、本方法は含む。

一実施形態は、コンピュータが読み出し可能な媒体を含み、この媒体は、ハードウェア抽象化を行う方法を実行するための、コンピュータが実行可能な命令を有する。コンピュータが読み出し可能な媒体は、幅広い種々の媒体に相当し得る。すなわち、これらに限定はしないが、ハードディスク、フロッピーディスク（登録商標）、および他の磁気ディスク、ＲＡＭ、ＲＯＭ、フラッシュメモリ、メモリカード、および他の固体回路記憶装置、光ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭおよび同様のものに相当し得る。

以下に概要を示す図面を参照して、本発明のこれらのおよび他の特徴を説明する。これらの図面および関連の説明は、本発明の好ましい実施形態を示すために提供するものであって、本発明の範囲を限定する意図はない。

いくつかの好ましい実施形態に関して本発明を説明していくが、ここに述べる利点および特徴の全てを提供するとは限らない実施形態を含めて、当業者に明らかな他の実施形態もまた、本発明の範囲内にある。したがって、本発明の範囲は、添付の特許請求の範囲を参照することによってのみ確定される。

図１Ａに異なるタイプのロボットの例を示す。ロボットは、非常に広範囲の種々の方法で使用可能であり、かつ非常に広範囲の種々の構成に対応可能である。例えば、ある場合には、第１のロボット１０２が、病院内における医療用品の自動搬送装置である。第２のロボット１０４が研究と趣味用のロボットである場合がある。第３のロボット１０６が人型ロボットである場合がある。第４のロボット１０８が娯楽目的の玩具である場合がある。ロボット用の多くの他の構成が可能であることを、当業者は理解するだろう。

構成を変えたロボットでは、ハードウェアが実質的に異なる可能性があることが理解されるだろう。例えば、第１のロボット１０２および第２のロボット１０４は、車輪で移動し、また、第３のロボット１０６および第４のロボット１０８は、足を使用して移動する。下層のハードウェアが根本的に異なる場合でさえ、本発明の実施形態によって、好ましいことに、１台のロボットのために開発されたソフトウェアを別のロボットに簡便に移植可能となる。さらに、本発明の実施形態によって、有利なことには、車輪の直径の変更など比較的軽微な変更をロボットに行うときに、ロボットを制御するために同じソフトウェアを使用可能になる。

本発明の実施形態は、有利なことには、ロボットソフトウェアの開発をハードウェアと無関係に行うことを可能にするハードウェア抽象化層（ＨＡＬ）を提供する。ＨＡＬは、ロボットのソフトウェアとハードウェアドライバとの間のソフトウェアアーキテクチャ内の層に存在することが好ましい。ＨＡＬによって、１台のロボットのために開発されたロボットソフトウェアを別のロボットに効率的に移植可能となる。ＨＡＬによって、さらに、既存のロボットの再構成を、ロボットソフトウェアを修正する必要なしに行うことが可能となる。例えば、センサまたはアクチュエータを変更可能である。ＨＡＬの使用によって、ロボットソフトウェアおよびハードウェアの迅速な開発および進展が促進される。

図１Ｂは、通常のロボット用のソフトウェアアーキテクチャを示す。ロボットソフトウェア１５０が、センサ１５２からの入力を処理し、アクチュエータ１５４に制御出力を与える。図１Ｂに示したソフトウェアアーキテクチャにおいては、ロボットソフトウェア１５０は、高レベルのプランナ１５７あるいはアプリケーション１５８を含んでいる。高レベルのプランナ１５７は、記号形式で特定された目標を扱う。高レベルのプランナ１５７は、それらの目標をもっともよく達成する方法を決定するための固有の論理を有する。例えば、高レベルのプランナは、ミッションプランニング、サーチおよびレスキュー、ならびにサービス指向型タスクなどの種々のロボットアプリケーションに使用される。アプリケーション１５８は、ロボット制御用のソフトウェアプログラムまたはアルゴリズムに相当し得る。高レベルのプランナ１５７またはアプリケーション１５８は、振る舞いまたはタスクとして示したより小さなソフトウエアコンポーネントを調整することによって、それらの目標を達成し、この振る舞いまたはタスクは、種々のロボットオペレーションをカプセル化したものである。振る舞いの一例が、「ロボットの前のどんな障害物も回避する」ことである。タスクの一例が、「内部地図の特定の場所へ行く」ことである。「会議室に行く」という目標を与えられた高レベルのプランナ１５７が、「回避する」という振る舞いの使用と、「特定の場所へ行く」というタスクの使用とを調整して、内部地図において会議室の位置を確認し、障害物に衝突せずにそこへ移動することを可能にする。これらの振る舞いおよびタスクのコンポーネントは、中間の振る舞い層１６０および／またはタスク層１６２を形成し得る。振る舞い層１６０および／またはタスク層１６２は、次いで、低レベルのデバイスドライバ１５６を介して、ロボットのハードウェアと、すなわち、センサ１５２および／またはアクチュエータ１５４と相互作用する。

低レベルのデバイスドライバ１５６は、対応のハードウェアデバイスに特有のものである。低レベルのデバイスドライバ１５６は、一般に、与えられたコマンドをサポートし、対応のデバイスの物理的特性に関してフィードバック情報を提供する。例えば、モータ用ドライバが、一定の速度でモータを回転させるコマンドをサポートするように構成可能であり、それは、毎分ある回転数（RPM）内に指定可能である。モータがロボット用ドライブシステムにおいて使用される場合、振る舞い層１６０および／またはタスク層１６２は、対応の低レベルのデバイスドライバにモータ回転に関してコマンドを与える。これは、比較的効率が悪く不便である。

ロボットの動きは、モータではなくロボットに適用可能な寸法単位でより効率的に記述可能である。例えば、本発明の実施形態によって用いられ、より便利な表記法では、センチメートルなどの直接的な距離単位、またはセンチメートル毎秒などの速度単位を用いて、ロボットの移動を記述する。この直接的な表記法は、モータの回転速度などの間接的な表記法よりもはるかに便利に用いることができる。

これとは対照的に、従来のロボットのソフトウェア１５０が低レベルのデバイスドライバ１５６と相互作用するように構成されている場合は、振る舞い層１６０および／またはタスク層１６２は、これらの間接的な単位の数値を特定のロボットのドライブシステム特性へ変換する。例えば、従来のロボットのソフトウェアを使用するソフトウェア開発者が、特定の移動が行われるようにするために、振る舞い層１６０および／またはタスク層１６２を、特定のロボットにおける特定の歯車比および車輪サイズに適合させるのは不便である。車輪サイズの変更などの、変更をロボットに行う場合、これらのカスタマイズを再調整する必要があるのは不便である。さらに、特定のロボットに適合した振る舞い層１６０および／またはタスク層１６２は、一般に、異なる構成のロボットへは移植不可能である。

図２に、ハードウェア抽象化層（ＨＡＬ）２０２を備えた、本発明の実施形態に係るソフトウェアアーキテクチャ２００を示す。ＨＡＬ２０２は、より高レベルのロボット振る舞いソフトウェアに中間層インターフェースを提供することが好ましく、それによって、下層のハードウェアの特定の詳細ではなく実際の寸法に基づいて、より高レベルのロボット振る舞いソフトウェアを開発可能となる。これによって、ソフトウェア開発者が、ロボットのアプリケーションをプログラムする時に、下層のロボットハードウェアデバイスの細密な詳細を補償するという横道に逸れることなく、現実のコンセプトを用いて作業可能となることが好ましい。一実施形態では、ＨＡＬ２０２はまた、異なるロボットハードウェアプラットフォームにおいて変更を行うことなく、ＨＡＬ２０２の上に書かれたロボットの振る舞いソフトウェアを作動させることができる。

ソフトウェアアーキテクチャ２００もまた、種々のプラットフォームにロード可能である。例えば、ここに示したソフトウェアアーキテクチャ２００は、Ｌｉｎｕｘ、Ｕｎｉｘ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）Ａｐｐｌｅ（登録商標）、ＭａｃＯＳ（登録商標）および同様のものなどの広範囲の種々のオペレーティングシステムに実装可能である。広範囲の種々のコンピュータハードウェアはまた、ロボット用のソフトウェアアーキテクチャ２００のホストとして機能し得る。例えば、コンピューターハードウェアは、パーソナルコンピュータ、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）、シングルボードコンピュータおよび同様のものである。コンピュータハードウェアを、ロボットに対して局在させ得るかまたは遠隔配置させ得ることが理解される。

図２が示すように、ＨＡＬ２０２は、低レベルのデバイスドライバ１５６用の層と振る舞いロボットソフトウェアとの間のソフトウェア層内に存在する。図３、図４、図６、図７および図８に関してＨＡＬ２０２の一実施形態のさらなる詳細を後述する。一実施形態では、低レベルのデバイスドライバ層は、下層のオペレーティングシステム（ＯＳ）内、例えば Windows XP（登録商標）の層内に存在する。ロボット用の比較的一様な制御インターフェースを提供することに加えて、ＨＡＬ２０２は、ロボットのセンサとの相互作用のための、比較的一様なインターフェースを提供する。しかしながら、自律型ロボットについては、ロボットにおけるセンサの位置、センサデータの標本化速度、および他のセンサ特性などの他の情報もまた、センサデータを用いて自律的な決定および動作を行うために必要な場合がある。ＨＡＬ２０２の実施形態は、ロボットシステム内におけるセンサのこれらの特性をカプセル化するための１セットの技術をさらに含み得ることが好ましく、下層のロボットハードウェアの特定の特性に好ましくは依存しない方法でデータにアクセスを行うための比較的一様なインターフェースを提供する。

ＨＡＬ２０２の一実施形態は、次の利点の少なくとも１つを提供する。
(I) ハードウェアデバイスを抽象化するための柔軟性のあるフレームワークを提供すること、
(II) プラットフォームの中立性を提供すること、
(III) ロボットハードウェアのリアルタイム制御のためのシステムレベルの効率のよさを提供すること。

利点(I)が、ハードウェアデバイスを抽象化するための柔軟性のあるフレームワークを提供し、図４に関して以下にさらに詳細に説明される。（II）プラットフォームの中立性と、(III)システムレベルの効率性とを達成するために、ＨＡＬ２０２の一実施形態は、Ｃ＋＋プログラミング言語を用いて実装され得る。Ｃ＋＋プログラミング言語は、システムレベルの効率をよくすることで、種々のプラットフォームに比較的幅広く標準化されたサポートを提供する。さらに、Ｃ＋＋プログラミング言語がオブジェクト指向方法をサポートすることによって、ソフトウェア設計が相対的にすぐれた構成になる。広範囲の種々のプログラミング言語を使用可能であることが、当業者に理解されるだろう。別の実施形態では、Ｊａｖａ（登録商標）またはＬｉｓｐが使用される。

図３は、ＨＡＬ２０２内におけるハードウェアデバイスの抽象化を例示し、リソースドライバ３０２とリソース３０４との間の関係を例示している。ＨＡＬ２０２は、低レベルのハードウェアデバイス３０６からリソース３０４を通り低レベルのデバイスドライバ１５６までの通信路を提供する。リソース３０４が、論理的構成に相当し得、この論理的構成は、ロボットのオペレーションおよび／または感覚フィードバックの別個のセットをカプセル化または代表してハードウェアデバイス３０６を制御する。低レベルのデバイスドライバ１５６は、所与のリソース３０４に関連したハードウェアデバイス３０６を制御する、比較的低レベルのソフトウェアに相当し得る。ＨＡＬ２０２は、適切なリソース３０４に対応するリソースドライバ３０２を介してハードウェアデバイス３０６にアクセスする。

リソース３０４によって抽象化されたハードウェアデバイス３０６は、コマンドを受信しまたはセンサデータを提供する、モータなどの能動的な構成部品を含み得、かつリソース３０４と通信はしていないが、ロボットと現実世界との相互作用に影響を与える、ギヤおよび車輪などの受動的な構成部品を含み得る。ハードウェア抽象化には、比較的単純なものから比較的複雑なものまでいろいろある。ハードウェア抽象化の比較的単純な例が、単一のモータアセンブリである。例えば、モータのドライブシステムの抽象化は、車輪の直径と歯車比とを格納し用いて、モータの回転に起因する動きを計算することを含み得る。中間的な複雑さの例では、IRSensorなどのハードウェアデバイス３０６の抽象化は、ハードウェアデバイス３０６から読み取りを行い、その読み取り値（例えば、ボルト）をセンチメートルなどの適切な寸法単位に変換することによって行われる。差動ドライブシステムなどのコンポーネントの集合体が、ハードウェアデバイス３０６の比較的複雑な例である。差動ドライブシステムの抽象化の一例では、２つのモータの速度および加速度を適切に調整して、望ましい線速度および角速度を達成する。

リソース３０４は、物理デバイス、物理的な結合ポイント、音声認識ソフトウェアなどのソフトウェアリソース、およびロボット制御ソフトウェアが外部環境と相互作用する他の方法に相当し得る。リソース３０４は、センサおよびアクチュエータ、ネットワークインターフェース、マイクロホンおよび音声認識システム、ならびにバッテリ充電残量にさえ相当する場合がある。リソース３０４は、物理デバイス、物理デバイスの組み合わせ、ソフトウェアオペレーション、またはハードウェアオペレーションに相当するかまたはそれらになり得るが、リソースドライバ３０２は、図３に示すように、リソース３０４のソフトウェア実装部分に相当し得る。立体面を描画するソフトウェアまたは音声認識ソフトウェアなどの、外部のソフトウェアアプリケーションに相当するリソース３０４に対して、リソースドライバ３０２は、外部のソフトウェアリソースに標準的なアプリケーションプログラムインターフェース（ＡＰＩ）を提示する中間抽象化層に相当し得る。

別の例においては、ドライブシステム用リソース３０４によって、対応のロボットの動きを、物理的な距離単位を用いてセンチメートル毎秒などの速度および加速度により指定することができる。これによって、ロボットが２つのモータを有する差動ドライブシステムを使用しているか、または機械の脚を使用して動くかを考慮せずに、ロボットの振る舞いソフトウェアの開発を行うことが可能になることが好ましい。

ハードウェアデバイス３０６用のリソース３０４は、ハードウェアデバイスの一部分、ハードウェアデバイス全体、またはハードウェアデバイスの組み合わせを抽象化したものにすることができる。例えば、モータドライブシステムでは、リソース３０４は、車輪、歯車およびモータを抽象化することができる。さらに、単一のハードウェアデバイス３０６またはその一部分が、１つまたはそれ以上のリソース３０４によって抽出可能である。例えば、モータドライブシステム用の抽象化において用いられるのと同じ車輪および歯車を走行距離計の位置フィードバック用の抽象化に含ませ得る。

図４に、ＨＡＬ２０２のさらなる詳細を示す。ＨＡＬ２０２は、リソースコンテナ４０２を含み、それは、１つまたはそれ以上のリソースドライバ３０２、４０４、４０６を含んでいる。
リソースコンテナ４０２内のリソースドライバの数を非常に広範囲に変化させ得ることが理解されるだろう。リソース構成４０８が、リソースドライバ３０２、４０４、４０６を作り出すために使用される情報を含み得る。リソース構成４０８は、持続性のあるデータ記憶装置４１０に格納される。リソース構成４０８の一実施形態を図６に関して以下にさらに詳細に説明する。

ＨＡＬ２０２の利点（I）、すなわち、ハードウェアデバイスを抽象化するための柔軟性のあるフレームワークを提供することは、図２に関して簡単に前述した。一実施形態においては、ＨＡＬ２０２の利点(I)は、以下の利点の少なくとも一部分を実行することによって、実施可能であることが好ましい。

Ｉ(a) XMLなどの、比較的汎用性があり移植可能なデバイスの記述フォーマットで、ＨＡＬ２０２に利用可能なリソースを記述するリソース構成４０８を設けること、
I (b)リソース３０４により抽象化したデバイス３０６のライフサイクルを管理すること、
I (c) 現実世界の概念および単位に基づいた種々のロボットオペレーション用のソフトウェアインターフェースの拡張可能なセットを提供すること、
I (d) リソース３０４からより高レベルのソフトウェアへのアクセスを提供すること、および
I (e)デバイス３０６にアクセスするための高信頼性機構を提供すること。

図５に、論理デバイスバスによる処理装置へのハードウェアデバイスの接続を示す。特定のロボットプラットフォームにおいて利用可能なリソース３０４は、ＨＡＬ２０２に記述すべきであり、その結果、ＨＡＬ２０２が、適切にリソース３０４を抽象化可能であるとともに、より高レベルのソフトウェアによる使用のために、抽象化したリソース３０４を利用可能にすることができる。一実施形態では、リソース３０４は、リソース構成４０８と呼ばれる木のような階層データ構造でＨＡＬ２０２に記述される。リソース構成４０８の構成は、ロボットハードウェアデバイスの、処理ハードウェア５０２への現実世界の接続を模倣し得る。

種々のハードウェアデバイスは、論理デバイスバスを介してロボットの処理コンポーネント５０２に接続可能である。論理デバイスバスは、ハードウェアデータバスを含み得、それは、例えばシリアルポート、パラレルポート、ＰＣＩバス、ＵＳＢ、ファイアワイヤなどの広範囲の種々のハードウェアデータバスに相当し得る。論理デバイスバスは、さらに、特別のプロトコルまたはドライバを含む論理的な構成に相当し、この特別のプロトコルまたはドライバは、ハードウェアデータバス上において通信するロボットデバイスと共に使用される。

例えば、ロボットデバイスＡ３０６およびハードウェアデバイスＢ５０４が、第１のＵＳＢポートへ接続されるとともに、ヒューマンインターフェースドライバを使用し、それと同時に、ハードウェアデバイスＣ５０６がまた、ＵＳＢポートへ接続されるが、仮想ＣＯＭポートドライバを使用している。ハードウェアデバイスＡ３０６およびハードウェアデバイスＢ５０４は、第１の論理データバス５１０に接続され、この第１の論理データバス５１０は、ＵＳＢハードウェアポートとヒューマンインターフェースドライバとの集合体である。それとは対照的に、ハードウェアデバイスＣ５０６は、第２の論理データバス５１２に接続され、この第２の論理データバス５１２は、ＵＳＢハードウェアポートと仮想ＣＯＭポートドライバとの集合体である。図５は、さらに、第２の論理データバス５１２に接続されたハードウェアデバイスＤ５０８を例示している。論理データバスの数を非常に広範囲に変更可能であることが理解されるだろう。

１つまたはそれ以上のハードウェアデバイス３０６、５０４、５０６、５０８を単一の論理デバイスバスに取り付け可能であるが、単一のデバイスを、１つを越える論理デバイスバスに取り付けるべきではないことが理解されるだろう。複数のハードウェアデバイス３０６、５０４、５０６、５０８は、集合させてデバイスグループにすることができる。

図６に、リソース構成４０８の一実施形態のさらなる詳細を示す。リソース構成４０８は、１つまたはそれ以上のデバイスグループ構成と、１つまたはそれ以上のデバイスバス構成とを含み得る。デバイスグループ構成は、ハードウェアデバイスへの１つまたはそれ以上の参照を含み得る。例えば、図６は、第１のデバイス参照６０４および第２のデバイス参照６０６を有する第１のデバイスグループ構成６０２を示している。

第１のデバイスグループ構成６０２は、図３に関して前述したリソースドライバ３０２などの対応のリソースドライバの実装を使用し、このリソースドライバは、ハードウェアデバイスに対応する第１のデバイスグループ構成６０２がどのように相互作用するかを管理している。モータドライブシステム用のリソースドライバが、デバイスグループ構成を実装したリソースドライバの一例であって、その結果、モータドライブシステム用のリソースドライバが、１つまたはそれ以上のモータ、ギヤおよび車輪を集合化させることができる。一実施形態では、ロボットへのデバイスのマウント方法および場所についての物理的性質は、デバイスの記述自体の一部分であり、すなわち、構造体およびデバイスは、ＨＡＬ２０２のリソース構成内に記述されており、特定のデバイスのマウント方法および場所の物理的性質は、デバイスグループ構成内においてデバイスと集合化されない。ＸＭＬフォーマットの、IRSensor用のデバイス構成の一例を以下に示す。
<Device id="IR＿tne"type="Evolution.USBIrSensor">
<Parameter name="address"value="0"/>
<Parameter name="link"value="origin"/>
<Parameter name="x"value="-20"/>
<Parameter name="y"value="-10"/>
<Parameter name="z"value="22"/>
<Parameter name="roll"value="0">
<Parameter name="pitch"value="0">
<Parameter name="yaw"value="-pi/4"/>
</Device>
上に示した例においては、ｉｄ属性は、一意的にＩＲデバイスを識別する。型属性は、デバイスがUSB IRSensorであることを示す。アドレス値は、論理デバイスバス上のアドレスを示し、このアドレスに、このデバイスを見つけることができる。リンク値は、このデバイスがロボットへいかにアタッチされるかを示す。ｘ、ｙ、およびｚの変数は、ロボットにおけるデバイスの位置に対応する。ロール、ピッチおよびヨー変数は、ロボットにおけるデバイスの方向に対応する。

図５に関して説明した利用可能な論理デバイスバスもまた、リソース構成４０８内に記述すべきである。論理デバイスバスの記述が、図６に示したデバイスバス構成に相当する。例えば、第１のデバイスバス構成６０８が、第１の論理データバス５１０に対応し、第２のデバイスバス構成６１０が、第２の論理データバス５１２に対応し得る。

デバイスバス構成は、ソフトウェア内の論理デバイスバスを活性化させ利用するために用いられる種々の情報を含むべきである。例えば、論理デバイスバスがシリアルプロトコルの抽象である場合、対応のデバイスバス構成は、ボーレート、パリティなどの種々の関連のあるシリアル通信パラメータを含むべきである。

対応のデバイス構成によって、ハードウェアデバイスを特定し定義することができる。例えば、図５に示したハードウェアデバイスＡ３０６、ハードウェアデバイスＢ５０４、ハードウェアデバイスＣ５０６、およびハードウェアデバイスＤ５０８は、それぞれ、第１のデバイス構成６１２、第２のデバイス構成６１４、第３のデバイス構成６１６、および第４のデバイス構成６１８によって、特定し定義することができる。デバイス構成６１２、６１４、６１６、６１８は、長さ、幅、量などの、デバイスの物理的性質に関係する情報を含み得、適宜、ロボットにおけるデバイスの位置を含み、方向を含み得る。

第１のハードウェアデバイス３０６がカメラに相当する例においては、ロボットにおけるカメラの位置および方向が、有用となり得、対応のデバイス構成６１２内に含まれるべきである。しかしながら、そのような位置および方向の情報は、テキスト音声合成装置などの別のロボット装置には適切ではない場合がある。

１つまたはそれ以上のデバイス構成が、対応のロボットデバイスが接続される論理デバイスバスの論理デバイスバス構成の下でグループ化される。第１のデバイスバス構成６０８などのデバイス構成が、ソフトウェア内の１つまたはそれ以上の対応のハードウェアデバイス３０６、５０４を活性化させ利用するために用いられる、デバイスパラメータを含めた情報を含むことが好ましい。例えば、ハードウェアデバイスＢ５０４が赤外線（ＩＲ）センサに相当する場合、第１の論理データバス５１０における赤外線センサのアドレス、センサ用較正データ、センサの最小・最大範囲などの情報が、特定されるべきである。別の例では、リソース３０４が、ハードウェアデバイスＣ５０６などの１つのロボットデバイスのためのみの抽象化を行う場合、対応のデバイス構成６１６は、ハードウェアデバイスＣ５０６を適切に抽象化するためのリソース３０４用のデータを全て特定すべきであり、それには、現実世界の単位など、デバイスの単位からより扱いやすい単位にデバイスデータを変換するために使用する換算因子が含まれている。

第１のデバイスバス構成６０８などの各デバイスバス構成、第１のデバイス構成６１２などの各デバイス構成、および第１のデバイスグループ構成６０２などの各デバイスグループ構成が、一意的識別子である各（ｉｄ）ストリングにより識別可能である。ＨＡＬ２０２の一実施形態が、この一意的ｉｄを使用して、異なるリソース同士の区別を効率的に行う。

図７は、リソースドライバオブジェクトが、IResourceDriverおよび１つまたはそれ以上のIResourceインターフェースからいかに導出されるかを示す。選択されたリソース３０４のためにリソースインターフェース７０２を取得するには、ＨＡＬ２０２の一実施形態では、選択されたリソース３０４のｉｄを使用することにより、リソースコンテナ４０２からの「obtain＿interface」メソッドなどのメソッドを呼び出す。

ここで図６に戻ると、２つのIRSensorがロボットに装着された１つの例においては、第１のIRSensor用の第１のデバイス構成６１２は、「ＩＲ１」というｉｄを有し、第２のIRSensor用の第２のデバイス構成６１４は、「ＩＲ２」というｉｄを有することができる。これらのセンサは、両方とも距離センサであり、したがって、これらのセンサを使用するロボットのソフトウェアについて、ＨＡＬ２０２は、リソースコンテナ４０２からIRangeSensorを検索して、その結果、適切なｉｄ、すなわち第１のセンサ用の「ＩＲ１」、および第２のセンサ用の「ＩＲ２」が、リソースコンテナ４０２の「obtain＿interface」メソッドという第２のパラメータ(resource＿id)として受け渡される。

リソース３０４が複数のデバイスを抽象化する時、それは、図６に関して前述したようにデバイスグループ構成として記述可能である。第１のデバイスグループ構成６０２などのデバイスグループ構成が、デバイスグループ構成内に、ハードウェアデバイスのデバイス参照への参照を含み得る。例えば、第１のデバイスグループ構成は、第１のデバイス参照６０４および第２のデバイス参照６０６を含んでいる。

一実施形態では、第１のデバイス参照６０４などのデバイス参照は、第１のデバイス参照６０４が参照する第２のデバイス構成６１４などのデバイス構成を一意的に識別するために十分なデータだけを含んでいる。一意的識別子は、リソース構成４０８を実装する、リレーショナルデータベース内または拡張可能なマークアップ言語（ＸＭＬ）の実装内の識別子に相当する場合があり、第１のデバイス参照６０４は、それが参照する第２のデバイス構成６１４のｉｄを含むＸＭＬタグに相当し得る。第１のデバイスグループ構成６０２の第１のデバイス参照６０４および第２のデバイス参照６０６などの、デバイスグループ構成のデバイス参照が、デバイスバス構成を変更する１つまたはそれ以上のデバイス構成の場所を示すことができる。

一実施形態では、ハードウェアデバイスＢ５０４およびハードウェアデバイスＤ５０８などの複数のハードウェアデバイスが、異なる論理デバイスバス５１０、５１２にアタッチされた時でさえ、リソースにより抽象化可能である。別個の論理デバイスバスと通信するハードウェアデバイスを含み得るハードウェアデバイスの一グループを抽象化可能であることによって、デバイスグループ構成の数が増加されることが好ましく、それは、ＨＡＬ２０２によって可能でありかつサポートされ得る。一実施形態では、デバイスグループ内のデバイスの集合体が、グループ用の別個のリソースドライバ３０２に相当する。

リソース構成４０８はまた、ロボット用の構造情報を格納可能である。一実施形態では、構造情報は、寸法構成６３０内に保持され、１つまたはそれ以上の形状構成６３２を含んでいる。各形状構成６３２は、ロボットの剛性構造部材についての情報を含み得る。一例においては、この情報は、以下の少なくとも１つの情報などの情報を保持するように構成され得る。

ｚ軸の正方向を上向きにとりかつｘ軸の正方向を前向きにとった右手座標を用いてｘ、ｙ、ｚ座標から見た、ロボットの重心に対する剛性構造部材の位置、
ｘ、ｙおよびｚ軸に沿った寸法で表した、構造部材のサイズ、
ロール、ピッチおよびヨーで表した、構造部材の方向、および
剛性構造部材と関連したリンクのｉｄ。

形状構成６３２に加えて、リソース構成４０８は、リンクに関連するジョイントを記述したリンク構成６３４を含んでいる。各リンク構成６３４は、１つの剛性構造部材を代表可能であり、一意的ｉｄを有している。一実施形態では、リンク構成６３４は、デナビット−ハルテンベルグパラメータを用いて、剛性構造部材を他の剛性構造部材に結合するジョイントに関する情報を含んでいる。

リソース構造４０８の記憶フォーマットは、非常に広範囲に変化させ得る。一実施形態が、ＸＭＬファイルを用いて実装されることが好ましいが、適切なデバイス情報が検索可能なフォーマットで記憶されていれば、リソース構成４０８のフォーマットが実質的にどんなものであってもよいことを、当業者は理解するだろう。リソース構成４０８はまた、ＨＡＬ２０２に望ましい検索のために、フラッシュメモリー内またはハードドライブ内などの、アクセス可能な持続性のあるデータ記憶装置４１０内に記憶されるべきである。

リソース構成４０８は、リソース構成パーサにより検索可能である。一実施形態では、リソース構成パーサは、ソフトウェアモジュールに相当し得、このソフトウェアモジュールは、リソース構成４０８内に記憶されたデバイス構成を構文解析して、ＨＡＬ２０２により内部で使用可能なフォーマットにする役割を担う。解析されたリソース構成の情報は、リソースコンテナ４０２に与えられ、そこで、記憶されＨＡＬ２０２により用いられる。一実施形態では、標準的なＸＭＬ構文解析技術を用いて、リソース構成パーサにより、リソース構成４０８のＸＭＬベースの実装の構文解析を行うことができる。リソース構成４０８によって、利点I(a)を得られる。比較的汎用性があり移植可能なデバイス記述フォーマットで、ＨＡＬ２０２に利用可能なリソースを記述するリソース構成４０８が得られる。

リソースコンテナ４０２は、リソース構造パーサを通じて、適切なロボットプラットホームにおいて利用可能なリソース４０８に関する情報を得る。一実施形態では、各リソース３０４については、リソースドライバ３０２があり、このリソースドライバ３０２は、第１のデバイス構成６１２などのデバイス構成によって、または第１のデバイスグループ構成６０２などのデバイスグループ構成によって記述される、１つまたはそれ以上のデバイスを抽象化することができる。

リソースコンテナ４０２は、リソース構成４０８内に各デバイス構成またはデバイスグループ構成に対応するリソースドライバ３０２を作成可能である。一実施形態では、作成されたリソースドライバ３０２への参照が、ドライバテーブル内に記憶される。リソースコンテナ４０２はまた、各リソースドライバ３０２の従属リストを計算可能である。従属リストは、適切な場合に、活性化順にリソースドライバ３０２に先行させるべきである他のリソースドライバ３０２のリストを含み得る。活性化順は、ハードウェアデバイスＡ３０６またはハードウェアデバイスＢ５０４などの１つを越えるハードウェアデバイスを抽象化する複合リソースドライバが存在する場合には重要になる。

一実施形態では、個別の各ハードウェアデバイス３０６、５０４、５０６、５０８用のリソースドライバ３０２の活性化は、複合リソースドライバ３０２を活性化させる前に行うべきである。リソースコンテナ４０２は、１つまたはそれ以上のリソースドライバの従属リストを用いて、リソースドライバ３０２を活性化させるべき順番を決定可能である。一度十分な活性化の順番が決定されると、リソースコンテナ４０２は、活性化順に適切なリソースドライバを活性化させることができる。リソースの活性化および非活性化をサポートするために、ＨＡＬ２０２は、IResourceDriverインターフェース７０６を含み得る。

図７に示すように、IResourceDriverインターフェース７０６は、「activate」および「deactivate」仮想メソッドを含んでいる。リソースドライバ３０２の実装では、IResourceDriverインターフェース７０６からの導出と、「activate」および「deactivate」仮想メソッドの実装とが行われる。「activate」方法では、リソースドライバ３０２をソフトウェア内において使用する準備を整えるために用いられるタスクを実行する。「deactivate」方法では、リソースドライバ３０２により使用されたデータをクリアし、リソースドライバ３０２により抽象化された対応のハードウェアデバイスを適切にシャットダウンする。

リソースの活性化シーケンスが決定されると、リソースコンテナ４０２は、活性化シーケンスに従って各リソースドライバ３０２の「activate」メソッドを呼び出す。一実施形態では、非活性化シーケンスは、活性化シーケンスの逆である。例えば、ソフトウェアが終了する時、リソースコンテナ４０２は、活性化順と逆の順番の「deactivate」メソッドを呼び出すことにより、リソースドライバ３０２を非活性化させる。リソースドライバ３０２の「activate」および「deactivate」メソッド、およびリソースコンテナ４０２によるそれらの使用方法は、利点I(b)を達成する。

ＨＡＬ２０２の利点I(c)では、現実世界の概念および単位に基づく種々のロボットオペレーション用のソフトウェアインターフェースの拡張可能なセットを得られる。リソースインターフェースのこの拡張可能なセットは、本明細書ではリソースインターフェース７０２と言い、ＨＡＬ２０２のリソースドライバ３０２により実装可能である。リソースドライバ３０２が、１つまたはそれ以上のリソースインターフェース７０２を実装することにより、ロボットオペレーションを抽象化しカプセル化する。リソースインターフェース７０２は、ベースのＩResource７０４のインターフェース定義から導出されるとともに、１つのタイプのロボットオペレーションまたはデバイスをカプセル化することができる。図７に示したように、リソースドライバ３０２のオブジェクトが、IResourceDriverのベースクラス７０６、およびそれが実装を行うリソースインターフェース７０２のベースクラスの両方から導出されるのが一般的である。

リソースインターフェース７０２が、１セットのロボットオペレーションを行う関数呼び出し（メソッド）のリストに相当し得る。より高レベルのソフトウェアが、リソースドライバ３０２と相互作用するとともに、最終的に下層にあるハードウェアデバイスと相互作用し、この最終的な相互作用は、リソースドライバの１つまたは複数のリソースインターフェースへの参照を受け取りかつリソースインターフェースのメソッドを呼び出すことによって行われる。これらのメソッドおよびパラメータ、ならびに結果は、下層にあるハードウェアまたは実装に関する仮定なしに、現実世界の言葉で扱いやすく確定することができる。例えば、IDriveSystemリソースインターフェース（コードブロック９に関連してさらに詳細に後述）が、「move＿and＿turn」などのメソッドを含み得、このメソッドは、ロボットの動きを制御可能に構成することができ、この制御は、速度にはセンチメートル毎秒（ｃｍ／秒）および加速度にはｃｍ／秒^２などの標準単位を用いて、所望の線速度および角速度、ならびに対応の加速度を指定することによって、行われる。別の例が、IRangeSensorリソースであり、「get＿distance＿reading」メソッドを提供するように構成可能であって、このメソッドでは、距離センサからセンチメートルなどの扱いやすい単位による距離の読み取り値を返す。サンプルコードブロックの説明の後に、リソースインターフェースのサンプルリストおよび対応のメソッドを説明する。

リソースインターフェース７０２の拡張性をサポートするために、ＨＡＬ２０２は、リソースインターフェース７０２を実装するコードが、動的にロード可能な共有ライブラリ内に存在することを明示可能である。この構成は、Windows（登録商標）内のダイナミックリンクライブラリ、および他のプラットフォームにおける共有ライブラリまたは共有オブジェクトとして知られており、最新のオペレーティングシステムによりサポートされ、以下これを「共有ライブラリ」と呼ぶ。リソースドライバの実装を含む共有ライブラリの名前および場所は、リソース構成４０８の一部分として指定されるべきである。したがって、同じリソースドライバ３０２によって抽象化されたタスクを実行する別のハードウェア用の別の実装が、別の共有ライブラリ内において実行可能であり、使用中のハードウェアに適切なライブラリが、ロードされる。これによって、新しい実装をフレームワークに容易に追加可能となる。さらに、新しいリソースドライバの定義を第三者が行うことさえでき、それらの実装は、実行時にロボットシステムにロードされる新しい共有ライブラリ内に記憶することができる。

リソースドライバ３０２を含む共有ライブラリを識別した後に、ＨＡＬ２０２は、リソースドライバ３０２をインスタンス化することができる。しかしながら、リソースドライバ３０２がインスタンス化された時共有ライブラリのロードが行われることを確認することが好ましい。一実施形態では、共有ライブラリは、実行可能なものへ直接リンクされているが、それは不都合でかつ非実用的な場合がある。リソースドライバのｉｄおよびその共有ライブラリは、動的ロードを可能にするある方法で通知されることが好ましい。一実施形態では、ＨＡＬ２０２は、Ｃ＋＋マクロのDECLARE＿RESOURCEを与え、それは、リソースドライバ３０２のコード内に入れられて、そのｉｄおよび共有ライブラリの名前が通知される。DECLARE＿RESOURCEマクロは、リソースドライバを作成するために、１つまたはそれ以上のメソッドの宣言、およびＨＡＬ２０２によって使用されるデータ項目を含み得る。DECLARE＿RESOURCEマクロによって、リソースドライバインプリメンタが、これらの標準メソッドおよびデータメンバの入力を省略できることが好ましい。例えば、これらのメソッドには、「create＿resource」メソッドと「get＿driver＿id」メソッドとを含み得、ＨＡＬ２０２が、「create＿resource」メソッドを呼び出してリソースドライバをインスタンス化可能であり、「get＿driver＿id」メソッドを呼び出してリソースドライバのｉｄを検索可能である。DECLARE＿RESOURCEマクロ内において宣言されたデータメンバは、リソースドライバのｉｄを含んでいる。

一実施形態では、ＨＡＬ２０２は、オペレーティングシステム内に設定された環境変数でパスの下リソースディレクトリを検索する。リソースドライバ３０２のリソース構成４０８は、リソースドライバ３０２を含んでいる共有ライブラリの名前を指定可能である。リソースドライバのｉｄが登録されていない場合、ＨＡＬ２０２は、共有ライブラリをロードするオペレーティングシステムメソッドの使用によって、リソースドライバ３０２を含んでいる共有ライブラリ
のロードを試行可能である。

Ｃ＋＋の実装では、リソースドライバ３０２は、複数の継承を用いて、IResourceDriverインターフェース７０６と、IResourceから導出され実装を行うリソースインターフェース７０２とから導出される。リソースドライバ３０２は、次いで、抽象化されるリソース３０４の特定の詳細に対する適切なコードを用いて、これらのインターフェースの仮想メソッドを実装する。

種々のリソースドライバ３０２およびリソースインターフェース７０２は、所定のシステムに存在し得る。以下に、どのリソースインターフェース７０２が実際に利用可能かを識別する１つの方法を説明する。

IResourceDriverインターフェース７０６ベースクラスは、リソースドライバ３０２によって実装されるべき仮想の「obtain＿interface」メソッドを指定する。このメソッドは、リソースドライバ３０２がどのリソースインターフェース７０２を実装するかを、リソースドライバ３０２が特定する方法である。

この方法では、入力としてインターフェースリソースｉｄを受け取る。リソースドライバ３０２が、指定されたｉｄを有するリソースインターフェース７０２を実装する時、「obtain＿interface」メソッドが、指定されたリソースインターフェース７０２へ有効な参照を返し、その後、それを用いて、そのリソースインターフェース７０２のメソッドを直接呼び出すことができる。

利点 I(d) は、より高レベルのソフトウェアにリソースを利用可能にすることである。一度リソースドライバ３０２が活性化させられると、リソースコンテナ４０２は、より高レベルのソフトウェアがリソースを使用できるようにする。一実施形態では、リソースコンテナ４０２は、リソースを、それ自体の「obtain＿interface」メソッドにより利用可能にする。このメソッドは、リソースドライバｉｄおよびリソースインターフェースｉｄを用いる。リソースコンテナ４０２は、指定されたリソースドライバの場所を見つけ、次いで、そのドライバの「obtain＿interface」コールを呼び出して、指定されたリソースインターフェース７０２が実装されるかどうかを決定する。指定されたリソースインターフェース７０２が、指定されたリソースドライバ３０２により実装された場合、リソースコンテナ４０２の「obtain＿interface」メソッドは、そのリソースインターフェースへ有効な参照を返す。指定されたリソースインターフェース７０２が、指定されたリソースドライバ３０２において利用不可能な場合、「obtain＿interface」コールは、適切なエラーコードを返す。これによって、より高レベルのソフトウェアが、所望のリソースインターフェース７０２に対するクエリーをリソースコンテナ４０２に行うことができる。一度より高レベルのソフトウェアが、所望のリソースインターフェース７０２を受け取れば、より高レベルのソフトウェアは、リソース３０４と相互作用するそのインターフェースメソッドを呼び出すことができる。例えば、一度より高レベルのソフトウェアが、距離センサに望ましいIRangeSensorインターフェースを取得すると、より高レベルのソフトウェアは、IRangeSensorインターフェースの「get＿distance＿reading」メソッドを呼び出して、扱いやすい現実世界の距離単位でのセンサからの読み取り値を取得することが可能になる。

図８に、距離センサの例を用いて、リソースをより高レベルのソフトウェアに利用可能にするプロセスを示す。リソースを利用可能にするプロセスについては、利点 I(d) に関して簡単に前述した。図８では、振る舞い（より高レベルのソフトウェア）が、距離センサ「ＩＲ１」からの読み取り値を要求する。より高レベルのソフトウェアは、リソースコンテナ４０２のobtain＿interfaceメソッドを呼び出して、距離センサ「ＩＲ１」のIRangeSensorインターフェースを検索する。この要求を実行するために、リソースコンテナ４０２は、リソースドライバテーブルを検索して、リソース「ＩＲ１」に対応するリソースドライバ３０２の場所を確認する。一度、確認を行うと、リソースコンテナ４０２は、このリソースドライバ３０２のobtain＿interfaceメソッドを呼び出し、このメソッドが、IRangeSensorリソースインターフェースの要求を行う。「ＩＲ１」に対応するリソースドライバ３０２は、IRangeSensorリソースインターフェースを実装し、センサ「ＩＲ１」用のIRangeSensorリソースインターフェースへの参照をリソースコンテナ４０２へ返し、次に、このリソースコンテナ４０２が、要求を出している振る舞いへ返す。振る舞いは、ここで、距離センサ「ＩＲ１」に対するIRangeSensorリソースインターフェースへの参照を有し、このリソースインターフェースのget＿distance＿readingメソッドを呼び出して、扱いやすい現実世界の距離単位での「ＩＲ１」距離センサの読み取りを行う。距離センサリソースドライバ３０２が距離センサインターフェースへ参照を返し、適切な距離の読み取りを提供することができる方法の一例を、「リソースドライバの詳細」に関して以下に説明する。

一実施形態では、振る舞いまたはタスク層におけるより高レベルのソフトウェアのみが、リソースコンテナ４０２およびリソースインターフェース７０２と相互作用する。たとえより高レベルのソフトウェアが、別のロボットハードウェアプラットフォームに移動されても、ＨＡＬ２０２は、新しいロボットハードウェアプラットフォームのリソース構成４０８に基づいて適切なリソースドライバ３０２をロードすることによって、これを処理する。新しいロボットハードウェアプラットフォームではもはやリソースインターフェース７０２を利用不可能であるというステータスは、より高レベルのソフトウェアによって確認可能であり、その確認は、リソースコンテナの「obtain＿interface」コールによりエラー結果コードが返されることによって行われ、それらのリソースに依存するオペレーションは、正常に行われない可能性がある。

利点 I(e) は、第１のハードウェアデバイス３０６などのハードウェアデバイスへのアクセスのためのセキュリティ機構を、ＨＡＬ２０２が提供することを示す。セキュリティのためにＨＡＬ２０２により提供可能な１つの機構が、あらゆるメソッドコールを有するセキュリティパラメータを含むことである。本明細書ではチケットｉｄと呼ぶパラメータは、セキュリティチケットを表わし、好ましくはリソースインターフェース７０２の公開メソッドにおける第１のパラメータである。

この機構は、個別のメソッドレベルまで比較的優れたセキュリティ粒度をサポートする。例えば、特定のセキュリティ使用許可については、リソースインターフェース７０２のいくつかのメソッドは、他のものが制限されている間に使用可能である。さらに、リソースドライバ３０２の「obtain＿interface」メソッドは、予約カウントパラメータを有する。このパラメータは、リソースドライバ３０２への同時アクセスをいくつ許可するかを命令する。例えば、この予約カウントを用いて、何人のクライアントが、同時に、リソースドライバ３０２のインターフェースへの参照の保持が可能かを、リソースコンテナ４０２に示すことができる。リソースコンテナ４０２は、この予約カウントを用いて、参照を追跡し、予約カウントが一杯である場合はクライアントへインターフェースを与えない。任意の数の同時アクセスが許可された場合、参照カウントは、０に設定可能である。

予約カウントが有用になりうる１つの例は、リソースドライバ３０２の内部の状態を変更する「書き込み者」であるリソースインターフェース７０２へのアクセスは、リソースドライバ３０２が一度に１回のみサポートするが、リソースドライバ３０２の内部の状態を単に問い合わせる「読み出し者」であるリソースインターフェース７０２へのアクセスは、リソースドライバ３０２が無制限にサポートする場合である。読み出し者であるリソースインターフェースは、０の予約カウントを指定可能であり、それによって、無制限なアクセスが許可され、また、書き込み者であるリソースインターフェースは、１の予約カウントを指定可能であり、その結果、一度に１回のみの書き込みアクセスが可能となる。リソースドライバ３０２の「obtain＿interface」メソッドのチケットｉｄおよび予約カウントパラメータは、利点 I(e) を提供可能である。

（リソースドライバの詳細）
以下に、IRSensor用のリソースドライバの実装の例を含めて、リソースドライバ３０２の作成方法の詳細をさらに説明する。

リソースドライバは、適切なインターフェースクラスに加えて、抽象クラスIResourceDriverから導出されることにより実装可能である。IResourceDriverは、ＨＡＬ２０２の他のコンポーネントがドライバと相互作用する基本メソッドを宣言する。しかしながら、ＨＡＬ２０２は、IResourceDriverから導出されるヘルパークラスを提供することができ、それは、「ResourceDriverImpl」と呼ばれ、「add＿ref」、「remove＿ref」などのメソッドを使用可能にデフォルト実装することにより、ドライバの作成を容易にする。次いで、ドライバが、初期化、活性化メソッド、およびドライバによるリソースインターフェース７０２の実装メソッドを再定義することができる。

（初期化）
ハードウェアアクセス、および構成情報の構文解析が一般に活性段階において行われるので、リソースドライバのコンストラクタ内における初期化は、一般に、比較的単純である。メソッドは、活性化準備のために、オブジェクトのメンバ変数を初期化する。以下は、IRSensorコンストラクタの比較的単純な実装に対応するサンプルコードである。

（コードブロック１）（図９）:

示した実施形態では、コンストラクタは、単にデータメンバをデフォルトの０値へ初期化する。

（活性化）
一実施形態では、３つのメソッドが、リソースドライバの活性化、すなわち「activate」「deactivate」、および「is＿active」を処理する。名前が示すように、メソッドは、活性化、非活性化を引き起こす役割と、活性状態を示す役割とをそれぞれ果たす。活性化および非活性化は、繰り返し行うことができ、例えば、フェールセーフシステムが、デバイスをリセットしようと作動を停止するドライバを非活性化および再活性化させることができ、リソースドライバ３０２が、このような活性を適切に処理すべきである。「activate」および「deactivate」シーケンスの後に、リソースドライバ３０２およびハードウェアは、活性前の状態と同じ状態に戻る。この理由のために、ハードウェア、スレッドおよび／またはネットワーク、あるいは他の通信の初期化は、コンストラクタ内ではなく、「activate」時に行われるべきである。シャットダウンは、「deactivate」時に行われるべきである。リソース構成４０８の読み出しは、「activate」時に行われ、リソース構成４０８内においてパラメータを用いて、リソースドライバを適切な状態にセットする。「is＿active」メソッドは、活性化がうまく完了した場合は「true」表示を返し、またはそうでない場合は「false」を返し得る。「is＿active」メソッドが、ドライバの状態の正確なレポートを提供することに留意すべきである。リソースドライバ３０２を管理するリソースコンテナ４０２は、この情報を用いて、ハードウェアが正常に作動しているか、ならびにドライバが、インターフェースポインタの要求を受け入れる準備ができているかを判断することができる。

さらに、「activate」メソッドは、実行開始時に「is＿active」をチェック可能であり、リソースドライバ３０２が既に活性状態である場合、直ちに、など、比較的早く成功の表示を返す。「deactivate」メソッドによって、リソースドライバ３０２が活性状態でないかどうかを判断可能である。「activate」または「deactivate」のコールが繰り返されたことはエラーではなく、そのメソッドの意味は、実質的に、もしまだ活性状態になっていなければ活性化する」ということである。

以下は、IRSensorリソースドライバの例についての「activate」メソッドに対応するサンプルコードである。ここに示したサンプルコードは、扱いやすいように単純化しており、示したソースコードに、ログインおよび／またはエラー処理関数を追加可能であることを、当業者は理解するだろう。

（コードブロック２）（図１１）

「activate」メソッドの１つの目的は、IRSensorへの有効なデバイスハンドルを取得することである。そうするためには、resource.configの「get＿parameter」および「get＿bus＿id」メソッドを呼び出すことによって、リソース構成４０８からIRSensorが接続されるアドレスおよびバスを取得すべきである。メソッドがバスｉｄを取得すると、そのメソッドは、リソースコンテナ４０２の「obtain＿interface」メソッドを呼び出すことにより、バスリソースドライバへの参照を得る。バスのリソースインターフェースが取得されると、メソッドは、そのインターフェースの「get＿device」メソッドを呼び出して、IRSensorのデバイスハンドルへの参照を取得する。このデバイスハンドルが有効である限り、IRSensorへのアクセスが可能であり、リソースは、活性状態であると考えることができる。

IRSensorリソースドライバの「is＿active」メソッドの１つの実装は、次のとおりである。

（コードブロック２ａ）（図１０）

「deactivate」メソッドに対応するソースコードの１つの例が、以下の通りである。

（コードブロック３）（図１２）

「deactivate」メソッドは、デバイスおよびバスインターフェースの解放によりクリーンアップを行う。「deactivate」メソッドはまた、＿deviceおよび＿busインターフェースのポインタをヌルに、＿addressを０にリセットして、「activate」メソッドを呼び出す前の状態に戻す。このサンプルコードはまた、ＨＡＬ２０２のオブジェクトの、ここに示した実施形態の組み込み参照カウントを示す。「release＿interface」コールは、実際に、それらのオブジェクトが他のオブジェクトにより参照されない時は、バスおよびデバイスオブジェクトを削除する。

（インターフェースの取得）
リソースドライバ３０２を有効にするために、他のソフトウエアコンポーネントがアクセス可能な、周知のリソースインターフェース７０２を公開するべきである。後述する「obtain＿interface」メソッドは、その機能を実行可能な１つの方法を示す。リソースドライバ３０２は、リソースコンテナ４０２の内部において保護されており、その結果、リソースインターフェース７０２を要求しているコンポーネントが、あるリソースドライバ３０２によって実装される時、その要求は、リソースコンテナ４０２を通じて行われる。コンテナの「obtain＿interface」メソッドは、リソースドライバ３０２が活性状態であることを確認し、次に、リソースインターフェース７０２を要求するリソースドライバ３０２の「obtain＿interface」メソッドを呼び出す。

次いで、ドライバは、要求されたリソースインターフェース７０２がサポートされているかどうかを判断し、要求されたリソースインターフェース７０２にポインタを返す。要求されたリソースインターフェース７０２がサポートされていない場合、そのコールは、「RESULT＿NOT＿IMPLEMENTED」を返す。リソースインターフェース７０２が返される場合、クライアントが、リソースドライバ３０２への参照を有し、実行時にリソースコンテナ４０２を通じてそれを解放する役割を担うので、「obtain＿interface」は、リソースドライバ３０２の「add＿ref」メソッドを呼び出す。インターフェースポインタに加えて、ＨＡＬ２０２の利点I(e)に関して述べたように、「obtain＿interface」メソッドは、予約カウントを出力する。以下の例では、IRSensorリソースドライバは、それが実装する唯一のものである、IRangeSensorリソースインターフェースへの無制限のアクセスを許可し、したがって、予約カウントは０にセットされる。

（コードブロック４）（図１３）

示した実施形態では、IRSensorインターフェースは、IRangeSensorインターフェースのみをサポートしているので、interface＿nameパラメータが、一定のIRangeSensor::INTERFACEIDと一致するかを判断するだけでよい。リソースドライバ３０２がまた、１つを超えるリソースインターフェース７０２をサポート可能であることが理解され、この場合には、「obtain＿interface」メソッドは、サポートされたリソースインターフェース７０２のｉｄを有するinterface＿nameパラメータをチェックし、一致することが分かると、適切なインターフェースの参照を返す。

リソースインターフェース７０２は、カプセル化されたリソース３０４のオペレーションに関連するメソッドを確定する。この例におけるIRangeSensorリソースインターフェースは、以下のメソッドを実装する。

（コードブロック５）

これらのメソッドは、距離センサのための典型的なオペレーションを示す。「get＿distance＿reading」メソッドは、センサの生の読み取り値から処理済みの現実世界の単位による読み取り値を返す。「get＿raw＿reading」メソッドは、センサから生の読み取り値を返す。

サンプルIRSensorリソースドライバ用の「get＿distance＿reading」メソッドのサンプル実装に対応するソースコードの１つの例を以下に示す。

（コードブロック６）（図１４）

ここに示した「get＿distance＿reading」メソッドは、リソースドライバ３０２が処理前に活性状態であることを確認する。次いで、「get＿distance＿reading」メソッドは、「activate」メソッドにより予め取得されたセンサの ＿device参照および＿address値を引き渡し、ハードウェアドライバメソッド「ercm＿device＿read＿analog」を用いて、この特定のタイプのデバイスにアクセスし、IRSensorから生の値を読み取る。読み取り値に対するタイムスタンプ値が、取得され、「raw＿to＿distance」メソッドが、それに続き、生の読み取り値を距離の読み取り値に変換する。次いで、変換された距離の値は、出力される距離パラメータへ格納され、「RESULT＿SUCCESS」値が返される。

IRSensorが「get＿raw＿reading」メソッドを実装する一実施形態を以下に示す。

（コードブロック７）（図１５）

この実装が、get＿distance＿readingと、以下の点を除いてほとんど同じであることに留意されたい。すなわち、生の読み取り値を距離へ変換する代わりに、その読み取り値が電圧単位に変換され、この電圧単位が、使用されている特定のIRSensorの生のフォームに相当するという点を除いて、殆ど同じであることに留意されたい。

（註：コードブロック８は、本明細書中にない）
ロボットの振る舞いを生じさせるために、より高レベルのソフトウェアが、どのようにリソースドライバ３０２の利用が可能かを、以下にさらに詳細に説明する。ロボットの振る舞いの１つの例が、ある距離を所望の速度でロボットを前進させることである。これを実行するために、振る舞いは、ロボットが所望の速度で前進しているかどうかを判断し、移動した距離を周期的に測定し、ロボットが所望の距離を移動するとロボットを停止させることができる。

一実施形態では、この振る舞いは、ＨＡＬ２０２により与えられる２つの異なるリソースインターフェース７０２、すなわち、ドライブシステムリソースインターフェースと走行距離リソースインターフェースとを使用する。ドライブシステムリソースインターフェースは、「move＿and＿turn」メソッドを与え、このメソッドによって、振る舞いが線速度を指定可能になる。そのメソッドの一実施形態ではまた、角速度の設定が可能であるが、前進の場合には、角速度は、０に設定可能である。

一実施形態では、走行距離リソースインターフェースは、「get＿position」メソッドを有し、このメソッドは、位置構造におけるロボットの現在位置を返し、それは、ロボットの方向（θ）に加えて、デカルト座標（ｘ，ｙ）におけるロボットの位置を含んでいる。

図８に関してすでに説明したように、リソースコンテナ４０２の「obtain＿interface」メソッドを呼び出して、ＨＡＬ２０２からこれらの２つのリソースインターフェース７０２への参照を要求することによって、振る舞いが開始される。リソースコンテナ４０２は、ドライブシステムおよび走行距離リソースインターフェースへの参照を返す。次いで、振る舞いは、走行距離リソースインターフェースの「get＿position」メソッドを呼び出して、ロボットの現在位置を検索し、振る舞いは、それを動きの開始点として格納することができる。次いで、振る舞いは、ドライブシステムの振る舞いの「move＿and＿turn」メソッドを呼び出して、所望の速度でロボットを動かし始める。次いで、振る舞いは、走行距離リソースの「get＿position」メソッドを呼び出すことにより、ロボットの現在位置を周期的にチェックするループを開始可能であり、また標準的な平方根による距離計算式を用いて現在位置と開始位置との間の距離を計算して、所望の距離に達したかどうかを確認可能である。これが達成されると、振る舞いは、ループを抜け出し、ドライブシステムリソースインターフェースの「move＿and＿turn」メソッドを呼び出し、線速度が０に、角速度が０にされて、停止される。この振る舞いのＣ＋＋実装の１つの例を、以下のコードブロック９に記述する。

（コードブロック９）（図１６）

コードブロック９が、ＨＡＬ２０２と相互作用して、例えばある距離を前進するなど、単純なロボットオペレーションを行うより高レベルの振る舞いを示す。ここに示したオペレーションでは、２つの異なるリソースインターフェース７０２を用いる。振る舞いは、まずリソースコンテナ４０２への「obtain＿interface」コールでこれらのリソースインターフェースを取得する。これらのインターフェースへの参照が取得されると、振る舞いは、これらのインターフェースのメソッド、すなわち、IOdometryの「get＿position」、およびIDriveSystemの「move＿and＿turn」を利用して、その目的を達成する。有利なことには、ＨＡＬ２０２によって、ここに示したコードは、下層にあるロボットハードウェアの詳細を配慮せずに実行可能である。リソース構成４０２は、活性状態のハードウェアを表しており、ＨＡＬ２０２は、リソース構成４０８内の情報を用いて、これらの２つのメソッドの正確な実装を決定し振る舞いに返し、その結果、振る舞いがこれらのメソッドを呼び出すと、ＨＡＬ２０２により抽象化され活性状態のロボットハードウェアは、意図されたように実行される。

コードブロック１０は、２つのモータを有する差動ドライブシステムの「move＿and＿turn」メソッドの一実装を示す。

（コードブロック１０）（図１７）

コードブロック１０では、差動ドライブシステムのための「move＿and＿turn」メソッドが、線速度および角速度、ならびに個々の加速度など、扱いやすい現実世界のパラメータを取り入れることができる方法、および所望の効果を生じるように左右のモータにおいて個別の速度を計算することができる方法が示されている。図１８は、図１７のフローチャートにおける変数参照用の一覧表を含んでいる。これは、リソースインターフェース７０２の機能を表している。ＨＡＬ２０２によって提供されるこれらのメソッドの実装の詳細が、下層のハードウェアに応じて変化し得ることが理解される。例えば、２組の脚を駆動させるために２つのモータを使用するドライブシステム用の「move＿and＿turn」メソッドの実装は、差動ドライブシステム用の上記のコードとは実質的に異なる。しかしながら、リソース構成４０８においてどのドライブシステムが活性状態であるかを示すことによって、ＨＡＬ２０２は、より高レベルのソフトウェアに正確な実装を行うことができることが好ましく、より高レベルのソフトウェアは、特定のロボットに特有の特性から効果的に切り離される。

（被実装リソースインターフェース）
ＨＡＬ２０２の一実施形態により実装可能なリソースインターフェース７０２の、必ずしも全てではないがリストを以下に示す。さらなるリソースインターフェース７０２が、追加され得ることが理解されるだろう。リソースインターフェースは、読み出し可能性について一般的なカテゴリに整理されている。

（オーディオカテゴリ）
ＨＡＬ２０２は、従来のロボット用ではないプラットホーム内においてサポートされるデバイスを含めて、非常に広範囲のデバイスのための抽象化を行うことが好ましい。オーディオリソースの抽象化によって、より高レベルのソフトウェアが、マイクロホン、デジタルシンセサイザ、スピーカーなどのロボットに取り付けられた音声装置と相互作用し得る。オブジェクト指向設計を用いると、オーディオリソースは、以下のクラス階層に構成可能である。

IAudioBaseによって、モノラルまたはステレオ、サンプリングレート、ブロックサイズ、オーディオチャネルの数、ならびに利用可能なオーディオデバイスの列挙および選択などのデジタルオーディオパラメータの仕様が可能になる。

IAudioPlayが、デジタル音声を再生するために使用可能である。

IAudioRecordが、デジタル音声を録音するために使用可能である
IAudioLevelが、ロボットの周りの環境において一般的な周囲の騒音ボリュームを取得するために使用可能である。IAudioLevelは、高レベルのソフトウエアコンポーネントにより使用されて、音声に反応し得るセンサ入力を提供可能である。例えば、セキュリティ振る舞いは、ある周囲のボリュームレベルに反応して「侵入者警報」を鳴らすように構成可能である。

（視覚的カテゴリ）
視覚的なカテゴリのリソースが、カメラのような視覚センサを抽象化する。それらによって、画像サイズ、色の深さおよびフォーマット、映像コーデック、映像フレーム速度、圧縮の質のような種々の映像および静止画像パラメータの仕様が可能になる。一実施形態では、リソース階層は、以下のとおりである。

ICameraリソースが、単一のカメラから静止画像および映像を取得可能である。取得された画像は、種々の色構成の生ラスタデータに従って、あるいはＪＰＥＧなどの圧縮形式で格納可能である。ICameraGroupリソースの一実施形態は、複数のカメラの相互作用の抽象化を行い、１台を超えるカメラの相対的な位置、方向、および間隔を考慮して、立体視像またはパノラマ画生成などの応用のための複数の画像および映像を同期取り込み可能にする。

（センサカテゴリ）
センサカテゴリは、種々のタイプの非視覚的なセンサデバイスのリソース抽象化を含んでいる。利用可能なセンサの種類は、レーザ距離計などの比較的ハイテクで高コストのセンサから、ソナーまたはバンプスイッチセンサなどの比較的単純で低コストのセンサまで、非常に多い。センサリソースは、この多様性に対処する困難を伴わずに、センサを機能別カテゴリにグループ化しかつ各カテゴリへ比較的単純で一様なインターフェースを提供することによって、抽象化を行う。機能別カテゴリの説明に続いて、以下に、クラス階層をさらに詳細に説明する。

IBumpSensorリソースは、センサとある異物との間の物理的な接触を検知するセンサを抽象化することができる。このカテゴリのセンサには、様々なスイッチセンサが含まれる。

IRangeSensorリソースは、センサが測定可能な距離内の異物の存在を検知するセンサを抽象化することができる。IRangeSensorリソースの一実施形態は、単一の距離読み取り値を返す。リソースは、不明瞭なゾーンまたはデッドゾーン、最小範囲、最大範囲などのある距離センサの物理的限界を記述する。センサから返された読み取り値は、距離単位に変換され、リソースの実装によりエラーを最小限にするフィルタリングを行うことができる。このカテゴリのセンサには、ほとんどのＩＲおよびソナーセンサが含まれる。

ISpatialSensorリソースは、比較広い範囲において異物の存在を検知するセンサを抽象化し、一度に複数の読み取り値を返すことができる。回転レーザ距離計が、このカテゴリのセンサの一例である。

（感情）

IFaceリソースインターフェースが、感情パラメータに基づいた、３Ｄ表示の顔の操作をサポートする。顔は、笑顔、しかめ面などの表情を反映するように変化し得る。

IMotorCommandリソースインターフェースが、モータの回転速度および加速度を設定するなど、単一のモータの制御をカプセル化する。

IMotorQueryリソースインターフェースは、モータの位置または速度などの単一のモータの状態に関して行い得るクエリーをカプセル化する。

IDriveSystemリソースインターフェースが、ロボット全体を動かすドライブシステムを抽象化することができる。このリソースインターフェースは、他のソフトウエアコンポーネントが、線速度および角速度などの扱いやすい現実世界のパラメータに基づいてロボットの動きを制御することを可能にする。その実装によって、これらの単純なコマンドが、仮想の移動ハードウェアの対応の制御信号に変換され、それは、差動ドライブシステムの２つのモータ、または複数のロボット脚の複雑な動きなど広範囲の種々のハードウェアに相当し得る。

IImageDisplayリソースインターフェースは、グラフィックユーザーインターフェースウィンドウに画像を表示する能力をカプセル化する。

IJoystickリソースインターフェースは、ジョイスティックからの入力をカプセル化する。

ISwitchDeviceリソースインターフェースは、外部の多位置ハードウェアスイッチからの入力をカプセル化する。

IGripperリソースインターフェースは、グリッパーの状態へのクエリー、およびグリッパーの開閉コマンドを含めて、グリッパーのオペレーションをカプセル化する。

ISpeechRecognizerリソースインターフェースは、音声認識インターフェースを抽象化する。

ISpeechTTSリソースインターフェースは、テキスト入力から音声を合成する能力をサポートするメソッドを含み得る。

IPollableリソースインターフェースは、選択されたリソースのポーリングオペレーションをカプセル化する。リソースインターフェース７０２にポーリングを行う時、リソースインターフェース７０２はまた、ポーリング方法とポーリングの間隔とを示す実装をこのインターフェースに行う。

ITransactableリソースインターフェースは、いくつかのリソースドライバをサポート可能であり、単一のトランザクションの一部分として複数のコマンドおよび／またはクエリーを送信するように構成される。

本発明の種々の実施形態を上に述べてきた。これらの特定の実施形態に関して本発明を説明してきたが、説明は、本発明を例示するものであって限定する意図はない。添付の特許請求の範囲に定められるような本発明の真の精神および範囲から逸脱せずに、種々の変更および応用を、当業者は着想可能である。

本発明の実施形態で使用可能な種々のロボットの、全てではないがサンプルを示す図である。 通常のロボットソフトウェアアーキテクチャを示す図である。 ハードウェア抽象層（ＨＡＬ）を用いたソフトウェアアーキテクチャを示す図である。 ハードウェアデバイスの抽象化、およびリソースドライバとリソースとの間の関係を示す図である。 ＨＡＬの詳細をさらに示す図である。 ハードウェアデバイスの、論理デバイスバスから処理ユニットへの結合を示す図である。 リソースの構成の詳細をさらに示す図である。 リソースドライバオブジェクトが、IResourceDriverと、１つまたはそれ以上のIResource インターフェースとから導出される様子を示す図である。 より高レベルのソフトウェアによるリソースの利用を可能にする処理を示す図である。 本発明の態様の概要を示すフローチャートである。 図１７に示したフローチャートの変数の参照符号表である。

Claims (14)

1. ロボットソフトウェアアーキテクチャ内のハードウェア抽象化層（ＨＡＬ）であって、
   高レベルのソフトウェアに対するソフトウェアインターフェースであって、当該ソフトウェアインターフェースが、ロボットと環境との相互作用に関連した現実世界の測定値を伴って、より高レベルのロボットソフトウェアと通信するように構成された前記ソフトウェアインターフェースと、
   前記高レベルのソフトウェアに、利用可能なリソースの表示を提供するリソース構成と、
   複数のリソースドライバであって、当該リソースドライバの少なくとも一部分が、前記リソース構成内の利用可能なリソースに相当し、前記リソースドライバの少なくとも２つが、機能性において部分的に重なっており、前記少なくとも２つのリソースドライバの１つのみが、利用可能な対応のリソースを有し、利用可能なリソース用のリソースドライバが、ロボット用の現実世界の測定値と、デバイス用のデバイスレベルの測定値との間において変換を行うように構成されている前記複数のリソースドライバと、
   低レベルのデバイスドライバに対するインターフェースであって、当該低レベルのデバイスドライバが、デバイスレベルにおいて対応のハードウェアと通信し、前記低レベルのデバイスドライバに対するインターフェースが、リソースドライバを介して、前記高レベルのソフトウェアと通信する、前記低レベルのデバイスドライバに対するインターフェースと、
   を備えるＨＡＬ。
2. 前記リソース構成が、構造上の、ロボットへのデバイスの結合場所についての表示をさらに含む請求項１に記載のＨＡＬ。
3. 前記高レベルのソフトウェアが、プランナ、アプリケーション、振る舞いおよびタスクから成るグループから選択される少なくとも１つを含む請求項１に記載のＨＡＬ。
4. デバイスドライバが、モータドライバに対応し、対応のリソースドライバが、車輪の直径および歯車比を用いて、前記リソースドライバが、前記モータドライバ用のモータ角速度と、前記高レベルのソフトウェア用の線速度との間において変換を行うように、モータの角速度として与えられる速度を計算する請求項１に記載のＨＡＬ。
5. 前記リソースドライバが、前記高レベルのソフトウェアと前記低レベルのデバイスドライバとの間のアプリケーションプログラムインターフェース（ＡＰＩ）層内に存在する請求項１に記載のＨＡＬ。
6. ロボットに、ロボット制御ソフトウェアのハードウェア抽象化を提供する方法であって、
   対応のハードウェアがロボットに存在しないリソースドライバを含む、前記ロボット用の複数のリソースドライバを設けるステップと、
   前記ロボット用のハードウェア構成を検出するステップと、
   前記検出された前記ハードウェア構成に基づき、前記ロボットにおいて利用可能なリソースを自動的に検出するステップと、
   前記ロボット制御ソフトウェアから、１つのタイプのリソースを使用する要求を受信するステップと、
   前記ロボット制御ソフトウェアにより要求されたタイプのリソースに相当するリソースを、前記利用可能なリソースから自動的に選択するステップと、
   前記選択されたリソースの使用に関連するとともに、ロボットに関連する測定単位で提供される第１の情報を前記ロボット制御ソフトウェアと交換するステップと、
   第２の情報であって、前記ロボット制御ソフトウェアによる使用要求に関連し、対応のデバイスに関連する測定単位で提供され、前記第１の情報とは異なる、前記リソースに対応する前記第２の情報を、低レベルのデバイスドライバと交換するステップと、
   前記ロボットの検出された構成に基づき、前記第１の情報及び前記第２の情報の間において変換を行うステップと、
   を含む、ＨＡＬ。
7. 前記第１の情報が線速度であり、前記第２の情報が角速度である請求項６に記載の方法。
8. 前記方法が、アプリケーションプログラムインターフェース（ＡＰＩ）において実施される請求項６に記載の方法。
9. リソースのタイプが、距離の意味を含み、前記選択されるリソースが、バンプセンサ、レーザ距離計、超音波センサ、および赤外線センサから成るグループから選択された１つのデバイスに相当する請求項６に記載の方法。
10. 前記ロボットが最初はバンプセンサを含み、かつ前記ロボット用のハードウェア構成が前記バンプセンサを指定し、さらに、
    前記バンプセンサを赤外線センサに変更するステップと、
    前記ロボット用のハードウェア構成を変更するステップと、
    前記ロボット制御ソフトウェアを、変更せずに使用可能となるように、前記ロボットの新たに検出された構成に基づいて、前記第１の情報と前記第２の情報とを自動的に変換するステップと、
    を含む請求項６に記載の方法。
11. メソッドコールを有するセキュリティパラメータを含むステップと、
    リソースへのアクセスが要求された時に、セキュリティチケットを確認するステップと、
    前記セキュリティチケットに基づいて前記リソースへのアクセスを抑制するステップと、
    をさらに含む請求項６に記載の方法。
12. リソースへのアクセスに基づいて更新される予約カウントパラメータを管理するステップと、
    前記カウントに基づいて前記リソースへのアクセスを制御するステップと、
    をさらに含む請求項６に記載の方法。
13. ロボット内の、ロボット制御ソフトウェア用のハードウェア抽象化層（ＨＡＬ）であって、
    対応のハードウェアがロボットに存在しないリソースドライバを含む、前記ロボット用の複数のリソースドライバを設ける手段と、
    前記ロボット用のハードウェア構成を検出する手段と、
    前記検出されたハードウェア構成に基づき、前記ロボットにおいて利用可能なリソースを自動的に検出する手段と、
    前記ロボット制御ソフトウェアから、１つのタイプのリソースを使用する要求を受信する手段と、
    前記ロボット制御ソフトウェアにより要求されたタイプのリソースに相当するリソースを、前記利用可能なリソースから自動的に選択する手段と、
    前記選択されたリソースの使用に関連し、かつロボットに関連する測定単位で提供される第１の情報を前記ロボット制御ソフトウェアと交換する手段と、
    第２の情報であって、前記ロボット制御ソフトウェアによる使用要求に関連し、対応のデバイスに関連する測定単位で提供され、前記第１の情報とは異なる、前記リソースに対応する前記第２の情報を、低レベルのデバイスドライバと交換する手段と、
    前記ロボットの検出された構成に基づき、前記第１の情報と前記第２の情報とを変換する手段と、
    を含む、ＨＡＬ。
14. コンピュータ読み出し可能媒体であって、方法を実施する命令をコンピュータが実行可能であり、当該方法は、
    対応のハードウェアがロボットに存在しないリソースドライバを含む、前記ロボット用の複数のリソースドライバを設けるステップと、
    前記ロボット用のハードウェア構成を検出するステップと、
    前記検出されたハードウェア構成に基づき、前記ロボットにおいて利用可能なリソースを自動的に検出するステップと、
    前記ロボット制御ソフトウェアから、１つのタイプのリソースを使用する要求を受信するステップと、
    前記ロボット制御ソフトウェアにより要求されたタイプのリソースに相当するリソースを、前記利用可能なリソースから自動的に選択するステップと、
    前記選択されたリソースの使用に関連し、かつロボットに関連する測定単位で提供される第１の情報を前記ロボット制御ソフトウェアと交換するステップと、
    第２の情報であって、前記ロボット制御ソフトウェアによる使用要求に関連し、対応のデバイスに関連する測定単位で提供され、前記第１の情報とは異なる、前記リソースに対応する前記第２の情報を、低レベルのデバイスドライバと交換するステップと、
    前記ロボットの検出された構成に基づき、前記第１の情報と前記第２の情報とを変換するステップと、
    を含む、コンピュータ読み出し可能媒体。

Images