Slik utvikler du skreddersydd programvare for Rokid AI Glasses Enterprise

Sammendrag

Rokid AI Glasses Enterprise kan videreutvikles til en formålsbygd forretningsenhet i stedet for bare å brukes med forhåndskonfigurerte applikasjoner. Rokids nåværende Sprite Enterprise-dokumentasjon gir tilgang til en Glasses SDK for applikasjoner som kjører direkte på Glass3, en Phone SDK for Android-baserte følgeapper og OpenAPI-tjenester for integrasjoner på skysiden. Sammen støtter disse lagene enhetstilkobling, meldinger, filoverføring, kamera- og medieopptak, direktevideo, talefunksjoner, AI-tjenester, gjenkjenning, enhetsstatus og arbeidsflyter for virksomheter.

For et utviklingsteam er den praktiske fremgangsmåten velkjent: bygg native Android-prosjekter i Android Studio, legg til Rokids Maven-repository og SDK-avhengigheter, kjør Rokids offisielle demo med to prosjekter, etabler Bluetooth for oppdagelse og styring, bytt til Wi-Fi P2P for store filer og lyd/video, og koble deretter arbeidsflyten til selskapets backend. En frittstående brilleapp er også mulig når bruksområdet ikke krever en følgetelefon.

Utover selve SDK-en kommer den viktigste verdien av å erstatte en generisk wearable-opplevelse med en kontrollert arbeidsflyt. En tekniker kan motta en arbeidsordre, se neste instruksjon på skjermen, bekrefte et trinn med stemmen eller via maskinvareinndata, samle visuell dokumentasjon og sende resultatet til et CMMS, ERP eller en skreddersydd plattform. Det gjør brillene relevante for inspeksjoner, feltservice, veiledet arbeid, logistikk, dokumentasjon og andre håndfrie prosesser. De viktigste forbeholdene er at den native SDK-støtten kun gjelder Android, versjons- og OTA-kompatibilitet, krav om API-nøkkel for enkelte nettbaserte tjenester og en kompakt skjerm på 480 x 640 som krever gjennomtenkt UI-design.

Hva Rokid gjør tilgjengelig for utviklere

Rokid deler bedriftsstakken inn i en SDK med to sider pluss en separat OpenAPI-plattform. Å forstå denne inndelingen før du skriver kode forhindrer en vanlig feil: å prøve å få brillene til å gjøre alt, når en telefon eller backend egner seg bedre for nettverk, autentisering, lagring eller integrasjon med forretningssystemer.

Brilleapplikasjon:

• Kjører på: Rokid Glass3
• Typisk ansvar: Gjengir brukergrensesnittet på brillene og gir tilgang til funksjoner på brillesiden, som kamera/media, enhetsstatus, meldinger, tale, AI og gjenkjenning, via Glasses SDK.

Følgeapplikasjon:

• Kjører på: Android-telefon
• Typisk ansvar: Oppdager og kobler til Glass3, håndterer Bluetooth og Wi-Fi P2P, utveksler meldinger/filer, mottar mediestrømmer og kan videreformidle forretningsdata.

Sky-/forretningslag:

• Kjører på: Din backend + Rokid OpenAPI der det er relevant
• Typisk ansvar: Lagrer forretningsdata, autentiserer brukere, kobler til ERP-/CMMS-/CRM-systemer og kan bruke Rokid OpenAPI-moduler som meldings- eller enhets-API-er når disse er klargjort.

Praktisk vurdering: For skreddersydd bedriftsprogramvare er den nyttige arkitekturen som regel «tynt UI på brillene + pålitelige enhetstjenester + forretningslogikk på telefon/backend». Å holde brilleopplevelsen fokusert reduserer UI-kompleksiteten og gjør prosjektet enklere å vedlikeholde, samtidig som håndfri interaksjon bevares der den betyr noe.

Utviklingsstakken i korte trekk

• Målmaskinvare i offentlig bedriftsdokumentasjon: Rokid Glass3
• Utviklingsmodell: Native Android-applikasjonsutvikling
• Glasses SDK-artefakt: com.rokid.security:glass3.open.sdk
• Phone SDK-artefakt: com.rokid.security:phone.sdk
• Gjeldende avhengighet vist i Quick Start: 2.2.0-E for begge SDK-ene
• Nyeste synlige oppføring i endringsloggen da undersøkelsen ble gjort: V2.2.0-E, datert 6. august 2026, med anbefalt OTA 1.19.e006-20260806-150201 eller nyere.
• Anbefalte verktøy: Android Studio 2022+, JDK 17+
• Demomiljø: Android SDK 34, JDK 17, Android-telefon, Rokid Glass3
• Koordinatsystem for brilleskjermen: Fast 480 x 640 i stående format
• Primære lokale transportkanaler: Klassisk Bluetooth og Wi-Fi P2P
• Skyautentisering: Enterprise API Key for Rokid OpenAPI og utvalgte nettbaserte tjenester
• Støttet telefonplattform: Android; den offentlige FAQ-en sier at iOS og native HarmonyOS ikke støttes av Glass3 SDK

Hva kan du bygge med Rokid AI Glasses Enterprise?

Den offentlige SDK-en er omfattende nok til å støtte mer enn én enkelt demoapplikasjon. Nøyaktig hvilket produkt du bygger, avhenger av hvilke funksjoner du kombinerer og hvor mye logikk du beholder på selve brillene.

Veiledet feltservice: vis én instruksjon om gangen, bekreft fullføring, ta bilder eller video og send strukturert dokumentasjon tilbake til et arbeidsordresystem.

Inspeksjon og samsvar: presenter sjekklister, bruk kameraopptak eller gjenkjenning, legg ved tidsstemplet dokumentasjon og eskaler avvik.

Arbeidsflyter for lager og logistikk: vis plukk- eller oppgaveinformasjon, utveksle enkle kommandoer over Bluetooth og bruk spesialiserte skanneintegrasjoner der det er nødvendig.

Visuell fjernassistanse: motta en direkte videostrøm på følgesiden eller integrer en dedikert løsning for fjernsamarbeid. Rokid fjernet RTC-samtaler fra kjernen i Phone SDK i versjon 2.1.7-E, så sanntidssamarbeid bør bygges opp rundt Android og Web: Rokids Remote Collaboration SDK eller din egen godkjente transportløsning, i stedet for at man antar at det er innebygd i basis-SDK-en.

AI-assistent for virksomheten: kombiner taleinndata, TTS, AI-chat eller selskapets egne AI-tjenester med et arbeidsflytspesifikt brukergrensesnitt i stedet for å eksponere brukerne for en generisk chatbot.

Innsamling av bevis og dokumentasjon: utløs bilder, video eller lyd, overfør større mediefiler over P2P og synkroniser resultatene med en backend.

Dedikert enhet med ett formål: start selskapets applikasjon automatisk etter omstart og knytt støttede maskinvarehendelser til handlinger i arbeidsflyten, forutsatt validering mot fastvaren på målenheten.

Steg for steg: slik utvikler du skreddersydd programvare for Rokid AI Glasses Enterprise

Trinn 1: Definer arbeidsflyten før du velger arkitektur

Begynn med den operative prosessen, ikke SDK-listen. Skriv ned nøyaktig hva arbeideren må se, si, registrere og bekrefte. Bestem deretter hvilken enhet som skal ha ansvaret for hver oppgave. En godt avgrenset brilleapplikasjon viser vanligvis konsis informasjon og registrerer inndata, mens telefonen eller backend håndterer tyngre forretningslogikk.

Frittstående brilleapp:

• Passer best for: Enkel lokal arbeidsflyt, opptak på enheten, drift uten nett eller med begrenset tilkobling
• Fordeler: Færre komponenter, direkte opplevelse på brillene
• Avveining: Du må håndtere mer lagrings-/nettverkslogikk på brillene; enkelte nettbaserte funksjoner krever fortsatt legitimasjon eller tilkobling

Briller + Android-telefon:

• Passer best for: De fleste bedriftspiloter, direktemedier, filoverføring, fjernstyring, følgeapp for forretningsapplikasjoner
• Fordeler: Den best dokumenterte tilkoblingsveien; telefonen kan håndtere autentisering, nettverk og UI som ikke hører hjemme i brilleglasset
• Avveining: Krever en Android-telefon og robust logikk for gjenoppkobling

Briller + telefon + backend:

• Passer best for: ERP-/CMMS-/CRM-integrasjon, revisjonsspor, sentralt administrerte arbeidsordrer, AI-tjenester
• Fordeler: Passer best for skalerbare forretningsarbeidsflyter og datastyring
• Avveining: Krever mer integrasjons-, sikkerhets- og backend-utvikling

Anbefaling: For et første B2B-konseptbevis bør du bruke modellen med briller + Android-telefon + backend, med mindre bruksområdet tydelig drar nytte av en frittstående brilleløsning. Den samsvarer godt med Rokids dokumenterte flyt med to enheter og gir utviklingsteamet rom til å flytte nettverk, legitimasjon og datalagring bort fra brillene.

Trinn 2: Skaff riktig maskinvare og tilgang

Før du installerer Android Studio, må du bekrefte at maskinvaren faktisk kjører bedriftsprogramvaren. Rokids FAQ sier at bedrifts-/arbeidsversjoner vanligvis har en «e» i systemversjonen. SDK-dokumentasjonen skiller også mellom bedrifts- og forbrukersystemer, så identifisering av fastvaren er en del av prosjektoppsettet, ikke noe man tar seg av i etterkant.

Rokid AI Glasses Enterprise (Rokid Glasses-maskinvaren) som kjører bedriftsversjonen av systemet/fastvaren (systemversjon som slutter på «e»).

Glass3-datakabelen for feilsøking. Rokid advarer uttrykkelig om at den vanlige ladekabelen kan gi strøm til brillene, men ikke kan brukes av Android Studio til feilsøking.

En Android-telefon hvis du bruker Phone SDK.

En utviklings-PC med Android Studio og JDK 17.

Bedriftskonto og API-nøkkel hvis prosjektet skal bruke Rokid OpenAPI eller nettbaserte funksjoner som krever autentisering.

Tilgang til nøyaktig den OTA-versjonen du planlegger å rulle ut på hele pilotflåten.

Ikke hopp over kabelkontrollen: Rokid oppgir datakabelen for feilsøking som påkrevd fordi den gjør at Android Studio kan gjenkjenne brillene, installere APK-er og lese logger. Hvis brillene lader, men ikke dukker opp som en enhet, bør du sjekke kabelen før du feilsøker Gradle, ADB eller SDK-en.

Trinn 3: Klargjør Android-utviklingsmiljøet

Rokids Quick Start anbefaler Android Studio 2022 eller nyere og JDK 17 eller nyere, og oppgir at Glass3 SDK støtter Android 8.0 eller nyere. Den offisielle demoveiledningen bruker for øyeblikket Android SDK 34. Rokids FAQ anbefaler separat Android 7.0 / API 24 eller nyere og sier at man skal bekrefte Gradle-konfigurasjonen i den gjeldende SDK-pakken og demoen. I et reelt prosjekt bør du behandle demoens Gradle-filer som fasit for den nøyaktige versjonen du integrerer.

1. Installer Android Studio 2022 eller nyere.

1. Installer og velg JDK 17 eller nyere for Gradle.

1. Installer Android SDK-versjonen som kreves av den gjeldende Rokid-demoen. Den nåværende demoveiledningen oppgir SDK 34.

1. Aktiver vanlig Android-feilsøking på utviklingstelefonen.

1. Koble til Glass3 med datakabelen for feilsøking og bekreft at Android Studio ser en målenhet som ligner på «Rokid RG-glasses».

1. Installer Rokids verktøy for skjermprojisering/speiling hvis du vil inspisere brillegrensesnittet fra PC-en. Rokid anbefaler sterkt projisering under utvikling.

Trinn 4: Kjør Rokids offisielle demo før du lager din egen applikasjon

Dette er det viktigste praktiske trinnet i hele prosessen. Den offisielle demoen bekrefter utviklingsmiljøet, SDK-binærfilene, tillatelsene, maskinvaretilkoblingene og versjonskombinasjonen før din egen kode blir enda en variabel.

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

# Glasses demo
cd glassdemo
./gradlew assembleDebug

# Phone demo
cd ../glass3sdkphonedemo
./gradlew assembleDebug

Repositoryet inneholder to separate Android-prosjekter: ett for brillene og ett for Android-telefonen. Rokid anbefaler å kjøre demoen på telefonsiden først, deretter demoen på brillesiden. Når begge er installert, søker du etter Glass3 fra telefondemoen og oppretter tilkoblingen.

1. SDK-initialisering. Bestått når: Begge prosjektene starter og rapporterer en gyldig SDK-status.
2. Bluetooth. Bestått når: Telefonen finner og kobler til Glass3.
3. Meldinger. Bestått når: Tekst- eller kontrollmeldinger kan sendes mellom telefon og briller.
4. Overføring av små filer. Bestått når: En liten fil kan utveksles uten feil.
5. Wi-Fi P2P. Bestått når: En P2P-kanal kan opprettes for operasjoner med høy båndbredde.
6. Media. Bestått når: Bilde, video eller direkteforhåndsvisning kan utløses og mottas.

Hvorfor dette betyr noe kommersielt: Et konseptbevis for en kunde blir mye enklere å avgrense når de grunnleggende enhetsfunksjonene er validert først. Da kan du bruke prosjekttiden på selve arbeidsflyten, integrasjonen og brukeropplevelsen i stedet for å feilsøke et uverifisert SDK-oppsett.

Trinn 5: Opprett dine egne prosjekter og legg til Rokids Maven-repository

Når demoen fungerer, oppretter eller åpner du dine egne Android-prosjekter. Rokid publiserer SDK-artefaktene via sitt Maven-repository. Legg til repositoryet sammen med Google og Maven Central, og legg deretter til brilleavhengigheten i brilleappen og telefonavhengigheten i følgeappen.

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

// Glasses app
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

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

Rokids gjeldende Quick Start viser versjon 2.2.0-E, med anbefalt OTA 1.19.e006-20260806-150201 eller nyere. Bedriftsteam bør låse og teste en kjent kombinasjon av SDK + OTA i stedet for å oppdatere komponentene automatisk og uavhengig av hverandre.

Regel for versjonskontroll: Før en pilot eller produksjonslansering bør du registrere OTA-versjonen på brillene, Glasses SDK-versjonen, Phone SDK-versjonen, demo-commiten og eventuelle spesialiserte SDK-versjoner i én kompatibilitetsmatrise. Kjør de grunnleggende tilkoblings- og medietestene på nytt hver gang en av disse komponentene endres.

Trinn 6: Deklarer bare de Android-tillatelsene arbeidsflyten din trenger

Rokids Quick Start lister opp vanlige tillatelser for nettverkstilgang, Wi-Fi, kamera, mikrofon, lagring, Bluetooth og enheter i nærheten. På moderne Android-versjoner er det ikke nok å deklarere farlige tillatelser i manifestet. Telefon- og brilleappene dine må be om de nødvendige tillatelsene under kjøring og håndtere avslag på en ryddig måte.

• Bluetooth-skanning/-tilkobling: Enhetsoppdagelse, sammenkobling, små meldinger og styring
• Wi-Fi i nærheten / Wi-Fi Direct: P2P-tilkobling for filer, bilder, video og sanntidsstrømmer
• Kamera: Bilde-/videoopptak og flyter for visuell gjenkjenning
• Mikrofon: Lydopptak, ASR og stemmeinteraksjon
• Nettverk / Internett: Backend-API-er, Rokids nettbaserte tjenester, skysynkronisering
• Lagring: Håndtering av medier og overførte filer, avhengig av oppførselen til Android-versjonen / SDK-en på målenheten

Råd for produksjon: Ikke kopier hele demomanifestet ukritisk. Å minimere tillatelser gjør sikkerhetsgjennomgangen enklere og reduserer risikoen for at brukere avslår en tillatelse som arbeidsflyten egentlig ikke trenger.

Trinn 7: Initialiser Glasses SDK og registrer appens identitet

Brilleapplikasjonen binder seg til Rokids sikkerhetstjeneste og registrerer deretter en klientidentifikator. Den viktige arkitekturregelen er at den samme klient-ID-en er kjent for følgeappen på telefonen når de to sidene utveksler applikasjonsspesifikke meldinger.

// Illustrative structure, simplified from Rokid's initialization flow
if (!GlassSdk.isReady()) {
    GlassSdk.bindSecurityService(context, object : IServiceConnectionCallback {
        override fun onServiceConnected() {
            GlassSdk.registerClient("FieldServiceApp", messageCallback)
        }
    })
}

Etter initialiseringen får du tilgang til funksjonene på brillesiden via tjenesteinngangspunkter som eksponeres av GlassSdk. De offentlige API-gruppene omfatter felles-/enhetsfunksjoner, klassisk Bluetooth, P2P, meldinger, media, filhåndtering, tale/AI, gjenkjenning og andre tjenester. Ikke initialiser alle funksjoner ved oppstart. Hent og aktiver bare de tjenestene som kreves for det gjeldende skjermbildet eller trinnet i arbeidsflyten.

Helsesjekk: Bruk GlassSdk.isReady() som et enkelt diagnostisk signal før du kaller funksjonstjenester. Hvis den returnerer false, må du rette initialiseringen eller tjenestebindingen før du tester funksjoner på høyere nivå.

Trinn 8: Initialiser Android Phone SDK med samsvarende klient-ID-er

På telefonsiden initialiserer du Rokids mobilmotor og registrerer klient-ID-ene telefonen skal kommunisere med. Rokids Phone SDK er tilkoblings- og kontrollaget for enhetsoppdagelse, Bluetooth/P2P, meldinger, filer, mottak av medier, synkronisering av konfigurasjon og tilknyttede operasjoner.

// Application-level outline
val engineParam = EngineParam.Builder()
    .setClientIds(listOf("FieldServiceApp"))
    .setApiKeyCredentials(apiKeyCredentials)
    .build()
IMobileEngine.initSDK(engineParam)

// Diagnostic check
val ready = PSecuritySDK.getMobileEngineService().isInit()

Hvis utvalgte nettbaserte funksjoner krever API Key Credentials, inneholder demoen plassholdere for autentiseringsinformasjon som må erstattes med legitimasjon innhentet gjennom Rokids forretningsprosess. Hold skyhemmeligheter utenfor kildekontrollen, og unngå å bygge inn langvarige plattform-API-nøkler i en klientapplikasjon som distribueres.

Trinn 9: Koble til over Bluetooth først, og bruk deretter P2P for båndbredde

Rokid dokumenterer to lokale transportmønstre med ulike oppgaver. Klassisk Bluetooth egner seg for oppdagelse, tilkobling, kontrollmeldinger og små filer. Wi-Fi P2P er den beste kanalen for bilder, store filer, video og sanntidsmedier. Å bruke feil transport er en enkel måte å lage en applikasjon som fungerer i en demo, men som oppleves upålitelig i felt.

Klassisk Bluetooth:

• Bruk den til: Oppdagelse, sammenkobling, kontrollkommandoer, kompakte JSON-meldinger, små filer
• Rolle i designet: Kontrollplan med lav båndbredde

Wi-Fi P2P:

• Bruk den til: Store filer, bilder, video, lyd-/videostrømmer, synkronisering med høy gjennomstrømning
• Rolle i designet: Dataplan med høy båndbredde

Direkte Wi-Fi på brillene:

• Bruk det til: Backend-tilgang fra en brilleapplikasjon når enheten er koblet til Wi-Fi
• Rolle i designet: Nyttig for utvalgte frittstående flyter; du bør likevel utforme atferd for frakoblet modus og nye forsøk

En robust bedriftsapp bør behandle tilkoblinger som tilstandsmaskiner i stedet for engangshendelser. Håndter eksplisitt tap av Bluetooth, nedkobling av P2P, telefon i dvale, Wi-Fi-endringer og omstart av brillene. Brukeren bør få en enkel status som «kobler til på nytt» eller «venter på synkronisering», ikke et Android-unntak eller en stille feil.

Trinn 10: Definer en liten applikasjonsprotokoll for forretningsmeldinger

Rokid leverer transport- og meldingstjenestene, men applikasjonen din trenger likevel en avtale om hva en forretningsmelding betyr. Hold denne avtalen kompakt, versjonert og uavhengig av brukergrensesnittet. JSON er et praktisk valg for tidlige prosjekter fordi det er lett å inspisere, selv om det nøyaktige nyttelastformatet er en del av ditt eget applikasjonsdesign og ikke et krav fra Rokid.

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

Ved fullføring kan brillene returnere en liten statusmelding som viser til arbeidsordre-ID-en og nummeret på trinnet. Selve mediefilen bør sendes via P2P-kanalen for filer/medier i stedet for å bygges inn i kontrollmeldingen. Denne separasjonen holder kommandokanalen responsiv og gjør nye forsøk enklere.

Trinn 11: Design brillegrensesnittet for 480 x 640, ikke som en telefonapp

Glass3-skjermen bruker et fast koordinatsystem på 480 x 640 i stående format. Rokids FAQ anbefaler å plassere hovedinnholdet i det sentrale området på 480 x 400, bruke de øverste 160 pikslene og de nederste 80 pikslene til sekundær informasjon, og flytte viktig innhold nedover fordi de øverste rundt 40 pikslene kan vise optisk refleksjon. Operativsystemet har ikke vanlig skjermrotasjon, så brede oppsett må utformes innenfor det stående lerretet.

Vis én oppgave, instruksjon eller beslutning om gangen. Lange dashbord egner seg dårlig for brilleglasset.

Bruk svart bakgrunn der det er mulig. Rokid anbefaler dette for å redusere opplevd flimring ved oppstart eller overganger.

Ikke plasser kritisk tekst eller knapper i refleksjonsområdet øverst (ca. 40 px).

Gjør tilstandsendringer tydelige uten å være avhengig av kompleks fargekoding. Rokid anbefaler grønt som primær visuell stil.

Vis en tydelig tilkoblingsstatus og en tydelig «synkronisert / venter»-status for forretningsdata.

Hold interaksjonsmålene enkle nok til at de kan betjenes med støttet maskinvareinndata eller stemme, uten å tvinge frem presis navigasjon i berøringsstil.

Forretningsmessig betydning: Skjermen er liten, men det kan være en fordel for prosedyrebasert arbeid. Den oppmuntrer programvareteam til å fjerne uvesentlig informasjon og bare vise den neste handlingen arbeideren trenger.

Trinn 12: Legg til funksjoner for kamera, bilde, video og direkteforhåndsvisning

Glasses SDK gir tilgang til mediefunksjoner for bilde, video, lyd og forhåndsvisning. Phone SDK kan motta mediestrømmer fra brillene. Rokids FAQ oppgir en standard videostrøm på 1080P med omtrent 15 til 19 bilder per sekund og rundt 300 ms avspillingsforsinkelse på telefonen, og påpeker at utdataene kan være H.264 eller dekodet NV21, avhengig av API og demovei. Betrakt disse tallene som gjeldende veiledning for implementering, ikke som en garantert SLA.

Bruk stillbilder til inspeksjonsdokumentasjon, bevis på fullført arbeid og senere AI-behandling.

Bruk H.264 når telefonen eller backend hovedsakelig skal videresende eller lagre strømmen. Rokids endringslogg for 2.1.8-E la til kontroll over automatisk dekoding fra H.264 til NV21, slik at unødvendig dekoding kan unngås.

Bruk NV21 når en datasynspipeline på telefonsiden trenger dekodede bilderammer.

Bruk Wi-Fi P2P i stedet for klassisk Bluetooth til direkteforhåndsvisning og medieoverføring.

Hvis du trenger kamera pluss skjermoverlegg i det innspilte resultatet, bør du gå gjennom Rokids gjeldende API-er for AR Mix / AR-opptak og tilpasse dem til den installerte SDK-versjonen.

En praktisk detalj fra Rokids FAQ er viktig for dokumentasjonsflyter: Etter en vellykket P2P-opplasting kan bilder på brillene bli ryddet bort av systemet. Behandle kopien som er mottatt på telefonen eller i backend, som den forretningsmessige fasiten, og bekreft at opplastingen er fullført før arbeidsordren går videre.

Trinn 13: Legg til tale, TTS og AI på en gjennomtenkt måte

Tale kan være verdifullt når arbeidere ikke kan bruke hendene, men det bør knyttes til eksplisitte handlinger i arbeidsflyten. SDK-dokumentasjonen for brillesiden gir tilgang til ASR, TTS, håndtering av frakoblede kommandoer og AI-chat. For øyeblikket sier FAQ-en at frakoblet TTS krever SDK 2.2.0 eller nyere, selv om endringsloggen oppgir den frakoblede TTS-tjenesten fra 2.1.2; test det på den versjonen du har låst. Åpen frakoblet ASR støttes for øyeblikket ikke som standard. For frakoblet tale-til-tekst henviser Rokid utviklere til private ASR/TTS-tjenester i stedet for å hevde at det finnes en innebygd frakoblet ASR-løsning.

Frakoblede kommandoord:

• God bruk: Korte, faste kommandoer som «neste», «tilbake», «opptak»
• Merknad om bedriftsdesign: Bra for deterministisk håndfri styring

Nettbasert ASR:

• God bruk: Fri tale-til-tekst
• Merknad om bedriftsdesign: Krever oppsett av nettverk/tjeneste og bør ha reserveatferd

TTS / frakoblet TTS:

• God bruk: Lese opp ledetekster, advarsler eller korte bekreftelser
• Merknad om bedriftsdesign: Nyttig når skjermbildet skal holdes minimalt

AI-chat / privat AI:

• God bruk: Kontekstuell assistanse eller tolking
• Merknad om bedriftsdesign: Hold modellen bak arbeidsflyten. Valider databehandling, ventetid og grenser for svarene.

Trinn 14: Koble arbeidsflyten sikkert til backend

Det er to separate backend-spørsmål: hvordan din egen applikasjon når forretningssystemene dine, og om du bruker Rokid OpenAPI. Applikasjonen kan sende data via den sammenkoblede telefonen, eller en brilleapplikasjon kan få direkte tilgang til internett når Glass3 er koblet til Wi-Fi. For selskapets systemer er standard backend-API-er som regel det ryddigste integrasjonspunktet, fordi legitimasjon, revisjonslogger, datavalidering og forretningsregler blir værende på serversiden.

Rokid OpenAPI er et separat plattformlag. Den offisielle dokumentasjonen krever en aktivert bedriftskonto og API-nøkkel. Forespørsler autentiseres med et Bearer-token, opprettede nøkler utløper, og standard gyldighet er én måned med mindre noe annet er konfigurert. Rokid advarer uttrykkelig mot å eksponere API-nøkler i offentlige repositorier eller klienter.

Sikkerhetsregel: Bruk en proxy på serversiden for Rokids plattformlegitimasjon når arkitekturen tillater det. En APK for mobil eller briller kan inspiseres. Ikke anta at en API-nøkkel blir hemmelig bare fordi den er skjult i Kotlin eller native kode.

Gjeldende Rokid OpenAPI-moduler omfatter blant annet meldings- og enhets-API-er, i tillegg til andre bedriftsfunksjoner (merk at disse meldings- og enhets-API-ene bare er tilgjengelige hvis enhetene er registrert i Rokids Lingmou-konsoll). Enhets-API-et kan for eksempel hente informasjon om registrerte Glass-enheter, mens meldings-API-et kan sende en forretningsmelding til en målenhet. Bruk disse tjenestene bare når de løser et reelt behov i utrullingen. En skreddersydd backend i selskapet er fortsatt rett sted for ERP, CMMS, CRM, identitet og orkestrering av arbeidsflyter.

Trinn 15: Konfigurer bedriftsatferd som autostart og tastehåndtering

En bærbar enhet blir mer nyttig i drift når brukeren ikke trenger å navigere i en launcher i forbrukerstil hver morgen. Rokid dokumenterer en autostartmekanisme som kan starte en konfigurert applikasjon etter oppstart på støttede bedriftssystemer. Rokid dokumenterer også tilpasning av maskinvarehendelser og, i endringsloggen for 2.1.9-E, API-er for lytting på og avskjæring av hendelser.

Bruk autostart for dedikerte arbeidsflyter innen inspeksjon, sikkerhet eller industri der brillene skal åpne rett i forretningsapplikasjonen.

Utsett SDK-avhengig arbeid en kort stund etter oppstart, og bekreft at tjenestene er klare før arbeidsflyten startes.

Knytt støttede tastehendelser til et lite antall meningsfulle handlinger, som bekreft, ta opp eller avbryt.

Valider alle autostart- og avskjæringsfunksjoner mot fastvaren på bedriftsenhetene, fordi enkelte funksjoner på systemnivå er versjonsavhengige.

Sørg alltid for en vei for støtte/gjenoppretting. En låst arbeidsflyt som en administrator ikke kan gå ut av, er en driftsrisiko.

Trinn 16: Bygg inn atferd for frakoblet modus, nye forsøk og gjenoppretting

En demo forutsetter ofte perfekt Bluetooth, Wi-Fi og skytilgang. Det kan ikke en utrulling i felt. Lagre den minste arbeidsflyttilstanden som trengs for å overleve frakobling fra telefonen, P2P-feil eller midlertidig nettverksbrudd. Hver forretningshandling bør være idempotent der det er mulig, slik at nye forsøk ikke skaper dupliserte arbeidsordrehendelser eller medieposter.

Bufre gjeldende arbeidsordre-ID, trinn-ID og siste bekreftede handling.

Sett usendte resultater i kø med en synlig «venter på synkronisering»-status.

Bruk unike operasjons-ID-er slik at backend trygt kan avvise duplikater.

Koble til Bluetooth på nytt først, og gjenopprett P2P bare hvis det trengs overføring med høy båndbredde.

Merk aldri et medieavhengig trinn som fullført før det er kvittert for målkopien.

Sørg for en trygg reserveløsning for brukeren når nettbasert ASR eller AI ikke er tilgjengelig. Faste frakoblede kommandoer kan fortsatt dekke kjernenavigasjonen.

Trinn 17: Test på ekte maskinvare med en testmatrise for bedrift

Emulatorer er ikke nok for et brilleprosjekt, fordi optikk, termisk oppførsel, Bluetooth, P2P, kamera, mikrofon og bærekomfort alle påvirker programvareopplevelsen. Test hele systemet på nøyaktig den bedrifts-OTA-en som er planlagt for piloten.

• Oppstart og autostart: Kaldstart, appstart, SDK-beredskap, gjenoppretting hvis tjenestebindingen går tregt
• Bluetooth: Første sammenkobling, gjenoppkobling, telefon i dvale, gjenoppretting etter å ha vært utenfor rekkevidde
• P2P: Gjentatt tilkobling/frakobling, stor fil, direktestrøm, Wi-Fi-endringer
• Tillatelser: Ny installasjon, avslått tillatelse, senere godkjenning, forskjeller mellom Android-versjoner
• Media: Bilde-/videokvalitet, filkvittering, nytt forsøk etter mislykket opplasting, opprydding i lagring
• Tale: Støyende omgivelser, ingen nettverk, ustøttet frase, avbrudd i TTS
• UI / optikk: Lesbarhet, refleksjonsområdet øverst, lang tekst, synlighet for status, brukertretthet
• Ytelse: Lange økter, CPU-temperatur, tilgjengelig minne, prosessoverlevelse
• Backend: Treg respons, duplisert forespørsel, utløpt token, server utilgjengelig
• Sikkerhet: Håndtering av legitimasjon, sladding i logger, tap av enhet, tilbakekalling av konto

Rokids FAQ foreslår spesifikt å overvåke minne og CPU-temperatur under ytelsesfeilsøking, og advarer om at svært lite tilgjengelig minne gjør det mer sannsynlig at bakgrunnsprosesser avsluttes. Det er enda en grunn til å holde brilleappen fokusert og flytte uvesentlige tjenester andre steder.

Trinn 18: Pakk piloten og kontroller utrullingsgrunnlaget

Under utviklingen kan APK-er installeres via Android Studio med Glass3-datakabelen for feilsøking. En produksjonsutrulling krever en strengere lanseringsprosess. Rokid dokumenterer ingen MDM-lignende policykontroll (som kioskmodus, fjernsletting eller app-policyer). I stedet dokumenteres registrering av enheter og statussporing via Lingmou-konsollen og OpenAPI, mens versjon 2.2.0-E gjør det mulig å installere APK-er via en app for QR-skanning. Avklar utrullingsmekanisme, klargjøringsrettigheter, bedriftsfastvare og oppdateringspolicy med Rokid eller distributøren før dere forplikter dere til en arkitektur for utrullingen.

1. Frys de testede SDK- og OTA-versjonene for piloten.

1. Lag signerte release-APK-er for brille- og telefonapplikasjonene.

1. Dokumenter klient-ID-er, pakkenavn og konfigurasjon av backend-miljøet.

1. Klargjør API-nøkler og backend-hemmeligheter via sikker infrastruktur, ikke kildekode.

1. Definer hvem som kan oppdatere brillene, telefonappen og backend, og i hvilken rekkefølge.

1. Kjør regresjonstester etter hver OTA- eller SDK-endring før flåten oppdateres.

1. Etabler en støttevei for logger, enhetsidentitet, tilkoblingsdiagnostikk og tilbakerulling.

Eksempelarkitektur: en skreddersydd inspeksjonsapp for feltservice

Følgende er et praktisk designeksempel satt sammen ut fra Rokids dokumenterte funksjoner. Det er ikke en ferdig arbeidsflyt fra Rokid. Det viser hvordan utviklerstakken kan gjøre brillene til et dedikert forretningsendepunkt.

1. Start. Teknisk handling: Brilleappen starter automatisk og kontrollerer at SDK-en er klar. Forretningsverdi: Arbeideren starter direkte i selskapets arbeidsflyt.
2. Tildel oppgave. Teknisk handling: Telefon/backend sender et sammendrag av arbeidsordren som en kompakt melding. Forretningsverdi: Det er ikke nødvendig med manuelle oppslag på en telefon.
3. Veiled. Teknisk handling: Brillene viser én instruksjon i det sentrale visningsområdet. Forretningsverdi: Hendene er ledige til oppgaven.
4. Bekreft. Teknisk handling: Arbeideren sier en fast kommando eller bruker en støttet maskinvarehendelse. Forretningsverdi: Rask, deterministisk interaksjon.
5. Samle dokumentasjon. Teknisk handling: Brillene tar et bilde eller et kort klipp. Forretningsverdi: Visuelt bevis knyttes til riktig trinn.
6. Overfør. Teknisk handling: Mediene flyttes over P2P; en liten statusmelding bekrefter opplastingen. Forretningsverdi: Store datamengder holdes unna kontrollkanalen med lav båndbredde.
7. Synkroniser. Teknisk handling: Telefonen eller backend sender resultatet til CMMS-/ERP-API-et. Forretningsverdi: Eksisterende forretningssystemer forblir det autoritative systemet.
8. Avvik. Teknisk handling: Ved behov mottar telefonen en direktestrøm, eller appen utløser den godkjente løsningen for fjernassistanse. Forretningsverdi: En arbeidsleder kan se det arbeideren ser.
9. Fullfør. Teknisk handling: Backend kvitterer for fullføringen og returnerer neste oppgave. Forretningsverdi: Brukeren får en tydelig sluttilstand, og revisjonssporet er komplett.

Hvorfor skreddersydd programvare endrer forretningsgrunnlaget for Rokid AI Glasses Enterprise

Den viktigste verdien for virksomheten kommer av å tilpasse enheten til en eksisterende operativ prosess, eller av å omforme prosessen for håndfritt arbeid.

Formålsbygd UI: fjern forbrukermenyer og vis bare informasjonen som trengs i det aktuelle arbeidstrinnet.

Integrasjon med forretningssystemer: koble innsamlet dokumentasjon og arbeiderens handlinger til eksisterende ERP-, CMMS-, CRM- eller skreddersydde plattformer.

Håndfri datainnsamling: bruk kamera, stemme og inndata på brillene uten å måtte gå tilbake til en telefon eller et nettbrett gang på gang.

Kontrollert tilkobling: bruk Bluetooth til kommandoer og P2P til data med høy båndbredde i stedet for å tvinge alle funksjoner gjennom én kanal.

Egne grenser for AI: bruk AI der det tilfører verdi, samtidig som arbeidsflytregler, tillatelser og datastyring forblir under selskapets kontroll.

Dedikert enhetsatferd: autostart og hendelseshåndtering kan redusere friksjon i utrullinger med ett formål, når bedriftsfastvaren støtter det.

Utvidbar arkitektur: start med et lokalt konseptbevis, og legg deretter til backend-integrasjon, plattform-API-er, fjernsamarbeid eller spesialiserte SDK-er etter hvert som arbeidsflyten modnes.

Argumentet for innkjøp: For organisasjoner som trenger en standard, fast appopplevelse, kan skreddersydd utvikling være unødvendig. For organisasjoner som vil at AI-briller skal bli en del av en kontrollert operativ arbeidsflyt, er den dokumenterte Glass3 SDK-en grunnen til at maskinvaren blir mer interessant. Selskapet kjøper et tilpasningsdyktig endepunkt, ikke bare en bærbar skjerm eller et kamera.

Begrensninger og tekniske risikoer å planlegge for

• Android-fokusert SDK: Den offentlige Glass3 SDK-en er rettet mot native Android. Rokids FAQ sier at iOS og native HarmonyOS ikke støttes. En uni-app-integrasjon er bare mulig ved å bygge din egen bro til den native Android-SDK-en.
• Kompakt skjerm: Det stående lerretet på 480 x 640 egner seg for konsise ledetekster, ikke tette bedriftsdashbord. God arbeidsflytdesign er helt nødvendig.
• Avvik mellom SDK og endringslogg: Valider SDK-artefakter, demo og OTA samlet, og ta hensyn til versjonsforskjeller mellom de kinesiske og engelske endringsloggene.
• Avhengighet av nettbaserte tjenester: Utvalgte ASR-, AI- og OpenAPI-funksjoner krever nettverkstilgang, bedriftslegitimasjon eller klargjøring av tjenester.
• Ingen åpen frakoblet ASR i gjeldende FAQ: Frakoblet TTS og faste frakoblede kommandoer kan bidra til robust interaksjon, men fri frakoblet tale-til-tekst er foreløpig ikke dokumentert som innebygd.
• Transportkompleksitet: Bluetooth og P2P løser ulike problemer. Gjenoppkobling, tillatelser og tilstandssynkronisering krever utvikling av produksjonskvalitet.
• RTC fjernet fra kjernen: Rokid fjernet RTC-samtaler fra basisversjonen av Phone SDK i 2.1.7-E. Fjernsamarbeid bør bruke Rokids Remote Collaboration SDK eller en separat utviklet løsning.
• Utrullingsdetaljer må valideres: Den offentlige SDK-dokumentasjonen er sterk på utvikling, men flåtestyring i produksjon og klargjøring via Lingmou-konsollen eller QR-skanningsappen bør bekreftes for kundens miljø før oppskalering.

Fordeler og ulemper ved skreddersydd bedriftsutvikling

Fordeler:

• Native Android-utviklingsmodell
• Offentlige Maven-artefakter
• Offisiell demo for briller + telefon
• Bluetooth og P2P
• Meldinger/filer/media
• Kamera og direkteforhåndsvisning
• Tjenester for tale/AI/gjenkjenning
• Direkte Wi-Fi mulig
• Enterprise OpenAPI
• Muligheter for autostart og tilpasning av hendelser.

Ulemper:

• Native SDK-støtte kun for Android
• Kompakt, fast skjerm
• Koordinering av versjoner/OTA
• Utvalgte nettbaserte funksjoner krever bedriftstilgang
• Begrensning for frakoblet ASR
• Detaljer om klargjøring/flåtestyring i produksjon må bekreftes for hvert enkelt prosjekt.

Endelig vurdering

Rokid AI Glasses Enterprise er verdt å vurdere når selskapets mål er å bygge en dedikert håndfri arbeidsflyt i stedet for å ta i bruk en generisk forbrukerapplikasjon. Den nåværende Glass3-bedriftsstakken gir Android-utviklere en dokumentert vei til å bygge på brillene, koble dem sammen med en Android-telefon, sende kontrolldata over Bluetooth, overføre medier over Wi-Fi P2P og koble arbeidsflyten til backend-systemer eller utvalgte Rokid OpenAPI-tjenester.

De sterkeste bruksområdene er veiledede inspeksjoner, feltservice, dokumentasjonsinnsamling, prosedyrebasert arbeid og andre oppgaver der arbeideren har nytte av å se én instruksjon om gangen og samtidig ha begge hendene ledige. Den største begrensningen er ikke mangel på API-er. Det er den tekniske disiplinen som kreves rundt den lille skjermen, tilkoblingsstatus, tillatelser, SDK/OTA-kompatibilitet og avhengigheter av nettbaserte tjenester.

For en bedriftskjøper er det sentrale vurderingsspørsmålet: «Kan vi tilpasse arbeidsflyten vår til den dokumenterte utviklerstakken, og kan vi støtte applikasjonen gjennom hele livssyklusen?» Hvis svaret er ja, gir skreddersydd programvare muligheten til å gjøre Rokid Glass3 om fra generelle AI-briller til en formålsbygd driftsenhet.

For selskaper som vurderer Rokid AI Glasses Enterprise til inspeksjoner, feltservice, logistikk, veiledet arbeid eller skreddersydde AI-arbeidsflyter, kan VR Expert hjelpe med å vurdere maskinvaren, definere et konseptbevis og validere utrullingsveien. Gå til produktsiden for Rokid AI Glasses Enterprise for å se nærmere på enheten, tilgjengelighet og kjøpsalternativer. For avgrensning av skreddersydd utvikling eller råd om utrulling kan du kontakte VR Expert.