本末転倒

RTCやRTSystemを配布するためのツールで、そのツール自体のインストールや使用が難しかったら本末転倒だと思います。
と言うより理想としては、配布先でネームサービスさえ起動できれば動作できた方が良いぐらいだと思います。できればcmakeやrtshellとかもインストールしたくありません。
ツールでパッケージは作成するけど、作成したパッケージを動作させるのにツールは必要ないという風にできればいいのですけど。



この前OpenRTM-aistはROSより難しいかもしれないと言いましたが、難しいと思うのであれば自分でコードを書かなければ良いと思うのですよね。
要はブロックを並べてポートを接続するだけでシステムを開発できるようになっているので、既存のRTCを使ってシステムを作れば良いじゃないですか。
まあ、その既存のRTCがなかなか動作できないので負のスパイラルに嵌っているのですけど。


ソースコード、実行ファイルのみで配布するのであれば、Pythonで実装した方が動作できる可能性も高いのじゃないかなあ。ソースコードだけの配布で大丈夫なわけですからね。もちろんこちら側でOpenRTM-aistのPython版をインストールしておく必要がありますけど、どのバージョンをインストールしていても動作はできるとは思います。


そういえば来週はサマーキャンプがあるとからしいですね。
行ったことないのでよく分かりませんけどなかなか面白そうな講義もあるので、後でスライドが公開されるようなら読みます。

個人的には、最優秀賞を取るという意味ではRTMコンテストに必勝法なんてないと思っています。
マニュアルを書く、期日までにソースコードを公開するなんてのは最低条件です。
ソースコードを読まれてしまう以上は最終的には実力だと思います。
当日の発表が悪くても内容さえ良ければ最優秀賞は取れます。


ただそれは最優秀賞の話であって、他の奨励賞だったら対策を取る意味はあります。
あまり言ってはいけないのかもしれませんが、去年のコンテストのドローンの作品は複数の賞を取りましたけど、僕がソースコード、マニュアルを読んだ印象はあまりよくありませんでした。
むしろ、マニュアルは読みづらい、独自のデータ型を使う意味が分からない、コメントを1週間放置した挙句質問には答えないとかで悪い印象の方が強かったように思います。
ソースコードもほとんど人のライブラリに依存していて自分で実装した部分は数百行程度だったのであまり頑張っているようには見えなかったのも印象を悪くしたかもしれません。
別に沢山コードを書けば良いという事ではありませんけど、人のライブラリを使って何の工夫もなく単純にRTCに実装しただけでは少し印象が悪いです。
ではなぜ賞が取れたのか？
正直なところ僕には分からないので、サマーキャンプで講師の人に訊いてください。
この作品にRTMコンテスト必勝法の鍵があると思います。



逆にこの作品はソースコード読んだ感じでは完成度高くて好印象だったのですが、何も賞を取れませんでした。過去の作品と微妙に被っていると言うのもあったのでしょうけど、マニュアルがないのが致命的だったかもしれません。と言うより、この人の研究室って誰もマニュアル書いてません。



以前の作品と被らない事は確かに重要だと思います。
個人的にはもう少しRTMの機能を生かしたツールが出てほしいなと思います。
マスターマネージャ、スレーブマネージャ機能とか上手く使いこなせている人はほとんどいないと思うので、ツールを作る余地はありそうです。










今週中に73種類のRTCを配布すると言いましたが、無理そうなので来週中にします。
以前作成したRTCの修正に思ったより手こずっている状況です。
ちょっと見込みが甘かったかもしれないです。
それ以外にもツール本体の修正もやったので、それで多少予定が狂った感じもあります。

配布予定のRTCの大半にはマニュアルがありません。
ツールでRTCの情報を読めるので、それがマニュアルの替わりです。













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