mongodbに蓄積されるedgetpu detectorの認識結果のHzが高い

チャットだと散逸しそうなのとデータベース周りを使いたいとなったときの今後の参考にもなりそうなのでこちらに追加します．もともとはmongodbにためられているedgetpuの認識結果のHzが高すぎて検索に時間がかかるのではないか，というところを発端としています．

解決策としては

edgetpuのtopicを認識結果がないときにはpublishされない機能を追加する (https://github.com/jsk-ros-pkg/coral_usb_ros/pull/134)
mongo_record.pyで認識結果が空のときはmongodbに貯められないようにする(実装中)

というところが考えられます．

Iori Yanokura, 昨日 13:30
@Naoto Tsukamoto 
human pose detectorのデータって10Hzごとに毎秒入っているのかな？
認識されていない区間のデータとかも保存されている?

Naoto Tsukamoto, 昨日 13:36
認識されていない部分も全部入っていました．human_pose_detectorがtarget_namesだけずっとpublishしているのが問題かなと思いました．

Iori Yanokura, 昨日 13:37
たしかに
target_namesが入ってしまってますね
これ実質無駄な情報になっちゃうよね

Iori Yanokura, 昨日 13:38
大量のデータを使う場合はなくしたほうがいい、もしくはtarget_namesは別に1回だけ記憶したほうが良さそうな気もしますね

Naoto Tsukamoto, 昨日 13:45
mongo_record.pyでテキトーに貯めている状況がよくないのと，
認識ノード側で認識結果がないのにtarget_namesがpublishされ続けているのと(こちらはJSKの仕様?)
両方見てみようと思います．

岡田慧, 昨日 14:30, 編集済み
これは仕様が安定しないところなんだけど、何もない、という事を明確にするために結果がNullなものをPublishすべきか、そもそも結果をPublishしないべきか、というのがありますね。
周期実行プログラムだとプログラムのメインループに相当する処理をコールバック関数の中に書いていると、結果が無くてもpublish してくれる方がうれしくて、プログラムはあくまでもメインループがあって、コールバック関数で大域変数を更新している書き方だと、条件処理を書かなくてよい分だけ、結果が無いときはデータが来ない方が良い感じがします。
一方、データドリブン型のプログラムを書いている場合は、基本は結果があるときだけデータがやってくると思っているのかな。DBはこちらのタイプなので、認識結果が無いのにPublishされている仕様とは相性が悪い気がします。
で、結局どっちがいいかわからなくて、使う人に丸投げしたのが以下の変更です。が、これも同じロボット内で複数の人が使うとなると、いろいろと使い分けしたくなりそうです
https://github.com/jsk-ros-pkg/jsk_recognition/pull/2744/files#diff-2dbcced88e36ff84629a2ef9f83dc3a39c38ad92553424d05adc2b17278a5f07R118-R120

@Naoto Tsukamoto 思い出しシステムについてはmongo使わないというのも手かもしれない．そもそもデータベースシステムである必要があるのか？rosbagだけでいいのでは，とか

Naoto Tsukamoto, 昨日 13:37
特に画像についてはmongoを使わないほうが扱いやすいかもしれないと思いました．
このあたりを少し整理してみます．

岡田慧, 昨日 13:59
これで、やっぱinflexだね、となって現在に至る、ということなので、人生2週目だと思って工夫があると良いですね。DBを何にするかは手段なので、あくまでも目標を決めて、それを達成するのにどうしても手段の変更が必要か、とか、ほかの手段があるのか？と考えると良いです。で、現時点ではデモで見せられるようにする、というのを目標として、ブレイクダウンすると、実際には
A)7月11日だけの記憶を持っていて、思い出せる。（デモにはなるけど、思い出す曜日は固定されている）
B)当日の記憶を持っていて、思い出せる。
があって、現状はA)は時間かけないと思い出せない。B)はreplacation が行われると、思い出せない気がする。
DBを軽くする方法は
１）不要な情報を消してみる
があって、これでB)が動くか確認したい。replacation された2時間前が思い出せるなら、7/11も同じように思い出せる気がするけど、違うかな。
この方法が簡単でないとした場合は、
２）12時間かかってもよいので、イベント日だけ別のcollection にして、後のデモではそこを使えるようにする。あるいはプログラム的に、7/11は、、、と言ったら、そこのcollectionに切り替える、などがありそう。http://www.open-ease.org/ も結局エピソードを選ぶ形になっているので、同じ問題があったのかな。

jsk-ros-pkg / jsk_robot

mongodbに蓄積されるedgetpu detectorの認識結果のHzが高い #1829