(57)【要約】【課題】相互運用したいミドルウェアのブリッジモジュールの自動生成方法及び装置を提供する。【解決手段】第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、を備えている。【選択図】図１
2014085732.tif 000002
【特許請求の範囲】
【請求項１】
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成法であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、
を備えた自動生成方法。
【請求項２】
前記変換モジュールを生成するステップは、
前記ソースコードと、
前記第１のインターフェース定義から生成したソースコードと、
前記第２のインターフェース定義から生成したソースコードと、
を用いて、変換モジュールを生成する、請求項１に記載の方法。
【請求項３】
第１のタイプのロボット機能要素モジュールの入出力は、第１のインターフェース定義により当該第１のタイプのロボット機能要素モジュールのプログラム実行前に規定されており、前記解析は、当該プログラム実行前に行われる、請求項１または２に記載の方法。
【請求項４】
第１のミドルウェアは、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ファイルのソースコードを生成する手段と、を備え、
前記３つのソースコードを用いて、変換モジュールを生成する、
請求項１９に記載の装置。
【請求項２１】
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールを自動生成するために、コンピュータを、請求項１１〜２０のいずれか１項に記載の手段として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なる規格からなるロボットミドルウェアの相互運用を行うための、あるミドルウェア上で稼働しているプログラムを、別のミドルウェア上からも制御・通信できるようにするために、プログラム自体を仮想化し情報を変換するブリッジと呼ばれる変換モジュールを生成する技術に関するものである。
【背景技術】
【０００２】
従来、ロボット研究分野ではオープンソースのOSや開発環境を活用することはあっても、その研究のコアとなる知的な情報処理モジュールに関してはオープンになることは無かったが、ここ数年、ロボット分野においてもオープンソースソフトウェアが、特に海外を中心に急速に拡がりを見せている。ロボット用オープンソースプロジェクトとしては、米国のWillowGarage社が展開するROS(Robot  Operating  System)、欧州におけるOrocosやiCub/Yarp等のプロジェクト、日本におけるOpenRTMプロジェクトが知られており、それぞれロボットを開発するためのミドルウェアを提供している。
【０００３】
このようなロボットミドルウェアは、ロボットを構成する要素（アクチュエータやセンサ）やロボットを制御するソフトウェアを、機能要素モジュールとして部品化するための技術であり、用途に応じて機能要素モジュールを適宜組み合わせるだけで、様々なロボットを開発することができる。例えば、OpenRTMプロジェクトであるOpenRTM-aistでは、ロボットシステムを作る際に、機能要素モジュール(RTC：RTコンポー ネント) ごとにプログラムを作成し、RTコンポーネントを繋ぎ合わせることでロボットシステムを構築する。
【０００４】
上述のように、規格の異なる複数のロボットミドルウェアが存在することから、従来は、ロボットミドルウェア毎に独立して開発が進められてきた傾向があり、これらを連携させる試みはあまり行われてこなかった。これらの異なるタイプのロボットミドルウェアを連携しようとする場合には、いわゆるブリッジモジュールを逐一手作業で開発することになり、ミドルウェアのバージョンアップや対象とするプログラムの機能更新、変更等が起こると、ブリッジモジュールが機能せず、再度、人手をかけて開発しなおす必要があった。
【０００５】
ブリッジモジュールの生成を自動で行えれば、逐一人手による作業が発生せず効率化につながるばかりでなく、ミドルウェアやプログラムの更新や変更に迅速に対応できるようになるが、そのための方法論は明らかでなかった。特許文献は、データ中継用ＲＴコンポーネント生成方法について開示するが、同じ規格のミドルウェアのコンポーネント間のミスマッチに対応するものである。
【特許文献１】特開２０１１−８６１８２号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、相互運用したいミドルウェアの分析に基づいたブリッジモジュールの自動生成方法及び装置を提供するものである。
【課題を解決するための手段】
【０００７】
本発明が採用した技術手段は、
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成法であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成するステップと、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成するステップと、
を備えた自動生成方法、ないし、
第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールの自動生成装置であって、
第１のタイプのロボット機能要素モジュールの第１のインターフェース定義を解析して、第２のタイプのロボット機能要素モジュールの第２のインターフェース定義と、ミドルウェア間変換ソースコードと、を生成する手段と、
前記第２のインターフェース定義と前記ソースコードを用いて、変換モジュールを生成する手段と、
を備えた自動生成装置、である。
本発明は、ハードウェアとしてのコンピュータ（入力部、出力部、演算部、記憶部、表示部等を備える）と、コンピュータに所定の機能を実行させるようなソフトウェアとの協働によって実現され、各ファイルないしプログラムは１つあるいは複数のコンピュータの記憶部に記憶されている。
本発明は、第１のタイプのロボット機能要素モジュールのセットを備えた第１のミドルウェアと、第２のタイプのロボット機能要素モジュールのセットを備えた第２のミドルウェアとの間を連携する変換モジュールを自動生成するために、コンピュータを所定の手段として機能させるためのコンピュータプログラムとして実現される。
【０００８】
１つの態様では、  前記変換モジュールを生成するステップは、
前記ソースコードと、
前記第１のインターフェース定義から生成したソースコードと、
前記第２のインターフェース定義から生成したソースコードと、
を用いて、変換モジュールを生成する。
インターフェース定義ファイルは、各ミドルウェア毎に規定されており、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 (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の例を示す。【図９Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図９Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図９Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図９Ｄ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図９Ｅ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図１０Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図１０Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図１０Ｃ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図１１Ａ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図１１Ｂ】自動変換用プログラムによって自動生成されたプログラム（異ミドルウェア間変換ソースコードの本体部分）の例を示す。【図１２】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。【図１３】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。【図１４】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。【図１５】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。【図１６】自動変換用プログラムによって自動生成されたサービスファイルの例を示す。【図１７】自動変換用プログラムによって自動生成されたメッセージファイルの例を示す。【図１８Ａ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｂ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｃ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｄ】上記ソースコード（メイン）と、メッセージファイル／サービ��ファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｅ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｆ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｇ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｈ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｉ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｊ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｋ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。【図１８Ｌ】上記ソースコード（メイン）と、メッセージファイル／サービスファイル、を生成する自動変換用プログラムの例を示す。
【発明を実施するための形態】
【００１５】
［Ａ］ロボットミドルウェア
ロボットミドルウェアは、ロボット機能要素のソフトウエアモジュールを複数組み合わせてロボットシステムを構築するためのソフトウエアプラットフォームである。ロボットミドルウェアとしては、米国のWillowGarage社が展開するROS(Robot  Operating  System)、欧州におけるOrocosやiCub/Yarp等のプロジェクト、日本におけるOpenRTMプロジェクトが知られている。また、企業が独自に開発したミドルウェアも存在する。ここでは、ROSとOpenRTM-aistを例にとって、本実施形態を説明するが、本発明が適用されるミドルウェアは、ROSとOpenRTM-aistに限定されないことが当業者に理解される。
【００１６】［Ａ−１］ROS(Robot  Operating  System)ROSの詳細については、（公序良俗違反につき、不掲載）を参照することができる。ここでは、本実施形態の理解に必要なROSに関連する用語を幾つか説明する。以下の記載には、前記ウェブサイトの記載の翻訳に基づく記述が含まれる。
【００１７】
［Package（パッケージ）］
パッケージ(package)は、まとまった機能を提供するソフトウェア群が含まれるフォルダないし開発用のファイルの集合である。パッケージはROSにおけるメインユニットであり、ROSのソフトウェアは、パッケージ内で組織化されている。パッケージには、ROSのランタイムプロセス（ノード）、ROS依存ライブラリ、データセット、コンフィギュレーションファイル、その他有用に組織化され得るファイルが含まれている。
【００１８】
［Node（ノード）］
ノードは、計算の実行するプロセスであり、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内で送信されるメッセージのデータ構造を定義する。
【００２０】
［srv  files（サービスファイル）］
サービスは、サービスファイルを用いて定義され、サービスファイルは、ＲＯＳクライアントライブラリによってソースコードにコンパイルされる。サービスファイルは、サービスを記述し、リクエストとリスポンスの２つからなる。サービスファイルは、リクエストとリスポンスの２つを含むことを除いて、メッセージファイルと同様である。サービスファイルの例として、「int64 A」、「int64 B」、「int64 Sum」を示す。A、Bは要求（request）で、Sumは応答（response）である。サービスファイルは、パッケージのサービスディレクトリに格納されている。Service (srv)types（サービス型）は、パッケージ内に格納されたサービス記述であり、ROS内のサービスの要求（request）及び応答（response） データ構造を定義する。
【００２１】
［Topic(トピック)］
ROSでは、データの送受信はトピックを用いて実行される。トピックは、名前付けられたバスであり、それを通してノードがメッセージを交換する。ノード（publishers）は、メッセージを所与のトピックに対してパブリッシュすることによって当該メッセージを送信する。トピックはメッセージの内容を特定する名前である。あるデータに関心のあるノード（subscribers）は、適当なトピックに対してサブスクライブする。パブリッシャーはデータを提供する側で、サブスクライバーはデータを受け取る側である。１つのトピックに対して同時に多数のパブリッシャー及びサブスクライバーが存在し得る。また、１つのノードが多数のトピックに対してパブリッシュおよび／あるいはサブスクライブし得る。一般に、パブリッシャー及びサブスクライバーは互いの存在を認知しない。論理的には、トピックは、強固に型付けられたメッセージバスとして捉えることができる。各バスは名前を有しており、誰でもバスにコネクトしてメッセージ（所定の型を備えた）の送信・受信が可能である。ノードは必要なトピックにアクセスして、データを受け取る。トピックは、一方向のストリーミング通信を意図しており、リクエストに対する応答の受信を実行するノードは、サービスを用いることになる。
【００２２】
Publisher  Nodeのコード例を示す（上記ウェブサイトから抜粋）
2014085732.tif 000003
pub = rospy.Publisher("chatter", String)は、このノードが、メッセージ型Stringを用いてchatterトピックに対してパブリッシュすることを宣言している。
【００２３】
Subscriber  Nodeのコード例を示す（上記ウェブサイトから抜粋）
2014085732.tif 000004
rospy.Subscriber("chatter"，String，callback)は、このノードが、メッセージ型Stringのchatterトピックをサブスクライブすることを宣言する。
【００２４】
［Service(サービス)］
サービスは、データの送受信ではなく、ある操作に対して、そのレスポンスを受け取るような場合（要求／応答の実行）に用いられる。サービスは、要求(request)と応答(reply)の一対のメッセージによって定義される。提供されるＲＯＳノードは、名前の下でサービスを提供し、クライアントは、リクエストメッセージを送信することでサービスを呼び、応答を待つ。サービスは関数の呼び出しないしremote procedure callに類似する。
【００２５】
Service  Nodeのコード例を示す（上記ウェブサイトから抜粋）
2014085732.tif 000005
【００２６】
Client  Nodeのコード例を示す（上記ウェブサイトから抜粋）
2014085732.tif 000006
【００２７】
［Ａ−２］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を作成することができる。
【００２９】
［データポート］
データポートは主に連続的なデータを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が異なって いてもインターフェース型が同じなら接続し関数を呼び出すことができる。「同じ型」とは同一のインターフェース定義を持つことである。
【００３１】
［インターフェース定義］
OpenRTM-aistでは、インターフェースはIDLと呼ばれるCORBAのインターフェー ス定義言語によって定義する。IDLは言語に依存しないインターフェース定義方法を提供し、またIDLコンパイラを利用することで、各種言語に対応したコード（スタブやスケルトン）が自動的に生成される。スタブは、リモートのオブジェクトを呼び出すためのプロキシオブジェクトのためのコードであり、スケルトンは、プロバイダを実装するためのベースとなるコードである。これら自動生成されるコードによって、異なる言語同士の呼び出しをシームレスに行うことができる。例えば、C++で実装されたプロバイダを、Pythonや Java等で容易に呼び出すことができる。
【００３２】
以下は、OpenRTM-aistのサンプルで使用されているIDL定義である（上記ウェブサイトから抜粋）。
2014085732.tif 000007
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に携わる当業者において比較的容易に定義できるので、詳細な説明は省略する。
【００３４】
［Ｂ］異なるタイプのロボットミドルウェア間を連携する変換モジュール
異なる規格からなるロボットミドルウェアの相互運用を行うための、あるミドルウェア上で稼働しているプログラムを、別のミドルウェア上からも制御・通信できるようにするために、プログラム自体を仮想化し情報を変換するブリッジと呼ばれる変換モジュールを生成する。ブリッジモジュールの生成を自動で行えれば、逐一人手による作業が発生せず効率化につながるばかりでなく、ミドルウェアやプログラムの更新や変更に迅速に対応できるようになる。
【００３５】
「ブリッジ」とは、２つのシステムや構成単位の間で情報を交換する装置（ソフトウェアを含む）である。このような、ブリッジモジュールは、ハードウェアとしてのコンピュータ（入力部、出力部、演算部、記憶部、表示部等を備える）と、コンピュータに所定の機能を実行させるようなソフトウェアとの協働によって実現される。
【００３６】
本実施形態では、相互運用したいミドルウェアの分析に基づいたブリッジモジュールの自動生成方法を提供するものである。ロボット機能要素モジュールの自動変換はオンライン方式とオフライン方式の２つの方法で解決し得ることを示し、プログラムの入出力が静的（プログラム実行前）に明らかなミドルウェアではオンライン方式が、そうでない場合にはオフライン方式を採用する。ブリッジモジュールの自動生成として、オンラインの変換方式とオフラインの変換方式、具体的には、実行しているプログラムの入出力を調べこれに対応したインターフェース定義ファイルとプログラムを生成するオンラインの変換方式と、インターフェース定義ファイルの解析から対応するプログラムを生成するオフラインの変換方式と、を提案する。いずれの方式も、「インターフェース定義ファイル（広義）」と「ソースコード」を生成し、ブリッジモジュールを実現する。従来、そのための具体的な手続きは明らかになっていなかったが、本実施形態では、ブリッジモジュールの自動生成にはオンラインとオフラインの２つの方式があることを示し、対象となるミドルウェアの分析によりどちらの方法を採用すればよいかという、手続を与える。
【００３７】
［Ｂ−１］OpenRTM-ROS自動相互運用システム
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ファイル並びにブリッジモジュールのソースコードを生成する方式である。
【００４２】
オンライン変換方式は、ロボットミドルウェアシステムのロボット機能要素モジュールのプログラムの入出力が、当該プログラムを実行するまで明らかでないようなシステムを対象とした場合に有効な方法である。例えば、ＲＯＳのノードプログラムにおいては、メッセージインターフェース定義ファイルはデータの入出力を定義するが、それがどのノードプログラムが提供するものなのかは明記されていないため、ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成する場合は、オンライン変換方式が適切である。
【００４３】
ＲＯＳのノードプログラムに対応するOpenRTMのコンポーメントプログラムを提供するブリッジモジュールを生成するためのフローチャートを図１Ａに示す。
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によるヒューマノイドシミュレーションであり、右図はそこで稼働しているOpenRTMコンポーネントの入出力インターフェース定義ファイルから自動生成したROSノードを示しており、ROSの入出力機能を利用して OpenRTMのヒューマノイドシミュレーション機能が利用できるようになっている。
【００４９】
明細書に添付されたコードや図面として添付したコードから当業者が読み取れる事項は、本願明細書及び図面に記載した事項として扱うことができることが当業者に理解される。
【産業上の利用可能性】
【００５０】
ロボットのミドルウェアが現在多数の規格が存在し、また、従来からロボットの研究を行っている企業でも社内で類似のシステムを有している。一方で、各ミドルウェアにはそれぞれ有用なアプリケーションが存在し、それを利用したいと考えた場合に、アプリケーションを別のミドルウェア上に再実装するか、あるいはミドルウェア間のブリッジモジュールを個別に開発するしかないのが現状である。本発明を利用すれば、これらを自動的に生成することができるため、大幅な省力化を可能にする。
【図１】
2014085732.tif 000008
【図１Ａ】
2014085732.tif 000009
【図１Ｂ】
2014085732.tif 000010
【図２Ｂ】
2014085732.tif 000011
【図３Ａ】
2014085732.tif 000012
【図５Ａ】
2014085732.tif 000013
【図５Ｂ】
2014085732.tif 000014
【図５Ｃ】
2014085732.tif 000015
【図６Ａ】
2014085732.tif 000016
【図６Ｂ】
2014085732.tif 000017
【図６Ｃ】
2014085732.tif 000018
【図６Ｄ】
2014085732.tif 000019
【図６Ｅ】
2014085732.tif 000020
【図６Ｆ】
2014085732.tif 000021
【図６Ｇ】
2014085732.tif 000022
【図６Ｈ】
2014085732.tif 000023
【図７Ａ】
2014085732.tif 000024
【図７Ｂ】
2014085732.tif 000025
【図８Ａ】
2014085732.tif 000026
【図８Ｂ】
2014085732.tif 000027
【図８Ｃ】
2014085732.tif 000028
【図８Ｄ】
2014085732.tif 000029
【図８Ｅ】
2014085732.tif 000030
【図８Ｆ】
2014085732.tif 000031
【図８Ｇ】
2014085732.tif 000032
【図９】
2014085732.tif 000033
【図９Ａ】
2014085732.tif 000034
【図９Ｂ】
2014085732.tif 000035
【図９Ｃ】
2014085732.tif 000036
【図９Ｄ】
2014085732.tif 000037
【図９Ｅ】
2014085732.tif 000038
【図１０Ａ】
2014085732.tif 000039
【図１０Ｂ】
2014085732.tif 000040
【図１０Ｃ】
2014085732.tif 000041
【図１１Ａ】
2014085732.tif 000042
【図１１Ｂ】
2014085732.tif 000043
【図１２】
2014085732.tif 000044
【図１３】
2014085732.tif 000045
【図１４】
2014085732.tif 000046
【図１５】
2014085732.tif 000047
【図１６】
2014085732.tif 000048
【図１７】
2014085732.tif 000049
【図１８Ａ】
2014085732.tif 000050
【図１８Ｂ】
2014085732.tif 000051
【図１８Ｃ】
2014085732.tif 000052
【図１８Ｄ】
2014085732.tif 000053
【図１８Ｅ】
2014085732.tif 000054
【図１８Ｆ】
2014085732.tif 000055
【図１８Ｇ】
2014085732.tif 000056
【図１８Ｈ】
2014085732.tif 000057
【図１８Ｉ】
2014085732.tif 000058
【図１８Ｊ】
2014085732.tif 000059
【図１８Ｋ】
2014085732.tif 000060
【図１８Ｌ】
2014085732.tif 000061
【図２Ａ】
2014085732.tif 000062
【図３Ｂ】
2014085732.tif 000063
【図３Ｃ】
2014085732.tif 000064
【図４】
2014085732.tif 000065