マネージャの機能を利用したツール

以前作ったツールですが、どうにも起動する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円はさすがにやりすぎだと思いました。





何だか今日は悪口みたいな事ばかり書いてしまったなあ。
別にそんなつもりはなかったのですが、今度から気を付けます。






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

7500円のロボットアーム

サインスマート製のロボットアームって7500円のものもあったみたいですね。
説明文のサバーってなんぞやって思いましたが、多分サーボの間違いでしょうか？

サインスマートなので説明書はついてこないでしょうし、マイコン等は自分で用意する必要はあると思うので、値段が安いからと言っても初心者には手を出しづらいと思います。
15000円とかならまだしも、7500円というとこのホビー用ロボットアームと値段が変わらないわけで、知識のない人が購入して全く動かし方が分からないなんていう事故が起こりそうです。


まずサインスマート製のロボットアームは6自由度、4自由度、2自由度＋グリッパーの製品があるわけですが、この製品単体では動かすことはできません。
何らかの方法でRCサーボにPWMを入力できるようにしなければなりません。
どうやらArduinoの使用を推奨しているようなので、持っていない人は購入してください。



一応このサイトに仕様らしきものは載っていますが、制御用のプログラムはどこにもないようですね。

まあでもArduinoでRCサーボを制御する方法を説明しているサイトなんてたくさんあるのでなんとかなるとは思います。



あと6自由度のロボットアームが少し値下げしたように見えるのですが、どうだったでしょうかね？
確か以前は25000円ぐらいだったような気がしますが、定かではありません。
それにしてもレビューを書いている人がいますが、なんだか独特の表現と言うか面白い事を書くなあと思いました。






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

違うデータ型でも接続してほしい

前にも言ったかもしれませんが、ちょっとデータ型が多すぎるのですよね。
BasicDataType.idlで定義されたデータ型だけで27種類、ExtendedDataTypes.idlで定義されたデータ型だけで28種類、InterfaceDataTypes.idlで定義されたデータ型だけで44種類、さらに独自のデータ型も色々と作られているので相当な数存在します。
TimedLong型とTimedULong型という違いでも通信は出来なくなるわけで、データ型が多すぎる事で再利用性を下げているように思います。

似たような意味のデータ型だったら通信できるようにしてくれたら便利だとは思います。
まずOpenRTM-aistではデータポートで通信する際に、CDRという形式に符号化して送信→受信後に復号化するという手順なので、復号化する際に似たデータ型であれば自動的に変換してくれると楽かもしれません。

例えばこんな感じで。

TimedPoint3D型　→　TimedPoint2D型　の通信

1. TimedPoint3D型からCDRに符号化
2. 通信
3. CDRからTimedPoint3Dに復号化
4. 復号化したTimedPoint3D型のデータd_3dをTimedPoint2D型のデータd_2dに変換する

d_2d.tm = d_3d.tm
d_2d.data.x = d_3d.data.x
d_2d.data.y = d_3d.data.y



問題はどうやって変換する手順を定義するかですね。
まあそんな簡単にできるわけないか。









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

CameraImage型について

てっきり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だけ入手できればそれでも良かったのだけどなあ。

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

雑談

Python 2.7.10が5月23日にリリースされていたらしいですね。


それはさておきツールを色々改良しています。

極力、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に関してはセーフみたいです。







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