ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
昨日の記事は人の作品を貶す発言があっただけに、何か言われるかと思いましたが何も起きませんでした。
あれから理由を考えてはみたのですが、1つ受賞ならともかく2つ受賞する理由は思いつきません。
と言うよりも受賞1つ以下の作品でこの作品より印象の良かった作品もいくつかありました。
サマーキャンプ賞やRTC再利用賞みたいに審査基準をクリアしている作品が他にないのであれば分かりますけど、この作品の場合そうじゃないわけで謎が深まるばかりです。
確かに環境の整ったVMWareイメージを配布しているのは便利と言えば便利なのですが、そこまで大した作業ではないだろうしこれだけでは苦しいです。
要はVMWare上のUbuntuで動作できるようにして、そのVMWareイメージのコピーをアップロードしただけですからね。
そもそもOpenRTM-aistのArmでのクロスコンパイルの情報が公式サイトに載っているので、やろうと思えば誰にでもできます。
それから、RTCの実装が独自のデータ型を除いても歪です。
CV Droneというライブラリはドローンにソケット通信することで各操作を行うライブラリらしく、つまりドローン上でこのライブラリとRTCを動作させると以下の2回の通信が発生することになります。
つまり、デフォルトのアドレス以外の場合は通信できない事になります。
それならlocalhostで良かったと思うけどなあ。
と言うよりCV Droneというライブラリの実装からして、ドローン上でCV Droneの動作するRTCを動作させた事自体間違っていると思います。
通信を挟まずに直接ドローンを操作する方法が存在しないのであれば別ですけど。
まさか人のソースコードを同じフォルダに入れているので審査員の人が勘違いしたのだったりして・・・・いやいくらなんでもそんな事あるわけないか。
ちなみに僕は最初に見たとき勘違いしました。
どちらにしろ誤解を招く行為なので、GitHubを使っているのであればsubmoduleを使うべきです。submoduleの使い方がややこしいのであれば、せめて別フォルダに分けておくべきでした。
どうにも僕の知らない審査基準があるみたいです。
それがRTMコンテストの必勝法だと思うので、知っている人は教えてください。
それはさておき70種類のRTCを配布します。
ここからダウンロードできます。
73種類だったはずなのですが、数え直してみると70種類でした。
おそらく、テスト用RTCを3つ数に含めていたのだとは思いますが定かではありません。
Windowsフォルダとubilinuxフォルダに分かれていますが、ubilinuxフォルダのRTCはubilinuxでしか動作できません。
このRTC群には必要なdllは付属していないので、ツールでの使用を前提にしています。
ここからツール本体をダウンロードして解凍後、Componentsと言う名前のフォルダ内にRTCをコピーします。
Windowsで動作させるのであればWindows/RTCフォルダの中身をコピーしてください。
ツールをVS2013、32bit以外の環境で再ビルドした場合、RTCも再ビルドする必要があるのでWindows/buildフォルダのVisual_Studio_xx_xx_yyy_Genarate.bat(xxxはVSのバージョン、64bitの場合はyyyにWin64)、BuildRelease.batを実行してビルドしてください。
そしてbuildフォルダの各RTC名のフォルダをComponentsフォルダにコピーしてください。
Ubuntuの場合も同様にUnix_Makefiles_Genarate.sh、BuildRelease.shを起動してフォルダをコピーしてください。
今のところあまりツール自体が使いやすくありませんね。
問題なのは配布先でビルドが必要な場合で、失敗するRTCもそれなりにあると思います。
できればツールの再ビルド自体してほしくないのですが、既に違うバージョンのOpenRTM-aistをインストールしている場合は自作のRTCが動作できないので不便かもしれません。
ビルドに失敗しても、最初から付属している実行ファイルでなら起動できるのでそうしてください。
実は昨日に公開することはできたのですけど、RTMコンテスト2010に応募したツールのGUIにスプラッシュスクリーンを追加していたら今日になってしまいました。
追加したスプラッシュスクリーンはこれです。
もはや何だよこれ・・・
明らかに前より酷くなっています。
なぜこうなったかを説明します。
まずこのツールはGUI上のエディタ上でボディのブロックを並べてジョイントで接続すると、3Dで組み立てたロボットが表示されるというツールです。
なので何か連結、合体するものを題材にしたいと思いました。
連結、合体と言えばメガドライブ＋メガcd＋スーパー32Xだろうという事で、まずメガドラ3段鏡餅を書いてみました。
そして物足りないので手を書いて、さらに何か笑いが欲しかったのでコントローラーを振り回させてみました。
というきわめて普通な理由なのですが、最終的にはカオスになりました。
まあ、どうせ一瞬しか見えないのでどうでもいいか。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
あれから理由を考えてはみたのですが、1つ受賞ならともかく2つ受賞する理由は思いつきません。
と言うよりも受賞1つ以下の作品でこの作品より印象の良かった作品もいくつかありました。
サマーキャンプ賞やRTC再利用賞みたいに審査基準をクリアしている作品が他にないのであれば分かりますけど、この作品の場合そうじゃないわけで謎が深まるばかりです。
確かに環境の整ったVMWareイメージを配布しているのは便利と言えば便利なのですが、そこまで大した作業ではないだろうしこれだけでは苦しいです。
要はVMWare上のUbuntuで動作できるようにして、そのVMWareイメージのコピーをアップロードしただけですからね。
そもそもOpenRTM-aistのArmでのクロスコンパイルの情報が公式サイトに載っているので、やろうと思えば誰にでもできます。
それから、RTCの実装が独自のデータ型を除いても歪です。
CV Droneというライブラリはドローンにソケット通信することで各操作を行うライブラリらしく、つまりドローン上でこのライブラリとRTCを動作させると以下の2回の通信が発生することになります。
- PCのRTCからドローンのRTCへ通信
- ドローン内部で通信
つまり、デフォルトのアドレス以外の場合は通信できない事になります。
それならlocalhostで良かったと思うけどなあ。
と言うよりCV Droneというライブラリの実装からして、ドローン上でCV Droneの動作するRTCを動作させた事自体間違っていると思います。
通信を挟まずに直接ドローンを操作する方法が存在しないのであれば別ですけど。
まさか人のソースコードを同じフォルダに入れているので審査員の人が勘違いしたのだったりして・・・・いやいくらなんでもそんな事あるわけないか。
ちなみに僕は最初に見たとき勘違いしました。
どちらにしろ誤解を招く行為なので、GitHubを使っているのであればsubmoduleを使うべきです。submoduleの使い方がややこしいのであれば、せめて別フォルダに分けておくべきでした。
どうにも僕の知らない審査基準があるみたいです。
それがRTMコンテストの必勝法だと思うので、知っている人は教えてください。
それはさておき70種類のRTCを配布します。
ここからダウンロードできます。
73種類だったはずなのですが、数え直してみると70種類でした。
おそらく、テスト用RTCを3つ数に含めていたのだとは思いますが定かではありません。
Windowsフォルダとubilinuxフォルダに分かれていますが、ubilinuxフォルダのRTCはubilinuxでしか動作できません。
このRTC群には必要なdllは付属していないので、ツールでの使用を前提にしています。
ここからツール本体をダウンロードして解凍後、Componentsと言う名前のフォルダ内にRTCをコピーします。
Windowsで動作させるのであればWindows/RTCフォルダの中身をコピーしてください。
ツールをVS2013、32bit以外の環境で再ビルドした場合、RTCも再ビルドする必要があるのでWindows/buildフォルダのVisual_Studio_xx_xx_yyy_Genarate.bat(xxxはVSのバージョン、64bitの場合はyyyにWin64)、BuildRelease.batを実行してビルドしてください。
そしてbuildフォルダの各RTC名のフォルダをComponentsフォルダにコピーしてください。
Ubuntuの場合も同様にUnix_Makefiles_Genarate.sh、BuildRelease.shを起動してフォルダをコピーしてください。
今のところあまりツール自体が使いやすくありませんね。
問題なのは配布先でビルドが必要な場合で、失敗するRTCもそれなりにあると思います。
できればツールの再ビルド自体してほしくないのですが、既に違うバージョンのOpenRTM-aistをインストールしている場合は自作のRTCが動作できないので不便かもしれません。
ビルドに失敗しても、最初から付属している実行ファイルでなら起動できるのでそうしてください。
実は昨日に公開することはできたのですけど、RTMコンテスト2010に応募したツールのGUIにスプラッシュスクリーンを追加していたら今日になってしまいました。
追加したスプラッシュスクリーンはこれです。
もはや何だよこれ・・・
明らかに前より酷くなっています。
なぜこうなったかを説明します。
まずこのツールはGUI上のエディタ上でボディのブロックを並べてジョイントで接続すると、3Dで組み立てたロボットが表示されるというツールです。
なので何か連結、合体するものを題材にしたいと思いました。
連結、合体と言えばメガドライブ＋メガcd＋スーパー32Xだろうという事で、まずメガドラ3段鏡餅を書いてみました。
そして物足りないので手を書いて、さらに何か笑いが欲しかったのでコントローラーを振り回させてみました。
というきわめて普通な理由なのですが、最終的にはカオスになりました。
まあ、どうせ一瞬しか見えないのでどうでもいいか。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
RTCやRTSystemを配布するためのツールで、そのツール自体のインストールや使用が難しかったら本末転倒だと思います。
と言うより理想としては、配布先でネームサービスさえ起動できれば動作できた方が良いぐらいだと思います。できればcmakeやrtshellとかもインストールしたくありません。
ツールでパッケージは作成するけど、作成したパッケージを動作させるのにツールは必要ないという風にできればいいのですけど。
この前OpenRTM-aistはROSより難しいかもしれないと言いましたが、難しいと思うのであれば自分でコードを書かなければ良いと思うのですよね。
要はブロックを並べてポートを接続するだけでシステムを開発できるようになっているので、既存のRTCを使ってシステムを作れば良いじゃないですか。
まあ、その既存のRTCがなかなか動作できないので負のスパイラルに嵌っているのですけど。
ソースコード、実行ファイルのみで配布するのであれば、Pythonで実装した方が動作できる可能性も高いのじゃないかなあ。ソースコードだけの配布で大丈夫なわけですからね。もちろんこちら側でOpenRTM-aistのPython版をインストールしておく必要がありますけど、どのバージョンをインストールしていても動作はできるとは思います。
そういえば来週はサマーキャンプがあるとからしいですね。
行ったことないのでよく分かりませんけどなかなか面白そうな講義もあるので、後でスライドが公開されるようなら読みます。
個人的には、最優秀賞を取るという意味ではRTMコンテストに必勝法なんてないと思っています。
マニュアルを書く、期日までにソースコードを公開するなんてのは最低条件です。
ソースコードを読まれてしまう以上は最終的には実力だと思います。
当日の発表が悪くても内容さえ良ければ最優秀賞は取れます。
ただそれは最優秀賞の話であって、他の奨励賞だったら対策を取る意味はあります。
あまり言ってはいけないのかもしれませんが、去年のコンテストのドローンの作品は複数の賞を取りましたけど、僕がソースコード、マニュアルを読んだ印象はあまりよくありませんでした。
むしろ、マニュアルは読みづらい、独自のデータ型を使う意味が分からない、コメントを1週間放置した挙句質問には答えないとかで悪い印象の方が強かったように思います。
ソースコードもほとんど人のライブラリに依存していて自分で実装した部分は数百行程度だったのであまり頑張っているようには見えなかったのも印象を悪くしたかもしれません。
別に沢山コードを書けば良いという事ではありませんけど、人のライブラリを使って何の工夫もなく単純にRTCに実装しただけでは少し印象が悪いです。
ではなぜ賞が取れたのか？
正直なところ僕には分からないので、サマーキャンプで講師の人に訊いてください。
この作品にRTMコンテスト必勝法の鍵があると思います。
逆にこの作品はソースコード読んだ感じでは完成度高くて好印象だったのですが、何も賞を取れませんでした。過去の作品と微妙に被っていると言うのもあったのでしょうけど、マニュアルがないのが致命的だったかもしれません。と言うより、この人の研究室って誰もマニュアル書いてません。
以前の作品と被らない事は確かに重要だと思います。
個人的にはもう少しRTMの機能を生かしたツールが出てほしいなと思います。
マスターマネージャ、スレーブマネージャ機能とか上手く使いこなせている人はほとんどいないと思うので、ツールを作る余地はありそうです。
今週中に73種類のRTCを配布すると言いましたが、無理そうなので来週中にします。
以前作成したRTCの修正に思ったより手こずっている状況です。
ちょっと見込みが甘かったかもしれないです。
それ以外にもツール本体の修正もやったので、それで多少予定が狂った感じもあります。
配布予定のRTCの大半にはマニュアルがありません。
ツールでRTCの情報を読めるので、それがマニュアルの替わりです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
と言うより理想としては、配布先でネームサービスさえ起動できれば動作できた方が良いぐらいだと思います。できればcmakeやrtshellとかもインストールしたくありません。
ツールでパッケージは作成するけど、作成したパッケージを動作させるのにツールは必要ないという風にできればいいのですけど。
この前OpenRTM-aistはROSより難しいかもしれないと言いましたが、難しいと思うのであれば自分でコードを書かなければ良いと思うのですよね。
要はブロックを並べてポートを接続するだけでシステムを開発できるようになっているので、既存のRTCを使ってシステムを作れば良いじゃないですか。
まあ、その既存のRTCがなかなか動作できないので負のスパイラルに嵌っているのですけど。
ソースコード、実行ファイルのみで配布するのであれば、Pythonで実装した方が動作できる可能性も高いのじゃないかなあ。ソースコードだけの配布で大丈夫なわけですからね。もちろんこちら側でOpenRTM-aistのPython版をインストールしておく必要がありますけど、どのバージョンをインストールしていても動作はできるとは思います。
そういえば来週はサマーキャンプがあるとからしいですね。
行ったことないのでよく分かりませんけどなかなか面白そうな講義もあるので、後でスライドが公開されるようなら読みます。
個人的には、最優秀賞を取るという意味ではRTMコンテストに必勝法なんてないと思っています。
マニュアルを書く、期日までにソースコードを公開するなんてのは最低条件です。
ソースコードを読まれてしまう以上は最終的には実力だと思います。
当日の発表が悪くても内容さえ良ければ最優秀賞は取れます。
ただそれは最優秀賞の話であって、他の奨励賞だったら対策を取る意味はあります。
あまり言ってはいけないのかもしれませんが、去年のコンテストのドローンの作品は複数の賞を取りましたけど、僕がソースコード、マニュアルを読んだ印象はあまりよくありませんでした。
むしろ、マニュアルは読みづらい、独自のデータ型を使う意味が分からない、コメントを1週間放置した挙句質問には答えないとかで悪い印象の方が強かったように思います。
ソースコードもほとんど人のライブラリに依存していて自分で実装した部分は数百行程度だったのであまり頑張っているようには見えなかったのも印象を悪くしたかもしれません。
別に沢山コードを書けば良いという事ではありませんけど、人のライブラリを使って何の工夫もなく単純にRTCに実装しただけでは少し印象が悪いです。
ではなぜ賞が取れたのか？
正直なところ僕には分からないので、サマーキャンプで講師の人に訊いてください。
この作品にRTMコンテスト必勝法の鍵があると思います。
逆にこの作品はソースコード読んだ感じでは完成度高くて好印象だったのですが、何も賞を取れませんでした。過去の作品と微妙に被っていると言うのもあったのでしょうけど、マニュアルがないのが致命的だったかもしれません。と言うより、この人の研究室って誰もマニュアル書いてません。
以前の作品と被らない事は確かに重要だと思います。
個人的にはもう少しRTMの機能を生かしたツールが出てほしいなと思います。
マスターマネージャ、スレーブマネージャ機能とか上手く使いこなせている人はほとんどいないと思うので、ツールを作る余地はありそうです。
今週中に73種類のRTCを配布すると言いましたが、無理そうなので来週中にします。
以前作成したRTCの修正に思ったより手こずっている状況です。
ちょっと見込みが甘かったかもしれないです。
それ以外にもツール本体の修正もやったので、それで多少予定が狂った感じもあります。
配布予定のRTCの大半にはマニュアルがありません。
ツールでRTCの情報を読めるので、それがマニュアルの替わりです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
前回の記事で77種類のRTCを同梱すると言いましたが、やはり例の4個のRTCを公開できるレベルに持っていくのは時間がかかるので73種類に減らします。
何のRTCかと言うとTITANⅧ制御関連のRTCなのですが、元々自分用に作ったRTCで公開できるような内容ではないので今回はやめておきます。
73種類については今週中には公開できそうです。
アクセス解析を見ると、産総研からのアクセスがあるみたいですが最近の記事の内容で怒っていないか不安です。
いやだって、動作できないものはできないのだから仕方ないじゃん。
wasanbonでパッケージを作成しておけば動作するまでが楽かもしれませんが、このツールのインストールで引っかかる人もいるのではないでしょうか？
どうにもpipで文字コードのエラーが出る事があるらしく、デフォルトの文字コードを設定しておく必要があります。
C:\Python27\Lib\site-packagesにsitecustomize.pyという名前のファイルを作成して以下のコードを記述します。
これでインストールはできると思います。
インストールは出来ても僕の環境では色々トラブルが起こっていますし、マニュアルを読んでもなかなか難しい部分があります。
と言うかそれ以前にマニュアルとコマンドが違うような気がするのですが、気のせいでしょうか？
よく見ると日本語と英語のマニュアルでも違うみたいです。
このツールを使っている人がどのぐらいいるのかは知りませんが、正直なところ僕には難しすぎです。
せっかくパッケージを作成しても、パッケージを使う側の人がwasanbonを使えなければ意味がありません。
人のツールを使うのでこれだけ苦労するのだから、逆に言えば僕の開発したツールは全然動作できていない可能性が高そうですね。
万が一、動作できた人がいれば下のコメント欄で教えてください。
動作できなくても教えてください。
僕が探した感じですが、RTC、RTSystemを他の環境で動作させるまでの手間を劇的に簡単化するツールと言うものは存在しないので、自分でビルド・RTCの起動・システムの復元のスクリプトを書くのが現状では確実だと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
何のRTCかと言うとTITANⅧ制御関連のRTCなのですが、元々自分用に作ったRTCで公開できるような内容ではないので今回はやめておきます。
73種類については今週中には公開できそうです。
アクセス解析を見ると、産総研からのアクセスがあるみたいですが最近の記事の内容で怒っていないか不安です。
いやだって、動作できないものはできないのだから仕方ないじゃん。
wasanbonでパッケージを作成しておけば動作するまでが楽かもしれませんが、このツールのインストールで引っかかる人もいるのではないでしょうか？
どうにもpipで文字コードのエラーが出る事があるらしく、デフォルトの文字コードを設定しておく必要があります。
C:\Python27\Lib\site-packagesにsitecustomize.pyという名前のファイルを作成して以下のコードを記述します。
import sys
sys.setdefaultencoding('cp932')
これでインストールはできると思います。
インストールは出来ても僕の環境では色々トラブルが起こっていますし、マニュアルを読んでもなかなか難しい部分があります。
と言うかそれ以前にマニュアルとコマンドが違うような気がするのですが、気のせいでしょうか？
よく見ると日本語と英語のマニュアルでも違うみたいです。
このツールを使っている人がどのぐらいいるのかは知りませんが、正直なところ僕には難しすぎです。
せっかくパッケージを作成しても、パッケージを使う側の人がwasanbonを使えなければ意味がありません。
人のツールを使うのでこれだけ苦労するのだから、逆に言えば僕の開発したツールは全然動作できていない可能性が高そうですね。
万が一、動作できた人がいれば下のコメント欄で教えてください。
動作できなくても教えてください。
僕が探した感じですが、RTC、RTSystemを他の環境で動作させるまでの手間を劇的に簡単化するツールと言うものは存在しないので、自分でビルド・RTCの起動・システムの復元のスクリプトを書くのが現状では確実だと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
昨日の記事は見方によってはRTMサイドの人に喧嘩を売るような発言があっただけに炎上するかとも思ったのですが、特に何も起きませんでした。
9割は動作できないというのは僕は動作できなかったという意味なので、動作できないのは僕の頑張りが足らないからと言われれば一理あるとは思いますが、動作確認するためだけにそんなに労力を割きたくありません。
公式で複数のバージョンのOpenRTM-aistのインストールを非推奨にしているにもかかわらず、必要なDLLを付属させず実行ファイルのみを配布するのは意図がよく分かりません。
ここでその事に関係しそうなことを議論しているようですが、まとめると以下の3通りの方法があると言っているみたいです。
RTMユーザーにWindowsを使っている人が多いせいもあって、CMakeがあまり身近な存在ではありません。
ビルドする過程で何かしらのトラブルが起こる可能性は高いと思います。
この方法の最大の問題は各RTCでいちいちcmake-guiを起動してプロジェクトを生成→VisualStudioで開いてビルドをしなければならない点で、RTCの数が10個も20個にもなるとやる気をなくします。
一つのRTCのプロジェクト作成からビルド完了までに5分かかるとして、10個で50分ですか。しかも放置して50分ではないので相当な手間です。
この辺は何かしらのツールを使えば解決できるかもしれないので今後に期待です。
3は自分だけならそれでも良いのですけどRTCの配布先でやってもらうのは無茶ですし、1.1.1がVS2008、2010、2012、2013に対応でさらに32bit版と64bit版が存在することを考えると現実的ではなさそうです。
まあ基本的には1で、何らかのツールを使う場合は2といったところでしょうかね？
どちらにしても何らかのライセンスなどの問題でもない限り、実行ファイルとソースコードのみを配布することはあり得ないと思います。
それにしてもRTMコンテストのプロジェクトページのコメント欄ってソースコードの話ばっかりだけど、動作できたできなかったの話はしないのだろうか？
おそらくですけど今年も去年と同じく何かしらの機器を使う作品が多くなると思うので、なかなかそういうコメントは付かないかもしれないです。
まあでもDLLが不足していて動作できないというのは何人にも当てはまる問題なので、メーリングリストとかで議論するべき事だとは思います。
ひょっとしたらマネージャの機能を使った作品が出るかもしれません。
何故かというと今のところ一部の人しかマネージャを有効に使えていない事と、マネージャを有効活用したツールがここ数年応募されていない事からなので確信があるわけではないです。
ただ去年は実行コンテキストが出ると言ったら当たったので今回も当たるかもしれないです。
そういえば奨励賞の一部が公開されているみたいですが、再チャレンジ賞以外は以前と同じですね。しかもその賞も5年前に受賞資格を失っています。
他の人の作品にコメントをたくさん投稿した人に賞があったら面白いかなとは思っています。今のままでは全体的にコメントが少なすぎです。僕は金がないので、誰か個人賞を出してください。
それはさておき、例のツールにRTCをリストから選択して起動する機能を追加したのですが、最初からある程度RTCを同梱していないと不便だと思ったので同梱するRTCを選んでみました。
厳選の結果、77種類のRTCを同梱する事にしました。
当初の予定は30種類の予定だったのですが、何故か大幅に増えてしまいました。
どこが厳選したんだよと言われそうですが、他のRTCのテストのみに作成したRTCや動作確認が面倒だったRTCは除いているので、一応実用性のあるRTCが残っているはずです。
まあでも他のRTCのテストのためのRTCをいちいち作っていたのも何年も前の話で、Calc(Excel)のRTCで簡単にテストできるので最近ではサービスポートのテストぐらいでしか作っていません。そうでなくてもrtshellでテストできるのでそういうRTCを作る人もあまりいないのではないかと思います。
今のところ77個中72個の動作確認を完了しましたが、面倒な5個を残しているのでまだ時間がかかりそうです。
OpenRTM-aist-1.0.0の時に作ったRTCなのですが、当時のプログラミング能力が酷いせいでかなりいいかげんな実装をしているので色々と変更をしています。
正直なところ5個のうち4個は特に面倒なので諦めるかもしれないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
9割は動作できないというのは僕は動作できなかったという意味なので、動作できないのは僕の頑張りが足らないからと言われれば一理あるとは思いますが、動作確認するためだけにそんなに労力を割きたくありません。
公式で複数のバージョンのOpenRTM-aistのインストールを非推奨にしているにもかかわらず、必要なDLLを付属させず実行ファイルのみを配布するのは意図がよく分かりません。
ここでその事に関係しそうなことを議論しているようですが、まとめると以下の3通りの方法があると言っているみたいです。
- DLLを同梱する
- CMakeListsを書いてビルドしてもらう
- 複数のバージョンのOpenRTM-aistをインストールして環境変数をいじる
RTMユーザーにWindowsを使っている人が多いせいもあって、CMakeがあまり身近な存在ではありません。
ビルドする過程で何かしらのトラブルが起こる可能性は高いと思います。
この方法の最大の問題は各RTCでいちいちcmake-guiを起動してプロジェクトを生成→VisualStudioで開いてビルドをしなければならない点で、RTCの数が10個も20個にもなるとやる気をなくします。
一つのRTCのプロジェクト作成からビルド完了までに5分かかるとして、10個で50分ですか。しかも放置して50分ではないので相当な手間です。
この辺は何かしらのツールを使えば解決できるかもしれないので今後に期待です。
3は自分だけならそれでも良いのですけどRTCの配布先でやってもらうのは無茶ですし、1.1.1がVS2008、2010、2012、2013に対応でさらに32bit版と64bit版が存在することを考えると現実的ではなさそうです。
まあ基本的には1で、何らかのツールを使う場合は2といったところでしょうかね？
どちらにしても何らかのライセンスなどの問題でもない限り、実行ファイルとソースコードのみを配布することはあり得ないと思います。
それにしてもRTMコンテストのプロジェクトページのコメント欄ってソースコードの話ばっかりだけど、動作できたできなかったの話はしないのだろうか？
おそらくですけど今年も去年と同じく何かしらの機器を使う作品が多くなると思うので、なかなかそういうコメントは付かないかもしれないです。
まあでもDLLが不足していて動作できないというのは何人にも当てはまる問題なので、メーリングリストとかで議論するべき事だとは思います。
ひょっとしたらマネージャの機能を使った作品が出るかもしれません。
何故かというと今のところ一部の人しかマネージャを有効に使えていない事と、マネージャを有効活用したツールがここ数年応募されていない事からなので確信があるわけではないです。
ただ去年は実行コンテキストが出ると言ったら当たったので今回も当たるかもしれないです。
そういえば奨励賞の一部が公開されているみたいですが、再チャレンジ賞以外は以前と同じですね。しかもその賞も5年前に受賞資格を失っています。
他の人の作品にコメントをたくさん投稿した人に賞があったら面白いかなとは思っています。今のままでは全体的にコメントが少なすぎです。僕は金がないので、誰か個人賞を出してください。
それはさておき、例のツールにRTCをリストから選択して起動する機能を追加したのですが、最初からある程度RTCを同梱していないと不便だと思ったので同梱するRTCを選んでみました。
厳選の結果、77種類のRTCを同梱する事にしました。
当初の予定は30種類の予定だったのですが、何故か大幅に増えてしまいました。
どこが厳選したんだよと言われそうですが、他のRTCのテストのみに作成したRTCや動作確認が面倒だったRTCは除いているので、一応実用性のあるRTCが残っているはずです。
まあでも他のRTCのテストのためのRTCをいちいち作っていたのも何年も前の話で、Calc(Excel)のRTCで簡単にテストできるので最近ではサービスポートのテストぐらいでしか作っていません。そうでなくてもrtshellでテストできるのでそういうRTCを作る人もあまりいないのではないかと思います。
今のところ77個中72個の動作確認を完了しましたが、面倒な5個を残しているのでまだ時間がかかりそうです。
OpenRTM-aist-1.0.0の時に作ったRTCなのですが、当時のプログラミング能力が酷いせいでかなりいいかげんな実装をしているので色々と変更をしています。
正直なところ5個のうち4個は特に面倒なので諦めるかもしれないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ROSとRTMの比較に関しては他のサイトで既に論じられている事なので今更語るほどの事でもないとは思いますが、Twitterでopenrtmと検索したところROSの方がOpenRTM-aistより遥かに簡単と言われていたのでその原因を考えてみます。
まずROSのチュートリアルをやってみた場合、パッケージ作成あたりで少し引っかかるもののPublisherとSubscriberを実行しただけで通信を開始するので簡単なように思います。
OpenRTM-aistはRTCの起動後、さらにRTシステムエディタで接続、アクティブ化が必要なので少し面倒くさいかもしれないです。
ただ、それはあらかじめソースコード内でトピック名を同じにしておいた場合の話であって、トピック名が違った場合はそんなに手間が変わらないようにも思います。
それに接続やアクティブ化が面倒と言っても、現在開発中のツールを使えば一度RTシステムエディタで接続してしまえば後は簡単に起動できるので、あまり問題にはならないように思います。
それからRTCの仕様が複雑で分かりづらいというのはあると思います。
慣れれば簡単なのですが、アクションコールバックがどのタイミングで呼び出されるのか分からない、と言うよりも何でアクションコールバックに処理を書かなければならないのかが分からない、一見するとコードが長くて難しそうとか思うかもしれないです。
じゃあ使いこなせばOpenRTM-aistの方が便利なのかと言われれば、全くそんなことはないです。
単純にOpenRTM-aistとROS自体を比較した場合でROSの方が上と言う事はないと思います。
ただRTMはサードパーティーの作成したモジュールの9割方は人の環境で動作できません。
どうにも対応するOSが多いのが裏目に出ているようにも思います。
基本的に特定のOSにしか対応していないRTCが多いので、これで相当数のRTCは動作できない事になります。
数えたわけではないのではっきりはしないのですが、Windowsで動作するRTCが多いように思います。
そして実行ファイルを付属している場合が多いのですが、何故かRTCXXX.dll等の必要なDLLを付属していません。
それならこちらでビルドをすれば良いのですが、CMakeList.txtの書き方が全く浸透していないのでビルドできない事が多いです。
こうなる原因は公式サイトの情報が不足している事もあるかもしれないです。
サードパーティの人が他の環境で動作させようという意識が低いのも原因にあるかもしれないですが、動作できなくても誰も教えてくれないという熱意の低さもあるかもしれないです。
サードパーティの開発したRTCの動作できない原因はいくつかあると思いますが、難しい仕様を理解して自分でシステムを開発できるようになっても他の人のRTCで使えるものがほとんどないので結局RTMを使わない場合に比べて開発効率が上がることは少ないというのがRTMの現状だと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まずROSのチュートリアルをやってみた場合、パッケージ作成あたりで少し引っかかるもののPublisherとSubscriberを実行しただけで通信を開始するので簡単なように思います。
OpenRTM-aistはRTCの起動後、さらにRTシステムエディタで接続、アクティブ化が必要なので少し面倒くさいかもしれないです。
ただ、それはあらかじめソースコード内でトピック名を同じにしておいた場合の話であって、トピック名が違った場合はそんなに手間が変わらないようにも思います。
それに接続やアクティブ化が面倒と言っても、現在開発中のツールを使えば一度RTシステムエディタで接続してしまえば後は簡単に起動できるので、あまり問題にはならないように思います。
それからRTCの仕様が複雑で分かりづらいというのはあると思います。
慣れれば簡単なのですが、アクションコールバックがどのタイミングで呼び出されるのか分からない、と言うよりも何でアクションコールバックに処理を書かなければならないのかが分からない、一見するとコードが長くて難しそうとか思うかもしれないです。
じゃあ使いこなせばOpenRTM-aistの方が便利なのかと言われれば、全くそんなことはないです。
単純にOpenRTM-aistとROS自体を比較した場合でROSの方が上と言う事はないと思います。
ただRTMはサードパーティーの作成したモジュールの9割方は人の環境で動作できません。
どうにも対応するOSが多いのが裏目に出ているようにも思います。
基本的に特定のOSにしか対応していないRTCが多いので、これで相当数のRTCは動作できない事になります。
数えたわけではないのではっきりはしないのですが、Windowsで動作するRTCが多いように思います。
そして実行ファイルを付属している場合が多いのですが、何故かRTCXXX.dll等の必要なDLLを付属していません。
それならこちらでビルドをすれば良いのですが、CMakeList.txtの書き方が全く浸透していないのでビルドできない事が多いです。
こうなる原因は公式サイトの情報が不足している事もあるかもしれないです。
サードパーティの人が他の環境で動作させようという意識が低いのも原因にあるかもしれないですが、動作できなくても誰も教えてくれないという熱意の低さもあるかもしれないです。
サードパーティの開発したRTCの動作できない原因はいくつかあると思いますが、難しい仕様を理解して自分でシステムを開発できるようになっても他の人のRTCで使えるものがほとんどないので結局RTMを使わない場合に比べて開発効率が上がることは少ないというのがRTMの現状だと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
