ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
以前作ったツールですが、どうにも起動するRTCを指定する手順が分かりづらかったように思います。
やはり予めリストで表示しておいて、選択するだけで動的に起動する方が簡単だと思います。
というわけでツールを作っているのですが、リストにするRTCの情報はどうやって取得しましょうね？
wasanbonは実行中のRTCからプロファイルを取得して、さらにXMLファイルから取得した情報とマージするらしいので、ちょっとコードを読んでみます。
twitterでopenrtmと検索すると色々と気になるツイートを見つけました。
まずRTミドルウェア普及貢献賞とは何でしょうね？
一応説明を読んでみたのですが、必要性が今一つ分かりません。
だいたい、「ＲＴミドルウェアを用いたロボットシステムの普及に関し、 産業や教育の現場において顕著な実績を挙げている組織（主に産業分野）あるいは個人（主に教育分野）」なんて存在するのですかね？
普及していないからすぐ下のツイートでROSサイドの人に舐められた発言をされるのではないでしょうか？
まあROSが普及しているかと言われれば、ロボットやっている人の中でも使っている人はごく一部だと思うので、なんであんなに上から目線なのかが謎です。RTMやっている人はさらに少ないのは事実ですけど。
それでもう一つ気になったツイートはそのROSサイドの人のツイートなのですが、何だか根本的に考え方が違うなと思いました。
まず、RTMはOMGに採用された標準規格です。なので「どちらが標準か」という意味では既に決着がついています。
ROSはROSで独自規格でやればいいじゃないですか。
別にそれでもROSの方が使われるのですから、無理に標準規格を取得する必要なんかありません。
後C++はOpenRTMよりROSの方が書きにくくて、PythonはROSよりOpenRTMの方が書きにくいと言われていますが、別にそんな感じはしないけどなあと思いました。
ROSの方が一見するとコード量が少なく見えるのでそう感じるのかな？と思いましたが、C++でも同じなので違うか。
あと「T-Frog」対応のRTコンポーネントと言うのが気になりました。
何が気になったかと言うと、馬鹿高いロボットの値段です。
まあ別にRTC開発した人が悪いわけではないですけど。
これで27万円はぼったくりのように思います。
モータードライバ、ACモーターは内容がよく分からないのでこのぐらいが相場なのかもしれませんが、ケーブル一本1000円はさすがにやりすぎだと思いました。
何だか今日は悪口みたいな事ばかり書いてしまったなあ。
別にそんなつもりはなかったのですが、今度から気を付けます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
やはり予めリストで表示しておいて、選択するだけで動的に起動する方が簡単だと思います。
というわけでツールを作っているのですが、リストにするRTCの情報はどうやって取得しましょうね？
wasanbonは実行中のRTCからプロファイルを取得して、さらにXMLファイルから取得した情報とマージするらしいので、ちょっとコードを読んでみます。
twitterでopenrtmと検索すると色々と気になるツイートを見つけました。
まずRTミドルウェア普及貢献賞とは何でしょうね？
一応説明を読んでみたのですが、必要性が今一つ分かりません。
だいたい、「ＲＴミドルウェアを用いたロボットシステムの普及に関し、 産業や教育の現場において顕著な実績を挙げている組織（主に産業分野）あるいは個人（主に教育分野）」なんて存在するのですかね？
普及していないからすぐ下のツイートでROSサイドの人に舐められた発言をされるのではないでしょうか？
まあROSが普及しているかと言われれば、ロボットやっている人の中でも使っている人はごく一部だと思うので、なんであんなに上から目線なのかが謎です。RTMやっている人はさらに少ないのは事実ですけど。
それでもう一つ気になったツイートはそのROSサイドの人のツイートなのですが、何だか根本的に考え方が違うなと思いました。
まず、RTMはOMGに採用された標準規格です。なので「どちらが標準か」という意味では既に決着がついています。
ROSはROSで独自規格でやればいいじゃないですか。
別にそれでもROSの方が使われるのですから、無理に標準規格を取得する必要なんかありません。
後C++はOpenRTMよりROSの方が書きにくくて、PythonはROSよりOpenRTMの方が書きにくいと言われていますが、別にそんな感じはしないけどなあと思いました。
ROSの方が一見するとコード量が少なく見えるのでそう感じるのかな？と思いましたが、C++でも同じなので違うか。
あと「T-Frog」対応のRTコンポーネントと言うのが気になりました。
何が気になったかと言うと、馬鹿高いロボットの値段です。
まあ別にRTC開発した人が悪いわけではないですけど。
これで27万円はぼったくりのように思います。
モータードライバ、ACモーターは内容がよく分からないのでこのぐらいが相場なのかもしれませんが、ケーブル一本1000円はさすがにやりすぎだと思いました。
何だか今日は悪口みたいな事ばかり書いてしまったなあ。
別にそんなつもりはなかったのですが、今度から気を付けます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
前にも言ったかもしれませんが、ちょっとデータ型が多すぎるのですよね。
BasicDataType.idlで定義されたデータ型だけで27種類、ExtendedDataTypes.idlで定義されたデータ型だけで28種類、InterfaceDataTypes.idlで定義されたデータ型だけで44種類、さらに独自のデータ型も色々と作られているので相当な数存在します。
TimedLong型とTimedULong型という違いでも通信は出来なくなるわけで、データ型が多すぎる事で再利用性を下げているように思います。
似たような意味のデータ型だったら通信できるようにしてくれたら便利だとは思います。
まずOpenRTM-aistではデータポートで通信する際に、CDRという形式に符号化して送信→受信後に復号化するという手順なので、復号化する際に似たデータ型であれば自動的に変換してくれると楽かもしれません。
例えばこんな感じで。
TimedPoint3D型 → TimedPoint2D型 の通信
d_2d.data.x = d_3d.data.x
d_2d.data.y = d_3d.data.y
問題はどうやって変換する手順を定義するかですね。
まあそんな簡単にできるわけないか。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
BasicDataType.idlで定義されたデータ型だけで27種類、ExtendedDataTypes.idlで定義されたデータ型だけで28種類、InterfaceDataTypes.idlで定義されたデータ型だけで44種類、さらに独自のデータ型も色々と作られているので相当な数存在します。
TimedLong型とTimedULong型という違いでも通信は出来なくなるわけで、データ型が多すぎる事で再利用性を下げているように思います。
似たような意味のデータ型だったら通信できるようにしてくれたら便利だとは思います。
まずOpenRTM-aistではデータポートで通信する際に、CDRという形式に符号化して送信→受信後に復号化するという手順なので、復号化する際に似たデータ型であれば自動的に変換してくれると楽かもしれません。
例えばこんな感じで。
TimedPoint3D型 → TimedPoint2D型 の通信
- TimedPoint3D型からCDRに符号化
- 通信
- CDRからTimedPoint3Dに復号化
- 復号化したTimedPoint3D型のデータd_3dをTimedPoint2D型のデータd_2dに変換する
d_2d.data.x = d_3d.data.x
d_2d.data.y = d_3d.data.y
問題はどうやって変換する手順を定義するかですね。
まあそんな簡単にできるわけないか。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
てっきりOpenRTM-aist-1.1.1でCameraImage型はImg.idlのTimedCameraImage型に変更するものと思っていましたがそのままでした。
OpenCVのサンプルもそのままです。
OpenRTM-aist/1.1/rtm/idlフォルダにもImg.idlは入っていません。
ここに1.1.1から正式採用と書いているのですが、一体何があったのでしょうね？
独自データ型を使うのは地味に面倒なので、多分ですがこれから開発されるRTCのほとんどでInterfaceDataTypes.idlのCameraImage型が使われると思います。
言い方は悪いですが、過去に開発されたRTCを切り捨てるのであれば早い方が良いとは思います。
そういえばrtcdで同一プロセスで起動したRTC同士の通信する場合に直接変数に書き込むことができるようになるらしいです。
RTCを細分化しすぎると通信のオーバーヘッドが問題になるわけですが、これで問題はなくなりそうですね。rtcdや複合コンポーネントがもう少し使いやすくなればですけど。
今の所rtcdでRTCを起動するように設定ファイルを書くのは簡単ではないわけで、rtcdで起動したRTC同士の通信が高速化してもあまりありがたみは感じないかもしれません。
その作業を簡単にするツールは作ったのですが、本当に簡単になっているかどうかも怪しいです。
あまり書くこともなかったので作成したRTシステムを他の環境で実行してもらう際の注意点を書きたいと思います。
僕がほかの人のRTシステムを試してみようと思った時ですが、こういう事がありました。
ビルドができない
→ビルドはできるようになったものの、10個以上のRTCをビルドするのは面倒なので諦める
→→実行ファイルが付属したもののDLLが足りず実行できず、あと何故かデバッグビルドしていた
未だに僕の環境では動作できてません。
なんだか何回か悪い例として紹介してるなあ。
そもそも必要なDLLを付属させないにも関わらず実行ファイルを付属させるのが間違いで、OpenRTM-aistのバージョン、対応するVSのバージョン、32bitか64bitかで何種類も違う環境が存在するので動作できないと思った方が良いです。
ライセンスを気にするのであればこちらでビルドするようにすれば良いのですが、複数のRTCをまとめてビルドするようなスクリプトでも作らない限り使ってはもらえません。
あと、他の人の開発したRTシステムでさらに別の人のRTCを使っているものがあったわけですが、これも動作できませんでした。
何が問題かと言うと自作のRTCはOpenRTM-aist-1.1.0でビルドしていて、別の人の作成したRTCはOpenRTM-aist-1.0.0でビルドしていたので、わざわざ1.0.0のdllを入手してくる必要があったみたいです。さすがに面倒くさいので動作させるのは諦めました。当時はOpenRTM-aist-1.1.0をインストールしていたので、こちらのdllは問題になりませんでした。
マニュアルに一言OpenRTM-aist-1.0.0のdllが必要だと書いてくれたら良かったのに、別の人のRTCのマニュアルに丸投げしていたのが不味かったと思います。
2つのバージョンのOpenRTM-aistのインストールが必要なんて普通は考えません。
それに2つ以上のOpenRTM-aistをインストールするとCMakeでプロジェクトを生成する時に問題が出てくるみたいだからなあ。
あの不具合はRTM_ROOTで指定されたOpenRTM-aistのバージョンとOMNI_ROOTで指定されたOpenRTM-aistのバージョンが違うせいだと思っていたのですが、ひょっとしたらRTM_ROOTで指定されたOpenRTM-aistと違うバージョンからOpenRTMConfig.cmakeが検索されるせいだったかもしれないです。面倒くさいので検証はしませんけど。
そもそも公式サイトに異なるバージョンのOpenRTM-aistのインストールは非推奨と書いてあるので、ユーザーに異なるバージョンのOpenRTM-aistをインストールを強いる時点でかなりの失態を犯していると言っても過言ではないです。
インストーラーから抽出して使えとでも言っているのでしょうか？
まあ元はと言えばその別の人が作成したRTCが実行ファイルのみの付属、さらにはソースコードを付属していないのが原因ではあるのですけど、ライセンスの問題もあったのかもしれないです。
どっかからdllだけ入手できればそれでも良かったのだけどなあ。
OpenCVのサンプルもそのままです。
OpenRTM-aist/1.1/rtm/idlフォルダにもImg.idlは入っていません。
ここに1.1.1から正式採用と書いているのですが、一体何があったのでしょうね？
独自データ型を使うのは地味に面倒なので、多分ですがこれから開発されるRTCのほとんどでInterfaceDataTypes.idlのCameraImage型が使われると思います。
言い方は悪いですが、過去に開発されたRTCを切り捨てるのであれば早い方が良いとは思います。
そういえばrtcdで同一プロセスで起動したRTC同士の通信する場合に直接変数に書き込むことができるようになるらしいです。
RTCを細分化しすぎると通信のオーバーヘッドが問題になるわけですが、これで問題はなくなりそうですね。rtcdや複合コンポーネントがもう少し使いやすくなればですけど。
今の所rtcdでRTCを起動するように設定ファイルを書くのは簡単ではないわけで、rtcdで起動したRTC同士の通信が高速化してもあまりありがたみは感じないかもしれません。
その作業を簡単にするツールは作ったのですが、本当に簡単になっているかどうかも怪しいです。
あまり書くこともなかったので作成したRTシステムを他の環境で実行してもらう際の注意点を書きたいと思います。
僕がほかの人のRTシステムを試してみようと思った時ですが、こういう事がありました。
ビルドができない
→ビルドはできるようになったものの、10個以上のRTCをビルドするのは面倒なので諦める
→→実行ファイルが付属したもののDLLが足りず実行できず、あと何故かデバッグビルドしていた
未だに僕の環境では動作できてません。
なんだか何回か悪い例として紹介してるなあ。
そもそも必要なDLLを付属させないにも関わらず実行ファイルを付属させるのが間違いで、OpenRTM-aistのバージョン、対応するVSのバージョン、32bitか64bitかで何種類も違う環境が存在するので動作できないと思った方が良いです。
ライセンスを気にするのであればこちらでビルドするようにすれば良いのですが、複数のRTCをまとめてビルドするようなスクリプトでも作らない限り使ってはもらえません。
あと、他の人の開発したRTシステムでさらに別の人のRTCを使っているものがあったわけですが、これも動作できませんでした。
何が問題かと言うと自作のRTCはOpenRTM-aist-1.1.0でビルドしていて、別の人の作成したRTCはOpenRTM-aist-1.0.0でビルドしていたので、わざわざ1.0.0のdllを入手してくる必要があったみたいです。さすがに面倒くさいので動作させるのは諦めました。当時はOpenRTM-aist-1.1.0をインストールしていたので、こちらのdllは問題になりませんでした。
マニュアルに一言OpenRTM-aist-1.0.0のdllが必要だと書いてくれたら良かったのに、別の人のRTCのマニュアルに丸投げしていたのが不味かったと思います。
2つのバージョンのOpenRTM-aistのインストールが必要なんて普通は考えません。
それに2つ以上のOpenRTM-aistをインストールするとCMakeでプロジェクトを生成する時に問題が出てくるみたいだからなあ。
あの不具合はRTM_ROOTで指定されたOpenRTM-aistのバージョンとOMNI_ROOTで指定されたOpenRTM-aistのバージョンが違うせいだと思っていたのですが、ひょっとしたらRTM_ROOTで指定されたOpenRTM-aistと違うバージョンからOpenRTMConfig.cmakeが検索されるせいだったかもしれないです。面倒くさいので検証はしませんけど。
そもそも公式サイトに異なるバージョンのOpenRTM-aistのインストールは非推奨と書いてあるので、ユーザーに異なるバージョンのOpenRTM-aistをインストールを強いる時点でかなりの失態を犯していると言っても過言ではないです。
インストーラーから抽出して使えとでも言っているのでしょうか？
まあ元はと言えばその別の人が作成したRTCが実行ファイルのみの付属、さらにはソースコードを付属していないのが原因ではあるのですけど、ライセンスの問題もあったのかもしれないです。
どっかからdllだけ入手できればそれでも良かったのだけどなあ。
Python 2.7.10が5月23日にリリースされていたらしいですね。
それはさておきツールを色々改良しています。
極力、RTC起動からシステムを復元するまでの手間を減らそうと思ったのでネームサーバーも同時に起動するようにしました。
インストールしなければならないソフトウェアが多いのも問題なのでインストールを簡単化するソフトウェアを作成しました。
まあ作っただけで配布はしないのですけど。
後、ツールで作成したスクリプトファイルはrtshellのコマンドを書いているので、C:\Python27やC:\Python27\Scriptsとかにパスが通っていないと動作できません。
動作できない人は以下のコマンドを実行してください。
どこかへインストールしたモジュールを読み込む、もしくはプロジェクトに同梱したモジュールを読み込んでRTCを起動するようにしてほしいのですが、前々から言っている通りインストールされる場所が問題です。
インストールしたモジュールを使う場合、別の環境ではインストールされているディレクトリが違うという場合もあると思います。
基本的には、
%RTM_ROOT%/components
とかから読み込めればよいのですがrtc.confのmanager.modules.load_pathに環境変数を書いたとして読み込んでくれるのでしょうか？
何らかの書き方があるのかもしれないですが、分からないので詳しい人は教えてください。
いつぞやかの記事でRTCをビルド済みバイナリで配布する際、ヘッダーファイルを読み込んでいるのでライセンス的にまずいとか言いましたが、RTCだけの配布ならばライセンスは自由に決めてよかったみたいです。
LGPLでヘッダーファイルを読み込んだビルド済み配布物のライセンスがどうなるかですが、ここを読む限り明確な判定基準がないみたいですね。ただ、OpenRTM-aistに関してはセーフみたいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それはさておきツールを色々改良しています。
極力、RTC起動からシステムを復元するまでの手間を減らそうと思ったのでネームサーバーも同時に起動するようにしました。
インストールしなければならないソフトウェアが多いのも問題なのでインストールを簡単化するソフトウェアを作成しました。
まあ作っただけで配布はしないのですけど。
後、ツールで作成したスクリプトファイルはrtshellのコマンドを書いているので、C:\Python27やC:\Python27\Scriptsとかにパスが通っていないと動作できません。
動作できない人は以下のコマンドを実行してください。
set pythonPATH=C:\Python27
set scriptPATH=%pythonPATH%\Scripts
setx /M PATH "%PATH%;%pythonPATH%;%scriptPATH%;"
どこかへインストールしたモジュールを読み込む、もしくはプロジェクトに同梱したモジュールを読み込んでRTCを起動するようにしてほしいのですが、前々から言っている通りインストールされる場所が問題です。
インストールしたモジュールを使う場合、別の環境ではインストールされているディレクトリが違うという場合もあると思います。
基本的には、
%RTM_ROOT%/components
とかから読み込めればよいのですがrtc.confのmanager.modules.load_pathに環境変数を書いたとして読み込んでくれるのでしょうか？
何らかの書き方があるのかもしれないですが、分からないので詳しい人は教えてください。
いつぞやかの記事でRTCをビルド済みバイナリで配布する際、ヘッダーファイルを読み込んでいるのでライセンス的にまずいとか言いましたが、RTCだけの配布ならばライセンスは自由に決めてよかったみたいです。
LGPLでヘッダーファイルを読み込んだビルド済み配布物のライセンスがどうなるかですが、ここを読む限り明確な判定基準がないみたいですね。ただ、OpenRTM-aistに関してはセーフみたいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
Intel EdisonにOpenRTM-aist-1.1.1-Releaseをインストールしようとしたのですが、少し引っかかる部分がありました。
DoxygenをインストールせずにconfigureでMakefileを生成しようとするとエラーが出ます。
それで--without-documentというオプションを付けなさいと言われるので付けてみたのですがエラーが消えません。
変だと思ってヘルプを見てみると--without-doxygenとなっていました。
何だか地味なミスだなあ。
複合コンポーネント作成支援ツール、ビルド自動化ツールのマニュアルを作成しました。
ここで読むことができます。まだ不十分なので今後追記はすると思います。
PyQtがインストールされていない場合もあると思うのでpy2exeで実行ファイルも作成しました。
これで多少は使いやすくなったかもしれないです。
以前作成したロボットアームのGUIを更新しようと思ったのですが、Ogre3DがVisual Studio 2012までしか対応していないのでOgre3Dが更新されるまで待つことにしました。
まあこちらでビルドすることもできるのでしょうけど、面倒くさいですからね。
VC++2010でビルドするのもOpenRTM-aistをVC++2010対応版をインストールしなければならないのでやりたくないです。
こちらでPython2.6のライブラリを使ってビルドしたので、Python2.6にOpenRTM-aistをインストールしておく必要があります。
OpenRTM-aist-PythonがPython2.7にも対応したのでこちらもバージョンアップしたいのですが、Ogre3Dが更新されるまでは保留にしておきます。
一応CMakeLists.txtを作成しておいたので、そちらでビルドできる人はそうしてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
DoxygenをインストールせずにconfigureでMakefileを生成しようとするとエラーが出ます。
それで--without-documentというオプションを付けなさいと言われるので付けてみたのですがエラーが消えません。
変だと思ってヘルプを見てみると--without-doxygenとなっていました。
何だか地味なミスだなあ。
複合コンポーネント作成支援ツール、ビルド自動化ツールのマニュアルを作成しました。
ここで読むことができます。まだ不十分なので今後追記はすると思います。
PyQtがインストールされていない場合もあると思うのでpy2exeで実行ファイルも作成しました。
これで多少は使いやすくなったかもしれないです。
以前作成したロボットアームのGUIを更新しようと思ったのですが、Ogre3DがVisual Studio 2012までしか対応していないのでOgre3Dが更新されるまで待つことにしました。
まあこちらでビルドすることもできるのでしょうけど、面倒くさいですからね。
VC++2010でビルドするのもOpenRTM-aistをVC++2010対応版をインストールしなければならないのでやりたくないです。
こちらでPython2.6のライブラリを使ってビルドしたので、Python2.6にOpenRTM-aistをインストールしておく必要があります。
OpenRTM-aist-PythonがPython2.7にも対応したのでこちらもバージョンアップしたいのですが、Ogre3Dが更新されるまでは保留にしておきます。
一応CMakeLists.txtを作成しておいたので、そちらでビルドできる人はそうしてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
