JP2014085732A - 異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置 - Google Patents
異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置 Download PDFInfo
- Publication number
- JP2014085732A JP2014085732A JP2012232391A JP2012232391A JP2014085732A JP 2014085732 A JP2014085732 A JP 2014085732A JP 2012232391 A JP2012232391 A JP 2012232391A JP 2012232391 A JP2012232391 A JP 2012232391A JP 2014085732 A JP2014085732 A JP 2014085732A
- Authority
- JP
- Japan
- Prior art keywords
- file
- functional element
- middleware
- source code
- ros
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
- Stored Programmes (AREA)
Abstract
【課題】
相互運用したいミドルウェアのブリッジモジュールの自動生成方法及び装置を提供する。
【解決手段】
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、を備えている。
【選択図】図１
相互運用したいミドルウェアのブリッジモジュールの自動生成方法及び装置を提供する。
【解決手段】
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、を備えている。
【選択図】図１
Description
本発明は、異なる規格からなるロボットミドルウェアの相互運用を行うための、あるミドルウェア上で稼働しているプログラムを、別のミドルウェア上からも制御・通信できるようにするために、プログラム自体を仮想化し情報を変換するブリッジと呼ばれる変換モジュールを生成する技術に関するものである。
従来、ロボット研究分野ではオープンソースのOSや開発環境を活用することはあっても、その研究のコアとなる知的な情報処理モジュールに関してはオープンになることは無かったが、ここ数年、ロボット分野においてもオープンソースソフトウェアが、特に海外を中心に急速に拡がりを見せている。ロボット用オープンソースプロジェクトとしては、米国のWillowGarage社が展開するROS(Robot Operating System)、欧州におけるOrocosやiCub/Yarp等のプロジェクト、日本におけるOpenRTMプロジェクトが知られており、それぞれロボットを開発するためのミドルウェアを提供している。
このようなロボットミドルウェアは、ロボットを構成する要素（アクチュエータやセンサ）やロボットを制御するソフトウェアを、機能要素モジュールとして部品化するための技術であり、用途に応じて機能要素モジュールを適宜組み合わせるだけで、様々なロボットを開発することができる。例えば、OpenRTMプロジェクトであるOpenRTM-aistでは、ロボットシステムを作る際に、機能要素モジュール(RTC：RTコンポー ネント) ごとにプログラムを作成し、RTコンポーネントを繋ぎ合わせることでロボットシステムを構築する。
上述のように、規格の異なる複数のロボットミドルウェアが存在することから、従来は、ロボットミドルウェア毎に独立して開発が進められてきた傾向があり、これらを連携させる試みはあまり行われてこなかった。これらの異なるタイプのロボットミドルウェアを連携しようとする場合には、いわゆるブリッジモジュールを逐一手作業で開発することになり、ミドルウェアのバージョンアップや対象とするプログラムの機能更新、変更等が起こると、ブリッジモジュールが機能せず、再度、人手をかけて開発しなおす必要があった。
ブリッジモジュールの生成を自動で行えれば、逐一人手による作業が発生せず効率化につながるばかりでなく、ミドルウェアやプログラムの更新や変更に迅速に対応できるようになるが、そのための方法論は明らかでなかった。特許文献は、データ中継用ＲＴコンポーネント生成方法について開示するが、同じ規格のミドルウェアのコンポーネント間のミスマッチに対応するものである。
特開２０１１−８６１８２号
本発明は、相互運用したいミドルウェアの分析に基づいたブリッジモジュールの自動生成方法及び装置を提供するものである。
本発明が採用した技術手段は、
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成法であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、
を備えた自動生成方法、ないし、
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成装置であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成する手段と、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成する手段と、
を備えた自動生成装置、である。
本発明は、ハードウェアとしてのコンピュータ（入力部、出力部、演算部、記憶部、表示部等を備える）と、コンピュータに所定の機能を実行させるようなソフトウェアとの協働によって実現され、各ファイルないしプログラムは１つあるいは複数のコンピュータの記憶部に記憶されている。
本発明は、第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールを自動生成するために、コンピュータを所定の手段として機能させるためのコンピュータプログラムとして実現される。
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成法であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、
を備えた自動生成方法、ないし、
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成装置であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成する手段と、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成する手段と、
を備えた自動生成装置、である。
本発明は、ハードウェアとしてのコンピュータ（入力部、出力部、演算部、記憶部、表示部等を備える）と、コンピュータに所定の機能を実行させるようなソフトウェアとの協働によって実現され、各ファイルないしプログラムは１つあるいは複数のコンピュータの記憶部に記憶されている。
本発明は、第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールを自動生成するために、コンピュータを所定の手段として機能させるためのコンピュータプログラムとして実現される。
１つの態様では、 前記変換モジュールを生成するステップは、
前記ソースコードと、
前記第１のインターフェース定義から生成したソースコードと、
前記第２のインターフェース定義から生成したソースコードと、
を用いて、変換モジュールを生成する。
インターフェース定義ファイルは、各ミドルウェア毎に規定されており、OpenRTMでは、ＩＤＬファイルであり、ＲＯＳでは、メッセージファイル、サービスファイルである。他のミドルウェアにおいても、これらに対応するインターフェース定義ファイルが備わっており、これらを用いて処理できることが当業者に理解される。
「前記第１のインターフェース定義から生成したソースコード」は、図１Ａに示すフローチャート（ＲＯＳ→ＲＴＭ）では「メッセージファイル／サービスファイルをＲＯＳコンパイラ（ＲＯＳメッセージ・サービスコンパイラ）で生成した.py」であり、図１Ｂに示すフローチャート（ＲＴＭ→ＲＯＳ）では「ＩＤＬをＩＤＬコンパイラで処理して生成した.cpp,.h」である。
「前記第２のインターフェース定義から生成したソースコード」は、図１Ａに示すフローチャート（ＲＯＳ→ＲＴＭ）では「ＩＤＬメッセーをＩＤＬコンパイラで生成した.py」であり、図１Ｂに示すフローチャート（ＲＴＭ→ＲＯＳ）では「メッセージファイル／サービスファイルをＲＯＳコンパイラ（ＲＯＳメッセージ・サービスコンパイラ）で処理して生成した.cpp,.h」である。
前記ソースコードと、
前記第１のインターフェース定義から生成したソースコードと、
前記第２のインターフェース定義から生成したソースコードと、
を用いて、変換モジュールを生成する。
インターフェース定義ファイルは、各ミドルウェア毎に規定されており、OpenRTMでは、ＩＤＬファイルであり、ＲＯＳでは、メッセージファイル、サービスファイルである。他のミドルウェアにおいても、これらに対応するインターフェース定義ファイルが備わっており、これらを用いて処理できることが当業者に理解される。
「前記第１のインターフェース定義から生成したソースコード」は、図１Ａに示すフローチャート（ＲＯＳ→ＲＴＭ）では「メッセージファイル／サービスファイルをＲＯＳコンパイラ（ＲＯＳメッセージ・サービスコンパイラ）で生成した.py」であり、図１Ｂに示すフローチャート（ＲＴＭ→ＲＯＳ）では「ＩＤＬをＩＤＬコンパイラで処理して生成した.cpp,.h」である。
「前記第２のインターフェース定義から生成したソースコード」は、図１Ａに示すフローチャート（ＲＯＳ→ＲＴＭ）では「ＩＤＬメッセーをＩＤＬコンパイラで生成した.py」であり、図１Ｂに示すフローチャート（ＲＴＭ→ＲＯＳ）では「メッセージファイル／サービスファイルをＲＯＳコンパイラ（ＲＯＳメッセージ・サービスコンパイラ）で処理して生成した.cpp,.h」である。
１つの態様では、第１のタイプのロボット機能要素モジュールの入出力は、第１のインターフェース定義により当該第１のタイプのロボット機能要素モジュールのプログラム実行前に規定されており、前記解析は、当該プログラム実行前に行われる。
いわゆるオフライン変換方式であり、ロボット機能要素モジュールの第１のインターフェース定義ファイル（例えば、コンポーネントのＩＤＬファイル）を解析し、そこから対応した第２のインターフェース定義ファイル（ノードのメッセージファイル、サービスファイル）を生成し、ブリッジモジュールのソースコードを生成する方式である。
いわゆるオフライン変換方式であり、ロボット機能要素モジュールの第１のインターフェース定義ファイル（例えば、コンポーネントのＩＤＬファイル）を解析し、そこから対応した第２のインターフェース定義ファイル（ノードのメッセージファイル、サービスファイル）を生成し、ブリッジモジュールのソースコードを生成する方式である。
１つの態様では、第１のミドルウェアは、OpenRTM (Open Robot Middleware)であり、第１のタイプのロボット機能要素モジュールはOpenRTMのコンポーネントであり、前記第１のインターフェース定義はIDLファイルである。
１つの態様では、第２のミドルウェアは、ROS(Robot Operating System)であり、第２のタイプのロボット機能要素モジュールはROSのノードであり、前記第２のインターフェース定義ファイルはメッセージファイルないしサービスファイルである。
この場合、OpenRTMのコンポーネントプログラムからＲＯＳのノードプログラムを提供するブリッジモジュールを生成する。
より具体的な態様では、第１のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、第２のタイプのロボット機能要素モジュールは、ROSのノードであり、
前記コンポーネントのIDLファイルを解析して、ノードのメッセージファイルあるいは／およびサービスファイルと、ソースコードと、を生成するステップと、
IDLコンパイラによって前記IDLファイルのソースコードを生成するステップと、
ROSコンパイラによって前記メッセージファイルあるいは／およびサービスファイルのソースコードを生成するステップと、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する。
１つの態様では、第２のミドルウェアは、ROS(Robot Operating System)であり、第２のタイプのロボット機能要素モジュールはROSのノードであり、前記第２のインターフェース定義ファイルはメッセージファイルないしサービスファイルである。
この場合、OpenRTMのコンポーネントプログラムからＲＯＳのノードプログラムを提供するブリッジモジュールを生成する。
より具体的な態様では、第１のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、第２のタイプのロボット機能要素モジュールは、ROSのノードであり、
前記コンポーネントのIDLファイルを解析して、ノードのメッセージファイルあるいは／およびサービスファイルと、ソースコードと、を生成するステップと、
IDLコンパイラによって前記IDLファイルのソースコードを生成するステップと、
ROSコンパイラによって前記メッセージファイルあるいは／およびサービスファイルのソースコードを生成するステップと、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する。
１つの態様では、第１のタイプのロボット機能要素モジュールの入出力は、当該第１のタイプのロボット機能要素モジュールのプログラム実行時に特定されるようになっており、前記解析は、当該プログラム実行時に行われる。
１つの態様では、いわゆるオンライン変換方式であり、起動している第１のタイプのロボット機能要素モジュール（例えば、ノードプログラム）の入出力を規定する第１のインターフェース定義ファイル（例えば、メッセージファイル、サービスファイル）を調べ、これに対応した第２のインターフェース定義ファイル（例えば、ＩＤＬファイル）並びにブリッジモジュールのソースコードを生成する方式である。
１つの態様では、いわゆるオンライン変換方式であり、起動している第１のタイプのロボット機能要素モジュール（例えば、ノードプログラム）の入出力を規定する第１のインターフェース定義ファイル（例えば、メッセージファイル、サービスファイル）を調べ、これに対応した第２のインターフェース定義ファイル（例えば、ＩＤＬファイル）並びにブリッジモジュールのソースコードを生成する方式である。
１つの態様では、第１のミドルウェアは、ROS(Robot Operating System)であり、第１のタイプのロボット機能要素モジュールはROSのノードであり、前記入出力は、実行されているノードのトピックのメッセージファイルあるいは／およびサービスのサービスファイルを解析することで取得される。
１つの態様では、第２のミドルウェアは、OpenRTM (Open Robot Middleware)であり、第２のタイプのロボット機能要素モジュールはOpenRTMのコンポーネントであり、前記第２のインターフェース定義ファイルはＩＤＬファイルである。
この場合、ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成する。
より具体的な態様では、第１のタイプのロボット機能要素モジュールは、ROSのノードであり、第２のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、
前記ノードのメッセージファイルあるいは／およびサービスファイルを解析して、コンポーネントのIDLファイルと、ソースコードと、を生成するステップと、
ROSコンパイラによって前記メッセージファイルあるいは／およびサービスファイルのソースコードを生成するステップと、
IDLコンパイラによって前記生成されたIDLファイルのソースコードを生成するステップと、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する。
１つの態様では、第２のミドルウェアは、OpenRTM (Open Robot Middleware)であり、第２のタイプのロボット機能要素モジュールはOpenRTMのコンポーネントであり、前記第２のインターフェース定義ファイルはＩＤＬファイルである。
この場合、ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成する。
より具体的な態様では、第１のタイプのロボット機能要素モジュールは、ROSのノードであり、第２のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、
前記ノードのメッセージファイルあるいは／およびサービスファイルを解析して、コンポーネントのIDLファイルと、ソースコードと、を生成するステップと、
ROSコンパイラによって前記メッセージファイルあるいは／およびサービスファイルのソースコードを生成するステップと、
IDLコンパイラによって前記生成されたIDLファイルのソースコードを生成するステップと、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する。
本発明によってブリッジモジュールの生成を自動で行うことができ、逐一人手による作業が発生せず効率化につながるばかりでなく、ミドルウェアやプログラムの更新や変更に迅速に対応できるようになる。
【図１】本実施形態に係るブリッジモジュールの概念図である。
【図１Ａ】ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成するためのフローチャートを示す。
【図１Ｂ】OpenRTMのコンポーネントプログラムからＲＯＳのノードプログラムを提供するブリッジモジュールを生成するためのフローチャートを示す。
【図２Ａ】RTコンポーネントアーキテクチャを示す図である（http://www.openrtm.org/openrtm/ja/content/openrtm-aist-official-websiteから引用）。
【図２Ｂ】ノードの概念を示す図である（（公序良俗違反につき、不掲載）から引用）。
【図３Ａ】ROSのナビゲーションノードを示す。中央の楕円はノードであり、ノードの周囲の複数の矩形はそれぞれトピックを示している。トピックからノードへ向かう→は入力（サブスクライブ）で、ノードからトピックへ向かう→は出力（パブリッシュ）である。
【図３Ｂ】自動生成されたROSナビゲーション機能を提供するRTMコンポーネントを示す。中央の縦長方形がコンポーネントであり、左側に入力ポート、右側に出力ポートが備わっている。
【図３Ｃ】ROSノードからOpenRTMコンポーネントブリッジを自動生成している様子を示す。
【図４】OpenRTMコンポーネントからROSノードを自動生成している様子を示す。
【図５Ａ】ROSのノード情報の例を示す。
【図５Ｂ】ROSのノード情報の例を示す。
【図５Ｃ】ROSのノード情報の例を示す。
【図６Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｄ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｅ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｆ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｇ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｈ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図７Ａ】自動変換用プログラムによって自動生成されたIDLの例を示す。
【図７Ｂ】自動変換用プログラムによって自動生成されたIDLの例を示す。
【図８Ａ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｂ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｃ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｄ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｅ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｆ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｇ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図９】OpenRTMのIDLの例を示す。
【図９Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｄ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｅ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１０Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１０Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１０Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１１Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１１Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１２】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１３】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１４】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１５】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１６】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１７】自動変換用プログラムによって自動生成されたメッセージファイルの例を示す。
【図１８Ａ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｂ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｃ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｄ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｅ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｆ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｇ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｈ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｉ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｊ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｋ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｌ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１Ａ】ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成するためのフローチャートを示す。
【図１Ｂ】OpenRTMのコンポーネントプログラムからＲＯＳのノードプログラムを提供するブリッジモジュールを生成するためのフローチャートを示す。
【図２Ａ】RTコンポーネントアーキテクチャを示す図である（http://www.openrtm.org/openrtm/ja/content/openrtm-aist-official-websiteから引用）。
【図２Ｂ】ノードの概念を示す図である（（公序良俗違反につき、不掲載）から引用）。
【図３Ａ】ROSのナビゲーションノードを示す。中央の楕円はノードであり、ノードの周囲の複数の矩形はそれぞれトピックを示している。トピックからノードへ向かう→は入力（サブスクライブ）で、ノードからトピックへ向かう→は出力（パブリッシュ）である。
【図３Ｂ】自動生成されたROSナビゲーション機能を提供するRTMコンポーネントを示す。中央の縦長方形がコンポーネントであり、左側に入力ポート、右側に出力ポートが備わっている。
【図３Ｃ】ROSノードからOpenRTMコンポーネントブリッジを自動生成している様子を示す。
【図４】OpenRTMコンポーネントからROSノードを自動生成している様子を示す。
【図５Ａ】ROSのノード情報の例を示す。
【図５Ｂ】ROSのノード情報の例を示す。
【図５Ｃ】ROSのノード情報の例を示す。
【図６Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｄ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｅ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｆ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｇ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図６Ｈ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図７Ａ】自動変換用プログラムによって自動生成されたIDLの例を示す。
【図７Ｂ】自動変換用プログラムによって自動生成されたIDLの例を示す。
【図８Ａ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｂ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｃ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｄ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｅ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｆ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図８Ｇ】上記ソースコード（メイン）とＩＤＬの２つのファイルを生成すると共に、これら２つのファイルを使ってOpenRTMノードを作るプログラムの例を示す。
【図９】OpenRTMのIDLの例を示す。
【図９Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｄ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図９Ｅ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１０Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１０Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１０Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１１Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１１Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。
【図１２】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１３】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１４】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１５】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１６】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。
【図１７】自動変換用プログラムによって自動生成されたメッセージファイルの例を示す。
【図１８Ａ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｂ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｃ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｄ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｅ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｆ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｇ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｈ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｉ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｊ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｋ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【図１８Ｌ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
［Ａ］ロボットミドルウェア
ロボットミドルウェアは、ロボット機能要素のソフトウエアモジュールを複数組み合わせてロボットシステムを構築するためのソフトウエアプラットフォームである。ロボットミドルウェアとしては、米国のWillowGarage社が展開するROS(Robot Operating System)、欧州におけるOrocosやiCub/Yarp等のプロジェクト、日本におけるOpenRTMプロジェクトが知られている。また、企業が独自に開発したミドルウェアも存在する。ここでは、ROSとOpenRTM-aistを例にとって、本実施形態を説明するが、本発明が適用されるミドルウェアは、ROSとOpenRTM-aistに限定されないことが当業者に理解される。
ロボットミドルウェアは、ロボット機能要素のソフトウエアモジュールを複数組み合わせてロボットシステムを構築するためのソフトウエアプラットフォームである。ロボットミドルウェアとしては、米国のWillowGarage社が展開するROS(Robot Operating System)、欧州におけるOrocosやiCub/Yarp等のプロジェクト、日本におけるOpenRTMプロジェクトが知られている。また、企業が独自に開発したミドルウェアも存在する。ここでは、ROSとOpenRTM-aistを例にとって、本実施形態を説明するが、本発明が適用されるミドルウェアは、ROSとOpenRTM-aistに限定されないことが当業者に理解される。
［Ａ−１］ROS(Robot Operating System)
ROSの詳細については、（公序良俗違反につき、不掲載）を参照することができる。ここでは、本実施形態の理解に必要なROSに関連する用語を幾つか説明する。以下の記載には、前記ウェブサイトの記載の翻訳に基づく記述が含まれる。
ROSの詳細については、（公序良俗違反につき、不掲載）を参照することができる。ここでは、本実施形態の理解に必要なROSに関連する用語を幾つか説明する。以下の記載には、前記ウェブサイトの記載の翻訳に基づく記述が含まれる。
［Package（パッケージ）］
パッケージ(package)は、まとまった機能を提供するソフトウェア群が含まれるフォルダないし開発用のファイルの集合である。パッケージはROSにおけるメインユニットであり、ROSのソフトウェアは、パッケージ内で組織化されている。パッケージには、ROSのランタイムプロセス（ノード）、ROS依存ライブラリ、データセット、コンフィギュレーションファイル、その他有用に組織化され得るファイルが含まれている。
パッケージ(package)は、まとまった機能を提供するソフトウェア群が含まれるフォルダないし開発用のファイルの集合である。パッケージはROSにおけるメインユニットであり、ROSのソフトウェアは、パッケージ内で組織化されている。パッケージには、ROSのランタイムプロセス（ノード）、ROS依存ライブラリ、データセット、コンフィギュレーションファイル、その他有用に組織化され得るファイルが含まれている。
［Node（ノード）］
ノードは、計算の実行するプロセスであり、ROSを用いて他のノードと通信可能な実行ファイルである。ノードは、ソフトウェアの１つの機能単位、すなわち、ロボット機能要素モジュールである。ロボット制御システムは多くのノードから構成される。
ノードは、計算の実行するプロセスであり、ROSを用いて他のノードと通信可能な実行ファイルである。ノードは、ソフトウェアの１つの機能単位、すなわち、ロボット機能要素モジュールである。ロボット制御システムは多くのノードから構成される。
［msg files（メッセージファイル）］
Message（メッセージ）は、トピックをサブスクライブあるいはパブリッシングする時に用いられるROSデータ型である。ノードは、このメッセージを渡すことによって互いに通信する。メッセージは、型付けられたフィールドを含むシンプルなデータ構造である。メッセージのデータ構造は、シンプルなテキストファイルであるメッセージファイルによって特定される。メッセージファイルは、１行につき、フィールド型とフィールドネームを伴うシンプルテキストファイルである。フィールド型としては、「int8, int16, int32, int64 (plus uint*)」、「float32, float64」、「string」、「time, duration」、「other msg files」、「variable-length array[] and fixed-length array[C]」がある。メッセージファイルは、異なる言語におけるメッセージのためのソースコードの生成に用いられる。メッセージファイルは、パッケージのメッセージディレクトリに格納されている。Message(msg)types（メッセージ型）は、パッケージ内に格納されたメッセージ記述であり、ROS内で送信されるメッセージのデータ構造を定義する。
Message（メッセージ）は、トピックをサブスクライブあるいはパブリッシングする時に用いられるROSデータ型である。ノードは、このメッセージを渡すことによって互いに通信する。メッセージは、型付けられたフィールドを含むシンプルなデータ構造である。メッセージのデータ構造は、シンプルなテキストファイルであるメッセージファイルによって特定される。メッセージファイルは、１行につき、フィールド型とフィールドネームを伴うシンプルテキストファイルである。フィールド型としては、「int8, int16, int32, int64 (plus uint*)」、「float32, float64」、「string」、「time, duration」、「other msg files」、「variable-length array[] and fixed-length array[C]」がある。メッセージファイルは、異なる言語におけるメッセージのためのソースコードの生成に用いられる。メッセージファイルは、パッケージのメッセージディレクトリに格納されている。Message(msg)types（メッセージ型）は、パッケージ内に格納されたメッセージ記述であり、ROS内で送信されるメッセージのデータ構造を定義する。
［srv files（サービスファイル）］
サービスは、サービスファイルを用いて定義され、サービスファイルは、ＲＯＳクライアントライブラリによってソースコードにコンパイルされる。サービスファイルは、サービスを記述し、リクエストとリスポンスの２つからなる。サービスファイルは、リクエストとリスポンスの２つを含むことを除いて、メッセージファイルと同様である。サービスファイルの例として、「int64 A」、「int64 B」、「int64 Sum」を示す。A、Bは要求（request）で、Sumは応答（response）である。サービスファイルは、パッケージのサービスディレクトリに格納されている。Service (srv)types（サービス型）は、パッケージ内に格納されたサービス記述であり、ROS内のサービスの要求（request）及び応答（response） データ構造を定義する。
サービスは、サービスファイルを用いて定義され、サービスファイルは、ＲＯＳクライアントライブラリによってソースコードにコンパイルされる。サービスファイルは、サービスを記述し、リクエストとリスポンスの２つからなる。サービスファイルは、リクエストとリスポンスの２つを含むことを除いて、メッセージファイルと同様である。サービスファイルの例として、「int64 A」、「int64 B」、「int64 Sum」を示す。A、Bは要求（request）で、Sumは応答（response）である。サービスファイルは、パッケージのサービスディレクトリに格納されている。Service (srv)types（サービス型）は、パッケージ内に格納されたサービス記述であり、ROS内のサービスの要求（request）及び応答（response） データ構造を定義する。
［Topic(トピック)］
ROSでは、データの送受信はトピックを用いて実行される。トピックは、名前付けられたバスであり、それを通してノードがメッセージを交換する。ノード（publishers）は、メッセージを所与のトピックに対してパブリッシュすることによって当該メッセージを送信する。トピックはメッセージの内容を特定する名前である。あるデータに関心のあるノード（subscribers）は、適当なトピックに対してサブスクライブする。パブリッシャーはデータを提供する側で、サブスクライバーはデータを受け取る側である。１つのトピックに対して同時に多数のパブリッシャー及びサブスクライバーが存在し得る。また、１つのノードが多数のトピックに対してパブリッシュおよび／あるいはサブスクライブし得る。一般に、パブリッシャー及びサブスクライバーは互いの存在を認知しない。論理的には、トピックは、強固に型付けられたメッセージバスとして捉えることができる。各バスは名前を有しており、誰でもバスにコネクトしてメッセージ（所定の型を備えた）の送信・受信が可能である。ノードは必要なトピックにアクセスして、データを受け取る。トピックは、一方向のストリーミング通信を意図しており、リクエストに対する応答の受信を実行するノードは、サービスを用いることになる。
ROSでは、データの送受信はトピックを用いて実行される。トピックは、名前付けられたバスであり、それを通してノードがメッセージを交換する。ノード（publishers）は、メッセージを所与のトピックに対してパブリッシュすることによって当該メッセージを送信する。トピックはメッセージの内容を特定する名前である。あるデータに関心のあるノード（subscribers）は、適当なトピックに対してサブスクライブする。パブリッシャーはデータを提供する側で、サブスクライバーはデータを受け取る側である。１つのトピックに対して同時に多数のパブリッシャー及びサブスクライバーが存在し得る。また、１つのノードが多数のトピックに対してパブリッシュおよび／あるいはサブスクライブし得る。一般に、パブリッシャー及びサブスクライバーは互いの存在を認知しない。論理的には、トピックは、強固に型付けられたメッセージバスとして捉えることができる。各バスは名前を有しており、誰でもバスにコネクトしてメッセージ（所定の型を備えた）の送信・受信が可能である。ノードは必要なトピックにアクセスして、データを受け取る。トピックは、一方向のストリーミング通信を意図しており、リクエストに対する応答の受信を実行するノードは、サービスを用いることになる。
Publisher Nodeのコード例を示す（上記ウェブサイトから抜粋）
pub = rospy.Publisher("chatter", String)は、このノードが、メッセージ型Stringを用いてchatterトピックに対してパブリッシュすることを宣言している。
pub = rospy.Publisher("chatter", String)は、このノードが、メッセージ型Stringを用いてchatterトピックに対してパブリッシュすることを宣言している。
Subscriber Nodeのコード例を示す（上記ウェブサイトから抜粋）
rospy.Subscriber("chatter"，String，callback)は、このノードが、メッセージ型Stringのchatterトピックをサブスクライブすることを宣言する。
rospy.Subscriber("chatter"，String，callback)は、このノードが、メッセージ型Stringのchatterトピックをサブスクライブすることを宣言する。
［Service(サービス)］
サービスは、データの送受信ではなく、ある操作に対して、そのレスポンスを受け取るような場合（要求／応答の実行）に用いられる。サービスは、要求(request)と応答(reply)の一対のメッセージによって定義される。提供されるＲＯＳノードは、名前の下でサービスを提供し、クライアントは、リクエストメッセージを送信することでサービスを呼び、応答を待つ。サービスは関数の呼び出しないしremote procedure callに類似する。
サービスは、データの送受信ではなく、ある操作に対して、そのレスポンスを受け取るような場合（要求／応答の実行）に用いられる。サービスは、要求(request)と応答(reply)の一対のメッセージによって定義される。提供されるＲＯＳノードは、名前の下でサービスを提供し、クライアントは、リクエストメッセージを送信することでサービスを呼び、応答を待つ。サービスは関数の呼び出しないしremote procedure callに類似する。
Service Nodeのコード例を示す（上記ウェブサイトから抜粋）
Client Nodeのコード例を示す（上記ウェブサイトから抜粋）
［Ａ−２］OpenRTM-aist
OpenRTM-aistの詳細については、http://www.openrtm.org/openrtm/ja/content/openrtm-aist-official-websiteを参照することができる。ここでは、本実施形態の理解に必要なOpenRTM-aistに関連する用語を幾つか説明する。以下の記載には、前記ウェブサイトの記載の援用が含まれる。
OpenRTM-aistの詳細については、http://www.openrtm.org/openrtm/ja/content/openrtm-aist-official-websiteを参照することができる。ここでは、本実施形態の理解に必要なOpenRTM-aistに関連する用語を幾つか説明する。以下の記載には、前記ウェブサイトの記載の援用が含まれる。
［RTコンポーネント（RTC）］
OpenRTM-aistでは、ロボット機能要素をソフトウエアモジュール化したものをRTコ ンポーネント(RT-Component:RTC)と呼ぶ。RTコンポーネントには、他のRTコンポーネントとデータをやり取りしたり、通信したりするためのポートと呼 ばれるインターフェースを備えている。ロボットシステムを作る際に、機能要素 (RTコンポーネント) ごとにプログラムを作成し、RTコンポーネントをつなぎ合わせることでシステムを構築する。RTシステムは、複数のＲＴコンポーネントのポート（データ通信用のエンドポイント）をつなぎ合わせ、それぞれのRTコンポーネント機能の集合体として構築される。RTC開発者は、自己が保有する制御アルゴリズムのコードや、既存のライブラリコード等 (コアロジックと呼ぶ) を、RTCBuilder等のツールによって自動生成されるRTCの雛型コードに埋め込み、コンパイル (スクリプト言語では不要) することで、RTCを作成することができる。
OpenRTM-aistでは、ロボット機能要素をソフトウエアモジュール化したものをRTコ ンポーネント(RT-Component:RTC)と呼ぶ。RTコンポーネントには、他のRTコンポーネントとデータをやり取りしたり、通信したりするためのポートと呼 ばれるインターフェースを備えている。ロボットシステムを作る際に、機能要素 (RTコンポーネント) ごとにプログラムを作成し、RTコンポーネントをつなぎ合わせることでシステムを構築する。RTシステムは、複数のＲＴコンポーネントのポート（データ通信用のエンドポイント）をつなぎ合わせ、それぞれのRTコンポーネント機能の集合体として構築される。RTC開発者は、自己が保有する制御アルゴリズムのコードや、既存のライブラリコード等 (コアロジックと呼ぶ) を、RTCBuilder等のツールによって自動生成されるRTCの雛型コードに埋め込み、コンパイル (スクリプト言語では不要) することで、RTCを作成することができる。
［データポート］
データポートは主に連続的なデータをRTC間で送受信するためのポートであり、データを他のRTCへ送信するためのデータポート（OutPort）、他のRTCからデータを受信するためのデータポート（InPort）の２種類がある。１つのRTCは必要に応じて任意の数のデータポートを備える。例えば、 センサからデータを取得するコンポーネントを作る場合には、このコンポーネントは少なくとも一つのセンサデータを出力するためのOutPortが必要となる。あるいは、指定されたトルク値に従って、モータを駆動するコンポーネントを作る場合には、このコンポーネントは、少なくとも一つの一つのトルク値指令を受け取るInPortが必要になる。これらのコンポーネントを利用して、フィー ドバック制御を行うための制御器 (コントローラ) コンポーネントを作る場合には、センサデータを受け取るInPort、指令値 (例えば速度指令)を受け取るInPort、トルク値を出力するOutPortのそれぞれが必要となる。データポートにはそれぞれ特有の型があり、データポートの型の定義はIDL(Interface Definition Language)という言語非依存のインターフェース定義言語によって定められている。同じデータ型同士なら、言語やOSが異なっていても、ネットワークを介して接続・通信することができる。
データポートは主に連続的なデータをRTC間で送受信するためのポートであり、データを他のRTCへ送信するためのデータポート（OutPort）、他のRTCからデータを受信するためのデータポート（InPort）の２種類がある。１つのRTCは必要に応じて任意の数のデータポートを備える。例えば、 センサからデータを取得するコンポーネントを作る場合には、このコンポーネントは少なくとも一つのセンサデータを出力するためのOutPortが必要となる。あるいは、指定されたトルク値に従って、モータを駆動するコンポーネントを作る場合には、このコンポーネントは、少なくとも一つの一つのトルク値指令を受け取るInPortが必要になる。これらのコンポーネントを利用して、フィー ドバック制御を行うための制御器 (コントローラ) コンポーネントを作る場合には、センサデータを受け取るInPort、指令値 (例えば速度指令)を受け取るInPort、トルク値を出力するOutPortのそれぞれが必要となる。データポートにはそれぞれ特有の型があり、データポートの型の定義はIDL(Interface Definition Language)という言語非依存のインターフェース定義言語によって定められている。同じデータ型同士なら、言語やOSが異なっていても、ネットワークを介して接続・通信することができる。
［サービスポート］
ロボットシステムを構築するためには、コンポーネント間のデータ通信に加えて、コマンドレベル(あるいは関数レベル)のコンポーネント間通信が必要となる。例えば、ロボットアームを制御するマニピュレータコンポーネントの場合、手先の位置や速度などは、上位のアプリケーションやコンポーネントからデータポートで送られるべきデータである。一方、ロボットアームの各種設定、座標系の設定、制御パラメータの設定、動作モードの設定、等については、マニピュレータオブジェクトに対して、setCoordinationSystem( )、setParameter( )、 setMode( )、等の関数を用意し、これらの関数を必要に応じて適切なタイミングで呼ぶ。サービスポートはこのようなコマンドレベルのコンポーネント間のやり取りを行うための仕組みを提供する。一般にサービスとは、機能的に関連のあるひとまとまりのコマンド(関数、メ ソッド、オペレーションなどとも呼ばれる) 群であり、OpenRTM-aistにおいては、この機能を提供する側をサービスプロバイダ(Service Provider)、機能を利用する側をサービスコンシューマ(Service Consumer)と呼ぶ。RTコンポーネントはデータポート同様、任意の数のサービスポートを持つことができる。また、サービスポートには、任意の種類、数のプロバイダまたはコンシューマを付加することができる。プロバイダおよびコンシューマをまとめてインターフェースまたは、サービスインターフェースと呼び、これらサービスインターフェースを持つポートをサービスポートと呼ぶ。データポート同様、言語、OSが異なって いてもインターフェース型が同じなら接続し関数を呼び出すことができる。「同じ型」とは同一のインターフェース定義を持つことである。
ロボットシステムを構築するためには、コンポーネント間のデータ通信に加えて、コマンドレベル(あるいは関数レベル)のコンポーネント間通信が必要となる。例えば、ロボットアームを制御するマニピュレータコンポーネントの場合、手先の位置や速度などは、上位のアプリケーションやコンポーネントからデータポートで送られるべきデータである。一方、ロボットアームの各種設定、座標系の設定、制御パラメータの設定、動作モードの設定、等については、マニピュレータオブジェクトに対して、setCoordinationSystem( )、setParameter( )、 setMode( )、等の関数を用意し、これらの関数を必要に応じて適切なタイミングで呼ぶ。サービスポートはこのようなコマンドレベルのコンポーネント間のやり取りを行うための仕組みを提供する。一般にサービスとは、機能的に関連のあるひとまとまりのコマンド(関数、メ ソッド、オペレーションなどとも呼ばれる) 群であり、OpenRTM-aistにおいては、この機能を提供する側をサービスプロバイダ(Service Provider)、機能を利用する側をサービスコンシューマ(Service Consumer)と呼ぶ。RTコンポーネントはデータポート同様、任意の数のサービスポートを持つことができる。また、サービスポートには、任意の種類、数のプロバイダまたはコンシューマを付加することができる。プロバイダおよびコンシューマをまとめてインターフェースまたは、サービスインターフェースと呼び、これらサービスインターフェースを持つポートをサービスポートと呼ぶ。データポート同様、言語、OSが異なって いてもインターフェース型が同じなら接続し関数を呼び出すことができる。「同じ型」とは同一のインターフェース定義を持つことである。
［インターフェース定義］
OpenRTM-aistでは、インターフェースはIDLと呼ばれるCORBAのインターフェー ス定義言語によって定義する。IDLは言語に依存しないインターフェース定義方法を提供し、またIDLコンパイラを利用することで、各種言語に対応したコード（スタブやスケルトン）が自動的に生成される。スタブは、リモートのオブジェクトを呼び出すためのプロキシオブジェクトのためのコードであり、スケルトンは、プロバイダを実装するためのベースとなるコードである。これら自動生成されるコードによって、異なる言語同士の呼び出しをシームレスに行うことができる。例えば、C++で実装されたプロバイダを、Pythonや Java等で容易に呼び出すことができる。
OpenRTM-aistでは、インターフェースはIDLと呼ばれるCORBAのインターフェー ス定義言語によって定義する。IDLは言語に依存しないインターフェース定義方法を提供し、またIDLコンパイラを利用することで、各種言語に対応したコード（スタブやスケルトン）が自動的に生成される。スタブは、リモートのオブジェクトを呼び出すためのプロキシオブジェクトのためのコードであり、スケルトンは、プロバイダを実装するためのベースとなるコードである。これら自動生成されるコードによって、異なる言語同士の呼び出しをシームレスに行うことができる。例えば、C++で実装されたプロバイダを、Pythonや Java等で容易に呼び出すことができる。
以下は、OpenRTM-aistのサンプルで使用されているIDL定義である（上記ウェブサイトから抜粋）。
moduleはC++の名前空間に相当し、これによりインターフェース名の衝突を防ぐ。C言語等と同様にtypedefキーワードがある。上記例では、sequence（動的配列型）を定義している。１つは、string(文字列型)型のリストとしてEchoList型、もう１つはfloat型のリストとしてValueList型を定義している。次にinterfaceで始まる部分が実際のインターフェースの定義になる。MyServiceインターフェースには、5つの関数(オペレーション)が定義されている。C言語やJavaなどと類似の定義であるが、IDLでは引数が入力であるか出力であるかを明確にするために、引数宣言の前に、in, out またはinoutの修飾子が付く。
moduleはC++の名前空間に相当し、これによりインターフェース名の衝突を防ぐ。C言語等と同様にtypedefキーワードがある。上記例では、sequence（動的配列型）を定義している。１つは、string(文字列型)型のリストとしてEchoList型、もう１つはfloat型のリストとしてValueList型を定義している。次にinterfaceで始まる部分が実際のインターフェースの定義になる。MyServiceインターフェースには、5つの関数(オペレーション)が定義されている。C言語やJavaなどと類似の定義であるが、IDLでは引数が入力であるか出力であるかを明確にするために、引数宣言の前に、in, out またはinoutの修飾子が付く。
［IDLコンパイル］
定義されたIDLをIDLコンパイラに与えてコンパイルを行うと、通常スタブとスケルトン (またはサーバとクライアントと呼ぶ場合もある)のためのコードが生成される。クライアント、すなわちサービスを利用する側は、スタブコードのインクルード等により、スタブとして定義されているプロキシ(代理)オブジェクトを利用して、リモートにある、サーバの機能にアクセスする。IDLを定義して、コンパイルすることで、分散オブジェクトを定義し利用するのに必要な大半のコードが自動的に生成される。IDLの定義方法自体については、C言語やJavaに携わる当業者において比較的容易に定義できるので、詳細な説明は省略する。
定義されたIDLをIDLコンパイラに与えてコンパイルを行うと、通常スタブとスケルトン (またはサーバとクライアントと呼ぶ場合もある)のためのコードが生成される。クライアント、すなわちサービスを利用する側は、スタブコードのインクルード等により、スタブとして定義されているプロキシ(代理)オブジェクトを利用して、リモートにある、サーバの機能にアクセスする。IDLを定義して、コンパイルすることで、分散オブジェクトを定義し利用するのに必要な大半のコードが自動的に生成される。IDLの定義方法自体については、C言語やJavaに携わる当業者において比較的容易に定義できるので、詳細な説明は省略する。
［Ｂ］異なるタイプのロボットミドルウェア間を連携する変換モジュール
異なる規格からなるロボットミドルウェアの相互運用を行うための、あるミドルウェア上で稼働しているプログラムを、別のミドルウェア上からも制御・通信できるようにするために、プログラム自体を仮想化し情報を変換するブリッジと呼ばれる変換モジュールを生成する。ブリッジモジュールの生成を自動で行えれば、逐一人手による作業が発生せず効率化につながるばかりでなく、ミドルウェアやプログラムの更新や変更に迅速に対応できるようになる。
異なる規格からなるロボットミドルウェアの相互運用を行うための、あるミドルウェア上で稼働しているプログラムを、別のミドルウェア上からも制御・通信できるようにするために、プログラム自体を仮想化し情報を変換するブリッジと呼ばれる変換モジュールを生成する。ブリッジモジュールの生成を自動で行えれば、逐一人手による作業が発生せず効率化につながるばかりでなく、ミドルウェアやプログラムの更新や変更に迅速に対応できるようになる。
「ブリッジ」とは、２つのシステムや構成単位の間で情報を交換する装置（ソフトウェアを含む）である。このような、ブリッジモジュールは、ハードウェアとしてのコンピュータ（入力部、出力部、演算部、記憶部、表示部等を備える）と、コンピュータに所定の機能を実行させるようなソフトウェアとの協働によって実現される。
本実施形態では、相互運用したいミドルウェアの分析に基づいたブリッジモジュールの自動生成方法を提供するものである。ロボット機能要素モジュールの自動変換はオンライン方式とオフライン方式の２つの方法で解決し得ることを示し、プログラムの入出力が静的（プログラム実行前）に明らかなミドルウェアではオンライン方式が、そうでない場合にはオフライン方式を採用する。ブリッジモジュールの自動生成として、オンラインの変換方式とオフラインの変換方式、具体的には、実行しているプログラムの入出力を調べこれに対応したインターフェース定義ファイルとプログラムを生成するオンラインの変換方式と、インターフェース定義ファイルの解析から対応するプログラムを生成するオフラインの変換方式と、を提案する。いずれの方式も、「インターフェース定義ファイル（広義）」と「ソースコード」を生成し、ブリッジモジュールを実現する。従来、そのための具体的な手続きは明らかになっていなかったが、本実施形態では、ブリッジモジュールの自動生成にはオンラインとオフラインの２つの方式があることを示し、対象となるミドルウェアの分析によりどちらの方法を採用すればよいかという、手続を与える。
［Ｂ−１］OpenRTM-ROS自動相互運用システム
ROSのノードプログラムから自動的にROSとOpenRTMの間で情報を変換するブリッジコンポーネントないしブリッジモジュールを生成することができれば、簡便にROSノードプログラムをOpenRTMから利用できるだけでなく、将来ROSのノードプログラムの仕様に変更があった際にも、OpenRTM側で明示的に対応する必要なく、継続的にブリッジコンポーネントを利用することが出来るようになる。
ROSのノードプログラムから自動的にROSとOpenRTMの間で情報を変換するブリッジコンポーネントないしブリッジモジュールを生成することができれば、簡便にROSノードプログラムをOpenRTMから利用できるだけでなく、将来ROSのノードプログラムの仕様に変更があった際にも、OpenRTM側で明示的に対応する必要なく、継続的にブリッジコンポーネントを利用することが出来るようになる。
OpenRTMとROSを対比すると、ミドルウェアの構成単位（ロボット機能要素モジュール）は、前者がＲＴコンポーネントで、後者がノードであり、ＲＴコンポーネントとノードが対応する。OpenRTMでは、「サービスポート」と「データポート」が提供される。データポートはデータを送受信するためのポートである。サービスポートはデータの送受信だけでなく、特定の関数をリモートから実行させる仕組みと考えられる。サービスのリクエストに対して、その成否結果を返すことができる。ROSでは、「トピック」と「サービス」が提供される。トピックは、一方向のストリーミング通信を意図しており、トピックの内容を特定するメッセージを記述するメッセージファイルは、異なる言語におけるメッセージのためのソースコードを生成することに用いられる。リクエストに対する応答の受信を実行するノードは、サービスを用いる。サービスの内容を特定するサービスファイルは、要求と応答の２つからなり、パッケージのサービスディレクトリに格納されている。OpenRTMのデータポートとROSのトピック、OpenRTMのサービスポートとROSのサービスが、前者は一方向のデータの流れ（データ送受信）、後者はデータを送りその結果を受け取る（関数呼び出し）、という意味で同じ機能をさしている。
OpenRTMのコンポーメントプログラムは、コンポーネントに対応したＩＤＬファイルを解析することで、そのコンポーネントがどのようなデータポートポート、および／あるいは、サービスポートを提供するかわかる。一方、ROSのプログラムは、プログラムの中身を解析しない限り、プログラムがどのような入出力を持つかは分からない。より具体的には、稼働しているROSモジュールの入出力のトピック、サービスの種類と、そこでやりとりされるメッセージファイル（トピックの場合）、サービスファイル（サービスの場合）の種類を解析する必要がある。ＲＯＳのメッセージファイルはIDLのなかでデータ型として定義でき、ＲＯＳのサービスファイルはIDLの関数呼び出しに対応する。
オンライン変換方式によりROSのノードプログラムからOpenRTMのコンポーネントプログラムを生成するツールと、オフライン変換方式によりOpenRTMのコンポーネントプログラムからROSのノードプログラムを生成するツールと、を開発した。
［Ｂ−２］オンライン変換方式
オンライン変換方式は、起動しているノードプログラムの入出力を調べ、これに対応したidlファイル並びにブリッジモジュールのソースコードを生成する方式である。
オンライン変換方式は、起動しているノードプログラムの入出力を調べ、これに対応したidlファイル並びにブリッジモジュールのソースコードを生成する方式である。
オンライン変換方式は、ロボットミドルウェアシステムのロボット機能要素モジュールのプログラムの入出力が、当該プログラムを実行するまで明らかでないようなシステムを対象とした場合に有効な方法である。例えば、ＲＯＳのノードプログラムにおいては、メッセージインターフェース定義ファイルはデータの入出力を定義するが、それがどのノードプログラムが提供するものなのかは明記されていないため、ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成する場合は、オンライン変換方式が適切である。
ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成するためのフローチャートを図１Ａに示す。
ROSからOpenRTMへの変換例を図５Ａ〜図８Ｇに示す。
図５Ａ〜図５Ｃ（rosnode.info.txt）ROSのノード情報を例示している。
図６Ａ〜図６Ｈ（rosbridge_idl.py）は、本実施形態に係る自動変換用プログラムを用いて自動生成されたソースコードである。
図７Ａ、７Ｂは（rosbridge.idl）は、本実施形態に係る自動変換用プログラムを用いて自動生成されたIDLファイルである。
図８Ａ〜図８Ｇ（rtmros-data-bridge.py）は、上記２つのファイル（ソースコードとＩＤＬファイル）を生成し、また、これらのファイルを使ってOpenRTMノードを作る自動変換用プログラム（いわば、変換プログラム実行制御ソースコード）である。ブリッジモジュールは、自動変換用プログラムによって生成される。
さらに、図１Ａを参照して説明する。
（１） ＲＯＳノードのｍｓｇ、ｓｒｖ（ｍｓｇファイル、ｓｒｖファイル）を自動変換用プログラム（図８Ａ〜図８Ｇ）で解析し、処理することで、「ＩＤＬファイル（図７Ａ、７Ｂ）」と「メインソースコード（図６Ａ〜６Ｈ）」が同時に生成される。メインソースコード（本実施形態ではPythonファイル）は、異ミドルウェア間変換ソースコード（の本体部分）であり、いわばミドルウェア変換コアソースコードである。
（２） ＲＯＳノードのｍｓｇ、ｓｒｖファイルを公知のＲＯＳコンパイラで処理することで、インターフェースソースファイル（Pythonファイル）が生成される。
（３） （１）で生成された「ＩＤＬファイル」を公知のＩＤＬコンパイラで処理することで、「ＩＤＬファイル」のソースコード（Pythonファイル）を生成する。
（４） 上記３つのソースコードを、自動変換用プログラム（図８Ａ〜図８Ｇ）を用いて処理してブリッジプログラムを生成する。
ROSからOpenRTMへの変換例を図５Ａ〜図８Ｇに示す。
図５Ａ〜図５Ｃ（rosnode.info.txt）ROSのノード情報を例示している。
図６Ａ〜図６Ｈ（rosbridge_idl.py）は、本実施形態に係る自動変換用プログラムを用いて自動生成されたソースコードである。
図７Ａ、７Ｂは（rosbridge.idl）は、本実施形態に係る自動変換用プログラムを用いて自動生成されたIDLファイルである。
図８Ａ〜図８Ｇ（rtmros-data-bridge.py）は、上記２つのファイル（ソースコードとＩＤＬファイル）を生成し、また、これらのファイルを使ってOpenRTMノードを作る自動変換用プログラム（いわば、変換プログラム実行制御ソースコード）である。ブリッジモジュールは、自動変換用プログラムによって生成される。
さらに、図１Ａを参照して説明する。
（１） ＲＯＳノードのｍｓｇ、ｓｒｖ（ｍｓｇファイル、ｓｒｖファイル）を自動変換用プログラム（図８Ａ〜図８Ｇ）で解析し、処理することで、「ＩＤＬファイル（図７Ａ、７Ｂ）」と「メインソースコード（図６Ａ〜６Ｈ）」が同時に生成される。メインソースコード（本実施形態ではPythonファイル）は、異ミドルウェア間変換ソースコード（の本体部分）であり、いわばミドルウェア変換コアソースコードである。
（２） ＲＯＳノードのｍｓｇ、ｓｒｖファイルを公知のＲＯＳコンパイラで処理することで、インターフェースソースファイル（Pythonファイル）が生成される。
（３） （１）で生成された「ＩＤＬファイル」を公知のＩＤＬコンパイラで処理することで、「ＩＤＬファイル」のソースコード（Pythonファイル）を生成する。
（４） 上記３つのソースコードを、自動変換用プログラム（図８Ａ〜図８Ｇ）を用いて処理してブリッジプログラムを生成する。
図３Ａは、ROSのナビゲーションノードを示す。中央の楕円はノードであり、ノードの周囲の複数の矩形はそれぞれトピックを示している。トピックからノードへ向かう→は入力（サブスクライブ）で、ノードからトピックへ向かう→は出力（パブリッシュ）である。図３Ｂは、自動生成されたROSナビゲーション機能を提供するRTMコンポーネントを示す。中央の縦長方形がコンポーネントであり、左側に入力ポート、右側に出力ポートが備わっている。図３Ｃにおいて、左側はROSのナビゲーションチュートリアルが生成される二次元のナビゲーションシミュレータ (上)と、そのセンサ情報表示 (下)あり、右図はそこで稼動しているROSのナビゲーションノードから自動的に生成されたOpenRTMのナビゲーションコンポーネントを表示している様子になっており、OpenRTMの入出力でROSのナビゲーション機能を利用できるようになっている。
［Ｂ−３］オフライン変換方式
オフライン変換方式は、コンポーメントのインターフェース定義ファイルであるＩＤＬファイルを解析し、そこから対応したインターフェース定義ファイル（メッセージファイル、サービスファイル）を生成し、ブリッジモジュールのソースコードを生成する方式である。
オフライン変換方式は、コンポーメントのインターフェース定義ファイルであるＩＤＬファイルを解析し、そこから対応したインターフェース定義ファイル（メッセージファイル、サービスファイル）を生成し、ブリッジモジュールのソースコードを生成する方式である。
オフライン変換方式は、ロボットミドルウェアシステムのロボット機能要素モジュールのプログラムの入出力がインターフェース定義ファイルに明記されている場合に有効な方法である。例えば、OpenRTMのコンポーメントプログラムは、コンポーネントに対応したインターフェース定義ファイルを解析することで、そのコンポーネントがどのようなデータポートポート、および／あるいは、サービスポートを提供するかわかるため、OpenRTMのコンポーネントプログラムからＲＯＳのノードプログラムを提供するブリッジモジュールを生成する場合はオフライン変換方式が適切である。
OpenRTMのコンポーネントプログラムからＲＯＳのノードプログラムを提供するブリッジモジュールを生成するためのフローチャートを図１Ｂに示す。
OpenRTMからROSへの変換例を図９〜図１８に示す。
図９（MyService.idl）は、OpenRTMのIDLファイルを例示する。
図９Ａ〜図９Ｅ（MyServiceROSBridge.cpp）、図１０Ａ〜図１０Ｃ（ MyServiceROSBridge.h）、図１１Ａ、１１Ｂ（MyServiceROSBridgeComp.cpp）は、本実施形態に係る自動変換用プログラムを用いて自動生成されたソースコード（メイン）を示す。
図１２（SimpleService_MyService_echo.srv）、
図１３（SimpleService_MyService_get_echo_history.srv）、
図１４（SimpleService_MyService_get_value.srv）、
図１５（SimpleService_MyService_get_value_history.srv、
図１６（SimpleService_MyService_set_value.srv）、
図１７（StringMultiArray.msg）、
は、本実施形態に係る自動変換用プログラムを用いて自動生成されたサービスファイル、メッセージファイルである。
図１８Ａ〜１８Ｌ（idl2srv.py）は、OpenRTMのIDLファイルから、上記２つのファイル（ソースコードと、メッセージファイル／サービスファイル）を生成する自動変換用プログラム（いわば、変換プログラム実行制御ソースコード）である。
さらに、図１Ｂを参照して説明する。
（１） ＲＴＭコンポーネントのＩＤＬファイルを自動変換用プログラムで解析し、処理することで、「メッセージ（msg）ファイル、サービス（srv）ファイル」と「ソースコード（Main） cppファイルとhファイル」が同時に生成される。メインソースコード（本実施形態ではcppファイルとhファイル）は、異ミドルウェア間変換ソースコード（の本体部分）であり、いわばミドルウェア変換コアソースコードである。
（２）ＲＴＭコンポーネントのＩＤＬファイルを公知のＩＤＬコンパイラで処理することで、インターフェースソースファイル（cppファイルとhファイル）が生成される。
（３）（１）で生成された「メッセージ（msg）ファイル、サービス（srv）ファイル」を公知のＲＯＳコンパイラで処理することで、「メッセージ（msg）ファイル、サービス（srv）ファイル」のソースコード（cppファイルとhファイル）を生成する。
公知の処理の一部を以下に例示する。
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSkel.h
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSK.cc
./idl_gen/cpp/openrtm_ros_bridge/idl/MyService.hh
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceDynSK.cc
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceStub.h
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSkel.cpp
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceStub.cpp
（４）上記３つのソースコードを、公知のＣ＋＋コンパイラを用いて処理してブリッジプログラムを生成する。
OpenRTMからROSへの変換例を図９〜図１８に示す。
図９（MyService.idl）は、OpenRTMのIDLファイルを例示する。
図９Ａ〜図９Ｅ（MyServiceROSBridge.cpp）、図１０Ａ〜図１０Ｃ（ MyServiceROSBridge.h）、図１１Ａ、１１Ｂ（MyServiceROSBridgeComp.cpp）は、本実施形態に係る自動変換用プログラムを用いて自動生成されたソースコード（メイン）を示す。
図１２（SimpleService_MyService_echo.srv）、
図１３（SimpleService_MyService_get_echo_history.srv）、
図１４（SimpleService_MyService_get_value.srv）、
図１５（SimpleService_MyService_get_value_history.srv、
図１６（SimpleService_MyService_set_value.srv）、
図１７（StringMultiArray.msg）、
は、本実施形態に係る自動変換用プログラムを用いて自動生成されたサービスファイル、メッセージファイルである。
図１８Ａ〜１８Ｌ（idl2srv.py）は、OpenRTMのIDLファイルから、上記２つのファイル（ソースコードと、メッセージファイル／サービスファイル）を生成する自動変換用プログラム（いわば、変換プログラム実行制御ソースコード）である。
さらに、図１Ｂを参照して説明する。
（１） ＲＴＭコンポーネントのＩＤＬファイルを自動変換用プログラムで解析し、処理することで、「メッセージ（msg）ファイル、サービス（srv）ファイル」と「ソースコード（Main） cppファイルとhファイル」が同時に生成される。メインソースコード（本実施形態ではcppファイルとhファイル）は、異ミドルウェア間変換ソースコード（の本体部分）であり、いわばミドルウェア変換コアソースコードである。
（２）ＲＴＭコンポーネントのＩＤＬファイルを公知のＩＤＬコンパイラで処理することで、インターフェースソースファイル（cppファイルとhファイル）が生成される。
（３）（１）で生成された「メッセージ（msg）ファイル、サービス（srv）ファイル」を公知のＲＯＳコンパイラで処理することで、「メッセージ（msg）ファイル、サービス（srv）ファイル」のソースコード（cppファイルとhファイル）を生成する。
公知の処理の一部を以下に例示する。
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSkel.h
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSK.cc
./idl_gen/cpp/openrtm_ros_bridge/idl/MyService.hh
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceDynSK.cc
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceStub.h
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSkel.cpp
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceStub.cpp
（４）上記３つのソースコードを、公知のＣ＋＋コンパイラを用いて処理してブリッジプログラムを生成する。
図４において、左図はOpenRTMによるヒューマノイドシミュレーションであり、右図はそこで稼働しているOpenRTMコンポーネントの入出力インターフェース定義ファイルから自動生成したROSノードを示しており、ROSの入出力機能を利用して OpenRTMのヒューマノイドシミュレーション機能が利用できるようになっている。
明細書に添付されたコードや図面として添付したコードから当業者が読み取れる事項は、本願明細書及び図面に記載した事項として扱うことができることが当業者に理解される。
ロボットのミドルウェアが現在多数の規格が存在し、また、従来からロボットの研究を行っている企業でも社内で類似のシステムを有している。一方で、各ミドルウェアにはそれぞれ有用なアプリケーションが存在し、それを利用したいと考えた場合に、アプリケーションを別のミドルウェア上に再実装するか、あるいはミドルウェア間のブリッジモジュールを個別に開発するしかないのが現状である。本発明を利用すれば、これらを自動的に生成することができるため、大幅な省力化を可能にする。
Claims (21)
- 第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成法であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、
を備えた自動生成方法。 - 前記変換モジュールを生成するステップは、
前記ソースコードと、
前記第１のインターフェース定義から生成したソースコードと、
前記第２のインターフェース定義から生成したソースコードと、
を用いて、変換モジュールを生成する、請求項１に記載の方法。 - 第１のタイプのロボット機能要素モジュールの入出力は、第１のインターフェース定義により当該第１のタイプのロボット機能要素モジュールのプログラム実行前に規定されており、前記解析は、当該プログラム実行前に行われる、請求項１または２に記載の方法。
- 第１のミドルウェアは、OpenRTM (Open Robot Middleware)であり、第１のタイプのロボット機能要素モジュールはOpenRTMのコンポーネントであり、前記第１のインターフェース定義はIDLファイルである、請求項１〜３いずれか１項に記載の方法。
- 第２のミドルウェアは、ROS(Robot Operating System)であり、第２のタイプのロボット機能要素モジュールはROSのノードであり、前記第２のインターフェース定義はメッセージファイルないしサービスファイルである、請求項１〜４いずれか１項に記載の方法。
- 第１のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、第２のタイプのロボット機能要素モジュールは、ROSのノードであり、
前記コンポーネントのIDLファイルを解析して、ノードのメッセージファイルあるいは／およびサービスファイルと、ソースコードと、を生成するステップと、
IDLコンパイラによって前記IDLファイルのソースコードを生成するステップと、
ROSコンパイラによって前記メッセージファイルあるいは／およびサービスファイルのソースコードを生成するステップと、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する、
請求項５に記載の方法。 - 第１のタイプのロボット機能要素モジュールの入出力は、当該第１のタイプのロボット機能要素モジュールのプログラム実行時に特定されるようになっており、前記解析は、当該プログラム実行時に行われる、請求項１または２に記載の方法。
- 第１のミドルウェアは、ROS(Robot Operating System)であり、第１のタイプのロボット機能要素モジュールはROSのノードであり、前記入出力は、実行されているノードのトピックのメッセージファイルあるいは／およびサービスのサービスファイルを解析することで取得される、請求項７に記載の方法。
- 第２のミドルウェアは、OpenRTM (Open Robot Middleware)であり、第２のタイプのロボット機能要素モジュールはOpenRTMのコンポーネントであり、前記第２のインターフェース定義はIDLファイルである、請求項７または８に記載の方法。
- 第１のタイプのロボット機能要素モジュールは、ROSのノードであり、第２のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、
前記ノードのメッセージファイルあるいは／およびサービスファイルを解析して、コンポーネントのIDLファイルと、ソースコードと、を生成するステップと、
ROSコンパイラによって前記メッセージファイルあるいは／およびサービスファイルのソースコードを生成するステップと、
IDLコンパイラによって前記生成されたIDLファイルのソースコードを生成するステップと、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する、
請求項９に記載の方法。 - 第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成装置であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成する手段と、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成する手段と、
を備えた自動生成装置。 - 前記変換モジュールを生成する手段は、
前記ソースコードと、
前記第１のインターフェース定義から生成したソースコードと、
前記第２のインターフェース定義から生成したソースコードと、
を用いて、変換モジュールを生成する、請求項１１に記載の装置。 - 第１のタイプのロボット機能要素モジュールの入出力は、第１のインターフェース定義により当該第１のタイプのロボット機能要素モジュールのプログラム実行前に規定されており、前記解析は、当該プログラム実行前に行われる、請求項１１または１２に記載の装置。
- 第１のミドルウェアは、OpenRTM (Open Robot Middleware)であり、第１のタイプのロボット機能要素モジュールはOpenRTMのコンポーネントであり、前記第１のインターフェース定義はIDLファイルである、請求項１１〜１３いずれか１項に記載の装置。
- 第２のミドルウェアは、ROS(Robot Operating System)であり、第２のタイプのロボット機能要素モジュールはROSのノードであり、前記第２のインターフェース定義はメッセージファイルないしサービスファイルである、請求項１１〜１４いずれか１項に記載の装置。
- 第１のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、第２のタイプのロボット機能要素モジュールは、ROSのノードであり、
前記コンポーネントのIDLファイルを解析して、ノードのメッセージファイルあるいは／およびサービスファイルと、ソースコードと、を生成する手段と、
IDLコンパイラによって前記IDLファイルのソースコードを生成する手段と、
ROSコンパイラによって前記メッセージファイルあるいは／およびサービスファイルのソースコードを生成する手段と、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する、
請求項１５に記載の装置。 - 第１のタイプのロボット機能要素モジュールの入出力は、当該第１のタイプのロボット機能要素モジュールのプログラム実行時に特定されるようになっており、前記解析は、当該プログラム実行時に行われる、請求項１１または１２に記載の装置。
- 第１のミドルウェアは、ROS(Robot Operating System)であり、第１のタイプのロボット機能要素モジュールはROSのノードであり、前記入出力は、実行されているノードのトピックのメッセージファイルあるいは／およびサービスのサービスファイルを解析することで取得される、請求項１７に記載の装置。
- 第２のミドルウェアは、OpenRTM (Open Robot Middleware)であり、第２のタイプのロボット機能要素モジュールはOpenRTMのコンポーネントであり、前記第２のインターフェース定義はIDLファイルである、請求項１７または１８に記載の装置。
- 第１のタイプのロボット機能要素モジュールは、ROSのノードであり、第２のタイプのロボット機能要素モジュールは、OpenRTMのコンポーネントであり、
前記ノードのメッセージファイルあるいは／およびサービスファイルを解析して、コンポーネントのIDLファイルと、ソースコードと、を生成する手段と、
ROSコンパイラによって前記メッセージファイル、あるいは／および、サービスファイルのソースコードを生成する手段と、
IDLコンパイラによって前記生成されたIDLファイルのソースコードを生成する手段と、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する、
請求項１９に記載の装置。 - 第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールを自動生成するために、コンピュータを、請求項１１〜２０のいずれか１項に記載の手段として機能させるためのコンピュータプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012232391A JP2014085732A (ja) | 2012-10-19 | 2012-10-19 | 異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置 |
| PCT/JP2013/077419 WO2014061516A1 (ja) | 2012-10-19 | 2013-10-09 | 異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012232391A JP2014085732A (ja) | 2012-10-19 | 2012-10-19 | 異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2014085732A true JP2014085732A (ja) | 2014-05-12 |
Family
ID=50488084
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012232391A Pending JP2014085732A (ja) | 2012-10-19 | 2012-10-19 | 異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置 |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP2014085732A (ja) |
| WO (1) | WO2014061516A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20150129987A (ko) * | 2014-05-13 | 2015-11-23 | (주)큐센텍 | 이기종 장치의 데이터 수집을 위한 미들웨어 간 인터페이스 장치 및 방법 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102015204751A1 (de) * | 2015-03-17 | 2016-09-22 | Robert Bosch Gmbh | Vorrichtung und verfahren zum erstellen von applikationen für anwendungen für eine kommunikation zwischen einem server und einem client einer automatisierungsanlage |
| CN111198770B (zh) * | 2018-11-19 | 2023-06-20 | 北京图森智途科技有限公司 | Ros1消息的通信方法、装置和系统、转换方法和装置 |
| CN114527982A (zh) * | 2020-11-23 | 2022-05-24 | 中移互联网有限公司 | 中间件文件生成和中间件的调用方法、装置及电子设备 |
| CN115134361B (zh) * | 2022-06-20 | 2024-04-26 | 中汽创智科技有限公司 | 一种自动驾驶软件平台的跨平台通信方法及装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011129115A (ja) * | 2009-12-18 | 2011-06-30 | Korea Electronics Telecommun | 異機種ロボットの協業のためのコンポーネント連動装置およびそれに伴う方法 |
-
2012
- 2012-10-19 JP JP2012232391A patent/JP2014085732A/ja active Pending
-
2013
- 2013-10-09 WO PCT/JP2013/077419 patent/WO2014061516A1/ja active Application Filing
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20150129987A (ko) * | 2014-05-13 | 2015-11-23 | (주)큐센텍 | 이기종 장치의 데이터 수집을 위한 미들웨어 간 인터페이스 장치 및 방법 |
| KR101668441B1 (ko) * | 2014-05-13 | 2016-10-21 | (주)큐센텍 | 이기종 장치의 데이터 수집을 위한 미들웨어 간 인터페이스 장치 및 방법 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2014061516A1 (ja) | 2014-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Buschmann et al. | PATTERN-ORIENTED SOFTWARE ARCHITECTURE: A PATTERN LANGUAGE FOR DISTRIBUTED COMPUTING, VOLUME 4 | |
| US7770146B2 (en) | Computer software development incorporating core and compound services | |
| Calisi et al. | OpenRDK: a modular framework for robotic software development | |
| Thramboulidis | Development of distributed industrial control applications: The CORFU framework | |
| WO2014061516A1 (ja) | 異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置 | |
| JP2011503682A (ja) | 制御プログラムを有する自動化装置ならびに制御プログラムをプログラミングするための方法 | |
| JP2004530194A (ja) | 異なるオブジェクト・タイプのサーバとクライアントを結合するための方法およびブリッジ | |
| KR20160000542A (ko) | 데이터 분산 서비스 응용 생성 방법 및 장치 | |
| Veiga et al. | Experiments with service-oriented architectures for industrial robotic cells programming | |
| US7398527B2 (en) | Dispatching application steps of an application running on an application server in a client/server environment | |
| Blake et al. | Robots on the web | |
| Wehner et al. | Internet of things simulation using omnet++ and hardware in the loop | |
| US7392060B2 (en) | Mobile exchange infrastructure | |
| US20030069998A1 (en) | Motion services protocol accessible through uniform resource locator (URL) | |
| Huang et al. | Designing an agent synthesis system for cross-RPC communication | |
| Brugali et al. | Service component architectures in robotics: The sca-orocos integration | |
| Jang et al. | A heterogeneous coupling scheme of OPRoS component framework with ROS | |
| Wu et al. | Remote multi‐robot monitoring and control system based on MMS and web services | |
| JP4776602B2 (ja) | コントローラ用のプログラミング装置、コントローラ及びコントローラ管理システム | |
| Grzelak et al. | Towards a Software Architecture for Near Real-time Applications of IoT. | |
| JP2003076563A (ja) | 分散オブジェクトミドルウェア連携方法及びプログラムを記録した記録媒体並びにプログラム | |
| Peng et al. | Connecting the Robot to ROS | |
| Wermann et al. | Architectural Components: Middleware | |
| Čurn | Distribution for Open Modeling Interface and Environment | |
| Jansson et al. | Bridging ROS for Heterogeneous Integration in Mobile Robot Systems |