Zo ontwikkelt u maatwerksoftware voor Rokid AI Glasses Enterprise

Samenvatting

Rokid AI Glasses Enterprise is uit te bouwen tot een zakelijk apparaat voor een specifiek doel, in plaats van alleen te worden gebruikt met vooraf geconfigureerde applicaties. De huidige Sprite Enterprise-documentatie van Rokid biedt een Glasses SDK voor applicaties die rechtstreeks op Glass3 draaien, een Phone SDK voor Android-companion-apps en OpenAPI-services voor integraties aan de cloudkant. Samen ondersteunen deze lagen apparaatconnectiviteit, messaging, bestandsoverdracht, camera- en media-opname, livevideo, spraakfuncties, AI-services, herkenning, apparaatstatus en zakelijke workflows.

Voor een ontwikkelteam is de praktische route vertrouwd: bouw native Android-projecten in Android Studio, voeg de Maven-repository en SDK-dependencies van Rokid toe, draai de officiële demo van Rokid (bestaande uit twee projecten), gebruik Bluetooth voor detectie en besturing, schakel over op Wi-Fi P2P voor grote bestanden en audio/video, en koppel de workflow vervolgens aan de backend van het bedrijf. Een standalone app op de bril is ook mogelijk als de toepassing geen companion-telefoon vereist.

Los van de SDK zit de belangrijkste waarde in het vervangen van een generieke wearable-ervaring door een gecontroleerde workflow. Een monteur kan een werkorder ontvangen, de volgende instructie op het display zien, een stap bevestigen met spraak of hardware-invoer, visueel bewijs vastleggen en het resultaat naar een CMMS, ERP of eigen platform sturen. Daardoor is de bril relevant voor inspecties, buitendienst, begeleid werk, logistiek, documentatie en andere handsfree processen. De belangrijkste kanttekeningen zijn native SDK-ondersteuning alleen voor Android, compatibiliteit tussen versies en OTA-updates, API-keys voor bepaalde online services en een compact display van 480 × 640 dat een doordacht UI-ontwerp vereist.

Wat Rokid beschikbaar stelt voor ontwikkelaars

Rokid verdeelt de enterprise-stack in een SDK voor twee kanten plus een apart OpenAPI-platform. Wie deze verdeling begrijpt voordat de eerste regel code wordt geschreven, voorkomt een veelgemaakte fout: de bril alles willen laten doen, terwijl een telefoon of backend beter geschikt is voor netwerkverkeer, authenticatie, opslag of integratie met bedrijfssystemen.

Applicatie op de bril:

• Draait op: Rokid Glass3
• Typische taak: Rendert de wearable-UI en benadert functies aan de brilkant, zoals camera/media, apparaatstatus, berichten, spraak, AI en herkenning, via de Glasses SDK.

Companion-app:

• Draait op: Android-telefoon
• Typische taak: Detecteert en verbindt met Glass3, beheert Bluetooth en Wi-Fi P2P, wisselt berichten/bestanden uit, ontvangt mediastreams en kan bedrijfsdata doorsturen.

Cloud-/bedrijfslaag:

• Draait op: Uw backend + Rokid OpenAPI waar relevant
• Typische taak: Slaat bedrijfsdata op, authenticeert gebruikers, koppelt ERP-/CMMS-/CRM-systemen en kan Rokid OpenAPI-modules zoals messaging- of device-API's gebruiken wanneer deze zijn ingericht.

Praktisch oordeel: Voor zakelijke maatwerksoftware is de bruikbare architectuur meestal “dunne wearable-UI + betrouwbare apparaatservices + bedrijfslogica op telefoon/backend”. Een gerichte brilervaring beperkt de UI-complexiteit en maakt het project beter onderhoudbaar, terwijl handsfree interactie behouden blijft waar dat ertoe doet.

De ontwikkelstack in één oogopslag

• Doelhardware in openbare enterprise-documentatie: Rokid Glass3
• Ontwikkelmodel: Native Android-applicatieontwikkeling
• Artefact Glasses SDK: com.rokid.security:glass3.open.sdk
• Artefact Phone SDK: com.rokid.security:phone.sdk
• Huidige dependency in de Quick Start: 2.2.0-E voor beide SDK's
• Nieuwste zichtbare changelog-item ten tijde van het onderzoek: V2.2.0-E, gedateerd 6 augustus 2026, met aanbevolen OTA 1.19.e006-20260806-150201 of later.
• Aanbevolen tools: Android Studio 2022+, JDK 17+
• Demo-omgeving: Android SDK 34, JDK 17, Android-telefoon, Rokid Glass3
• Coördinatenstelsel van het brildisplay: Vast 480 × 640, staand
• Primaire lokale verbindingen: Classic Bluetooth en Wi-Fi P2P
• Cloudauthenticatie: Enterprise API Key voor Rokid OpenAPI en bepaalde online services
• Ondersteund telefoonplatform: Android; volgens de openbare FAQ worden iOS en native HarmonyOS niet ondersteund door de Glass3 SDK

Wat kunt u bouwen met Rokid AI Glasses Enterprise?

De openbare SDK is breed genoeg voor meer dan één demo-applicatie. Wat u precies bouwt, hangt af van welke functies u combineert en hoeveel logica u op de wearable houdt.

Begeleide buitendienst: toon één instructie tegelijk, bevestig afronding, maak foto's of video en stuur gestructureerd bewijs terug naar een werkordersysteem.

Inspectie en compliance: toon checklists, gebruik camera-opname of herkenning, voeg bewijs met tijdstempel toe en escaleer afwijkingen.

Workflows in magazijn en logistiek: toon pick- of taakinformatie, wissel lichte commando's uit via Bluetooth en gebruik waar nodig gespecialiseerde scanintegraties.

Visuele ondersteuning op afstand: ontvang een livevideostream aan de companion-kant of integreer een apart pad voor samenwerking op afstand. Rokid heeft RTC-bellen in versie 2.1.7-E uit de kern-Phone SDK verwijderd. Realtime samenwerking moet daarom worden opgezet op basis van Android en Web: de Remote Collaboration SDK van Rokid of uw eigen goedgekeurde transportlaag, in plaats van ervan uit te gaan dat dit in de basis-SDK zit.

Zakelijke AI-assistent: combineer spraakinvoer, TTS, AI-chat of AI-services van het bedrijf met een UI voor die specifieke workflow, in plaats van gebruikers een generieke chatbot voor te schotelen.

Vastleggen van bewijs en documentatie: activeer foto-, video- of audio-opname, verstuur grotere media via P2P en synchroniseer resultaten met een backend.

Speciaal apparaat voor één taak: start de bedrijfsapplicatie automatisch na een herstart en koppel ondersteunde hardware-events aan workflowacties, mits gevalideerd op de doelfirmware.

Stap voor stap: maatwerksoftware ontwikkelen voor Rokid AI Glasses Enterprise

Stap 1: definieer de workflow voordat u de architectuur kiest

Begin bij het operationele proces, niet bij de lijst met SDK-functies. Schrijf precies op wat de medewerker moet zien, zeggen, vastleggen en bevestigen. Bepaal daarna welk apparaat verantwoordelijk is voor elke taak. Een goed afgebakende wearable-applicatie toont meestal beknopte informatie en registreert invoer, terwijl de telefoon of backend de zwaardere bedrijfslogica afhandelt.

Standalone app op de bril:

• Meest geschikt voor: Eenvoudige lokale workflow, opname op het apparaat, gebruik offline of met beperkte connectiviteit
• Voordelen: Minder componenten, directe wearable-ervaring
• Afweging: U moet meer opslag- en netwerklogica op de bril afhandelen; sommige online functies vereisen nog steeds inloggegevens of connectiviteit

Bril + Android-telefoon:

• Meest geschikt voor: De meeste zakelijke pilots, live media, bestandsoverdracht, bediening op afstand, companion voor een zakelijke app
• Voordelen: Best gedocumenteerde verbindingsroute; de telefoon kan authenticatie, netwerkverkeer en UI afhandelen die niet in de lens thuishoort
• Afweging: Vereist een Android-telefoon en robuuste logica voor herverbinden

Bril + telefoon + backend:

• Meest geschikt voor: ERP-/CMMS-/CRM-integratie, audittrail, centraal beheerde werkorders, AI-services
• Voordelen: Het meest geschikt voor schaalbare zakelijke workflows en datagovernance
• Afweging: Vergt meer integratie-, beveiligings- en backendwerk

Advies: Kies voor een eerste B2B-proof of concept het model bril + Android-telefoon + backend, tenzij de toepassing duidelijk baat heeft bij een standalone wearable. Dit model sluit nauw aan op de gedocumenteerde flow met twee apparaten van Rokid en geeft het ontwikkelteam ruimte om netwerkverkeer, inloggegevens en dataopslag van de bril weg te halen.

Stap 2: zorg voor de juiste hardware en toegang

Controleer voordat u Android Studio installeert of de hardware daadwerkelijk op het enterprise-softwarepad zit. Volgens de FAQ van Rokid bevatten enterprise-/werkbuilds meestal een “e” in de systeemversie. De SDK-documentatie maakt ook onderscheid tussen enterprise- en consumentensystemen. Het identificeren van de firmware hoort dus bij de projectopzet en is geen bijzaak.

Rokid AI Glasses Enterprise (de Rokid Glasses-hardware) met de enterprise-systeembuild/-firmware (systeemversie die eindigt op “e”).

De Glass3-datadebugkabel. Rokid waarschuwt uitdrukkelijk dat de gewone laadkabel de bril wel van stroom voorziet, maar niet door Android Studio kan worden gebruikt voor debuggen.

Een Android-telefoon als u de Phone SDK gebruikt.

Een ontwikkel-pc met Android Studio en JDK 17.

Een enterprise-account en API Key als het project Rokid OpenAPI of online functies met authenticatie gebruikt.

Toegang tot exact de OTA-versie die u op de pilotvloot wilt uitrollen.

Sla de kabelcontrole niet over: Rokid noemt de datadebugkabel verplicht, omdat Android Studio de bril daarmee herkent, APK's kan installeren en logs kan inzien. Laadt de bril wel op, maar verschijnt hij niet als apparaat? Controleer dan eerst de kabel voordat u Gradle, ADB of de SDK gaat debuggen.

Stap 3: bereid de Android-ontwikkelomgeving voor

De Quick Start van Rokid adviseert Android Studio 2022 of later en JDK 17 of later, en vermeldt dat de Glass3 SDK Android 8.0 of later ondersteunt. De officiële demohandleiding gebruikt momenteel Android SDK 34. De FAQ van Rokid adviseert daarnaast Android 7.0 / API 24 of later en raadt aan de Gradle-configuratie te controleren in het actuele SDK-pakket en de demo. Behandel in een echt project de Gradle-bestanden van de demo als leidend voor de exacte release die u integreert.

1. Installeer Android Studio 2022 of nieuwer.

1. Installeer JDK 17 of nieuwer en selecteer deze voor Gradle.

1. Installeer de Android SDK-versie die de huidige Rokid-demo vereist. De huidige demohandleiding noemt SDK 34.

1. Schakel gewoon Android-debuggen in op de ontwikkeltelefoon.

1. Sluit Glass3 aan met de datadebugkabel en controleer of Android Studio een doelapparaat ziet zoals “Rokid RG-glasses”.

1. Installeer de screenprojectie-/mirroringtool van Rokid als u de wearable-UI vanaf de pc wilt bekijken. Rokid raadt projectie tijdens de ontwikkeling sterk aan.

Stap 4: draai de officiële demo van Rokid voordat u een eigen applicatie maakt

Dit is de belangrijkste praktische stap van het hele proces. De officiële demo valideert de ontwikkelomgeving, SDK-binaries, permissies, hardwareverbindingen en versiecombinatie voordat uw eigen code een extra variabele wordt.

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

# Demo voor de bril
cd glassdemo
./gradlew assembleDebug

# Demo voor de telefoon
cd ../glass3sdkphonedemo
./gradlew assembleDebug

De repository bevat twee afzonderlijke Android-projecten: één voor de bril en één voor de Android-telefoon. Rokid adviseert eerst de demo aan de telefoonkant te draaien en daarna die aan de brilkant. Zijn beide geïnstalleerd, zoek dan vanuit de telefoondemo naar Glass3 en maak verbinding.

1. SDK-initialisatie. Geslaagd als: beide projecten starten en een geldige SDK-status melden.
2. Bluetooth. Geslaagd als: de telefoon Glass3 vindt en er verbinding mee maakt.
3. Messaging. Geslaagd als: tekst- of besturingsberichten heen en weer kunnen tussen telefoon en bril.
4. Kleine bestandsoverdracht. Geslaagd als: een klein bestand zonder fouten kan worden uitgewisseld.
5. Wi-Fi P2P. Geslaagd als: er een P2P-kanaal kan worden opgezet voor taken met veel bandbreedte.
6. Media. Geslaagd als: foto, video of live preview kan worden geactiveerd en ontvangen.

Waarom dit commercieel belangrijk is: Een proof of concept voor een klant is veel makkelijker af te bakenen als eerst de basisfuncties van het apparaat zijn gevalideerd. Daarna kunt u de projecttijd besteden aan de eigenlijke workflow, integratie en gebruikerservaring, in plaats van aan het diagnosticeren van een niet-geverifieerde SDK-opzet.

Stap 5: maak uw eigen projecten en voeg de Maven-repository van Rokid toe

Werkt de demo, maak of open dan uw eigen Android-projecten. Rokid publiceert de SDK-artefacten via een eigen Maven-repository. Voeg de repository toe naast Google en Maven Central, en voeg daarna de glasses-dependency toe aan de wearable-app en de phone-dependency aan de companion-app.

// settings.gradle - vereenvoudigd voorbeeld
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
        maven { url 'https://maven.rokid.com/repository/maven-public/' }
    }
}

// App voor de bril
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

// App voor de Android-telefoon
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

De huidige Quick Start van Rokid toont versie 2.2.0-E, met een aanbevolen OTA van 1.19.e006-20260806-150201 of later. Zakelijke teams doen er goed aan een bekende combinatie van SDK en OTA vast te zetten en te testen, in plaats van componenten automatisch en los van elkaar te updaten.

Regel voor versiebeheer: Leg vóór een pilot- of productierelease de OTA-build van de bril, de versie van de Glasses SDK, de versie van de Phone SDK, de demo-commit en eventuele versies van gespecialiseerde SDK's vast in één compatibiliteitsmatrix. Voer de basistests voor verbinding en media opnieuw uit zodra een van die componenten verandert.

Stap 6: declareer alleen de Android-permissies die uw workflow nodig heeft

De Quick Start van Rokid noemt gangbare permissies voor netwerktoegang, Wi-Fi, camera, microfoon, opslag, Bluetooth en apparaten in de buurt. Op moderne Android-versies is declareren in het manifest niet voldoende voor gevaarlijke permissies. Uw telefoon- en brilapps moeten de vereiste permissies tijdens runtime aanvragen en een weigering netjes afhandelen.

• Bluetooth scannen/verbinden: Apparaatdetectie, koppelen, kleine berichten en besturing
• Wi-Fi-apparaten in de buurt / Wi-Fi Direct: P2P-verbinding voor bestanden, afbeeldingen, video en realtime streams
• Camera: Foto-/video-opname en flows voor visuele herkenning
• Microfoon: Audio-opname, ASR en spraakinteractie
• Netwerk / internet: Backend-API's, online services van Rokid, cloudsynchronisatie
• Opslag: Verwerking van media en overgedragen bestanden, afhankelijk van het gedrag van de Android-/SDK-doelversie

Advies voor productie: Kopieer niet klakkeloos het volledige demomanifest. Minimale permissies maken de securityreview eenvoudiger en verkleinen de kans dat gebruikers een permissie weigeren die de workflow eigenlijk niet nodig heeft.

Stap 7: initialiseer de Glasses SDK en registreer de identiteit van uw app

De applicatie op de bril maakt verbinding met de security service van Rokid en registreert vervolgens een client-ID. De belangrijke architectuurregel: de companion-app op de telefoon kent hetzelfde client-ID wanneer beide kanten applicatiespecifieke berichten uitwisselen.

// Illustratieve structuur, vereenvoudigd op basis van de initialisatieflow van Rokid
if (!GlassSdk.isReady()) {
    GlassSdk.bindSecurityService(context, object : IServiceConnectionCallback {
        override fun onServiceConnected() {
            GlassSdk.registerClient("FieldServiceApp", messageCallback)
        }
    })
}

Na de initialisatie benadert u de functies aan de brilkant via service-entrypoints die GlassSdk beschikbaar stelt. De openbare API-groepen omvatten algemene/apparaatfuncties, classic Bluetooth, P2P, messaging, media, bestandsverwerking, spraak/AI, herkenning en andere services. Initialiseer niet alle functies bij het opstarten. Haal alleen de services op die nodig zijn voor het huidige scherm of de huidige workflowstap, en activeer alleen die.

Statuscontrole: Gebruik GlassSdk.isReady() als eenvoudig diagnostisch signaal voordat u functieservices aanroept. Geeft dit false terug, los dan eerst de initialisatie of service-binding op voordat u functies op hoger niveau test.

Stap 8: initialiseer de Android Phone SDK met overeenkomende client-ID's

Initialiseer aan de telefoonkant de mobile engine van Rokid en registreer de client-ID's waarmee de telefoon communiceert. De Phone SDK van Rokid is de verbindings- en besturingslaag voor apparaatdetectie, Bluetooth/P2P, messaging, bestanden, het ontvangen van media, configuratiesynchronisatie en aanverwante taken.

// Opzet op applicatieniveau
val engineParam = EngineParam.Builder()
    .setClientIds(listOf("FieldServiceApp"))
    .setApiKeyCredentials(apiKeyCredentials)
    .build()
IMobileEngine.initSDK(engineParam)

// Diagnostische controle
val ready = PSecuritySDK.getMobileEngineService().isInit()

Vereisen bepaalde online functies API Key Credentials, dan bevat de demo placeholder-authenticatiegegevens die u moet vervangen door credentials die u via het zakelijke proces van Rokid verkrijgt. Houd cloudsecrets buiten versiebeheer en verwerk geen langlevende platform-API-keys in een distribueerbare clientapplicatie.

Stap 9: verbind eerst via Bluetooth en gebruik daarna P2P voor bandbreedte

Rokid documenteert twee lokale verbindingspatronen, elk met een eigen taak. Classic Bluetooth is geschikt voor detectie, verbinding, besturingsberichten en kleine bestanden. Wi-Fi P2P is het betere kanaal voor afbeeldingen, grote bestanden, video en realtime media. Wie het verkeerde kanaal kiest, krijgt al snel een applicatie die in een demo werkt maar in de praktijk onbetrouwbaar aanvoelt.

Classic Bluetooth:

• Gebruiken voor: Detectie, koppelen, besturingscommando's, compacte JSON-berichten, kleine bestanden
• Rol in het ontwerp: Control plane met lage bandbreedte

Wi-Fi P2P:

• Gebruiken voor: Grote bestanden, afbeeldingen, video, audio-/videostreams, synchronisatie met hoge doorvoer
• Rol in het ontwerp: Data plane met hoge bandbreedte

Directe Wi-Fi op de bril:

• Gebruiken voor: Backendtoegang vanuit een brilapplicatie wanneer het apparaat met Wi-Fi is verbonden
• Rol in het ontwerp: Nuttig voor bepaalde standalone flows; ontwerp toch offline- en retrygedrag

Een robuuste zakelijke app behandelt verbindingen als state machines, niet als eenmalige gebeurtenissen. Handel verlies van Bluetooth, het afbreken van P2P, een slapende telefoon, Wi-Fi-wijzigingen en een herstart van de bril expliciet af. De gebruiker hoort een eenvoudige status te zien, zoals “opnieuw verbinden” of “synchronisatie in behandeling”, en geen Android-exception of stille fout.

Stap 10: definieer een klein applicatieprotocol voor bedrijfsberichten

Rokid levert de transport- en berichtenservices, maar uw applicatie heeft nog steeds een afspraak nodig over wat een bedrijfsbericht betekent. Houd dit contract compact, geversioneerd en los van de UI. JSON is een praktische keuze voor eerste projecten, omdat het makkelijk te inspecteren is. Het exacte payloadformaat is wel een ontwerpkeuze van uw applicatie en geen eis van Rokid.

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

Na afronding kan de bril een kort statusbericht terugsturen met een verwijzing naar het werkorder-ID en het stapnummer. Het mediabestand zelf hoort via het P2P-bestands-/mediapad te gaan en niet in het besturingsbericht te worden ingesloten. Deze scheiding houdt het commandokanaal responsief en maakt retries eenvoudiger.

Stap 11: ontwerp de bril-UI voor 480 × 640, niet als een telefoonapp

Het Glass3-display gebruikt een vast, staand coördinatenstelsel van 480 × 640. De FAQ van Rokid adviseert de primaire content in het centrale gebied van 480 × 400 te plaatsen, de bovenste 160 pixels en onderste 80 pixels te gebruiken voor secundaire informatie en belangrijke content omlaag te verplaatsen, omdat in de bovenste circa 40 pixels optische reflectie kan optreden. Het besturingssysteem ondersteunt geen normale schermrotatie; brede layouts moeten dus binnen het staande canvas worden ontworpen.

Toon één taak, instructie of beslissing tegelijk. Lange dashboards passen slecht bij de lens.

Gebruik waar mogelijk een zwarte achtergrond. Rokid raadt dit aan om zichtbaar flitsen tijdens het opstarten of bij overgangen te beperken.

Plaats geen kritieke tekst of knoppen in het reflectiegebied van de bovenste ~40 px.

Maak statuswijzigingen duidelijk zonder te leunen op complexe kleurcodering. Rokid adviseert groen als primaire visuele stijl.

Toon een duidelijke verbindingsstatus en een duidelijke status “gesynchroniseerd / in behandeling” voor bedrijfsdata.

Houd interactiedoelen eenvoudig genoeg om te bedienen met ondersteunde hardware-invoer of spraak, zonder precieze navigatie in touchscreenstijl af te dwingen.

Zakelijke implicatie: Het display is klein, maar dat kan een voordeel zijn bij procedureel werk. Het stimuleert softwareteams om niet-essentiële informatie te schrappen en alleen de volgende handeling te tonen die de medewerker nodig heeft.

Stap 12: voeg camera-, foto-, video- en live-previewfuncties toe

De Glasses SDK biedt mediafuncties voor foto, video, audio en preview. De Phone SDK kan mediastreams van de bril ontvangen. Volgens de FAQ van Rokid is de standaard videostream 1080P bij circa 15 tot 19 frames per seconde, met ongeveer 300 ms afspeellatency op de telefoon. De output kan H.264 of gedecodeerd NV21 zijn, afhankelijk van de API en het demopad. Beschouw deze cijfers als actuele implementatierichtlijn, niet als gegarandeerde SLA.

Gebruik foto-opnamen voor inspectiebewijs, bewijs van afronding en latere AI-verwerking.

Gebruik H.264 als de telefoon of backend de stream vooral moet doorsturen of opslaan. Met de changelog van 2.1.8-E voegde Rokid controle toe over automatische H.264-naar-NV21-decodering, zodat onnodig decoderen kan worden vermeden.

Gebruik NV21 als een computervisionpipeline aan de telefoonkant gedecodeerde frames nodig heeft.

Gebruik Wi-Fi P2P voor live preview en mediaoverdracht, niet classic Bluetooth.

Hebt u camerabeeld plus een on-screen overlay in de opname nodig, bekijk dan de actuele AR Mix-/AR-recording-API's van Rokid en stem ze af op de geïnstalleerde SDK-versie.

Een praktisch detail uit de FAQ van Rokid is belangrijk voor bewijsworkflows: na een geslaagde P2P-upload kan het systeem afbeeldingen op de bril opruimen. Beschouw de succesvol ontvangen kopie op de telefoon of backend als de zakelijke bron van waarheid en bevestig dat de upload is voltooid voordat de werkorder naar de volgende stap gaat.

Stap 13: zet spraak, TTS en AI bewust in

Spraak kan waardevol zijn als medewerkers hun handen niet kunnen gebruiken, maar koppel het aan expliciete workflowacties. De SDK-documentatie voor de brilkant beschrijft ASR, TTS, offline commandoverwerking en AI-chat. Volgens de FAQ vereist offline TTS momenteel SDK 2.2.0 of later, terwijl de changelog de offline TTS-service al vanaf 2.1.2 vermeldt; test het op uw vastgezette versie. Open offline ASR wordt momenteel standaard niet ondersteund. Voor offline spraak-naar-tekst verwijst Rokid ontwikkelaars naar private ASR-/TTS-services, in plaats van een ingebouwd offline ASR-pad te claimen.

Offline commandowoorden:

• Goed gebruik: Korte vaste commando's zoals “volgende”, “terug”, “vastleggen”
• Ontwerpnotitie voor zakelijk gebruik: Geschikt voor deterministische handsfree bediening

Online ASR:

• Goed gebruik: Vrije spraak-naar-tekst
• Ontwerpnotitie voor zakelijk gebruik: Vereist netwerk-/service-inrichting en moet fallbackgedrag hebben

TTS / offline TTS:

• Goed gebruik: Prompts, waarschuwingen of korte bevestigingen voorlezen
• Ontwerpnotitie voor zakelijk gebruik: Nuttig als het display minimaal moet blijven

AI-chat / private AI:

• Goed gebruik: Contextuele ondersteuning of interpretatie
• Ontwerpnotitie voor zakelijk gebruik: Houd het model achter de workflow. Valideer gegevensverwerking, latency en de grenzen van antwoorden.

Stap 14: koppel de workflow veilig aan uw backend

Er spelen twee afzonderlijke backendvragen: hoe uw eigen applicatie uw bedrijfssystemen bereikt, en of u Rokid OpenAPI gebruikt. Uw applicatie kan data via de gekoppelde telefoon versturen, of een brilapplicatie kan rechtstreeks het internet op wanneer Glass3 met Wi-Fi is verbonden. Voor bedrijfssystemen zijn standaard backend-API's doorgaans het schoonste integratiepunt, omdat inloggegevens, auditlogs, datavalidatie en bedrijfsregels dan aan de serverkant blijven.

Rokid OpenAPI is een aparte platformlaag. De officiële documentatie vereist een geactiveerd enterprise-account en een API Key. Verzoeken authenticeren met een Bearer-token, aangemaakte keys verlopen en de standaard geldigheid is één maand, tenzij anders geconfigureerd. Rokid waarschuwt uitdrukkelijk om API-keys niet bloot te geven in openbare repositories of clients.

Beveiligingsregel: Gebruik een server-side proxy voor de platformcredentials van Rokid wanneer de architectuur dat toelaat. Een APK voor telefoon of bril kan worden geïnspecteerd. Ga er niet van uit dat een API-key geheim blijft door hem te verbergen in Kotlin of native code.

De huidige Rokid OpenAPI-modules omvatten onder meer messaging- en device-API's, naast andere zakelijke functies (let op: deze messaging- en device-API's zijn alleen toegankelijk als apparaten zijn geregistreerd in de Lingmou-console van Rokid). Met de device-API kunt u bijvoorbeeld geregistreerde Glass-units opvragen, terwijl de message-API een bedrijfsbericht naar een doelapparaat kan pushen. Gebruik deze services alleen als ze een echte uitrolbehoefte oplossen. Een eigen bedrijfsbackend blijft de juiste plek voor ERP, CMMS, CRM, identiteit en workfloworkestratie.

Stap 15: configureer zakelijk gedrag zoals autostart en toetsafhandeling

Een wearable wordt in de praktijk bruikbaarder als de gebruiker niet elke ochtend door een launcher in consumentenstijl hoeft te navigeren. Rokid documenteert een autostartmechanisme dat op ondersteunde enterprise-systemen een geconfigureerde applicatie na het opstarten kan starten. Daarnaast documenteert Rokid het aanpassen van hardware-events en, in de changelog van 2.1.9-E, API's voor event listeners/interceptie.

Gebruik autostart voor specifieke inspectie-, beveiligings- of industriële workflows waarbij de bril direct in de bedrijfsapplicatie moet openen.

Stel SDK-afhankelijk werk na het opstarten kort uit en controleer of de services gereed zijn voordat de workflow start.

Koppel ondersteunde toetsevents aan een klein aantal zinvolle acties, zoals bevestigen, vastleggen of annuleren.

Valideer elke autostart- of interceptiefunctie op de beoogde enterprise-firmware, omdat sommig gedrag op systeemniveau versieafhankelijk is.

Zorg altijd voor een ondersteunings-/herstelroute. Een vergrendelde workflow die een beheerder niet kan verlaten, is een operationeel risico.

Stap 16: bouw offline-, retry- en herstelgedrag in

Een demo gaat vaak uit van perfecte Bluetooth, Wi-Fi en cloudtoegang. Bij een uitrol in het veld kan dat niet. Sla de minimale workflowstatus op die nodig is om een verbroken telefoonverbinding, P2P-storing of tijdelijke netwerkuitval te overleven. Maak elke bedrijfsactie waar mogelijk idempotent, zodat een nieuwe poging geen dubbele werkorder-events of mediarecords oplevert.

Cache het huidige werkorder-ID, het stap-ID en de laatst bevestigde actie.

Zet niet-verzonden resultaten in een wachtrij met een zichtbare status “synchronisatie in behandeling”.

Gebruik unieke operatie-ID's, zodat de backend duplicaten veilig kan weigeren.

Herstel eerst de Bluetooth-verbinding en bouw P2P alleen opnieuw op als overdracht met hoge bandbreedte nodig is.

Markeer een stap die van media afhankelijk is nooit als voltooid voordat de ontvangst van de doelkopie is bevestigd.

Bied een veilige fallback voor de gebruiker als online ASR of AI niet beschikbaar is. Vaste offline commando's kunnen de kernnavigatie dan nog steeds afdekken.

Stap 17: test op echte hardware met een zakelijke testmatrix

Emulators volstaan niet voor een brilproject, omdat optiek, thermisch gedrag, Bluetooth, P2P, camera, microfoon en draagcomfort allemaal invloed hebben op de software-ervaring. Test het complete systeem op exact de enterprise-OTA die voor de pilot is gepland.

• Opstarten en autostart: Koude start, app-start, SDK-gereedheid, herstel bij trage service-binding
• Bluetooth: Eerste koppeling, herverbinden, slapende telefoon, herstel na buiten bereik raken
• P2P: Herhaald verbinden/verbreken, groot bestand, livestream, Wi-Fi-wijzigingen
• Permissies: Nieuwe installatie, geweigerde permissie, later alsnog toegekend, verschillen tussen Android-versies
• Media: Foto-/videokwaliteit, ontvangstbevestiging van bestanden, retry bij mislukte upload, opslag opruimen
• Spraak: Lawaaiige omgeving, geen netwerk, niet-ondersteunde zin, onderbreking van TTS
• UI / optiek: Leesbaarheid, reflectiegebied bovenaan, lange tekst, zichtbaarheid van status, vermoeidheid bij gebruikers
• Prestaties: Lange sessie, CPU-temperatuur, beschikbaar geheugen, overleven van processen
• Backend: Trage respons, dubbel verzoek, verlopen token, server niet beschikbaar
• Beveiliging: Omgang met credentials, redactie van logs, verlies van het apparaat, intrekken van accounts

De FAQ van Rokid raadt specifiek aan geheugen en CPU-temperatuur te monitoren bij het analyseren van prestatieproblemen, en waarschuwt dat bij zeer weinig beschikbaar geheugen achtergrondprocessen eerder worden beëindigd. Nog een reden om de brilapp gericht te houden en niet-essentiële services elders onder te brengen.

Stap 18: stel het pilotpakket samen en leg de uitrolbasis vast

Tijdens de ontwikkeling kunt u APK's via Android Studio installeren met de Glass3-datadebugkabel. Een productie-uitrol vraagt om een strenger releaseproces. Rokid documenteert geen beleidsbeheer in MDM-stijl (zoals kiosk mode, op afstand wissen of app-beleid). Wel documenteert Rokid apparaatregistratie en het volgen van de apparaatstatus via de Lingmou-console en OpenAPI, en maakt versie 2.2.0-E APK-installatie mogelijk via een QR-scan-app. Stem het uitrolmechanisme, provisioningrechten, enterprise-firmware en updatebeleid af met Rokid of de distributeur voordat u zich vastlegt op een uitrolarchitectuur.

1. Bevries de geteste SDK- en OTA-versies voor de pilot.

1. Maak ondertekende release-APK's voor de bril- en telefoonapplicaties.

1. Documenteer client-ID's, pakketnamen en de configuratie van de backendomgeving.

1. Richt API-keys en backendsecrets in via beveiligde infrastructuur, niet via broncode.

1. Leg vast wie de bril, de telefoonapp en de backend mag updaten, en in welke volgorde.

1. Voer na elke OTA- of SDK-wijziging regressietests uit voordat u de vloot bijwerkt.

1. Richt een ondersteuningsroute in voor logs, apparaatidentiteit, connectiviteitsdiagnose en rollback.

Voorbeeldarchitectuur: een maatwerk-inspectieapp voor de buitendienst

Het volgende is een praktisch ontwerpvoorbeeld, samengesteld op basis van de gedocumenteerde functies van Rokid. Het is geen kant-en-klare Rokid-workflow. Het laat zien hoe de ontwikkelstack de bril kan omvormen tot een specifiek zakelijk endpoint.

1. Start. Technische actie: de brilapp start automatisch en controleert of de SDK gereed is. Zakelijke waarde: de medewerker begint direct in de bedrijfsworkflow.
2. Taak toewijzen. Technische actie: telefoon/backend stuurt een samenvatting van de werkorder als compact bericht. Zakelijke waarde: handmatig opzoeken op een telefoon is niet nodig.
3. Begeleiden. Technische actie: de bril toont één instructie in het centrale displaygebied. Zakelijke waarde: de handen blijven vrij voor de taak.
4. Bevestigen. Technische actie: de medewerker spreekt een vast commando uit of gebruikt een ondersteund hardware-event. Zakelijke waarde: snelle, deterministische interactie.
5. Bewijs vastleggen. Technische actie: de bril maakt een foto of korte clip. Zakelijke waarde: visueel bewijs wordt aan de juiste stap gekoppeld.
6. Overdragen. Technische actie: media gaat via P2P; een kort statusbericht bevestigt de upload. Zakelijke waarde: grote hoeveelheden data blijven weg van het besturingskanaal met lage bandbreedte.
7. Synchroniseren. Technische actie: telefoon of backend stuurt het resultaat naar de CMMS-/ERP-API. Zakelijke waarde: bestaande bedrijfssystemen blijven het leidende systeem.
8. Uitzondering. Technische actie: indien nodig ontvangt de telefoon een livestream of start de app het goedgekeurde pad voor ondersteuning op afstand. Zakelijke waarde: een leidinggevende ziet wat de medewerker ziet.
9. Afronden. Technische actie: de backend bevestigt de afronding en stuurt de volgende taak. Zakelijke waarde: de gebruiker krijgt een duidelijke eindstatus en de audittrail is compleet.

Waarom maatwerksoftware de businesscase voor Rokid AI Glasses Enterprise verandert

De belangrijkste zakelijke waarde ontstaat door het apparaat af te stemmen op een bestaand operationeel proces, of door dat proces opnieuw in te richten voor handsfree werk.

UI voor een specifiek doel: verwijder consumentenmenu's en toon alleen de informatie die nodig is bij de huidige werkstap.

Integratie met bedrijfssystemen: koppel vastgelegd bewijs en handelingen van medewerkers aan bestaande ERP-, CMMS-, CRM- of maatwerkplatformen.

Handsfree gegevensregistratie: gebruik camera, spraak en wearable-invoer zonder steeds terug te hoeven naar een telefoon of tablet.

Gecontroleerde connectiviteit: gebruik Bluetooth voor commando's en P2P voor data met hoge bandbreedte, in plaats van elke functie door één kanaal te persen.

Eigen AI-grenzen: zet AI in waar het waarde toevoegt en houd workflowregels, permissies en datagovernance onder controle van het bedrijf.

Specifiek apparaatgedrag: autostart en eventafhandeling kunnen drempels verlagen bij een uitrol voor één doel, mits de enterprise-firmware dit ondersteunt.

Uitbreidbare architectuur: begin met een lokale proof of concept en voeg backendintegratie, platform-API's, samenwerking op afstand of gespecialiseerde SDK's toe naarmate de workflow volwassener wordt.

Het aankoopargument: Voor organisaties die een standaard, vaste app-ervaring nodig hebben, is maatwerkontwikkeling mogelijk overbodig. Voor organisaties die AI-brillen onderdeel willen maken van een gecontroleerde operationele workflow, is de gedocumenteerde Glass3 SDK juist de reden dat de hardware interessanter wordt. Het bedrijf koopt een aanpasbaar endpoint, niet alleen een draagbaar display of een camera.

Beperkingen en technische risico's om rekening mee te houden

• Op Android gerichte SDK: De openbare Glass3 SDK richt zich op native Android. Volgens de FAQ van Rokid worden iOS en native HarmonyOS niet ondersteund. Een uni-app-integratie is alleen mogelijk door zelf een bridge naar de native Android SDK te bouwen.
• Compact display: Het staande canvas van 480 × 640 is geschikt voor beknopte prompts, niet voor drukke zakelijke dashboards. Goed workflowontwerp is noodzakelijk.
• Mismatch tussen SDK en changelog: Valideer SDK-artefacten, demo en OTA samen en houd rekening met versieverschillen tussen de Chinese en Engelse changelogs.
• Afhankelijkheid van online services: Bepaalde ASR-, AI- en OpenAPI-functies vereisen netwerktoegang, enterprise-credentials of service-provisioning.
• Geen open offline ASR in de huidige FAQ: Offline TTS en vaste offline commando's kunnen bijdragen aan robuuste interactie, maar vrije offline spraak-naar-tekst staat momenteel niet als ingebouwde functie gedocumenteerd.
• Complexiteit van verbindingen: Bluetooth en P2P lossen verschillende problemen op. Herverbinden, permissies en statussynchronisatie vragen om engineering van productiekwaliteit.
• RTC uit de kern verwijderd: Rokid heeft RTC-bellen in 2.1.7-E uit de basis-Phone SDK verwijderd. Voor samenwerking op afstand gebruikt u de Remote Collaboration SDK van Rokid of een apart ontwikkelde oplossing.
• Uitroldetails vereisen validatie: De openbare SDK-documentatie is sterk op het gebied van ontwikkeling, maar vlootbeheer in productie en provisioning via de Lingmou-console of de QR-scan-app moeten voor de omgeving van de klant worden bevestigd voordat u opschaalt.

Voor- en nadelen van zakelijke maatwerkontwikkeling

Voordelen:

• Native Android-ontwikkelmodel
• Openbare Maven-artefacten
• Officiële demo voor bril + telefoon
• Bluetooth en P2P
• Messaging/bestanden/media
• Camera en live preview
• Spraak-/AI-/herkenningsservices
• Directe Wi-Fi mogelijk
• Enterprise OpenAPI
• Mogelijkheden voor autostart en het aanpassen van events.

Nadelen:

• Native SDK-ondersteuning alleen voor Android
• Compact, vast display
• Afstemming van versies/OTA
• Bepaalde online functies vereisen enterprise-toegang
• Beperkte offline ASR
• Details over provisioning/vlootbeheer in productie vereisen projectspecifieke bevestiging.

Eindoordeel

Rokid AI Glasses Enterprise is het overwegen waard als het bedrijf een specifieke handsfree workflow wil bouwen in plaats van een generieke consumentenapplicatie uit te rollen. De huidige Glass3 enterprise-stack biedt Android-ontwikkelaars een gedocumenteerde route om op de bril te bouwen, deze te koppelen aan een Android-telefoon, besturingsdata via Bluetooth te versturen, media over te dragen via Wi-Fi P2P en de workflow te koppelen aan backendsystemen of bepaalde Rokid OpenAPI-services.

De sterkste toepassingen zijn begeleide inspecties, buitendienst, het vastleggen van bewijs, procedureel werk en andere taken waarbij de medewerker er baat bij heeft om één instructie tegelijk te zien en beide handen vrij te houden. De belangrijkste beperking is niet een gebrek aan API's. Het gaat om de technische discipline die nodig is rond het kleine display, de verbindingsstatus, permissies, SDK-/OTA-compatibiliteit en de afhankelijkheid van online services.

Voor een zakelijke koper is de belangrijkste evaluatievraag: “Kunnen we onze workflow afstemmen op de gedocumenteerde ontwikkelstack, en kunnen we de applicatie gedurende de hele levenscyclus ondersteunen?” Is het antwoord ja, dan biedt maatwerksoftware de route om Rokid Glass3 van een algemene AI-bril om te vormen tot een operationeel apparaat voor een specifiek doel.

Evalueert u Rokid AI Glasses Enterprise voor inspecties, buitendienst, logistiek, begeleid werk of eigen AI-workflows? VR Expert kan u helpen de hardware te beoordelen, een proof of concept te definiëren en de uitrolroute te valideren. Bekijk de productpagina van Rokid AI Glasses Enterprise voor het apparaat, de beschikbaarheid en de aankoopopties. Voor het afbakenen van maatwerkontwikkeling of advies over de uitrol kunt u contact opnemen met VR Expert.