ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
そういえば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は同一プロセスで動作しておくべきだとは思います。コールバックの呼び出しでのオーバーヘッドが多少は少なくなります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする
