視覚脳科学研究を目的としたRTミドルウェアの応用と結果
視覚脳科学研究を目的としたRTミドルウェアの応用と結果
概要
本ページはRTミドルウェアコンテスト2014で発表予定のRTCページです.OpenRTM-aistを基盤とする視覚脳科学研究用プラットフォーム:HI-brainで研究を遂行するために必要な機能の提供をします.
提供する機能は下記の通りです.また,それらを用いたサンプルRTCを公開します.
- RTC同士の共有メモリによるデータ転送
- コンポーネント同士を協調的に動作させる独自実行コンテキスト
サンプルRTC
コンポーネントの使い方はzipファイル内のreadme.txtに記述してあります.
- MIT saliency benchmarkで1位をとった視覚的注意モデルのRTC
binary code(binary_Saliency_models.zip)
source code(source_BMSmodel.zip, source_CovSal.zip, source_JuddSaliencyModel.zip, source_Mixture_of_Saliency_Models.zip)
- 画像の読み込みおよび可視化コンポーネント
binary code(binary_Lib_samples.zip)
source code(source_load_image_sequence.zip, source_show_image.zip)
- 他のStepwiseECコンポーネントを管理するRTC
binary code(binary_StepwiseCtlComp.zip)
他にもHI-brainホームページには様々なコンポーネントが登録されています.
OpenCV関数群を簡単にRTC化する「OpenCV-RTC」や,網膜モデルなど様々な視覚数理モデルRTCが入っているUbuntuインストールディスクなどが提供されています.
※利用時には新規GitHubアカウントの作成を推奨します.
※モデルRTCを簡単に共有可能とするため,GitHubアカウントに登録されたプロジェクトが自動的にHI-brainに読み込まれます.
コンテンツ
提供するライブラリ
cv::flipのRTCを参考に,各ライブラリの詳しい使い方を書いたreadme.htmlが作成例の中にあります.
cv::flipによる共有メモリを用いるRTCの作成例(source_Flip_SharedMemory_0.zip)
cv::flipによるStepwiseECを用いるRTCの作成例(source_Flip_StepwiseEC_0.zip)
共有メモリによるデータ転送
視覚脳科学研究では主に画像(行列)を送受信するため,画像サイズが大きくなるとデータ転送に時間がかかります.
ここでは,ユーザーのコーディング量を最小限にし,共有メモリで効率的にデータを転送する方法を紹介します.
本実装方法を真似ることで,入出力ポートにおける型変換をユーザーが意識する必要がなくなり,IDLの変更にも柔軟に対応することが可能となります.
ソースコード(source_SharedMemory.zip)
前提
- OpenCVライブラリで行列を扱うクラスcv::MatをRTC内で用いる共通のデータ型とし,cv::Matを効率的に転送する独自IDL(Timed_cvMat)を用います.
- 共有メモリでデータを転送するためにboostライブラリを使用します.
- 独自データ型の使用にはOpenRTPのアップデートが必要です.
アップデート方法についてはhttp://openrtm.org/openrtm/ja/content/openrtp_plugin_updateをご覧下さい.
実装方法の概要
- RTC名前空間とは異なる名前空間(USM)を定義
- 新しい名前空間でRTC::OutPortを継承した新しいOutPort,RTC::InPortを継承した新しいInPortを定義
- write(),read()関数をオーバーロード
以上の内容をソースコードで表すと次の通りです.
namespace USM{ class OutPort : public RTC::OutPort { bool write(cv::Mat data); }; class InPort : public RTC::InPort { bool read(cv::Mat data); }; }
ユーザーの手間
次の手順を踏むだけで簡単に共有メモリを用いたデータ転送が可能となります.
- ファイルを適切な場所に配置する
- InPort/OutPortの変数宣言を,新しく定義したポート(USM::InPort/USM::OutPort)に切り替える
- OutPortがある場合は初期化関数を呼び出す(共有メモリの領域確保のため)
- read(),write()関数の代わりにオーバーロードしたread(cv::Mat),write(cv::Mat)を用いる
詳細な手順はcv::flipによる共有メモリを用いるRTCの作成例(source_Flip_SharedMemory_0.zip)のreadme.htmlをご覧下さい.
Stepwise Execution Context
既存のPeriodic Execution Contextでシミュレーションを行おうとするとデータの欠損などが発生し,再現性を保証できません.
ここでは,OpenRTM上でシミュレーションを行うためにRTC同士を協調的に動作させる独自実行コンテキスト(Stepwise Execution Context)について紹介します.
ソースコード(source_StepwiseEC.zip)
利用方法の概要
- ファイルを適切な位置に配置し, StepwiseSystem.h をインクルードする
- コンストラクタに StepwiseExecutionContextInit(m_pManager); を追記する
- rtc.confに exec_cxt.periodic.type: StepwiseExecutionContext を追記する
詳細な利用方法は,cv::flipによるStepwiseECを用いるRTCの作成例(source_Flip_StepwiseEC_0.zip)のreadme.htmlをご覧下さい.
動作環境
実行ファイルが動作することを確認した環境,ソースコードがビルドできることを確認した環境は次の通りです.
コンポーネントの動作テスト環境
OpenRTM-aistが動作するWindows環境であればMATLAB Compiler Runtimeをインストールするだけで動作します.
下記にサンプルコンポーネントを動作させる必要最低限の環境を示します.
パッケージ名 | 動作確認したバージョン | ダウンロードURL (ホームページ) |
Windows 64bit | Windows 7 Professional 64bit | |
OpenRTM-aist | 1.1.0 vc10 x64 | download ( http://www.openrtm.org/openrtm/ja/node/5012 ) |
Java JRE (64bit) | Java 8 Update 25 64-bit | download ( http://java.com/ja/download/manual.jsp ) |
Microsoft Visual C++ 2010 再頒布可能パッケージ (x64) | download ( http://www.microsoft.com/ja-jp/download/details.aspx?id=14632 ) |
|
MATLAB Compiler Runtime | R2014a (8.3) 64ビット | download ( http://www.mathworks.co.jp/products/compiler/mcr/ ) |
コンポーネントのビルド用環境
新しいRTCを作成する場合,RTCの開発環境に加えBoostライブラリが必要になります.
また,環境変数の設定が必要になります.
下記に動作確認した環境を示します.
パッケージ名 | 動作確認したバージョン,エディション | ダウンロードURL (ホームページ) |
Windows 64bit | Windows 7 Professional 64bit | |
OpenRTM-aist | 1.1.0 vc10 x64 | download ( http://www.openrtm.org/openrtm/ja/node/5012 ) |
OpenRTP | 1.1.0-RC4 Eclipse 3.8.1 Windows(64bit)用全部入り | download ( http://www.openrtm.org/openrtm/ja/node/30 ) |
Java JRE (64bit) | Java 8 Update 25 64-bit | download ( http://java.com/ja/download/manual.jsp ) |
Python-64bit | 2.7.3 | download ( https://www.python.org/ ) |
Python-32bit | 2.6.6 | download ( https://www.python.org/ ) |
PyYAML | 3.10 | download ( http://pyyaml.org/ ) |
CMake | 2.8.8 | download ( http://www.cmake.org/ ) |
Doxygen | 1.8.1 | download ( http://www.doxygen.jp/ ) |
Microsoft Visual Studio 2010 | Professional | |
MATLAB Compiler Runtime | R2014a (8.3) 64ビット | download ( http://www.mathworks.co.jp/products/compiler/mcr/ ) |
boost | 1.56.0 | download ( http://www.boost.org/ ) |
- Boostライブラリのビルド
コンパイル済みのBoostライブラリではCMakeによるfind_package()で${Boost_LIBRARY_DIRS}が設定されないため,Boostライブラリのコンパイルを推奨します.
- OpenRTPのアップデート
独自データ型(Timed_cvMat型)を使用するにはOpenRTPのアップデートが必要です.
アップデート方法については下記URLをご覧下さい.
http://openrtm.org/openrtm/ja/content/openrtp_plugin_update
- 環境変数に下記の値を追加
変数 | 値 |
PATH | C:\Python27 |
BOOST_ROOT | BOOSTのルートディレクトリ (上記インストール方法であれば C:\boost\boost_1_56_0 |
謝辞
本研究はJSPS科研費24500371の助成を受けたものです.
連絡先
- 電気通信大学 大学院 情報システム学研究科 情報メディアシステム学専攻 人間情報学講座 佐藤俊治研究室
- 〒182-8585 東京都調布市調布ヶ丘1-5-1 西10号館(IS棟) 435号室
- URL: http://www.hi.is.uec.ac.jp/ ,http://hi-brain.org/
- E-mail: daiki<at>hi.is.uec.ac.jp , hi-brain<at>hi.is.uec.ac.jp
コメント
Stepwise Execution Contextとはどういう動作をする実行コンテキストなのでしょうか?
基本的にはPeriodic Execution Contextと同様,onExecute()関数を周期的に呼び出します.
PeriodicECと異なる点は,StepwiseECで動作しているコンポーネント同士は協調的に動作します.
全てのコンポーネントがonExecute()関数の実行が終了したのを確認してから次のonExecute()関数を呼び出します.
つまり,onExecute()関数の実行に同期性があります.
これにより,転送されるデータの欠損などが発生しなくなり,シミュレーションにおける結果の再現性が保証できます.
返信ありがとうございます. binary_Lib_samplesのRTCを起動してアクティブにしても何も動作しなかったため、binary_StepwiseCtlCompのStepwiseCtlComp.exeでsを入力したら画像が表示されるようにはなったのですが、これで使い方は正しいのでしょうか? またExtTrigExecutionContextを使う場合に比べてどのような利点があるのでしょうか?
ExtTrigExecutionContextでもステップ実行は可能ですが,各コンポーネントの実行順番に応じて外部からtick()を呼び出す必要があります.また,外部のプログラムからは基本的にはコンポーネントの動作状況は分かりません.
一方StepwiseECであればコンポーネントの実行順番を考える必要がなく,並列実行できます.(データが到達していない場合は実行周期によるインターバルを経たのちにデータが到達するまで再実行を試みます.)また,RTCがデータ待ち・計算中・計算終了のどの状態かが分かります.これにより,デッドロックの発見や,計算の重たいRTCの特定およびそのアルゴリズムの改良や計算リソースの分配などが可能になるといった利点があります.
使い方に関しては,binary_Lib_samplesのRTCとbinary_StepwiseCtlCompのRTCを起動し,アクティブにすれば画像が連続して表示されるはずです.
ExtTrigExecutionContextについてはあまり詳しくないので,担当の者に質問を投げておきます.
回答にお時間がかかり申し訳ありませんが,ご了承願います.
このRTCは共有メモリを使うような、独自にデータポートを作成&利用されていますが、共有メモリを使う必然性は何なのでしょうか?シミュレーションでECをコントロールしていますので、実時間性は必要ないようですし、複数のRTCでの共有が必須のようにも見えないのですが。
視覚脳科学研究では画像(行列)を入出力として用いることが多く,画像サイズが大きくなるとコンポーネント間のデータ転送に要する時間が増えます.その結果シミュレーション全体に与える影響が大きくなります.
今回公開した共有メモリライブラリは共有メモリが使えるか否かを自動で判断する機能を実装しているため,ユーザーはPC内通信,PC外通信を意識することなく,データ転送に要するオーバーヘッドを減らすことが可能となります.
分野によってはデータポートの入出力に決まった処理を行う場合があり,今回の実装方法を真似ることでRTCを作成するたびに同じ処理を記述する必要がなくなるといった応用も考えられます.
返信ありがとうございます。共有メモリに関してなのですが、同じ計算機内でコンポーネント間でのデータの受け渡しは、複合コンポーネントとして実行させた方が効率がよいはずです。OpenRTM-aistでは、omniORBを使っており、多くのCORBAミドルウェアでは、同一プロセス内の通信は、通信自体を行わず、関数コールを行うのみですので、共有メモリよりもはるかに高速になります。 ちなみに、現在の実装で、共有メモリを使うポートと通常のRTCのデータポートを使った場合、どのくらいの性能差が出るのでしょうか?
定量的に、共有メモリを使わければ使い物にならないとのデータがプレゼンテーションの時に示していただければ、非常に有益な情報だと思っております。
それから、このRTCをより多くにシステムで再利用を行う場合に、データ型を合わせる必要があると思いますので、名城大の大原先生による標準インターフェースもRTCの設計に取り入れられることを期待しております。
複合コンポーネントについてあまり詳しくないのですが,複合コンポーネント化するだけでは同一プロセスで動作しなかったと記憶しております. 同一プロセスで動作させるのはRTC daemonではないでしょうか?
現在の実装では測定していませんが,参考までに私の所属する研究室の卒業生が測定したデータで,
通常のRTCのデータポートを使った場合はデータ転送に67msほどかかるのに対し,RTC daemonで生成したRTCのデータ転送は29ms,共有メモリを用いたRTCのデータ転送は19ms程度であるとの結果があります.
用いた画像は
2560×1920pixel,3チャンネル,ビット深度8bit
でデータサイズ14400KiB,環境は
ThinkStation D20,Windows7 Professional 64bit,Xeon X5675@3.06GHz,メモリ12GB
とのことです. 現在の実装で改めて測定を行い次第,結果をお知らせしたいと思います.
大原先生の「カメラ系の共通インターフェース」を用いたRTCの作成も検討してみます.
大変遅くなりましたが,現在の実装で改めて測定しましたので報告します.
1024×1024pixel,3チャンネル,ビット深度8bitでデータサイズ3072KiB
20,000回送信した時の平均値(OutPort/共有メモリへの書き込み開始~InPort/共有メモリから読み込み完了までの時間)
共有メモリ :2.0ms
全データ送信:12.0ms
RTC daemon:5.7ms
2048×2048pixel,3チャンネル,ビット深度8bitでデータサイズ12288KiB
20,000回送信した時の平均値(OutPort/共有メモリへの書き込み開始~InPort/共有メモリから読み込み完了までの時間)
共有メモリ :7.8ms
全データ送信:47.7ms
RTC daemon:18.7ms
測定結果は上記の通りです.
共有メモリを用いない場合に比べて約6倍,RTC daemonを用いた場合と比べても約2.4倍高速に転送できます.
テスト環境は
モデル:ThinkStation D20
OS:Windows7 Professional 64bit
CPU:Xeon X5675@3.06GHz デュアルCPU
メモリ:24GB
NIC:Broadcom NetXtreme Gigabit Ethernet
です.
発表ありがとうございました.素晴らしい作品ですね. 計測結果をアップしていただけたのも非常に嬉しいです.コメントできなかったので,会場で書き込んでいます(笑)
・是非,画像の共通インターフェースを利用していただきたかったです. ・共通メモリポートを実装していただいたのはとても面白いです.画像だけでも実装されているのは良いと思います.できればCVMat型だけでなく,他のデータ型にも対応できたらいいとも思います.書き込み時のシリアライゼーションはCORBAのものを再利用すれば便利だと思います. ・ExtTriggerECという外部トリガからonExecuteを呼ぶ実行コンテキストがあります.こちらとの比較ということも論じていただきたかったです