しました。
TL;DR
- スマホの加速度センサから取得した値をWeb経由でモータ直結のマシンに送ることでマスタスレーブをやりました。
- スマホのセンサが安定しないのでVRHMDを買うと良いと思います。
- 途中経過のまとめなのでシステムが安定して機能が出そろったところでちゃんとした記事にします。
- 以下の記事の続きです。
godiva-frappuccino.hatenablog.com
なぜVRHMDではなくスマートフォンでやろうとしたか
動画で載せたスマホ→ロボットの姿勢送信の他にロボット→スマホへの映像ストリーミングをやる際に、VRHMDの開発に使われるC#（Unity）で映像のストリーミングをやる為の情報があまりなかったのが理由です。
Azure Communication ServiceというWebRTCができてサンプルコードでTeamsミーティングに参加できるサービスがありますが、そこではWeb、iOS、Androidだけしかなかったので悲しいですね。
WebRTCをやろうとしたときにJavaScript、Java（Android）辺りは画面を前提としたアプリケーションの開発が多くて映像のストリーミング周りの情報が多く、サンプルコードもあったのでそれを流用する形で作るのが楽かなという感じです。
ちなみにロボット側はJavaScriptでやる予定ですが、スマホ側はJavaScriptだと画面方向の固定や姿勢などのスマホの情報にアクセスするのに不便な場合があるので、制御しやすいAndroidアプリを生成するのが都合がよかったりしました。（あとで映像ストリーミングと姿勢送信を別スレッドで一つのアプリにまとめればよいかなと思ったり）
現在の仕組みを振り返ってみて
前回姿勢を送る際にロボットの姿勢送信のマルチテナント化（やる予定なし）やステートレスな方式のメリット、ロボット側で通信するかどうか決めたい思想などからRedis Cacheに姿勢を置いておく方式にしました。
今現在はスマホ、ロボット側マシン両方が同じWebAPIにHttpRequestを送ってアクセスしていますが、WebAPI経由でRedis Cacheを叩く仕組みは考え直してみると負荷やオーバーヘッドの関係で微妙なので、直にRedis Cacheを読み書きした方が良いです。
今後の話
Oculus Quest Proほしいですね。
