ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
とりあえず例のツールに機能を追加しました。
これで欲しかった機能はほぼ実装できたと思います。
これを使えば複合コンポーネントの利用が多少楽になるかもしれないです。
あらかじめ、Python2.7、pyQt4、OpenRTM-aist-Python-1.1.0-Release、rtctree、rtcprofile、rtshellをインストールしておいてください。
動作手順としては、
まずはSettingRTSystem.pyをダブルクリックして実行してください。
ツールが起動したら、新規作成ボタンを押してプロジェクトを新規作成します。
次にCPP、Pythonタブを選択→RTコンポーネントをファイルから読み込みボタンを押下して、起動したいRTCのDLL、Pythonファイルを選択します。
※この時モジュールの存在するディレクトリへのパスは相対パスで入力されるので作成したプロジェクトとモジュール、ツールを解凍したフォルダとの位置関係は変更しないでください、
今のところツールを解凍したフォルダのprojectフォルダにプロジェクトを作成してモジュールも同梱することを推奨しています。
ただし/usr/local/components/libに存在するモジュールを指定した場合のみ絶対パスで入力されるようになっています。Linuxの場合、RTCをビルド後make installと入力するとこのフォルダにモジュールがコピーされるので、それを利用させてもらっています。
次にRTCDタブに戻ってrtcd起動ボタンを押すことで選択したRTCを起動できます。
そしてRTシステムエディタでデータポート、サービスポートの接続、コンフィギュレーションパラメータの設定を行い、必要であれば複合コンポーネント作成します(必要でない場合はしなくてもかまいません)。
複合コンポーネントを起動するマネージャはツールと同時に起動したmanager_compositeをしていしてください。
そしてFile→Saveを選択して任意の場所にプロジェクトを保存してください。
すると作成したプロジェクトのフォルダ内にバッチファイルが生成されています。
この中のstart.bat(Linuxではstart.sh)を実行すると先ほど選択したRTCの起動、複合コンポーネントの起動、RTシステムの復元までを行います。
複合コンポーネント内で実行順序を設定したい場合は実行順序設定可能な実行コンテキストを指定する事もできます。
実行コンテキストタブから実行コンテキストをファイルから読み込みボタンを押下して、C++の場合はExecutionContext/MultipleOrderedEC/MultipleOrderedEC.dll、Pythonの場合はExecutionContext/MultipleOrderedEC-Python/MultipleOrderedEC.pyを指定します。
また別のマシン上でプロジェクトを作成したい場合、GUIを起動する側のマシンでは上記の通りツールを起動して、プロジェクトを作成する側のマシンではrtcConfSet/rtcConfSet.pyを起動してください。
そして以下のようにプロジェクトを作成する側のIPアドレスを指定することで作業ができます。
RTシステムの復元も行えるようになっていますが、通常の設定では先ほどの作業で指定したRTCとそれに接続されたRTCに関してのみ保存されるようになっています。
別プロセスでRTCを起動して、そのRTCに関しても保存したい場合はRTCのツリーから選択して外部のRTCをシステムに追加ボタンを押してください。
ツリーはRTCツリー更新ボタンを押すと表示されます。
まあこんなところか。
複合コンポーネントを作成する際にmanager_composite.mgrというマスターマネージャを指定してありますが、プロジェクト保存後に起動するとC++、もしくはPythonのrtcdで複合コンポーネントを起動するようにしています。C++のRTCが1つでも含まれているとC++のrtcdで複合コンポーネントを起動します。子RTCと同一プロセスで複合コンポーネントを起動することで子コンポーネントのコールバックを呼び出す際のオーバーヘッドを多少は軽減しています。
まだ使いづらい部分があるので改善していきたいとは思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
これで欲しかった機能はほぼ実装できたと思います。
これを使えば複合コンポーネントの利用が多少楽になるかもしれないです。
あらかじめ、Python2.7、pyQt4、OpenRTM-aist-Python-1.1.0-Release、rtctree、rtcprofile、rtshellをインストールしておいてください。
動作手順としては、
まずはSettingRTSystem.pyをダブルクリックして実行してください。
ツールが起動したら、新規作成ボタンを押してプロジェクトを新規作成します。
次にCPP、Pythonタブを選択→RTコンポーネントをファイルから読み込みボタンを押下して、起動したいRTCのDLL、Pythonファイルを選択します。
※この時モジュールの存在するディレクトリへのパスは相対パスで入力されるので作成したプロジェクトとモジュール、ツールを解凍したフォルダとの位置関係は変更しないでください、
今のところツールを解凍したフォルダのprojectフォルダにプロジェクトを作成してモジュールも同梱することを推奨しています。
ただし/usr/local/components/libに存在するモジュールを指定した場合のみ絶対パスで入力されるようになっています。Linuxの場合、RTCをビルド後make installと入力するとこのフォルダにモジュールがコピーされるので、それを利用させてもらっています。
次にRTCDタブに戻ってrtcd起動ボタンを押すことで選択したRTCを起動できます。
そしてRTシステムエディタでデータポート、サービスポートの接続、コンフィギュレーションパラメータの設定を行い、必要であれば複合コンポーネント作成します(必要でない場合はしなくてもかまいません)。
複合コンポーネントを起動するマネージャはツールと同時に起動したmanager_compositeをしていしてください。
そしてFile→Saveを選択して任意の場所にプロジェクトを保存してください。
すると作成したプロジェクトのフォルダ内にバッチファイルが生成されています。
この中のstart.bat(Linuxではstart.sh)を実行すると先ほど選択したRTCの起動、複合コンポーネントの起動、RTシステムの復元までを行います。
複合コンポーネント内で実行順序を設定したい場合は実行順序設定可能な実行コンテキストを指定する事もできます。
実行コンテキストタブから実行コンテキストをファイルから読み込みボタンを押下して、C++の場合はExecutionContext/MultipleOrderedEC/MultipleOrderedEC.dll、Pythonの場合はExecutionContext/MultipleOrderedEC-Python/MultipleOrderedEC.pyを指定します。
また別のマシン上でプロジェクトを作成したい場合、GUIを起動する側のマシンでは上記の通りツールを起動して、プロジェクトを作成する側のマシンではrtcConfSet/rtcConfSet.pyを起動してください。
そして以下のようにプロジェクトを作成する側のIPアドレスを指定することで作業ができます。
RTシステムの復元も行えるようになっていますが、通常の設定では先ほどの作業で指定したRTCとそれに接続されたRTCに関してのみ保存されるようになっています。
別プロセスでRTCを起動して、そのRTCに関しても保存したい場合はRTCのツリーから選択して外部のRTCをシステムに追加ボタンを押してください。
ツリーはRTCツリー更新ボタンを押すと表示されます。
まあこんなところか。
複合コンポーネントを作成する際にmanager_composite.mgrというマスターマネージャを指定してありますが、プロジェクト保存後に起動するとC++、もしくはPythonのrtcdで複合コンポーネントを起動するようにしています。C++のRTCが1つでも含まれているとC++のrtcdで複合コンポーネントを起動します。子RTCと同一プロセスで複合コンポーネントを起動することで子コンポーネントのコールバックを呼び出す際のオーバーヘッドを多少は軽減しています。
まだ使いづらい部分があるので改善していきたいとは思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
前々回の記事でかなり辛辣な事を言いましたが、今考えてもあれはかなり問題のある行動だと思います。
何が問題かというと本当にバグかどうか確認が取れていない段階でバグだと言っていた事で、しかもその内容をその場で言わなかった分さらにたちが悪いと思います。後で報告してそれでバグだったから良かったというわけではありません。
直接伝えるならまだしもTwitterで言うのがなあ・・・風評被害というのもありますからね。
なぜこんなに問題視するかはこのサイトを読んでいただければ分かると思います。
さすがにこれ以上は言うつもりはありませんけど、かなり失礼な行為なのでやめてほしいです。
それはさておき前回配布を開始したツールですが、とりあえず以下の変更をしたいと思っています。
まだ動作確認が不十分なのでその辺も何とかしたいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
何が問題かというと本当にバグかどうか確認が取れていない段階でバグだと言っていた事で、しかもその内容をその場で言わなかった分さらにたちが悪いと思います。後で報告してそれでバグだったから良かったというわけではありません。
直接伝えるならまだしもTwitterで言うのがなあ・・・風評被害というのもありますからね。
なぜこんなに問題視するかはこのサイトを読んでいただければ分かると思います。
さすがにこれ以上は言うつもりはありませんけど、かなり失礼な行為なのでやめてほしいです。
それはさておき前回配布を開始したツールですが、とりあえず以下の変更をしたいと思っています。
- rtcd以外で起動したRTCについても、指定したRTCについてはRTシステムとして保存(ツリーから選択するGUIを追加)
- Linuxへの対応
まだ動作確認が不十分なのでその辺も何とかしたいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
OpenRTM-aist-Python-1.1.0-Releaseのソースコードを読んでいたのですが、少し気になる点がありました。
PeriodicExecutionContext.pyのPeriodicExecutionContextInitで、
RC1では、
manager.registerECFactory～
だったのが、
OpenRTM_aist.ExecutionContextFactory.instance().addFactory～
に変更されています。
何の意味があるのかは分かりませんが、今までに作った独自の実行コンテキストが上記の変更をしないと使えなくなるので勘弁してほしいです。
一方、C++版の1.1.1-Releaseではmanager->registerECFactory～となっているのでそのままのようですね。
パッと見ただけでも変更点が多いような気がします。
1.1.0-RC1から1.1.0-Releaseへの更新なのですけど1.2ぐらいになったような変わりようです。
それはさておき、例のツールを配布します。
ここからダウンロードできます。
複合コンポーネントの利用を簡単にするのが目的のツールではあるのですが、他にも以下の機能があります。
ツール本体はOpenRTM-aistのPython版の1.1.0-Releaseでも1.1.0-RC1でも動作できますが、付属の実行コンテキストは上述の理由により1.1.0-Releaseでしか動作できません。
あと、pyQt4のインストールが必要です。
C++版のRTCを扱えますが、ツールの一部をOpenRTM-aist-1.1.1-Release(32bit)、Visual Studio 2013で作成してあるので他の環境で作成したRTCを扱いたい場合はそっちでビルドし直してください。
使い方ですが、
これでプロジェクトが作成されるはずです。
・・・どうにも手順が多いのでどこかで改善したいとは思います。
作成したフォルダのstart.batを実行すればRTCの起動、複合コンポーネント化、RTシステムの復元ができます。
projectフォルダにサンプルを付属させてあります。
利用するダイナミックリンクライブラリ、Pythonファイルとの相対パスが変わると読み込めなくなるので、できるだけそれらのファイル作成したプロジェクトのフォルダの中に入れてください。
/usr/local/components/libにインストールされたモジュールを読み込むのが一番な感じがしなくもないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PeriodicExecutionContext.pyのPeriodicExecutionContextInitで、
RC1では、
manager.registerECFactory～
だったのが、
OpenRTM_aist.ExecutionContextFactory.instance().addFactory～
に変更されています。
何の意味があるのかは分かりませんが、今までに作った独自の実行コンテキストが上記の変更をしないと使えなくなるので勘弁してほしいです。
一方、C++版の1.1.1-Releaseではmanager->registerECFactory～となっているのでそのままのようですね。
パッと見ただけでも変更点が多いような気がします。
1.1.0-RC1から1.1.0-Releaseへの更新なのですけど1.2ぐらいになったような変わりようです。
それはさておき、例のツールを配布します。
ここからダウンロードできます。
複合コンポーネントの利用を簡単にするのが目的のツールではあるのですが、他にも以下の機能があります。
- rtc.confのGUIによる編集機能
- コンフィギュレーションパラメータ設定ファイル自動作成機能
- rtshellによるRTシステムの復元、複合コンポーネントの作成、RTCの活性化、非活性化、終了のバッチファイル、シェルスクリプトの自動作成機能(作成したプロジェクトのバッチファイルを起動するだけでRTシステムの復元までを行います)
- 別のマシン上でのプロジェクト作成機能(例えばIntel Edison上でプロジェクト作成、別のPC上でGUIを操作すること等ができます)※一部機能が未実装
ツール本体はOpenRTM-aistのPython版の1.1.0-Releaseでも1.1.0-RC1でも動作できますが、付属の実行コンテキストは上述の理由により1.1.0-Releaseでしか動作できません。
あと、pyQt4のインストールが必要です。
C++版のRTCを扱えますが、ツールの一部をOpenRTM-aist-1.1.1-Release(32bit)、Visual Studio 2013で作成してあるので他の環境で作成したRTCを扱いたい場合はそっちでビルドし直してください。
使い方ですが、
- 解凍したフォルダの直下のSettingRTSystem.batを実行する
- ファイル→Newを押して新規作成する(既に開きたいファイルがある場合はOpenを選択する)
- C++タブ、もしくはPythonタブを選択後する
- マネージャタブを選択する
- RTコンポーネントのファイルから読み込みボタンを押して起動したいRTC(C++はdll、so、Pythonはpyの拡張子のファイル)を選択する
- RTCDタブを選択する
- rtcd起動ボタンを押してC++、Pythonのrtcdを起動する
- RTシステムエディタでデータポートの接続、複合コンポーネント作成、コンフィギュレーションパラメータの変更等を行う
- File→Saveを選択してファイルを保存する
これでプロジェクトが作成されるはずです。
・・・どうにも手順が多いのでどこかで改善したいとは思います。
作成したフォルダのstart.batを実行すればRTCの起動、複合コンポーネント化、RTシステムの復元ができます。
projectフォルダにサンプルを付属させてあります。
利用するダイナミックリンクライブラリ、Pythonファイルとの相対パスが変わると読み込めなくなるので、できるだけそれらのファイル作成したプロジェクトのフォルダの中に入れてください。
/usr/local/components/libにインストールされたモジュールを読み込むのが一番な感じがしなくもないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
RTM講習会ではOpenRTM-aistのC++版は1.1.1-Release、Python版は1.1.0-Release、を使ったらしいですが、公式サイトでは最新版は1.1.0-Releaseと1.1.0-RC1が最新版と書いてあるので扱いがいまいち分かりません。
ひょっとして講習会で実験的に使っただけで正式にリリースはしていないのではないでしょうか？
よく分かりませんが新しい方をインストールしておきます。
何らかの更新があればまたインストールしなおせば良いと思います。
それにしても、src/Releaseに実行ファイルが生成される誰も得しない謎仕様は何とかならないのでしょうかね？
直下のReleaseフォルダに生成してくれたほうが直感的に分かりやすいように思うのですが。
あまり関係ないけどメーリングリストで言われてたサービスポートの不具合って、
typedef short shortArray10 [10];
ではなくて通常は、
typedef sequence<short> shortArray10;
と記述するものではないのですかね？
そうすれば、
sample::shortArray10_out a, const sample::shortArray10& b
となるので特に問題はなさそうに見えます。
多分ですけど、この人ってtwitterでOpenRTM-aist-1.1.1-Releaseにバグがあるとか言っていた人でしょうかね？
あくまで僕の考えですが、プログラムをやっている人はバグという言葉に非常に敏感だと思います。不具合の内容も言うのであれば良いのですが、この人は不具合の内容を言わずにバグ見つけたとだけtwitterで言っていました。かなり癇に障る行為だと思うので絶対に真似をしないでください。結果的にそれがバグだったかどうかは関係ありません。
前回の記事の補足ですけど、rtctreeでマスターマネージャからスレーブマネージャの一覧を取得するプログラムで、
print mgr._obj.get_slave_managers()
を追加すると、
[<RTM._objref_Manager instance at 0x044E1D28>, <RTM._objref_Manager instance at 0x044E1C60>]
と出力されるのでちゃんとスレーブマネージャは2つ登録されているみたいです。
ということはprint mgr.slavesとした時だけ正常に取得ができないということだろうか？
rtshellのrtcryo.pyを読んでみたのですけど、find_all_used_components関数で指定したネームサーバー上のRTCの内ポートの接続されているものを取得しているみたいなので、指定したRTCのみのRTシステムを保存するのは現状無理みたいですね。
まあrtcryoの関数を利用すればこちらで独自に作ることもできるのでそうします。
freeze_dry関数のfind_all_used_components～の部分を変更したいだけなのでほぼコピペになりそうなのが不安です。
例のツールですが、今週中には完成しそうです。
それから4自由度アーム、クローラー制御関連のRTC、実行順序設定可能な実行コンテキストも更新する予定です。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ひょっとして講習会で実験的に使っただけで正式にリリースはしていないのではないでしょうか？
よく分かりませんが新しい方をインストールしておきます。
何らかの更新があればまたインストールしなおせば良いと思います。
それにしても、src/Releaseに実行ファイルが生成される誰も得しない謎仕様は何とかならないのでしょうかね？
直下のReleaseフォルダに生成してくれたほうが直感的に分かりやすいように思うのですが。
あまり関係ないけどメーリングリストで言われてたサービスポートの不具合って、
typedef short shortArray10 [10];
ではなくて通常は、
typedef sequence<short> shortArray10;
と記述するものではないのですかね？
そうすれば、
sample::shortArray10_out a, const sample::shortArray10& b
となるので特に問題はなさそうに見えます。
多分ですけど、この人ってtwitterでOpenRTM-aist-1.1.1-Releaseにバグがあるとか言っていた人でしょうかね？
あくまで僕の考えですが、プログラムをやっている人はバグという言葉に非常に敏感だと思います。不具合の内容も言うのであれば良いのですが、この人は不具合の内容を言わずにバグ見つけたとだけtwitterで言っていました。かなり癇に障る行為だと思うので絶対に真似をしないでください。結果的にそれがバグだったかどうかは関係ありません。
前回の記事の補足ですけど、rtctreeでマスターマネージャからスレーブマネージャの一覧を取得するプログラムで、
print mgr._obj.get_slave_managers()
を追加すると、
[<RTM._objref_Manager instance at 0x044E1D28>, <RTM._objref_Manager instance at 0x044E1C60>]
と出力されるのでちゃんとスレーブマネージャは2つ登録されているみたいです。
ということはprint mgr.slavesとした時だけ正常に取得ができないということだろうか？
rtshellのrtcryo.pyを読んでみたのですけど、find_all_used_components関数で指定したネームサーバー上のRTCの内ポートの接続されているものを取得しているみたいなので、指定したRTCのみのRTシステムを保存するのは現状無理みたいですね。
まあrtcryoの関数を利用すればこちらで独自に作ることもできるのでそうします。
freeze_dry関数のfind_all_used_components～の部分を変更したいだけなのでほぼコピペになりそうなのが不安です。
例のツールですが、今週中には完成しそうです。
それから4自由度アーム、クローラー制御関連のRTC、実行順序設定可能な実行コンテキストも更新する予定です。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
この文書なんかを読んでいて気付いたのですが、複合コンポーネントとrtcdは混同しやすいのではないかと思いました。
まず複合コンポーネントというのはこの論文に書いてある通り「幾つかのRTコンポーネント (RTC) を合成してひとつのRTCにする手法」の事で、複数のRTCを一纏めにして指定したポートだけ公開することで内部の隠蔽ができるようになっています。
rtcdはマネージャーの起動のみを行います。
rtcdではどのDLLをロードしてRTCを起動するかはrtc.confに記述します。
単一のマネージャで複数のRTCを起動することも可能です。
同一プロセスでRTCを起動するため、通信は高速に行える等のメリットがあります。
分かりづらいと言えばマスターマネージャとスレーブマネージャが理解しづらいです。
というよりも僕もよく分かっていません。
この論文を読む限りでは、外部から操作を受け付けてスレーブマネージャにRTC起動等の要求を出すのがマスターマネージャで、マスターマネージャからの要求に従ってRTCの起動などを行うのがスレーブマネージャという認識でいいのかな？
いやでもマスターマネージャでもRTCの起動はできているように見える、というかほとんどその使われ方しかしていないように思うのですが、現状がどうなっているのかは分かりません。
ひょっとして内部的には新たにスレーブマネージャを起動してRTCを起動しているのだろうか？
見た目ではよく分かりません。
スレーブマネージャはマスターマネージャの要求がなくとも自分でRTCを起動している、というよりも現在存在するRTCのほとんどはそうなっていると思うのですが、よく分かりません。
僕はですがこのあたりでマスターマネージャとスレーブマネージャの区別が曖昧になっています。
外部から操作するとなったらマネージャの起動したプロセスでGUIも起動するという方法もありますが、基本的にはRTシステムエディタ、rtshell、rtctreeで操作することにはなるので、スレーブマネージャはマスターマネージャを経由して操作する必要があるとは思います。
・・・・が、RTシステムエディタ、rtshellでの操作方法が分かりませんでした。
仕方ないのでrtctreeを使って以下のようなプログラムを書きました。
見ての通りmanager.mgrというマスターマネージャにどのようなスレーブマネージャが登録されているか確認するためのプログラムです。
import rtctree.tree
tree = rtctree.tree.RTCTree(servers='localhost:2809')
mgr = tree.get_node(['/', 'localhost:2809' ,'manager.mgr'])
#print mgr.masters
print mgr.slaves
del tree
まずマスターマネージャでmanager.mgrを起動します。
次にサンプルのConsoleIn、ConsoleOutを起動します。
この時点でConsoleIn、ConsoleOutのRTCを起動したマネージャはスレーブマネージャとして起動してあるためmanager.mgrのスレーブとして登録されるはずです。
・・・・が、実行結果は以下の通り何故か一つしかスレーブマネージャが登録されていません。
[<rtctree.manager.Manager object at 0x02C1CF90>]
確認のためにmanager.mgrを起動したプログラムで以下の処理を追加しました。
while True:
print mgr._mgrservant.get_slave_managers()
結果は以下の通り2つのスレーブマネージャが登録されています。
[<RTM._objref_Manager instance at 0x026A5850>, <RTM._objref_Manager instance at 0x026A20F8>]
な… 何を言っているのか わからねーと思うが(ry
このネタを使うのは2週間ぐらい早かったかもしれません。
ちなみにrtctreeのプログラムでprint mgr.componentsとするとちゃんと2つのRTCが存在することが確認できたので、スレーブマネージャで起動したRTCを取得できてはいるみたいです。
どうにも僕のマスターマネージャ、スレーブマネージャに関する認識が違うのではないかと思い始めました。
前にどこかのブログでマネージャの説明をしているのを見たようなと思って探してみたらこのサイトがそうだったみたいです。
前半部分は同じ認識だと思うのですが、後半部分が一致しません。
そもそも複合コンポーネントを作成する手順は、
それからスレーブマネージャは起動した時点で対応するポート番号のマスターマネージャに登録されると思っていたので複合コンポーネントと関係はないと思うのですがもう何がなんやら分からなくなってきました。
やっぱりややこしいなあ。
誰かOpenRTM-aistのサイトのwikiに解説記事を書いてください。
だいたい誰も教えてくれないから混乱するのであって僕は悪くありません。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まず複合コンポーネントというのはこの論文に書いてある通り「幾つかのRTコンポーネント (RTC) を合成してひとつのRTCにする手法」の事で、複数のRTCを一纏めにして指定したポートだけ公開することで内部の隠蔽ができるようになっています。
rtcdはマネージャーの起動のみを行います。
rtcdではどのDLLをロードしてRTCを起動するかはrtc.confに記述します。
単一のマネージャで複数のRTCを起動することも可能です。
同一プロセスでRTCを起動するため、通信は高速に行える等のメリットがあります。
分かりづらいと言えばマスターマネージャとスレーブマネージャが理解しづらいです。
というよりも僕もよく分かっていません。
この論文を読む限りでは、外部から操作を受け付けてスレーブマネージャにRTC起動等の要求を出すのがマスターマネージャで、マスターマネージャからの要求に従ってRTCの起動などを行うのがスレーブマネージャという認識でいいのかな？
いやでもマスターマネージャでもRTCの起動はできているように見える、というかほとんどその使われ方しかしていないように思うのですが、現状がどうなっているのかは分かりません。
ひょっとして内部的には新たにスレーブマネージャを起動してRTCを起動しているのだろうか？
見た目ではよく分かりません。
スレーブマネージャはマスターマネージャの要求がなくとも自分でRTCを起動している、というよりも現在存在するRTCのほとんどはそうなっていると思うのですが、よく分かりません。
僕はですがこのあたりでマスターマネージャとスレーブマネージャの区別が曖昧になっています。
外部から操作するとなったらマネージャの起動したプロセスでGUIも起動するという方法もありますが、基本的にはRTシステムエディタ、rtshell、rtctreeで操作することにはなるので、スレーブマネージャはマスターマネージャを経由して操作する必要があるとは思います。
・・・・が、RTシステムエディタ、rtshellでの操作方法が分かりませんでした。
仕方ないのでrtctreeを使って以下のようなプログラムを書きました。
見ての通りmanager.mgrというマスターマネージャにどのようなスレーブマネージャが登録されているか確認するためのプログラムです。
import rtctree.tree
tree = rtctree.tree.RTCTree(servers='localhost:2809')
mgr = tree.get_node(['/', 'localhost:2809' ,'manager.mgr'])
#print mgr.masters
print mgr.slaves
del tree
まずマスターマネージャでmanager.mgrを起動します。
次にサンプルのConsoleIn、ConsoleOutを起動します。
この時点でConsoleIn、ConsoleOutのRTCを起動したマネージャはスレーブマネージャとして起動してあるためmanager.mgrのスレーブとして登録されるはずです。
・・・・が、実行結果は以下の通り何故か一つしかスレーブマネージャが登録されていません。
[<rtctree.manager.Manager object at 0x02C1CF90>]
確認のためにmanager.mgrを起動したプログラムで以下の処理を追加しました。
while True:
print mgr._mgrservant.get_slave_managers()
結果は以下の通り2つのスレーブマネージャが登録されています。
[<RTM._objref_Manager instance at 0x026A5850>, <RTM._objref_Manager instance at 0x026A20F8>]
な… 何を言っているのか わからねーと思うが(ry
このネタを使うのは2週間ぐらい早かったかもしれません。
ちなみにrtctreeのプログラムでprint mgr.componentsとするとちゃんと2つのRTCが存在することが確認できたので、スレーブマネージャで起動したRTCを取得できてはいるみたいです。
どうにも僕のマスターマネージャ、スレーブマネージャに関する認識が違うのではないかと思い始めました。
前にどこかのブログでマネージャの説明をしているのを見たようなと思って探してみたらこのサイトがそうだったみたいです。
前半部分は同じ認識だと思うのですが、後半部分が一致しません。
そもそも複合コンポーネントを作成する手順は、
- どこかのマネージャで複合コンポーネントを起動する
- 複合コンポーネントに子コンポーネントを登録する
- 公開するデータポートを指定する
それからスレーブマネージャは起動した時点で対応するポート番号のマスターマネージャに登録されると思っていたので複合コンポーネントと関係はないと思うのですがもう何がなんやら分からなくなってきました。
やっぱりややこしいなあ。
誰かOpenRTM-aistのサイトのwikiに解説記事を書いてください。
だいたい誰も教えてくれないから混乱するのであって僕は悪くありません。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
