ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
とうとう締切日を迎えてしまいました。
予想はしていましたが、思った以上に僕の作品の評価は低いようです。
ここまで低いのは少し予想外です。
今日は以下の作品が投稿されています。
1の作品はなかなか面白いと思いました。今まで投稿された作品の中では一番興味あるかもしれないです。残念ながらKinectは持っていないので試用できませんが。
とりあえずソースコードを読んで思ったことは、ヘッダーファイルに何もかも書いてしまっているのでコンパイルに時間がかかって大変ではないだろうかとは思いました。別に動作には影響ないですけど。あとKinect_PointingMain.hのconv3Dto2D関数ですが、現状ではX、Y、Z軸と垂直な平面しか扱えませんね。平面上の座標系から有顔ベクトルと副顔ベクトルを求めて、そこから[[1 0 0], [0 0 1]]に変換するための回転変換行列を算出→回転変換行列の逆行列と交差点の内積を計算すれば算出できるかなあと思いましたが、さすがに相当面倒なのでコメントに書いてその作業を強いるのはやめておきます。それから設定する平面は地面か壁面しか設定できず、壁面の場合は4つの平面を設定してその4つ全ての壁面に関して交差判定を行って一番近い平面を選択するようにしています。なんだかスマートなやり方ではないなあと思いました。法線方向も指の方向で決めたら良かったのではないかなあと思ったりもします。というかソースコード読んだ感じですが、検出してるのって指の方向ではなくて腕の方向のように見えるのですが。
2の作品は今のところわからないので後で感想を書きます。
実は言わなかったのですが3の作品みたいにLeapMotionを使った作品が出るのではないかと思っていました。僕でも思いつくのですから他の誰かがやってもおかしくはないです。それにしてもやけにファイルが重いなあと思っていたら、VC++のプロジェクトのsdfファイル等が丸々入っています。少し雑だなあと思いました。1の作品にしてもそうですけど、こういう系のソフトウェアは動作例をどれだけ面白くするかが重要な感じがします。
4の作品はまた変な所に目を付けたなあって感じです。内容がわかってから感想を書きます。
5の作品も後で感想を書きます。まだ内容がわかりません。
6の作品は・・・正直こういう系の作品はどう評価していいのかがわかりません。
HOTMOCKも当然持っていませんから。ソースコードを読んでみた感じではdynamic_port.hppが技術的にもかなり高度で参考になりました。
7の作品の人は去年も似たような作品を投稿してたと思います。感想は明日書きます。
ORiNのRTCは凄い評価が高いみたいです。
僕も一応気になるところを指摘しつつ褒めるようなコメントを書きましたけど、思っていた以上に評価が高いですね。プロジェクトページのコメント欄に具体的にどこを評価したのか等を書けば作者様も喜ぶと思うので、ぜひそうしてください。
よくよく考えてみたらKobukiのRTCがSLAMやっているみたいなので、「SLAM関連の作品も必ず投稿される」という予想は当たっていました。予想が全て当たるとは思いませんでした。つまり僕の予想を超えてくるような作品が最優秀賞を取るという事かもしれません。
RSNPのRTCのマニュアル、ソースコードを読んでいるのですが・・・・あまり言うことがないなあ。とりあえずソフトウェアの完成度は高いです。それだけに何も言うことがないです。Human_Trackingのプログラムがこちらでビルド出来るようにCMakeファイルやプロジェクトファイルを付属させていないことが若干不満ですが、実行ファイルが付属しているので普通に使う分にはほとんど困ることなさそうです。素直に絶賛するコメントを書いたら良いのですけど、LRFを持っていなくて動作確認できたわけでもないので少し困りました。動画の人が何で室内で帽子を被っているのかぐらいしか疑問に思ったことがありません。あえて言うならLRFで検知しているので、人の後ろにもう一人誰かいたらカウントできないとか思いましたけど、そんなの当たり前なので別にコメントする程の事でもないです。count_dataはTimedLongSeq型ですが、TimedLong型3つの方が汎用性があるかなあとは思いましたけど大して変るものでもないですし。
大した問題ではないですけどHumanのdistanceとかの配列の数が100になっていますが、Human_Tracking.cppでmax_particlesを100と宣言しているのでHuman_Tracking.hでmax_particlesを宣言してdistance[max_particles]とした方がmax_particlesを変更した場合でも安全なのでは？とは思いましたがこちらでビルドするようになっていないので関係なさそうです。
あと、m_humanX.data[i] = m_qHuman->human[i+1].y2[1]とm_humanY.data[i] = m_qHuman->human[i+1].x2[1]みたいにX座標とY座標を逆に出力しているように見えるのですが意図がよくわかりません。ほとんど想像になるのですが、変数x2[1]、y2[1]が更新前の人の位置だと思うのですが、TARGET_TRACKINGでx[1]、y[2]との距離を計算後、m_qHuman->human[t].x2[1]=m_qHuman->human[sti].x[1]+1としているので、つまりマッチングの前はx、yとx2、y2が対応しているかどうかはわかっていないのではないかと思います。実際はm_qHuman->human[0]のx2、y2がm_qHuman->human[1]のx、yに更新されることもあるように見えます。となると同じ構造体に値を格納するとソースコードの見通しが悪くなるのでは？と思いましたが、本当にそういう動作をするのか確信がありません。言うことがあったとしても細かい部分になるのでコメントする程でもないような気がします。
まだ最低でも4作品以上がまだ投稿されていないようですが、優勝予想をします。
視覚脳科学研究を目的としたRTミドルウェアの応用と結果が優勝本命だと思っていたのですが、ORiNとの連携(以下略)の評価が考えていた以上に高いようなのでわからなくなってきました。
RTMによるカメラマンロボットの動作確実性の向上とメディアアートコミュニティ実現に向けた RTコンポーネントの開発と提案も評価は高そうです。個人的にはユーザによる指差し指示の為のコンポーネントが面白いとは思います。
悩みましたが、昨日の予想した通り視覚脳科学研究を目的としたRTミドルウェアの応用と結果が最優秀になるのではないかと個人的には思います。
なんかこんなこと言っていると「お前は最優秀賞を取る気がないのか？」とか言われそうですが、最初に言った通り想像以上の評価の低さに愕然としたのでどうにもやる気は起きません。
コンセプトの段階から間違っていたのかもしれないです。
唐突ですが、以前C++で作成したcoilを使うプログラムのPython版を作成しました。
ここからダウンロードできます。
やったこと自体は以前の記事の内容と同じなので説明は省略します。
気になったと言えばuuidの関数の使い方がC++と少し違うかな？ぐらいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
予想はしていましたが、思った以上に僕の作品の評価は低いようです。
ここまで低いのは少し予想外です。
今日は以下の作品が投稿されています。
- ユーザによる指差し指示の為のコンポーネント
- 複数台の移動ロボットを対象とした経路計画法の検証用RTC
- LeapMotionを用いたロボットマニピュレータの操作支援コンポーネント
- ロボットとインタラクションを行うためのつま先の位置推定コンポーネント
- HMDを用いたPTカメラの遠隔操作
- メディアアートコミュニティ実現に向けた RTコンポーネントの開発と提案
- Webコンテンツ配信コンポーネント群
1の作品はなかなか面白いと思いました。今まで投稿された作品の中では一番興味あるかもしれないです。残念ながらKinectは持っていないので試用できませんが。
とりあえずソースコードを読んで思ったことは、ヘッダーファイルに何もかも書いてしまっているのでコンパイルに時間がかかって大変ではないだろうかとは思いました。別に動作には影響ないですけど。あとKinect_PointingMain.hのconv3Dto2D関数ですが、現状ではX、Y、Z軸と垂直な平面しか扱えませんね。平面上の座標系から有顔ベクトルと副顔ベクトルを求めて、そこから[[1 0 0], [0 0 1]]に変換するための回転変換行列を算出→回転変換行列の逆行列と交差点の内積を計算すれば算出できるかなあと思いましたが、さすがに相当面倒なのでコメントに書いてその作業を強いるのはやめておきます。それから設定する平面は地面か壁面しか設定できず、壁面の場合は4つの平面を設定してその4つ全ての壁面に関して交差判定を行って一番近い平面を選択するようにしています。なんだかスマートなやり方ではないなあと思いました。法線方向も指の方向で決めたら良かったのではないかなあと思ったりもします。というかソースコード読んだ感じですが、検出してるのって指の方向ではなくて腕の方向のように見えるのですが。
2の作品は今のところわからないので後で感想を書きます。
実は言わなかったのですが3の作品みたいにLeapMotionを使った作品が出るのではないかと思っていました。僕でも思いつくのですから他の誰かがやってもおかしくはないです。それにしてもやけにファイルが重いなあと思っていたら、VC++のプロジェクトのsdfファイル等が丸々入っています。少し雑だなあと思いました。1の作品にしてもそうですけど、こういう系のソフトウェアは動作例をどれだけ面白くするかが重要な感じがします。
4の作品はまた変な所に目を付けたなあって感じです。内容がわかってから感想を書きます。
5の作品も後で感想を書きます。まだ内容がわかりません。
6の作品は・・・正直こういう系の作品はどう評価していいのかがわかりません。
HOTMOCKも当然持っていませんから。ソースコードを読んでみた感じではdynamic_port.hppが技術的にもかなり高度で参考になりました。
7の作品の人は去年も似たような作品を投稿してたと思います。感想は明日書きます。
ORiNのRTCは凄い評価が高いみたいです。
僕も一応気になるところを指摘しつつ褒めるようなコメントを書きましたけど、思っていた以上に評価が高いですね。プロジェクトページのコメント欄に具体的にどこを評価したのか等を書けば作者様も喜ぶと思うので、ぜひそうしてください。
よくよく考えてみたらKobukiのRTCがSLAMやっているみたいなので、「SLAM関連の作品も必ず投稿される」という予想は当たっていました。予想が全て当たるとは思いませんでした。つまり僕の予想を超えてくるような作品が最優秀賞を取るという事かもしれません。
RSNPのRTCのマニュアル、ソースコードを読んでいるのですが・・・・あまり言うことがないなあ。とりあえずソフトウェアの完成度は高いです。それだけに何も言うことがないです。Human_Trackingのプログラムがこちらでビルド出来るようにCMakeファイルやプロジェクトファイルを付属させていないことが若干不満ですが、実行ファイルが付属しているので普通に使う分にはほとんど困ることなさそうです。素直に絶賛するコメントを書いたら良いのですけど、LRFを持っていなくて動作確認できたわけでもないので少し困りました。動画の人が何で室内で帽子を被っているのかぐらいしか疑問に思ったことがありません。あえて言うならLRFで検知しているので、人の後ろにもう一人誰かいたらカウントできないとか思いましたけど、そんなの当たり前なので別にコメントする程の事でもないです。count_dataはTimedLongSeq型ですが、TimedLong型3つの方が汎用性があるかなあとは思いましたけど大して変るものでもないですし。
大した問題ではないですけどHumanのdistanceとかの配列の数が100になっていますが、Human_Tracking.cppでmax_particlesを100と宣言しているのでHuman_Tracking.hでmax_particlesを宣言してdistance[max_particles]とした方がmax_particlesを変更した場合でも安全なのでは？とは思いましたがこちらでビルドするようになっていないので関係なさそうです。
あと、m_humanX.data[i] = m_qHuman->human[i+1].y2[1]とm_humanY.data[i] = m_qHuman->human[i+1].x2[1]みたいにX座標とY座標を逆に出力しているように見えるのですが意図がよくわかりません。ほとんど想像になるのですが、変数x2[1]、y2[1]が更新前の人の位置だと思うのですが、TARGET_TRACKINGでx[1]、y[2]との距離を計算後、m_qHuman->human[t].x2[1]=m_qHuman->human[sti].x[1]+1としているので、つまりマッチングの前はx、yとx2、y2が対応しているかどうかはわかっていないのではないかと思います。実際はm_qHuman->human[0]のx2、y2がm_qHuman->human[1]のx、yに更新されることもあるように見えます。となると同じ構造体に値を格納するとソースコードの見通しが悪くなるのでは？と思いましたが、本当にそういう動作をするのか確信がありません。言うことがあったとしても細かい部分になるのでコメントする程でもないような気がします。
まだ最低でも4作品以上がまだ投稿されていないようですが、優勝予想をします。
視覚脳科学研究を目的としたRTミドルウェアの応用と結果が優勝本命だと思っていたのですが、ORiNとの連携(以下略)の評価が考えていた以上に高いようなのでわからなくなってきました。
RTMによるカメラマンロボットの動作確実性の向上とメディアアートコミュニティ実現に向けた RTコンポーネントの開発と提案も評価は高そうです。個人的にはユーザによる指差し指示の為のコンポーネントが面白いとは思います。
悩みましたが、昨日の予想した通り視覚脳科学研究を目的としたRTミドルウェアの応用と結果が最優秀になるのではないかと個人的には思います。
なんかこんなこと言っていると「お前は最優秀賞を取る気がないのか？」とか言われそうですが、最初に言った通り想像以上の評価の低さに愕然としたのでどうにもやる気は起きません。
コンセプトの段階から間違っていたのかもしれないです。
唐突ですが、以前C++で作成したcoilを使うプログラムのPython版を作成しました。
ここからダウンロードできます。
やったこと自体は以前の記事の内容と同じなので説明は省略します。
気になったと言えばuuidの関数の使い方がC++と少し違うかな？ぐらいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする
