Jak vyvíjet vlastní software pro Rokid AI Glasses Enterprise

Shrnutí

Rokid AI Glasses Enterprise lze pomocí vývoje proměnit v účelově navržené firemní zařízení, místo aby se používaly jen s předkonfigurovanými aplikacemi. Aktuální dokumentace Rokid Sprite Enterprise zpřístupňuje Glasses SDK pro aplikace běžící přímo na Glass3, Phone SDK pro doprovodné aplikace pro Android a služby OpenAPI pro cloudové integrace. Tyto vrstvy společně podporují konektivitu zařízení, zasílání zpráv, přenos souborů, snímání kamerou a záznam médií, živé video, hlasové funkce, služby AI, rozpoznávání, stav zařízení a podnikové pracovní postupy.

Pro vývojářský tým je praktický postup povědomý: vytvořit nativní projekty pro Android v Android Studiu, přidat Maven repozitář a závislosti SDK od Rokidu, spustit oficiální demo Rokidu složené ze dvou projektů, navázat Bluetooth pro vyhledání a ovládání, pro velké soubory a audio/video přepnout na Wi-Fi P2P a poté propojit pracovní postup s firemním backendem. Možná je i samostatná aplikace pro brýle, pokud daný případ užití nevyžaduje doprovodný telefon.

Nad rámec samotného SDK plyne hlavní přínos z nahrazení obecného zážitku z nositelného zařízení řízeným pracovním postupem. Technik může obdržet pracovní příkaz, vidět na displeji další pokyn, potvrdit krok hlasem nebo hardwarovým vstupem, pořídit vizuální důkaz a odeslat výsledek do systému CMMS, ERP nebo vlastní platformy. Díky tomu jsou brýle relevantní pro inspekce, servis v terénu, řízenou práci, logistiku, dokumentaci a další procesy bez použití rukou. Hlavními výhradami jsou nativní podpora SDK pouze pro Android, kompatibilita verzí a OTA, požadavek na API klíč u vybraných online služeb a kompaktní displej 480 x 640, který vyžaduje promyšlený návrh UI.

Co Rokid zpřístupňuje vývojářům

Rokid rozděluje podnikovou sadu nástrojů na dvoustranné SDK a samostatnou platformu OpenAPI. Pochopení tohoto rozdělení ještě před psaním kódu pomáhá předejít častému omylu: snaze přimět brýle dělat všechno, i když se telefon nebo backend pro síťovou komunikaci, ověřování, ukládání dat nebo integraci s firemními systémy hodí lépe.

Aplikace pro brýle:

• Běží na: Rokid Glass3
• Typická úloha: Vykresluje UI nositelného zařízení a prostřednictvím Glasses SDK přistupuje k funkcím na straně brýlí, jako jsou kamera/média, stav zařízení, zprávy, hlas, AI a rozpoznávání.

Doprovodná aplikace:

• Běží na: Telefon s Androidem
• Typická úloha: Vyhledává Glass3 a připojuje se k nim, spravuje Bluetooth a Wi-Fi P2P, vyměňuje zprávy/soubory, přijímá mediální streamy a může předávat firemní data.

Cloudová / firemní vrstva:

• Běží na: Váš backend + Rokid OpenAPI, kde je to relevantní
• Typická úloha: Ukládá firemní data, ověřuje uživatele, propojuje systémy ERP/CMMS/CRM a po zřízení může využívat moduly Rokid OpenAPI, například API pro zasílání zpráv nebo API zařízení.

Praktický verdikt: Pro vlastní podnikový software je užitečnou architekturou obvykle „tenké UI na nositelném zařízení + spolehlivé služby zařízení + obchodní logika v telefonu/na backendu“. Soustředěné prostředí v brýlích snižuje složitost UI a usnadňuje údržbu projektu, a přitom zachovává ovládání bez rukou tam, kde na něm záleží.

Vývojová sada nástrojů v kostce

• Cílový hardware ve veřejné podnikové dokumentaci: Rokid Glass3
• Vývojový model: Vývoj nativních aplikací pro Android
• Artefakt Glasses SDK: com.rokid.security:glass3.open.sdk
• Artefakt Phone SDK: com.rokid.security:phone.sdk
• Aktuální závislost uvedená v Quick Startu: 2.2.0-E pro obě SDK
• Nejnovější viditelný záznam v changelogu v době průzkumu: V2.2.0-E z 6. srpna 2026 s doporučenou OTA 1.19.e006-20260806-150201 nebo novější.
• Doporučené nástroje: Android Studio 2022+, JDK 17+
• Demo prostředí: Android SDK 34, JDK 17, telefon s Androidem, Rokid Glass3
• Souřadnicový systém displeje brýlí: Pevný 480 x 640, na výšku
• Hlavní lokální přenosové kanály: Klasické Bluetooth a Wi-Fi P2P
• Cloudové ověřování: Podnikový API klíč pro Rokid OpenAPI a vybrané online služby
• Podporovaná platforma telefonu: Android; podle veřejných FAQ Glass3 SDK nepodporuje iOS ani nativní HarmonyOS

Co můžete s Rokid AI Glasses Enterprise vytvořit?

Veřejné SDK je dostatečně široké, aby podpořilo víc než jedinou demo aplikaci. Jaký konkrétní produkt vytvoříte, závisí na tom, které funkce zkombinujete a kolik logiky ponecháte na nositelném zařízení.

Řízený servis v terénu: zobrazovat vždy jeden pokyn, potvrzovat dokončení, pořizovat fotografie nebo video a vracet strukturované důkazy do systému pracovních příkazů.

Inspekce a dodržování předpisů: zobrazovat kontrolní seznamy, využívat snímání kamerou nebo rozpoznávání, přikládat důkazy s časovým razítkem a eskalovat výjimky.

Skladové a logistické procesy: zobrazovat informace o vychystávání nebo úkolech, vyměňovat jednoduché příkazy přes Bluetooth a tam, kde je to nutné, využívat specializované integrace skenování.

Vzdálená vizuální asistence: přijímat živý videostream na straně doprovodného zařízení nebo integrovat vyhrazenou cestu pro vzdálenou spolupráci. Rokid ve verzi 2.1.7-E odstranil z jádra Phone SDK volání RTC, takže spolupráci v reálném čase je třeba navrhnout s využitím Remote Collaboration SDK od Rokidu pro Android a web nebo vlastního schváleného přenosu, a ne předpokládat, že je zabudována v základním SDK.

Podnikový asistent AI: kombinovat hlasový vstup, TTS, chat s AI nebo firemní služby AI s UI přizpůsobeným konkrétnímu pracovnímu postupu, místo aby se uživatelé potýkali s obecným chatbotem.

Pořizování důkazů a dokumentace: spouštět pořízení snímků, videa nebo zvuku, přenášet větší média přes P2P a synchronizovat výsledky s backendem.

Vyhrazené jednoúčelové nositelné zařízení: automaticky spouštět firemní aplikaci po restartu a mapovat podporované hardwarové události na akce v pracovním postupu, s výhradou ověření na cílovém firmwaru.

Krok za krokem: jak vyvíjet vlastní software pro Rokid AI Glasses Enterprise

Krok 1: Před volbou architektury definujte pracovní postup

Začněte provozním procesem, ne seznamem SDK. Sepište přesně, co musí pracovník vidět, říct, zachytit a potvrdit. Pak rozhodněte, které zařízení má za kterou úlohu odpovídat. Dobře vymezená aplikace pro nositelné zařízení obvykle zobrazuje stručné informace a zachycuje vstupy, zatímco náročnější obchodní logiku obstarává telefon nebo backend.

Samostatná aplikace pro brýle:

• Nejvhodnější pro: Jednoduchý lokální pracovní postup, snímání na straně zařízení, provoz offline nebo s omezenou konektivitou
• Výhody: Méně komponent, přímý zážitek z nositelného zařízení
• Kompromis: Více logiky pro úložiště/síť musíte řešit na brýlích; některé online funkce i tak vyžadují přihlašovací údaje nebo konektivitu

Brýle + telefon s Androidem:

• Nejvhodnější pro: Většina podnikových pilotů, živá média, přenos souborů, dálkové ovládání, doprovodná firemní aplikace
• Výhody: Nejlépe zdokumentovaná cesta konektivity; telefon může obstarat ověřování, síťovou komunikaci a UI, které do čočky nepatří
• Kompromis: Vyžaduje telefon s Androidem a robustní logiku opětovného připojení

Brýle + telefon + backend:

• Nejvhodnější pro: Integrace s ERP/CMMS/CRM, auditní stopa, centrálně spravované pracovní příkazy, služby AI
• Výhody: Nejvhodnější pro škálovatelné firemní pracovní postupy a správu dat
• Kompromis: Vyžaduje více integrační, bezpečnostní a backendové práce

Doporučení: Pro první B2B proof of concept použijte model brýle + telefon s Androidem + backend, pokud daný případ užití zjevně nevyužije samostatné nositelné zařízení. Tento model úzce odpovídá zdokumentovanému toku Rokidu se dvěma zařízeními a dává vývojovému týmu prostor přesunout síťovou komunikaci, přihlašovací údaje a ukládání dat mimo brýle.

Krok 2: Opatřete si správný hardware a přístupy

Před instalací Android Studia ověřte, že hardware skutečně běží na podnikové softwarové větvi. Podle FAQ Rokidu podnikové/pracovní buildy obvykle obsahují ve verzi systému „e“. Dokumentace SDK také rozlišuje podnikové a spotřebitelské systémy, takže identifikace firmwaru je součástí nastavení projektu, nikoli něčím, co se řeší až dodatečně.

Rokid AI Glasses Enterprise (hardware Rokid Glasses) s podnikovým buildem systému / firmwarem (verze systému končící na „e“).

Datový ladicí kabel Glass3. Rokid výslovně upozorňuje, že běžný nabíjecí kabel sice brýle napájí, ale Android Studio ho k ladění použít nemůže.

Telefon s Androidem, pokud používáte Phone SDK.

Vývojový počítač s Android Studiem a JDK 17.

Podnikový účet a API klíč, pokud bude projekt využívat Rokid OpenAPI nebo online funkce vyžadující ověření.

Přístup k přesné verzi OTA, kterou plánujete nasadit v celé pilotní flotile.

Kontrolu kabelu nevynechávejte: Rokid uvádí datový ladicí kabel jako povinný, protože umožňuje Android Studiu rozpoznat brýle, instalovat APK a prohlížet logy. Pokud se brýle nabíjejí, ale nezobrazují se jako zařízení, zkontrolujte kabel dřív, než začnete ladit Gradle, ADB nebo SDK.

Krok 3: Připravte vývojové prostředí pro Android

Quick Start od Rokidu doporučuje Android Studio 2022 nebo novější a JDK 17 nebo novější a uvádí, že Glass3 SDK podporuje Android 8.0 nebo novější. Oficiální průvodce demem aktuálně používá Android SDK 34. FAQ Rokidu zvlášť doporučuje Android 7.0 / API 24 nebo novější a radí ověřit konfiguraci Gradle v aktuálním balíčku SDK a demu. U skutečného projektu považujte soubory Gradle z dema za směrodatný zdroj pro konkrétní vydání, které integrujete.

1. Nainstalujte Android Studio 2022 nebo novější.

1. Nainstalujte JDK 17 nebo novější a zvolte ho pro Gradle.

1. Nainstalujte verzi Android SDK, kterou vyžaduje aktuální demo Rokidu. Současný průvodce demem uvádí SDK 34.

1. Na vývojovém telefonu povolte běžné ladění Androidu.

1. Připojte Glass3 datovým ladicím kabelem a ověřte, že Android Studio vidí cílové zařízení podobné „Rokid RG-glasses“.

1. Pokud chcete UI nositelného zařízení sledovat z počítače, nainstalujte nástroj Rokidu pro projekci / zrcadlení obrazovky. Rokid během vývoje projekci důrazně doporučuje.

Krok 4: Než vytvoříte vlastní aplikaci, spusťte oficiální demo Rokidu

Toto je nejdůležitější praktický krok celého procesu. Oficiální demo ověří vývojové prostředí, binární soubory SDK, oprávnění, hardwarová propojení a kombinaci verzí dřív, než se další proměnnou stane váš vlastní kód.

git clone https://gitee.com/as_pixar/glass3sdkdemo.git

# Demo pro brýle
cd glassdemo
./gradlew assembleDebug

# Demo pro telefon
cd ../glass3sdkphonedemo
./gradlew assembleDebug

Repozitář obsahuje dva samostatné projekty pro Android: jeden pro brýle a jeden pro telefon s Androidem. Rokid doporučuje spustit nejprve demo na straně telefonu a poté demo na straně brýlí. Po instalaci obou vyhledejte z dema v telefonu Glass3 a navažte spojení.

1. Inicializace SDK. Podmínka úspěchu: Oba projekty se spustí a hlásí platný stav SDK.
2. Bluetooth. Podmínka úspěchu: Telefon najde Glass3 a připojí se k nim.
3. Zasílání zpráv. Podmínka úspěchu: Mezi telefonem a brýlemi lze přenášet textové nebo řídicí zprávy.
4. Přenos malých souborů. Podmínka úspěchu: Malý soubor lze vyměnit bez chyb.
5. Wi-Fi P2P. Podmínka úspěchu: Lze navázat kanál P2P pro operace s vysokou šířkou pásma.
6. Média. Podmínka úspěchu: Lze spustit a přijmout fotografii, video nebo živý náhled.

Proč na tom záleží z obchodního hlediska: Proof of concept pro zákazníka se mnohem snáz vymezuje, když se nejprve ověří základní funkce zařízení. Projektový čas pak můžete věnovat samotnému pracovnímu postupu, integraci a uživatelskému zážitku, místo abyste diagnostikovali neověřené nastavení SDK.

Krok 5: Vytvořte vlastní projekty a přidejte Maven repozitář Rokidu

Jakmile demo funguje, vytvořte nebo otevřete vlastní projekty pro Android. Rokid publikuje artefakty SDK prostřednictvím svého Maven repozitáře. Přidejte repozitář vedle Google a Maven Central a poté přidejte závislost pro brýle do aplikace pro nositelné zařízení a závislost pro telefon do doprovodné aplikace.

// settings.gradle - zjednodušený příklad
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
        maven { url 'https://maven.rokid.com/repository/maven-public/' }
    }
}

// Aplikace pro brýle
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

// Aplikace pro telefon s Androidem
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

Aktuální Quick Start od Rokidu uvádí verzi 2.2.0-E s doporučenou OTA 1.19.e006-20260806-150201 nebo novější. Podnikové týmy by měly zafixovat a otestovat známou kombinaci SDK + OTA, místo aby komponenty automaticky aktualizovaly nezávisle na sobě.

Pravidlo správy verzí: Před pilotním nebo produkčním vydáním zaznamenejte do jedné matice kompatibility build OTA brýlí, verzi Glasses SDK, verzi Phone SDK, commit dema a verze všech specializovaných SDK. Kdykoli se některá z těchto komponent změní, znovu spusťte základní testy připojení a médií.

Krok 6: Deklarujte jen ta oprávnění Androidu, která váš pracovní postup potřebuje

Quick Start od Rokidu uvádí běžná oprávnění pro přístup k síti, Wi-Fi, kameru, mikrofon, úložiště, Bluetooth a zařízení v okolí. U moderních verzí Androidu nestačí nebezpečná oprávnění jen deklarovat v manifestu. Vaše aplikace pro telefon i brýle musí potřebná oprávnění vyžádat za běhu a čistě ošetřit jejich odmítnutí.

• Vyhledávání/připojení Bluetooth: Vyhledání zařízení, párování, malé zprávy a ovládání
• Wi-Fi v okolí / Wi-Fi Direct: Spojení P2P pro soubory, obrázky, video a streamy v reálném čase
• Kamera: Pořizování fotografií/videa a toky vizuálního rozpoznávání
• Mikrofon: Nahrávání zvuku, ASR a hlasová interakce
• Síť / internet: Backendová API, online služby Rokidu, cloudová synchronizace
• Úložiště: Práce s médii a přenesenými soubory v závislosti na chování cílové verze Androidu / SDK

Rada pro produkci: Nekopírujte slepě celý manifest z dema. Minimalizace oprávnění usnadňuje bezpečnostní revizi a snižuje pravděpodobnost, že uživatelé odmítnou oprávnění, které pracovní postup ve skutečnosti nepotřebuje.

Krok 7: Inicializujte Glasses SDK a zaregistrujte identitu aplikace

Aplikace pro brýle se naváže na bezpečnostní službu Rokidu a poté zaregistruje identifikátor klienta. Důležitým architektonickým pravidlem je, že stejné ID klienta zná i doprovodná aplikace v telefonu, když si obě strany vyměňují zprávy specifické pro aplikaci.

// Ilustrativní struktura, zjednodušená podle inicializačního toku Rokidu
if (!GlassSdk.isReady()) {
    GlassSdk.bindSecurityService(context, object : IServiceConnectionCallback {
        override fun onServiceConnected() {
            GlassSdk.registerClient("FieldServiceApp", messageCallback)
        }
    })
}

Po inicializaci se k funkcím na straně brýlí přistupuje prostřednictvím vstupních bodů služeb, které zpřístupňuje GlassSdk. Veřejné skupiny API zahrnují běžné funkce a funkce zařízení, klasické Bluetooth, P2P, zasílání zpráv, média, práci se soubory, hlas/AI, rozpoznávání a další služby. Neinicializujte při spuštění všechny funkce. Získejte a aktivujte jen služby potřebné pro aktuální obrazovku nebo fázi pracovního postupu.

Kontrola stavu: Před voláním služeb jednotlivých funkcí použijte GlassSdk.isReady() jako jednoduchý diagnostický signál. Pokud vrací false, opravte inicializaci nebo navázání služby dřív, než začnete testovat funkce vyšší úrovně.

Krok 8: Inicializujte Android Phone SDK s odpovídajícími ID klientů

Na straně telefonu inicializujte mobilní engine Rokidu a zaregistrujte ID klientů, se kterými bude telefon komunikovat. Phone SDK od Rokidu je vrstva pro připojení a ovládání, která zajišťuje vyhledávání zařízení, Bluetooth/P2P, zasílání zpráv, soubory, příjem médií, synchronizaci konfigurace a související operace.

// Nástin na úrovni aplikace
val engineParam = EngineParam.Builder()
    .setClientIds(listOf("FieldServiceApp"))
    .setApiKeyCredentials(apiKeyCredentials)
    .build()
IMobileEngine.initSDK(engineParam)

// Diagnostická kontrola
val ready = PSecuritySDK.getMobileEngineService().isInit()

Pokud vybrané online funkce vyžadují API Key Credentials, obsahuje demo zástupné ověřovací údaje, které je nutné nahradit přihlašovacími údaji získanými prostřednictvím obchodního procesu Rokidu. Cloudová tajemství neukládejte do správy zdrojového kódu a nevkládejte dlouhodobě platné API klíče platformy do distribuovatelné klientské aplikace.

Krok 9: Nejprve se připojte přes Bluetooth, pro šířku pásma pak použijte P2P

Rokid dokumentuje dva vzory lokálního přenosu s odlišnými úlohami. Klasické Bluetooth se hodí pro vyhledávání, připojení, řídicí zprávy a malé soubory. Wi-Fi P2P je lepší kanál pro obrázky, velké soubory, video a média v reálném čase. Volba nesprávného přenosu je snadný způsob, jak vytvořit aplikaci, která v demu funguje, ale v terénu působí nespolehlivě.

Klasické Bluetooth:

• Použijte ho pro: Vyhledávání, párování, řídicí příkazy, kompaktní zprávy JSON, malé soubory
• Role v návrhu: Řídicí rovina s nízkou šířkou pásma

Wi-Fi P2P:

• Použijte ho pro: Velké soubory, obrázky, video, audio/video streamy, synchronizace s vysokou propustností
• Role v návrhu: Datová rovina s vysokou šířkou pásma

Přímé Wi-Fi brýlí:

• Použijte ho pro: Přístup k backendu z aplikace pro brýle, když je zařízení připojeno k Wi-Fi
• Role v návrhu: Užitečné pro vybrané samostatné toky; i tak navrhněte chování offline a při opakování pokusů

Robustní podniková aplikace by měla připojení chápat jako stavové automaty, nikoli jako jednorázové události. Explicitně ošetřete ztrátu Bluetooth, ukončení P2P, uspání telefonu, změny Wi-Fi a restart brýlí. Uživatel by měl dostat jednoduchý stav, například „znovu se připojuje“ nebo „čeká na synchronizaci“, nikoli výjimku Androidu nebo tiché selhání.

Krok 10: Definujte malý aplikační protokol pro firemní zprávy

Rokid poskytuje přenosové a zprávové služby, ale vaše aplikace stále potřebuje kontrakt určující, co firemní zpráva znamená. Udržujte tento kontrakt kompaktní, verzovaný a nezávislý na UI. JSON je pro rané projekty praktickou volbou, protože se snadno kontroluje, i když přesný formát dat je věcí návrhu vaší aplikace, nikoli požadavkem Rokidu.

{
  "schema": 1,
  "type": "WORK_STEP",
  "workOrderId": "WO-10458",
  "step": 3,
  "title": "Check valve pressure",
  "requiresPhoto": true
}

Po dokončení mohou brýle vrátit malou stavovou zprávu, která odkazuje na ID pracovního příkazu a číslo kroku. Samotný mediální soubor by měl putovat cestou P2P pro soubory/média, a ne být vložen do řídicí zprávy. Toto oddělení udržuje příkazový kanál pohotový a zjednodušuje opakování pokusů.

Krok 11: Navrhněte UI brýlí pro 480 x 640, ne jako aplikaci pro telefon

Displej Glass3 používá pevný souřadnicový systém 480 x 640 na výšku. FAQ Rokidu doporučuje umístit hlavní obsah do centrální oblasti 480 x 400, horních 160 pixelů a spodních 80 pixelů využít pro doplňující informace a důležitý obsah posunout níž, protože v horních zhruba 40 pixelech se může objevit optický odraz. Operační systém neumožňuje běžné otáčení displeje, takže široká rozvržení je nutné navrhnout v rámci plátna na výšku.

Zobrazujte vždy jen jeden úkol, pokyn nebo rozhodnutí. Dlouhé dashboardy se pro čočku nehodí.

Kde je to možné, použijte černé pozadí. Rokid ho doporučuje kvůli omezení vnímaného blikání při spouštění nebo přechodech.

Kritický text ani tlačítka neumisťujte do oblasti odrazu v horních ~40 px.

Změny stavu musí být zřejmé i bez složitého barevného kódování. Rokid doporučuje jako hlavní vizuální styl zelenou.

Zajistěte jasnou indikaci stavu připojení a jasný stav „synchronizováno / čeká“ u firemních dat.

Ovládací prvky udržujte tak jednoduché, aby je šlo ovládat podporovaným hardwarovým vstupem nebo hlasem bez nutnosti přesné navigace ve stylu dotykového ovládání.

Dopad na firmu: Displej je malý, ale u procedurální práce to může být výhoda. Vede softwarové týmy k tomu, aby odstranily nepodstatné informace a zobrazovaly jen další krok, který pracovník potřebuje.

Krok 12: Přidejte funkce kamery, fotografií, videa a živého náhledu

Glasses SDK zpřístupňuje mediální funkce pro fotografie, video, zvuk a náhled. Phone SDK dokáže z brýlí přijímat mediální streamy. FAQ Rokidu uvádí výchozí videostream 1080P se zhruba 15 až 19 snímky za sekundu a latencí přehrávání v telefonu přibližně 300 ms a poznamenává, že výstupem může být H.264 nebo dekódovaný NV21 v závislosti na API a cestě v demu. Tyto hodnoty berte jako aktuální vodítko k implementaci, nikoli jako garantovanou SLA.

Statické snímky používejte pro důkazy z inspekcí, doložení dokončení a pozdější zpracování pomocí AI.

H.264 použijte, když telefon nebo backend potřebuje stream hlavně přeposílat nebo ukládat. Changelog Rokidu k verzi 2.1.8-E přidal ovládání automatického dekódování H.264 na NV21, takže se lze vyhnout zbytečnému dekódování.

NV21 použijte, když dekódované snímky potřebuje pipeline počítačového vidění na straně telefonu.

Pro živý náhled a přenos médií používejte Wi-Fi P2P, nikoli klasické Bluetooth.

Pokud v nahraném výstupu potřebujete kameru spolu s překryvem z displeje, prostudujte aktuální API Rokidu pro AR Mix / AR záznam a slaďte je s nainstalovanou verzí SDK.

Jeden praktický detail z FAQ Rokidu je důležitý pro procesy pořizování důkazů: po úspěšném nahrání přes P2P může systém obrázky v brýlích odstranit. Za směrodatný zdroj pro firmu považujte úspěšně přijatou kopii v telefonu nebo na backendu a před posunem pracovního příkazu dál ověřte dokončení nahrání.

Krok 13: Hlas, TTS a AI přidávejte uvážlivě

Hlas může být cenný, když pracovníci nemohou používat ruce, měl by však být vázán na explicitní akce v pracovním postupu. Dokumentace SDK na straně brýlí zpřístupňuje funkce ASR, TTS, zpracování offline příkazů a chatu s AI. FAQ v současnosti uvádí, že offline TTS vyžaduje SDK 2.2.0 nebo novější, ačkoli changelog uvádí službu offline TTS již od verze 2.1.2; otestujte ji na své zafixované verzi. Volné offline ASR není ve výchozím stavu aktuálně podporováno. Pro offline převod řeči na text odkazuje Rokid vývojáře na soukromé služby ASR/TTS, místo aby tvrdil, že existuje vestavěná cesta pro offline ASR.

Offline povelová slova:

• Vhodné použití: Krátké pevné povely jako „další“, „zpět“, „pořídit“
• Poznámka k podnikovému návrhu: Vhodné pro deterministické ovládání bez rukou

Online ASR:

• Vhodné použití: Volný převod řeči na text
• Poznámka k podnikovému návrhu: Vyžaduje nastavení sítě/služby a mělo by mít záložní chování

TTS / offline TTS:

• Vhodné použití: Předčítání výzev, varování nebo krátkých potvrzení
• Poznámka k podnikovému návrhu: Užitečné, když má displej zůstat minimalistický

Chat s AI / soukromá AI:

• Vhodné použití: Kontextová asistence nebo tlumočení
• Poznámka k podnikovému návrhu: Model držte až za pracovním postupem. Ověřte nakládání s daty, latenci a hranice odpovědí.

Krok 14: Bezpečně propojte pracovní postup s backendem

U backendu jde o dvě samostatné otázky: jak se vaše vlastní aplikace dostane k firemním systémům a zda budete používat Rokid OpenAPI. Vaše aplikace může odesílat data přes spárovaný telefon, nebo může aplikace pro brýle přistupovat k internetu přímo, když jsou Glass3 připojeny k Wi-Fi. U firemních systémů jsou standardní backendová API obvykle nejčistším integračním bodem, protože přihlašovací údaje, auditní logy, validace dat a obchodní pravidla zůstávají na straně serveru.

Rokid OpenAPI je samostatná platformní vrstva. Oficiální dokumentace vyžaduje aktivovaný podnikový účet a API klíč. Požadavky se ověřují tokenem Bearer, vytvořené klíče mají omezenou platnost a výchozí doba platnosti je jeden měsíc, pokud není nastaveno jinak. Rokid výslovně varuje, aby API klíče nebyly zveřejněny ve veřejných repozitářích ani v klientech.

Bezpečnostní pravidlo: Kdykoli to architektura dovolí, používejte pro přihlašovací údaje k platformě Rokid proxy na straně serveru. APK pro telefon nebo brýle lze prozkoumat. Nepředpokládejte, že API klíč zůstane tajný jen proto, že ho ukryjete v Kotlinu nebo nativním kódu.

Aktuální moduly Rokid OpenAPI zahrnují mimo jiné podnikové funkce také API pro zasílání zpráv a API zařízení (k těmto API je však možné přistupovat pouze tehdy, jsou-li zařízení zaregistrována v konzoli Lingmou od Rokidu). API zařízení například umožňuje dotazovat se na registrované jednotky Glass, zatímco API zpráv dokáže odeslat firemní zprávu na cílové zařízení. Tyto služby používejte jen tehdy, když řeší skutečný požadavek nasazení. Správným místem pro ERP, CMMS, CRM, správu identit a orchestraci pracovních postupů zůstává vlastní firemní backend.

Krok 15: Nakonfigurujte podnikové chování, například automatické spouštění a obsluhu tlačítek

Nositelné zařízení je v provozu užitečnější, když uživatel nemusí každé ráno procházet spouštěč ve spotřebitelském stylu. Rokid dokumentuje mechanismus automatického spouštění, který na podporovaných podnikových systémech dokáže po startu spustit nakonfigurovanou aplikaci. Dokumentuje také přizpůsobení hardwarových událostí a v changelogu verze 2.1.9-E i API pro naslouchání událostem a jejich zachytávání.

Automatické spouštění používejte pro vyhrazené inspekční, bezpečnostní nebo průmyslové procesy, kde se mají brýle otevřít přímo do firemní aplikace.

Práci závislou na SDK po startu krátce odložte a před spuštěním pracovního postupu ověřte připravenost služeb.

Podporované události tlačítek mapujte na malý počet smysluplných akcí, jako je potvrzení, pořízení snímku nebo zrušení.

Každou funkci automatického spouštění nebo zachytávání ověřte na cílovém podnikovém firmwaru, protože některé chování na úrovni systému závisí na verzi.

Vždy zachovejte cestu pro podporu/obnovu. Uzamčený pracovní postup, který administrátor nemůže ukončit, představuje provozní riziko.

Krok 16: Zajistěte chování offline, opakování pokusů a obnovu

Demo často předpokládá dokonalé Bluetooth, Wi-Fi a přístup ke cloudu. Nasazení v terénu si to dovolit nemůže. Ukládejte minimální stav pracovního postupu potřebný k tomu, aby přežil odpojení telefonu, selhání P2P nebo dočasný výpadek sítě. Každá obchodní akce by měla být pokud možno idempotentní, aby opakovaný pokus nevytvořil duplicitní události pracovního příkazu nebo záznamy médií.

Ukládejte do mezipaměti aktuální ID pracovního příkazu, ID kroku a poslední potvrzenou akci.

Neodeslané výsledky řaďte do fronty s viditelným stavem „čeká na synchronizaci“.

Používejte jedinečná ID operací, aby backend mohl duplicity bezpečně odmítnout.

Nejprve obnovte připojení Bluetooth a P2P znovu sestavujte jen tehdy, je-li potřeba přenos s vysokou šířkou pásma.

Krok závislý na médiích nikdy neoznačujte jako dokončený, dokud nebude potvrzeno přijetí cílové kopie.

Zajistěte pro uživatele bezpečné záložní řešení pro případ, že online ASR nebo AI nebude k dispozici. Základní navigaci mohou i tak pokrýt pevné offline povely.

Krok 17: Testujte na skutečném hardwaru s podnikovou testovací maticí

Emulátory u projektu s brýlemi nestačí, protože optika, tepelné chování, Bluetooth, P2P, kamera, mikrofon i pohodlí při nošení ovlivňují zážitek ze softwaru. Celý systém otestujte přesně na té podnikové OTA, která je plánována pro pilot.

• Start a automatické spouštění: Studený start, spuštění aplikace, připravenost SDK, obnova při pomalém navazování služby
• Bluetooth: První párování, opětovné připojení, uspání telefonu, obnova po ztrátě dosahu
• P2P: Opakované připojení/odpojení, velký soubor, živý stream, změny Wi-Fi
• Oprávnění: Čerstvá instalace, odmítnuté oprávnění, pozdější udělení, rozdíly mezi verzemi Androidu
• Média: Kvalita fotografií/videa, potvrzení přijetí souboru, opakování neúspěšného nahrání, čištění úložiště
• Hlas: Hlučné prostředí, žádná síť, nepodporovaná fráze, přerušení TTS
• UI / optika: Čitelnost, horní oblast odrazu, dlouhý text, viditelnost stavu, únava uživatele
• Výkon: Dlouhá relace, teplota CPU, dostupná paměť, přežití procesu
• Backend: Pomalá odezva, duplicitní požadavek, vypršelý token, nedostupný server
• Zabezpečení: Nakládání s přihlašovacími údaji, redakce logů, ztráta zařízení, odvolání účtu

FAQ Rokidu výslovně doporučuje při řešení výkonnostních problémů sledovat paměť a teplotu CPU a upozorňuje, že při velmi nízké dostupné paměti je ukončení procesů na pozadí pravděpodobnější. To je další důvod, proč udržovat aplikaci pro brýle soustředěnou a nepodstatné služby přesunout jinam.

Krok 18: Připravte balíček pro pilot a mějte pod kontrolou základní konfiguraci nasazení

Během vývoje lze APK instalovat přes Android Studio pomocí datového ladicího kabelu Glass3. Produkční nasazení vyžaduje přísnější proces vydávání. Rokid nedokumentuje žádné řízení zásad ve stylu MDM (například režim kiosku, vzdálené vymazání nebo zásady aplikací). Místo toho dokumentuje registraci zařízení a sledování jejich stavu prostřednictvím konzole Lingmou a OpenAPI, přičemž verze 2.2.0-E umožňuje instalaci APK pomocí aplikace se skenováním QR kódu. Mechanismus nasazení, oprávnění ke zřizování, podnikový firmware a zásady aktualizací koordinujte s Rokidem nebo distributorem dřív, než se zavážete k architektuře zavádění.

1. Zmrazte otestované verze SDK a OTA pro pilot.

1. Vytvořte podepsané release APK pro aplikace pro brýle i telefon.

1. Zdokumentujte ID klientů, názvy balíčků a konfiguraci prostředí backendu.

1. API klíče a tajné údaje backendu zřizujte prostřednictvím zabezpečené infrastruktury, ne ve zdrojovém kódu.

1. Určete, kdo smí aktualizovat brýle, aplikaci v telefonu a backend a v jakém pořadí.

1. Po každé změně OTA nebo SDK spusťte regresní testy dřív, než aktualizujete flotilu.

1. Vytvořte cestu podpory pro logy, identitu zařízení, diagnostiku konektivity a návrat k předchozí verzi.

Příklad architektury: vlastní aplikace pro inspekce v terénním servisu

Následuje praktický příklad návrhu sestavený ze zdokumentovaných funkcí Rokidu. Nejde o hotový pracovní postup od Rokidu. Ukazuje, jak může vývojářská sada nástrojů proměnit brýle ve vyhrazený firemní koncový bod.

1. Start. Technická akce: Aplikace pro brýle se automaticky spustí a zkontroluje připravenost SDK. Přínos pro firmu: Pracovník začíná přímo ve firemním pracovním postupu.
2. Přidělení úkolu. Technická akce: Telefon/backend odešle souhrn pracovního příkazu jako kompaktní zprávu. Přínos pro firmu: Není nutné nic ručně dohledávat v telefonu.
3. Navádění. Technická akce: Brýle zobrazí jeden pokyn v centrální oblasti displeje. Přínos pro firmu: Ruce zůstávají volné pro práci.
4. Potvrzení. Technická akce: Pracovník vysloví pevný povel nebo využije podporovanou hardwarovou událost. Přínos pro firmu: Rychlá, deterministická interakce.
5. Pořízení důkazu. Technická akce: Brýle pořídí fotografii nebo krátký klip. Přínos pro firmu: Vizuální důkaz je připojen ke správnému kroku.
6. Přenos. Technická akce: Média se přenášejí přes P2P; malá stavová zpráva potvrdí nahrání. Přínos pro firmu: Velká data nezatěžují řídicí kanál s nízkou šířkou pásma.
7. Synchronizace. Technická akce: Telefon nebo backend odešle výsledek do API systému CMMS/ERP. Přínos pro firmu: Stávající firemní systémy zůstávají hlavní evidencí.
8. Výjimka. Technická akce: V případě potřeby telefon přijme živý stream nebo aplikace spustí schválenou cestu vzdálené asistence. Přínos pro firmu: Nadřízený vidí to, co vidí pracovník.
9. Dokončení. Technická akce: Backend potvrdí dokončení a vrátí další úkol. Přínos pro firmu: Uživatel dostane jasný koncový stav a auditní stopa je kompletní.

Proč vlastní software mění obchodní argumentaci pro Rokid AI Glasses Enterprise

Hlavní podniková hodnota vychází z přizpůsobení zařízení stávajícímu provoznímu procesu nebo z přepracování tohoto procesu pro práci bez použití rukou.

Účelově navržené UI: odstraňte spotřebitelské nabídky a zobrazujte jen informace potřebné v aktuálním kroku práce.

Integrace s firemními systémy: propojte pořízené důkazy a akce pracovníků se stávajícími systémy ERP, CMMS, CRM nebo vlastními platformami.

Sběr dat bez použití rukou: využívejte kameru, hlas a vstup z nositelného zařízení, aniž byste se museli opakovaně vracet k telefonu nebo tabletu.

Řízená konektivita: používejte Bluetooth pro příkazy a P2P pro data s vysokou šířkou pásma, místo abyste všechny funkce tlačili jediným kanálem.

Vlastní hranice AI: využívejte AI tam, kde přináší hodnotu, a pravidla pracovních postupů, oprávnění a správu dat přitom ponechte pod kontrolou firmy.

Chování vyhrazeného zařízení: automatické spouštění a obsluha událostí mohou u jednoúčelových nasazení omezit tření, pokud je podnikový firmware podporuje.

Rozšiřitelná architektura: začněte lokálním proof of concept a s tím, jak pracovní postup dozrává, přidávejte integraci s backendem, platformní API, vzdálenou spolupráci nebo specializovaná SDK.

Argument pro nákup: Pro organizace, které potřebují standardní, pevně daný zážitek z aplikace, může být vlastní vývoj zbytečný. Pro organizace, které chtějí, aby se AI brýle staly součástí řízeného provozního postupu, je právě zdokumentované Glass3 SDK důvodem, proč je tento hardware zajímavější. Firma kupuje přizpůsobitelný koncový bod, nejen nositelný displej nebo kameru.

Omezení a inženýrská rizika, se kterými je třeba počítat

• SDK zaměřené na Android: Veřejné Glass3 SDK cílí na nativní Android. Podle FAQ Rokidu nejsou iOS ani nativní HarmonyOS podporovány. Integrace s uni-app je možná pouze tak, že si sami vytvoříte most k nativnímu Android SDK.
• Kompaktní displej: Plátno 480 x 640 na výšku se hodí pro stručné výzvy, nikoli pro hutné podnikové dashboardy. Dobrý návrh pracovního postupu je nezbytný.
• Nesoulad SDK / changelogu: Ověřujte artefakty SDK, demo a OTA společně a zohledněte rozdíly ve verzích mezi čínským a anglickým changelogem.
• Závislost na online službách: Vybrané funkce ASR, AI a OpenAPI vyžadují přístup k síti, podnikové přihlašovací údaje nebo zřízení služby.
• Aktuální FAQ neuvádí volné offline ASR: Offline TTS a pevné offline povely mohou podpořit odolnou interakci, ale volný offline převod řeči na text v současnosti není dokumentován jako vestavěná funkce.
• Složitost přenosu: Bluetooth a P2P řeší různé problémy. Opětovné připojení, oprávnění a synchronizace stavu vyžadují inženýrskou práci v produkční kvalitě.
• Odstraněné RTC v jádru: Rokid ve verzi 2.1.7-E odstranil volání RTC ze základního Phone SDK. Vzdálená spolupráce by měla využívat Remote Collaboration SDK od Rokidu nebo samostatně vyvinuté řešení.
• Podrobnosti nasazení vyžadují ověření: Veřejná dokumentace SDK je silná v oblasti vývoje, ale správu produkční flotily a zřizování přes konzoli Lingmou nebo aplikaci se skenováním QR kódu je třeba před rozšířením ověřit pro prostředí zákazníka.

Klady a zápory vlastního podnikového vývoje

Klady:

• Model nativního vývoje pro Android
• Veřejné artefakty v Mavenu
• Oficiální demo pro brýle + telefon
• Bluetooth a P2P
• Zprávy/soubory/média
• Kamera a živý náhled
• Služby hlasu/AI/rozpoznávání
• Možnost přímého Wi-Fi
• Podnikové OpenAPI
• Možnosti automatického spouštění a přizpůsobení událostí.

Zápory:

• Nativní podpora SDK pouze pro Android
• Kompaktní pevný displej
• Koordinace verzí/OTA
• Vybrané online funkce vyžadují podnikový přístup
• Omezení offline ASR
• Podrobnosti produkčního zřizování/správy flotily vyžadují potvrzení pro konkrétní projekt.

Závěrečný verdikt

Rokid AI Glasses Enterprise stojí za zvážení, pokud je cílem firmy vytvořit vyhrazený pracovní postup bez použití rukou, a ne nasadit obecnou spotřebitelskou aplikaci. Aktuální podniková sada nástrojů Glass3 dává vývojářům pro Android zdokumentovanou cestu, jak stavět přímo na brýlích, spárovat je s telefonem s Androidem, přenášet řídicí data přes Bluetooth, přenášet média přes Wi-Fi P2P a propojit pracovní postup s backendovými systémy nebo vybranými službami Rokid OpenAPI.

Nejsilnějšími případy užití jsou řízené inspekce, servis v terénu, pořizování důkazů, procedurální práce a další úkoly, u nichž pracovníkovi pomáhá vidět vždy jeden pokyn a mít přitom obě ruce volné. Hlavním omezením není nedostatek API. Je jím inženýrská disciplína, kterou vyžaduje malý displej, stav připojení, oprávnění, kompatibilita SDK/OTA a závislosti na online službách.

Pro firemního kupujícího zní klíčová hodnoticí otázka: „Dokážeme svůj pracovní postup namapovat na zdokumentovanou vývojářskou sadu nástrojů a dokážeme aplikaci podporovat po celou dobu jejího životního cyklu?“ Pokud je odpověď ano, vlastní software představuje cestu, jak z Rokid Glass3 udělat místo univerzálních AI brýlí účelově navržené provozní zařízení.

Firmám, které zvažují Rokid AI Glasses Enterprise pro inspekce, servis v terénu, logistiku, řízenou práci nebo vlastní pracovní postupy s AI, může VR Expert pomoci posoudit hardware, definovat proof of concept a ověřit cestu k nasazení. Navštivte produktovou stránku Rokid AI Glasses Enterprise, kde najdete informace o zařízení, dostupnosti a možnostech nákupu. Pro vymezení vlastního vývoje nebo rady k zavedení kontaktujte VR Expert.