Az IDE szállítja az OpenMV saját kártyáit, firmware-jét, példáit, gépi tanulási modelljeit és szerkesztői csonkjait, de más cégektől is be tudja tölteni ugyanazokat a tartalmakat – egy partner által épített táblát, a rajta futó firmware-t, rá hangolt példákat és modelleket, valamint a firmware által hozzáadott API-k kódbefejezését. Ezek third-party repositories-ként érkeznek: tartalommappák, amelyeket az IDE egyesít a sajátjával, és naprakészen tartja.
Ennek az oldalnak két közönsége van. Legtöbbjük annak a személynek szól, aki telepíti és kezeli a valaki más által közzétett tárolót. Az utolsó szakasz, a authoring a repository, a szállító építése.
13.1.14.1. A Harmadik fél adattárai oldal
Minden a Szerkesztés → Beállítások → OpenMV → Harmadik fél adattárai menüpontból kezelhető. A táblázat felsorolja az összes telepített tárolót, és mindegyikhez annak megjelenítési nevét, rövid azonosítóját, legyen az Built-in vagy User, az egyes tartalomtípusok telepített verziója – firmware, példák, modellek, csonkok – és az URL, amelyről frissít.
A Built-in azt jelenti, hogy a lerakatot a szállító által szállított telepítő helyezte el az alkalmazás saját könyvtárába, ahogyan az illesztőprogram-csomag fájlokat ad hozzá a programhoz. Az User azt jelenti, hogy saját maga telepítette egy URL-ről. Az egyetlen gyakorlati különbség az, hogy a beépített tárolót nem távolíthatja el az IDE-ből – az eltávolításra kerül, ha eltávolítjuk azt, ami oda került –, így az Eltávolítás gomb le van tiltva.
13.1.14.2. Leraktár telepítése
A telepítés URL-ről kéri a tárhely config.json címét – a szállító által közzétett kis jegyzékfájlt –, és telepít mindent, amire mutat. Illessze be a szállítótól kapott URL-t; az IDE letölti a jegyzéket, lekéri a firmware-t, a példákat, a modelleket és a felsorolt csonkokat, és minden letöltést ellenőriz. A lerakat telepítése, eltávolítása és frissítése az újraindítás után lép életbe, így az IDE felajánlja az újraindítást, amikor a telepítés befejeződik.
A szállító telepítőként is terjeszthet egy lerakat, amely közvetlenül az alkalmazáskönyvtárba helyezi azt, ebben az esetben egyszerűen Built-in sorként jelenik meg az oldal első megnyitásakor – nincs mit telepíteni.
13.1.14.4. Prioritás és felülírások
A tárak egy rendezett lista, a legmagasabb prioritású a tetején, és a Move Up and Move Down átrendezi a kiválasztottat. A sorrend csak akkor számít, ha két forrás biztosítja a same dolgot: egy kártya azonos USB-azonosítóval, vagy egy példa, modell vagy csonk azonos névvel. Amikor ez megtörténik, a magasabb bejegyzés nyer, és minden adattár nyeri az OpenMV beépített tartalmát. Ez szándékos – így biztosítják a gyártók saját firmware-jét egy OpenMV kártya USB azonosítóját megosztó kártyához, lecserélve az IDE által egyébként kínált törzsszoftvert, vagy lecserélik a készletpéldát a saját hardverére írtkal.
Mivel a felülírás csendben megváltoztatja az ismerős név működését, az oldal soha nem rejt el semmit. A Felülírási figyelmeztetések panel felsorolja az összes hatályos felülbírálást – melyik lerakat táblája, példája, modellje vagy csonkja felülbírálja melyiket –, és ugyanez a lista egyszer megjelenik üzenetként, amikor egy tárat először látja. Ha egy tábla, példa vagy modell nem úgy viselkedik, ahogy az OpenMV dokumentációja leírja, akkor ezt a panelt érdemes először megnézni.
13.1.14.6. Adattár létrehozása
A tárház a szállító által elnevezett mappa, amely egy config.json jegyzéket és egy almappát tartalmaz minden általa biztosított tartalomtípushoz:
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
A mappa neve az adattár azonosítója: kisbetűk, számjegyek, - és _, betűvel kezdődően. Minden alkatrészmappa nem kötelező; csak azt szállítsd, ami van. Minden részmappa mellett található egy <part>.version fájl, amely egyetlen verziójú karakterláncot (1.2.0) tartalmaz, amelyet az IDE használ annak eldöntésére, hogy mikor legyen újabb frissítés.
13.1.14.6.1. A manifeszt
config.json megnevezi a tárolót, és minden résznél egy letölthető archívumra mutat:
{
"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 meg kell egyeznie a mappa nevével. configUrl az a cím, amelyen ugyanaz a fájl található; az IDE újra letölti, hogy ellenőrizze a frissítéseket, ezért csak olyan lerakat esetén hagyja ki, amely soha nem frissül. Mindegyik résznek van egy release csatornája, és a firmware-nek is lehet egy development csatornája, amelyet a legújabb fejlesztési kiadás telepítése használ. A version kiadás értékeit a rendszer számokként hasonlítja össze, így frissítésként magasabbat ajánl fel; a fejlesztési verziókat csak a változás miatt hasonlítják össze. Az sha256 nem kötelező, de ellenőrizve van, ha van.
Mindegyik url egy .zip-re mutat (csak zip). Egy archívum pontosan one top-level folder-et tartalmaz, és az IDE a mappa contents-jét telepíti alkatrészként – tehát a firmware-archívum a következőképpen van csomagolva:
acme-fw-1.2.0.zip
acme-firmware/ one wrapping folder; its name does not matter
settings.json
ACME_CAM1/
firmware.bin
romfs0.img
és kicsomagolja a korábban bemutatott firmware/ mappába. A példák, a modellek és a csonkok archívumai ugyanúgy vannak csomagolva – egy csomagolómappa, amely tartalmazza azt, ami a examples/, models/ vagy stubs/ belsejében található. A csomagoló mappa nevét figyelmen kívül hagyja; az a lényeg, hogy pontosan egy van. A fájlok tömörítése az archívum gyökérkönyvtárában csomagolómappa nélkül, vagy egynél több mappába csomagolva nem települ. A helyes megoldás legegyszerűbb módja, ha magát a mappát tömöríti – válassza ki a acme-firmware lehetőséget, és tömörítse, ahelyett, hogy kijelölné a tartalmát.
13.1.14.6.2. Táblák, példák, modellek és csonkok
firmware/settings.json ugyanazt a kártyaleírási formátumot használja, mint az IDE által szállított firmware; adj hozzá egy boards bejegyzést minden táblához. Néhány szabály a harmadik féltől származó táblákra vonatkozik: A boardFirmwareFolder egyedinek kell lennie (az OpenMV vagy más gyártó még nem használja, mivel megnevezi azt a mappát, amelyben a bináris fájljai élnek), minden kártyának tartalmaznia kell a saját firmware_version-jét (ez hajtja a frissítést a csatlakozáskor), és a kártya beállíthatja a boardFirmwareFolderAlias értéket egy OpenMV kártya firmware-mappájára – a kártyatípusok esetén az escape-mappa neve a készletben. firmware kompatibilis egy OpenMV-vel. Az OpenMV rendszerbetöltő azonosítók újrafelhasználása várható (az aláírt Windows illesztőprogramokat hordozzák); egy beépített kártyával ütköző alkalmazásazonosító felülírja az adott kártyát, amiről a Felülbírálási figyelmeztetések panel jelent.
A példák a számozott kategóriájú mappákban találhatók, mint például az OpenMV-k (01-Getting-Started); egy kategória, amelyet ugyanúgy elnevez, mint egy OpenMV-t, beépül bele, és egy új név lesz a saját menürésze. A modell egy mappa, amelyben a .tflite és a hozzá tartozó .txt osztálycímkék vannak, egy mappa alá csoportosítva, amelynek index.html (és egy opcionális kép) a mellette látható leírás a Modell Állatkertben. A examples/index.csv és models/index.csv ugyanazok a kártya- és érzékelőszűrő-fájlok, amelyeket az OpenMV saját példái és modelljei használnak, összeillesztve az Ön példa- és modellútvonalaival, és eldöntheti, hogy melyik kártyán jelenjen meg az Öné. A csonkok közönséges .pyi fájlok; az IDE átadja a mappáját a nyelvi szervernek, hogy az OpenMV-vel együtt oldja meg, és egy meglévő modulhoz elnevezett csonk (csi.pyi) felülírja a modul befejezését.
13.1.14.6.3. Közzététel és frissítés
A közzétételhez stabil URL-címeken tárolja a config.json-et és az archívumokat, amelyekre hivatkozik, és adja meg a felhasználóknak az config.json URL-t a telepítéshez. Bárhol működik, ahol egyszerű fájlokat szolgálnak ki HTTPS-en keresztül – webszerver, objektumtároló vagy kódgazda. Frissítés elküldéséhez töltsön fel új archívumot, helyezze az érintett version értékeket a tárolt config.json közé, és a következő alkalommal, amikor minden felhasználó IDE-je elindul, felajánlja a frissítést. Azok a felhasználók, akik ehelyett telepítőn keresztül telepítették a tárolót, ugyanúgy kapnak frissítést, ha a telepített config.json configUrl-t hordoz.
13.1.14.6.4. Tárhely a GitHubon
A GitHub kényelmes gazdagép, és az IDE ugyanúgy letölti belőle, mint a saját erőforrásait. Két darabot kell elhelyezni: a manifestet és az archívumot.
Tartsa a config.json-et egy adattárban, és adja meg a felhasználóknak annak raw URL-jét – a címet, amelyen a fájl közvetlenül kiszolgálásra kerül, nem pedig az azt megjelenítő GitHub-oldalon. A fájl Nyers gombja mutatja; megvan a formája
https://raw.githubusercontent.com/<user>/<repo>/<branch>/config.json
Ezt a nyers URL-t a felhasználó beilleszti a Telepítés URL-ből mezőbe, és amit a jegyzék saját configUrl-jébe ír be, így az IDE újra lekéri, hogy ellenőrizze a frissítéseket. Ha egy ágra mutat (main) azt jelenti, hogy egy új véglegesítés leküldése közzéteszi a változást; egy címkére mutatva a felhasználókat egy fix verzióhoz rögzíti.
A .zip archívumokat release assets-ként tárolja, ahelyett, hogy véglegesítené őket – a kiadások bináris letöltésekhez készültek, így egy több megabájtos firmware-köteg oda tartozik, nem pedig a tároló történetébe. Csatolja az egyes archívumokat egy GitHub-kiadáshoz, és használja a letöltési URL-címét, amely tartalmazza az űrlapot
https://github.com/<user>/<repo>/releases/download/<tag>/acme-fw-1.2.0.zip
a jegyzék url mezőiben, mindegyikben az archívum sha256. A frissítés szállítása ezután a következő: csatolja az új archívumot egy kiadáshoz, szerkessze a config.json-et, hogy rájuk mutasson, és a verziókat érintse, majd véglegesítse. Az IDE a következő indításkor veszi fel a változást (a nyers fájlt egy gyorsítótáron keresztül szolgálják ki, amely a leküldést követően néhány percen belül frissül).