• OpenRTM-aist とは何ですか？
• 上の説明を聞いてもまだよくわからないのですが？
• RTコンポーネントとは何ですか？
• もっと具体的に教えて下さい。
• OpenRTM-aistは何に向いていて、何に向いていないのですか？
  • 向いていること
  • 向いていないこと
• OpenRTM-aistの技術的概要について教えて下さい
  • RTCフレームワーク
  • ネットワーク透過性
  • RTコンポーネントの機能
• CORBAの通信速度は遅いと聞いた事があるのですが
• CORBAのメモリ使用量が大きく重いと聞いたことがあるのですが
• なぜ今さら古臭いCORBAを使うのですか？

OpenRTM-aist とは何ですか？

ひとことで言うと「ロボットシステムのための分散コンポーネントミドルウエア」です。

• ロボットシステムのための -> ロボットシステムを作るための便利な機能を提供します。
• 分散 -> OpenRTM-aist を使うとネットワークを利用した分散システムを簡単に構築できます。
• コンポーネント -> OpenRTM-aistではソフトウエアを「コンポーネント」単位で作成し組み合わせて全体システムを構築します。
• ミドルウエア -> コンポーネントのフレームワークだけでなく、開発を補助するライブラリ・ツールなども含みます

上の説明を聞いてもまだよくわからないのですが？

プログラムをコンポーネント単位（これをRTコンポーネントと呼ぶ）で作成する、という点が重要です。

• プログラムはコンポーネント (exeやdll, あるいは実行バイナリまたはso, dylibなど) として作成する
• 他のRTコンポーネントとつないでシステムをつくる
• コンポーネントは他の人が作ったものを借りてきても良い
• OSや言語の違うRTコンポーネント同士を接続できる
• 接続はネットワーク越しにもできる

LEGOブロックを想像するとわかりやすいかもしれません。ここのRTコンポーネントはブロックです。 ブロック単体では何も面白くありませんが、ブロックを組み合わせていろいろなものを作ることができます。 ブロック同士は共通の凹凸 (RTコンポーネントの標準インターフェース) を持っているため、簡単に接続することができます。

RTコンポーネントとは何ですか？

概念的に言えば

 ひとかたまりの機能を持ったソフトウエアモジュールで、入出力やサービスインターフェースをもつもの

実装上、つまりプログラミングする際には

 RTObjectクラスを継承し、固有の機能 (コアロジック)を埋め込んだクラス

また、このようにして実装したクラスはコンパイルされ、実行形式 (exeやUNIX上の実行可能形式) やローダブルモジュール (dll, so, dylib形式) になります。 これらもそれぞれ

 スタンドアロンコンポーネント: 実行形式のコンポーネントで、実行時にインスタンスが1つだけ作成される
 ローダブルモジュールコンポーネント：ローダブルモジュール形式でローダに読み込み

もっと具体的に教えて下さい。

たとえば、いまあなたは卒論で画像処理についての研究をしているとします。画像をカメラから取得して、画像に対して何かの処理をし、画面に表示するプログラムを作らなければなりません。プログラムは大きく分けて以下の3つの部分から構成されるでしょう。

1. カメラから画像を取得する
2. 取得した画層に対して処理を行う
3. 結果を見るために画面に表示する

卒論の研究テーマは「画像処理」です。つまり上の「2. 取得した画層に対して処理を行う」部分が重要で、ほかはどうでもいいわけです。 しかし、もしすべてを自分で1からプログラムをつくろうとすると、カメラのドライバの知識も必要になりますし、画面表示のためにはウインドウシステムの知識も必要でしょう。

OpenRTM-aistを使ってください。カメラから画像を取得するRTコンポーネントも画像を画面に表示するコンポーネントはすでにあります。 あとは、あなたの「2. 取得した画層に対して処理を行う」RTコンポーネントを作成するだけです。 それも、似たようなサンプルが沢山ありますのでそれを少し修正して自分のアルゴリズムを実装してください。

OpenRTM-aistは何に向いていて、何に向いていないのですか？

向いていること

• 多人数で開発する中規模から大規模なRTシステム
  • 大学の研究室で先輩から後輩へ資産を継承するときにはべんりでしょう
• ネットワークを利用したRTシステム
  • ネットワーク透過なのでコンポーネントの配置の自由度が高い
  • 面倒なネットワークプログラミングは不要
• 様々なOS、言語が混在したRTシステム
  • Windows, Linux (UNIX), Mac OS X, uITRON, QNXなどで利用可能
  • C++, Python, Javaで利用可能
• RTシステムのプロトタイピング
  • 他のRTコンポーネントを借りてきて、簡単にシステムを組み立てることができます
  • もちろん実運用時にも使えます

向いていないこと

• 小規模な単一アプリケーションの作成
  • 可能ですが作業工数とのトレードオフを考える必要があるでしょう
• 小型組込CPU上で完結したRTシステム
  • RTC-LiteやRTnoという仕組みもありますが、ネットワークで組込機器と他のロボットを連携させるための仕組みです。

OpenRTM-aistの技術的概要について教えて下さい

OpenRTM-aistはRTコンポーネント(RTC)というソフトウエアの基本単位を組み合わせてシステムを作るためのフレームワークおよびミドルウエアです。

RTCフレームワーク

あなたがすでに持っているプログラムをRTCにするのは比較的簡単です。RTCフレームワークに従って、幾つかの関数にロジックを実装します。 コンポーネントには入出力のためのポートというものがあり、それらもフレームワークを利用すれば簡単に利用することができます。 具体的には、RTCBuilderと呼ばれるGUIツール、作成しようとするコンポーネントの基本情報、入出力ポートの情報などを入力するとほとんどのコードが自動で出力されます。 出力されたコードはあなたのコンポーネントのためのクラス定義が含まれます。その中のonExecute()という関数がC言語で言うところのmain関数にあたり、ここに主なコードを実装します。 ポートから入力を読み取るには、予め定義されている入力ポートのread()関数を呼び、別途定義されている入力ポート用の変数からデータを読むだけです。 ポートへデータを出力するには、これも予め定義されている出力ポート用の変数にデータを書き込み、別途定義されている出力ポートのwrite()関数を呼分だけです。 ポート同士の接続は、システムを組み立てるときにおこなわれ、RTCを実装する際には相手がネットワーク上のどこにあるか、どんな言語やOS上のコンポーネントかなどについて気にする必要はありません。ネットワーク通信、OS、言語間の透過性はOpenRTM-aistによってすべて保証されます。

ネットワーク透過性

OpenRTM-aistのネットワーク透過性は、分散オブジェクトミドルウエアの標準であるCORBA (Common Object Request Broker Architecture) により実現されています。 CORBA はネットワーク上に存在するリモートオブジェクト間の呼び出しを、ネットワーク・言語・OS間で透過的に行うことができ、ほぼすべてのOS、言語をサポートしています。 また、CORBA自体はOMG (Object Management Group) という標準化団体により標準化されている標準仕様ですが、この仕様に従ってCORBAのミドルウエアを実装・提供 (あるいは販売) している組織・会社は多数あり、これにより様々なOSや言語間のサポートが実現されています。

RTコンポーネントの機能

• メタ情報取得
  • プロファイル情報などシステムの動的構成を可能にする情報を実行時に取得できる機能
• 実行コンテキストと状態遷移
  • コンポーネント内のロジックは実行コンテキストと呼ばれる抽象スレッドオブジェクトにより実行されます
  • コンポーネントはInactive, Active, Error などの状態をもち、状態ごとに実行するアクションが決まっています
  • 一つの実行コンテキストを複数のRTCと関連付けることで通常は難しい複数コンポーネントの同期連続実行が可能です
  • 実行コンテキストをリアルタイムをサポートするものと交換すると、コンポーネントをリアルタイム化できます
• データポート
  • 連続的なデータをやり取りするポートでInPort, OutPortがあります
  • InPortはデータを受け取り、OutPortはデータを送信します
  • InPortとOutPortの接続は実行時に動的に行うことができます
  • InPortとOutPortはデータ型が同じ場合のみ接続できます
  • 即時送信、バッファリングし別スレッドで送信するなど様々な送信方法を接続時に選択できます
• サービスポート
  • 開発者が任意のインターフェースを定義することができます
  • 提供 (Provided) 型と、要求 (Required) 型があり、これらが相互につながります
  • データポートではできない詳細なサービスを提供したいときに利用します
• コンフィギュレーション
  • RTCの実行時に変更可能なパラメータを持たせることができます
  • パラメータはプログラム中で振る舞いを変えるためなdに利用できます
  • パラメータは外部からツールなどで実行時に変更することができます
  • パラメータは複数のパラメータをひとまとめにした「セット」として持つことができ、状況によってセットを丸ごと入れ替えることができます

CORBAの通信速度は遅いと聞いた事があるのですが

これはある意味において正しく、また間違いです。 ごく簡単なプロトコルを持ったネットワーク通信をsocket APIで実装した場合、CORBAの通信速度を超えることはそれほど難しくはないでしょう。 ただそれは、ネットワーク上でのネゴシエーションを含む透過性の実現、可変長メッセージのサポート、異なるエンディアンへの対応、複数の言語間での相互利用などは考慮されていないのではないでしょうか？ これらの機能をサポートしようとすれば、次第にCORBAが利用している CDR (Common Data Representation) というマーシャリング手法と、GIOP (general Inter-ORB Protocol) というプロトコルに近いものになっていき、CPU使用量やパケットサイズが増大します。 また、これらを複数の言語間で整合性を保証し、かつ複数の実装間で相互運用性を保証することは大変なことです。 一からこうしたミドルウエアを実装し、バグのが少なくかつCORBAより高速なミドルウエアを実装することはおそらく難しいでしょう。 CORBAのオーバーヘッドはこうした柔軟性と相互運用性のための代償なのです。

CORBAのメモリ使用量が大きく重いと聞いたことがあるのですが

CORBAを利用する際にはCORBAのためのコアライブラリと、スタブやスケルトンと呼ばれるユーザ定義に基づくコードを同時にリンクする必要があります。 大抵の実装におけるコアライブラリは、言語によっても違いますが例えばC++であれば数MB程度のものになります。一方スタブやスケルトンは利用するインターフェース定義によって大きく異なり、複雑なインターフェース定義を利用すればするほど大きくなります。OpenRTM-aistではこれらはスタティックライブラリの状態で2MB程度のファイルサイズになります。

最近のLinuxやWindows上のアプリケーションに比べると実行時にメモリ上に占めるサイズも気になる程ではありませんが、数MB程度しかメインメモリを搭載しない機器ではCORBAを動作させることは難しいでしょう。C言語で実装された省メモリのCORBAなどもありますが、組込みの世界の常識から言えばこれでもかなり大きいサイズになります。

ただし、ロボットシステムを構築する再には、モーションコントロールや運動学計算、あるいいは画像処理、音声処理などを行う必要があり、これらを行うには通常PC程度のスペックの計算機がロボットに搭載されます。したがって、こうした環境で利用する際にはCORBAおよびOpenRTM-aistのメモリ使用量やCPU使用量などはそれほど問題にはならないでしょう。

なお、スタブやスケルトンはリモート呼び出しの際の複雑な手順や、呼び出されるオブジェクトを実現するために必要な様々な処理を隠蔽します。 これらは通常IDLコンパイラと呼ばれる一種のコードジェネレータにより自動的に生成されるため、同じ作業を手で行うよりもずっと間違いやバグが少なくなります。

なぜ今さら古臭いCORBAを使うのですか？

たしかに、CORBA 1.0の標準仕様が最初にリリースされたのは今から20年も前の1991年です。(CORBAの歴史) 仕様およびその設計に様々な問題があることも知られています。

Javaであれば、RMIやEJBなどを使えばCORBAを使うよりもずっと簡単にリモートオブジェクトやコンポーネントを利用することができます。 ただし、これらはJavaでしか利用することができません。DCOMは複数の言語をサポートしますが、Windowsでしか利用できません。

複数の言語、複数のOSをサポートするミドルウエアとしては、ZeroC Inc.のIceがあります。これはCORBAの仕様策定にも深く携わり、Advanced CORBA Programming with C++の著者のひとりでもあるMichi Henning (ZeroC Inc. CTO) が作ったミドルウエアです。 CORBAの問題点を改善し、よりシンプルに、学習しやすく、またCORBAにない幾つかの機能も追加されたミドルウエアです。 ほとんどのメジャーな (かつ最近の) 言語やOSをサポートしています。

ただし、OpenRTM-aistの開発が始まった2003年時点では、Iceの最初のバージョン (2003年リリース) がリリースされたばかりであり、CORBAの大胆となるミドルウエアは他にありませんでした。