ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
前回の記事を書いてから5時間の間に以下の作品が投稿されたようです。
滑り込みで間に合ったようですね。またKinectですか。だから持っていないっていってるのに。
仕方ないのでまたソースコードを読む作業です。感想は後で書きます。
2の作品はかなり頑張っているみたいなので優勝争いに絡んできそうです。
今マニュアルを読んでいるのですが、今一内容が理解できてません。
こんなにデータポートを作る必要あったのかなと思います。
とにかく僕の環境で動作確認できそうな数少ない作品の内の一つなので、何とか動かすところまで持っていけるように頑張ります。余程焦っていたのかログファイルが残ってしまっています。
動作確認用の画像ファイルはどこにあるのでしょうか？
自分で用意しろということなのでしょうかね。
CMakeしてビルドしようとしたのですが、物凄い数のエラーが出ます。
意味不明なエラーの内容なので多分文字コードだろなあと思ったら案の定でした。
マニュアルを見ると著者が5人もいるということは5回は動作確認ができているはずなのに、これはまずい事態だと思います。
そもそも10個以上のRTCをこちらでビルドしろというのが無茶ですし、僕みたいな小物が偉そうなことを言ってしまうようですが人に使ってもらおうという意思が感じられません。
ちょっと言い過ぎました。ごめんなさい。
内容は充実してそうなだけにもったいないなと思いました。
そういえば今日は作品投稿のメールがたくさん来ましたが、同じ研究室なら一緒に送れば良かったのでは？と思いました。面倒だろうし。
今年は何らかの機器を使った作品が多くなると予想していましたが、見た感じ18作品中14作品が何らかの機器を必須にしているようです。
実のところまだ1作品しか動作確認できてません。
Kinect買ってこようかな。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
滑り込みで間に合ったようですね。またKinectですか。だから持っていないっていってるのに。
仕方ないのでまたソースコードを読む作業です。感想は後で書きます。
2の作品はかなり頑張っているみたいなので優勝争いに絡んできそうです。
今マニュアルを読んでいるのですが、今一内容が理解できてません。
こんなにデータポートを作る必要あったのかなと思います。
とにかく僕の環境で動作確認できそうな数少ない作品の内の一つなので、何とか動かすところまで持っていけるように頑張ります。余程焦っていたのかログファイルが残ってしまっています。
動作確認用の画像ファイルはどこにあるのでしょうか？
自分で用意しろということなのでしょうかね。
CMakeしてビルドしようとしたのですが、物凄い数のエラーが出ます。
意味不明なエラーの内容なので多分文字コードだろなあと思ったら案の定でした。
マニュアルを見ると著者が5人もいるということは5回は動作確認ができているはずなのに、これはまずい事態だと思います。
そもそも10個以上のRTCをこちらでビルドしろというのが無茶ですし、僕みたいな小物が偉そうなことを言ってしまうようですが人に使ってもらおうという意思が感じられません。
ちょっと言い過ぎました。ごめんなさい。
内容は充実してそうなだけにもったいないなと思いました。
そういえば今日は作品投稿のメールがたくさん来ましたが、同じ研究室なら一緒に送れば良かったのでは？と思いました。面倒だろうし。
今年は何らかの機器を使った作品が多くなると予想していましたが、見た感じ18作品中14作品が何らかの機器を必須にしているようです。
実のところまだ1作品しか動作確認できてません。
Kinect買ってこようかな。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
とうとう締切日を迎えてしまいました。
予想はしていましたが、思った以上に僕の作品の評価は低いようです。
ここまで低いのは少し予想外です。
今日は以下の作品が投稿されています。
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++と少し違うかな？ぐらいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
実は昨日、メーリングリストで作品の宣伝をしてしまいました。
メーリングリストでこういう手前味噌な事をするのは嫌いなのですが、事務局の方からやれと指示があったので心の中で他の人に謝りながらメールを送りました。多分気にする人もいると思うので。そのおかげで30回ぐらいはアクセスがあったみたいです。使ってもらっているかどうかは別として。
いよいよ明日締め切りです。
今日は2作品が投稿されています。ロボットサービスイニシアチブ(RSi)賞はRSNPライブラリを使用した作品に贈られるらしいので、1の作品はおそらく受賞確実ですね。まだ内容はよくわからないですけど。
2の作品はMIDIを扱ったことがないのでよくわかりません。ソースコードがアップロードされてから感想は書きます。
今の段階でプロジェクトページの作成、ソースコードの公開をしているのは4作品、プロジェクトページのみの公開は5作品で、最低20人以上の参加者がいるはずなので明日大量に投稿、更新されることにはなります。
どう考えても何人かはプロジェクトページのみを作成してマニュアル、ソースコードの公開ができない、もしくはプロジェクトページ自体未作成の状態になりそうです。やはり締め切りが早すぎたようです。
今年は産総研の方は作品を投稿しないのでしょうか？
毎年かなり高いクオリティの作品を出してくるので楽しみだったのですが。
今投稿されている作品の中では視覚脳科学研究を目的としたRTミドルウェアの応用と結果が技術的にも評価が高そうなので優勝本命になりそうです。
あとORiNとの連携(以下略)がかなり力を入れているみたいなので対抗になるかもしれません。ちょっと名前長すぎですよね。
そう言えばORiNのRTCのプロジェクトページのいいねの数が11回になっていたので、いきなり抜かれてしまいました。わずか6日で50日の差をひっくり返してダブルスコアまで差を広げるとか思った以上の決定的な差があるみたいです。ある程度予想はしていましたが現実を見せつけられると精神的ダメージは大きいです。
明日凄い作品が投稿されるかもしれないので、また明日予想します。
プロジェクトページに目次を作っている人が何人かいますが、大体の人はちょっとスクロールするだけで全体が見渡せると思うので余程長くない限り必要はないと思います。プロジェクトページに使用方法まで書いてある場合は必要かもしれませんね。
以前Pythonで書いた実行コンテキストのコールバック、コンポーネントアクションの前後のコールバック、コンフィギュレーションコールバック、動的なRTCの起動のプログラムのC++版を作成しました。サンプルプログラムはここからダウンロードできます。
addExecutionContextActionListener、addPostComponentActionListener、addPreComponentActionListenerの引数がPython版と違うようです。
Python版は第2引数に関数を入れていたのですが、C++版はRTC::ExecutionContextActionListener、RTC::PostComponentActionListener、RTC::PreComponentActionListenerを継承したクラスを入れなければなりません。
というか、なんでPython版の上述の関数だけ引数が違うのでしょうね？
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
メーリングリストでこういう手前味噌な事をするのは嫌いなのですが、事務局の方からやれと指示があったので心の中で他の人に謝りながらメールを送りました。多分気にする人もいると思うので。そのおかげで30回ぐらいはアクセスがあったみたいです。使ってもらっているかどうかは別として。
いよいよ明日締め切りです。
今日は2作品が投稿されています。ロボットサービスイニシアチブ(RSi)賞はRSNPライブラリを使用した作品に贈られるらしいので、1の作品はおそらく受賞確実ですね。まだ内容はよくわからないですけど。
2の作品はMIDIを扱ったことがないのでよくわかりません。ソースコードがアップロードされてから感想は書きます。
今の段階でプロジェクトページの作成、ソースコードの公開をしているのは4作品、プロジェクトページのみの公開は5作品で、最低20人以上の参加者がいるはずなので明日大量に投稿、更新されることにはなります。
どう考えても何人かはプロジェクトページのみを作成してマニュアル、ソースコードの公開ができない、もしくはプロジェクトページ自体未作成の状態になりそうです。やはり締め切りが早すぎたようです。
今年は産総研の方は作品を投稿しないのでしょうか？
毎年かなり高いクオリティの作品を出してくるので楽しみだったのですが。
今投稿されている作品の中では視覚脳科学研究を目的としたRTミドルウェアの応用と結果が技術的にも評価が高そうなので優勝本命になりそうです。
あとORiNとの連携(以下略)がかなり力を入れているみたいなので対抗になるかもしれません。ちょっと名前長すぎですよね。
そう言えばORiNのRTCのプロジェクトページのいいねの数が11回になっていたので、いきなり抜かれてしまいました。わずか6日で50日の差をひっくり返してダブルスコアまで差を広げるとか思った以上の決定的な差があるみたいです。ある程度予想はしていましたが現実を見せつけられると精神的ダメージは大きいです。
明日凄い作品が投稿されるかもしれないので、また明日予想します。
プロジェクトページに目次を作っている人が何人かいますが、大体の人はちょっとスクロールするだけで全体が見渡せると思うので余程長くない限り必要はないと思います。プロジェクトページに使用方法まで書いてある場合は必要かもしれませんね。
以前Pythonで書いた実行コンテキストのコールバック、コンポーネントアクションの前後のコールバック、コンフィギュレーションコールバック、動的なRTCの起動のプログラムのC++版を作成しました。サンプルプログラムはここからダウンロードできます。
addExecutionContextActionListener、addPostComponentActionListener、addPreComponentActionListenerの引数がPython版と違うようです。
Python版は第2引数に関数を入れていたのですが、C++版はRTC::ExecutionContextActionListener、RTC::PostComponentActionListener、RTC::PreComponentActionListenerを継承したクラスを入れなければなりません。
というか、なんでPython版の上述の関数だけ引数が違うのでしょうね？
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
RTMコンテストの作品一覧のページの載っている順序ですが、よく見ると投稿日の順序にはなっていません。おそらくアクセス数で並び替えている物と思われます。
僕は50日ぐらい早く投稿したのでその貯金で一番目に来ていると思います。
一日平均8回ぐらいだと思うので、50日だと400回ぐらいアクセスがあったことになります。
なんかこの作品が毎日のように100人以上来てるのですけど、このペースではすぐに抜かれてしまいます。というか、何をすればこんなアクセス数になるのでしょうね？
今日は1つ作品が投稿されました。
RTMによるカメラマンロボットの動作確実性の向上
半数以上の人がプロジェクトページの名称に～の実装とか～の結果とか付けてますけど、前にも言った通り付けないでくれと公式サイトに書いてあります。
それはさておき、やはりカメラを使った作品は多いです。
何故今年は何らかの機器を使った作品が多くなると予想したかというと、RTMコンテストも8回目ともなると市販の製品を使う等ピンポイントなものでないとアイデアがなかなか出てこないからです。画像処理関連にしてもそうで「このアルゴリズムを使う」みたいなピンポイントでないとなかなかアイデアを出すのは難しいと思います。
まだ詳しくわからない作品もありますが、現在投稿されている7作品の中で5作品はそのピンポイントのアイデアだと思います。
ただ、今までの傾向として最優秀賞を取るにはピンポイントの作品は少し不利な感じがします。僕は論外なので有利になっても関係ないですけど。
それにしても、明後日が締め切りなのに動きが少し鈍いですね。
まあ遅れても減点されるだけで発表できなくなるわけではないのですが、最優秀賞が絶望的にはなるのでしょうね。おそらくですが。
多分ですけど運営しているサイドの方の考えとしては「10月31日までにプロジェクトページ、詳細なマニュアル、完成したソースコードを公開してほしい」ということだと思うので、ソースコードとマニュアルが公開されてなかったら減点かもしれませんね。あくまで僕の想像ですけど。
今回は書くことがないのでcoilを使っていろいろやってみます。
まずcoil(Common Operating-system Infrastructure Layer)とはOpenRTM-aist-1.0.0から導入されたスレッドやタイマー機能を抽象化したライブラリです。このことによりOSが違ってもcoilでサポートしている機能ならば同じコードで書くことができます。
0.4.2の時はACEというライブラリを使用してました。
今回のサンプルプログラムはここからダウンロードできます。
以下のヘッダーファイルで定義されたクラス、関数を使ってみました。
まずUUIDとは他と重複しない識別子のことです。
UUIDを生成するためには
としてください。
あとstringutil.hで文字の分割とか置き換え等の関数も宣言されているのですが、今投稿している作品でこういう関数を自作してしまったので今少し後悔しています。まあ別に数十行のコードなのですが、何か損した気分です。
いろいろな機能をサポートしているみたいなので、RTCのプログラミングをするときは積極的に使ってください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
僕は50日ぐらい早く投稿したのでその貯金で一番目に来ていると思います。
一日平均8回ぐらいだと思うので、50日だと400回ぐらいアクセスがあったことになります。
なんかこの作品が毎日のように100人以上来てるのですけど、このペースではすぐに抜かれてしまいます。というか、何をすればこんなアクセス数になるのでしょうね？
今日は1つ作品が投稿されました。
RTMによるカメラマンロボットの動作確実性の向上
半数以上の人がプロジェクトページの名称に～の実装とか～の結果とか付けてますけど、前にも言った通り付けないでくれと公式サイトに書いてあります。
それはさておき、やはりカメラを使った作品は多いです。
何故今年は何らかの機器を使った作品が多くなると予想したかというと、RTMコンテストも8回目ともなると市販の製品を使う等ピンポイントなものでないとアイデアがなかなか出てこないからです。画像処理関連にしてもそうで「このアルゴリズムを使う」みたいなピンポイントでないとなかなかアイデアを出すのは難しいと思います。
まだ詳しくわからない作品もありますが、現在投稿されている7作品の中で5作品はそのピンポイントのアイデアだと思います。
ただ、今までの傾向として最優秀賞を取るにはピンポイントの作品は少し不利な感じがします。僕は論外なので有利になっても関係ないですけど。
それにしても、明後日が締め切りなのに動きが少し鈍いですね。
まあ遅れても減点されるだけで発表できなくなるわけではないのですが、最優秀賞が絶望的にはなるのでしょうね。おそらくですが。
多分ですけど運営しているサイドの方の考えとしては「10月31日までにプロジェクトページ、詳細なマニュアル、完成したソースコードを公開してほしい」ということだと思うので、ソースコードとマニュアルが公開されてなかったら減点かもしれませんね。あくまで僕の想像ですけど。
今回は書くことがないのでcoilを使っていろいろやってみます。
まずcoil(Common Operating-system Infrastructure Layer)とはOpenRTM-aist-1.0.0から導入されたスレッドやタイマー機能を抽象化したライブラリです。このことによりOSが違ってもcoilでサポートしている機能ならば同じコードで書くことができます。
0.4.2の時はACEというライブラリを使用してました。
今回のサンプルプログラムはここからダウンロードできます。
以下のヘッダーファイルで定義されたクラス、関数を使ってみました。
coil/UUID.h
coil/stringutil.h
coil/OS.h
coil/Process.h
coil/File.h
coil/DynamicLib.h
使用した機能が多いので気になったものだけ説明します。まずUUIDとは他と重複しない識別子のことです。
UUIDを生成するためには
coil::UUID_Generator *m_uuid = new coil::UUID_Generator();
coil::UUID* m_generateUUID = m_uuid->generateUUID(0, 0);
std::string m_uuidstr = m_generateUUID->to_string();としてください。
あとstringutil.hで文字の分割とか置き換え等の関数も宣言されているのですが、今投稿している作品でこういう関数を自作してしまったので今少し後悔しています。まあ別に数十行のコードなのですが、何か損した気分です。
いろいろな機能をサポートしているみたいなので、RTCのプログラミングをするときは積極的に使ってください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
先に断っておきます。
今回は「このRTCの実装方法は少しおかしいんじゃないの？」と取られかねないような発言をしていますが、自分の考えと違うと書いてあるだけで別に自分の方が正しいとは全く思っていません。
また新たに作品が投稿されました。
コサイン類似度を用いた日常動作認識のためのテンプレート作成および動作認識RTC
無知なのでコサイン類似度が何かわからず調べてしまいました。
なんでも文書の類似性を計算する方法らしいです。
簡単な方法としては単語の出現頻度で計算する方法もありますが、TF-IDFという単語の出現頻度、重要度の計算式を使用する方法もあるみたいです。このサイトがわかりやすいですね。
そういえば8月に今年の作品の傾向を予想したと思ったのですが、その記事が何故かどこにもありませんね。
確かこんな予想だったはずです。
まさかこんなにズバズバ当たるとは思いませんでした。
11月になったら優勝予想でもしてみようかな？
多分当たると思います。
昨日投稿されたAR.Droneの作品ですが、ここにあるソースコードを利用しているみたいです。
なんかリンク先のユーザー名をどこかで見たなと思ったら、AR.Droneの関数を調べていたときに見つけたサイトの人と同じでした。AR.Droneのプログラミングに関する情報が多くのっていて参考になりました。と言うか僕は何でAR.Droneも持っていないのにこんなことを調べているのか自分で疑問です。というか別の人が作ったコードを使い回しているなら別にその部分は解析しなくてもいいかもしれないです。今のところ関係はわかりませんが。
RTCを作る時に以下の3つのルールを勝手に自分に課しています。
というより1、2は間違いと言う可能性大ですね。
なぜ独自のデータ型を使わないかと言うと、既存のRTCと接続できなくなるのが気に食わないからです。こちらで作成したIDLファイルを使わなければならないわけで、それが面倒なのも何か押しつけがましいです。
どうしても必要な時はサービスポートを使います。
ただそれも以下の状況の場合だけです。
念のために言っておきますが、人の作成したIDLファイルで定義したインターフェースは利用します。ただ自作のIDLファイルは極力使わないようにしてます。自分で作ったIDLファイルを使ってもらえるとは思っていないので。
コンポーネントのコードとロジックのコードを分けるのは、ソースコードの再利用性のためです。まあ、そうすれば多少はソースコードが見やすくなるかもしれません。
AR.Droneの作品で独自のデータ型を2つ使っていますが、既存のRTCと接続できることを捨ててまでそうする理由は何かと考えてみます。TimedControldata型はTimedVector3D型とTimedDouble型とTimedBoolean型、TimedNavdata型はCameraImage型とTimedOrientation3D型とTimedVector3D型とTimedDouble型とTimedBoolean型とTimedShort型に分割した場合を考えると、確かにデータポートがやたら多くて接続が面倒ですし通信の同期が取りづらいという欠点はありますね。どちらが正しいかは難しい問題だと思います。まあコメントで聞いてみれば一発で解決するか。
何かこれ以上言ったら再利用厨とか言われるかもしれないのでそろそろやめておきます。
あとこちらの作品の共有メモリ通信のソースコードを読んでみた感想でも書きます。OnConnectedListenerはデータポートの接続時のコールバックだと思うのですが、この中でuseSharedMemoryという変数を接続先が違うPCの場合はFalseにしています。useSharedMemoryがTrueのままの場合は共有メモリ通信、Falseの場合は通常通信するみたいです。つまり一つでも違うPCで起動したRTCのデータポートと接続してしまうと同一PCで起動したRTCとの通信も共有メモリではなく通常の通信を行うようになるみたいです。コネクタごとに設定できればまた違ったのかもしれませんが・・・いや通常の通信を行う場合は普通にRTC::OutPortのwriteを使っているので無理か。いっその事以前の記事で書いた方法でoutport.connectors()[num]->write(&Data)のようにコネクタごとにデータを書き込めば可能かもしれないです。まあ相当面倒ですし、そもそもそんな状況レアなのでコメントで書くかは少し考えます。
それから共有メモリの空間名なのですが、特に理由がなければUUIDを使った方がいいのではないかと思ってはいます。
Lib_samplesのサンプルRTCを試してみたのですが、何故かアクティブにしても何も起こりません。rtc.confで通常の周期実行の実行コンテキストに変更すると画像がちゃんと表示されたのでStepwiseECという実行コンテキストが何かしているのだと思いますが、仕様がまだ書かれていないためよくわかりません。ソースコードもヘッダーファイルとライブラリだけ配布されているので中身がわからない。というか何でPeriodicExecutionContextをオーバーライドしないのでしょうね？PeriodicExecutionContext.hと大部分が同じコードのようですが。
画像処理は完全な専門外なのでコードを読んでも全くわかりません。この部分は見なかったことにします。
以前からしている画像を圧縮してからの通信についてですが、やはりこのソースコードのものに移行するみたいです。どうやらうっかりメールを見落としていたみたいです。いやでも既にInterfaceDataTypes.idlのCameraImage型に対応したRTCがたくさんあるわけで、今回はどちらを使うかというのは非常に難しい問題ではあります。とりあえず他の人が新しい方に合わせてくるようであればそれに合わせます。ちなみにOpenRTM-aist-1.1.1-betaではInterfaceDataTypes.idlのCameraImage型のサンプルコンポーネントがインストールされるのでReleaseでもそのままだと思います。じゃあ結局Img.idlのCameraImage型は今後どういう扱いになるのかが謎です。全く別物と考えた方が良いのでしょうかね？
既存のRTCと接続できる利点を捨ててまでImg.idlのCameraImage型を使う理由も今のところ僕にはないのですよね。
なんでメールを見逃がしてたのかなあと考えてみたら、そもそもCameraImage型だって必要になったので使っただけであって、画像処理関連のことに全く興味がないのでチラッと見ただけで特に気にしなかったのかなと思ってきました。今はとりあえず必要なので真剣に調べます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
今回は「このRTCの実装方法は少しおかしいんじゃないの？」と取られかねないような発言をしていますが、自分の考えと違うと書いてあるだけで別に自分の方が正しいとは全く思っていません。
また新たに作品が投稿されました。
コサイン類似度を用いた日常動作認識のためのテンプレート作成および動作認識RTC
無知なのでコサイン類似度が何かわからず調べてしまいました。
なんでも文書の類似性を計算する方法らしいです。
簡単な方法としては単語の出現頻度で計算する方法もありますが、TF-IDFという単語の出現頻度、重要度の計算式を使用する方法もあるみたいです。このサイトがわかりやすいですね。
そういえば8月に今年の作品の傾向を予想したと思ったのですが、その記事が何故かどこにもありませんね。
確かこんな予想だったはずです。
- 何らかの機器を使った作品が多くなる
- 画像処理関連の作品は間違いなく投稿される
- SLAM関連の作品も必ず投稿される
- いままで一度も実行コンテキストは投稿されたことがないので、今年は出るかも
まさかこんなにズバズバ当たるとは思いませんでした。
11月になったら優勝予想でもしてみようかな？
多分当たると思います。
昨日投稿されたAR.Droneの作品ですが、ここにあるソースコードを利用しているみたいです。
なんかリンク先のユーザー名をどこかで見たなと思ったら、AR.Droneの関数を調べていたときに見つけたサイトの人と同じでした。AR.Droneのプログラミングに関する情報が多くのっていて参考になりました。と言うか僕は何でAR.Droneも持っていないのにこんなことを調べているのか自分で疑問です。というか別の人が作ったコードを使い回しているなら別にその部分は解析しなくてもいいかもしれないです。今のところ関係はわかりませんが。
RTCを作る時に以下の3つのルールを勝手に自分に課しています。
- 独自のデータ型は使わない
- サービスポートは極力使わない
- コンポーネントのコードとロジックのコードは切り離す
というより1、2は間違いと言う可能性大ですね。
なぜ独自のデータ型を使わないかと言うと、既存のRTCと接続できなくなるのが気に食わないからです。こちらで作成したIDLファイルを使わなければならないわけで、それが面倒なのも何か押しつけがましいです。
どうしても必要な時はサービスポートを使います。
ただそれも以下の状況の場合だけです。
- 補足的な機能の場合
- 入念に検討した結果サービスポートを使わざる得ない場合
念のために言っておきますが、人の作成したIDLファイルで定義したインターフェースは利用します。ただ自作のIDLファイルは極力使わないようにしてます。自分で作ったIDLファイルを使ってもらえるとは思っていないので。
コンポーネントのコードとロジックのコードを分けるのは、ソースコードの再利用性のためです。まあ、そうすれば多少はソースコードが見やすくなるかもしれません。
AR.Droneの作品で独自のデータ型を2つ使っていますが、既存のRTCと接続できることを捨ててまでそうする理由は何かと考えてみます。TimedControldata型はTimedVector3D型とTimedDouble型とTimedBoolean型、TimedNavdata型はCameraImage型とTimedOrientation3D型とTimedVector3D型とTimedDouble型とTimedBoolean型とTimedShort型に分割した場合を考えると、確かにデータポートがやたら多くて接続が面倒ですし通信の同期が取りづらいという欠点はありますね。どちらが正しいかは難しい問題だと思います。まあコメントで聞いてみれば一発で解決するか。
何かこれ以上言ったら再利用厨とか言われるかもしれないのでそろそろやめておきます。
あとこちらの作品の共有メモリ通信のソースコードを読んでみた感想でも書きます。OnConnectedListenerはデータポートの接続時のコールバックだと思うのですが、この中でuseSharedMemoryという変数を接続先が違うPCの場合はFalseにしています。useSharedMemoryがTrueのままの場合は共有メモリ通信、Falseの場合は通常通信するみたいです。つまり一つでも違うPCで起動したRTCのデータポートと接続してしまうと同一PCで起動したRTCとの通信も共有メモリではなく通常の通信を行うようになるみたいです。コネクタごとに設定できればまた違ったのかもしれませんが・・・いや通常の通信を行う場合は普通にRTC::OutPortのwriteを使っているので無理か。いっその事以前の記事で書いた方法でoutport.connectors()[num]->write(&Data)のようにコネクタごとにデータを書き込めば可能かもしれないです。まあ相当面倒ですし、そもそもそんな状況レアなのでコメントで書くかは少し考えます。
それから共有メモリの空間名なのですが、特に理由がなければUUIDを使った方がいいのではないかと思ってはいます。
Lib_samplesのサンプルRTCを試してみたのですが、何故かアクティブにしても何も起こりません。rtc.confで通常の周期実行の実行コンテキストに変更すると画像がちゃんと表示されたのでStepwiseECという実行コンテキストが何かしているのだと思いますが、仕様がまだ書かれていないためよくわかりません。ソースコードもヘッダーファイルとライブラリだけ配布されているので中身がわからない。というか何でPeriodicExecutionContextをオーバーライドしないのでしょうね？PeriodicExecutionContext.hと大部分が同じコードのようですが。
画像処理は完全な専門外なのでコードを読んでも全くわかりません。この部分は見なかったことにします。
以前からしている画像を圧縮してからの通信についてですが、やはりこのソースコードのものに移行するみたいです。どうやらうっかりメールを見落としていたみたいです。いやでも既にInterfaceDataTypes.idlのCameraImage型に対応したRTCがたくさんあるわけで、今回はどちらを使うかというのは非常に難しい問題ではあります。とりあえず他の人が新しい方に合わせてくるようであればそれに合わせます。ちなみにOpenRTM-aist-1.1.1-betaではInterfaceDataTypes.idlのCameraImage型のサンプルコンポーネントがインストールされるのでReleaseでもそのままだと思います。じゃあ結局Img.idlのCameraImage型は今後どういう扱いになるのかが謎です。全く別物と考えた方が良いのでしょうかね？
既存のRTCと接続できる利点を捨ててまでImg.idlのCameraImage型を使う理由も今のところ僕にはないのですよね。
なんでメールを見逃がしてたのかなあと考えてみたら、そもそもCameraImage型だって必要になったので使っただけであって、画像処理関連のことに全く興味がないのでチラッと見ただけで特に気にしなかったのかなと思ってきました。今はとりあえず必要なので真剣に調べます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
