デモの「期待されるビヘイビア」を文章化する

[k-okada]

今更ですが，

デモの出力(ロボットの行動、tweet、日記メール、resultメール)に関する明確な仕様がほしいです。

の指摘はナルホドで，明確な仕様とまではいかないけど，期待される結果レベルの記述はあるとよいとおもいます。
Fetchのキッチンデモだと，
https://github.com/jsk-ros-pkg/jsk_robot/tree/master/jsk_fetch_robot/jsk_fetch_startup/apps/go_to_kitchen
にReadMe.md 作って
https://github.com/jsk-ros-pkg/jsk_robot/tree/master/jsk_fetch_robot/jsk_fetch_startup
からリンク張るのかな。

で，イメージとしては

• 何をするデモか。
  例：https://github.com/sktometometo/jsk_robot/blob/b9b0a8ff80e8eec1fbdcf21e483ba69aa927443a/jsk_spot_robot/jsk_spot_head_joy/README.md#usage
  みたいに，立ち上げ方＋何ができるか軽いgifファイルで紹介されているとよい

• メールとかTwitterが流れてくるならその画面。
  例:[jsk_fetch_startup] Enable to attach pictures to kitchen demo #1463 (comment)

• 学会発表へのCitation

ぐらいの簡単なもので良いでしょう。https://github.com/jsk-ros-pkg/jsk_demos/tree/master/jsk_2013_04_pr2_610 みたいな感じです。

で，これで確認したいのは，

１）そもそも，どういうデモになっているか？最近は動いた，だけでなくて，データがアップロードされたり通知されている。今後は，その結果をさらに処理するバックエンドがポイントだと思うけど，どういうデモでどういうデータが作られているか，理解するのに役に立ちそう。

２）複数の機能が提供されているけど，なんか重複していないか？という事を，視覚化して確認できる。例えばメールが二種類やってくる，メールとTwitterで似たような情報を流している，あるいは，Twitterにも何をしているときの写真か説明文を入れたい，等々。今あるコードを今すぐ変える必要はないけど，新しいロボットで新しく作ろうと思ったとき，あるいは，同じようなコンテンツで別のコミュニケーションを行いと思ったとき，は，0から作るのではなく，既存の機能の拡張を考える。

３）2，3個のデモでこういう文章があると，それぞれのデモ間で，機能の説明が重複していないか？という事を確認できる。違うロボットで同じようなメールを流しているけど，違うページに説明がある場合は，共通のシステムにするチャンス。各ロボットのデモの説明は写真をはって，詳細はこちら→　と，共通パッケージへのリンクになっていると，複数のロボットで使えるようなシステムになっているという証拠になる。

取り合ず，これでどうなるかgo_to_kitchen でやってみましょう @708yamaguchi @tkmtnt7000 @mqcmd196 ....

[mqcmd196]

思いついたことを書いていきます．最後にここでまとまったみんなの議論をREADMEとしてPRを出します．
1)

その結果をさらに処理するバックエンド

は現段階では存在していないという認識です．つまりアップロードが成功したら終了となっています．
ここからはIMOですがメール機能以外に，①チャットで特に重要な情報を通知し，②人からフィードバックをもらってロボットの次からの行動に生かすシステムのenhancementが考えられます．1つ目についてはメールはlog.debug，チャットはlog.infoみたいなイメージです．2つ目についてはキッチンの異常検知用の学習器の学習をやりたいと思ったことがあり，半年ぐらい前にそれ用の学習器を作りかけています．これとチャットシステムを使ってキッチンデモが終了するたびに，人に自分が判断した異常結果を報告してフィードバックをもらい，dlboxで毎日学習モデルの重みパラメータをアップデートしていくみたいなバックエンドの追加が考えられます．このシステムの前段階として，学習データに不良データが交じるのを防止するために，例えば撮れたrosbagのimage topicが適切なHzで取れているか，デバイスの接続不良等による画像のチラツキなどが混じっていないかなどを検出し，報告するbackendは存在してもいいかもしれないです．dlbox側に搭載するのか，Fetch側で検出するのかという議論はあります．

[mqcmd196]

最初はロボットが知覚したもの，体内でのWARN,ERRORなどをとにかくエラーとしてGoogle Chatに吐く．見ている側が「いいね」とかのリアクションをつけて，何を見ているか，見ていないかをフィードバックしてあげて，Google Chatでのlogに重みをつけていく?など?

[708yamaguchi]

僕の思いついた要素です
プログラム的な意味での構成要素について、思いついた限りを書きます

デモの概要
・fetchがキッチンに行って周囲の様子を観察する。

デモの特徴
・app_managerによるデモのアプリ化。アイコンをクリックするだけで実行可能というお手軽さ。
・smachによるデモ管理
・事前作成された地図に基づくmove_baseおよびコストマップの動的な変更
・Twitterへの認識結果の通知
・部屋の照明の制御
・ゴミ箱検知、内容量の確認
・auto dock、auto undock
・デモのデータ保存に使われるセンサ。頭部カメラ、360度カメラ、rviz、音、coralによる画像認識
・背中モニタでのrviz表示によるデモ状態fetch状態の可視化

app_manager_utilsによるデモ固有でないコードの共通化。
・デモの自動起動、毎日実行
・rosbag保存
・rosbagからの動画音声ファイル生成
・rosbagや動画のアップロード
・デモ実行結果メール(内容は、デモの成否、生成された動画やrosbag、デモ中のsmach状態遷移、その他の認識結果など)
・デモ失敗時のロボットバッテリ保護のためのシャットダウン制御

[knorth55]

今後は，その結果をさらに処理するバックエンドがポイントだと思うけど，どういうデモでどういうデータが作られているか，理解するのに役に立ちそう。

これは個人的には古田さんの研究に近い点があって，

• 物体存在確率マップ
• 部屋の配置換え
  • [WIP] [jsk_rosbag_tools] Add bag_to_map node knorth55/jsk_common#20 ?
• 人の動線
  などが挙げられると思います．

それ以外にも使えるかはわからないですが，

• AutoEncoderのためのデータセット
• Self-supervisedな学習のためのデータセット
• マルチモーダルな学習の関連付けデータセット（音声と画像の結びつけ？，場所と音声の結びつき？）
  などが挙げられると思います．

で，どれがやれているかと言われると，どれもやれていません．．．

[tkmtnt7000]

スライドにもデータの流れなどをまとめたシステム構成図を作れるといいかなと思いました．
システムとしてだいぶ大きくなっているので，いまはとりあえず山口さんのさきほどあげた特徴を並べて書いたくらいです．
編集していきましょう．
https://docs.google.com/presentation/d/1nikle-vDEFYFQVEJgaPhxXFNHM9nI4SUBwXnMI1uR_A/edit?usp=sharing