ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
前々回の記事でかなり辛辣な事を言いましたが、今考えてもあれはかなり問題のある行動だと思います。
何が問題かというと本当にバグかどうか確認が取れていない段階でバグだと言っていた事で、しかもその内容をその場で言わなかった分さらにたちが悪いと思います。後で報告してそれでバグだったから良かったというわけではありません。
直接伝えるならまだしもTwitterで言うのがなあ・・・風評被害というのもありますからね。
なぜこんなに問題視するかはこのサイトを読んでいただければ分かると思います。
さすがにこれ以上は言うつもりはありませんけど、かなり失礼な行為なのでやめてほしいです。
それはさておき前回配布を開始したツールですが、とりあえず以下の変更をしたいと思っています。
まだ動作確認が不十分なのでその辺も何とかしたいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
何が問題かというと本当にバグかどうか確認が取れていない段階でバグだと言っていた事で、しかもその内容をその場で言わなかった分さらにたちが悪いと思います。後で報告してそれでバグだったから良かったというわけではありません。
直接伝えるならまだしもTwitterで言うのがなあ・・・風評被害というのもありますからね。
なぜこんなに問題視するかはこのサイトを読んでいただければ分かると思います。
さすがにこれ以上は言うつもりはありませんけど、かなり失礼な行為なのでやめてほしいです。
それはさておき前回配布を開始したツールですが、とりあえず以下の変更をしたいと思っています。
- rtcd以外で起動したRTCについても、指定したRTCについてはRTシステムとして保存(ツリーから選択するGUIを追加)
- Linuxへの対応
まだ動作確認が不十分なのでその辺も何とかしたいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
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に解説記事を書いてください。
だいたい誰も教えてくれないから混乱するのであって僕は悪くありません。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
そういえばOpenELってどうなったのですかね？
Raspberry Piで動作させるという記事があったのですが、肝心のOpenELの部分の内容が少なかったためよく分かりませんでした。
OpenELに対応していないモータードライバやセンサを使おうと思ったら結局自分でOpenEL対応のプログラムを書かなくてはならないと思うので、この記事で作成したものに関してはOpenELを使う利点は特にないよう思うのですがよく分かりません。詳しい人は教えてください。
※ややこしそうなので追記しますが、ここからは全く別の話です
複合コンポーネントを作る際にマネージャを指定するのが地味に面倒だと思います。
ひょっとしてサンプルのCompsiteみたいにコンフィギュレーションパラメータ設定ファイルに複合するコンポーネント名を記述するのが本来のやり方なのだろうか？
ひょっとしたらサンプルに含まれている割には動作があまり知られていないかもしれないので、少し説明しておきます。
このサンプルを実行するのに必要なファイルは以下の通りです。
マネージャを起動する実行ファイル
Compsite.exe
設定ファイル
rtc_composite.conf
コンフィギュレーションパラメータ設定ファイル
composite.conf
読み込むモジュール
Controller.dll
Motor.dll
Sensor.dll
まず本体のCompsite.exeという実行ファイルですが、これは他の実行ファイルと違って特定のRTCの起動を行うものではありません。
rtcdみたいにマネージャだけ起動するようにしています。
そしてrtc_composite.confではPeriodicECSharedCompositeというコンポーネントを起動するように設定しています。これは以前説明した通り実行コンテキストを共有する複合コンポーネントです。
肝心の複合するコンポーネントをどこで指定するかというとcomposite.confというコンフィギュレーションパラメータ設定ファイルで指定しています。つまりコンフィギュレーションパラメータで設定できるということです。
membersというパラメータで複合するコンポーネント、exported_portsというパラメータで公開するデータポート、サービスポートを指定できます。
ただ、membersという変数の使い方がよく分かりません。ソースコードを読んでみた感じでの想像ですが、同一マネージャで起動したRTCに関してはここで指定した名前で指定できそうですが、他のプロセスで起動したマネージャでは指定できないのではないかと思うのですがどうでしょうね？
とりあえずサンプルの方法で複合コンポーネントを起動するまでの手順を説明します。
まずはrtc.confを編集します。
複合するモジュールをロードします。
manager.modules.preload: Controller.dll, Motor.dll, Sensor.dll
次に複合コンポーネントと複合するRTCを起動します。
manager.components.precreate: Controller, Motor, Sensor, PeriodicECSharedComposite
そして複合コンポーネントのコンフィギュレーションパラメータ設定ファイルを指定します。
composite.PeriodicECShared.PeriodicECSharedComposite0.config_file: composite.conf
次にcomposite.confを編集します。
まずは複合するRTCを指定します。
conf.default.members: Sensor0, Controller0, Motor0
次に公開するデータポートを指定します。
conf.default.exported_ports: Motor0.out, Sensor0.in
これで完了です。
他のマネージャで起動したRTCを複合する場合はRTシステムエディタとかrtshell、rtctreeでやる必要があるのかどうかは怪しいですが、一応そちらでもできます。
rtshellでは、
rtcomp 複合コンポーネント名 複合するRTCの名前：公開するポート名
で複合するRTCを追加できるようです。
rtctreeの場合はadd_membersでRTCを追加後、set_conf_set_value関数でexported_portsを設定してください。
小技ですが、
manager.components.precreate: PeriodicECSharedComposite?&instance_name=CompositeRTC.rtc
のようにすることでコンポーネント名を変更できるので必要ならばそうしてください。
さすがになんでもかんでもPeriodicECSharedCompositeという名前では不便だと思うので。
後、以前の記事で複合コンポーネントの動作に関してかなり頓珍漢な間違ったことを書いてしまったのでここでお詫びしておきます。今は間違っていた部分は抹消した後なので分かりませんが、複合コンポーネントをアクティブにしても複合コンポーネント化した際にアタッチした実行コンテキストに関して複合したRTCがアクティブにはならないとか意味不明なことを書いていました。多分、複合コンポーネントのコールバックで各RTCのコールバックが呼び出されるとか勘違いしていたのだと思います。
RTC1、RTC2を複合化すると複合コンポーネントの実行コンテキストEC3にアタッチされます。複合コンポーネントをアクティブにしたときのコールバックで他のRTCもアクティブにするようになっています。よって各RTCのコールバックはEC3で呼び出されます。
以前の記事で言った状態は共有して実行コンテキストは共有しないという複合コンポーネントもこちらで独自に作ることはできそうです。
要はPeriodicECSharedComposite.pyの、
ecs[0].activate_component(rtc)
を
rtc.get_owned_contexts[0].activate_component(rtc)
にすれば実現できそうです。
一部のRTCがエラーになった場合は、複合コンポーネントのonExecuteで状態を監視しておけば複合コンポーネントもエラーに遷移できそうです。
基本的に複合コンポーネントと複合される側のRTCは同一プロセスで動作しておくべきだとは思います。コールバックの呼び出しでのオーバーヘッドが多少は少なくなります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
Raspberry Piで動作させるという記事があったのですが、肝心のOpenELの部分の内容が少なかったためよく分かりませんでした。
OpenELに対応していないモータードライバやセンサを使おうと思ったら結局自分でOpenEL対応のプログラムを書かなくてはならないと思うので、この記事で作成したものに関してはOpenELを使う利点は特にないよう思うのですがよく分かりません。詳しい人は教えてください。
※ややこしそうなので追記しますが、ここからは全く別の話です
複合コンポーネントを作る際にマネージャを指定するのが地味に面倒だと思います。
ひょっとしてサンプルのCompsiteみたいにコンフィギュレーションパラメータ設定ファイルに複合するコンポーネント名を記述するのが本来のやり方なのだろうか？
ひょっとしたらサンプルに含まれている割には動作があまり知られていないかもしれないので、少し説明しておきます。
このサンプルを実行するのに必要なファイルは以下の通りです。
マネージャを起動する実行ファイル
Compsite.exe
設定ファイル
rtc_composite.conf
コンフィギュレーションパラメータ設定ファイル
composite.conf
読み込むモジュール
Controller.dll
Motor.dll
Sensor.dll
まず本体のCompsite.exeという実行ファイルですが、これは他の実行ファイルと違って特定のRTCの起動を行うものではありません。
rtcdみたいにマネージャだけ起動するようにしています。
そしてrtc_composite.confではPeriodicECSharedCompositeというコンポーネントを起動するように設定しています。これは以前説明した通り実行コンテキストを共有する複合コンポーネントです。
肝心の複合するコンポーネントをどこで指定するかというとcomposite.confというコンフィギュレーションパラメータ設定ファイルで指定しています。つまりコンフィギュレーションパラメータで設定できるということです。
membersというパラメータで複合するコンポーネント、exported_portsというパラメータで公開するデータポート、サービスポートを指定できます。
ただ、membersという変数の使い方がよく分かりません。ソースコードを読んでみた感じでの想像ですが、同一マネージャで起動したRTCに関してはここで指定した名前で指定できそうですが、他のプロセスで起動したマネージャでは指定できないのではないかと思うのですがどうでしょうね？
とりあえずサンプルの方法で複合コンポーネントを起動するまでの手順を説明します。
まずはrtc.confを編集します。
複合するモジュールをロードします。
manager.modules.preload: Controller.dll, Motor.dll, Sensor.dll
次に複合コンポーネントと複合するRTCを起動します。
manager.components.precreate: Controller, Motor, Sensor, PeriodicECSharedComposite
そして複合コンポーネントのコンフィギュレーションパラメータ設定ファイルを指定します。
composite.PeriodicECShared.PeriodicECSharedComposite0.config_file: composite.conf
次にcomposite.confを編集します。
まずは複合するRTCを指定します。
conf.default.members: Sensor0, Controller0, Motor0
次に公開するデータポートを指定します。
conf.default.exported_ports: Motor0.out, Sensor0.in
これで完了です。
他のマネージャで起動したRTCを複合する場合はRTシステムエディタとかrtshell、rtctreeでやる必要があるのかどうかは怪しいですが、一応そちらでもできます。
rtshellでは、
rtcomp 複合コンポーネント名 複合するRTCの名前：公開するポート名
で複合するRTCを追加できるようです。
rtctreeの場合はadd_membersでRTCを追加後、set_conf_set_value関数でexported_portsを設定してください。
小技ですが、
manager.components.precreate: PeriodicECSharedComposite?&instance_name=CompositeRTC.rtc
のようにすることでコンポーネント名を変更できるので必要ならばそうしてください。
さすがになんでもかんでもPeriodicECSharedCompositeという名前では不便だと思うので。
後、以前の記事で複合コンポーネントの動作に関してかなり頓珍漢な間違ったことを書いてしまったのでここでお詫びしておきます。今は間違っていた部分は抹消した後なので分かりませんが、複合コンポーネントをアクティブにしても複合コンポーネント化した際にアタッチした実行コンテキストに関して複合したRTCがアクティブにはならないとか意味不明なことを書いていました。多分、複合コンポーネントのコールバックで各RTCのコールバックが呼び出されるとか勘違いしていたのだと思います。
RTC1、RTC2を複合化すると複合コンポーネントの実行コンテキストEC3にアタッチされます。複合コンポーネントをアクティブにしたときのコールバックで他のRTCもアクティブにするようになっています。よって各RTCのコールバックはEC3で呼び出されます。
以前の記事で言った状態は共有して実行コンテキストは共有しないという複合コンポーネントもこちらで独自に作ることはできそうです。
要はPeriodicECSharedComposite.pyの、
ecs[0].activate_component(rtc)
を
rtc.get_owned_contexts[0].activate_component(rtc)
にすれば実現できそうです。
一部のRTCがエラーになった場合は、複合コンポーネントのonExecuteで状態を監視しておけば複合コンポーネントもエラーに遷移できそうです。
基本的に複合コンポーネントと複合される側のRTCは同一プロセスで動作しておくべきだとは思います。コールバックの呼び出しでのオーバーヘッドが多少は少なくなります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
