ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
SysML-RTMを使ってみたのでその感想を書きます。
とりあえずこのページのチュートリアルを3つやってみました。
どうにもこのツールに関して僕は誤解をしていたらしく、RTCのテンプレートまで生成してくれると思っていたのですがRTC プロファイルまでの生成みたいです。
RTCBuilderでの読み込み、生成が地味に面倒ですね。
一見しただけでは使い方が覚えられないと言うか、僕みたいな初心者には難しい印象です。コンポーネント名でシステム復元のエラーが出るとか、サービスポートを使用する際にIDLパスの設定が必要となるあたり、どうにもこのツールとRTCBuilder・RTSystemEditorとの連携が今一つな感じがします。
何だか文句みたいな事ばっかり言ってしまいましたが、かなり便利なツールだと思います。
ただ現時点では初心者には敷居が高いかな？とは思います。
少なくとも僕は使いこなすにはそれなりに時間がかかりそうです。
前も似たような事を言ったとは思いますが、ブロック定義図等で作成したブロックを何でもかんでもRTCに割り当てるのは僕は間違いだと思います。RTCの粒度を小さくしすぎるかもしれないです。設計図はよく出来ているのに完成したものがヘンテコだったりすると、見ていて悲しくなります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
とりあえずこのページのチュートリアルを3つやってみました。
どうにもこのツールに関して僕は誤解をしていたらしく、RTCのテンプレートまで生成してくれると思っていたのですがRTC プロファイルまでの生成みたいです。
RTCBuilderでの読み込み、生成が地味に面倒ですね。
一見しただけでは使い方が覚えられないと言うか、僕みたいな初心者には難しい印象です。コンポーネント名でシステム復元のエラーが出るとか、サービスポートを使用する際にIDLパスの設定が必要となるあたり、どうにもこのツールとRTCBuilder・RTSystemEditorとの連携が今一つな感じがします。
何だか文句みたいな事ばっかり言ってしまいましたが、かなり便利なツールだと思います。
ただ現時点では初心者には敷居が高いかな？とは思います。
少なくとも僕は使いこなすにはそれなりに時間がかかりそうです。
前も似たような事を言ったとは思いますが、ブロック定義図等で作成したブロックを何でもかんでもRTCに割り当てるのは僕は間違いだと思います。RTCの粒度を小さくしすぎるかもしれないです。設計図はよく出来ているのに完成したものがヘンテコだったりすると、見ていて悲しくなります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
とりあえず昨日はPython版でCDRによる変換処理のどの程度時間がかかるか計測しましたが、今回はC++版で計測します。
まずは500KBのデータを通信したときの結果です。
遅延時間(同一プロセス)：1.569[ms]
遅延時間(別プロセス)：9.08[ms]
符号化：0.493[ms]
復号化：0.298[ms]
次に50KBのデータを通信したときの結果です。
遅延時間(同一プロセス)：0.174[ms]
遅延時間(別プロセス)：1.281[ms]
符号化：0.0266[ms]
復号化：0.0375[ms]
やはり何か結果がおかしいように思います。
と言うか500KB・別プロセスの時にPythonより通信が遅くなっているので間違っている可能性大ですね。
他の人が通信の遅延時間を計測した結果を見てみますと、このサイトの人は1MBで6msとかなので僕の実験の500KBの通信より速いです。こちらのページの人の実験結果を見てみると上の人と似たような結果なので多分僕が間違っています。ひょっとしたらPCの性能の問題かもしれませんが、他のPCで動作確認するのも面倒なので誰か検証してください。とりあえず他の人が作った計測用のRTCで別プロセス・500KBの通信遅延時間を計測した所9msかかることが分かりました。糞みたいなPCですみません。
苦しいですけど僕の実験結果が正しいと仮定すると、同一プロセス・500KBの時は符号化・復号化が遅延時間の59％、50KBの時は36％なのでデータサイズが大きくなればなるほどCDRでの変換の比重が大きくはなると思ったのですが、1MBで実験してみると35％まで下がっていました。ちなみに400KBだと60％、600KBだと39％、10MBだと47％でした。一体500KBを境にして何があったのでしょうね？
同一プロセス内通信だと前から言っているように関数呼び出しでデータを受け渡すはずなので、データサイズが大きくなって影響を大きく受けるのはCDRでの変換だと思ったのですが違ったかもしれないです。
とりあえず遅延時間とデータサイズの関係を調べてみたところ変なグラフになりました。
つまりどういう事ですかね？
見間違いでなければ500KB付近でいきなり遅延時間が増えているように見えるのですが。
さっき見たサイトで共有メモリでの通信と比較している結果がありましたが、512×512ではあまり差はないにもかかわらず1024×1024ではいきなり倍以上の差になっているのは同一プロセス内通信でCDRの変換の比重が大きくなるせいだと思ったのですが、何だか違うような雰囲気になってきました。
CORBA以外でのデータ転送を実装する場合に役立つかと思ったのですが、どうにも実験結果の信憑性が疑わしいので見直す必要があるようです。誰か実験した人がいれば教えてください。
ここからはCMakeの話です。
自分でCMake、ビルドする仕様で配布する場合、
何だか凄く今更ですね。
僕はCMakeを使いこなせておらずプロジェクト作成後にプロパティを変更することも多いので、CMakeする仕様自体があまり好きではありません。と言うかRTCの作成にCMakeを使うようになってから明らかに手間が増えた感じはあります。最近気づいたのですが、CMakeのGUIでプロジェクトファイルを作るよりも上記のようにコマンドからやった方が速いように感じます。Ubuntuで開発しているとCMakeがやたら速いのでおかしいとは思っていたのですが、ひょっとしてGUIでやると遅いのでしょうか？詳しい人がいれば教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まずは500KBのデータを通信したときの結果です。
遅延時間(同一プロセス)：1.569[ms]
遅延時間(別プロセス)：9.08[ms]
符号化：0.493[ms]
復号化：0.298[ms]
次に50KBのデータを通信したときの結果です。
遅延時間(同一プロセス)：0.174[ms]
遅延時間(別プロセス)：1.281[ms]
符号化：0.0266[ms]
復号化：0.0375[ms]
やはり何か結果がおかしいように思います。
と言うか500KB・別プロセスの時にPythonより通信が遅くなっているので間違っている可能性大ですね。
他の人が通信の遅延時間を計測した結果を見てみますと、このサイトの人は1MBで6msとかなので僕の実験の500KBの通信より速いです。こちらのページの人の実験結果を見てみると上の人と似たような結果なので多分僕が間違っています。ひょっとしたらPCの性能の問題かもしれませんが、他のPCで動作確認するのも面倒なので誰か検証してください。とりあえず他の人が作った計測用のRTCで別プロセス・500KBの通信遅延時間を計測した所9msかかることが分かりました。糞みたいなPCですみません。
苦しいですけど僕の実験結果が正しいと仮定すると、同一プロセス・500KBの時は符号化・復号化が遅延時間の59％、50KBの時は36％なのでデータサイズが大きくなればなるほどCDRでの変換の比重が大きくはなると思ったのですが、1MBで実験してみると35％まで下がっていました。ちなみに400KBだと60％、600KBだと39％、10MBだと47％でした。一体500KBを境にして何があったのでしょうね？
同一プロセス内通信だと前から言っているように関数呼び出しでデータを受け渡すはずなので、データサイズが大きくなって影響を大きく受けるのはCDRでの変換だと思ったのですが違ったかもしれないです。
とりあえず遅延時間とデータサイズの関係を調べてみたところ変なグラフになりました。
つまりどういう事ですかね？
見間違いでなければ500KB付近でいきなり遅延時間が増えているように見えるのですが。
さっき見たサイトで共有メモリでの通信と比較している結果がありましたが、512×512ではあまり差はないにもかかわらず1024×1024ではいきなり倍以上の差になっているのは同一プロセス内通信でCDRの変換の比重が大きくなるせいだと思ったのですが、何だか違うような雰囲気になってきました。
CORBA以外でのデータ転送を実装する場合に役立つかと思ったのですが、どうにも実験結果の信憑性が疑わしいので見直す必要があるようです。誰か実験した人がいれば教えてください。
ここからはCMakeの話です。
自分でCMake、ビルドする仕様で配布する場合、
"C:\Program Files\CMake\bin\cmake" .\
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild Test.sln /p:Configuration=Release
という内容のバッチファイルを付けてくれればビルドが簡単なのでそうしてください。何だか凄く今更ですね。
僕はCMakeを使いこなせておらずプロジェクト作成後にプロパティを変更することも多いので、CMakeする仕様自体があまり好きではありません。と言うかRTCの作成にCMakeを使うようになってから明らかに手間が増えた感じはあります。最近気づいたのですが、CMakeのGUIでプロジェクトファイルを作るよりも上記のようにコマンドからやった方が速いように感じます。Ubuntuで開発しているとCMakeがやたら速いのでおかしいとは思っていたのですが、ひょっとしてGUIでやると遅いのでしょうか？詳しい人がいれば教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
また更新してしまいました。
前から書こうと思っていたのですが忘れていたのでCDR(Common Data Representation)での変換にどの程度の時間がかかるのかを実験しておきたいと思います。CDRについては他に説明しているサイトがあるようなので説明は省略します。OpenRTM-aistのデータポートによる通信ではデータをバイト列に変換して通信するわけですが、その表現方法にCORBAのCDRと言う形式を使っています。
さてOpenRTM-aist-PythonのどこでCDRによる符号化、復号化をしているかというと、ソースコードを読んだ限りではOutPortConnector.pyのcdr_data = cdrMarshal(any.to_any(data).typecode(), data, self._endian)で符号化、InPortPushConnector.pyの_data = cdrUnmarshal(any.to_any(self._dataType).typecode(),data,self._endian)で復号化しているみたいに見えます。
とりあえずOutPortConnector.py、InPortPushConnector.pyに時間を計測するコードを書いて、適当に通信してみました。
とりあえず500KBのデータを通信した結果です。データの遅延時間はwrite関数の直前からデータを受け取った時のコネクタコールバックが呼び出されるまでの時間を計測しています。
遅延時間(同一プロセス)：1.713[ms]
遅延時間(別プロセス)：7.287[ms]
符号化：0.608[ms]
復号化：0.302[ms]
ちなみに500回実験した結果の平均値です。
なんだか同一プロセスの通信が速いのか、別プロセスの通信が遅いのかは知りませんが結果が違うような気がします。確かC++版で計測したときには2倍ぐらいの差しか無かったような気がしますが、Python版だとこうなるのですかね？入念にソースコードを調べたのですが特に間違っている所はなさそうなので、多分あっているとは思います。誰か検証してください。
それはさておきCDRの符号化、複合化ですが、同一プロセスでの通信では53％を締めているみたいですね・・・・本当だろうか？やっぱり結果が怪しいように思います。
何だか怪しいので50KBでも実験してみました。
遅延時間(同一プロセス)：0.599[ms]
遅延時間(別プロセス)：1.523[ms]
符号化：0.0992[ms]
復号化：0.0448[ms]
比率が24％まで下がりました。やはり怪しいので誰か検証してください。
よくわからないのでデータサイズと比率の関係を調べてみました。
各データサイズで何百回も試行した平均を出すのは面倒なので1回しか計測していません。
こうして見るとデータサイズが大きくなるほど符号化、復号化の比率が大きくなっているように見えます。
どうやらC++版だとOutPortConnector.hのdata >>= m_cdr;の部分が符号化、ConnectorListener.hのdata <<= cdr;が復号化のように見えます。誰か試せる人は試してください。
というか何でこんな事を調べていたかと言うと、何か別の方式の通信を実装してみたいと思ったからです。共有メモリとかで通信するにしても、一旦CDRで符号化して送信先で復号化すれば色々なデータ型が通信できると思います。まあ別に共有メモリが使いたいわけではないですが。なんでもHRTMというRTM実装では同一プロセス内通信の場合、アドレス参照でデータをコピーするとからしいのですね。論文読んだ限りでは従来の方法ではデータ変換処理が通信の大部分を占めているような事を書いてあるので、他の方法で通信するにしてもCDRでの変換を組み込むかどうかは考えた方が良いかもしれないです。
たしかこのソフトウェアは独自のデータ型でもデータの記録、再生ができるらしいですが、CDRで保存しているかららしいです。上手い使い方するなあ(小並感)
そういえば、この本ってどんな内容なのでしょうね？
レビューが酷いので購入したくはないのですが、酷いだけに内容が気になります。
別にRTMの本ならばはじめてのコンポーネント指向ロボットアプリケーション開発を読めば良いと思いますけどね。ただ、ちょっと内容が古くなりつつあるのが問題かもしれないです。
UMLとRTミドルウェアによるモデルベースロボットシステム開発はちょっとUML関連の内容が多すぎてRTM関連の内容が薄いような印象です。この本もamazonのレビューが酷いな。確かにRTMの本だと思って読んでみたらUMLの事ばっかり書いててガッカリしたのですが、最初からUMLの本だと思って読めば悪い本ではないはずです。
というかRTM関連の本って何年も出てないので、そろそろ誰か書いてください。もしかして、RTM本出しても全然売れないから出ないとか・・いやあまり考えないでおこう。少なくとも僕は買うのでお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
前から書こうと思っていたのですが忘れていたのでCDR(Common Data Representation)での変換にどの程度の時間がかかるのかを実験しておきたいと思います。CDRについては他に説明しているサイトがあるようなので説明は省略します。OpenRTM-aistのデータポートによる通信ではデータをバイト列に変換して通信するわけですが、その表現方法にCORBAのCDRと言う形式を使っています。
さてOpenRTM-aist-PythonのどこでCDRによる符号化、復号化をしているかというと、ソースコードを読んだ限りではOutPortConnector.pyのcdr_data = cdrMarshal(any.to_any(data).typecode(), data, self._endian)で符号化、InPortPushConnector.pyの_data = cdrUnmarshal(any.to_any(self._dataType).typecode(),data,self._endian)で復号化しているみたいに見えます。
とりあえずOutPortConnector.py、InPortPushConnector.pyに時間を計測するコードを書いて、適当に通信してみました。
とりあえず500KBのデータを通信した結果です。データの遅延時間はwrite関数の直前からデータを受け取った時のコネクタコールバックが呼び出されるまでの時間を計測しています。
遅延時間(同一プロセス)：1.713[ms]
遅延時間(別プロセス)：7.287[ms]
符号化：0.608[ms]
復号化：0.302[ms]
ちなみに500回実験した結果の平均値です。
なんだか同一プロセスの通信が速いのか、別プロセスの通信が遅いのかは知りませんが結果が違うような気がします。確かC++版で計測したときには2倍ぐらいの差しか無かったような気がしますが、Python版だとこうなるのですかね？入念にソースコードを調べたのですが特に間違っている所はなさそうなので、多分あっているとは思います。誰か検証してください。
それはさておきCDRの符号化、複合化ですが、同一プロセスでの通信では53％を締めているみたいですね・・・・本当だろうか？やっぱり結果が怪しいように思います。
何だか怪しいので50KBでも実験してみました。
遅延時間(同一プロセス)：0.599[ms]
遅延時間(別プロセス)：1.523[ms]
符号化：0.0992[ms]
復号化：0.0448[ms]
比率が24％まで下がりました。やはり怪しいので誰か検証してください。
よくわからないのでデータサイズと比率の関係を調べてみました。
各データサイズで何百回も試行した平均を出すのは面倒なので1回しか計測していません。
こうして見るとデータサイズが大きくなるほど符号化、復号化の比率が大きくなっているように見えます。
どうやらC++版だとOutPortConnector.hのdata >>= m_cdr;の部分が符号化、ConnectorListener.hのdata <<= cdr;が復号化のように見えます。誰か試せる人は試してください。
というか何でこんな事を調べていたかと言うと、何か別の方式の通信を実装してみたいと思ったからです。共有メモリとかで通信するにしても、一旦CDRで符号化して送信先で復号化すれば色々なデータ型が通信できると思います。まあ別に共有メモリが使いたいわけではないですが。なんでもHRTMというRTM実装では同一プロセス内通信の場合、アドレス参照でデータをコピーするとからしいのですね。論文読んだ限りでは従来の方法ではデータ変換処理が通信の大部分を占めているような事を書いてあるので、他の方法で通信するにしてもCDRでの変換を組み込むかどうかは考えた方が良いかもしれないです。
たしかこのソフトウェアは独自のデータ型でもデータの記録、再生ができるらしいですが、CDRで保存しているかららしいです。上手い使い方するなあ(小並感)
そういえば、この本ってどんな内容なのでしょうね？
レビューが酷いので購入したくはないのですが、酷いだけに内容が気になります。
別にRTMの本ならばはじめてのコンポーネント指向ロボットアプリケーション開発を読めば良いと思いますけどね。ただ、ちょっと内容が古くなりつつあるのが問題かもしれないです。
UMLとRTミドルウェアによるモデルベースロボットシステム開発はちょっとUML関連の内容が多すぎてRTM関連の内容が薄いような印象です。この本もamazonのレビューが酷いな。確かにRTMの本だと思って読んでみたらUMLの事ばっかり書いててガッカリしたのですが、最初からUMLの本だと思って読めば悪い本ではないはずです。
というかRTM関連の本って何年も出てないので、そろそろ誰か書いてください。もしかして、RTM本出しても全然売れないから出ないとか・・いやあまり考えないでおこう。少なくとも僕は買うのでお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
別に再開するわけではないですが、ちょっと考えに変化があったので書いておきます。
「独自データ型は使わないようにしている」と以前言いましたが、極力使わないぐらいな考えに変わりました。
どういう場合に使うかと言うと、例えば(x1,y1,x2,y2・・・・xn,yn)と言うようなデータを送信する場合、TimedDoubleSeqで通信するよりも、
システムとなると少し難しいような先入観があります。
「OpenRTM-aistを使ったからこういうシステムができました」というアイデアがないからです。
RTCやツールであれば現状のRTM関連のソフトウェアに足らない部分を考えれば良いので簡単なのですが、システムが対象となるとシステムを構築する事が目的になるので、単純にシステムを作るだけではなく、RTMを使うメリットが必要です。
RTCやツールを作る事を目的にする人はあまりいないと思うので、その点が違うのではないかと思います。
例えば、「似た機能のライブラリなりを使えば、同じような労力で同じシステムは構成できる」と言うのであれば特に意味はないと思います。
工程を削減できたとかでも良いので何か利点が無ければならないのですが、そもそも人のRTCを使うのが今の所簡単ではないのでむしろ時間が増える事の方が多いのが現状のような感じがしています。
何と言うか、OpenRTM-aistのC++版に32bit版と64bit版があることと、あと複数のOSに対応している事が逆効果になっているように思います。使いたいRTCがあっても自分の環境で動作できません。ロボットやっている人は大抵WindowsとLinux両方使えると思うので、それが余計にまずいのかもしれないです。
あと、OpenRTM-aistの1.0.0で開発したRTCは当然のことながら1.0.0のdllが無ければ動作できません。ただほとんどのRTCはdllを付属していないので、そのまま使われないように思います。
何と言うか、通常はExeファイルを実行(もしくはマネージャでモジュールをロード)→ネームサービスビューからRTCを選択してエディタ上に並べるというのが通常の手順だとは思いますが、もっと簡単にならないかなとは思っています。なにか有用なツールはないものですかね？
話がだいぶそれてしまいましたが、システムについては特に何もアイデアがありません。
今考えていてアイデアが浮かばない理由がもう一つある事がわかりました。
どうにも自分が使う分には良いのですが、人に使ってもらえるようにするのが難しいのではないかと思いました。そもそもシステムを構成するとなると色々な機器を使うことも多いので、それを人の環境で動作できるようにするのは難しいような感じです。単一のRTCであれば使用する機器も単一だと思うのでそこまで問題にならないのですが、複数の機器が必要となると他の環境で動作できる可能性は著しく下がると思います。実の所それで評価が下がる事はあまりないように思うのですが、僕は最低でも審査員の人の環境で動作できていないと不服なので避けたいと思っています。
完全に個人的な意見ですが、あるシステムを構築するためのRTC群を配布している作品もありますけど、何と言うか最終的に目的のシステムが構築できていれば良いのではなくて、もっとそれぞれのRTCの再利用性を考えてほしいなとは思いました。そのシステムでしか使えないようなRTCならば無駄に分割する必要もないと思います。
システム作るの面倒だし、むしろRTC自身がセンサRTCなりアクチュエータRTCなりをどっかから自動検索、接続して勝手にシステムを構築してロボットが動いてくれないかなと思いました。
RTMはデータ型で何を通信しているのかは大体わかるので、適当にデータポートを接続してOutPortにデータを送信したらどこかに接続したInPortのデータが変化した→面白いのでもっとOutPortと通信してみようとか何をやらかすかわからないRTCとか作ってもらえれば僕は爆笑すると思います。それで何か学習してだんだんまともになっていくのならば良いのですが、何が目的なのかわからないのですから無理かもしれません。
たまに教育や学習を目的とした作品がありますけど、僕向きではないのでそちら方向はやめておきます。そもそも僕は人に教えるほどRTMについて詳しくないですからね。
いっその事メディアアートでもやってみるのも手かもしれないです。
アイデアはいくつかあるのですが、そもそも実現が可能なのかがわかっていません。
何せ2年ぐらい前にアニメを見てて思いついた事なので、出来るかどうかなんか考えている訳がないです。
もっと奨励賞で「自社製品を使ってほしい」とか言うのは増えないものかなあとは思います。
そうすれば僕が自分でアイデアを考える必要もないわけですから。
今年の予想ですけど、多分Pepperを使った作品が出てくるんだろうなあと思っています。
でも最近発売された製品を使うとか単純な発想では他の人と被る可能性大なので僕は避ける方針でいきます。
個人的な意見ですが、100ページ以上のマニュアル等はできれば読みたくないです。
もちろんそれだけのマニュアルを書く事自体は構わないのですが、それだけのマニュアルを読まないと使えないようなソフトウェアが良いものだとは思えません。簡易マニュアル等を別途に用意してほしいです。
以前はマニュアルはたくさん書いてある方が良いと思っていたのですが、他の作品のマニュアルを読んでいく中で考えが変わりました。正直しんどいです。
しかもそれで他のRTCを使用していたりするとそちらのマニュアルも読まなければならないので、ちょっとそれは勘弁してほしいです。と言うかそれだけ大量にマニュアルを書いたのに、なんで他のRTCのインストール方法は省略するのかが正直意味が分かりません。
あとpdfのマニュアルは読みづらいと思っているのですが、他の人はどう思っているのでしょうね？
他の作品を見ていて思った事は以下の通りです。
あとお願いですがCMakeの使い方がよくわからないので誰か解説してくれれば大変うれしいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
「独自データ型は使わないようにしている」と以前言いましたが、極力使わないぐらいな考えに変わりました。
どういう場合に使うかと言うと、例えば(x1,y1,x2,y2・・・・xn,yn)と言うようなデータを送信する場合、TimedDoubleSeqで通信するよりも、
struct Point2D
{
double x;
double y;
};
struct TimedPoint2DSeq
{
Time tm;
sequence<Point2D> data;
};
で通信した方が分かりやすいという単純な理由です。
いや別にそんな事何年も前に気付いていたのですが、独自データ型自体使いづらいですし、僕が既存のRTCと接続できる事を重視し過ぎていたみたいです。
凄く今更な事なのですが、他の作品のタイトル等にOpenRTMという単語が入っている事が多いのですが、これは何を指すのでしょうね？OpenRTM-aistとかOpenRTM.NETとかなら分かるのですが、OpenRTMだけだと何でしょう？オープンソースのRTMの実装を総称してそう言うのでしょうか？分からないのはひょっとしたら非常に恥ずかしいのかもしれないので、詳しい人は教えてください。
それから僕の思い違いかもしれないですけど、僕が他の作品に投稿したコメントをアドバイスだと思っている人がいるかもしれないので念のために言っておきますが、アドバイスではありません。疑問、もしくは苦情です。ちなみにツンデレではないです。「どうして～なのか？」のようにコメントしている場合はただの疑問ですが、「～してほしい」と言う風な感じの時は実は少し頭にきている事もあります。ちょっと試したいだけなのに***.dllがありませんとか、RTCを10個ビルドしろとか、ビルドに失敗するとか、手動でデータポートを10箇所以上接続してくださいとか言われたら、ちょっとイラッとすることもあります。どれか一つなら別に気にしないのですが、さすがに前述したトラブルが全て起きると嫌にもなりますよ。使ってもらう気あるの？と思うでしょ。
};
で通信した方が分かりやすいという単純な理由です。
いや別にそんな事何年も前に気付いていたのですが、独自データ型自体使いづらいですし、僕が既存のRTCと接続できる事を重視し過ぎていたみたいです。
凄く今更な事なのですが、他の作品のタイトル等にOpenRTMという単語が入っている事が多いのですが、これは何を指すのでしょうね？OpenRTM-aistとかOpenRTM.NETとかなら分かるのですが、OpenRTMだけだと何でしょう？オープンソースのRTMの実装を総称してそう言うのでしょうか？分からないのはひょっとしたら非常に恥ずかしいのかもしれないので、詳しい人は教えてください。
それから僕の思い違いかもしれないですけど、僕が他の作品に投稿したコメントをアドバイスだと思っている人がいるかもしれないので念のために言っておきますが、アドバイスではありません。疑問、もしくは苦情です。ちなみにツンデレではないです。「どうして～なのか？」のようにコメントしている場合はただの疑問ですが、「～してほしい」と言う風な感じの時は実は少し頭にきている事もあります。ちょっと試したいだけなのに***.dllがありませんとか、RTCを10個ビルドしろとか、ビルドに失敗するとか、手動でデータポートを10箇所以上接続してくださいとか言われたら、ちょっとイラッとすることもあります。どれか一つなら別に気にしないのですが、さすがに前述したトラブルが全て起きると嫌にもなりますよ。使ってもらう気あるの？と思うでしょ。
一つ言い忘れていた事がありました。
僕の作品のソースコードを読んでくださった審査員の皆さまに感謝の意を表します。
発表では失言を吐いてすみませんでした。
僕も全作品のソースコードを読んだので、その大変さが身にしみてわかったつもりです。
でも何だか全体的に誰がどの賞を取ったかを見てみると、自分の評価とは違ったなあというものもあると言う感じはあります。当日の発表で評価するという賞もあるのかもしれないです。
正直よくわからないのですが、予稿原稿には「実現できた」と書いてあるのに当日の発表では「できなかった」みたいな事を言っていた人がいたように思うのですが、それはどうなのでしょうね？まあ、別にどうでもいいのですが。
僕の作品のソースコードを読んでくださった審査員の皆さまに感謝の意を表します。
発表では失言を吐いてすみませんでした。
僕も全作品のソースコードを読んだので、その大変さが身にしみてわかったつもりです。
でも何だか全体的に誰がどの賞を取ったかを見てみると、自分の評価とは違ったなあというものもあると言う感じはあります。当日の発表で評価するという賞もあるのかもしれないです。
正直よくわからないのですが、予稿原稿には「実現できた」と書いてあるのに当日の発表では「できなかった」みたいな事を言っていた人がいたように思うのですが、それはどうなのでしょうね？まあ、別にどうでもいいのですが。
実は今年出す作品を考えていたのですが、なかなか名案がありません。
いやアイデア自体はいくつかあるのですが、どれも決め手に欠けます。
まずどういう方向性で行くか、単体のRTCか、ツールか、システムか、それとも別の何かか。いやアイデア自体はいくつかあるのですが、どれも決め手に欠けます。
システムとなると少し難しいような先入観があります。
「OpenRTM-aistを使ったからこういうシステムができました」というアイデアがないからです。
RTCやツールであれば現状のRTM関連のソフトウェアに足らない部分を考えれば良いので簡単なのですが、システムが対象となるとシステムを構築する事が目的になるので、単純にシステムを作るだけではなく、RTMを使うメリットが必要です。
RTCやツールを作る事を目的にする人はあまりいないと思うので、その点が違うのではないかと思います。
例えば、「似た機能のライブラリなりを使えば、同じような労力で同じシステムは構成できる」と言うのであれば特に意味はないと思います。
工程を削減できたとかでも良いので何か利点が無ければならないのですが、そもそも人のRTCを使うのが今の所簡単ではないのでむしろ時間が増える事の方が多いのが現状のような感じがしています。
何と言うか、OpenRTM-aistのC++版に32bit版と64bit版があることと、あと複数のOSに対応している事が逆効果になっているように思います。使いたいRTCがあっても自分の環境で動作できません。ロボットやっている人は大抵WindowsとLinux両方使えると思うので、それが余計にまずいのかもしれないです。
あと、OpenRTM-aistの1.0.0で開発したRTCは当然のことながら1.0.0のdllが無ければ動作できません。ただほとんどのRTCはdllを付属していないので、そのまま使われないように思います。
何と言うか、通常はExeファイルを実行(もしくはマネージャでモジュールをロード)→ネームサービスビューからRTCを選択してエディタ上に並べるというのが通常の手順だとは思いますが、もっと簡単にならないかなとは思っています。なにか有用なツールはないものですかね？
話がだいぶそれてしまいましたが、システムについては特に何もアイデアがありません。
今考えていてアイデアが浮かばない理由がもう一つある事がわかりました。
どうにも自分が使う分には良いのですが、人に使ってもらえるようにするのが難しいのではないかと思いました。そもそもシステムを構成するとなると色々な機器を使うことも多いので、それを人の環境で動作できるようにするのは難しいような感じです。単一のRTCであれば使用する機器も単一だと思うのでそこまで問題にならないのですが、複数の機器が必要となると他の環境で動作できる可能性は著しく下がると思います。実の所それで評価が下がる事はあまりないように思うのですが、僕は最低でも審査員の人の環境で動作できていないと不服なので避けたいと思っています。
完全に個人的な意見ですが、あるシステムを構築するためのRTC群を配布している作品もありますけど、何と言うか最終的に目的のシステムが構築できていれば良いのではなくて、もっとそれぞれのRTCの再利用性を考えてほしいなとは思いました。そのシステムでしか使えないようなRTCならば無駄に分割する必要もないと思います。
システム作るの面倒だし、むしろRTC自身がセンサRTCなりアクチュエータRTCなりをどっかから自動検索、接続して勝手にシステムを構築してロボットが動いてくれないかなと思いました。
RTMはデータ型で何を通信しているのかは大体わかるので、適当にデータポートを接続してOutPortにデータを送信したらどこかに接続したInPortのデータが変化した→面白いのでもっとOutPortと通信してみようとか何をやらかすかわからないRTCとか作ってもらえれば僕は爆笑すると思います。それで何か学習してだんだんまともになっていくのならば良いのですが、何が目的なのかわからないのですから無理かもしれません。
たまに教育や学習を目的とした作品がありますけど、僕向きではないのでそちら方向はやめておきます。そもそも僕は人に教えるほどRTMについて詳しくないですからね。
いっその事メディアアートでもやってみるのも手かもしれないです。
アイデアはいくつかあるのですが、そもそも実現が可能なのかがわかっていません。
何せ2年ぐらい前にアニメを見てて思いついた事なので、出来るかどうかなんか考えている訳がないです。
もっと奨励賞で「自社製品を使ってほしい」とか言うのは増えないものかなあとは思います。
そうすれば僕が自分でアイデアを考える必要もないわけですから。
今年の予想ですけど、多分Pepperを使った作品が出てくるんだろうなあと思っています。
でも最近発売された製品を使うとか単純な発想では他の人と被る可能性大なので僕は避ける方針でいきます。
個人的な意見ですが、100ページ以上のマニュアル等はできれば読みたくないです。
もちろんそれだけのマニュアルを書く事自体は構わないのですが、それだけのマニュアルを読まないと使えないようなソフトウェアが良いものだとは思えません。簡易マニュアル等を別途に用意してほしいです。
以前はマニュアルはたくさん書いてある方が良いと思っていたのですが、他の作品のマニュアルを読んでいく中で考えが変わりました。正直しんどいです。
しかもそれで他のRTCを使用していたりするとそちらのマニュアルも読まなければならないので、ちょっとそれは勘弁してほしいです。と言うかそれだけ大量にマニュアルを書いたのに、なんで他のRTCのインストール方法は省略するのかが正直意味が分かりません。
あとpdfのマニュアルは読みづらいと思っているのですが、他の人はどう思っているのでしょうね？
他の作品を見ていて思った事は以下の通りです。
- マニュアルがないのは論値、とまでは言いませんがかなりまずいです
- できれば動画等があると分かりやすいと思います
- プロジェクトページに画像を設定してください
- マニュアルは少し読んだだけで試用したい
- 個人的にはpdfのマニュアルは読みづらいのでやめてほしい
- 全員GitHubを使うように統一しても良いかもしれません
- RTCの粒度に注意しないと後々苦労するのは自分ではなくユーザーです
- システムを構築することが目的の場合、もっと個々のRTCの設計もよく考えてほしい
- 必要なdll等があるなら付属させるか、入手方法を記してほしいです
- 複数の環境で動作確認するようにしてください
- できれば2種類以上のOSに対応させてください
- マネージャーでモジュールをロードする機能をもっと使った方が面白いかもしれません
- 既に開発されているRTCは入念に調べてください
- 独自データ型はよく考えてから使ってください
- サービスポートを使った作品が少なかったように思ったので、もう少し使われてもいいかも
- while文等で処理を長時間ブロックしないようにしてください
- スレッド等の機能はできればcoilを使ってください
- 実行ファイルを配布する場合はリリースビルドしてください
- こちらでビルドする仕様なのにエラーがでるとキレそうになります
- できれば回路の自作、部品の加工などを強いるのはやめてほしい
- Python版、Java版、OpenRTM.NET等をもっと使ってほしい
- 定量的なデータがあると利点が分かりやすい事もあります
- さらにその原因まで述べる事が出来ていれば、僕には勉強になるので嬉しいです
- 他の人の作品にコメントしてください
- というか、他の人の作品にも興味を持ってください
- 自分が助言を貰う側の人間だとは思わないでほしい
- ちゃんと動作できているかどうかをもっと審査で重視したほうが良いと思う
- 何か機器を使う場合は価格、購入方法まで記載してほしいです
- ログファイル等は削除してアップロードしてください
あとお願いですがCMakeの使い方がよくわからないので誰か解説してくれれば大変うれしいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
こんどこそ、これでしばらく休みます。
今回は感想等を書きます。
公式ページを見ると、「このコンテストを通して、これからのロボットソフトウエア開発者に不可欠なRTミドルウエアに精通する技術者も育成できるものと期待しています」と書いてあります。
僕でも3回出れば最優秀賞取れるのですから、確かな成果はあったと言う事なのでしょう。
来年のコンテストのキーノート講演の予稿原稿「RTミドルウェアコンテスト2015の狙い(仮)」には、そう言う事を書いておけばウケが良いと思います。
確実に前回よりクオリティの高い作品を作り続ければ、いずれは誰でも最優秀賞を取れます。
そもそも、1回目に参加する人でRTミドルウェアについて既に詳しい人なんてほとんどいないと思います。OpenRTM-aistの機能について把握するのにも相当時間がかかると思いますし、さらにrtshell、OpenRTM.NET等関連技術、CORBAの仕組み等について理解しようと思えば膨大な時間がかかります。好きじゃないととてもできません。僕なんか未だにOpenRTM-aistの全機能を把握できていません。
ORiNとの連携(以下略)、屋内地図モデルの簡易生成コンポーネント群、RTMによるカメラマンロボットの動作確実性の向上、メディアアートコミュニティ実現に向けたRTコンポーネントの開発と提案、楽器演奏のためのMIDI RTコンポーネントの開発あたりは2回以上参加しているだけあって非常にレベルが高い印象です。
この事からも「コンテストによるRTミドルウェアに精通する技術者の育成」と言う意味で、コンテストを毎年開催している効果があったという事なのだと思います。
これらの作品が前回より確実にレベルアップした事に加えて、視覚脳科学研究を目的としたRTミドルウェアの応用と結果、AR Drone用OPEN-RTM通信コンポーネントの実装、RTM-RSNPによる人数管理システムも評価が高く、非常にハイレベルなコンテストになりました。賞が30個ぐらいあっても良かったと思います。
特にORiNとの連携(以下略)、屋内地図モデルの簡易生成コンポーネント群あたりは例年であれば3～4つ賞を取れていてもおかしくありません。
しかしこれだけレベルが高くなってくると、初参加で優勝と言うのはかなり難しいと思います。
実際、初参加で優勝しているのって殿堂入りしている2人だけですからね。
今回のコンテストを通じて一つ分かった事があります。
他の投稿作品で科研費やNEDOの支援を受けて研究していたものもありましたが、そんなものなくても勝てると言う事です。それから、協力者が誰もいなくても勝つ事は可能です。ただ質疑応答で一悶着起こしてしまったわけですが、その事を事前に誰かに指摘してもらっていたら良かったかもしれません。だからあれだけコメントくれくれと言っていたのですが、なかなか上手くいきませんでした。
来年は出るかどうか分かりません。
次優勝するとおそらく殿堂入りで出禁になってしまうので、いつ参加しても次が最後の参加になるかもしれないです。切りの良い第10回大会を狙う方が面白いかもしれないですね。
(補足)
そういえば、審査は相当揉めて最終的に多数決で決めたらしいです。
自分の評価は分かりませんけど、他の作品から最優秀賞を選べと言われれば相当迷うと思います。
屋内地図モデルの簡易生成コンポーネント群はレベルは高いのですが、あの非合理とも思えるRTCの設計が僕の評価を下げています。SysMLで設計したとからしいですけど、使わない方が良かったのではと思っています。システム全体として見た場合rtshellでデータポートの接続等の面倒さ等の問題は解決できるとしてもオーバーヘッドが大きくなるのはどうにもなりませんし、個々のRTCを見た場合再利用性の低い部分までコンポーネントとして分割しているため一部のRTCを使いたい場合でも複数のRTCを起動しなければならないため使いづらく、再利用性を下げているように思います。
ORiNとの連携(以下略)は少しプログラミング技術が未熟な部分があるのが気になります。
視覚脳科学研究を目的としたRTミドルウェアの応用と結果は詳細なマニュアルがないのが大きなマイナス点です。
楽器演奏のためのMIDI RTコンポーネントの開発は笑いを取ったので個人賞ならあげたいのですが、僕がMIDIを知らないのでどう評価してよいのか分かりません。
まあでも自分が一番気になる作品と言われれば、上の作品の中で一番熱を込めて語ってしまった作品だと思うので、そう言う事なのだとは思います。
まあ何にせよ、次出るときは全く異論の出ないぐらい圧倒して最優秀賞を取れるように努力する必要がありそうですね。
(補足の補足)
どうしても一つ言っておきたい事があったので、補足しておきます。
某大学から毎年のようにRTMコンテストに参加しているみたいですが、あまり成績は振るっていないようですね。
今年は4組参加して一つも賞を貰えなかったみたいです。
先に言っておきますが、大学とは関係あるとも言えなくもないですが、研究室とは全くの無関係で知り合いもいないぐらいなので、以下で言っている事は僕が勝手に言っている事です。
自分の研究とは別にやるのであれば、もっと気楽にというか楽しくやった方が良いのではないでしょうか？
自分の研究としてやっているのであれば、死ぬ気でやるしかないですね。
とりあえず、マニュアルはちゃんと書くように研究室内で徹底した方が良いと思います。見た感じ、誰もマニュアルを書いてません。おそらく評価を著しく下げていると思います。
芝浦工業大学、埼玉大学、電気通信大学あたりは毎年強いので、コツでも聞いてみてはどうでしょうか？
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
今回は感想等を書きます。
公式ページを見ると、「このコンテストを通して、これからのロボットソフトウエア開発者に不可欠なRTミドルウエアに精通する技術者も育成できるものと期待しています」と書いてあります。
僕でも3回出れば最優秀賞取れるのですから、確かな成果はあったと言う事なのでしょう。
来年のコンテストのキーノート講演の予稿原稿「RTミドルウェアコンテスト2015の狙い(仮)」には、そう言う事を書いておけばウケが良いと思います。
確実に前回よりクオリティの高い作品を作り続ければ、いずれは誰でも最優秀賞を取れます。
そもそも、1回目に参加する人でRTミドルウェアについて既に詳しい人なんてほとんどいないと思います。OpenRTM-aistの機能について把握するのにも相当時間がかかると思いますし、さらにrtshell、OpenRTM.NET等関連技術、CORBAの仕組み等について理解しようと思えば膨大な時間がかかります。好きじゃないととてもできません。僕なんか未だにOpenRTM-aistの全機能を把握できていません。
ORiNとの連携(以下略)、屋内地図モデルの簡易生成コンポーネント群、RTMによるカメラマンロボットの動作確実性の向上、メディアアートコミュニティ実現に向けたRTコンポーネントの開発と提案、楽器演奏のためのMIDI RTコンポーネントの開発あたりは2回以上参加しているだけあって非常にレベルが高い印象です。
この事からも「コンテストによるRTミドルウェアに精通する技術者の育成」と言う意味で、コンテストを毎年開催している効果があったという事なのだと思います。
これらの作品が前回より確実にレベルアップした事に加えて、視覚脳科学研究を目的としたRTミドルウェアの応用と結果、AR Drone用OPEN-RTM通信コンポーネントの実装、RTM-RSNPによる人数管理システムも評価が高く、非常にハイレベルなコンテストになりました。賞が30個ぐらいあっても良かったと思います。
特にORiNとの連携(以下略)、屋内地図モデルの簡易生成コンポーネント群あたりは例年であれば3～4つ賞を取れていてもおかしくありません。
しかしこれだけレベルが高くなってくると、初参加で優勝と言うのはかなり難しいと思います。
実際、初参加で優勝しているのって殿堂入りしている2人だけですからね。
今回のコンテストを通じて一つ分かった事があります。
他の投稿作品で科研費やNEDOの支援を受けて研究していたものもありましたが、そんなものなくても勝てると言う事です。それから、協力者が誰もいなくても勝つ事は可能です。ただ質疑応答で一悶着起こしてしまったわけですが、その事を事前に誰かに指摘してもらっていたら良かったかもしれません。だからあれだけコメントくれくれと言っていたのですが、なかなか上手くいきませんでした。
来年は出るかどうか分かりません。
次優勝するとおそらく殿堂入りで出禁になってしまうので、いつ参加しても次が最後の参加になるかもしれないです。切りの良い第10回大会を狙う方が面白いかもしれないですね。
(補足)
そういえば、審査は相当揉めて最終的に多数決で決めたらしいです。
自分の評価は分かりませんけど、他の作品から最優秀賞を選べと言われれば相当迷うと思います。
屋内地図モデルの簡易生成コンポーネント群はレベルは高いのですが、あの非合理とも思えるRTCの設計が僕の評価を下げています。SysMLで設計したとからしいですけど、使わない方が良かったのではと思っています。システム全体として見た場合rtshellでデータポートの接続等の面倒さ等の問題は解決できるとしてもオーバーヘッドが大きくなるのはどうにもなりませんし、個々のRTCを見た場合再利用性の低い部分までコンポーネントとして分割しているため一部のRTCを使いたい場合でも複数のRTCを起動しなければならないため使いづらく、再利用性を下げているように思います。
ORiNとの連携(以下略)は少しプログラミング技術が未熟な部分があるのが気になります。
視覚脳科学研究を目的としたRTミドルウェアの応用と結果は詳細なマニュアルがないのが大きなマイナス点です。
楽器演奏のためのMIDI RTコンポーネントの開発は笑いを取ったので個人賞ならあげたいのですが、僕がMIDIを知らないのでどう評価してよいのか分かりません。
まあでも自分が一番気になる作品と言われれば、上の作品の中で一番熱を込めて語ってしまった作品だと思うので、そう言う事なのだとは思います。
まあ何にせよ、次出るときは全く異論の出ないぐらい圧倒して最優秀賞を取れるように努力する必要がありそうですね。
(補足の補足)
どうしても一つ言っておきたい事があったので、補足しておきます。
某大学から毎年のようにRTMコンテストに参加しているみたいですが、あまり成績は振るっていないようですね。
今年は4組参加して一つも賞を貰えなかったみたいです。
先に言っておきますが、大学とは関係あるとも言えなくもないですが、研究室とは全くの無関係で知り合いもいないぐらいなので、以下で言っている事は僕が勝手に言っている事です。
自分の研究とは別にやるのであれば、もっと気楽にというか楽しくやった方が良いのではないでしょうか？
自分の研究としてやっているのであれば、死ぬ気でやるしかないですね。
とりあえず、マニュアルはちゃんと書くように研究室内で徹底した方が良いと思います。見た感じ、誰もマニュアルを書いてません。おそらく評価を著しく下げていると思います。
芝浦工業大学、埼玉大学、電気通信大学あたりは毎年強いので、コツでも聞いてみてはどうでしょうか？
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
