Sådan udvikler du skræddersyet software til Rokid AI Glasses Enterprise

Resumé

Rokid AI Glasses Enterprise kan udvikles til en specialbygget forretningsenhed i stedet for kun at blive brugt med forudkonfigurerede applikationer. Rokids nuværende Sprite Enterprise-dokumentation stiller et Glasses SDK til rådighed for applikationer, der kører direkte på Glass3, et Phone SDK til Android-ledsagerapps og OpenAPI-tjenester til integrationer på cloudsiden. Tilsammen understøtter disse lag enhedsforbindelse, beskeder, filoverførsel, kamera- og medieoptagelse, live-video, stemmefunktioner, AI-tjenester, genkendelse, enhedsstatus og virksomhedsarbejdsgange.

For et udviklingsteam er den praktiske vej velkendt: Byg native Android-projekter i Android Studio, tilføj Rokids Maven-repository og SDK-afhængigheder, kør Rokids officielle demo med to projekter, etablér Bluetooth til opdagelse og styring, skift til Wi-Fi P2P til store filer og lyd/video, og forbind derefter arbejdsgangen med virksomhedens backend. En selvstændig brilleapp er også mulig, når brugsscenariet ikke kræver en ledsagertelefon.

Ud over selve SDK'et kommer den primære værdi af at erstatte en generisk wearable-oplevelse med en kontrolleret arbejdsgang. En tekniker kan modtage en arbejdsordre, se den næste instruktion i displayet, bekræfte et trin med stemmen eller via hardwareinput, optage visuel dokumentation og sende resultatet til et CMMS, ERP eller en skræddersyet platform. Det gør brillerne relevante til inspektioner, field service, guidet arbejde, logistik, dokumentation og andre håndfri processer. De vigtigste forbehold er, at det native SDK kun understøtter Android, versions- og OTA-kompatibilitet, krav om API-nøgle til udvalgte onlinetjenester og et kompakt 480 x 640-display, der kræver bevidst UI-design.

Hvad Rokid stiller til rådighed for udviklere

Rokid opdeler virksomhedsstakken i et SDK med to sider plus en separat OpenAPI-platform. Forstår man denne opdeling, før man skriver kode, undgår man en almindelig fejl: at forsøge at få brillerne til at klare alt, når en telefon eller backend er bedre egnet til netværk, godkendelse, lagring eller integration med forretningssystemer.

Brilleapplikation:

• Kører på: Rokid Glass3
• Typisk ansvar: Viser den bærbare brugerflade og tilgår funktioner på brillesiden såsom kamera/medier, enhedsstatus, beskeder, stemme, AI og genkendelse via Glasses SDK.

Ledsagerapplikation:

• Kører på: Android-telefon
• Typisk ansvar: Finder og forbinder til Glass3, håndterer Bluetooth og Wi-Fi P2P, udveksler beskeder/filer, modtager mediestreams og kan videresende forretningsdata.

Cloud-/forretningslag:

• Kører på: Jeres backend + Rokid OpenAPI, hvor det er relevant
• Typisk ansvar: Gemmer forretningsdata, godkender brugere, forbinder ERP-/CMMS-/CRM-systemer og kan bruge Rokid OpenAPI-moduler såsom besked- eller enheds-API'er, når de er klargjort.

Praktisk vurdering: Til skræddersyet virksomhedssoftware er den nyttige arkitektur som regel »tynd wearable-brugerflade + pålidelige enhedstjenester + forretningslogik på telefon/backend«. Når brilleoplevelsen holdes fokuseret, reduceres UI-kompleksiteten, og projektet bliver lettere at vedligeholde, samtidig med at den håndfri interaktion bevares, hvor det betyder noget.

Udviklingsstakken i overblik

• Målhardware i offentlig virksomhedsdokumentation: Rokid Glass3
• Udviklingsmodel: Native udvikling af Android-applikationer
• Glasses SDK-artefakt: com.rokid.security:glass3.open.sdk
• Phone SDK-artefakt: com.rokid.security:phone.sdk
• Aktuel afhængighed vist i Quick Start: 2.2.0-E for begge SDK'er
• Nyeste synlige changelog-post på researchtidspunktet: V2.2.0-E, dateret 6. august 2026 med anbefalet OTA 1.19.e006-20260806-150201 eller nyere.
• Anbefalede værktøjer: Android Studio 2022+, JDK 17+
• Demomiljø: Android SDK 34, JDK 17, Android-telefon, Rokid Glass3
• Brilledisplayets koordinatsystem: Fast 480 x 640 portræt
• Primære lokale transportkanaler: Klassisk Bluetooth og Wi-Fi P2P
• Cloudgodkendelse: Enterprise API Key til Rokid OpenAPI og udvalgte onlinetjenester
• Understøttet telefonplatform: Android; den offentlige FAQ oplyser, at iOS og native HarmonyOS ikke understøttes af Glass3 SDK

Hvad kan man bygge med Rokid AI Glasses Enterprise?

Det offentlige SDK er bredt nok til at understøtte mere end en enkelt demoapplikation. Hvilket produkt du præcis bygger, afhænger af, hvilke funktioner du kombinerer, og hvor meget logik du holder på selve brillerne.

Guidet field service: Vis én instruktion ad gangen, bekræft udførelse, tag fotos eller video, og send struktureret dokumentation tilbage til et arbejdsordresystem.

Inspektion og compliance: Præsenter tjeklister, brug kameraoptagelse eller genkendelse, vedhæft tidsstemplet dokumentation, og eskalér afvigelser.

Lager- og logistikarbejdsgange: Vis pluk- eller opgaveinformation, udveksl lette kommandoer via Bluetooth, og brug specialiserede scanningsintegrationer, hvor det er nødvendigt.

Visuel fjernassistance: Modtag en live-videostream på ledsagersiden, eller integrer en dedikeret løsning til fjernsamarbejde. Rokid fjernede RTC-opkald fra kerne-Phone SDK'et i version 2.1.7-E, så realtidssamarbejde bør arkitekteres mod Android og Web: Rokids Remote Collaboration SDK eller jeres egen godkendte transport i stedet for at antage, at det er indbygget i basis-SDK'et.

Virksomheds-AI-assistent: Kombiner taleinput, TTS, AI-chat eller virksomhedens egne AI-tjenester med en arbejdsgangsspecifik brugerflade i stedet for at udsætte brugerne for en generisk chatbot.

Optagelse af dokumentation: Udløs billeder, video eller lyd, overfør større mediefiler via P2P, og synkroniser resultaterne med en backend.

Dedikeret wearable til ét formål: Start virksomhedens applikation automatisk efter genstart, og knyt understøttede hardwarehændelser til handlinger i arbejdsgangen – forudsat validering på målfirmwaren.

Trin for trin: sådan udvikler du skræddersyet software til Rokid AI Glasses Enterprise

Trin 1: Definér arbejdsgangen, før du vælger arkitekturen

Start med den operationelle proces, ikke listen over SDK'er. Skriv præcist ned, hvad medarbejderen skal se, sige, optage og bekræfte. Beslut derefter, hvilken enhed der skal have ansvaret for hver opgave. En velafgrænset wearable-applikation viser som regel kortfattet information og registrerer input, mens telefonen eller backend håndterer den tungere forretningslogik.

Selvstændig brilleapp:

• Passer bedst til: Enkel lokal arbejdsgang, optagelse på enheden, drift offline eller med begrænset forbindelse
• Fordele: Færre komponenter, direkte wearable-oplevelse
• Afvejning: Du skal håndtere mere lagrings-/netværkslogik på brillerne; nogle onlinefunktioner kræver stadig legitimationsoplysninger eller forbindelse

Briller + Android-telefon:

• Passer bedst til: De fleste virksomhedspiloter, live-medier, filoverførsel, fjernstyring, ledsager til forretningsapp
• Fordele: Den bedst dokumenterede forbindelsesvej; telefonen kan håndtere godkendelse, netværk og brugerflade, der ikke hører hjemme i linsen
• Afvejning: Kræver en Android-telefon og robust genforbindelseslogik

Briller + telefon + backend:

• Passer bedst til: ERP-/CMMS-/CRM-integration, revisionsspor, centralt styrede arbejdsordrer, AI-tjenester
• Fordele: Bedst egnet til skalerbare forretningsarbejdsgange og datastyring
• Afvejning: Kræver mere integration, sikkerhed og backend-udvikling

Anbefaling: Til et første B2B-proof of concept bør I bruge modellen briller + Android-telefon + backend, medmindre brugsscenariet tydeligt har gavn af en selvstændig wearable. Den ligger tæt op ad Rokids dokumenterede flow med to enheder og giver udviklingsteamet mulighed for at flytte netværk, legitimationsoplysninger og datalagring væk fra brillerne.

Trin 2: Skaf den rigtige hardware og adgang

Før du installerer Android Studio, skal du sikre dig, at hardwaren faktisk kører på virksomhedssoftwaren. Ifølge Rokids FAQ indeholder enterprise-/arbejdsbuilds normalt et »e« i systemversionen. SDK-dokumentationen skelner også mellem enterprise- og forbrugersystemer, så identifikation af firmwaren er en del af projektopsætningen – ikke noget, man tænker på bagefter.

Rokid AI Glasses Enterprise (Rokid Glasses-hardwaren) med enterprise-systembuild/-firmware (systemversion, der ender på »e«).

Glass3-datadebugkablet. Rokid advarer udtrykkeligt om, at det almindelige ladekabel kan forsyne brillerne med strøm, men ikke kan bruges af Android Studio til debugging.

En Android-telefon, hvis du bruger Phone SDK.

En udviklings-pc med Android Studio og JDK 17.

Virksomhedskonto og API Key, hvis projektet skal bruge Rokid OpenAPI eller onlinefunktioner, der kræver godkendelse.

Adgang til præcis den OTA-version, I planlægger at udrulle på tværs af pilotflåden.

Spring ikke kabeltjekket over: Rokid angiver datadebugkablet som påkrævet, fordi det gør det muligt for Android Studio at genkende brillerne, installere APK'er og se logs. Hvis brillerne lader, men ikke vises som en enhed, så tjek kablet, før du begynder at fejlsøge Gradle, ADB eller SDK'et.

Trin 3: Forbered Android-udviklingsmiljøet

Rokids Quick Start anbefaler Android Studio 2022 eller nyere og JDK 17 eller nyere og oplyser, at Glass3 SDK understøtter Android 8.0 eller nyere. Den officielle demoguide bruger i øjeblikket Android SDK 34. Rokids FAQ anbefaler separat Android 7.0 / API 24 eller nyere og siger, at man skal bekræfte Gradle-konfigurationen i den aktuelle SDK-pakke og demo. I et rigtigt projekt bør demoens Gradle-filer betragtes som den autoritative kilde for netop den udgivelse, I integrerer.

1. Installer Android Studio 2022 eller nyere.

1. Installer og vælg JDK 17 eller nyere til Gradle.

1. Installer den Android SDK-version, som den aktuelle Rokid-demo kræver. Den nuværende demoguide angiver SDK 34.

1. Aktivér almindelig Android-debugging på udviklingstelefonen.

1. Tilslut Glass3 med datadebugkablet, og bekræft, at Android Studio ser et mål svarende til »Rokid RG-glasses«.

1. Installer Rokids værktøj til skærmprojektion/-spejling, hvis du vil se wearable-brugerfladen fra pc'en. Rokid anbefaler kraftigt projektion under udviklingen.

Trin 4: Kør Rokids officielle demo, før du laver din egen applikation

Dette er det vigtigste praktiske trin i hele processen. Den officielle demo bekræfter udviklingsmiljøet, SDK-binærfilerne, tilladelserne, hardwareforbindelserne og versionskombinationen, før din egen kode bliver endnu en variabel.

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

# Glasses demo
cd glassdemo
./gradlew assembleDebug

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

Repository'et indeholder to separate Android-projekter: et til brillerne og et til Android-telefonen. Rokid anbefaler at køre demoen på telefonsiden først og derefter demoen på brillesiden. Når begge er installeret, skal du scanne efter Glass3 fra telefondemoen og oprette forbindelsen.

1. SDK-initialisering. Bestået, når: Begge projekter starter og rapporterer en gyldig SDK-tilstand.
2. Bluetooth. Bestået, når: Telefonen finder og forbinder til Glass3.
3. Beskeder. Bestået, når: Tekst- eller kontrolbeskeder kan sendes mellem telefon og briller.
4. Overførsel af små filer. Bestået, når: En lille fil kan udveksles uden fejl.
5. Wi-Fi P2P. Bestået, når: En P2P-kanal kan etableres til operationer med høj båndbredde.
6. Medier. Bestået, når: Foto, video eller live-preview kan udløses og modtages.

Hvorfor det betyder noget kommercielt: Et proof of concept for en kunde bliver langt lettere at afgrænse, når enhedens basisfunktioner er valideret først. Så kan projekttiden bruges på selve arbejdsgangen, integrationen og brugeroplevelsen i stedet for på at diagnosticere en uverificeret SDK-opsætning.

Trin 5: Opret dine egne projekter, og tilføj Rokids Maven-repository

Når demoen virker, kan du oprette eller åbne dine egne Android-projekter. Rokid udgiver SDK-artefakterne via sit Maven-repository. Tilføj repository'et sammen med Google og Maven Central, og tilføj derefter brilleafhængigheden til wearable-appen og telefonafhængigheden til ledsagerappen.

// 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 aktuelle Quick Start viser version 2.2.0-E med en anbefalet OTA på 1.19.e006-20260806-150201 eller nyere. Virksomhedsteams bør låse og teste en kendt SDK + OTA-kombination i stedet for automatisk at opdatere komponenterne hver for sig.

Regel for versionsstyring: Før en pilot eller produktionsudgivelse skal du registrere brillernes OTA-build, Glasses SDK-version, Phone SDK-version, demo-commit og eventuelle specialiserede SDK-versioner i én kompatibilitetsmatrix. Kør de grundlæggende forbindelses- og medietest igen, hver gang en af disse komponenter ændres.

Trin 6: Erklær kun de Android-tilladelser, din arbejdsgang har brug for

Rokids Quick Start angiver almindelige tilladelser til netværksadgang, Wi-Fi, kamera, mikrofon, lagring, Bluetooth og enheder i nærheden. På moderne Android-versioner er det ikke nok at erklære en tilladelse i manifestet, når det gælder farlige tilladelser. Dine telefon- og brilleapps skal anmode om de nødvendige tilladelser under kørsel og håndtere afslag på en ordentlig måde.

• Bluetooth-scanning/-forbindelse: Enhedsopdagelse, parring, små beskeder og styring
• Wi-Fi-enheder i nærheden / Wi-Fi Direct: P2P-forbindelse til filer, billeder, video og realtidsstreams
• Kamera: Foto-/videooptagelse og flows til visuel genkendelse
• Mikrofon: Lydoptagelse, ASR og stemmeinteraktion
• Netværk/internet: Backend-API'er, Rokids onlinetjenester, cloudsynkronisering
• Lagring: Håndtering af medier og overførte filer, afhængigt af adfærden i den pågældende Android-/SDK-version

Råd til produktion: Kopiér ikke hele demoens manifest i blinde. Minimering af tilladelser gør sikkerhedsgennemgangen lettere og mindsker risikoen for, at brugerne afviser en tilladelse, som arbejdsgangen faktisk ikke har brug for.

Trin 7: Initialiser Glasses SDK, og registrér din apps identitet

Brilleapplikationen binder sig til Rokids sikkerhedstjeneste og registrerer derefter et klient-ID. Den vigtige arkitekturregel er, at ledsagerappen på telefonen kender det samme klient-ID, når de to sider udveksler applikationsspecifikke beskeder.

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

Efter initialiseringen tilgås funktionerne på brillesiden via de tjenesteindgange, som GlassSdk stiller til rådighed. De offentlige API-grupper omfatter fælles-/enhedsfunktioner, klassisk Bluetooth, P2P, beskeder, medier, filhåndtering, stemme/AI, genkendelse og andre tjenester. Initialiser ikke alle funktioner ved opstart. Hent og aktivér kun de tjenester, der kræves til den aktuelle skærm eller det aktuelle trin i arbejdsgangen.

Sundhedstjek: Brug GlassSdk.isReady() som et simpelt diagnostisk signal, før du kalder funktionstjenester. Hvis værdien er false, skal du rette initialiseringen eller tjenestebindingen, før du tester funktioner på højere niveau.

Trin 8: Initialiser Android Phone SDK med matchende klient-ID'er

På telefonsiden initialiserer du Rokids mobilmotor og registrerer de klient-ID'er, som telefonen skal kommunikere med. Rokids Phone SDK er forbindelses- og styringslaget for enhedsopdagelse, Bluetooth/P2P, beskeder, filer, modtagelse af medier, synkronisering af konfiguration og relaterede operationer.

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

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

Hvis udvalgte onlinefunktioner kræver API Key Credentials, indeholder demoen pladsholdere for godkendelsesoplysninger, som skal erstattes af legitimationsoplysninger, der er indhentet via Rokids forretningsproces. Hold cloudhemmeligheder ude af versionsstyringen, og undgå at indlejre langtidsgyldige platform-API-nøgler i en klientapplikation, der distribueres.

Trin 9: Forbind først via Bluetooth, og brug derefter P2P til båndbredde

Rokid dokumenterer to lokale transportmønstre med forskellige opgaver. Klassisk Bluetooth egner sig til opdagelse, forbindelse, kontrolbeskeder og små filer. Wi-Fi P2P er den bedre kanal til billeder, store filer, video og realtidsmedier. At bruge den forkerte transport er en nem måde at skabe en applikation på, der virker i en demo, men føles upålidelig i felten.

Klassisk Bluetooth:

• Brug det til: Opdagelse, parring, styringskommandoer, kompakte JSON-beskeder, små filer
• Rolle i designet: Kontrolplan med lav båndbredde

Wi-Fi P2P:

• Brug det til: Store filer, billeder, video, lyd-/videostreams, synkronisering med høj kapacitet
• Rolle i designet: Dataplan med høj båndbredde

Direkte Wi-Fi på brillerne:

• Brug det til: Backend-adgang fra en brilleapplikation, når enheden er forbundet til Wi-Fi
• Rolle i designet: Nyttigt til udvalgte selvstændige flows; design stadig offline- og genforsøgsadfærd

En robust virksomhedsapp bør behandle forbindelser som tilstandsmaskiner frem for engangshændelser. Håndter eksplicit tab af Bluetooth, nedlukning af P2P, telefon i dvale, Wi-Fi-ændringer og genstart af brillerne. Brugeren bør få en enkel status som »genopretter forbindelse« eller »synkronisering afventer« – ikke en Android-undtagelse eller en lydløs fejl.

Trin 10: Definér en lille applikationsprotokol til forretningsbeskeder

Rokid leverer transport- og beskedtjenesterne, men din applikation har stadig brug for en kontrakt for, hvad en forretningsbesked betyder. Hold kontrakten kompakt, versioneret og uafhængig af brugerfladen. JSON er et praktisk valg i tidlige projekter, fordi det er let at inspicere, selvom det præcise payload-format er et spørgsmål om dit applikationsdesign og ikke et krav fra Rokid.

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

Når trinnet er udført, kan brillerne returnere en lille statusbesked, der henviser til arbejdsordre-ID'et og trinnummeret. Selve mediefilen bør sendes via P2P-fil-/mediekanalen i stedet for at blive indlejret i kontrolbeskeden. Denne adskillelse holder kommandokanalen responsiv og gør genforsøg enklere.

Trin 11: Design brillernes brugerflade til 480 x 640 – ikke som en telefonapp

Glass3-displayet bruger et fast koordinatsystem på 480 x 640 i portrætformat. Rokids FAQ anbefaler at placere det primære indhold i det centrale område på 480 x 400, bruge de øverste 160 pixels og nederste 80 pixels til sekundær information og flytte vigtigt indhold nedad, fordi de øverste ca. 40 pixels kan vise optisk refleksion. Operativsystemet understøtter ikke almindelig skærmrotation, så brede layouts skal designes inden for portrætlærredet.

Vis én opgave, instruktion eller beslutning ad gangen. Lange dashboards passer dårligt til linsen.

Brug en sort baggrund, hvor det er muligt. Rokid anbefaler det for at mindske oplevet flimren ved opstart eller overgange.

Placer ikke kritisk tekst eller knapper i refleksionsområdet i de øverste ~40 px.

Gør tilstandsændringer tydelige uden at være afhængig af kompleks farvekodning. Rokid anbefaler grøn som den primære visuelle stil.

Vis tydeligt forbindelsestilstanden og en klar »synkroniseret/afventer«-tilstand for forretningsdata.

Hold interaktionsmålene så enkle, at de kan betjenes med understøttet hardwareinput eller stemme uden at kræve præcis touch-agtig navigation.

Forretningsmæssig betydning: Displayet er lille, men det kan være en fordel i procedurebaseret arbejde. Det tilskynder softwareteams til at fjerne ikke-væsentlig information og kun vise den næste handling, medarbejderen har brug for.

Trin 12: Tilføj funktioner til kamera, foto, video og live-preview

Glasses SDK stiller mediefunktioner til rådighed for foto, video, lyd og preview. Phone SDK kan modtage mediestreams fra brillerne. Rokids FAQ angiver en standardvideostream på 1080P ved ca. 15 til 19 billeder pr. sekund med omkring 300 ms afspilningsforsinkelse på telefonen og bemærker, at outputtet kan være H.264 eller afkodet NV21 afhængigt af API'et og demovejen. Betragt disse tal som aktuel implementeringsvejledning snarere end en garanteret SLA.

Brug stillbilleder til inspektionsdokumentation, bevis for udførelse og senere AI-behandling.

Brug H.264, når telefonen eller backend primært skal videresende eller gemme streamen. Rokids changelog for 2.1.8-E tilføjede styring af automatisk H.264-til-NV21-afkodning, så unødvendig afkodning kan undgås.

Brug NV21, når en computer vision-pipeline på telefonsiden har brug for afkodede frames.

Brug Wi-Fi P2P til live-preview og medieoverførsel frem for klassisk Bluetooth.

Hvis du har brug for kamera plus overlay på skærmen i det optagede output, så gennemgå Rokids aktuelle API'er til AR Mix/AR-optagelse, og afstem dem med den installerede SDK-version.

En praktisk detalje fra Rokids FAQ er vigtig for dokumentationsarbejdsgange: Efter en vellykket P2P-upload kan billederne på brillerne blive ryddet op af systemet. Betragt den modtagne kopi på telefonen eller i backend som den forretningsmæssigt autoritative kilde, og bekræft, at uploaden er gennemført, før arbejdsordren går videre.

Trin 13: Tilføj stemme, TTS og AI med omtanke

Stemme kan være værdifuld, når medarbejderne ikke kan bruge hænderne, men den bør knyttes til eksplicitte handlinger i arbejdsgangen. SDK-dokumentationen på brillesiden omfatter ASR, TTS, håndtering af offlinekommandoer og AI-chat. I øjeblikket siger FAQ'en, at offline-TTS kræver SDK 2.2.0 eller nyere, selvom changeloggen angiver offline-TTS-tjenesten fra 2.1.2; test det på jeres låste version. Åben offline-ASR understøttes i øjeblikket ikke som standard. Til offline tale-til-tekst henviser Rokid udviklere til private ASR/TTS-tjenester i stedet for at hævde, at der findes en indbygget offline-ASR-løsning.

Offline kommandoord:

• God anvendelse: Korte faste kommandoer som »næste«, »tilbage«, »optag«
• Note om virksomhedsdesign: God til deterministisk håndfri styring

Online-ASR:

• God anvendelse: Fri tale-til-tekst
• Note om virksomhedsdesign: Kræver opsætning af netværk/tjeneste og bør have en fallback-adfærd

TTS/offline-TTS:

• God anvendelse: Oplæsning af prompter, advarsler eller korte bekræftelser
• Note om virksomhedsdesign: Nyttig, når displayet skal holdes minimalt

AI-chat/privat AI:

• God anvendelse: Kontekstuel assistance eller fortolkning
• Note om virksomhedsdesign: Hold modellen bag arbejdsgangen. Validér datahåndtering, latens og svargrænser.

Trin 14: Forbind arbejdsgangen sikkert med jeres backend

Der er to separate backend-spørgsmål: hvordan jeres egen applikation når jeres forretningssystemer, og om I bruger Rokid OpenAPI. Jeres applikation kan sende data via den parrede telefon, eller en brilleapplikation kan tilgå internettet direkte, når Glass3 er forbundet til Wi-Fi. For virksomhedssystemer er standard-backend-API'er normalt det reneste integrationspunkt, fordi legitimationsoplysninger, revisionslogs, datavalidering og forretningsregler forbliver på serversiden.

Rokid OpenAPI er et separat platformslag. Den officielle dokumentation kræver en aktiveret virksomhedskonto og API Key. Forespørgsler godkendes med et Bearer-token, oprettede nøgler udløber, og standardgyldigheden er én måned, medmindre andet er konfigureret. Rokid advarer udtrykkeligt mod at eksponere API-nøgler i offentlige repositories eller klienter.

Sikkerhedsregel: Brug en proxy på serversiden til Rokids platformslegitimationsoplysninger, når arkitekturen tillader det. En mobil- eller brille-APK kan inspiceres. Gå ikke ud fra, at en API-nøgle bliver hemmelig, blot fordi den er gemt i Kotlin- eller native kode.

Rokids nuværende OpenAPI-moduler omfatter blandt andet besked- og enheds-API'er samt andre virksomhedsfunktioner (bemærk, at disse besked- og enheds-API'er kun kan tilgås, hvis enhederne er registreret i Rokids Lingmou-konsol). Enheds-API'et kan for eksempel forespørge registrerede Glass-enheder, mens besked-API'et kan sende en forretningsbesked til en målenhed. Brug kun disse tjenester, når de løser et reelt behov i udrulningen. En skræddersyet virksomhedsbackend er fortsat det rette sted til ERP, CMMS, CRM, identitet og orkestrering af arbejdsgange.

Trin 15: Konfigurer virksomhedsadfærd som autostart og håndtering af taster

En wearable bliver mere nyttig i driften, når brugeren ikke skal navigere i en launcher i forbrugerstil hver morgen. Rokid dokumenterer en autostartmekanisme, der kan starte en konfigureret applikation efter opstart på understøttede enterprise-systemer. Rokid dokumenterer også tilpasning af hardwarehændelser og, i changeloggen for 2.1.9-E, API'er til lytning efter og opfangning af hændelser.

Brug autostart til dedikerede inspektions-, sikkerheds- eller industrielle arbejdsgange, hvor brillerne skal åbne direkte i forretningsapplikationen.

Udskyd SDK-afhængigt arbejde kortvarigt efter opstart, og bekræft, at tjenesterne er klar, før arbejdsgangen startes.

Knyt understøttede tastehændelser til et lille antal meningsfulde handlinger såsom bekræft, optag eller annuller.

Validér alle autostart- og opfangningsfunktioner på den aktuelle enterprise-firmware, fordi noget adfærd på systemniveau afhænger af versionen.

Bevar altid en support-/gendannelsesvej. En låst arbejdsgang, som en administrator ikke kan forlade, er en driftsrisiko.

Trin 16: Byg offline-, genforsøgs- og gendannelsesadfærd

En demo forudsætter ofte perfekt Bluetooth, Wi-Fi og cloudadgang. Det kan en udrulning i felten ikke. Gem den minimale arbejdsgangstilstand, der er nødvendig for at overleve en afbrudt telefonforbindelse, en P2P-fejl eller et midlertidigt netværksudfald. Hver forretningshandling bør så vidt muligt være idempotent, så et genforsøg ikke skaber dublerede arbejdsordrehændelser eller medieposter.

Cache det aktuelle arbejdsordre-ID, trin-ID og den sidst bekræftede handling.

Sæt ikke-sendte resultater i kø med en synlig »afventer synkronisering«-tilstand.

Brug unikke operations-ID'er, så backend sikkert kan afvise dubletter.

Genopret Bluetooth-forbindelsen først, og genopbyg kun P2P, hvis der er brug for overførsel med høj båndbredde.

Markér aldrig et medieafhængigt trin som udført, før modtagelsen af målkopien er bekræftet.

Sørg for en sikker fallback for brugeren, når online-ASR eller AI ikke er tilgængelig. Faste offlinekommandoer kan stadig dække den grundlæggende navigation.

Trin 17: Test på rigtig hardware med en testmatrix til virksomhedsbrug

Emulatorer er ikke nok til et brilleprojekt, fordi optik, termisk adfærd, Bluetooth, P2P, kamera, mikrofon og bærekomfort alle påvirker softwareoplevelsen. Test hele systemet på præcis den enterprise-OTA, der er planlagt til piloten.

• Opstart og autostart: Koldstart, app-start, SDK-parathed, gendannelse, hvis tjenestebindingen er langsom
• Bluetooth: Første parring, genforbindelse, telefon i dvale, gendannelse efter at have været uden for rækkevidde
• P2P: Gentagen tilslutning/afbrydelse, stor fil, livestream, Wi-Fi-ændringer
• Tilladelser: Ny installation, afvist tilladelse, senere tildeling, forskelle mellem Android-versioner
• Medier: Foto-/videokvalitet, kvittering for fil, genforsøg ved mislykket upload, oprydning i lagerplads
• Stemme: Støjende miljø, intet netværk, ikke-understøttet frase, afbrydelse af TTS
• UI/optik: Læsbarhed, refleksionsområdet øverst, lang tekst, synlighed af status, brugertræthed
• Ydeevne: Lang session, CPU-temperatur, ledig hukommelse, processens overlevelse
• Backend: Langsomt svar, dubleret forespørgsel, udløbet token, server utilgængelig
• Sikkerhed: Håndtering af legitimationsoplysninger, maskering af følsomme data i logs, tab af enhed, tilbagekaldelse af konto

Rokids FAQ foreslår specifikt at overvåge hukommelse og CPU-temperatur under fejlfinding af ydeevne og advarer om, at meget lidt ledig hukommelse gør det mere sandsynligt, at baggrundsprocesser bliver afsluttet. Det er endnu en grund til at holde brilleappen fokuseret og flytte ikke-væsentlige tjenester andre steder hen.

Trin 18: Pak piloten, og kontrollér udrulningens baseline

Under udviklingen kan APK'er installeres via Android Studio med Glass3-datadebugkablet. En produktionsudrulning kræver en strengere udgivelsesproces. Rokid dokumenterer ingen politikstyring i MDM-stil (såsom kiosktilstand, fjernsletning eller app-politikker). I stedet dokumenteres enhedsregistrering og statussporing via Lingmou-konsollen og OpenAPI, mens version 2.2.0-E gør det muligt at installere APK'er via en QR-scanningsapp. Koordinér udrulningsmekanismen, klargøringsrettigheder, enterprise-firmware og opdateringspolitik med Rokid eller distributøren, før I lægger jer fast på en arkitektur for udrulningen.

1. Frys de testede SDK- og OTA-versioner til piloten.

1. Opret signerede release-APK'er til brille- og telefonapplikationerne.

1. Dokumentér klient-ID'er, pakkenavne og konfigurationen af backend-miljøet.

1. Klargør API-nøgler og backend-hemmeligheder via sikker infrastruktur, ikke via kildekoden.

1. Fastlæg, hvem der må opdatere brillerne, telefonappen og backend, og i hvilken rækkefølge.

1. Kør regressionstest efter hver OTA- eller SDK-ændring, før flåden opdateres.

1. Etablér en supportvej for logs, enhedsidentitet, diagnosticering af forbindelser og rollback.

Eksempel på arkitektur: en skræddersyet inspektionsapp til field service

Følgende er et praktisk designeksempel, der er sammensat ud fra Rokids dokumenterede funktioner. Det er ikke en færdig Rokid-arbejdsgang. Det viser, hvordan udviklerstakken kan gøre brillerne til et dedikeret forretningsendepunkt.

1. Start. Teknisk handling: Brilleappen starter automatisk og kontrollerer, om SDK'et er klar. Forretningsværdi: Medarbejderen starter direkte i virksomhedens arbejdsgang.
2. Tildel opgave. Teknisk handling: Telefon/backend sender et resumé af arbejdsordren som en kompakt besked. Forretningsværdi: Der kræves intet manuelt opslag på en telefon.
3. Vejled. Teknisk handling: Brillerne viser én instruktion i det centrale displayområde. Forretningsværdi: Hænderne forbliver frie til opgaven.
4. Bekræft. Teknisk handling: Medarbejderen siger en fast kommando eller bruger en understøttet hardwarehændelse. Forretningsværdi: Hurtig, deterministisk interaktion.
5. Optag dokumentation. Teknisk handling: Brillerne tager et foto eller et kort klip. Forretningsværdi: Visuelt bevis knyttes til det rigtige trin.
6. Overfør. Teknisk handling: Medier sendes via P2P; en lille statusbesked bekræfter uploaden. Forretningsværdi: Store datamængder holdes væk fra kontrolkanalen med lav båndbredde.
7. Synkroniser. Teknisk handling: Telefon eller backend sender resultatet til CMMS-/ERP-API'et. Forretningsværdi: De eksisterende forretningssystemer forbliver det autoritative system.
8. Undtagelse. Teknisk handling: Om nødvendigt modtager telefonen en livestream, eller appen aktiverer den godkendte løsning til fjernassistance. Forretningsværdi: En supervisor kan se det, medarbejderen ser.
9. Afslut. Teknisk handling: Backend bekræfter afslutningen og returnerer den næste opgave. Forretningsværdi: Brugeren får en klar sluttilstand, og revisionssporet er komplet.

Hvorfor skræddersyet software ændrer business casen for Rokid AI Glasses Enterprise

Den primære værdi for virksomheden kommer af at forme enheden omkring en eksisterende operationel proces eller at redesigne processen til håndfrit arbejde.

Specialbygget brugerflade: Fjern forbrugermenuer, og vis kun den information, der er nødvendig på det aktuelle trin i opgaven.

Integration med forretningssystemer: Forbind optaget dokumentation og medarbejderhandlinger med eksisterende ERP-, CMMS- eller CRM-systemer eller skræddersyede platforme.

Håndfri dataindsamling: Brug kamera, stemme og wearable-input uden gang på gang at skulle vende tilbage til en telefon eller tablet.

Kontrolleret forbindelse: Brug Bluetooth til kommandoer og P2P til data med høj båndbredde i stedet for at tvinge alle funktioner gennem én kanal.

Skræddersyede AI-grænser: Brug AI, hvor det tilfører værdi, mens regler for arbejdsgange, tilladelser og datastyring forbliver under virksomhedens kontrol.

Dedikeret enhedsadfærd: Autostart og hændelseshåndtering kan mindske friktionen ved udrulninger med ét formål, når det understøttes af enterprise-firmwaren.

Udvidelig arkitektur: Start med et lokalt proof of concept, og tilføj derefter backend-integration, platform-API'er, fjernsamarbejde eller specialiserede SDK'er, efterhånden som arbejdsgangen modnes.

Købsargumentet: For organisationer, der har brug for en standardiseret, fast app-oplevelse, kan skræddersyet udvikling være unødvendig. For organisationer, der ønsker, at AI-briller skal blive en del af en kontrolleret operationel arbejdsgang, er det dokumenterede Glass3 SDK grunden til, at hardwaren bliver mere interessant. Virksomheden køber et tilpasningsdygtigt endepunkt – ikke kun et bærbart display eller kamera.

Begrænsninger og tekniske risici, der skal planlægges for

• Android-fokuseret SDK: Det offentlige Glass3 SDK er rettet mod native Android. Ifølge Rokids FAQ understøttes iOS og native HarmonyOS ikke. En uni-app-integration er kun mulig, hvis man selv bygger en bro til det native Android-SDK.
• Kompakt display: Portrætlærredet på 480 x 640 egner sig til korte prompter, ikke til tætpakkede virksomhedsdashboards. Godt arbejdsgangsdesign er et must.
• Uoverensstemmelse mellem SDK og changelog: Validér SDK-artefakter, demo og OTA samlet, og tag højde for versionsforskelle mellem de kinesiske og engelske changelogs.
• Afhængighed af onlinetjenester: Udvalgte ASR-, AI- og OpenAPI-funktioner kræver netværksadgang, virksomhedslegitimationsoplysninger eller klargøring af tjenester.
• Ingen åben offline-ASR i den nuværende FAQ: Offline-TTS og faste offlinekommandoer kan understøtte robust interaktion, men fri offline tale-til-tekst er i øjeblikket ikke dokumenteret som indbygget.
• Kompleksitet i transport: Bluetooth og P2P løser forskellige problemer. Genforbindelse, tilladelser og tilstandssynkronisering kræver udvikling i produktionskvalitet.
• RTC fjernet fra kernen: Rokid fjernede RTC-opkald fra basis-Phone SDK'et i 2.1.7-E. Fjernsamarbejde bør bruge Rokids Remote Collaboration SDK eller en separat udviklet løsning.
• Udrulningsdetaljer kræver validering: Den offentlige SDK-dokumentation er stærk på udvikling, men flådestyring i produktion og klargøring via Lingmou-konsollen eller QR-scanningsappen bør bekræftes for kundens miljø, før der skaleres op.

Fordele og ulemper ved skræddersyet virksomhedsudvikling

Fordele:

• Native Android-udviklingsmodel
• Offentlige Maven-artefakter
• Officiel demo til briller + telefon
• Bluetooth og P2P
• Beskeder/filer/medier
• Kamera og live-preview
• Stemme-/AI-/genkendelsestjenester
• Direkte Wi-Fi muligt
• Enterprise OpenAPI
• Muligheder for autostart og tilpasning af hændelser.

Ulemper:

• Native SDK-understøttelse kun til Android
• Kompakt, fast display
• Koordinering af versioner/OTA
• Udvalgte onlinefunktioner kræver virksomhedsadgang
• Begrænsning i offline-ASR
• Detaljer om klargøring/flådestyring i produktion kræver projektspecifik bekræftelse.

Endelig vurdering

Rokid AI Glasses Enterprise er værd at overveje, når virksomhedens mål er at bygge en dedikeret håndfri arbejdsgang frem for at udrulle en generisk forbrugerapplikation. Den nuværende Glass3-enterprise-stak giver Android-udviklere en dokumenteret vej til at bygge på brillerne, parre dem med en Android-telefon, sende kontroldata via Bluetooth, overføre medier via Wi-Fi P2P og forbinde arbejdsgangen med backend-systemer eller udvalgte Rokid OpenAPI-tjenester.

De stærkeste brugsscenarier er guidede inspektioner, field service, optagelse af dokumentation, procedurebaseret arbejde og andre opgaver, hvor medarbejderen har gavn af at se én instruktion ad gangen og samtidig have begge hænder fri. Den største begrænsning er ikke mangel på API'er. Det er den tekniske disciplin, der kræves omkring det lille display, forbindelsestilstand, tilladelser, SDK/OTA-kompatibilitet og afhængighed af onlinetjenester.

For en erhvervskøber er det centrale evalueringsspørgsmål: »Kan vi tilpasse vores arbejdsgang til den dokumenterede udviklerstak, og kan vi supportere applikationen gennem hele dens livscyklus?« Hvis svaret er ja, er skræddersyet software vejen til at gøre Rokid Glass3 fra generelle AI-briller til en specialbygget driftsenhed.

For virksomheder, der overvejer Rokid AI Glasses Enterprise til inspektioner, field service, logistik, guidet arbejde eller skræddersyede AI-arbejdsgange, kan VR Expert hjælpe med at vurdere hardwaren, definere et proof of concept og validere udrulningsvejen. Besøg produktsiden for Rokid AI Glasses Enterprise for at se nærmere på enheden, tilgængelighed og købsmuligheder. Ønsker du hjælp til at afgrænse skræddersyet udvikling eller råd om udrulning, så kontakt VR Expert.