13.1.14. サードパーティのリポジトリ#

IDE には OpenMV 独自のボード、ファームウェア、サンプル、機械学習モデル、およびエディタースタブが同梱されていますが、他社からの同じ種類のコンテンツ (パートナーが構築したボード、その上で実行されるファームウェア、そのために調整されたサンプルとモデル、ファームウェアが追加する API のコード補完) も同様に読み込むことができます。これらは third-party repositories として到着します。IDE が独自のコンテンツとマージし、最新の状態に保つコンテンツのフォルダーです。

このページには 2 人の読者がいます。そのほとんどは、他の人が公開したリポジトリをインストールおよび管理する人のためのものです。最後のセクション authoring a repository は、ベンダーがセクションを構築するためのものです。

13.1.14.1. 「サードパーティリポジトリ」ページ#

すべては「編集」→「設定」→「OpenMV」→「サードパーティリポジトリ」から管理されます。この表には、インストールされているすべてのリポジトリと、それぞれの表示名、その短縮 ID (Built-in か User か)、リポジトリが提供する各種類のコンテンツ (ファームウェア、サンプル、モデル、スタブ) のインストールされているバージョン、および更新元の URL がリストされています。

Built-in は、ベンダーが出荷したインストーラー (ドライバーパッケージがプログラムにファイルを追加する方法) によってリポジトリがアプリケーション独自のディレクトリに配置されたことを意味します。 User は、URL から自分でインストールしたことを意味します。唯一の実際的な違いは、組み込みリポジトリを IDE から削除できないことです。組み込みリポジトリは、そこに配置されているものをアンインストールすることで削除されます。そのため、[削除] ボタンは無効になっています。

13.1.14.2. リポジトリのインストール#

URL からインストールでは、リポジトリの config.json (ベンダーが公開する小さなマニフェストファイル) のアドレスを要求し、それが指すものをすべてインストールします。ベンダーから提供された URL を貼り付けます。 IDE はマニフェストをダウンロードし、リストされているファームウェア、サンプル、モデル、およびスタブを取得し、各ダウンロードを検証します。リポジトリのインストール、削除、更新はすべて再起動後に有効になるため、インストールが完了すると IDE は再起動を求めます。

ベンダーは、リポジトリをアプリケーションディレクトリに直接ドロップするインストーラーとして配布することもできます。その場合、最初にページを開いたときには単に Built-in 行として表示され、インストールするものはありません。

13.1.14.3. リポジトリを常に最新の状態に保つ#

更新 URL を含むリポジトリは、IDE が起動するたびにチェックされます。新しいコンテンツが利用可能になると、IDE は内容を通知し、各リポジトリと関連するバージョンをリストし、そのインストールをすべて 1 つのプロンプトで提案します。「更新のチェック」は、同じチェックをオンデマンドで実行します。

13.1.14.4. 優先順位とオーバーライド#

リポジトリは順序付きリストであり、最も高い優先順位が一番上にあり、「上へ移動」および「下へ移動」により、選択したリストの順序が変更されます。順序が重要になるのは、2 つのソースが「0」のものを提供する場合のみです。つまり、同じ USB 識別子を持つボード、または同じ名前を持つサンプル、モデル、またはスタブです。そうなると、上位のエントリが優先され、すべてのリポジトリが OpenMV の組み込みコンテンツよりも優先されます。これは意図的なものです。これは、ベンダーが OpenMV ボードの USB 識別子を共有するボードに独自のファームウェアを提供し、IDE が提供するストックファームウェアを置き換えたり、ストックサンプルを自社のハードウェア用に書かれたサンプルに置き換えたりする方法です。

オーバーライドはよく知られた名前の動作を暗黙的に変更するため、ページが名前を隠すことはありません。 [オーバーライド警告] パネルには、有効なすべてのオーバーライド (どのリポジトリのボード、サンプル、モデル、またはスタブがどのオーバーライドをオーバーライドしているか) がリストされ、リポジトリが初めて表示されたときに同じリストがメッセージとして 1 回表示されます。ボード、サンプル、またはモデルが OpenMV のドキュメントに記載されているとおりに動作しない場合は、最初にこのパネルを参照してください。

13.1.14.5. リポジトリが提供するもの#

4 種類のコンテンツはそれぞれ IDE の通常の場所に表示されるため、リポジトリがインストールされれば、新しく学ぶことは何もありません。

Boards and firmware. リポジトリのボードは OpenMV ボードとまったく同じように動作します。接続時に認識され、ステータスバーにタイプが表示され、最新の開発リリースのインストールパスを含む IDE を通じてファームウェアが更新されます。ファームウェアの更新と復旧を参照してください。
Examples. リポジトリのサンプルは [ファイル] → [サンプル] に表示され、カテゴリツリーにマージされます。ベンダーが OpenMV カテゴリと同じ名前を付けたカテゴリのサンプルが OpenMV のカテゴリと並んで配置され、新しいカテゴリが独自のサブメニューになります。他の例と同様に、サポートするボードにフィルターされます。スクリプト、サンプル、そしてドキュメントフォルダを参照してください。
Models. リポジトリのモデルは Model Zoo に表示され、ベンダー独自の説明とともに同じ方法でブラウザツリーにマージされます。
Stubs. リポジトリは .pyi スタブファイルを配布できるため、editor はファームウェアが追加する関数の補完、署名、およびドキュメントを提供します。これは、OpenMV 独自のモジュールやベンダーのカスタム API で得られるのと同じ補完です。

13.1.14.6. リポジトリの作成#

リポジトリは、ベンダーにちなんで名付けられたフォルダーであり、config.json マニフェストと、ベンダーが提供する各種類のコンテンツのサブフォルダーを保持します。

acme/
  config.json
  firmware/
    settings.json                 board descriptions
    ACME_CAM1/                    one folder per board, named by boardFirmwareFolder
      firmware.bin
      romfs0.img
  firmware.version
  examples/
    index.csv                     which examples show for which board / sensor
    01-Getting-Started/           numbered category folders, same as OpenMV's
      hello_acme.py
      read_sensor.py
    02-Acme-Widgets/
      spin_widget.py
  examples.version
  models/
    index.csv                     which models show for which board
    acme/                         a group; its index.html + image describe it
      index.html
      image.jpg
      person_detector/            one folder per model
        person_detector.tflite
        person_detector.txt       class labels
  models.version
  stubs/
    acme_hal.pyi                  a module the firmware adds
    csi.pyi                       overrides OpenMV's to add methods
  stubs.version

フォルダー名はリポジトリ ID です。文字で始まる小文字、数字、- および _。すべてのパーツフォルダーはオプションです。あなたが持っているものだけを発送してください。各パーツフォルダーの横には、IDE が更新が新しいかどうかを判断するために使用する単一のバージョン文字列 (1.2.0) を保持する <part>.version ファイルがあります。

13.1.14.6.1. マニフェスト#

config.json はリポジトリに名前を付け、各部分がダウンロード可能なアーカイブを指します。

{
  "name": "acme",
  "displayName": "Acme Robotics",
  "homepage": "https://acme.example",
  "configUrl": "https://acme.example/openmv/config.json",
  "firmware": {
    "release":     { "version": "1.2.0", "url": "https://acme.example/acme-fw-1.2.0.zip", "sha256": "..." },
    "development": { "version": "dev-20260701", "url": "https://acme.example/acme-fw-dev.zip", "sha256": "..." }
  },
  "examples": { "release": { "version": "1.1.0", "url": "https://acme.example/acme-examples-1.1.0.zip", "sha256": "..." } },
  "models":   { "release": { "version": "1.0.0", "url": "https://acme.example/acme-models-1.0.0.zip", "sha256": "..." } },
  "stubs":    { "release": { "version": "1.0.0", "url": "https://acme.example/acme-stubs-1.0.0.zip", "sha256": "..." } }
}

name はフォルダー名と一致する必要があります。 configUrl は、この同じファイルがホストされているアドレスです。 IDE はそれを再フェッチして更新をチェックするため、更新されないリポジトリの場合にのみ省略します。各パーツには release チャネルがあり、ファームウェアにも最新の開発リリースのインストールで使用される development チャネルがある場合があります。リリース version の値は数値として比較されるため、より高い値がアップデートとして提供されます。開発バージョンは変更点のみを比較します。 sha256 はオプションですが、存在すると確認されます。

各 url は .zip を指します (zip のみ)。アーカイブは正確に one top-level folder を保持し、IDE はそのフォルダーの contents を一部としてインストールします。そのため、ファームウェアアーカイブは次のようにパッケージ化されます。

acme-fw-1.2.0.zip
  acme-firmware/           one wrapping folder; its name does not matter
    settings.json
    ACME_CAM1/
      firmware.bin
      romfs0.img

そして、前に示した firmware/ フォルダーに解凍されます。サンプル、モデル、およびスタブアーカイブは同じ方法でパッケージ化されます。つまり、examples/、models/、または stubs/ 内に収まるものを保持する 1 つのラッピングフォルダーです。ラッピングフォルダーの名前は無視されます。重要なのは、まさに 1 つだけ存在するということです。ラップフォルダーを使用せずにアーカイブルートでファイルを圧縮したり、複数のフォルダーにラップしたりすると、インストールされません。これを正しく行う最も簡単な方法は、フォルダー自体を zip 圧縮することです。その内容を選択するのではなく、acme-firmware を選択して圧縮します。

13.1.14.6.2. ボード、サンプル、モデル、およびスタブ#

firmware/settings.json は、IDE に同梱されているファームウェアと同じボード記述形式を使用します。各ボードに boards エントリを追加します。サードパーティのボードに固有のルールがいくつかあります。 boardFirmwareFolder は一意でなければなりません (バイナリが存在するフォルダーに名前を付けるため、OpenMV や他のベンダーではまだ使用されていません)、各ボードは独自の firmware_version を持つ必要があります (これが接続時の更新プロンプトを駆動するものです)、ボードはそのボードのストックサンプルとモデルを継承するために boardFirmwareFolderAlias を OpenMV ボードのファームウェアフォルダー名に設定できます (エスケープハッチ) OpenMV とファームウェア互換性のあるボードの場合。 OpenMV ブートローダー識別子の再利用が期待されています (署名された Windows ドライバーが含まれています)。組み込みボードと衝突するアプリ識別子は、そのボードをオーバーライドし、オーバーライド警告パネルで報告されます。

例は、OpenMV の (01-Getting-Started) のような番号付きのカテゴリフォルダーに格納されます。 OpenMV と同じ名前を付けたカテゴリがその中にインターリーブされ、新しい名前が独自のメニューセクションになります。モデルは、その .tflite と対応するクラスラベル .txt を保持するフォルダーであり、その index.html (およびオプションの画像) が Model Zoo で横に表示される説明であるフォルダーの下にグループ化されます。 examples/index.csv と models/index.csv は、OpenMV 独自のサンプルとモデルが使用するのと同じボードフィルターファイルとセンサーフィルターファイルで、サンプルとモデルのパスと照合され、どのボードがどのボードに表示されるかを決定します。スタブは通常の .pyi ファイルです。 IDE はフォルダーを言語サーバーに渡して、OpenMV と並行して解決し、既存のモジュール (csi.pyi) にちなんで名付けられたスタブがそのモジュールの完了をオーバーライドします。

13.1.14.6.3. 公開と更新#

公開するには、config.json とそれが参照するアーカイブを安定した URL でホストし、インストール元の config.json URL をユーザーに提供します。 Web サーバー、オブジェクトストア、コードホストなど、HTTPS 経由でプレーンファイルを提供する場所ならどこでも機能します。アップデートを配布するには、新しいアーカイブをアップロードし、ホストされている config.json で影響を受ける version の値をバンプします。次に各ユーザーの IDE が起動するときに、アップデートが提供されます。インストーラーを介してリポジトリをインストールしたユーザーは、インストールされた config.json に configUrl が付いている限り、同じ方法でアップデートを取得します。

13.1.14.6.4. GitHub でのホスティング#

GitHub は便利なホストであり、IDE は独自のリソースを取得するのと同じ方法で GitHub から取得します。配置する部分は 2 つあります: マニフェストとアーカイブです。

config.json をリポジトリに保持し、その raw URL をユーザーに提供します。ファイルが表示される GitHub ページではなく、ファイルが直接提供されるアドレスです。ファイルの「Raw」ボタンにはそれが表示されます。それは形を持っています

https://raw.githubusercontent.com/<user>/<repo>/<branch>/config.json

その生の URL は、ユーザーが「URL からインストール」に貼り付けるものであり、マニフェスト自体の configUrl に入力するものであるため、IDE はそれを再フェッチして更新を確認します。ブランチ (main) を指すことは、新しいコミットをプッシュして変更を公開することを意味します。タグを指定すると、代わりにユーザーが固定バージョンに固定されます。

.zip アーカイブをコミットするのではなく、release assets としてホストします。リリースはバイナリダウンロード用に構築されているため、数メガバイトのファームウェアバンドルはリポジトリの履歴ではなく、そこに属します。各アーカイブを GitHub リリースに添付し、次の形式のダウンロード URL を使用します。

https://github.com/<user>/<repo>/releases/download/<tag>/acme-fw-1.2.0.zip

マニフェストの url フィールドに、それぞれアーカイブの sha256 が入ります。アップデートの出荷は、新しいアーカイブをリリースに添付し、config.jsonを編集してそれらをポイントし、バージョンを上げて、コミットすることになります。 IDE は次回の起動時に変更を取得します (生のファイルはキャッシュを通じて提供され、プッシュ後数分以内に更新されます)。