汎用ロボットのアーキテクチャについて続き２

前回の記事はこちらです。
汎用ロボットのアーキテクチャについて続き１ - neuralnetな日記

次に、アルファのブレインとボディの接続について検討します。データの送り方は、データを流し続けるストリーミングタイプと、一度だけデータを送付するワンショットタイプがありそうです。

ボディからブレインに入力可能な情報は以下の通りです。

カメラ情報：映像ストリーミング
マイク情報：音声ストリーミング
温度/湿度情報：テキスト情報のストリーミング(JSON等)

ストリーミングデータを受け取り、メッセージキューで処理することになりそうなので、クラウドのIoTソリューションが向いていそうですが、一旦は単体サーバーで進めてみます。

余談になりますが、クラウドのIoTソリューションですと、PubSubができるようです。カーシェアリングの車の貸し借りのような感覚で、ロボットのボディを貸し借りする世界観も想像に難くありません。
こちらは、GoogleのIoTソリューションです。
cloud.google.com

次にボディの出力は以下の通りです。

スピーカー(答えるため、また音楽を流すため)
赤外線出力(リモコン操作)
ディスプレイ(表情を表現するため)
移動(キャタピラ移動)

出力はすこし複雑で、ワンショットとストリーミングで流すものがありそうです。また、ボディで完結するものもあるかもしれません。
基本的には、自律的な発言には意思決定が必要なので、ブレインからキックする必要があります。

スピーカーでの回答、実行単位はワンショットもしくは文脈の長さによってはストリーミングです。
スピーカーでの音楽は、ストリーミングです。
赤外線出力は、リモートから送信パターンを送付するものとし、データをワンショットで送付することとします。
ディスプレイは、表情パターン（にっこり、笑う、悲しい、眠る、しゃべる、うれしそうにしゃべる、忙しくしゃべる、普通等）のみを送付し、表示はボディが行うことします。転回する際にデータを送付するワンショットとします。
移動は、左右に対して、－１，０，１の３パターンを送付するものとします。(右,左)=(1,1)は前進、(右,左)=(1,-1)は左に回転等です。また、電圧のレベルを1から10で決定します。指令が出ているときのみ動くと考えれば、ストリーミングのほうが適切です。

まとめると以下の通りです。

カメラ情報	入力：ボディからブレイン	映像	ストリーミング
マイク情報	出力：ボディからブレイン	音声	ストリーミング
温度/湿度情報	入力：ボディからブレイン	テキスト	ストリーミング
スピーカー(回答)	出力：ブレインからボディ	音声	ストリーミングもしくはワンショット
スピーカー(音楽)	出力：ブレインからボディ	音声	ストリーミング
赤外線出力	出力：ブレインからボディ	テキスト	ワンショット
ディスプレイ	出力：ブレインからボディ	テキスト	ワンショット
キャタピラ移動	出力：ブレインからボディ	テキスト	ストリーミング

仮に、移動をワンショットで行う場合は、緊急停止等のボディのみで終始する仕組みがあったほうがよいかなと思いましたが、アルファでは、ボディ側に周辺を把握するセンサー等がないので実装が困難であったのと、ストリーミングが切れたら停止するという対応ができるので、その方向で検討を進めます。
逆に、ボディがアルファよりリッチな場合や、将来的に、安全性を考慮しなければいけない場合は、ボディがある程度自律的に安全性を判断して緊急停止するなどの動きを取り入れる必要がありそうです。

思い付きで、音楽を再生できる機能を搭載する設計にしましたが、同じ流れでいうと、ディスプレイに映像を表示できる機能があってもよくなります。どちらも、このロボットが完全なサービス提供者という立ち位置であれば自然なのですが、ロボットがパートナーであると考えると、逆に不自然さを感じます。ドラえもんは歌が下手であり、音楽を流すロボットではなく、音楽をともに聴くロボットだからです。当たり前な話ですが、汎用ロボットであっても目的に応じて搭載する機能が変わってくるため、ベータの設計では、それを意識したほうがよさそうです。

本題に戻ります。これだけ複数のセッションがある場合、全体的なセッション管理が必要です。LTEの場合、IPアドレスも同的に変わる可能性があるため、どのレイヤーでセッション維持するかを検討する必要もありそうです。

当初想定していた仕様
汎用ロボットのアーキテクチャについて - neuralnetな日記
では、セッションをつなげに行くのはボディからという想定です。これは、ボディの通信手段が常に変わる事を想定しており、ネットワークアドレスが普遍なものがブレインしか存在しないためです。
暗に、従来のwebのホスト名およびIPアドレスを使用すると宣言しています。

なお、この段階で基本的にはブレインとボディはサーバークライアント方式を採用しており、その制約を受けることになります。具体的に言うと、あるボディに別のロボットのブレインが接続しに行くということが困難な構成になります。SIP(もしくはそれに類似した機能)などを導入し、双方向の通信を可能にすることで、ネットワークの構成がより柔軟になり、ロボットの相互接続性が広がると思います。このあたりは、どちらの設計思想が将来求められてくるかに依存するのだと思います。
Session Initiation Protocol - Wikipedia

今回はシンプルに、ブレインサイドにWebサーバーを立てて、そことGET/POSTを通じてセッション管理を行う前提で話を進めていきます。