ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
先に断っておきます。
今回は「この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型だって必要になったので使っただけであって、画像処理関連のことに全く興味がないのでチラッと見ただけで特に気にしなかったのかなと思ってきました。今はとりあえず必要なので真剣に調べます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする
