|
OpenRTM-aist
OpenRTM-aistは、RTミドルウエア規格に基づき開発されたロボット技術用のミドルウエアである[1][2][3]。RTミドルウエアにかかわる規格の実装として、中心的に同規格策定を行っている独立行政法人産業技術総合研究所が主体となって開発を行っている。 概要RTミドルウエアでは、アクチュエータやセンサ、および知能化のためのアルゴリズムなどのロボットの技術要素を一つのコンポーネントとみなし、これをRTコンポーネント (RT-Component, RTC) と呼ぶ。RTコンポーネントは外部のRTコンポーネントと通信するためのポートを持っており、単一ないしは複数のRTコンポーネントを接続することで、ロボット技術を応用したシステムを構成することができる。したがってRTミドルウエアでは分散型アーキテクチャを採用しているといえる[4]。 RTミドルウエアに関わる規格では、プラットフォーム独立モデル (PIM) としての規格が定められているため、CORBAや.NET Framework、EJBなどの分散技術に依存しないが、OpenRTM-aistは分散オブジェクト技術のCORBAをベースとして独自の拡張を行っており、OpenRTM-aistでの成果は再度、上位のRTミドルウエア関連規格の策定にフィードバックされる。 OpenRTM-aistの特徴は、Object Management Group（OMG）の規格で定められたRTコンポーネントに独自の拡張を行った機能を搭載しており、さらにRTコンポーネントの運用を助けるマネージャ (Manager) の機能が搭載されている。また、CORBAを採用したため複数の言語での開発が可能になり、さらに異なる言語で開発されたRTコンポーネント間の通信や状態管理が可能となった。また、厳密にいえばOpenRTM-aist本体とは異なるが、OpenRTM-aistの運用を助けるためのツール群が多数、産総研などからリリースされており、スケルトンコードの自動生成やRTコンポーネントの接続、状態遷移の監視などをグラフィカルに行うツールが揃っている。 OpenRTM-aistの主な機能RTコンポーネントは、OMGによって定められたRTコンポーネント規格に沿ったロボット技術を用いた機能要素を制御する要素単位をいう。OpenRTM-aistでは、外部との通信用ポートとしてデータポートとサービスポートを規定している。さらにRTコンポーネントの実行状態を管理するための実行コンテキストや、RTコンポーネントの制御パラメータを変化させるコンフィグレーションが重要な概念といえる。 RTコンポーネントのデータポートによる通信データポートとは、センサーの取得したデータや、ロボットの位置姿勢、移動速度等の指令値などのデータを複数のRTコンポーネント間で送受信するための通信チャネルを指す。一つRTコンポーネントは複数のデータポートを持つことができる。 データポートにはデータを他のRTコンポーネントに送信するための出力ポート (OutPort) と、他のRTコンポーネントからデータを受信するための入力ポート (InPort) があり、OutPortとInPortを接続 (connect) することによって、データ送受信が可能となる。 データポートにはデータ型があり、ここで設定されるデータ型のデータを送信ないしは受信するため、接続は同じデータ型のデータポート間でのみ可能となる。 データポートで選択できるデータ型整数型や浮動小数点型ないしはその組み合わせで表現されるデータの送受信が主な用途であり、同じ型を持つデータポートならば接続、通信が可能である。OpenRTM-aistではCORBAをベースとした通信を採用しているため、プリミティブデータ型として、boolean, char, wchar, octet, byte, short, unsigned short, long, unsigned long, long long, unsigned long long, float, double, string, wstringを用いることができる。また、インターフェース記述言語 (IDL) を用いてデータ型を定義することによって、これらの配列およびシーケンス (可変長配列) およびその組み合わせの構造体を定義することができる。 OpenRTM-aistでは、ロボット固有のデータ型として、上記のプリミティブなデータの組み合わせを使ったデータ型が導入されている[5][6]．
通常は上記のデータ型に "Timed" を加えたデータ型を使う。たとえば、「TimedVelocity2D」は、Velocity2D型のデータにタイムスタンプ情報を加えたデータ型である。 また、上記の基本データ型を組み合わせた、よりロボット向けのデータ型も導入されている。
インターフェースデータ型では、上記データ型にタイムスタンプ情報が付与されているものが多い。 また、日本ロボット工業会のロボットビジネス推進協議会のRTミドルウェアワーキンググループで監修された「共通インターフェース」として、「カメラ」および「マニピュレータ」の共通インターフェースIDLを利用することができる。[7] RTコンポーネントのデータポートの接続と接続プロパティ設定OpenRTM-aistでは、接続を司るコネクターと呼ばれるオブジェクトにプロパティを設定することができる。このプロパティは実行中のRTコンポーネントのデータポート間を接続する際に設定することができる。 インターフェース型OpenRTM-aistでは、CORBAをベースにした実装が行われているが、データポートでの通信はCORBAの通信のみではなく、他の複数の通信方法に対応できる実装となっている。この通信方法を設定するのがインターフェース型の選択である。 2019年に公開されたバージョン1.2.0では、デフォルトでCORBA通信以外に、共有メモリ通信と、ダイレクト通信をサポートする。 共有メモリ通信では、通信する複数のRTコンポーネントが、同一のホスト上で実行されている場合にのみ選択することができ、OSが提供する共有メモリ機能を使ってデータを送受信することができる。 また、ダイレクト通信では、マネージャーの機能を使って、同一プロセス上で実行された複数のRTコンポーネント間で通信するときのみに選択することができ、CORBA通信を経由せずに、データのポインタのみの受け渡しを行うため、非常に高速な通信が可能となっている。 さらに、OpenRTM-aistのデータポートは、基底クラスをカスタマイズして動的にロードする機能が備わっており、CORBAに限らない通信に対応させる場合にこの方法が使われる。これまでにDDSトランスポート [8][9] やROSトランスポート [10]などが実装され、公開されている。 データフロー型OutPortとInPortを接続する際に、データが実際に送受信されるタイミングを設定するのがデータフロー型の設定である。これにはpushとpullの2つの選択肢がある。 push型では、送信側RTコンポーネントがOutPortに書き込んだ際に、接続されているInPortのバッファにデータが書き込まれる。この時、通常のCORBA型接続を選択していればCORBA通信が行われる。接続されている二つのRTコンポーネントが別々のホストで実行されており、Ethernetで接続されている場合はCORBA通信が行われるタイミングで通信負荷がかかる。 一方、push型では、送信側RTコンポーネントがOutPortにデータを書き込んだ際に、OutPortに用意されているバッファにデータが貯められ、接続されているInPort側のRTコンポーネントがInPortに対してreadのコマンドを送信した際に、実際にデータが送受信される。 サブスクリプション型データフロー型でpush型を選択したときに変更できる設定パラメータで、送信側RTコンポーネントがOutPortに書き込んだ際に、受信側にデータが実際に送信されるタイミングを調整することができる。 サブスクリプション型がflushである場合は、RTコンポーネントがOutPortにデータを書き込んだ際に直ちにデータが送信される。マーシャリングと送信は書き込みを実行したスレッドが引き受けるため、周期処理中にデータを書き込んだ場合は、送信の遅延も同じスレッドが負担することになる。 一方、サブスクリプション型にnewを選択した場合は、OutPortにデータを書き込んだ際にデータはOutPort内のバッファに書き込まれ、直ちに処理が返る。このとき、書き込みと同時に別のスレッドを立ち上げて、新しいスレッド内で送信を行う。 サブスクリプション型にperiodicを選択した場合は、newと同様にOutPort内のバッファにデータが書き込まれるが、書き込みとは別のスレッドが周期的にバッファを監視しており、バッファに書き込みがあった場合はそのスレッドがデータを送信する。periodicを選択した場合は、バッファ監視の周期を設定する必要がある。 データ送信ポリシーサブスクリプション型にnewもしくはperiodicを選択した場合は、バッファに保存されたデータを送信するポリシーを選択することができる。 allを選択した場合は、バッファに残っているデータをすべて送信する。 fifoの場合は、先入れ先だし方式でデータを一つずつ送信する。 skipを選択した場合は、いくつかのデータをスキップしながらデータを送信し、それ以外は捨てる。 newの場合はバッファに保存された値のうち、最新値のみを送信し古い値は捨てる。 RTコンポーネントのサービスポートサービスポートとは、データポートで規定されるようなデータ通信に限らない、フレキシブルな通信が可能となっている。 サービスポートでは、CORBAの仕組みを応用して、サービスを利用するRTC側からの特定のリクエストに関して、結果を返り値として返却することが可能である。またデータの送受信を伴わない、たとえば状態遷移命令のような仕組みを提供することも可能である。 この機能を使うためには、サービスポートのインターフェースを規定するIDLを記述する必要があり、ほとんどCORBAの技術を直接応用した形での開発が可能になっている。 RTコンポーネントのコンフィグレーションRTコンポーネントの制御にかかわるパラメータを動的に変更する仕組みとして提案されているのがコンフィグレーションである。コンフィグレーションは起動時および任意のタイミングでツール等から変更することができるため、外部のプロセスと通信する方法としてデータポートやサービスポートとは異なるインターフェースを提供している。 コンフィグレーションは、Key-Value型のデータストアであり、コンフィグレーション名から対応する値を文字列で取得することができる。OpenRTM-aistでは開発者がコンフィグレーションの利用を助ける仕組みとして、外部からコンフィグレーションの変更があった場合に、ミドルウェアが自動的に対応する変数の値を書き換える機能があり、文字列型のみでなく、整数型や浮動小数点型の数値に対応している。 コンフィグレーションセットコンフィグレーションセットは、複数のコンフィグレーションを同期して変更するための機能である。たとえばモーターの位置制御を行う装置のRTコンポーネントがあったとして、この制御の複数のゲインをロボットがサービスを提供する場面に応じて変更したい場合、一つ一つのゲインを順番に変更していくと、変更途中の制御が不安定になる恐れがある。これに対して、あらかじめRTコンポーネントに複数のコンフィグレーションセットを登録し、場面に応じてアクティブなコンフィグレーションセットを変更することによって問題を回避することができる。 実行コンテキスト実行コンテキストとは、RTコンポーネントで定義されている処理を実行するオブジェクトを指す言葉である。RTコンポーネントの規格では、RTコンポーネントはCREATED、INACTIVE、ACTIVE、およびERRORの状態を持っており、RTコンポーネント自体は各状態遷移時に呼ばれるアクションを定義するものである。そしてRTコンポーネントの各状態への遷移や、状態遷移に伴うアクションを管理・実行するのが実行コンテキストである。 実行コンテキストに対してRTコンポーネントを登録 (attach) することで、RTコンポーネントは状態を持ち、通常はINACTIVEな状態に移る。後述するRT System Editorなどのツールから実行コンテキストに対して、任意のRTコンポーネントのアクティブ化のコマンドを送信すると、実行コンテキストは管理中の対象RTの状態を遷移させ、対応するアクションを呼び出す。また、OpenRTM-aistで用意されている周期実行コンテキストでは、RTコンポーネントがACTIVE状態にある時、RTコンポーネントのon_executeアクションを周期的に呼び出す。これによってOpenRTM-aistのRTコンポーネントは、ハードウェアの初期化や終了、周期処理をRTコンポーネントのアクションとして実装し、ツールから任意のタイミング・周期で呼び出すことができる。 また、実行コンテキストは実行時のRTコンポーネントに動的に登録・解除することができ、また複数のRTコンポーネントを同一の周期実行コンテキストに登録することで、周期実行タイミングを同期させて動かすなど、フレキシブルなシステムを実行時に構築・設定することができる。 さらに、実行コンテキストは基底クラスを継承することでカスタマイズすることができ、後述するマネージャに実行時にロードさせることで、いろいろな実行コンテキストを使うことができる。例えば、OpenHRP3などのシミュレータのシミュレーション時間と同期して実行する実行コンテキストを使えば、実機でも動作するRTコンポーネントを、コンパイル時ではなく実行時にシミュレーションに組み込んで処理を行わせることができる。また、OpenRTM-aistでは，Linuxカーネルのプリエンプションを利用したリアルタイム実行コンテキストをサポートしており，実行時にリアルタイム性を持たせることが可能である。 マネージャーマネージャーとは、RTコンポーネントの生成や破棄を行う機能である。OpenRTM-aistではマネージャーはManagerクラスとして提供されており、OpenRTM-aistを利用するプロセスは、必ずManagerクラスのオブジェクトを生成して、Manager経由でRTコンポーネントを生成する必要がある。 対応OSWindowsおよび各種Linux、macOSで動作するライブラリが公開されている[11]。このほかにVxWorksでの実装が行われている[12] 使用言語CORBAを用いたために複数の言語でのRTコンポーネント開発が可能となり、さらに異なる言語で開発されたRTコンポーネント間での通信が可能となっている。現在はC++言語、Python、およびJavaでの開発がおこなわれている。またErlangでの実装も非公式ではあるが発表されている。[13]また、宮本信彦氏によるLua版のOpenRTM-aistが公開されている[14] [15][16] ツール群OpenRTM-aistを使った開発を支援するためのツールが複数提案されている。 RTC Builder OpenRTM-aistでは、RTコンポーネント開発においては、ライブラリで提供されているRTコンポーネントの規定クラスのメソッドをオーバーライドする形で開発するため、スケルトンコードの自動生成ツールが重要となっている。OpenRTM-aistではRTC Builderを提供しており、Eclipse上で必要事項を選択、および入力することで、LinuxおよびWindows (Visual Studio) で開発可能なスケルトンコードを自動的に生成することができる。 RTC BuilderではC++、Java、PythonでのRTコンポーネントのスケルトンコードの生成が可能であり、スケルトンコードやMakefileと併せて、RTコンポーネントプロファイルというXML形式のファイルを生成することができる。RTCプロファイルにはRTCのポートに関する情報や、コールバック関数に関する設定が記述されており、RTCのインターフェースに関する情報を交換する方法として用意されている。 RT System Editor RTミドルウエアでは、RTコンポーネントの組み合わせと状態遷移によってロボット・システムの開発を行うが、ポートの接続および監視を行うツールも、RTコンポーネント運用の重要なカギとなってくる。OpenRTM-aistでは、RT System Editorを提供している。 RT System Editorでは、ネームサーバー上のRTコンポーネントの一覧の取得、RTコンポーネント間の接続、状態遷移、コンフィグレーションの変更などをグラフィカルに行うことができる。また、Managerを使って、遠隔からRTコンポーネントの起動、停止も可能になっている。接続やコンフィグレーションの状態はRT System ProfileというXML形式のファイルに保存することができ、次回からはRT System Profileをロードすることによって、RTシステムの状態を簡単に再現することができる。 rtshellrtshellは産業技術総合研究所が開発したコンソール上でのRTコンポーネントの管理、運用ツールであり、コマンドライン上で実行することが出来る複数のコマンド群からなるツールセットである。 rtshellではRT System Editor同様に、RTCの実行、停止、状態遷移、ポートの接続のほかに、ポートの値のエコー、ポートへのデータの送信、ログの収集および再生、RT System EditorでのXMLファイルの読み込みによるRTシステムの構築などに対応しており、コマンドラインに慣れた技術者であればRTCのデバッグにも使えるツールになっている。 RTC DaemonOpenRTM-aistにおけるManagerの機能のみを実装したプログラム。複数のRTCを読み込み、起動する機能がある。 実際には、実行形式でコンパイルされたRTCではManagerの機能を利用しており、設定ファイルであるrtc.confを編集することでも複数のRTCを起動することができる。 OpenRTM-aistから利用できるロボット
OpenRTM-aistを内部で利用している(または利用予定の)ロボットOpenRTM-aistに関連したソフトウエアライセンスEPLおよび産総研と個別に契約するライセンスのデュアルライセンス方式を採用している。 関連項目参考文献
外部リンク |
||||||||||||||||||||||||||||||||||||||||||||||||
