ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
とりあえず昨日は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でやると遅いのでしょうか？詳しい人がいれば教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
また更新してしまいました。
前から書こうと思っていたのですが忘れていたので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の使い方がよくわからないので誰か解説してくれれば大変うれしいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
Wordを操作するRTCを作りました。
ここからダウンロードできます。
あと、OpenOffice Writerを操作するRTCも作りました。
ダウンロードはこのページのリンクからできます。
とりあえず、マニュアルがないので作りたいとは思っています。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ここからダウンロードできます。
あと、OpenOffice Writerを操作するRTCも作りました。
ダウンロードはこのページのリンクからできます。
とりあえず、マニュアルがないので作りたいとは思っています。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
Excelを操作するRTCを作りました。
ここからダウンロードできます。
まだマニュアルがないのでこれから作りたいと思います。
とりあえずGUIの構成は以下のようになってます。
ダウンロードしたファイルを解凍したフォルダに入っているExcelRTC.exeを実行すればRTCが立ちあがります。
それからOpenOffice Calcを操作するRTCの機能を増やしといたので、前より使いやすくなったような気がしなくもないです。
Excelを操作するRTCですが、起動したら後の使い方はCalcを操作するRTCとほぼ同じなのでとりあえずCalcを操作するRTCのマニュアルを見れば使えるかもしれないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ここからダウンロードできます。
まだマニュアルがないのでこれから作りたいと思います。
とりあえずGUIの構成は以下のようになってます。
ダウンロードしたファイルを解凍したフォルダに入っているExcelRTC.exeを実行すればRTCが立ちあがります。
それからOpenOffice Calcを操作するRTCの機能を増やしといたので、前より使いやすくなったような気がしなくもないです。
Excelを操作するRTCですが、起動したら後の使い方はCalcを操作するRTCとほぼ同じなのでとりあえずCalcを操作するRTCのマニュアルを見れば使えるかもしれないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
