[jsk_robot_startup/smach_to_mail] Not use yaml file to set address

[tkmtnt7000]

This reverts commit b73a8ac.
We do not use yaml file (/var/lib/robot/...yaml) to set sender and receiver address.
From #71 (comment)

[mqcmd196]

Should I rebase this for launch file?

[tkmtnt7000]

I would be happy if you could use this as a base, either cherry-pick or rebase, there may be minor changes, though.

[k-okada]

@tkmtnt7000 since I have merged jsk-ros-pkg#1558, please create your PR on jsk-ros-pkg as well as email_topic.py. Sorry for confusion.

@mqcmd196 If you are talking about #72, please also create PR against jsk-ros-pkg so that every one can see your work. BTW, how to deal with responces from chat, I think main differentce between email vs chat is Chat can use respond easily. So I whould like to find a way to change goal or userdata from chat interface.

(IT IS TOO LATE: you do not have to cherry-pick or rebase, beacause your inmprovement is independent from email receiver/ sender parameters, so if the software is desinged well, your patch did not collide with this fix.)

[tkmtnt7000]

OK. I make PR to jsk-rod-pkg

BTW, how to deal with responces from chat, I think main differentce between email vs chat is Chat can use respond easily. So I whould like to find a way to change goal or userdata from chat interface.

僕もメールとチャットでの違いが面白いと感じていて、チャットの返信があったときにロボット側がどう反応するのが良いかあまりわかっていませんがこの応答について今後さらに発展性がありそう、という感じがしています。(市倉さんの研究につながる？？)

ふんわり使い方とかメリットとして考えているのは
メール:みんなあるいは個人に通知、検索性良い
チャット:対話的に作業できる
ツイッター:対外発信
みたいなイメージです

そうすると各インターフェースに流したらいい情報の種類というのもある程度見えてくるかなと思います(エラー情報等含め)

[mqcmd196]

僕もメールとチャットでの違いが面白いと感じていて、チャットの返信があったときにロボット側がどう反応するのが良いかあまりわかっていませんがこの応答について今後さらに発展性がありそう、という感じがしています。(市倉さんの研究につながる？？)
そうすると各インターフェースに流したらいい情報の種類というのもある程度見えてくるかなと思います(エラー情報等含め)

これはかなり同意です．それと同時にインタラクションの前に通知の部分があると思うのですが，多分chatは情報を普段から流しすぎると通知がうるさくなってみんなスレッドをミュートして見なくなるので，みんなが見てもらえるレベルの情報をちゃんと流すことがかなり大事だと思っています．個人的にロボットのソフトウェアを書くときに意識しているのはloggingのlevelなんだけど，developerのfetchスレッドにはlogerrorの内容を出す，ユーザにはデモ中に発見したもので一番情報量がでかいもの(普段出現しなかったこと)を出す，みたいに情報をフィルタすることは大事だと思います．

例えばstackしたときに，結局だれかが気づいたときに今僕達は誰かにjoyで操作してもらうようにお願いしていますが，

Level 1. SMACHの遷移がtime out していることを伝えて助けてもらう
Level 2. smachを中断して/cmd_vel を送れるようにする
Level 3. /cmd_velではなくdock move-to-spot みたいなボタンを用意して目的地を抽象化
...
みたいなレベルがあると思いました．ただ結局コレもdeveloper的な需要なのでアプリケーションレベルでは具体的にキッチンデモのsmachの各状態のタスクが何を目的にしているのかは考える必要があると思いました(多分僕の課題です)．でdeveloperレベルの使い方ばっかしてるとそこに落ち着いてそれ以上がなくなってしまう気がするのでそこは気をつけるべきだと思います(自戒も込めて)．

[mqcmd196]

(IT IS TOO LATE: you do not have to cherry-pick or rebase, beacause your inmprovement is independent from email receiver/ sender parameters, so if the software is desinged well, your patch did not collide with this fix.)

I see. I work on current origin/master independently on this PR

[mqcmd196]

なので現状のシステムにchatを組み込むとして，SMACHのreportにはレベルが存在しているべきなのではないかという提案です．現状全部の情報を報告していますが，そこに重要度の何らかのパラメータはあっていいと思います

[k-okada]

こういうのは重要な議論なので jsk-ros-pkg#1578 みたいに見えるところでやるのがいいですね。で、
jsk-ros-pkg/jsk_roseus#716 (comment)
jsk-ros-pkg#1568 (comment)
に書いたみたいに、DESCRIPTION/IMAGE は、重要な伝えるべき情報で、すべてのノードにある必要はい。一方INFOは全ノードが持っている（なければ自動で生成される）、という切り分けで考えて、必要ない、重複した情報がDESCRIPTONに入っていれば、jsk-ros-pkg#1568 を直してみましょう。

SMACHレベルだと、できることは内部状態の変更と、目標の変更、になるので、（あとは現在の状態の強制変更？）なので、まずはパスがいくつかできるような状態遷移図に拡張するのがよいとおもいます。
例えば、キッチンの上のものを見つけたら、それをもって片づけるとか、その作業をした後人がいたら、その人に、なんでコレ（＝車いす？）がこんなところにあるの？というとか、曜日によってゴミ箱を見たり見なかったりするとか、時間によって最後に電気を消すとか消さないとか、、
で、それを書くと、内部でuserdataを持つか、あるいは、大域変数を作ると思うので、
あとはそれを外部から変更してみるというのがありそうです。

@mqcmd196 としては、どういう命令形式を受け付けるか、というのを整理しておくのが良くて、これはRSJの原稿の時のコメントに言ったかな？CPUつくったらその命令セットをデザインするんだけど、それの組み合わせでどういう計算ができるか示す。という感じです。CPUだと足し算掛け算がこうできますと。GPU（あるいはSIMD計算機）だと、こういうベクトル計算ができます、とか。
で、命令セットと、それでできる事の距離が大切で、
　チューリングマシンを作りました→知能ができました、は飛躍しすぎ
　ブラウザを作りました→Webがみれます、は、それで何ができるか（オンラインで本屋をできると思った人が、いまどうなっているか。。。。）
という感じで、このシステムがどういう命令セットを持っているか説明する、その命令セットの組み合わせでどういうリッチな実験ができているか、実証してみる。と、聞いている人は、これぐらいの可能性がありそう、と評価してくれると思います。

[k-okada]

@tkmtnt7000 これとemail_topic.py と合わせてjsk-ros-pkg にPRを送ってくれると助かります。

[tkmtnt7000]

遅くなってすみません．
jsk-ros-pkg#1588 にこの内容とemail_topic.pyを合わせて出しました．