12.10. まとめ

USBケーブルに接続されたカメラが、ホストプログラムへフレームをストリーミングし、ホストから設定の更新を受け取り、抜き差ししても同期を失わずに動作し続ける(再送は隠蔽され、複数の論理ストリームが1つのポートを共有し、アプリケーションにフレーミングコードはゼロ)。これがカメラ側のおよそ40行のコードと、ホスト側の同程度の量から実現されます。プロトコルライブラリはバイトパイプをプログラム可能なチャネル面に変え、アプリケーションより下のすべてを目に見えないままにします。

12.10.1. この章で構築したもの

  • スタックの4層メンタルモデル: トランスポート、フレーミング、信頼性、チャネル。各層は1つの問題を解決し、その上のすべてを無視します。

  • 伝送路上のパケット形式。CRC付きの10バイトヘッダー、可変長ペイロード、末尾のCRC。バイト単位でたどれるほど小さいものです。

  • トランスポートが接続したときにカメラとホストが実行するハンドシェイク: PROTO_SYNC、機能交換、チャネル探索。

  • その上の信頼性機構: シーケンス番号、ACK、NAK、指数バックオフ付きの再送、10種類のステータスコード。

  • チャネルモデル: 1本の伝送路上で最大32個の名前付き論理ストリーム。組み込みの stdin / stdout / stream / profile と、Pythonクラスで登録されるアプリケーションチャネルを備えます。

  • バックエンドインターフェース(sizereadwritepolllock / unlockshapeioctlflushis_active)と、プロトコルライブラリがバックエンドに存在するメソッドを使ってチャネルが何をサポートするかをどう判断するか。

  • ホスト側: openmv-python SDKの Camera クラス、USB-CDCをプロトコルモードに切り替える 921600 ボーのマジックレート、そして channel_size / channel_read / channel_write の往復パターン。

  • フレームストリーミングパターン(単一バッファのキャプチャ、ラッチ付きの readp、新フレーム通知のための send_event)と、双方向の設定パターン(ホスト書き込み可能なチャネル、JSON往復)。これらが合わさって、あらゆるインタラクティブなカメラツールの基盤を形成します。

12.10.2. リファレンスのロードマップ

ライブラリリファレンスのページは、これらの機能が実際のコードに現れたときの参照先です:

  • protocol --- OpenMVプロトコルチャネル -- protocol モジュール、protocol.init()protocol.register()ProtocolChannel、チャネルフラグ定数、そしてカメラごとの最大ペイロードの表。

  • ホストSDK -- pip install openmvopenmv.camera.Camera。この章で扱ったメソッド: update_channels()has_channel()channel_size()channel_read()channel_write()poll_events()read_frame()exec()、そして stop()

  • openmv-projects リポジトリ -- プロトコルライブラリ上に構築された実際のツール。tools/ ディレクトリには、thermal-overlay-calibration(RGB + サーマル位置合わせGUI)、ccm-tuning(カラー補正行列チューナー)、genx320-event-streaminggenx320-overlay-calibration(イベントカメラ用ツール)が含まれます。いずれもこの章のパターンを端から端まで使用しています。

12.10.3. 次に進む先

カメラプロジェクトがここから進む方向をいくつか挙げます:

  • ホストGUIの構築。 動画ウィジェットに供給するフレームチャネルと、スライダーやボタンに供給する1〜2個の設定チャネル。GUIレイヤー自体には DearPyGui が自然な選択です。純粋なPython製で、pipでインストール可能、ライブプレビューに十分なほど高速で、既存のすべてのOpenMVホストツールがまず手に取るものです。

  • マルチチャネルテレメトリダッシュボード。 同じカメラ上の複数のアプリケーションチャネル(センサー読み取り値、カウンター、ステータスイベント)がそれぞれ独自のコールバックで更新され、ホストGUIがそれらをタイマーで読み取って個別にレンダリングします。チャネルレイヤーの独立したフロー制御により、1つの遅い読み取りが他を停滞させることはありません。

  • UART経由のリモートチューニング。 同じチャネルコールバックを使い、アプリケーションは protocol.init を呼び出してUSBからUARTトランスポートに切り替えます。カメラはヘッドレスで動作し続け、Raspberry Piやラップトップ上のPythonスクリプトがシリアル回線越しに通信して現場でチューニングします。

伝送路の形式、信頼性レイヤー、チャネルの抽象化は変わりません。デプロイに合ったトランスポートを選び、ホストが見たり設定したりする必要のあるものごとにチャネルを追加することが、ここから先のエンジニアリング作業のすべてです。