ドキュメント一覧
ESP32 iPhone Agentの仕組み
画面からモデルへ、モデルから操作へ。接続ごとの役割を理解する。
現在の構成はiPhone、ESP32-S3、視覚モデルのAPIです。エージェントはiPhoneアプリで動き、ボードは画面の受信とマウス・キーボード入力を担当します。
目：AirPlayとBluetooth
ボードは自分のWi-Fiアクセスポイントを作ります。iPhoneはそこに接続し、画面ミラーリングの受信先にESP32 Agentを選びます。
ESP32はH.264映像をデコードせず、BLE経由で同じiPhone上のアプリに転送します。アプリがデコードした画面からスクリーンショットを取り出し、視覚モデルに渡します。
iPhoneの画面 → AirPlay / Wi-Fi → ESP32-S3
ESP32-S3 → H.264 / BLE → iPhoneアプリ → 視覚モデルWi-Fiをボードに使っている間、モデルへのリクエストはモバイル通信で送ります。
頭脳：iPhoneアプリとモデル
プランナーとアクターが、指示と画像からタップ、スワイプ、描画、文字入力、キー操作、ホームへ戻るといった動作を決めます。モデルはクラウドAPIでも、iPhoneからアクセスできる自前のサーバーでも構いません。
ほかのアプリを操作している間もエージェントはバックグラウンドで動作し、対応端末ではLive Activityで進行状況を確認できます。ESP32上でモデルの推論を行うわけではありません。
手：標準のUSB入力
ボードはUSBマウスとキーボードとして認識されます。AssistiveTouchを使うことで、クリックがタップに、ドラッグがスワイプになります。
iPhoneアプリ → BLEの操作指令 → ESP32-S3
ESP32-S3 → USBマウス / キーボード → iPhoneUSBは入力経路と給電を兼ね、BLEはアプリの指令と映像を運びます。BLE接続があることは、USBケーブル不要のBluetooth HID操作が実装済みであることを意味しません。
操作を閉じたループにする
マウスの移動量は相対値です。アプリはポインタ位置を追跡し、隅に戻して基準を取り直したり、細かなタップの前に画像から位置を確認したりします。操作後は画面が落ち着くのを待って、次の判断を行います。
これは視覚による操作ループです。各アプリの意味情報を直接呼び出すAPIとは異なり、小さな対象、画面の曖昧さ、モデルの判断ミス、応答の遅れが結果に影響します。
なぜボードを使うのか
ESP32は、iOSが受け付ける画面ミラーリングとマウス・キーボード入力をつなぎます。画面が見えるだけでは、iPhone上のエージェントから実際に操作を送る経路にはなりません。
この構成なら、アプリごとに専用の連携機能を作らずに実験できます。ただし、初回のXcode導入や、保護された画面が映らないといった制約は残ります。
旧バージョンとの違い
v0.1.0ではMacまたはLinux上のUxPlayとPythonサーバーを使っていました。旧構成はlegacyブランチに残っています。現在のmainではAirPlay受信をボードに、エージェントをiPhoneアプリに移しています。