ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[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
パソコンがお亡くなりになったので作業が滞りそうです。
何年も前から言おうとして言っていなかったのですが、コンポーネントやマネージャのネーミングフォーマットを%h.host_cxt/%n.mgrや%p.host_cxt/%n.rtc等とはすべきではないと思います。
まあ単純にホスト名やプロセスIDが加わるとRTシステムエディタ等で保存したRTシステムを復元できないかもしれないというのが理由ですけど。
rtshellでスクリプトを書くにしてもRTCのパスが変わるので面倒くさいです。
できるだけ環境が変わっても変化しないような名前を付けておいたほうがよいと思います。
まあ%n.rtcとか付けるのが楽なのですが同じRTCを2つ起動したときに名前が被るせいで1つしか動作しないなんて事はよくあると思うので出来ればやめておいたほうがよさそうです。
ネーミングフォーマットに関して何か明確なルールがあるのかどうかはよく分からないので詳しい人は教えてください。
rtshellではrtcryoと言うコマンドでRTシステムの保存、rtresurrectでRTシステムの復元ができるようになっています。
cmd /c rtcryo localhost -o sys.rtsys
でlocalhostのネームサーバー上のデータポート、サービスポートが接続されているRTCをRTシステムとしてsys.rtsysというファイルに保存できるみたいです。
できればこちらで指定したRTCのみ保存できないかとも思ったのですが、やり方がよく分かりません。詳しい人は教えてください。
あまり関係ないけど、コンフィギュレーションパラメータをファイルから読み込んでRTCを起動したときに1回だけ実行する処理で利用する場合(例えばコンフィギュレーションパラメータでファイル名を指定して読み込む等)、以前にonStartupでその処理をしていたRTCがあったような記憶があるのですがこれはやるべきではありません。
onStartupは実行コンテキストをがstartイベントを受け取って実行状態に遷移した時に呼び出されるので複数回呼び出される可能性があります。onInitialize内でbindParameterをした後に処理を実行すべきです。ただしonInitializeではファイルから読み込んだパラメータがコンフィギュレーションパラメータに反映されていないのでupdateParameters関数で更新しておきましょう。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
何年も前から言おうとして言っていなかったのですが、コンポーネントやマネージャのネーミングフォーマットを%h.host_cxt/%n.mgrや%p.host_cxt/%n.rtc等とはすべきではないと思います。
まあ単純にホスト名やプロセスIDが加わるとRTシステムエディタ等で保存したRTシステムを復元できないかもしれないというのが理由ですけど。
rtshellでスクリプトを書くにしてもRTCのパスが変わるので面倒くさいです。
できるだけ環境が変わっても変化しないような名前を付けておいたほうがよいと思います。
まあ%n.rtcとか付けるのが楽なのですが同じRTCを2つ起動したときに名前が被るせいで1つしか動作しないなんて事はよくあると思うので出来ればやめておいたほうがよさそうです。
ネーミングフォーマットに関して何か明確なルールがあるのかどうかはよく分からないので詳しい人は教えてください。
rtshellではrtcryoと言うコマンドでRTシステムの保存、rtresurrectでRTシステムの復元ができるようになっています。
cmd /c rtcryo localhost -o sys.rtsys
でlocalhostのネームサーバー上のデータポート、サービスポートが接続されているRTCをRTシステムとしてsys.rtsysというファイルに保存できるみたいです。
できればこちらで指定したRTCのみ保存できないかとも思ったのですが、やり方がよく分かりません。詳しい人は教えてください。
あまり関係ないけど、コンフィギュレーションパラメータをファイルから読み込んでRTCを起動したときに1回だけ実行する処理で利用する場合(例えばコンフィギュレーションパラメータでファイル名を指定して読み込む等)、以前にonStartupでその処理をしていたRTCがあったような記憶があるのですがこれはやるべきではありません。
onStartupは実行コンテキストをがstartイベントを受け取って実行状態に遷移した時に呼び出されるので複数回呼び出される可能性があります。onInitialize内でbindParameterをした後に処理を実行すべきです。ただしonInitializeではファイルから読み込んだパラメータがコンフィギュレーションパラメータに反映されていないのでupdateParameters関数で更新しておきましょう。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
rtc.confの記述方法に関して1つよく分からない事があります。
いやコンフィギュレーションパラメータのファイルとか他にも分かりづらい部分はあるのですが、それはおいておきます。
通常RTCを起動する際に、
実行ファイル名 -f 設定ファイル名
として起動すると思います。
ここで実行ファイル、設定ファイルは以下のパスにあるとします。
実行ファイル C:\RTCD\rtcd.exe
設定ファイル C:\Conf\rtc.conf
そしてrtc.conf内のmanager.modules.load_pathにはDLL等の存在するディレクトリのパスを指定すると思います。今回はDLLと言う名前のフォルダを指定しているとします。
ここでC:\RTCDで、
rtcd -f ../Conf/rtc.conf
と入力します。
この時どこのディレクトリからモジュールをロードするかと言うと、
C:\RTCD\DLL
になります。
色々ツールを作る中でC:\Conf\DLLのようにコンフィギュレーションファイルの存在するディレクトリからの相対パスで指定できないと不都合が多い事が分かってきました。
僕の認識としては、設定ファイル＋コンフィギュレーションパラメータ設定ファイル＋各モジュールがセットで、設定ファイルをrtcdで読み込むことでRTCを起動できると思っていたのですが少し違うのですかね？
例えば、Test1とTest2というフォルダがあるとします。
それぞれのフォルダには、
Test1
-rtc.conf
-bin
--test1_1.dll
--test1_2.dll
-conf
--test1_10.conf
--test1_11.conf
--test1_20.conf
Test2
-rtc.conf
-bin
--test2_1.dll
--test2_2.dll
-conf
--test2_10.conf
--test2_20.conf
のように設定ファイル、dll等が入っているとします。
この状態でrtc.confのmanager.modules.load_pathにrtcdからのconfフォルダへのパスを記述するのは直感的に分かりづらいです。
最大の問題はTest1、Test2のフォルダが別の場所に移動してしまった時で、非常に面倒くさいことになります。解決策としてはrtcd.exeの存在するフォルダにパスを通した後Test1、Test2のフォルダまで移動してrtcd -f rtc.confと入力すれば動作はできますが、それはそれでコマンドが増えるのであまり気が進みません。と言うかできれば今いるディレクトリからは移動せずにRTCを起動したいとは思うのですが、都合良くはできていないようです。
それはさておき、今回のツールはPythonと一部C++で実装します。Javaには対応しない予定です。.NETには対応するかもしれないです。
rtcdでRTCを起動するためにrtc.confの作成が必要ですが、言語ごとに作成する必要があるのが面倒です。
rtc.conf設定用GUIを流用するのでGUIの部分は楽ができそうです。
理想としてはEdisonやRaspberry Pi上で動作するRTCに関しても、GUIは別のPCで操作してシングルボードコンピュータ上にシェルスクリプト、設定ファイルを作成するようにしたいです。
まあEdisonでデスクトップをX Windowを動作させてVNC接続する事もできるとは思うので、そちらでGUIを操作しても良いのですがあまりデスクトップ表示させている人もいないしなあ。
多分、かなりイライラする程度の動作の重さにはなると思うのでやめておきます。
おまけですが、コンフィギュレーションパラメータ設定ファイル作成ツールを作りました。いや別にRTCビルダで作成すれば良いのですが、できればRTシステムエディタで起動したRTCのコンフィギュレーションパラメータを変更して、そのパラメータからファイルを作れたら便利だと思うので簡単に作ってみました。使うにはOpenRTM-aistのPython版、rtctreeが必要です。
使い方としては、
python RTCConfSet.py RTCのパス(例えば /localhost/ConfigSample0.rtc)
と言うようにコマンドを入力すれば自動作成してくれます。
あとはこのページのようにファイル作成後にrtc.confに、
カテゴリ名(例えばexample).ConfigSample0.config_file: ./ConfigSample0.conf
を追加すればRTC起動時にコンフィギュレーションパラメータが反映されるようになります。
それからrtc.conf設定用GUIの動的にRTCを起動する、コンフィギュレーションパラメータ設定ファイル自動作成機能を削って、単純にrtc.confを作成するだけのツールを作成しました。ここからダウンロードできます。PyQt4のインストールが必要です。上のツールと合わせて使えば便利かな？とは思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
いやコンフィギュレーションパラメータのファイルとか他にも分かりづらい部分はあるのですが、それはおいておきます。
通常RTCを起動する際に、
実行ファイル名 -f 設定ファイル名
として起動すると思います。
ここで実行ファイル、設定ファイルは以下のパスにあるとします。
実行ファイル C:\RTCD\rtcd.exe
設定ファイル C:\Conf\rtc.conf
そしてrtc.conf内のmanager.modules.load_pathにはDLL等の存在するディレクトリのパスを指定すると思います。今回はDLLと言う名前のフォルダを指定しているとします。
ここでC:\RTCDで、
rtcd -f ../Conf/rtc.conf
と入力します。
この時どこのディレクトリからモジュールをロードするかと言うと、
C:\RTCD\DLL
になります。
色々ツールを作る中でC:\Conf\DLLのようにコンフィギュレーションファイルの存在するディレクトリからの相対パスで指定できないと不都合が多い事が分かってきました。
僕の認識としては、設定ファイル＋コンフィギュレーションパラメータ設定ファイル＋各モジュールがセットで、設定ファイルをrtcdで読み込むことでRTCを起動できると思っていたのですが少し違うのですかね？
例えば、Test1とTest2というフォルダがあるとします。
それぞれのフォルダには、
Test1
-rtc.conf
-bin
--test1_1.dll
--test1_2.dll
-conf
--test1_10.conf
--test1_11.conf
--test1_20.conf
Test2
-rtc.conf
-bin
--test2_1.dll
--test2_2.dll
-conf
--test2_10.conf
--test2_20.conf
のように設定ファイル、dll等が入っているとします。
この状態でrtc.confのmanager.modules.load_pathにrtcdからのconfフォルダへのパスを記述するのは直感的に分かりづらいです。
最大の問題はTest1、Test2のフォルダが別の場所に移動してしまった時で、非常に面倒くさいことになります。解決策としてはrtcd.exeの存在するフォルダにパスを通した後Test1、Test2のフォルダまで移動してrtcd -f rtc.confと入力すれば動作はできますが、それはそれでコマンドが増えるのであまり気が進みません。と言うかできれば今いるディレクトリからは移動せずにRTCを起動したいとは思うのですが、都合良くはできていないようです。
それはさておき、今回のツールはPythonと一部C++で実装します。Javaには対応しない予定です。.NETには対応するかもしれないです。
rtcdでRTCを起動するためにrtc.confの作成が必要ですが、言語ごとに作成する必要があるのが面倒です。
rtc.conf設定用GUIを流用するのでGUIの部分は楽ができそうです。
理想としてはEdisonやRaspberry Pi上で動作するRTCに関しても、GUIは別のPCで操作してシングルボードコンピュータ上にシェルスクリプト、設定ファイルを作成するようにしたいです。
まあEdisonでデスクトップをX Windowを動作させてVNC接続する事もできるとは思うので、そちらでGUIを操作しても良いのですがあまりデスクトップ表示させている人もいないしなあ。
多分、かなりイライラする程度の動作の重さにはなると思うのでやめておきます。
おまけですが、コンフィギュレーションパラメータ設定ファイル作成ツールを作りました。いや別にRTCビルダで作成すれば良いのですが、できればRTシステムエディタで起動したRTCのコンフィギュレーションパラメータを変更して、そのパラメータからファイルを作れたら便利だと思うので簡単に作ってみました。使うにはOpenRTM-aistのPython版、rtctreeが必要です。
使い方としては、
python RTCConfSet.py RTCのパス(例えば /localhost/ConfigSample0.rtc)
と言うようにコマンドを入力すれば自動作成してくれます。
あとはこのページのようにファイル作成後にrtc.confに、
カテゴリ名(例えばexample).ConfigSample0.config_file: ./ConfigSample0.conf
を追加すればRTC起動時にコンフィギュレーションパラメータが反映されるようになります。
それからrtc.conf設定用GUIの動的にRTCを起動する、コンフィギュレーションパラメータ設定ファイル自動作成機能を削って、単純にrtc.confを作成するだけのツールを作成しました。ここからダウンロードできます。PyQt4のインストールが必要です。上のツールと合わせて使えば便利かな？とは思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
いままでRTCの粒度を小さくすることに否定的でしたが、今回は逆の考え方をする事にします。
要は細分化することで発生したデメリットを解消できれば問題はないと言う事です。
今までにRTCを細分化する事に以下のデメリットがあると述べてきました。
さらにrtcdで起動をすればオーバーヘッドも多少は減らせます。
複合コンポーネント化、データポートの接続等を行うスクリプトを自動生成できれば3、4も改善できるのでほぼデメリットはなくなります。
・・・・だが現時点で簡単ではないのが問題です。
僕もrtc.confの編集用GUIや実行順序設定可能な実行コンテキストを作成してきましたが、これらの問題を解消するには至っていません。
現状としてRTC単体で配布するか、あるいはwasanbonを使ってシステムとして配布するかという方法があります。
複合コンポーネントとして配布できれば面白いとは思っているのですがあまりそうしている人は見ないなあ。
とりあえずrtcdでの起動＋複合コンポーネント化＋データポート・サービスポートの接続を自動化するソフトウェアをつくりたいと思います。つまり最終的にはバッチファイルやシェルスクリプトを起動するだけで複合コンポーネントを起動できるようにしたいです。
ただ手順が簡略化できたからと言ってRTCの粒度を小さすぎて良い訳ではありません。オーバーヘッドは軽減されるだけですし、置き換えのできない部分を分割しても意味はありません。
手順としては、
さっそく取り掛かりたいと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
要は細分化することで発生したデメリットを解消できれば問題はないと言う事です。
今までにRTCを細分化する事に以下のデメリットがあると述べてきました。
- オーバーヘッドが増加する
- 他の人がシステムを理解するのが困難になる
- 同期が必要な場合、複合コンポーネント化が面倒
- データポートの接続等、システムを構成する事が面倒になる
さらにrtcdで起動をすればオーバーヘッドも多少は減らせます。
複合コンポーネント化、データポートの接続等を行うスクリプトを自動生成できれば3、4も改善できるのでほぼデメリットはなくなります。
・・・・だが現時点で簡単ではないのが問題です。
僕もrtc.confの編集用GUIや実行順序設定可能な実行コンテキストを作成してきましたが、これらの問題を解消するには至っていません。
現状としてRTC単体で配布するか、あるいはwasanbonを使ってシステムとして配布するかという方法があります。
複合コンポーネントとして配布できれば面白いとは思っているのですがあまりそうしている人は見ないなあ。
とりあえずrtcdでの起動＋複合コンポーネント化＋データポート・サービスポートの接続を自動化するソフトウェアをつくりたいと思います。つまり最終的にはバッチファイルやシェルスクリプトを起動するだけで複合コンポーネントを起動できるようにしたいです。
ただ手順が簡略化できたからと言ってRTCの粒度を小さすぎて良い訳ではありません。オーバーヘッドは軽減されるだけですし、置き換えのできない部分を分割しても意味はありません。
手順としては、
- GUIで起動するRTC等を設定する
- RTシステムエディタでデータポート、サービスポートの接続、コンフィギュレーションパラメータを設定する
- GUIで実行順序を設定する
- 作成ボタンを押せばバッチファイル、設定ファイル等を自動作成する
さっそく取り掛かりたいと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
とりあえずEdisonでRTnoが動作するか確認してみました。
EdisonのArduino基盤とArduinoの5V、GNDをそれぞれ以下のように接続します。
Edison Arduino
5V 5V
GND GND
Tx Rx
Rx Tx
これで通信できる・・・はずなのですが通信できたりできなかったりします。
どうにもmraaのUARTのサンプルプログラム等を1回でも実行すると通信できるようになるらしい。
どっちにしても/dev/ttyMFD1というデバイスファイルの読み書きをするという事には変わらないと思うのですが、一体どういう違いがあるのでしょうね？
色々調べてみるとこのページに答えらしき事が書いてありました。
どうやらCではmraa_uart_init(0);、C++ではmraa::UART u = new mraa::UART(0)、Pythonではu = mraa.Uart(0)を使うだけでmodeが設定されるみたいなのでそうしてください。
あとEdisonのArduino基盤のIO7を使おうとすると無線LANが切断したり、IO10が操作できなかったりするのがよくわかりません。
Intel Edison Kit for Arduino Hardware Guideの日本語訳を読んでいるのですがよく分かりません。
詳しい人がいれば教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
EdisonのArduino基盤とArduinoの5V、GNDをそれぞれ以下のように接続します。
Edison Arduino
5V 5V
GND GND
Tx Rx
Rx Tx
これで通信できる・・・はずなのですが通信できたりできなかったりします。
どうにもmraaのUARTのサンプルプログラム等を1回でも実行すると通信できるようになるらしい。
どっちにしても/dev/ttyMFD1というデバイスファイルの読み書きをするという事には変わらないと思うのですが、一体どういう違いがあるのでしょうね？
色々調べてみるとこのページに答えらしき事が書いてありました。
どうやらCではmraa_uart_init(0);、C++ではmraa::UART u = new mraa::UART(0)、Pythonではu = mraa.Uart(0)を使うだけでmodeが設定されるみたいなのでそうしてください。
あとEdisonのArduino基盤のIO7を使おうとすると無線LANが切断したり、IO10が操作できなかったりするのがよくわかりません。
Intel Edison Kit for Arduino Hardware Guideの日本語訳を読んでいるのですがよく分かりません。
詳しい人がいれば教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
