(57)【要約】【課題】  コンパイラ言語で記述されたオブジェクトとスクリプト言語で記述されたオブジェクト間でクラス継承を好適に実現する。【解決手段】  相互の言語のオブジェクトに他方のオブジェクトの参照をメンバに持つことで、クラスの継承を扱う。第１の言語におけるクラスのメンバに、これを継承したクラスである第２の言語のクラスへの参照を保持させ、第２の言語のオブジェクトのメンバに第１のクラスへの参照を保持させる。Ｃ＋＋のベース・クラスからメソッドを呼び出した際、継承したクラスがスクリプト言語のクラスであれば、スクリプト言語のクラスのメソッドを正しく呼び出すことができる。【選択図】  図１
2005321954.tif 000002
【特許請求の範囲】
【請求項１】
１以上の可動部を備えたロボット装置において、
第１の言語で記述されたプログラム・コードの実行により前記ロボット装置の動作を制御する制御装置と、
第２の言語で記述されたプログラム・コードの実行により、前記制御装置を継承する継承装置とを備え、
前記第１の言語で記述されたクラスを前記第２の言語のクラスで継承する際に、前記制御装置は前記第２の言語のクラスへの参照を保持し，前記継承装置は前記第１の言語のクラスへの参照を保持する、
ことを特徴とするロボット装置。
【請求項２】
第１の言語はプログラム・コードを所定のコンパイル処理を経て実行可能となるコンパイル言語であり、第２の言語はプログラム・コードをインタープリタ上で実行可能なスクリプト言語である、
ことを特徴とする請求項１に記載のロボット装置。
【請求項３】
前記継承装置は、第１の言語で記述されたベース・クラスを第２の言語で記述されたスーパー・クラスへ継承させる際に、
前記ベース・クラスを継承する、第１の言語で記述された第１のラッパー・クラスと、
前記スーパー・クラスで継承される、第２の言語で記述された第２のラッパー・クラスと、
前記第１のラッパー・クラスから前記第２のラッパー・クラスのインスタンスへのポインタと、
前記第２のラッパー・クラスから前記第１のラッパー・クラスのインスタンスへのポインタと、
を備えることを特徴とする請求項１に記載のロボット装置。
【請求項４】
前記第１のラッパー・クラスは、前記ベース・クラスの関数が第２の言語側で継承されているクラスにオーバーライドされているかどうかをチェックする判断機能を備える、
ことを特徴とする請求項３に記載のロボット装置。
【請求項５】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックし、前記スーパー・クラスにおいて前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記ベース・クラスの関数を呼び出す、
ことを特徴とする請求項４に記載のロボット装置。
【請求項６】
前記第２のラッパー・クラスはいずれの関数を呼び出すかを判断する機能を装備する、
ことを特徴とする請求項３に記載のロボット装置。
【請求項７】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を持ち、
前記第２のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックし、前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記擬似オーバーライド関数を呼び出す、
ことを特徴とする請求項６に記載のロボット装置。
【請求項８】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、
前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を定義する第３のラッパー・クラスが前記第１のラッパー・クラスを継承し、
前記第２のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックし、前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記第３のラッパー・クラスを呼び出す、
ことを特徴とする請求項６に記載のロボット装置。
【請求項９】
第１の言語と第２の言語でそれぞれ記述されたオブジェクトが混在するオブジェクト指向プログラミング環境においてプログラムを実行する情報処理システムにおいて、
第１の言語で記述されたクラスを継承したクラスを第２の言語のクラスとする際に、第１の言語におけるクラスのメンバに該クラスを継承した第２の言語のクラスへの参照を保持させるとともに、第２の言語のオブジェクトのメンバに第１の言語のクラスへの参照を保持させる、
ことを特徴とする情報処理システム。
【請求項１０】
第１の言語はプログラム・コードを所定のコンパイル処理を経て実行可能となるコンパイル言語であり、第２の言語はプログラム・コードをインタープリタ上で実行可能なスクリプト言語である、
ことを特徴とする請求項９に記載の情報処理システム。
【請求項１１】
第１の言語で記述されたベース・クラスを第２の言語で記述されたスーパー・クラスへ継承させる際に、
前記ベース・クラスを第１の言語で記述された第１のラッパー・クラスで継承するとともに、第２の言語で記述された第２のラッパー・クラスを前記スーパー・クラスが継承し、
前記第１のラッパー・クラスは前記第２のラッパー・クラスのインスタンスのポインタを格納し、
前記第２のラッパー・クラスは前記第１のラッパー・クラスのインスタンスのポインタを格納する、
ことを特徴とする請求項９に記載の情報処理システム。
【請求項１２】
前記第１のラッパー・クラスは、前記ベース・クラスの関数が第２の言語側で継承されているクラスにオーバーライドされているかどうかをチェックする判断機能を装備する、
ことを特徴とする請求項１１に記載の情報処理システム。
【請求項１３】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックし、前記スーパー・クラスにおいて前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記ベース・クラスの関数を呼び出す、
ことを特徴とする請求項１２に記載の情報処理システム。
【請求項１４】
前記第２のラッパー・クラスはいずれの関数を呼び出すかを判断する機能を装備する、
ことを特徴とする請求項１１に記載の情報処理システム。
【請求項１５】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を持ち、
前記第２のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックし、前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記擬似オーバーライド関数を呼び出す、
ことを特徴とする請求項１４に記載の情報処理システム。
【請求項１６】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、
前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を定義する第３のラッパー・クラスが前記第１のラッパー・クラスを継承し、
前記第２のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックし、前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記第３のラッパー・クラスを呼び出す、
ことを特徴とする請求項１４に記載の情報処理システム。
【請求項１７】
第１の言語と第２の言語でそれぞれ記述されたオブジェクトが混在するオブジェクト指向プログラミング環境においてプログラムを実行するための情報処理方法において、
第１の言語で記述されたクラスを継承したクラスを第２の言語のクラスとする際に、第１の言語におけるクラスのメンバに該クラスを継承した第２の言語のクラスへの参照を保持させるステップと、第２の言語のオブジェクトのメンバに第１の言語のクラスへの参照を保持させるステップと、
を備えることを特徴とする情報処理方法。
【請求項１８】
第１の言語はプログラム・コードを所定のコンパイル処理を経て実行可能となるコンパイル言語であり、第２の言語はプログラム・コードをインタープリタ上で実行可能なスクリプト言語である、
ことを特徴とする請求項１７に記載の情報処理方法。
【請求項１９】
第１の言語で記述されたベース・クラスを第２の言語で記述されたスーパー・クラスへ継承させる際に、
前記ベース・クラスを第１の言語で記述された第１のラッパー・クラスで継承するステップと、
第２の言語で記述された第２のラッパー・クラスを前記スーパー・クラスが継承するステップと、
前記第１のラッパー・クラスが前記第２のラッパー・クラスのインスタンスのポインタを格納するステップと、
前記第２のラッパー・クラスが前記第１のラッパー・クラスのインスタンスのポインタを格納するステップと、
をさらに備えることを特徴とする請求項１７に記載の情報処理方法。
【請求項２０】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックするステップを備え、
前記のチェックするステップでは、前記スーパー・クラスにおいて前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記ベース・クラスの関数を呼び出す、
ことを特徴とする請求項１９に記載の情報処理方法。
【請求項２１】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を持ち、
前記第２のラッパー・クラスが、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックするステップを備え、
前記のチェックするステップでは、前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記擬似オーバーライド関数を呼び出す、
ことを特徴とする請求項１９に記載の情報処理方法。
【請求項２２】
前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、
前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を定義する第３のラッパー・クラスが前記第１のラッパー・クラスを継承し、
前記第２のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされているかどうかをチェックするステップを備え、
前記のチェックするステップでは、前記スーパー・クラスで前記ベース・クラスの関数がオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記第３のラッパー・クラスを呼び出す、
ことを特徴とする請求項１９に記載の情報処理方法。
【請求項２３】
第１の言語と第２の言語でそれぞれ記述されたオブジェクトが混在するオブジェクト指向プログラミング環境においてプログラムを実行するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムにおいて、
第１の言語で記述されたクラスを継承したクラスを第２の言語のクラスとする際に、第１の言語におけるクラスのメンバに該クラスを継承した第２の言語のクラスへの参照を保持させるステップと、第２の言語のオブジェクトのメンバに第１の言語のクラスへの参照を保持させるステップと、
を備えることを特徴とするコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オブジェクト指向言語で記述されたプログラムを実行するロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムに係り、特に、複数のオブジェクト指向言語で記述された言語間でクラス継承を実現するロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、コンパイラ言語で記述されたオブジェクトとスクリプト言語で記述されたオブジェクト間でクラス継承を実現するロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムに係り、例えば、ロボット装置にネイティブのコンパイラ言語で記述されたオブジェクトと、装置にダウンロードされたスクリプト言語形式のオブジェクト間において適切な関数呼び出しを行なうロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
電気的若しくは磁気的な作用を用いて人間の動作に似せた運動を行う機械装置のことを「ロボット」という。ロボットの語源は、スラブ語の“ＲＯＢＯＴＡ（奴隷機械）”に由来すると言われている。わが国では、ロボットが普及し始めたのは１９６０年代末からであるが、その多くは、工場における生産作業の自動化・無人化などを目的としたマニピュレータや搬送ロボットなどの産業用ロボット（ｉｎｄｕｓｔｒｉａｌ ｒｏｂｏｔ）であった。
【０００４】
最近では、イヌやネコのように４足歩行の動物の身体メカニズムやその動作を模したペット型ロボット、あるいは、ヒトやサルなどの２足直立歩行を行う動物の身体メカニズムや動作を模した「人間形」若しくは「人間型」のロボット（ｈｕｍａｎｏｉｄ ｒｏｂｏｔ）など、脚式移動ロボットの構造やその安定歩行制御に関する研究開発が進展し、実用化への期待も高まってきている。これら脚式移動ロボットは、クローラ式ロボットに比し不安定で姿勢制御や歩行制御が難しくなるが、階段の昇降や障害物の乗り越えなど、柔軟な歩行・走行動作を実現できるという点で優れている。
【０００５】
また、最近では、ロボット装置は、産業上の用途以外に、生活密着型、すなわち人間との「共生」あるいは「エンターティンメント」という目的で使用されることが多くなってきている。従来の玩具機械では、ユーザ操作と応答動作との関係が固定的で、玩具の動作をユーザの好みに合わせて変更することはできないため、ユーザは同じ動作の繰り返しにやがては飽きてしまう。これに対し、知能型のロボット装置は、動作に起因する行動モデルや学習モデルを備え、外部からの音声や画像、触覚などの入力情報に基づいてモデルを変化させて動作を決定し、自律的な思考及び動作制御を実現する。さらに、ロボットが感情モデルや本能モデルを用意することにより、ロボット自身の感情や本能に従った自律的な行動を表出することができる。また、人間とのインターフェースとして画像認識処理や音声認識処理などの認識技術を導入し、より高度でリアリスティックなコミュニケーションが可能となる。
【０００６】
この種のロボットは高い情報処理能力を備えており、一種の計算機システムとして捉えることができる。すなわち、上述したような行動計画の立案やこれを体現するためのロボットの動作制御は、計算機システム上におけるプログラム・コード（例えぱアプリケーションなど）の実行という形態で実装される。言い換えれば、ロボットの行動・動作制御システムの構築は、計算機システムにおけるソフトウェア開発・設計という側面を持つ。
【０００７】
ところで、最近のソフトウェア設計においては、処理手順ではなく処理対象となるデータを重要視するという「オブジェクト指向」（ｏｂｊｅｃｔ Ｏｒｉｅｎｔｅｄ）技術が広く採用されている。一般に、オブジェクト指向によれば、ソフトウェアの開発と保守が効率化する。オブジェクト指向に基づくソフトウェアは、基本的に、データとそのデータに対する処理手続きとを一体化させた「オブジェクト」というモジュール単位で扱われる。また、必要に応じて複数のオブジェクトを作成し、これら組み合わせることで１つのソフトウェアが完成する。
【０００８】
オブジェクト指向パラダイムは、「カプセル化」、「クラス／インスタンス」、「クラス継承（インヘリタンス）」、及び、「メッセージ・パッシング」という主要な基本技術によって実現される。
【０００９】
カプセル化は、データと手続き（メソッド）を一体化させることを指す。クラスは、複数のオブジェクトを共通化して定義することを指す。インスタンスはクラスに属するオブジェクトの実体を表す（同一クラスに属するオブジェクトすなわちインスタンスは基本的に同一のメソッドを有するので、個々にメソッドを定義する必要がない）。インヘリタンスとは、あるクラスで定義したことを別の（例えば下位の）クラスが継承することを意味する（新たにクラスを定義するときには、定義済みのクラスとの差分のみを追加変更するだけでよい）。メッセージ・パッシングとは、オブジェクトにメッセージを送って所定の動作を指示することを言う。各オブジェクトは自身のデータを隠蔽しているので、通常、メッセージ・パッシング以外の方法でオブジェクトにアクセスすることはできない。
【００１０】
一般的な計算機システムとロボットとの主な相違として、前者はシステムを構成するハードウェア・コンポーネントの種類や組み合わせ（すなわちハードウェア構成）が各システム間で差が比較的少ないのに対して、後者はハードウェア構成がシステム間で大幅に変更するという点を挙げることができる。ひとえに移動ロボットといっても、胴体に対して取り付けられる可動部として、頭と脚部と尻尾で構成されるロボットや、頭部と車輪のみで構成されるロボットなど、千差万別である。
【００１１】
装備されるハードウェア構成がシステム間で比較的均一である計算機システムにおいては、システム上で実行するソフトウェアのデザインはハードウェアの影響を比較的受けずに済む。これに対して、後者のロボットの場合には、特にハードウェア操作を行なう制御ソフトウェアにおいてはハードウェア依存性が極めて高くなる。
【００１２】
例えば、ロボットの移動制御を考えた場合、移動手段が可動脚の場合と車輪の場合と、２足と４足の場合とでは、移動時・歩行時における安定度判別規範がまったく相違するので、アプリケーションを実行するための動作環境はシステム間で大幅に異なる。このような事情を鑑み、ハードウェアの依存性が比較的低いソフトウェア層と、ハードウェアの依存性が高いソフトウェア層に分離してソフトウェア開発・設計を行なうことが効率的である。すなわち、ハードウェア非依存ソフトウェアと、ハードウェア依存ソフトウェアとを個別に開発しておき、両者の組み合わせにより、多岐にわたる、さまざまな特性や性能を持つ製品ラインアップを提供することができる。
【００１３】
ハードウェア非依存のソフトウェアは、例えば、感情モデルや行動モデル、学習モデルなどのハードウェア操作との関係が少ない処理を行なうアプリケーションである。また、ハードウェア依存のソフトウェアは、例えば、ロボットの基本的な機能を提供するソフトウェア・モジュールの集まりで構成されるミドルウェアであり、各モジュールの構成はロボットの機械的・電気的な特性や仕様、形状などハードウェア属性の影響を受ける。ミドルウェアは、機能的には、各部のセンサの入力を処理・認識して上位のアプリケーションに通知する認識系のミドルウェアと、アプリケーションが発行するコマンドに従って各関節アクチュエータの駆動などハードウェアの駆動制御を行なう出力系のミドルウェアに大別することができる。
【００１４】
例えば、ハードウェア構成に適合したミドルウェアをロボットに導入することによって、同じアプリケーションをさまざまなハードウェア構成のロボット上で実行可能となる。また、アプリケーションとミドルウェア間の任意の組み合わせを許容するためには、これらソフトウェア層間でのデータやコマンドを交換する形式、すなわちプログラム間のインターフェースを確立させておく必要がある（例えば、特許文献１を参照のこと）。
【００１５】
【特許文献１】特開２００２−１１３６７５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
ところで、ロボットを始めとして各種の計算機システムに対してソフトウェアを導入する形態として、新しいソフトウェアをリムーバブル・メディアを介して供給したり、あるいはネットワーク経由でソフトウェアをダウンロードしたりすることが挙げられる。
【００１７】
例えば、ロボットの本体のある部位に、メモリ・カードやメモリ・スティックなどのリムーバブル・メディアを介して、アプリケーションやミドルウェアなどの新しいソフトウェアを簡単にロボットに導入することができる。あるいは、ロボットが無線又は有線のＬＡＮインターフェースを装備することにより、例えば最寄りの基地局やサーバを経由して所定のサイトから最新バージョンのプログラムをダウンロードすることができる。
【００１８】
ここで、プログラミング言語には、コンパイル処理後に実行形式となるコンパイラ言語と、スクリプト言語や簡易プログラミング言語と呼ばれる高レベル・プログラミング言語などがある。前者の例としてＣやＣ＋＋を挙げることができる。また、後者の例では、ｐｅｒｌ、ｐｙｔｈｏｎ、Ｒｕｂｙなどを挙げることができる。
【００１９】
スクリプト言語は、高機能であるが、インタープリタ上で実行されるためスピードが遅いという問題点がある。このため、高スピードが要求されている部分は、コンパイラ型の言語で記述したり、あらかじめＣやＣ＋＋などのライブラリと組み合わせたりして使用している。例えば、ロボットなどの情報処理装置において、ネイティブなコード部分はＣやＣ＋＋などのコンパイラ言語で記述される。
【００２０】
ところが、コンパイラ言語はコンパイル処理してからでないと実行できないことから、装置にダウンロードされるプログラム・モジュールに関しては、コンパイル処理なしで実行可能にするため、スクリプト言語で記述することが便利であると、本発明者らは思料する。
【００２１】
この場合、スクリプト言語で記述されたプログラム・モジュール側から、コンパイラ言語で記述されたサブルーチンを呼び出す、あるいはその逆に、コンパイラ言語で記述されたプログラム・モジュール側から、スクリプト言語で記述されたサブルーチンを呼び出す必要があり、両方の言語の相違を吸収しなければならない。
【００２２】
とりわけ、オブジェクト指向プログラミングにおけるメッセージのメカニズムの基本的な概念の１つとして、ポリモルフィズム（多相性、多様性）を挙げることができる。このポリモルフィズムとは、異なるクラスに定義されている別のメソッドに同一の操作名を付ける（ｏｖｅｒｒｉｄｅ）ことにより、それらを同一のメッセージで使用できる、ということを意味する。ポリモルフィズムの成立により、上下のクラスにおいて同じ名前の異なるメソッドを定義することができ、インヘリタンス（継承）を効率的に利用することができる。ポリモルフィズムに関しては、例えばＢｊａｒｎｅ Ｓｔｒｏｕｓｔｒｕｐ著「プログラミング言語Ｃ++第三版」（Ａｄｄｉｓｏｎ-Ｗｅｓｌｅｙ，アスキー、ｐｐ ６７）を参照されたい。
【００２３】
上述した例では、ポリモルフィズムを達成するためには、コンパイラ言語及びスクリプト言語でそれぞれ記述されたオブジェクト相互間で、他方のオブジェクトへの参照情報を持ち、正しくクラス継承を扱えなくてはならない。例えば、Ｃ＋＋のベース・クラスからメソッドを呼び出した際、正しいクラスを呼び出す。これがスクリプト言語のクラスであれば、スクリプト言語のクラスのメソッドを呼び出す。
【００２４】
Ｃ＋＋では、一般に、仮想（ｖｉｒｔｕａｌ）関数を用いてポリモルフィズムを実装している。ベース・クラスでメンバ関数を仮想関数と宣言し、派生クラスで関数のオーバーライドを行なう。このとき、クラスに仮想テーブルを持たせることで、オブジェクトの属しているクラスを判定する。
【００２５】
Ｃ＋＋のようなコンパイラ型の言語では、コンパイル時に派生クラスが関数のオーバーライドを行なっているかどうかを判断することができる。これに対し、スクリプト型の言語は、実行効率はよいが、インタープリタによる実行時でないと関数のオーバーライドを行なっているかどうかを判断することができない。このため、Ｃ＋＋のクラスをスクリプト言語に継承することは困難である。
【００２６】
また、２つの言語間の相違を吸収するために、ラッパー・コードと呼ばれるプログラムを利用することがある。このラッパー・コードを自動生成するツールとして、ＳＷＩＧなどが知られている（ｈｔｔｐ：／／ｓｗｉｇ．ｏｒｇ／又はｈｔｔｐ：／／ｓｗｉｇ−ｊｐ．ｄｙｎｄｎｓ．ｏｒｇ／を参照のこと）。ところが、このＳＷＩＧでは、スクリプト言語のクラスにＣ＋＋のオブジェクトを持たせているだけであり、Ｃ＋＋からスクリプト言語を呼び出すことができない。すなわち、Ｃ＋＋のクラスをスクリプト言語に継承することはできない。
【００２７】
本発明は、上述したような技術的課題を勘案したものであり、その主な目的は、オブジェクト指向言語で記述された他言語間でクラス継承を好適に実現することができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。
【００２８】
本発明のさらなる目的は、コンパイラ言語で記述されたオブジェクトとスクリプト言語で記述されたオブジェクト間でクラス継承を好適に実現することができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。
【００２９】
本発明のさらなる目的は、ロボット装置にネイティブのコンパイラ言語形式のオブジェクトと、装置にダウンロードされたスクリプト言語形式のオブジェクト間において適切な関数を正しく呼び出すことができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。
【００３０】
本発明のさらなる目的は、コンパイラ言語及びスクリプト言語のいずれのオブジェクトからでも、関数がスクリプト言語側のオブジェクトにオーバーライドされているか否かに応じて正しく呼び出し、ポリモルフィズムを達成することができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【００３１】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、１以上の可動部を備えたロボット装置において、
第１の言語で記述されたプログラム・コードの実行により前記ロボット装置の動作を制御する制御装置と、
第２の言語で記述されたプログラム・コードの実行により、前記制御装置を継承する継承装置とを備え、
前記第１の言語で記述されたクラスを前記第２の言語のクラスで継承する際に、前記制御装置は前記第２の言語のクラスへの参照を保持し，前記継承装置は前記第１の言語のクラスへの参照を保持する、
ことを特徴とするロボット装置である。
【００３２】
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【００３３】
ここで言う第１及び第２の言語はともにオブジェクト指向言語である。第１の言語は例えばＣ＋＋などのコンパイラ言語であり、第２の言語はｐｙｔｈｏｎ又はその他のスクリプト言語であり、インタープリタ上で実行される。すなわち、本発明に係るロボット装置では、コンパイラ言語とスクリプト言語でそれぞれ記述されたオブジェクトが混在するオブジェクト指向プログラミング環境により制御システムが構成されている。
【００３４】
このようなシステム環境下では、異なる言語間におけるクラス継承の問題がある。具体的には、第１の言語で記述されたクラスを継承したクラスを第２の言語のクラスとしなければならない局面がある。この場合、いずれの言語のクラスから関数が呼び出された場合であっても、正しく関数を呼び出すようにする必要がある。
【００３５】
本発明に係るロボット装置の制御システムでは、相互の言語のオブジェクトに他方のオブジェクトの参照をメンバに持つことで、クラスの継承を扱うようにした。具体的には、第１の言語におけるクラスのメンバに、これを継承したクラスである第２の言語のクラスへの参照を保持させるとともに、第２の言語のオブジェクトのメンバに第１の言語のクラスへの参照を保持させる。例えば、Ｃ＋＋のベース・クラスからメソッドを呼び出した際に、正しいクラスを呼び出す。すなわち、継承したクラスがスクリプト言語のクラスであれば、スクリプト言語のクラスのメソッドを正しく呼び出すことができる。
【００３６】
具体的には、第１の言語で記述されたベース・クラスを第２の言語で記述されたスーパー・クラスへ継承させる際に、前記ベース・クラスを第１の言語で記述された第１のラッパー・クラスで継承するとともに、第２の言語で記述された第２のラッパー・クラスをスーパー・クラスが継承する。そして、前記第１のラッパー・クラスは前記第２のラッパー・クラスのインスタンスのポインタを格納し、前記第２のラッパー・クラスは前記第１のラッパー・クラスのインスタンスのポインタを格納する。
【００３７】
しかし、両言語のクラスに相互参照の関係を構成するだけでは、ポリモルフィズムを完全に到達することはできない。すなわち、Ｃ＋＋側のクラスに定義されている関数を、これを継承したスクリプト言語側のクラスにおいてオーバーライドしている場合には、正しく呼び出すことができるが、スクリプト言語側のクラスにおいてオーバーライドしていない場合には無限ループが生じ、正しく関数を呼び出すことができない、という問題がある。
【００３８】
このような無限ループを解決する１つの方法として、前記ベース・クラスの関数が第２の言語側で継承されているクラスにオーバーライドされているかどうかをチェックする判断機能を装備することを挙げることができる。
【００３９】
具体的には、前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、該オーバーライドした関数内において前記スーパー・クラスにおいてオーバーライドされているかどうかをチェックする。そして、前記スーパー・クラスにおいてオーバーライドされている場合には第２の言語側の関数を呼び出す一方、前記スーパー・クラスにおいてオーバーライドされていない場合には前記ベース・クラスの関数を呼び出すようにし、無限ループへ突入しないようにする。
【００４０】
また、無限ループを解決する他の方法として、前記第２のラッパー・クラスがいずれの関数を呼び出すかを判断する機能を装備することを挙げることができる。
【００４１】
具体的には、前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドし、且つ、前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を持つ。また、前記第２のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドする。そして、第２のラッパー・クラスでは、オーバーライドした関数を呼び出す際には、該オーバーライドした関数内において前記スーパー・クラスにおいてオーバーライドされているかどうかをチェックする。前記スーパー・クラスにおいてオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記擬似オーバーライド関数を呼び出すようにする。このチェック機構は、第二言語では自動的に行なわれる処理なので、ユーザがチェック機構チェック機構を負荷する必要はない。擬似オーバーライド関数は、前記ベース・クラスの関数を呼び出すので、無限ループへ突入しなくなる。
【００４２】
あるいは、前記第１のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドするとともに、前記第１のラッパー・クラスを継承する第３のラッパー・クラスを設ける。この第３のラッパー・クラスでは、前記ベース・クラスの関数を呼び出す擬似オーバーライド関数を定義する。また、前記第２のラッパー・クラスは、前記ベース・クラスの関数をオーバーライドする。そして、第２のラッパー・クラスでは、オーバーライドした関数を呼び出す際には、前記スーパー・クラスにおいてオーバーライドされているかどうかをチェックする。前記スーパー・クラスにおいてオーバーライドされている場合には第２の言語側の関数を呼び出すが、前記スーパー・クラスにおいてオーバーライドされていない場合には前記第３のラッパー・クラスを呼び出す。そして、第3のラッパー・クラスで定義されている擬似オーバーライド関数は、前記ベース・クラスの関数を呼び出すので、無限ループへ突入しなくなる。
【００４３】
また、本発明の第２の側面は、第１の言語と第２の言語でそれぞれ記述されたオブジェクトが混在するオブジェクト指向プログラミング環境においてプログラムを実行するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムにおいて、
第１の言語で記述されたクラスを継承したクラスを第２の言語のクラスとする際に、第１の言語におけるクラスのメンバに該クラスを継承した第２の言語のクラスへの参照を保持させるステップと、第２の言語のオブジェクトのメンバに第１の言語のクラスへの参照を保持させるステップと、
を備えることを特徴とするコンピュータ・プログラムである。
【００４４】
本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係るロボット装置の制御システムと同様の作用効果を得ることができる。
【発明の効果】
【００４５】
本発明によれば、オブジェクト指向言語で記述された他言語間でクラス継承を好適に実現することができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。
【００４６】
また、本発明によれば、コンパイラ言語で記述されたオブジェクトとスクリプト言語で記述されたオブジェクト間でクラス継承を好適に実現することができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。
【００４７】
また、本発明によれば、ロボット装置にネイティブのコンパイラ言語形式のオブジェクトと、装置にダウンロードされたスクリプト言語形式のオブジェクト間において適切な関数を正しく呼び出すことができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。
【００４８】
また、本発明によれば、コンパイラ言語及びスクリプト言語のいずれのオブジェクトからでも、関数がスクリプト言語側のオブジェクトにオーバーライドされているか否かに応じて正しく呼び出し、ポリモルフィズムを達成することができる、優れたロボット装置、情報処理システム及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。
【００４９】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【００５０】
以下、図面を参照しながら本発明の実施形態について詳解する。
【００５１】
図１には、本発明に実施に供されるロボット装置１の機能構成を模式的に示している。同図に示すように、ロボット装置１は、全体の動作の統括的制御やその他のデータ処理を行なう制御ユニット２０と、入出力部４０と、駆動部５０と、電源部６０とで構成される。以下、各部について説明する。
【００５２】
入出力部４０は、入力部としてロボット装置１の目に相当するＣＣＤカメラ１５や、耳に相当するマイクロフォン１６、頭部や背中などの部位に配設されてユーザの接触を感知するタッチ・センサ１８、あるいは五感に相当するその他の各種のセンサを含む。また、出力部として、口に相当するスピーカ１７や、点滅の組み合わせや点灯のタイミングにより顔の表情を形成するＬＥＤインジケータ（目ランプ）１９などを装備している。
【００５３】
駆動部５０は、制御部２０が指令する所定の運動パターンに従ってロボット装置１の機体動作を実現する機能ブロックであり、行動制御による制御対象である。駆動部５０は、ロボット装置１の各関節における自由度を実現するための機能モジュールであり、それぞれの関節におけるロール、ピッチ、ヨーなど各軸毎に設けられた複数の駆動ユニットで構成される。各駆動ユニットは、所定軸回りの回転動作を行なうモータ５１と、モータ５１の回転位置を検出するエンコーダ５２と、エンコーダ５２の出力に基づいてモータ５１の回転位置や回転速度を適応的に制御するドライバ５３の組み合わせで構成される。
【００５４】
電源部６０は、ロボット装置１内の各電気回路などに対して給電を行なう機能モジュールである。本実施形態に係るロボット装置１は、バッテリを用いた自律駆動式であり、電源部６０は、充電バッテリ６１と、充電バッテリ６１の充放電状態を管理する充放電制御部６２とで構成される。充電バッテリ６１は、例えば、複数本のリチウムイオン２次電池セルをカートリッジ式にパッケージ化した「バッテリ・パック」の形態で構成される。また、充放電制御部６２は、バッテリ６１の端子電圧や充電／放電電流量、バッテリ６１の周囲温度などを測定することでバッテリ６１の残存容量を把握し、充電の開始時期や終了時期などを決定する。
【００５５】
制御部２０は、「頭脳」に相当し、例えばロボット装置１の頭部ユニットあるいは胴体部ユニットに搭載される。
【００５６】
図２には、制御ユニット２０の構成をさらに詳細に図解している。同図に示すように、制御ユニット２０は、メイン・コントローラとしてのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２１が、メモリその他の各回路コンポーネントや周辺機器とバス接続された構成となっている。バス２８は、データ・バス、アドレス・バス、コントロール・バスなどを含む共通信号伝送路である。
【００５７】
ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２２は、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）などの揮発性メモリで構成された書き込み可能メモリであり、ＣＰＵ２１が実行するプログラム・コードをロードしたり、実行プログラムによる作業データの一時的に保存したりするために使用される。
【００５８】
ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２３は、プログラムやデータを恒久的に格納する読み出し専用メモリである。ＲＯＭ２３に格納されるプログラム・コードには、ロボット装置１の電源投入時に実行する自己診断テスト・プログラムや、ロボット装置１の動作を規定する動作制御プログラムなどが挙げられる。
【００５９】
不揮発性メモリ２４は、例えばＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）のように、電気的に消去再書き込みが可能なメモリ素子で構成され、逐次更新すべきデータを不揮発的に保持するために使用される。逐次更新すべきデータには、例えば、製造番号や暗号鍵などのセキュリティ情報などが挙げられる。
【００６０】
インターフェース２５は、制御ユニット２０外の機器と相互接続し、データ交換を可能にするための装置である。インターフェース２５は、例えば、カメラ１５やマイクロフォン１６、スピーカ１７との間でデータ入出力を行なう。また、インターフェース２５は、駆動部５０内の各駆動回路５３−１…との間でデータやコマンドの入出力を行なう。
【００６１】
また、インターフェース２５は、ＲＳ（Ｒｅｃｏｍｍｅｎｄｅｄ Ｓｔａｎｄａｒｄ）−２３２Ｃなどのシリアル・インターフェース、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）１２８４などのパラレル・インターフェース、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）インターフェース、ｉ−Ｌｉｎｋ（ＩＥＥＥ１３９４）インターフェース、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）インターフェース、メモリ・カード・インターフェースなどのような、コンピュータの周辺機器接続用の汎用インターフェースを備え、ローカル接続された外部機器との間でプログラムやデータの移動を行なうようにしてもよい。
【００６２】
また、インターフェース２５の他の例として、赤外線通信（ＩｒＤＡ）インターフェースを備え、外部機器と無線通信を行なうようにしてもよい。
【００６３】
さらに、制御ユニット２０は、無線通信インターフェース２６を含み、Ｂｌｕｅｔｏｏｔｈのような近距離無線データ通信やＩＥＥＥ８０２．１１ｂのような無線ネットワークにより機体の数メートル以内に配設されたアクセスポイント（図示しない）との間で無線データ通信を行なうことができる。アクセスポイントは、さらにＬＡＮなどの小規模ネットワークやインターネットなどの広域ネットワークに相互接続され、ロボット装置１をネットワーク上の情報提供空間へと導くことができる。
【００６４】
ネットワーク上には、コンテンツ・サーバを始めとし、多数のホスト装置が接続されている。ロボット装置１は、コンテンツ・サーバからソフトウェアをダウンロードすることができる。ここで、ロボット装置においてネイティブなコード部分は、処理の高速化などのため、ＣやＣ＋＋などのコンパイラ言語で記述される。一方、ダウンロードされるプログラム・モジュールに関しては、コンパイル処理なしで実行可能にするため、スクリプト言語で記述する。
【００６５】
図３１には、本実施形態に係るロボット装置を取り巻くネットワーク構成を模式的に示している。
【００６６】
ロボット装置は、無線データ通信機能を装備しており、アクセス・ポイント経由でネットワークに接続されている（前述）。ロボット装置には、ユーザから与えられた指示を認識する能力、あるいは、ロボットが自らの行動のために必要と判断するプログラムが存在する。
【００６７】
ここで言うネットワークには、ＬＡＮなどの小規模ネットワークやインターネットのような広域ネットワークが含まれる。
【００６８】
ネットワーク上には、ロボット装置のためにＷＷＷ情報探索を代行して行う中継サーバや、その他の多数のサーバが存在する。ネットワーク上では、サーバなどの各ホストは例えばＴＣＰ／ＩＰプロトコルによって相互接続されている。
【００６９】
中継サーバは、ロボット装置に必要なプログラム（オブジェクト）や情報コンテンツ、データなどをあらかじめ記憶しておくとともに、随時これらを更新して、ネットワーク経由で特定のロボット装置あるいはすべてのロボットに配信する。また逆に、ロボット装置から送られてくるプログラム（オブジェクト）や情報コンテンツ、データなどを受信してローカルな記憶システムに格納することができる。
【００７０】
また、ネットワーク上には、有料又は無料で情報を提供する情報提供サーバが存在する。例えば、情報提供サーバは、ウェブサイトが構築された典型的なＷＷＷサーバとして稼働して、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）形式で記述された情報コンテンツを蓄積し情報公開している。中継サーバは、ＨＴＴＰを用いてＨＴＭＬコンテンツにアクセスすることができる。
【００７１】
アプリケーション・サーバは、ロボット装置の機能拡張用のプログラム・モジュールを蓄積しており、ロボット装置からの要求に応じて、プログラム・モジュールを有償又は無償で提供する。
【００７２】
ロボット装置上で実行されるプログラム・コードは、ネイティブ・コード及びアプリケーション・サーバよりダウンロードされるプログラム・モジュールともに、オブジェクト指向プログラミングにより、設計・作成がなされている。アプリケーション・サーバよりダウンロードされたプログラム・モジュールは、ロボット装置にネイティブのクラスを継承する。
【００７３】
ロボット装置においてネイティブなコード部分は、処理の高速化などのため、ＣやＣ＋＋などのコンパイラ言語で記述される。一方、アプリケーション・サーバ側で蓄積されているプログラム・モジュールに関しては、ロボット装置へダウンロードした後にコンパイル処理なしで実行可能にするため、スクリプト言語で記述する。
【００７４】
図３には、本発明の実施形態に係るロボット装置１の行動制御システム１００の機能構成を模式的に示している。ロボット装置１は、外部刺激の認識結果や内部状態の変化に応じて行動制御を行なうことができる。さらには、長期記憶機能を備え、外部刺激から内部状態の変化を連想記憶することにより、外部刺激の認識結果や内部状態の変化に応じて行動制御を行なうことができる。
【００７５】
図示の行動制御システム１００にはオブジェクト指向プログラミングを採り入れて実装することができる。この場合、各ソフトウェアは、データとそのデータに対する処理手続きとを一体化させた「オブジェクト」というモジュール単位で扱われる。また、各オブジェクトは、メッセージ通信と共有メモリを使ったオブジェクト間通信方法によりデータの受け渡しとＩｎｖｏｋｅを行なうことができる。
【００７６】
行動制御システム１００は、外部環境（Ｅｎｖｉｒｏｎｍｅｎｔｓ）を認識するために、視覚認識機能部１０１と、聴覚認識機能部１０２と、接触認識機能部１０３を備えている。
【００７７】
視覚認識機能部（Ｖｉｄｅｏ）５１は、例えば、ＣＣＤカメラのような画像入力装置を介して入力された撮影画像を基に、顔認識や色認識などの画像認識処理や特徴抽出を行なう。視覚認識機能部５１は、後述する“ＭｕｌｔｉＣｏｌｏｒＴｒａｃｋｅｒ”、“ＦａｃｅＤｅｔｅｃｔｏｒ”、“ＦａｃｅＩｄｅｎｔｉｆｙ”といった複数のオブジェクトで構成される。
【００７８】
聴覚認識機能部（Ａｕｄｉｏ）５２は、マイクなどの音声入力装置を介して入力される音声データを音声認識して、特徴抽出したり、単語セット（テキスト）認識を行ったりする。聴覚認識機能部５２は、後述する“ＡｕｄｉｏＲｅｃｏｇ”、“ＡｕｔｈｕｒＤｅｃｏｄｅｒ”といった複数のオブジェクトで構成される。
【００７９】
接触認識機能部（Ｔａｃｔｉｌｅ）５３は、例えば機体の頭部などに内蔵された接触センサによるセンサ信号を認識して、「なでられた」とか「叩かれた」という外部刺激を認識する。
【００８０】
内部状態管理部（ＩＳＭ:Ｉｎｔｅｒｎａｌ Ｓｔａｔｕｓ Ｍａｎａｇｅｒ）１０４は、本能や感情といった数種類の情動を数式モデル化して管理しており、上述の視覚認識機能部１０１と、聴覚認識機能部１０２と、接触認識機能部１０３によって認識された外部刺激（ＥＳ：ＥｘｔｅｒｎａｌＳｔｉｍｕｌａ）に応じてロボット装置１の本能や情動といった内部状態を管理する。
【００８１】
感情モデルと本能モデルは、それぞれ認識結果と行動履歴を入力に持ち、感情値と本能値を管理している。行動モデルは、これら感情値や本能値を参照することができる。
【００８２】
本実施形態では、情動についてその存在意義による複数階層で構成され、それぞれの階層で動作する。決定された複数の動作から、そのときの外部環境や内部状態によってどの動作を行なうかを決定するようになっている（後述）。また、それぞれの階層で行動は選択されるが、より低次の行動から優先的に動作を発現していくことにより、反射などの本能的行動や、記憶を用いた動作選択などの高次の行動を１つの個体上で矛盾なく発現することができる。
【００８３】
ロボット装置１は、外部刺激の認識結果や内部状態の変化に応じて行動制御を行なうために、時間の経過とともに失われる短期的な記憶を行なう短期記憶部１０５と、情報を比較的長期間保持するための長期記憶部１０６を備えている。短期記憶と長期記憶という記憶メカニズムの分類は神経心理学に依拠する。
【００８４】
短期記憶部（ＳｈｏｒｔＴｅｒｍＭｅｍｏｒｙ）１０５は、上述の視覚認識機能部１０１と、聴覚認識機能部１０２と、接触認識機能部１０３によって外部環境から認識されたターゲットやイベントを短期間保持する機能モジュールである。例えば、カメラ１５からの入力画像を約１５秒程度の短い期間だけ記憶する。一方、長期記憶部（ＬｏｎｇＴｅｒｍＭｅｍｏｒｙ）１０６は、物の名前など学習により得られた情報を長期間保持するために使用される。長期記憶部１０６は、例えば、ある行動モジュールにおいて外部刺激から内部状態の変化を連想記憶することができる。
【００８５】
また、本実施形態に係るロボット装置１の行動制御は、反射行動部１０９によって実現される「反射行動」と、状況依存行動階層１０８によって実現される「状況依存行動」と、熟考行動階層１０７によって実現される「熟考行動」に大別される。
【００８６】
反射的行動部（ＲｅｆｌｅｘｉｖｅＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓＬａｙｅｒ）１０９は、上述の視覚認識機能部１０１と、聴覚認識機能部１０２と、接触認識機能部１０３によって認識された外部刺激に応じて反射的な機体動作を実現する機能モジュールである。反射行動とは、基本的に、センサ入力された外部情報の認識結果を直接受けて、これを分類して、出力行動を直接決定する行動のことである。例えば、人間の顔を追いかけたり、うなずくといった振る舞いは反射行動として実装することが好ましい。
【００８７】
状況依存行動階層（ＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓＬａｙｅｒ）１０８は、短期記憶部１０５並びに長期記憶部１０６の記憶内容や、内部状態管理部１０４によって管理される内部状態を基に、ロボット装置１が現在置かれている状況に即応した行動を制御する。
【００８８】
状況依存行動階層１０８は、各行動毎にステートマシン（又は状態遷移モデル）を用意しており、それ以前の行動や状況に依存して、センサ入力された外部情報の認識結果を分類して、行動を機体上で発現する。また、状況依存行動階層１０８は、内部状態をある範囲に保つための行動（「ホメオスタシス行動」とも呼ぶ）も実現し、内部状態が指定した範囲内を越えた場合には、その内部状態を当該範囲内に戻すための行動が出現し易くなるようにその行動を活性化させる（実際には、内部状態と外部環境の両方を考慮した形で行動が選択される）。状況依存行動は、反射行動に比し、反応時間が遅い。
【００８９】
熟考行動階層（ＤｅｌｉｂｅｒａｔｉｖｅＬａｙｅｒ）１０７は、短期記憶部１０５並びに長期記憶部１０６の記憶内容に基づいて、ロボット装置１の比較的長期にわたる行動計画などを行なう。熟考行動とは、与えられた状況あるいは人間からの命令により、推論やそれを実現するための計画を立てて行なわれる行動のことである。例えば、ロボットの位置と目標の位置から経路を探索することは熟考行動に相当する。このような推論や計画は、ロボット装置１がインタラクションを保つための反応時間よりも処理時間や計算負荷を要する（すなわち処理時間がかかる）可能性があるので、上記の反射行動や状況依存行動がリアルタイムで反応を返しながら、熟考行動は推論や計画を行なう。
【００９０】
熟考行動階層１０７や状況依存行動階層１０８、反射行動部１０９は、ロボット装置１のハードウェア構成に非依存の上位のアプリケーション・プログラムとして記述することができる。これに対し、ハードウェア依存層制御部（ＣｏｎｆｉｇｕｒａｔｉｏｎＤｅｐｅｎｄｅｎｔＡｃｔｉｏｎｓＡｎｄＲｅａｃｔｉｏｎｓ）１１０は、これら上位アプリケーション（「スキーマ」と呼ばれる行動モジュール）からの命令に応じて、関節アクチュエータの駆動などの機体のハードウェア（外部環境）を直接操作する。
【００９１】
図３に示したようなロボット１の行動制御システム１００における各機能モジュールは、オブジェクトとして構成される。各オブジェクトは、メッセージ通信と共有メモリを使ったオブジェクト間通信方法によりデータの受け渡しとＩｎｖｏｋｅを行なうことができる。図４には、本実施形態に係る行動制御システム１００のオブジェクト構成を模式的に示している。
【００９２】
視覚認識機能部１０１は、“ＦａｃｅＤｅｔｅｃｔｏｒ”、“ＭｕｌｉｔＣｏｌｏｔＴｒａｃｋｅｒ”、“ＦａｃｅＩｄｅｎｔｉｆｙ”という３つのオブジェクトで構成される。ＦａｃｅＤｅｔｅｃｔｏｒは、画像フレーム中から顔領域を検出するオブジェクトであり、検出結果をＦａｃｅＩｄｅｎｔｉｆｙに出力する。ＭｕｌｉｔＣｏｌｏｔＴｒａｃｋｅｒは、色認識を行なうオブジェクトであり、認識結果をＦａｃｅＩｄｅｎｔｉｆｙ及びＳｈｏｒｔＴｅｒｍＭｅｍｏｒｙ（短期記憶ブ１０５を構成するオブジェクト）に出力する。また、ＦａｃｅＩｄｅｎｔｉｆｙは、検出された顔画像を手持ちの人物辞書で検索するなどして人物の識別を行ない、顔画像領域の位置、大きさ情報とともに人物のＩＤ情報をＳｈｏｒｔＴｅｒｍＭｅｍｏｒｙに出力する。
【００９３】
聴覚認識機能部１０２は、“ＡｕｄｉｏＲｅｃｏｇ”と”ＳｐｅｅｃｈＲｅｃｏｇ”という２つのオブジェクトで構成される。ＡｕｄｉｏＲｅｃｏｇは、マイクなどの音声入力装置からの音声データを受け取って、特徴抽出と音声区間検出を行なうオブジェクトであり、音声区間の音声データの特徴量及び音源方向をＳｐｅｅｃｈＲｅｃｏｇやＳｈｏｒｔＴｅｒｍＭｅｍｏｒｙに出力する。ＳｐｅｅｃｈＲｅｃｏｇは、ＡｕｄｉｏＲｅｃｏｇから受け取った音声特徴量と音声辞書及び構文辞書を使って音声認識を行なうオブジェクトであり、認識された単語のセットをＳｈｏｒｔＴｅｒｍＭｅｍｏｒｙに出力する。
【００９４】
触覚認識記憶部１０３は、接触センサからのセンサ入力を認識する“ＴａｃｔｉｌｅＳｅｎｓｏｒ”というオブジェクトで構成され、認識結果はＳＨｏｒｔＴｅｒｍＭｅｍｏｒｙや内部状態を管理するオブジェクトであるＩｎｔｅｒｎａｌＳｔａｔｅＭｏｄｅｌ（ＩＳＭ）に出力する。
【００９５】
ＳｈｏｒｔＴｅｒｍＭｅｍｏｒｙ（ＳＴＭ）は、短期記憶部１０５を構成するオブジェクトであり、上述の認識系の各オブジェクトによって外部環境から認識されたターゲットやイベントを短期間保持（例えばカメラ１５からの入力画像を約１５秒程度の短い期間だけ記憶する）する機能モジュールであり、ＳＴＭクライアントであるＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓＬａｙｅｒに対して外部刺激の通知（Ｎｏｔｉｆｙ）を定期的に行なう。
【００９６】
ＬｏｎｇＴｅｒｍＭｅｍｏｒｙ（ＬＴＭ）は、長期記憶部１０６を構成するオブジェクトであり、物の名前など学習により得られた情報を長期間保持するために使用される。ＬｏｎｇＴｅｒｍＭｅｍｏｒｙは、例えば、ある行動モジュールにおいて外部刺激から内部状態の変化を連想記憶することができる。
【００９７】
ＩｎｔｅｒｎａｌＳｔａｔｕｓＭａｎａｇｅｒ（ＩＳＭ）は、内部状態管理部１０４を構成するオブジェクトであり、本能や感情といった数種類の情動を数式モデル化して管理しており、上述の認識系の各オブジェクトによって認識された外部刺激（ＥＳ：ＥｘｔｅｒｎａｌＳｔｉｍｕｌａ）に応じてロボット装置１の本能や情動といった内部状態を管理する。
【００９８】
ＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓｌａｙｅｒ（ＳＢＬ）は状況依存型行動階層１０８を構成するオブジェクトである。ＳＢＬは、ＳｈｏｒＴｅｒｍＭｅｍｏｒｙのクライアント（ＳＴＭクライアント）となるオブジェクトであり、ＳｈｏｒＴｅｒｍＭｅｍｏｒｙからは定期的に外部刺激（ターゲットやイベント）に関する情報の通知（Ｎｏｔｉｆｙ）を受け取ると、スキーマ（ｓｃｈｅｍａ）すなわち実行すべき行動モジュールを決定する（後述）。
【００９９】
ＲｅｆｌｅｘｉｖｅＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓＬａｙｅｒは、反射的行動部１０９を構成するオブジェクトであり、上述した認識系の各オブジェクトによって認識された外部刺激に応じて反射的・直接的な機体動作を実行する。例えば、人間の顔を追いかけたり、うなずく、障害物の検出により咄嗟に避けるといった振る舞いを行なう。
【０１００】
ＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓｌａｙｅｒは外部刺激や内部状態の変化などの状況に応じて行動を選択する。これに対し、ＲｅｆｌｅｘｉｖｅＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓＬａｙｅｒは、外部刺激に応じて反射的を行動する。これら２つのオブジェクトによる行動選択は独立して行なわれるため、互いに選択された行動モジュール（スキーマ）を機体上で実行する場合に、ロボット１のハードウェア・リソースが競合して実現不可能なこともある。Ｒｅｓｏｕｒｃｅｍａｎａｇｅｒというオブジェクトは、ＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓｌａｙｅｒとＲｅｆｌｅｘｉｖｅＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒｓＬａｙｅｒによる行動選択時のハードウェアの競合を調停する。そして、調停結果に基づいて機体動作を実現する各オブジェクトに通知することにより機体が駆動する。
【０１０１】
ＳｏｕｎｄＰｅｒｆｏｒｍｅｒ、ＭｏｔｉｏｎＣｏｎｔｒｏｌｌｅｒ、ＬｅｄＣｏｎｔｒｏｌｌｅｒは、機体動作を実現するオブジェクトである。ＳｏｕｎｄＰｅｒｆｏｒｍｅｒは、音声出力を行なうためのオブジェクトであり、ＲｅｓｏｕｒｃｅＭａｎａｇｅｒ経由でＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒＬａｙｅｒから与えられたテキスト・コマンドに応じて音声合成を行ない、ロボット１の機体上のスピーカから音声出力を行なう。また、ＭｏｔｉｏｎＣｏｎｔｒｏｌｌｅｒは、機体上の各関節アクチュエータの動作を行なうためのオブジェクトであり、ＲｅｓｏｕｒｃｅＭａｎａｇｅｒ経由でＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒＬａｙｅｒから手や脚などを動かすコマンドを受けたことに応答して、該当する関節角を計算する。また、ＬｅｄＣｏｎｔｒｏｌｌｅｒは、ＬＥＤ１９の点滅動作を行なうためのオブジェクトであり、ＲｅｓｏｕｒｃｅＭａｎａｇｅｒ経由でＳｉｔｕａｔｅｄＢｅｈａｖｉｏｒＬａｙｅｒからコマンドを受けたことに応答してＬＥＤ１９の点滅駆動を行なう。
【０１０２】
図５には、状況依存行動階層（ＳＢＬ）１０８（但し、反射行動部１０９を含む）による状況依存行動制御の形態を模式的に示している。認識系１０１〜１０３による外部環境の認識結果は、外部刺激として状況依存行動階層１０８（反射行動部１０９を含む）に与えられる。また、認識系による外部環境の認識結果に応じた内部状態の変化も状況依存行動階層１０８に与えられる。そして、状況依存行動階層１０８では、外部刺激や内部状態の変化に応じて状況を判断して、行動選択を実現することができる。
【０１０３】
状況依存行動階層１０８は、行動モジュール毎にステートマシンを用意しており、それ以前の行動や状況に依存して、センサ入力された外部情報の認識結果を分類して、行動を機体上で発現する。行動モジュールは、機体動作を記述し行動実行に伴う状態遷移（ステートマシン）を実現するａｃｔｉｏｎ機能と、ａｃｔｉｏｎ機能において記述された行動の実行を外部刺激や内部状態に応じて評価して状況判断を行なうｍｏｎｉｔｏｒ機能とを備えたスキーマ（ｓｃｈｅｍａ）として記述される。図６には、状況依存行動階層１０８が複数のスキーマによって構成されている様子を模式的に示している。
【０１０４】
状況依存行動階層１０８（より厳密には、状況依存行動階層１０８のうち、通常の状況依存行動を制御する階層）は、複数のスキーマが階層的に連結されたツリー構造として構成され、外部刺激や内部状態の変化に応じてより最適なスキーマを統合的に判断して行動制御を行なうようになっている。ツリーは、例えば動物行動学的（Ｅｔｈｏｌｏｇｉｃａｌ）な状況依存行動を数式化した行動モデルや、感情表現を実行するためのサブツリーなど、複数のサブツリー（又は枝）を含んでいる。
【０１０５】
図７には、状況依存行動階層１０８におけるスキーマのツリー構造を模式的に示している。同図に示すように、状況依存行動階層１０８は、短期記憶部１０５から外部刺激の通知（Ｎｏｔｉｆｙ）を受けるルート・スキーマを先頭に、抽象的な行動カテゴリから具体的な行動カテゴリに向かうように、各階層毎にスキーマが配設されている。例えば、ルート・スキーマの直近下位の階層では、「探索する（Ｉｎｖｅｓｔｉｇａｔｅ）」、「食べる（Ｉｎｇｅｓｔｉｖｅ）」、「遊ぶ（Ｐｌａｙ）」というスキーマが配設される。そして、「探索する（Ｉｎｖｅｓｔｉｇａｔｅ）」の下位には、「ＩｎｖｅｓｔｉｇａｔｉｖｅＬｏｃｏｍｏｔｉｏｎ」、「ＨｅａｄｉｎＡｉｒＳｎｉｆｆｉｎｇ」、「ＩｎｖｅｓｔｉｇａｔｉｖｅＳｎｉｆｆｉｎｇ」というより具体的な探索行動を記述したスキーマが配設されている。同様に、スキーマ「食べる（Ｉｎｇｅｓｔｉｖｅ）」の下位には「Ｅａｔ」や「Ｄｒｉｎｋ」などのより具体的な飲食行動を記述したスキーマが配設され、スキーマ「遊ぶ（Ｐｌａｙ）」の下位には「ＰｌａｙＢｏｗｉｎｇ」、「ＰｌａｙＧｒｅｅｔｉｎｇ」、「ＰｌａｙＰａｗｉｎｇ」などのより具体的な遊ぶ行動を記述したスキーマが配設されている。
【０１０６】
このようにロボット装置１００の行動制御プログラムは、スキーマのツリー構造によって構成される。このツリー構造の下位のスキーマは、コンテンツ・サーバからダウンロードし、逐次的にインストールすることができる。例えば、「遊ぶ（ｐｌａｙ）」というスキーマの具体的な行動を記述したスキーマや、スキーマの次期バージョンなどをダウンロードして、行動制御システムに随時組み込んでいくことができる。
【０１０７】
図７に示したように、各スキーマは外部刺激と内部状態を入力している。また、各スキーマは、少なくともＭｏｎｉｔｏｒ関数とＡｃｔｉｏｎ関数を備えている。また、図８には、スキーマの内部構成を模式的に示している。同図に示すように、スキーマは、所定の事象の発生に従がって状態（又はステート）が移り変わっていく状態遷移モデル（ステートマシン）の形式で機体動作を記述したＡｃｔｉｏｎ関数と、外部刺激や内部状態に応じてＡｃｔｉｏｎ関数の各状態を評価して活動度レベル値として返すＭｏｎｉｔｏｒ関数と、Ａｃｔｉｏｎ関数のステートマシンをＲＥＡＤＹ（準備完了）、ＡＣＴＩＶＥ（活動中），ＳＬＥＥＰ（待機中）いずれかの状態としてスキーマの状態を記憶管理する状態管理部で構成されている。
【０１０８】
Ｍｏｎｉｔｏｒ関数は、外部刺激と内部状態に応じて当該スキーマの活動度レベル（Ａｃｔｉｖａｔｉｏｎ Ｌｅｖｅｌ：ＡＬ値）を算出する関数である。図７に示すようなツリー構造を構成する場合、上位（親）のスキーマは外部刺激と内部状態を引数として下位（子供）のスキーマのＭｏｎｉｔｏｒ関数をコールすることができ、子供のスキーマはＡＬ値を返り値とする。また、スキーマは自分のＡＬ値を算出するために、さらに子供のスキーマのＭｏｎｉｔｏｒ関数をコールすることができる。そして、ルートのスキーマには各サブツリーからのＡＬ値が返されるので、外部刺激と内部状態の変化に応じた最適なスキーマすなわち行動を統合的に判断することができる。
【０１０９】
図８で示す例では、スキーマすなわち行動モジュールの管理を行なう行動状態制御部（仮称）は、Ｍｏｎｉｔｏｒ関数からの戻り値に基づいて、実行すべき行動を選択し、該当するスキーマのＡｃｔｉｏｎ関数をコールし、あるいは状態管理部に記憶されているスキーマの状態の移行を指示する。例えば行動誘発評価値としての活動度レベルが最も高いスキーマを選択したり、リソースが競合しないように優先順位に従って複数のスキーマを選択したりする。また、行動状態制御部は、より優先順位の高いスキーマが起動し、リソースの競合が生じた場合、優先順位が下位のスキーマの状態をＡＣＴＩＶＥからＳＬＥＥＰに退避させ、競合状態が解かれるとＡＣＴＩＶＥに回復するなど、スキーマの状態を制御する。
【０１１０】
行動状態の制御機能を、状況依存行動階層１０８内のスキーマ毎に分散して配置し階層的に構成することができる。図９に示すように。スキーマがツリー構造を形成している場合、上位（親）のスキーマの行動状態制御は、外部刺激と内部状態を引数として下位（子供）のスキーマのＭｏｎｉｔｏｒ関数をコールし、子供のスキーマから活動度レベルと使用リソースを返り値として受け取る。また、子供のスキーマは、自分の活動度レベルと使用リソースを算出するために、さらに子供のスキーマのＭｏｎｉｔｏｒ関数をコールする。そして、ルートのスキーマの行動状態制御部には、各サブツリーからの活動度レベルと使用リソースが返されるので、外部刺激と内部状態の変化に応じた最適なスキーマすなわち行動を統合的に判断して、Ａｃｔｉｏｎ関数をコールして、子供スキーマの実行を開始したり中断させたりする。
【０１１１】
本実施形態では、ロボット装置１にネイティブのプログラム・コード部分については、高スピード化などの目的のため、Ｃ＋＋などのコンパイラ言語で記述されている。他方、スキーマ・ツリー構造において下位に位置付けられるコード部分など、コンテンツ・サーバからのダウンロードなどにより後から追加されるコード部分については、インストール後のコンパイル処理を不要にするなどの目的のため、ｐｙｔｈｏｎ又はその他のスクリプト言語で記述され、インタープリタ上で実行される。
【０１１２】
また、本実施形態では、ネイティブのコンパイラ言語で記述されたコード部分、並びにダウンロードされるスクリプト形式のコード部分のいずれにおいても、オブジェクト指向言語として構成されている。ここで、ポリモルフィズムを達成するために、言語間におけるクラス継承の問題が生じる。
【０１１３】
ポリモルフィズムを実現するためには、いずれのクラスで関数を呼び出した場合であっても、正しく関数を呼び出すようにする必要がある。例えば、Ｃ＋＋などのコンパイラ言語及びｐｙｔｈｏｎなどのスクリプト言語いずれの側のクラスから関数が呼び出された場合であっても、同名の関数がスクリプト言語側のクラスでオーバーライドされている場合にはその関数を呼び出すが、オーバーライドされていない場合には、コンパイラ言語側のベース・クラスにある関数を呼び出さなければならない。
【０１１４】
ここで、正しいポリモルフィズムの動作を以下に示しておく。但し、コンパイラ言語側のクラスをＢａｓｅとし、これを継承するスクリプト言語のクラスをＳｃｒｉｐｔＳｕｐｅｒとし、呼び出される関数をｆｕｎｃとする。
【０１１５】
【表１】
2005321954.tif 000003
【０１１６】
図１０には、Ｃ＋＋のようなコンパイラ言語とスクリプト言語でそれぞれ記述されたオブジェクトが混在するオブジェクト指向プログラミング環境下におけるプログラム開発手順を模式的に示している。
【０１１７】
Ｃ＋＋などのコンパイラ言語で記述されたソース・プログラムは、コンパイル処理され、さらに他のライブラリと組み合わせて、実行ライブラリを構成する。
【０１１８】
一方、ｐｙｔｈｏｎなどのスクリプト言語で記述されたソース・プログラムは、インタープリタ上で実行する。
【０１１９】
また、Ｃ＋＋のソース・プログラムをトランスレータでトランスレートした後、両言語間でクラス継承する際の言語の相違を吸収するためのラッパー・コードを生成する。
【０１２０】
このラッパー・コードを自動生成するツールとして、ＳＷＩＧ（前述）などが知られている。ＳＷＩＧなどの例では、Ｃ＋＋側のインスタンスのポインタをスクリプト言語側のクラスで保持することで、スクリプト言語側のクラスからＣ＋＋側の関数、メソッドを呼び出すことを実現している。しかし、この場合、スクリプト言語側のインスタンスのポインタをＣ＋＋側で保持していないので、スクリプト言語側のメソッドをＣ＋＋側のクラスから呼び出すことはできない。これは、インタープリタによる実行時でないと関数のオーバーライドを行なっているかどうかを判断できない、という理由に依拠する。
【０１２１】
そこで、本実施形態では、Ｃ＋＋側のクラスのメンバとして、スクリプト言語の継承したオブジェクトの値、継承されたスクリプト言語側のクラスのメンバにＣ＋＋側の基本クラスのインスタンスの値（ｔｈｉｓ）を持たせることによって、Ｃ＋＋とスクリプト言語の相互に呼び出せるラッパー・コードを組み込むようにした。これによってスクリプト言語のクラスをＣ＋＋のクラスの継承関係を持たせることができる。
【０１２２】
図１１には、Ｃ＋＋とスクリプト言語の相互に呼び出せるラッパー・コードを組み込んだ様子を示している。
【０１２３】
図示の例では、Ｃ＋＋言語側では、ユーザ・クラスをベース・クラスが継承し、さらにスーパー・クラスがベース・クラスを継承している。また、スクリプト言語側では、ラッパー・クラスをスクリプト・ユーザ・クラスが継承している。また、両言語間で、ベース・クラスとラッパー・クラスは継承関係にある。
【０１２４】
ここで、Ｃ＋＋言語側のベース・クラス、並びにスクリプト言語側のラップ・クラスは、両言語間で継承関係を成立させるために設けられた、謂わばダミーのクラスである。実体としては、Ｃ＋＋で記述されたユーザ・クラスを継承して、スクリプト・ユーザ・クラスを作成する。
【０１２５】
ベース・クラスはスクリプト言語の継承したオブジェクトの値、継承されたスクリプト言語側のラップ・クラスのメンバにＣ＋＋側のベース・クラスのインスタンスの値（ｔｈｉｓ）を持ち、クラスの継承関係が成立する。
【０１２６】
Ｃ＋＋で記述されたユーザ・クラス（ＵｓｅｒＢａｓｅ）を継承して、スクリプト・ユーザ・クラス（ＳｃｒｉｐｔＳｕｐｅｒ）を作成することを考えた場合の、ユーザ・クラス及びベース・クラスのコードを、図１２に擬似的に示している。また、図１３には、スクリプト言語側でのクラス宣言を擬似的に示している。
【０１２７】
図１４を参照しながら、単純にＣ＋＋側のインスタンスにスクリプト言語側のインスタンスのポインタを相互に持つ場合について考察する。
【０１２８】
図示の例では、Ｃ＋＋側では、スクリプト言語側のクラスと継承関係を持つために、元のクラスＵｓｅｒＢａｓｅからスクリプト言語側のクラスへの継承を直接行なうのではなく、ラッパー・クラスとしてＷｓｕｐｅｒを用意し、Ｗｓｕｐｅｒへ一旦継承する。
【０１２９】
同様に、スクリプト言語側では、Ｃ＋＋言語側からクラス継承を直接行なうのではなく、ラッパー・クラスとしてＳｃｒｉｐｔＢａｓｅを用意する。そして、クラス継承した実体としてのＳｃｒｉｐｔＳｕｐｅｒは、ラッパー・クラスＳｃｒｉｐｔＢａｓｅをクラス継承した形態とする。ユーザはＳｃｒｉｐｔＢａｓｅを継承するとする。
【０１３０】
スクリプト言語側でラッパークラスＳｃｒｉｐｔＢａｓｅのインスタンスが構築される際に、Ｃ＋＋側のラッパー・クラスＷｓｕｐｅｒには、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅのインスタンスのポインタをｐｙ＿ｓｅｌｆとして格納する（１４−１）。また、ＳｃｒｉｐｔＢａｓｅには、Ｃ＋＋側のラッパー・クラスＷｓｕｐｅｒのインスタンスのポインタを、ｔｈｉｓに格納する（１４−２）。これによって、各言語のクラス間で相互に参照することができ、Ｃ＋＋側からスクリプト言語の関数を、スクリプト言語側からＣ＋＋の関数を相互に呼び出すことができる。
【０１３１】
しかし、このように両言語にラッパー・クラスを用意し、それぞれのポインタを格納して相互参照の関係を構成するだけでは、ポリモルフィズムを完全に到達することはできない。すなわち、Ｃ＋＋側のクラスに定義されている関数を、これを継承したスクリプト言語側のクラスにおいてオーバーライドしている場合には、正しく呼び出すことができるが、スクリプト言語側のクラスにおいてオーバーライドしていない場合には関数を呼び出すことができない、という問題がある。
【０１３２】
図１５には、Ｃ＋＋側のクラスで定義されている関数ｆｕｎｃｏｋ１が、これを継承しているスクリプト言語側のクラスでオーバーライドされている場合における関数呼び出しの手順について図解している。図示の例では、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがクラス継承する際に、関数をオーバーライドする処理を行なっている。
【０１３３】
まず、スクリプト言語のクラス側から関数ｆｕｎｃＯＫ１（）を呼び出した場合（１５−１−１）、ｆｕｎｃＯＫ１（）はスクリプト言語のクラスでオーバーライドされているので、適切な関数ＳｃｒｉｐｔＳｕｐｅｒ．ｆｕｎｃＯＫ１（）を呼び出して戻る（１５−１−２）。
【０１３４】
一方、コンパイラ言語のクラス側から関数ｆｕｎｃＯＫ１（）を呼び出した場合（１５−２−１）、ｆｕｎｃＯＫ１（）はＵｓｅｒＢａｓｅからラッパー・クラスであるＷＳｕｐｅｒにより仮想的（ｖｉｒｔｕａｌ）にオーバーライドされているため、仮想関数により、オーバーライドしている適切な関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ１（）が自動的に呼び出される（１５−２−２）。ポリモルフィズム設計では、継承したクラスにおいて関数がオーバーライドされている場合には、オーバーライドされている関数を順次呼び出すようになっている。
【０１３５】
そして、スクリプト言語のインスタンスのポインタｐｙ＿ｓｅｌｆから、スクリプト言語でクラス継承したインスタンスを取り出し、ｆｕｎｃＯＫ１（）を呼び出す。Ｗｓｕｐｅｒには、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅのインスタンスのポインタをｐｙ＿ｓｅｌｆとして格納しているので、スクリプト言語側では、まずラッパー・クラスの関数ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃＯＫ１（）が適切に呼び出される。そして、インタープリタ処理により、この関数をオーバーライドしている適切な関数ＳｃｒｉｐｔＳｕｐｅｒ．ｆｕｎｃＯＫ１が自動的に呼び出される（１５−２−３）。
【０１３６】
このように、Ｃ＋＋側のクラスで定義されている関数がスクリプト言語側のクラスでオーバーライドされている場合には、適切に関数を呼び出すことができる。ところが、スクリプト言語側でオーバーライドされていない場合には、図１４に示した相互参照の仕組みだけでは、関数を正しく呼び出すことができない場合がある。
【０１３７】
図１６には、Ｃ＋＋側のクラスで定義されている関数ｆｕｎｃＮＧが、これを継承しているスクリプト言語側のクラスでオーバーライドされていない場合における関数呼び出しの手順について図解している。図示のように、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがＳｃｒｉｐｔＢａｓｅをクラス継承する際に、関数をオーバーライドする処理を行なっていない。何故ならば、ベース・クラス側ではデフォルトではクラス継承時に関数をオーバーライドしないようになっているからである。
【０１３８】
スクリプト言語のクラス側から関数ｆｕｎｃＮＧ（）を呼び出した場合（１６−１）、ｆｕｎｃＮＧ（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、関数ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃＮＧ（）が呼び出される（１６−２）。ポリモルフィズム設計では、継承先のクラスに該当する関数がない場合には、継承した元のクラス側の関数を呼び出すようになっている。
【０１３９】
ここで、ＵｓｅｒＢａｓｅはラッパークラスであり、クラスでオーバーライドされている関数の実体はないことから、次いで、元のクラス側の関数を呼び出す。ＳｃｒｉｐｔＢａｓｅには、コンパイラ言語側のラッパー・クラスＷｓｕｐｅｒのインスタンスのポインタをｔｈｉｓに格納しているので、コンパイラ言語側では、Ｗｓｕｐｅｒを経由して、元のクラスＵｓｅｒＢａｓｅの関数Ｂａｓｅ：：ｆｕｎｃＮＧ（）が呼び出される（１６−３）。
【０１４０】
関数Ｂａｓｅ：：ｆｕｎｃＮＧ（）は、ＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）でオーバーライドされているので、自動的にＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が呼び出される（１６−４）。ここで、ＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が自動的に呼び出されるのは、Ｃ＋＋で仮想関数を用いるためであり、ＳｃｒｉｐｔＢａｓｅに格納してあるＣ＋＋のインスタンスはＷＳｕｐｅｒで構築されていることから、ＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が自動的に呼び出される。
【０１４１】
そして、スクリプト言語のインスタンスのポインタｐｙ＿ｓｅｌｆから、スクリプト言語でクラス継承したインスタンスを取り出し、関数を呼び出す。Ｗｓｕｐｅｒには、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅのインスタンスのポインタをｐｙ＿ｓｅｌｆとして格納しているので、スクリプト言語側では、まずラッパー・クラスの関数ＳｃｒｉｐｔＢａｓｅ：：ｆｕｎｃＮＧ（）が呼び出される（１６−５）。しかし、この場合はＳｃｒｉｐｔＳｕｐｅｒで関数をオーバーライドしていないことから、元のクラスＵｓｅｒＢａｓｅの関数Ｂａｓｅ：：ｆｕｎｃＮＧ（）が呼び出され（１６−３）、さらにこれをオーバーライドしているＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が自動的に呼び出されてしまい（１６−４）、無限ループに陥ってしまう。
【０１４２】
一方、Ｃ＋＋のクラス側から関数ｆｕｎｃＮＧ（）を呼び出した場合（１６−６）、関数Ｂａｓｅ：：ｆｕｎｃＮＧ（）は、ＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）でオーバーライドされているので、自動的にＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が呼び出される（１６−４）。ここで、ＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が自動的に呼び出されるのは、Ｃ＋＋で仮想関数を用いるためであり、ＳｃｒｉｐｔＢａｓｅに格納してあるＣ＋＋のインスタンスはＷＳｕｐｅｒで構築されていることから、ＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が自動的に呼び出される。
【０１４３】
そして、スクリプト言語のインスタンスのポインタｐｙ＿ｓｅｌｆから、スクリプト言語でクラス継承したインスタンスを取り出し、関数を呼び出す。Ｗｓｕｐｅｒには、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅのインスタンスのポインタをｐｙ＿ｓｅｌｆとして格納しているので、スクリプト言語側では、まずラッパー・クラスの関数ＳｃｒｉｐｔＢａｓｅ：：ｆｕｎｃＮＧ（）が呼び出される（１６−５）。しかし、この場合はＳｃｒｉｐｔＳｕｐｅｒで関数をオーバーライドしていないことから、元のクラスＵｓｅｒＢａｓｅの関数Ｂａｓｅ：：ｆｕｎｃＮＧ（）が呼び出され（１６−３）、さらにこれをオーバーライドしているＷＳｕｐｅｒ：：ｆｕｎｃＮＧ（）が自動的に呼び出されるので（１６−４）、無限ループに陥ってしまう（同上）。
【０１４４】
図１７には、スクリプト言語側の継承クラスＳｃｒｉｐｔＳｕｐｅｒにおいて関数ｆｕｎｃ（）が定義されていない場合に、ＳｃｒｉｐｔＳｕｐｅｒのインスタンスをＣ＋＋側から関数ｆｕｎｃ（）が呼び出されたときの処理を模式的に示している。
【０１４５】
まず、Ｃ＋＋側のクラスＵｓｅｒＢａｓｅから関数ｆｕｎｃ（）を呼ぶ。ここで、ＵｓｅｒＢａｓｅ：：ｆｕｎｃ（）は仮想関数なので、ＷＳｕｐｅｒ：：ｆｕｎｃ（）が呼ばれる。
【０１４６】
ＷＳｕｐｅｒ：：ｆｕｎｃ（）が呼ばれると、ＷＳｕｐｅｒ：：ｆｕｎｃ（）メンバ変数ｐｙ＿ｔｈｉｓの関数ｆｕｎｃ（）を求める。
【０１４７】
ここで、ＳｃｒｉｐｔＳｕｐｅｒでは関数ｆｕｎｃ（）を定義していない（オーバーライドしていない）ため、得られる関数はＳｃｒｉｐｔＢａｓｅのものとなり、ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃ（）を呼び出す。
【０１４８】
ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃ（）では、関数ｔｈｉｓ．ｆｕｎｃ（）を呼び出す。ｔｈｉｓのクラスはＷＳｕｐｅｒであることからＷＳｕｐｅｒ：：ｆｕｎｃ（）が呼ばれる。
【０１４９】
すなわち、ＷＳｕｐｅｒ：：ｆｕｎｃ（）が呼ばれ、無限ループに陥ってしまう。
【０１５０】
このような無限ループを解決する１つの方法として、コンパイラ言語側で用意するラッパー・クラスＷＳｕｐｅｒに、スクリプト言語側で継承されているクラス（但し、ラッパー・クラスを除く）に関数がオーバーライドされているかどうかをチェックする判断機能を装備することを挙げることができる。
【０１５１】
すなわち、ＷＳｕｐｅｒに格納されているスクリプト言語側のインスタンスに属するクラスを取り出し、そのクラスのメンバ関数がオーバーライドされているかどうかを、ＷＳｕｐｅｒでオーバーライドしている関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ（）が呼び出される度に毎回確認する。
【０１５２】
そして、スクリプト言語側でクラス継承したＳｃｒｉｐｔＳｕｐｅｒにおいて関数がオーバーライドされているときにはスクリプト言語側の関数を呼び出すが、オーバーライドされていない場合にはスクリプト言語側の関数を呼び出さず、ＵｓｅｒＢａｓｅから関数Ｂａｓｅ：：ｆｕｎｃＯＫを呼び出すようにし、無限ループへの突入を回避する。
【０１５３】
図１８には、コンパイラ言語側で用意するラッパー・クラスＷＳｕｐｅｒに、スクリプト言語側で継承されているクラスに関数がオーバーライドされているかどうかをチェックする判断機能を装備した場合における関数呼び出しの手順について図解している。図示の例では、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがＳｃｒｉｐｔＢａｓｅをクラス継承する際に、関数をオーバーライドする処理を行なっていない。
【０１５４】
スクリプト言語のクラス側から関数ｆｕｎｃＯＫ１（）を呼び出した場合（１８−１−１）、ｆｕｎｃＯＫ１（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、関数ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃＯＫ１（）が呼び出される（１８−１−２）。ポリモルフィズム設計では、継承先のクラスに該当する関数がない場合には、継承した元のクラス側の関数を呼び出すようになっている。
【０１５５】
ＵｓｅｒＢａｓｅはラッパークラスであり、クラスでオーバーライドされている関数の実体はないことから、次いで、元のクラス側の関数を呼び出す。ＳｃｒｉｐｔＢａｓｅには、コンパイラ言語側のラッパー・クラスＷｓｕｐｅｒのインスタンスのポインタをｔｈｉｓに格納しているので、コンパイラ言語側では、ラッパー・クラスＷＳｕｐｅｒの関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ１（）が呼び出される（１８−１−３）。
【０１５６】
ここで、ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ１（）内部では、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅのインスタンスのポインタｐｙ＿ｓｅｌｆを取り出し、ｐｙ＿ｓｅｌｆが属しているクラスを求める。そのクラスがｆｕｎｋＯＫ１（）をオーバーライドしていれば、スクリプト言語側の関数ｆｕｎｃＯＫ１（）を呼び出すが、そうでなければ、自身がオーバーライドしている関数Ｂａｓｅ：：ｆｕｎｃＯＫ１（）を呼び出す。図示の例では、ｐｙ＿ｓｅｌｆが属しているスクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒは関数をオーバーライドしていないので、関数ｆｕｎｃＯＫ１（）を呼び出す（１８−１−４）。
【０１５７】
一方、Ｃ＋＋のクラス側から関数ｆｕｎｃｏｋ１（）を呼び出した場合（１８−２−１）、ラッパー・クラスＷＳｕｐｅｒにおいて定義されている関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ１（）でオーバーライドされているので、ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ１（）が自動的に呼び出される（１８−２−２）。
【０１５８】
ここで、ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ１（）内部では、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅのインスタンスのポインタｐｙ＿ｓｅｌｆを取り出し、ｐｙ＿ｓｅｌｆが属しているクラスを求める。そして、ｐｙ＿ｓｅｌｆが属しているスクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒは関数をオーバーライドしていないので、関数ｆｕｎｃＯＫ１（）を呼び出す（同上）。
【０１５９】
図１９及び図２０には、上述した解決方法を適用した場合における、Ｃ＋＋でのクラス定義、及びｐｙｔｈｏｎでのクラス定義の記述例をそれぞれ示している。
【０１６０】
なお、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがＳｃｒｉｐｔＢａｓｅをクラス継承する際に、関数をオーバーライドする処理を行なっている場合には、関数呼び出しの動作は、図１５に示した場合と同様となるので、ここでは説明を省略する。
【０１６１】
また、図１６に示したような無限ループを解決する他の方法として、コンパイラ言語側で用意するラッパー・クラスＷＳｕｐｅｒに格納されているスクリプト言語側のインスタンスに属するクラスを取り出し、どの関数を呼び出すべきかをスクリプト言語側のクラスで判断することを挙げることができる。
【０１６２】
この場合、Ｃ＋＋のラッパー・クラスＷＳｕｐｅｒがベース・クラスＵｓｅｒＢａｓｅをクラス継承する際に、ベース・クラスＵｓｅｒＢａｓｅの関数をオーバーライドする以外に、当該ベース・クラスを呼び出すための擬似オーバーライド関数を用意する。また、スクリプト言語側で、ＷＳｕｐｅｒを継承するラッパー・クラスＳｃｒｉｐｔＢａｓｅでは、ベース・クラスＵｓｅｒＢａｓｅの関数をオーバーライドするが、この関数はいずれの関数を呼び出すべきかを判断する。
【０１６３】
ベース・クラスＵｓｅｒＢａｓｅにｆｕｎｃ（）という関数が存在する場合、ラッパー・クラスＷＳｕｐｅｒには、ＵｓｅｒＢａｓｅのｆｕｎｃ（）を呼び出すコードが記述された擬似オーバーライド関数ｆｕｎｃ＿Ｂａｓｅ（）を書いておく。そして、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅでは、ｆｕｎｃ（）をオーバーライドするとともに、このｆｕｎｃ（）には、オーバーライドした基の関数を呼び出すときには、これに代えて擬似オーバーライド関数ＷＳｕｐｅｒ：：ｆｕｎｃ＿Ｂａｓｅ（）を呼び出すように記述する。
【０１６４】
図２１には、どの関数を呼び出すべきかをスクリプト言語側のクラスで判断する機能を装備した場合における関数呼び出しの手順について図解している。図示の例では、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがＳｃｒｉｐｔＢａｓｅをクラス継承する際に、関数をオーバーライドする処理を行なっていない。
【０１６５】
スクリプト言語のクラス側から関数ｆｕｎｃＯＫ２（）を呼び出した場合（２１−１−１）、ｆｕｎｃＯＫ２（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、関数ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃＯＫ２（）が自動的に呼び出される（２１−１−２）。ポリモルフィズム設計では、継承先のクラスに該当する関数がない場合には、継承した元のクラス側の関数を呼び出すようになっている。
【０１６６】
ＳｃｒｉｐｔＢａｓｅはラッパークラスであり、クラスでオーバーライドされている関数の実体はないことから、次いで、元のクラス側の関数を呼び出す。ＳｃｒｉｐｔＢａｓｅには、コンパイラ言語側のラッパー・クラスＷｓｕｐｅｒのインスタンスのポインタをｔｈｉｓに格納しているので、コンパイラ言語側では、ラッパー・クラスＷＳｕｐｅｒを呼び出す。ここで、ｆｕｎｃＯＫ２（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、ＳｃｒｉｐｔＢａｓｅ：：ｆｕｎｃＯＫ２（）がオーバーライドした関数を呼び出すときには、擬似オーバーライド関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ２＿Ｂａｓｅ（）が呼び出される（２１−１−３）。そして、この擬似オーバーライド関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ２＿Ｂａｓｅ（）は、ＵｓｅｒＢａｓｅのｆｕｎｃＯＫ２（）を呼び出す（２１−１−４）。
【０１６７】
一方、Ｃ＋＋のクラス側から関数ｆｕｎｃＯＫ２（）を呼び出した場合（２１−２−１）、ラッパー・クラスＷＳｕｐｅｒにおいて定義されている関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ２（）でオーバーライドされているので、ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ２（）が自動的に呼び出される（２１−２−２）。
【０１６８】
そして、ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ２（）内部では、スクリプト言語側のインスタンスのポインタｐｙ＿ｓｅｌｆから、ＳｃｒｉｐｔＢａｓｅでオーバーライドされている関数ｆｕｎｃＯＫ２を呼び出す（２１−２−３）。
【０１６９】
ＳｃｒｉｐｔＢａｓｅはラッパークラスであり、クラスでオーバーライドされている関数の実体はないことから、次いで、元のクラス側の関数を呼び出す。ＳｃｒｉｐｔＢａｓｅには、コンパイラ言語側のラッパー・クラスＷｓｕｐｅｒのインスタンスのポインタをｔｈｉｓに格納しているので、コンパイラ言語側では、ラッパー・クラスＷＳｕｐｅｒを呼び出す。ここで、ｆｕｎｃＯＫ２（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、ＳｃｒｉｐｔＢａｓｅ：：ｆｕｎｃ（）がオーバーライドした関数を呼び出すときには、擬似オーバーライド関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ２＿Ｂａｓｅ（）が呼び出される（２１−２−３）。そして、この擬似オーバーライド関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ２＿Ｂａｓｅ（）は、ＵｓｅｒＢａｓｅのｆｕｎｃ（）を呼び出す（同上）。
【０１７０】
図２２及び図２３には、上述した解決方法を適用した場合における、Ｃ＋＋でのクラス定義、及びｐｙｔｈｏｎでのクラス定義の記述例をそれぞれ示している。
【０１７１】
なお、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがＳｃｒｉｐｔＢａｓｅをクラス継承する際に、関数をオーバーライドする処理を行なっている場合には、関数呼び出しの動作は、図１５に示した場合と同様となるので、ここでは説明を省略する。
【０１７２】
図２１に示した実施形態の変形例として、スクリプト言語側から呼び出す専用のラッパー・クラスＷｒａｐをＣ＋＋側に用意するようにしてもよい。
【０１７３】
スクリプト言語のクラスに関数がオーバーライドされていない場合に、Ｃ＋＋側でクラス継承を行なう際に、ベース・クラスＵｓｅｒＢａｓｅの関数をオーバーライドしたラッパー・クラスＷＳｕｐｅｒのインスタンスを生成する以外に、ＵｓｅｒＢａｓｅのｆｕｎｃ（）を呼び出すためのコードが記述された擬似オーバーライド関数ｆｕｎｃ＿Ｂａｓｅ（）を定義したラッパー・クラスＷｒａｐのインスタンスを生成する。擬似オーバーライド関数ｆｕｎｃ＿Ｂａｓｅ（）には、ＵｓｅｒＢａｓｅのｆｕｎｃ（）を呼び出すことが書かれている。また、スクリプト言語側で、ＷＳｕｐｅｒを継承するラッパー・クラスＳｃｒｉｐｔＢａｓｅでは、ベース・クラスＵｓｅｒＢａｓｅの関数をオーバーライドするが、Ｃ＋＋側のラッパー・クラスのいずれの関数を呼び出すべきかではなく、いずれのラッパー・クラスを呼び出すべきかを判断する。
【０１７４】
図２４には、この場合の関数呼び出しの実行順序について図解している。図示の例では、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがＳｃｒｉｐｔＢａｓｅをクラス継承する際に、関数をオーバーライドする処理を行なっている。
【０１７５】
まず、スクリプト言語のクラス側から関数ｆｕｎｃＯＫ３（）を呼び出した場合（２４−１−１）、ｆｕｎｃＯＫ３（）はスクリプト言語のクラスでオーバーライドされているので、適切な関数ＳｃｒｉｐｔＳｕｐｅｒ．ｆｕｎｃＯＫ３（）を呼び出して戻る（２４−１−２）。
【０１７６】
一方、コンパイラ言語のクラス側から関数ｆｕｎｃＯＫ３（）を呼び出した場合（２４−２−１）、ｆｕｎｃＯＫ３（）はＵｓｅｒＢａｓｅからラッパー・クラスであるＷＳｕｐｅｒにより仮想的（ｖｉｒｔｕａｌ）にオーバーライドされているため、仮想関数により、オーバーライドしている適切な関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ３（）が自動的に呼び出される（２４−２−２）。ポリモルフィズム設計では、継承したクラスにおいて関数がオーバーライドされている場合には、オーバーライドされている関数を順次呼び出すようになっている。
【０１７７】
そして、スクリプト言語のインスタンスのポインタｐｙ＿ｓｅｌｆから、スクリプト言語でクラス継承したインスタンスを取り出し、ｆｕｎｃＯＫ３（）を呼び出す。Ｗｓｕｐｅｒには、スクリプト言語側のラッパー・クラスＳｃｒｉｐｔＢａｓｅのインスタンスのポインタをｐｙ＿ｓｅｌｆとして格納しているので、スクリプト言語側では、まずラッパー・クラスの関数ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃＯＫ３（）が適切に呼び出される。そして、インタープリタ処理により、この関数をオーバーライドしている適切な関数ＳｃｒｉｐｔＳｕｐｅｒ．ｆｕｎｃＯＫ３が自動的に呼び出される（２４−２−３）。
【０１７８】
また、図２５には、スクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒがＳｃｒｉｐｔＢａｓｅをクラス継承する際に、関数をオーバーライドする処理を行なっていないときの関数呼び出しの実行順序について図解している。
【０１７９】
スクリプト言語のクラス側から関数ｆｕｎｃＯＫ４（）を呼び出した場合（２５−１−１）、ｆｕｎｃＯＫ４（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、関数ＳｃｒｉｐｔＢａｓｅ．ｆｕｎｃＯＫ４（）が自動的に呼び出される（２５−１−２）。ポリモルフィズム設計では、継承先のクラスに該当する関数がない場合には、継承した元のクラス側の関数を呼び出すようになっている。
【０１８０】
ＳｃｒｉｐｔＢａｓｅはラッパークラスであり、クラスでオーバーライドされている関数の実体はないことから、次いで、元のクラス側の関数を呼び出す。ここで、ｆｕｎｃＯＫ４（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、Ｃ＋＋側のラッパー・クラスＷｒａｐを呼び出す（２５−１−３）。このラッパー・クラスＷｒａｐには擬似オーバーライド関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ４＿Ｂａｓｅ（）が定義されており、ＵｓｅｒＢａｓｅのｆｕｎｃＯＫ４（）を呼び出す（２５−１−４）。
【０１８１】
一方、Ｃ＋＋のクラス側から関数ｆｕｎｃＯＫ４（）を呼び出した場合（２５−２−１）、ラッパー・クラスＷＳｕｐｅｒにおいて定義されている関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ４（）でオーバーライドされているので、ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ４（）が自動的に呼び出される（２５−２−２）。
【０１８２】
そして、ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ４（）内部では、スクリプト言語側のインスタンスのポインタｐｙ＿ｓｅｌｆから、ＳｃｒｉｐｔＢａｓｅでオーバーライドされている関数ｆｕｎｃＯＫ４を呼び出す（２５−２−３）。
【０１８３】
ＳｃｒｉｐｔＢａｓｅはラッパークラスであり、クラスでオーバーライドされている関数の実体はないことから、次いで、元のクラス側の関数を呼び出す。ここで、ｆｕｎｃＯＫ４（）はスクリプト言語で継承したクラスＳｃｒｉｐｔＳｕｐｅｒでオーバーライドされていないので、Ｃ＋＋側のラッパー・クラスＷｒａｐを呼び出す。このラッパー・クラスＷｒａｐには擬似オーバーライド関数ＷＳｕｐｅｒ：：ｆｕｎｃＯＫ４＿Ｂａｓｅ（）が定義されており、ＵｓｅｒＢａｓｅのｆｕｎｃＯＫ４（）を呼び出す（同上）。
【０１８４】
図２６及び図２７には、上述した解決方法を適用した場合における、Ｃ＋＋でのクラス定義、及びｐｙｔｈｏｎでのクラス定義の記述例をそれぞれ示している。
【０１８５】
図２８には、Ｃ＋＋側のベース・クラスＵｓｅｒＢａｓｅを継承するスクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒのインスタンスを構築するとき（コンストラクタ）の実行順序を図解している。
【０１８６】
まず、ＳｃｒｉｐｔＳｕｐｅｒ．＿＿ｉｎｉｔ＿＿（）が呼ばれる（２８−１）。
【０１８７】
次いで、ＳｃｒｉｐｔＢａｓｅ．＿＿ｉｎｉｔ＿＿（）を呼び出す（２８−２）。
【０１８８】
次いで、ＷＳｕｐｅｒ：：ＷＳｕｐｅｒ（）を呼び出す（２８−３）。
【０１８９】
このとき、Ｃ＋＋では、自動的にベース・クラスから初期化されるため、ＵｓｅｒＢａｓｅ：：ＵｓｅｒＢａｓｅ（）が呼ばれる（２８−４）。
【０１９０】
そして、ＵｓｅｒＢａｓｅ：：ＵｓｅｒＢａｓｅ（）の後、ＷＳｕｐｅｒ：：ＷＳｕｐｅｒ（）が呼ばれる（２８−５）。
【０１９１】
ＷＳｕｐｅｒ：：ＷＳｕｐｅｒ（）が終わった後、ＳｃｒｉｐｔＢａｓｅのｔｈｉｓにＣ＋＋のインスタンスのポインタを格納する（２８−６）。
【０１９２】
Ｃ＋＋のメンバ変数に、スクリプト言語側のインスタンスのポインタを書き込むため、ＷＳｕｐｅｒ．ｓｅｔ＿ｓｅｌｆ（）を呼ぶ（２８−７）。
【０１９３】
ＷＳｕｐｅｒ：：ｓｅｔ＿ｓｅｌｆ（）でスクリプト言語のインスタンスのポインタを格納した後、戻る（２８−８）。
【０１９４】
そして、ＳｃｒｉｐｔＢａｓｅ．＿ｉｎｉｔ＿（）から戻るとともに（２８−９）、ＳｃｒｉｐｔＳｕｐｅｒ．＿ｉｎｉｔ＿（）から戻る（２８−１０）。
【０１９５】
また、図２９には、ＳｃｒｉｐｔＳｕｐｅｒのインスタンスを消滅するとき（デストラクタ）の実行順序を図解している。
【０１９６】
まず、ＳｃｒｉｐｔＳｕｐｅｒ．＿＿ｄｅｌ＿＿（）が呼ばれると（２９−１）、ＳｃｒｉｐｔＢａｓｅ．＿＿ｄｅｌ＿＿（）が呼ばれる（２９−２）。
【０１９７】
そして、ＳｃｒｉｐｔＢａｓｅのメンバ変数ｔｈｉｓの値からＷＳｕｐｅｒ：：〜ＷＳｕｐｅｒ（）を呼び出す（２９−３）。
【０１９８】
次いで、ＷＳｕｐｅｒ：：〜ＷＳｕｐｅｒ（）が呼び出され（２９−４）、ＵｓｅｒＢａｓｅ：：〜ＵｓｅｒＢａｓｅ（）が呼び出される（２９−５）。
【０１９９】
このようにコンストラクタ及びデストラクタが機能することにより、結果として、図３０に示すように、仮想的にＣ＋＋のクラスをスクリプト言語側のクラスが継承したように見える。
【産業上の利用可能性】
【０２００】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。
【０２０１】
本発明の要旨は、必ずしも「ロボット」と称される製品には限定されない。すなわち、電気的若しくは磁気的な作用を用いて人間の動作に似せた運動を行なう機械装置であるならば、例えば玩具等のような他の産業分野に属する製品であっても、同様に本発明を適用することができる。
【０２０２】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【図面の簡単な説明】
【０２０３】
【図１】図１は、本発明に実施に供されるロボット装置１の機能構成を模式的に示した図である。
【図２】図２は、制御ユニット２０の構成を示した図である。
【図３】図３は、本発明の実施形態に係るロボット装置１の行動制御システム１００の機能構成を模式的に示した図である。
【図４】図４は、行動制御システム１００のオブジェクト構成を模式的に示した図である。
【図５】図５は、状況依存行動階層（ＳＢＬ）１０８（但し、反射行動部１０９を含む）による状況依存行動制御の形態を模式的に示した図である。
【図６】図６は、状況依存行動階層１０８が複数のスキーマによって構成されている様子を模式的に示した図である。
【図７】図７は、状況依存行動階層１０８におけるスキーマのツリー構造を模式的に示した図である。
【図８】図８は、スキーマの内部構成を模式的に示した図である。
【図９】図９は、スキーマがツリー構造を形成している場合における行動状態制御のメカニズムを説明するための図である。
【図１０】図１０は、Ｃ＋＋のようなコンパイラ言語とスクリプト言語でそれぞれ記述されたオブジェクトが混在するオブジェクト指向プログラミング環境下におけるプログラム開発手順を模式的に示した図である。
【図１１】図１１は、Ｃ＋＋とスクリプト言語の相互に呼び出せるラッパー・コードを組み込んだ様子を示した図である。
【図１２】図１２は、Ｃ＋＋で記述されたユーザ・クラス（ＵｓｅｒＢａｓｅ）を継承して、スクリプト・ユーザ・クラス（Ｓｃｒｉｐｔ＿Ｓｕｐｅｒ）を作成することを考えた場合の、ユーザ・クラス及びベース・クラスのコードを示した図である。
【図１３】図１３は、スクリプト言語側でのクラス宣言を擬似的に示した図である。
【図１４】図１４は、Ｃ＋＋側のインスタンスにスクリプト言語側のインスタンスのポインタを相互に持つ様子を示した図である。
【図１５】図１５は、Ｃ＋＋側のクラスで定義されている関数ｆｕｎｃｏｋ１が、これを継承しているスクリプト言語側のクラスでオーバーライドされている場合における関数呼び出しの実行順序を説明するための図である。
【図１６】図１６は、Ｃ＋＋側のクラスで定義されている関数ｆｕｎｃｏｋ１が、これを継承しているスクリプト言語側のクラスでオーバーライドされていない場合における関数呼び出しの実行順序を説明するための図である。
【図１７】図１７は、スクリプト言語側の継承クラスＳｃｒｉｐｔＳｕｐｅｒにおいて関数ｆｕｎｃ（）が定義されていない場合に、関数呼び出しにより無限ループに陥る動作を説明するための図である。
【図１８】図１８は、コンパイラ言語側で用意するラッパー・クラスＷＳｕｐｅｒに、スクリプト言語側で継承されているクラスに関数がオーバーライドされているかどうかをチェックする判断機能を装備した場合における関数呼び出しの実行順序を説明するための図である。
【図１９】図１９は、図１８に示した解決方法を適用した場合におけるＣ＋＋でのクラス定義の記述例を示した図である。
【図２０】図２０は、図１８に示した解決方法を適用した場合におけるｐｙｔｈｏｎでのクラス定義の記述例を示した図である。
【図２１】図２１は、どの関数を呼び出すべきかをスクリプト言語側のクラスで判断する機能を装備した場合における関数呼び出しの実行順序を説明するための図である。
【図２２】図２２は、図２１に示した解決方法を適用した場合におけるＣ＋＋でのクラス定義の記述例を示した図である。
【図２３】図２３は、図２１に示した解決方法を適用した場合におけるｐｙｔｈｏｎでのクラス定義の記述例を示した図である。
【図２４】図２４は、図２１に示した関数呼び出しの実行順序の変形例を説明するための図である。
【図２５】図２５は、図２１に示した関数呼び出しの実行順序の変形例を説明するための図である。
【図２６】図２６は、図２５に示した解決方法を適用した場合におけるＣ＋＋でのクラス定義の記述例を示した図である。
【図２７】図２７は、図２５に示した解決方法を適用した場合におけるｐｙｔｈｏｎでのクラス定義の記述例を示した図である。
【図２８】図２８は、Ｃ＋＋側のベース・クラスＵｓｅｒＢａｓｅを継承するスクリプト言語側のクラスＳｃｒｉｐｔＳｕｐｅｒのインスタンスを構築するとき（コンストラクタ）の実行順序を説明するための図である。
【図２９】図２９は、ＳｃｒｉｐｔＳｕｐｅｒのインスタンスを消滅するとき（デストラクタ）の実行順序を説明するための図である。
【図３０】図３０は、仮想的にＣ＋＋のクラスをスクリプト言語側のクラスが継承した様子を示した図である。
【図３１】図３１は、本発明に係るロボット装置を取り巻くネットワーク構成を模式的に示した図である。
【符号の説明】
【０２０４】
１…ロボット装置
１５…ＣＣＤカメラ
１６…マイクロフォン
１７…スピーカ
１８…タッチ・センサ
１９…ＬＥＤインジケータ
２０…制御部ユニット
２１…ＣＰＵ
２２…ＲＡＭ
２３…ＲＯＭ
２４…不揮発メモリ
２５…インターフェース
２６…無線通信インターフェース
２８…バス
４０…入出力部
５０…駆動部
５１…モータ
５２…エンコーダ
５３…ドライバ
【図１】
2005321954.tif 000004
【図２】
2005321954.tif 000005
【図３】
2005321954.tif 000006
【図４】
2005321954.tif 000007
【図５】
2005321954.tif 000008
【図６】
2005321954.tif 000009
【図７】
2005321954.tif 000010
【図８】
2005321954.tif 000011
【図９】
2005321954.tif 000012
【図１０】
2005321954.tif 000013
【図１１】
2005321954.tif 000014
【図１２】
2005321954.tif 000015
【図１３】
2005321954.tif 000016
【図１４】
2005321954.tif 000017
【図１５】
2005321954.tif 000018
【図１６】
2005321954.tif 000019
【図１７】
2005321954.tif 000020
【図１８】
2005321954.tif 000021
【図１９】
2005321954.tif 000022
【図２０】
2005321954.tif 000023
【図２１】
2005321954.tif 000024
【図２２】
2005321954.tif 000025
【図２３】
2005321954.tif 000026
【図２４】
2005321954.tif 000027
【図２５】
2005321954.tif 000028
【図２６】
2005321954.tif 000029
【図２７】
2005321954.tif 000030
【図２８】
2005321954.tif 000031
【図２９】
2005321954.tif 000032
【図３０】
2005321954.tif 000033
【図３１】
2005321954.tif 000034