Så utvecklar du anpassad programvara för Rokid AI Glasses Enterprise

Sammanfattning

Rokid AI Glasses Enterprise kan utvecklas till en ändamålsenlig affärsenhet i stället för att bara användas med förkonfigurerade applikationer. Rokids nuvarande Sprite Enterprise-dokumentation erbjuder ett Glasses SDK för applikationer som körs direkt på Glass3, ett Phone SDK för kompanjonsappar för Android och OpenAPI-tjänster för integrationer på molnsidan. Tillsammans stöder dessa lager enhetsanslutning, meddelanden, filöverföring, kamera- och mediainspelning, livevideo, röstfunktioner, AI-tjänster, igenkänning, enhetsstatus och företagsarbetsflöden.

För ett utvecklingsteam är den praktiska vägen välbekant: bygg inbyggda Android-projekt i Android Studio, lägg till Rokids Maven-repository och SDK-beroenden, kör Rokids officiella demo med två projekt, upprätta Bluetooth för identifiering och styrning, växla till Wi-Fi P2P för stora filer och ljud/video och koppla sedan arbetsflödet till företagets backend. En fristående glasögonapp är också möjlig när användningsfallet inte kräver en kompanjonstelefon.

Utöver SDK:t kommer det främsta värdet av att ersätta en generisk upplevelse av bärbar teknik med ett kontrollerat arbetsflöde. En tekniker kan ta emot en arbetsorder, se nästa instruktion på skärmen, bekräfta ett steg med rösten eller via hårdvaruinmatning, dokumentera visuella bevis och skicka resultatet till ett CMMS, ERP eller en egen plattform. Det gör glasögonen relevanta för inspektioner, fältservice, guidat arbete, logistik, dokumentation och andra handsfreeprocesser. De viktigaste förbehållen är att det inbyggda SDK-stödet endast gäller Android, kompatibilitet mellan versioner och OTA, krav på API-nyckel för vissa onlinetjänster samt en kompakt skärm på 480 x 640 som kräver genomtänkt UI-design.

Vad Rokid erbjuder utvecklare

Rokid delar upp företagsstacken i ett tvåsidigt SDK plus en separat OpenAPI-plattform. Att förstå denna uppdelning innan man skriver kod förhindrar ett vanligt misstag: att försöka få glasögonen att göra allt när en telefon eller backend är bättre lämpad för nätverk, autentisering, lagring eller integration med affärssystem.

Glasögonapplikation:

• Körs på: Rokid Glass3
• Typiskt ansvar: Renderar det bärbara gränssnittet och får åtkomst till funktioner på glasögonsidan, såsom kamera/media, enhetsstatus, meddelanden, röst, AI och igenkänning, via Glasses SDK.

Kompanjonsapplikation:

• Körs på: Android-telefon
• Typiskt ansvar: Identifierar och ansluter till Glass3, hanterar Bluetooth och Wi-Fi P2P, utbyter meddelanden/filer, tar emot medieströmmar och kan vidarebefordra affärsdata.

Moln-/affärslager:

• Körs på: Din backend + Rokid OpenAPI där det är relevant
• Typiskt ansvar: Lagrar affärsdata, autentiserar användare, ansluter ERP-/CMMS-/CRM-system och kan använda Rokid OpenAPI-moduler som meddelande- eller enhets-API:er när de har tillhandahållits.

Praktisk bedömning: För anpassad företagsprogramvara är den användbara arkitekturen oftast ”tunt bärbart gränssnitt + pålitliga enhetstjänster + affärslogik i telefon/backend”. Att hålla glasögonupplevelsen fokuserad minskar gränssnittets komplexitet och gör projektet lättare att underhålla, samtidigt som handsfreeinteraktionen bevaras där den spelar roll.

Utvecklingsstacken i korthet

• Målhårdvara i offentlig företagsdokumentation: Rokid Glass3
• Utvecklingsmodell: Inbyggd (native) Android-apputveckling
• Artefakt för Glasses SDK: com.rokid.security:glass3.open.sdk
• Artefakt för Phone SDK: com.rokid.security:phone.sdk
• Aktuellt beroende som visas i Quick Start: 2.2.0-E för båda SDK:erna
• Senaste synliga changelog-post vid tidpunkten för researchen: V2.2.0-E, daterad 6 augusti 2026 med rekommenderad OTA 1.19.e006-20260806-150201 eller senare.
• Rekommenderade verktyg: Android Studio 2022+, JDK 17+
• Demomiljö: Android SDK 34, JDK 17, Android-telefon, Rokid Glass3
• Glasögonskärmens koordinatsystem: Fast 480 x 640 i stående format
• Primära lokala överföringsvägar: Klassisk Bluetooth och Wi-Fi P2P
• Molnautentisering: Enterprise API Key för Rokid OpenAPI och vissa onlinetjänster
• Telefonplattform som stöds: Android; enligt den offentliga FAQ:n stöds inte iOS och inbyggt HarmonyOS av Glass3 SDK

Vad kan du bygga med Rokid AI Glasses Enterprise?

Det offentliga SDK:t är tillräckligt omfattande för att stödja mer än en enskild demoapplikation. Exakt vilken produkt du bygger beror på vilka funktioner du kombinerar och hur mycket logik du behåller på den bärbara enheten.

Guidad fältservice: visa en instruktion i taget, bekräfta slutförande, ta foton eller video och skicka strukturerade bevis tillbaka till ett arbetsordersystem.

Inspektion och regelefterlevnad: presentera checklistor, använd kamerainspelning eller igenkänning, bifoga tidsstämplade bevis och eskalera avvikelser.

Arbetsflöden inom lager och logistik: visa plock- eller uppgiftsinformation, utbyt lätta kommandon via Bluetooth och använd specialiserade skanningsintegrationer där det behövs.

Visuell fjärrassistans: ta emot en livevideoström på kompanjonssidan eller integrera en dedikerad väg för fjärrsamarbete. Rokid tog bort RTC-samtal från kärnan i Phone SDK i version 2.1.7-E, så realtidssamarbete bör arkitektureras mot Android och Web: Rokids Remote Collaboration SDK eller er egen godkända överföringslösning, i stället för att man utgår från att det är inbyggt i bas-SDK:t.

Företags-AI-assistent: kombinera talinmatning, TTS, AI-chatt eller företagets egna AI-tjänster med ett arbetsflödesspecifikt gränssnitt i stället för att låta användarna möta en generisk chattbot.

Bevisinsamling och dokumentation: utlös bilder, video eller ljud, överför större mediefiler via P2P och synkronisera resultaten med en backend.

Dedikerad bärbar enhet för ett enda syfte: starta företagsapplikationen automatiskt efter omstart och koppla hårdvaruhändelser som stöds till arbetsflödesåtgärder, förutsatt att detta valideras mot målets firmware.

Steg för steg: så utvecklar du anpassad programvara för Rokid AI Glasses Enterprise

Steg 1: Definiera arbetsflödet innan du väljer arkitektur

Börja med den operativa processen, inte med listan över SDK:er. Skriv ned exakt vad arbetaren måste se, säga, dokumentera och bekräfta. Bestäm sedan vilken enhet som ska ansvara för varje uppgift. En väl avgränsad bärbar applikation visar oftast koncis information och tar emot inmatning, medan telefonen eller backend hanterar tyngre affärslogik.

Fristående glasögonapp:

• Passar bäst för: Enkla lokala arbetsflöden, inspelning på enheten, drift offline eller med begränsad uppkoppling
• Fördelar: Färre komponenter, direkt upplevelse på den bärbara enheten
• Avvägning: Du måste hantera mer lagrings-/nätverkslogik på glasögonen; vissa onlinefunktioner kräver fortfarande inloggningsuppgifter eller uppkoppling

Glasögon + Android-telefon:

• Passar bäst för: De flesta företagspiloter, livemedia, filöverföring, fjärrstyrning, kompanjon till affärsapp
• Fördelar: Den bäst dokumenterade anslutningsvägen; telefonen kan hantera autentisering, nätverk och gränssnitt som inte hör hemma i linsen
• Avvägning: Kräver en Android-telefon och robust logik för återanslutning

Glasögon + telefon + backend:

• Passar bäst för: ERP-/CMMS-/CRM-integration, revisionsspår, centralt hanterade arbetsordrar, AI-tjänster
• Fördelar: Passar bäst för skalbara affärsarbetsflöden och datastyrning
• Avvägning: Kräver mer integrations-, säkerhets- och backendutveckling

Rekommendation: För ett första B2B-konceptbevis (proof of concept) bör ni använda modellen glasögon + Android-telefon + backend, såvida inte användningsfallet tydligt gynnas av en fristående bärbar enhet. Den motsvarar nära Rokids dokumenterade flöde med två enheter och ger utvecklingsteamet utrymme att flytta nätverk, inloggningsuppgifter och datalagring bort från glasögonen.

Steg 2: Skaffa rätt hårdvara och åtkomst

Innan du installerar Android Studio bör du bekräfta att hårdvaran faktiskt kör företagsprogramvaran. Enligt Rokids FAQ innehåller företags-/arbetsversioner vanligtvis ett ”e” i systemversionen. SDK-dokumentationen skiljer också mellan företags- och konsumentsystem, så identifiering av firmware är en del av projektuppsättningen, inte något man tänker på i efterhand.

Rokid AI Glasses Enterprise (hårdvaran Rokid Glasses) med företagsversionen av systemet/firmware (systemversion som slutar på ”e”).

Glass3-datakabeln för felsökning. Rokid varnar uttryckligen för att den vanliga laddkabeln kan driva glasögonen men inte kan användas av Android Studio för felsökning.

En Android-telefon om du använder Phone SDK.

En utvecklingsdator med Android Studio och JDK 17.

Företagskonto och API Key om projektet ska använda Rokid OpenAPI eller onlinefunktioner som kräver autentisering.

Åtkomst till exakt den OTA-version som du planerar att driftsätta i hela pilotflottan.

Hoppa inte över kabelkontrollen: Rokid anger datakabeln för felsökning som ett krav eftersom den gör det möjligt för Android Studio att känna igen glasögonen, installera APK:er och granska loggar. Om glasögonen laddas men inte visas som en enhet bör du kontrollera kabeln innan du felsöker Gradle, ADB eller SDK:t.

Steg 3: Förbered Android-utvecklingsmiljön

Rokids Quick Start rekommenderar Android Studio 2022 eller senare och JDK 17 eller senare, och anger att Glass3 SDK stöder Android 8.0 eller senare. Den officiella demoguiden använder för närvarande Android SDK 34. Rokids FAQ rekommenderar separat Android 7.0 / API 24 eller senare och uppmanar till att bekräfta Gradle-konfigurationen i det aktuella SDK-paketet och demot. I ett verkligt projekt bör demots Gradle-filer betraktas som sanningskällan för exakt den version du integrerar.

1. Installera Android Studio 2022 eller nyare.

1. Installera och välj JDK 17 eller nyare för Gradle.

1. Installera den Android SDK-version som krävs av det aktuella Rokid-demot. Den nuvarande demoguiden anger SDK 34.

1. Aktivera vanlig Android-felsökning på utvecklingstelefonen.

1. Anslut Glass3 med datakabeln för felsökning och bekräfta att Android Studio ser ett mål liknande ”Rokid RG-glasses”.

1. Installera Rokids verktyg för skärmprojicering/spegling om du vill granska det bärbara gränssnittet från datorn. Rokid rekommenderar starkt projicering under utvecklingen.

Steg 4: Kör Rokids officiella demo innan du skapar din egen applikation

Detta är det viktigaste praktiska steget i hela processen. Det officiella demot verifierar utvecklingsmiljön, SDK-binärfilerna, behörigheterna, hårdvarulänkarna och versionskombinationen innan din egen kod blir ytterligare en variabel.

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

# Glasses demo
cd glassdemo
./gradlew assembleDebug

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

Repositoryt innehåller två separata Android-projekt: ett för glasögonen och ett för Android-telefonen. Rokid rekommenderar att man kör demot på telefonsidan först och sedan demot på glasögonsidan. När båda är installerade söker du efter Glass3 från telefondemot och upprättar anslutningen.

1. SDK-initiering. Godkänt när: Båda projekten startar och rapporterar ett giltigt SDK-tillstånd.
2. Bluetooth. Godkänt när: Telefonen hittar och ansluter till Glass3.
3. Meddelanden. Godkänt när: Text- eller styrmeddelanden kan skickas mellan telefon och glasögon.
4. Överföring av små filer. Godkänt när: En liten fil kan utbytas utan fel.
5. Wi-Fi P2P. Godkänt när: En P2P-kanal kan upprättas för operationer med hög bandbredd.
6. Media. Godkänt när: Foto, video eller liveförhandsvisning kan utlösas och tas emot.

Varför detta spelar roll kommersiellt: Ett konceptbevis för en kund blir mycket enklare att avgränsa när enhetens grundfunktioner valideras först. Då kan projekttiden läggas på det faktiska arbetsflödet, integrationen och användarupplevelsen i stället för på att diagnostisera en overifierad SDK-uppsättning.

Steg 5: Skapa dina egna projekt och lägg till Rokids Maven-repository

När demot fungerar skapar eller öppnar du dina egna Android-projekt. Rokid publicerar SDK-artefakterna via sitt Maven-repository. Lägg till repositoryt tillsammans med Google och Maven Central och lägg sedan till glasögonberoendet i den bärbara appen och telefonberoendet i kompanjonsappen.

// 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 nuvarande Quick Start visar version 2.2.0-E, med en rekommenderad OTA på 1.19.e006-20260806-150201 eller senare. Företagsteam bör låsa och testa en känd kombination av SDK + OTA i stället för att automatiskt uppdatera komponenterna var för sig.

Regel för versionshantering: Före en pilot- eller produktionslansering bör du registrera glasögonens OTA-build, Glasses SDK-version, Phone SDK-version, demo-commit och eventuella versioner av specialiserade SDK:er i en enda kompatibilitetsmatris. Kör om grundtesterna för anslutning och media varje gång någon av dessa komponenter ändras.

Steg 6: Deklarera endast de Android-behörigheter som ditt arbetsflöde behöver

Rokids Quick Start listar vanliga behörigheter för nätverksåtkomst, Wi-Fi, kamera, mikrofon, lagring, Bluetooth och enheter i närheten. På moderna Android-versioner räcker det inte att deklarera en behörighet i manifestet när det gäller farliga behörigheter. Dina telefon- och glasögonappar måste begära de nödvändiga behörigheterna vid körning och hantera nekanden på ett smidigt sätt.

• Bluetooth-sökning/-anslutning: Enhetsidentifiering, parkoppling, små meddelanden och styrning
• Wi-Fi i närheten / Wi-Fi Direct: P2P-anslutning för filer, bilder, video och realtidsströmmar
• Kamera: Foto-/videoinspelning och flöden för visuell igenkänning
• Mikrofon: Ljudinspelning, ASR och röstinteraktion
• Nätverk/internet: Backend-API:er, Rokids onlinetjänster, molnsynkronisering
• Lagring: Hantering av media och överförda filer, beroende på beteendet hos aktuell Android-/SDK-version

Råd för produktion: Kopiera inte hela demots manifest utan eftertanke. Att minimera behörigheterna underlättar säkerhetsgranskningen och minskar risken att användare nekar en behörighet som arbetsflödet egentligen inte behöver.

Steg 7: Initiera Glasses SDK och registrera appens identitet

Glasögonapplikationen binder till Rokids säkerhetstjänst och registrerar sedan en klientidentifierare. Den viktiga arkitekturregeln är att samma klient-ID är känt av kompanjonsappen på telefonen när de två sidorna utbyter applikationsspecifika meddelanden.

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

Efter initieringen nås funktionerna på glasögonsidan via tjänsteingångar som exponeras av GlassSdk. De offentliga API-grupperna omfattar gemensamma funktioner/enhetsfunktioner, klassisk Bluetooth, P2P, meddelanden, media, filhantering, röst/AI, igenkänning och andra tjänster. Initiera inte alla funktioner vid uppstart. Hämta och aktivera bara de tjänster som krävs för den aktuella skärmen eller det aktuella steget i arbetsflödet.

Hälsokontroll: Använd GlassSdk.isReady() som en enkel diagnostisk signal innan du anropar funktionstjänster. Om den returnerar false ska du åtgärda initieringen eller tjänstebindningen innan du testar funktioner på högre nivå.

Steg 8: Initiera Android Phone SDK med matchande klient-ID:n

På telefonsidan initierar du Rokids mobilmotor och registrerar de klient-ID:n som telefonen ska kommunicera med. Rokids Phone SDK är anslutnings- och styrlagret för enhetsidentifiering, Bluetooth/P2P, meddelanden, filer, mottagning av media, synkronisering av konfiguration och relaterade operationer.

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

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

Om vissa onlinefunktioner kräver API Key Credentials innehåller demot platshållare för autentiseringsinformation som måste ersättas med inloggningsuppgifter som erhållits via Rokids affärsprocess. Håll molnhemligheter utanför versionshanteringen och undvik att bädda in långlivade plattforms-API-nycklar i en klientapplikation som distribueras.

Steg 9: Anslut först via Bluetooth och använd sedan P2P för bandbredd

Rokid dokumenterar två lokala överföringsmönster med olika uppgifter. Klassisk Bluetooth lämpar sig för identifiering, anslutning, styrmeddelanden och små filer. Wi-Fi P2P är den bättre kanalen för bilder, stora filer, video och realtidsmedia. Att använda fel överföringsväg är ett enkelt sätt att skapa en applikation som fungerar i ett demo men känns opålitlig i fält.

Klassisk Bluetooth:

• Använd den för: Identifiering, parkoppling, styrkommandon, kompakta JSON-meddelanden, små filer
• Roll i designen: Styrplan med låg bandbredd

Wi-Fi P2P:

• Använd det för: Stora filer, bilder, video, ljud-/videoströmmar, synkronisering med hög genomströmning
• Roll i designen: Dataplan med hög bandbredd

Direkt Wi-Fi i glasögonen:

• Använd det för: Backendåtkomst från en glasögonapplikation när enheten är ansluten till Wi-Fi
• Roll i designen: Användbart för vissa fristående flöden; designa ändå beteende för offline och nya försök

En robust företagsapp bör behandla anslutningar som tillståndsmaskiner snarare än engångshändelser. Hantera uttryckligen Bluetooth-avbrott, nedkoppling av P2P, telefonens viloläge, Wi-Fi-byten och omstart av glasögonen. Användaren bör få en enkel status som ”återansluter” eller ”synkronisering väntar”, inte ett Android-undantag eller ett tyst fel.

Steg 10: Definiera ett litet applikationsprotokoll för affärsmeddelanden

Rokid tillhandahåller överförings- och meddelandetjänsterna, men din applikation behöver ändå ett kontrakt för vad ett affärsmeddelande betyder. Håll kontraktet kompakt, versionshanterat och oberoende av gränssnittet. JSON är ett praktiskt val för tidiga projekt eftersom det är lätt att granska, även om det exakta formatet på nyttolasten är ett designbeslut i din applikation snarare än ett krav från Rokid.

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

När steget är slutfört kan glasögonen returnera ett litet statusmeddelande som refererar till arbetsorderns ID och stegnummer. Själva mediefilen bör skickas via P2P-vägen för filer/media i stället för att bäddas in i styrmeddelandet. Denna uppdelning håller kommandokanalen responsiv och gör nya försök enklare.

Steg 11: Designa glasögonens gränssnitt för 480 x 640, inte som en telefonapp

Glass3-skärmen använder ett fast koordinatsystem på 480 x 640 i stående format. Rokids FAQ rekommenderar att primärt innehåll placeras i det centrala området på 480 x 400, att de översta 160 pixlarna och de nedersta 80 pixlarna används för sekundär information och att viktigt innehåll flyttas nedåt eftersom ungefär de översta 40 pixlarna kan visa optisk reflektion. Operativsystemet erbjuder inte vanlig skärmrotation, så breda layouter måste utformas inom den stående ytan.

Visa en uppgift, instruktion eller ett beslut i taget. Långa instrumentpaneler passar dåligt i linsen.

Använd svart bakgrund där det är möjligt. Rokid rekommenderar det för att minska upplevt flimmer vid uppstart eller övergångar.

Placera inte kritisk text eller knappar i reflektionsområdet längst upp (de översta ~40 px).

Gör tillståndsändringar tydliga utan att förlita dig på komplex färgkodning. Rokid rekommenderar grönt som primär visuell stil.

Visa tydligt anslutningsstatus och en tydlig status ”synkroniserad/väntar” för affärsdata.

Håll interaktionsmålen så enkla att de kan hanteras med hårdvaruinmatning som stöds eller med rösten, utan att kräva exakt navigering i pekskärmsstil.

Affärsmässig innebörd: Skärmen är liten, men det kan vara en fördel vid procedurbaserat arbete. Den uppmuntrar mjukvaruteam att ta bort icke-väsentlig information och bara visa nästa åtgärd som arbetaren behöver.

Steg 12: Lägg till funktioner för kamera, foto, video och liveförhandsvisning

Glasses SDK exponerar mediefunktioner för foto, video, ljud och förhandsvisning. Phone SDK kan ta emot medieströmmar från glasögonen. Rokids FAQ anger en standardvideoström på 1080P med ungefär 15 till 19 bilder per sekund och cirka 300 ms uppspelningslatens på telefonen, och noterar att utdata kan vara H.264 eller avkodad NV21 beroende på API och demoväg. Betrakta dessa siffror som aktuell implementeringsvägledning snarare än ett garanterat SLA.

Använd stillbilder för inspektionsbevis, bevis på slutfört arbete och senare AI-bearbetning.

Använd H.264 när telefonen eller backend främst behöver vidarebefordra eller lagra strömmen. Rokids changelog för 2.1.8-E lade till styrning av automatisk avkodning från H.264 till NV21 så att onödig avkodning kan undvikas.

Använd NV21 när en datorseendepipeline på telefonsidan behöver avkodade bildrutor.

Använd Wi-Fi P2P för liveförhandsvisning och medieöverföring i stället för klassisk Bluetooth.

Om du behöver kamerabild plus överlägg på skärmen i den inspelade utdatan bör du granska Rokids aktuella API:er för AR Mix/AR-inspelning och matcha dem mot den installerade SDK-versionen.

En praktisk detalj från Rokids FAQ är viktig för bevisarbetsflöden: efter en lyckad P2P-uppladdning kan bilderna på glasögonen rensas bort av systemet. Betrakta den kopia som framgångsrikt tagits emot i telefonen eller backend som affärsmässig sanningskälla och bekräfta att uppladdningen är slutförd innan arbetsordern förs vidare.

Steg 13: Lägg till röst, TTS och AI med eftertanke

Röst kan vara värdefullt när arbetare inte kan använda händerna, men den bör kopplas till uttryckliga arbetsflödesåtgärder. SDK-dokumentationen för glasögonsidan exponerar ASR, TTS, hantering av offlinekommandon och AI-chattfunktioner. För närvarande anger FAQ:n att offline-TTS kräver SDK 2.2.0 eller senare, även om changelogen listar offline-TTS-tjänsten från och med 2.1.2; testa den på din låsta version. Öppen offline-ASR stöds för närvarande inte som standard. För tal-till-text offline hänvisar Rokid utvecklare till privata ASR-/TTS-tjänster snarare än att hävda att det finns en inbyggd väg för offline-ASR.

Offlinekommandoord:

• Bra användning: Korta fasta kommandon som ”nästa”, ”tillbaka”, ”ta bild”
• Designanteckning för företag: Bra för deterministisk handsfreestyrning

Online-ASR:

• Bra användning: Fritt tal till text
• Designanteckning för företag: Kräver nätverks-/tjänsteuppsättning och bör ha ett reservbeteende

TTS/offline-TTS:

• Bra användning: Läsa upp uppmaningar, varningar eller korta bekräftelser
• Designanteckning för företag: Användbart när skärmen ska hållas minimal

AI-chatt/privat AI:

• Bra användning: Kontextuell assistans eller tolkning
• Designanteckning för företag: Låt modellen verka bakom arbetsflödet. Validera datahantering, latens och svarens gränser.

Steg 14: Koppla arbetsflödet säkert till din backend

Det finns två separata backendfrågor: hur din egen applikation når era affärssystem och om ni använder Rokid OpenAPI. Din applikation kan skicka data via den parkopplade telefonen, eller så kan en glasögonapplikation nå internet direkt när Glass3 är ansluten till Wi-Fi. För företagssystem är vanliga backend-API:er normalt den renaste integrationspunkten eftersom inloggningsuppgifter, granskningsloggar, datavalidering och affärsregler stannar på serversidan.

Rokid OpenAPI är ett separat plattformslager. Den officiella dokumentationen kräver ett aktiverat företagskonto och en API Key. Förfrågningar autentiseras med en Bearer-token, skapade nycklar upphör att gälla och standardgiltigheten är en månad om inget annat har konfigurerats. Rokid varnar uttryckligen för att exponera API-nycklar i offentliga repositoryn eller klienter.

Säkerhetsregel: Använd en proxy på serversidan för Rokids plattformsuppgifter närhelst arkitekturen tillåter det. En APK för mobil eller glasögon kan granskas. Utgå inte från att en API-nyckel blir hemlig bara för att den göms i Kotlin eller inbyggd kod.

Aktuella Rokid OpenAPI-moduler omfattar meddelande- och enhets-API:er, bland andra företagsfunktioner (observera att dessa meddelande- och enhets-API:er endast kan nås om enheterna är registrerade i Rokids Lingmou-konsol). Enhets-API:t kan till exempel söka efter registrerade Glass-enheter, medan meddelande-API:t kan skicka ett affärsmeddelande till en målenhet. Använd dessa tjänster endast när de löser ett verkligt driftsättningsbehov. En egen företagsbackend förblir rätt plats för ERP, CMMS, CRM, identitet och orkestrering av arbetsflöden.

Steg 15: Konfigurera företagsbeteenden som autostart och knapphantering

En bärbar enhet blir mer användbar i verksamheten när användaren inte behöver navigera i en startskärm i konsumentstil varje morgon. Rokid dokumenterar en autostartmekanism som kan starta en konfigurerad applikation efter uppstart på företagssystem som stöds. Rokid dokumenterar också anpassning av hårdvaruhändelser och, i changelogen för 2.1.9-E, API:er för att lyssna på och fånga upp händelser.

Använd autostart för dedikerade arbetsflöden inom inspektion, säkerhet eller industri där glasögonen ska öppnas direkt i affärsapplikationen.

Fördröj SDK-beroende arbete en kort stund efter uppstart och verifiera att tjänsterna är redo innan arbetsflödet startas.

Koppla knapphändelser som stöds till ett litet antal meningsfulla åtgärder, som bekräfta, ta bild eller avbryt.

Validera varje autostart- eller avlyssningsfunktion mot målets företagsfirmware, eftersom visst beteende på systemnivå är versionsberoende.

Behåll alltid en väg för support/återställning. Ett låst arbetsflöde som en administratör inte kan lämna är en operativ risk.

Steg 16: Bygg beteende för offline, nya försök och återställning

Ett demo förutsätter ofta perfekt Bluetooth, Wi-Fi och molnåtkomst. Det kan en fältdriftsättning inte göra. Spara det minimala arbetsflödestillstånd som behövs för att klara ett avbrott i telefonanslutningen, ett P2P-fel eller ett tillfälligt nätverksavbrott. Varje affärsåtgärd bör om möjligt vara idempotent så att nya försök inte skapar dubbla arbetsorderhändelser eller medieposter.

Cacha aktuellt arbetsorder-ID, steg-ID och senast bekräftade åtgärd.

Köa osända resultat med en synlig status ”väntar på synkronisering”.

Använd unika operations-ID:n så att backend säkert kan avvisa dubbletter.

Återanslut Bluetooth först och bygg sedan upp P2P igen endast om överföring med hög bandbredd behövs.

Markera aldrig ett mediaberoende steg som slutfört förrän målkopian har kvitterats.

Tillhandahåll en säker reservlösning för användaren när online-ASR eller AI inte är tillgängligt. Fasta offlinekommandon kan fortfarande täcka grundläggande navigering.

Steg 17: Testa på riktig hårdvara med en testmatris för företag

Emulatorer räcker inte för ett glasögonprojekt eftersom optik, termiskt beteende, Bluetooth, P2P, kamera, mikrofon och bärbarhet alla påverkar mjukvaruupplevelsen. Testa hela systemet på exakt den företags-OTA som planeras för piloten.

• Uppstart och autostart: Kallstart, appstart, SDK-beredskap, återhämtning om tjänstebindningen är långsam
• Bluetooth: Första parkoppling, återanslutning, telefonens viloläge, återhämtning efter att ha varit utom räckvidd
• P2P: Upprepad anslutning/frånkoppling, stor fil, liveström, Wi-Fi-byten
• Behörigheter: Ny installation, nekad behörighet, senare beviljande, skillnader mellan Android-versioner
• Media: Foto-/videokvalitet, filkvittering, nytt försök efter misslyckad uppladdning, rensning av lagring
• Röst: Bullrig miljö, inget nätverk, fras som inte stöds, avbruten TTS
• Gränssnitt/optik: Läsbarhet, reflektionsområde upptill, lång text, statusens synlighet, användartrötthet
• Prestanda: Lång session, CPU-temperatur, tillgängligt minne, processöverlevnad
• Backend: Långsamt svar, dubblerad förfrågan, utgången token, server otillgänglig
• Säkerhet: Hantering av inloggningsuppgifter, maskering i loggar, förlorad enhet, återkallande av konto

Rokids FAQ föreslår specifikt att minne och CPU-temperatur övervakas vid prestandafelsökning och varnar för att mycket lite tillgängligt minne gör det mer sannolikt att bakgrundsprocesser avslutas. Det är ytterligare ett skäl att hålla glasögonappen fokuserad och flytta icke-väsentliga tjänster till andra delar av systemet.

Steg 18: Paketera piloten och kontrollera driftsättningens baslinje

Under utvecklingen kan APK:er installeras via Android Studio med Glass3-datakabeln för felsökning. En produktionsdriftsättning kräver en striktare releaseprocess. Rokid dokumenterar ingen policykontroll i MDM-stil (som kioskläge, fjärradering eller app-policyer). I stället dokumenteras enhetsregistrering och statusspårning via Lingmou-konsolen och OpenAPI, medan version 2.2.0-E möjliggör APK-installation via en app för QR-skanning. Samordna driftsättningsmekanism, provisioneringsrättigheter, företagsfirmware och uppdateringspolicy med Rokid eller återförsäljaren innan ni bestämmer er för en utrullningsarkitektur.

1. Frys de testade SDK- och OTA-versionerna för piloten.

1. Skapa signerade release-APK:er för glasögon- och telefonapplikationerna.

1. Dokumentera klient-ID:n, paketnamn och konfigurationen av backendmiljön.

1. Provisionera API-nycklar och backendhemligheter via säker infrastruktur, inte via källkod.

1. Definiera vem som får uppdatera glasögonen, telefonappen och backend, och i vilken ordning.

1. Kör regressionstester efter varje OTA- eller SDK-ändring innan flottan uppdateras.

1. Skapa en supportväg för loggar, enhetsidentitet, anslutningsdiagnostik och återställning till tidigare version.

Exempelarkitektur: en anpassad inspektionsapp för fältservice

Följande är ett praktiskt designexempel sammanställt utifrån Rokids dokumenterade funktioner. Det är inte ett färdigt arbetsflöde från Rokid. Det visar hur utvecklarstacken kan göra glasögonen till en dedikerad affärsterminal.

1. Start. Teknisk åtgärd: Glasögonappen startar automatiskt och kontrollerar att SDK:t är redo. Affärsvärde: Arbetaren börjar direkt i företagets arbetsflöde.
2. Tilldela uppgift. Teknisk åtgärd: Telefon/backend skickar en sammanfattning av arbetsordern som ett kompakt meddelande. Affärsvärde: Ingen manuell sökning i en telefon krävs.
3. Vägled. Teknisk åtgärd: Glasögonen visar en instruktion i skärmens centrala område. Affärsvärde: Händerna förblir fria för uppgiften.
4. Bekräfta. Teknisk åtgärd: Arbetaren säger ett fast kommando eller använder en hårdvaruhändelse som stöds. Affärsvärde: Snabb, deterministisk interaktion.
5. Dokumentera bevis. Teknisk åtgärd: Glasögonen tar ett foto eller ett kort klipp. Affärsvärde: Visuella bevis kopplas till rätt steg.
6. Överför. Teknisk åtgärd: Media skickas via P2P; ett litet statusmeddelande bekräftar uppladdningen. Affärsvärde: Stora datamängder hålls borta från styrkanalen med låg bandbredd.
7. Synkronisera. Teknisk åtgärd: Telefon eller backend skickar resultatet till CMMS-/ERP-API:t. Affärsvärde: Befintliga affärssystem förblir det ledande systemet (system of record).
8. Avvikelse. Teknisk åtgärd: Vid behov tar telefonen emot en liveström eller så utlöser appen den godkända vägen för fjärrassistans. Affärsvärde: En arbetsledare kan se det som arbetaren ser.
9. Slutför. Teknisk åtgärd: Backend kvitterar slutförandet och returnerar nästa uppgift. Affärsvärde: Användaren får ett tydligt sluttillstånd och revisionsspåret är komplett.

Varför anpassad programvara förändrar affärsnyttan med Rokid AI Glasses Enterprise

Det främsta värdet för företag kommer av att forma enheten kring en befintlig operativ process, eller att omforma processen för handsfreearbete.

Ändamålsenligt gränssnitt: ta bort konsumentmenyer och visa endast den information som krävs i det aktuella arbetssteget.

Integration med affärssystem: koppla insamlade bevis och arbetarens åtgärder till befintliga ERP-, CMMS- och CRM-system eller egna plattformar.

Handsfree datainsamling: använd kamera, röst och inmatning via den bärbara enheten utan att gång på gång behöva gå tillbaka till en telefon eller surfplatta.

Kontrollerad uppkoppling: använd Bluetooth för kommandon och P2P för data med hög bandbredd i stället för att tvinga alla funktioner genom en och samma kanal.

Egna gränser för AI: använd AI där det tillför värde, samtidigt som arbetsflödesregler, behörigheter och datastyrning förblir under företagets kontroll.

Dedikerat enhetsbeteende: autostart och händelsehantering kan minska friktionen vid driftsättningar för ett enda syfte, när företagsfirmwaren stöder det.

Utbyggbar arkitektur: börja med ett lokalt konceptbevis och lägg sedan till backendintegration, plattforms-API:er, fjärrsamarbete eller specialiserade SDK:er i takt med att arbetsflödet mognar.

Köpargumentet: För organisationer som behöver en standardiserad, fast appupplevelse kan anpassad utveckling vara onödig. För organisationer som vill att AI-glasögon ska bli en del av ett kontrollerat operativt arbetsflöde är det dokumenterade Glass3 SDK:t skälet till att hårdvaran blir mer intressant. Företaget köper en anpassningsbar terminal, inte bara en bärbar skärm eller kamera.

Begränsningar och tekniska risker att planera för

• Android-fokuserat SDK: Det offentliga Glass3 SDK:t riktar sig mot inbyggd Android. Enligt Rokids FAQ stöds inte iOS och inbyggt HarmonyOS. En uni-app-integration är endast möjlig om du bygger en egen brygga till det inbyggda Android-SDK:t.
• Kompakt skärm: Den stående ytan på 480 x 640 lämpar sig för koncisa uppmaningar, inte för täta instrumentpaneler för företag. God arbetsflödesdesign är ett måste.
• Avvikelser mellan SDK och changelog: Validera SDK-artefakter, demo och OTA tillsammans och ta hänsyn till versionsskillnader mellan de kinesiska och engelska changelogarna.
• Beroende av onlinetjänster: Vissa ASR-, AI- och OpenAPI-funktioner kräver nätverksåtkomst, inloggningsuppgifter för företag eller provisionering av tjänster.
• Ingen öppen offline-ASR enligt aktuell FAQ: Offline-TTS och fasta offlinekommandon kan stödja robust interaktion, men fri tal-till-text offline finns för närvarande inte dokumenterad som en inbyggd funktion.
• Komplexa överföringsvägar: Bluetooth och P2P löser olika problem. Återanslutning, behörigheter och tillståndssynkronisering kräver utveckling av produktionskvalitet.
• RTC borttaget ur kärnan: Rokid tog bort RTC-samtal från bas-SDK:t för telefon (Phone SDK) i 2.1.7-E. Fjärrsamarbete bör använda Rokids Remote Collaboration SDK eller en separat utvecklad lösning.
• Driftsättningsdetaljer kräver validering: Den offentliga SDK-dokumentationen är stark när det gäller utveckling, men flotthantering i produktion och provisionering via Lingmou-konsolen eller QR-skanningsappen bör bekräftas för kundens miljö före uppskalning.

För- och nackdelar med anpassad företagsutveckling

Fördelar:

• Inbyggd Android-utvecklingsmodell
• Offentliga Maven-artefakter
• Officiellt demo för glasögon + telefon
• Bluetooth och P2P
• Meddelanden/filer/media
• Kamera och liveförhandsvisning
• Röst-/AI-/igenkänningstjänster
• Direkt Wi-Fi möjligt
• OpenAPI för företag
• Möjligheter till autostart och anpassning av händelser.

Nackdelar:

• Inbyggt SDK-stöd endast för Android
• Kompakt fast skärm
• Samordning av versioner/OTA
• Vissa onlinefunktioner kräver företagsåtkomst
• Begränsning för offline-ASR
• Detaljer kring provisionering/flotthantering i produktion behöver bekräftas per projekt.

Slutsats

Rokid AI Glasses Enterprise är värt att överväga när företagets mål är att bygga ett dedikerat handsfreearbetsflöde snarare än att driftsätta en generisk konsumentapplikation. Den nuvarande Glass3-stacken för företag ger Android-utvecklare en dokumenterad väg för att bygga på glasögonen, koppla ihop dem med en Android-telefon, skicka styrdata via Bluetooth, överföra media via Wi-Fi P2P och ansluta arbetsflödet till backendsystem eller utvalda Rokid OpenAPI-tjänster.

De starkaste användningsfallen är guidade inspektioner, fältservice, bevisinsamling, procedurbaserat arbete och andra uppgifter där arbetaren har nytta av att se en instruktion i taget och samtidigt ha båda händerna fria. Den största begränsningen är inte brist på API:er. Det är den tekniska disciplin som krävs kring den lilla skärmen, anslutningsstatus, behörigheter, SDK-/OTA-kompatibilitet och beroenden av onlinetjänster.

För en företagsköpare är den centrala utvärderingsfrågan: ”Kan vi mappa vårt arbetsflöde till den dokumenterade utvecklarstacken, och kan vi ge applikationen support under hela dess livscykel?” Om svaret är ja är anpassad programvara vägen till att förvandla Rokid Glass3 från AI-glasögon för allmänna ändamål till en ändamålsbyggd operativ enhet.

För företag som utvärderar Rokid AI Glasses Enterprise för inspektioner, fältservice, logistik, guidat arbete eller anpassade AI-arbetsflöden kan VR Expert hjälpa till att bedöma hårdvaran, definiera ett konceptbevis och validera vägen till driftsättning. Besök produktsidan för Rokid AI Glasses Enterprise för att se enheten, tillgänglighet och köpalternativ. För avgränsning av anpassad utveckling eller råd om utrullning, kontakta VR Expert.