扱いがわからない

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、実行順序設定可能な実行コンテキストも更新する予定です。











にほんブログ村のロボットのカテゴリから
全然人が来ない・・・