Come sviluppare software personalizzato per Rokid AI Glasses Enterprise

Sintesi

Rokid AI Glasses Enterprise possono diventare un dispositivo aziendale su misura, anziché essere usati solo con applicazioni preconfigurate. L'attuale documentazione Sprite Enterprise di Rokid mette a disposizione un Glasses SDK per le applicazioni eseguite direttamente su Glass3, un Phone SDK per le applicazioni companion Android e servizi OpenAPI per le integrazioni lato cloud. Insieme, questi livelli supportano connettività del dispositivo, messaggistica, trasferimento di file, acquisizione da fotocamera e di contenuti multimediali, video in diretta, funzioni vocali, servizi di IA, riconoscimento, stato del dispositivo e flussi di lavoro aziendali.

Per un team di sviluppo, il percorso pratico è familiare: creare progetti Android nativi in Android Studio, aggiungere il repository Maven e le dipendenze SDK di Rokid, eseguire la demo ufficiale di Rokid composta da due progetti, stabilire il Bluetooth per il rilevamento e il controllo, passare a Wi-Fi P2P per file di grandi dimensioni e audio/video, quindi collegare il flusso di lavoro al backend aziendale. È possibile anche un'app autonoma per gli occhiali, quando il caso d'uso non richiede uno smartphone companion.

Al di là dell'SDK, il valore principale deriva dalla sostituzione di un'esperienza indossabile generica con un flusso di lavoro controllato. Un tecnico può ricevere un ordine di lavoro, vedere l'istruzione successiva sul display, confermare un passaggio con la voce o con un input hardware, acquisire prove visive e inviare il risultato a un CMMS, a un ERP o a una piattaforma personalizzata. Ciò rende gli occhiali interessanti per ispezioni, assistenza sul campo, lavoro guidato, logistica, documentazione e altri processi a mani libere. Le principali avvertenze riguardano il supporto SDK nativo solo per Android, la compatibilità tra versioni e OTA, la necessità di chiavi API per alcuni servizi online e un display compatto da 480 x 640 che richiede una progettazione dell'interfaccia ponderata.

Che cosa Rokid mette a disposizione degli sviluppatori

Rokid suddivide lo stack enterprise in un SDK a due lati più una piattaforma OpenAPI separata. Comprendere questa suddivisione prima di scrivere codice evita un errore comune: cercare di far fare tutto agli occhiali quando uno smartphone o un backend sono più adatti a gestire rete, autenticazione, archiviazione o integrazione con i sistemi aziendali.

Applicazione per gli occhiali:

• Eseguita su: Rokid Glass3
• Responsabilità tipica: Visualizza l'interfaccia indossabile e accede alle funzionalità lato occhiali, come fotocamera/contenuti multimediali, stato del dispositivo, messaggi, voce, IA e riconoscimento, tramite il Glasses SDK.

Applicazione companion:

• Eseguita su: Smartphone Android
• Responsabilità tipica: Rileva Glass3 e vi si connette, gestisce Bluetooth e Wi-Fi P2P, scambia messaggi/file, riceve flussi multimediali e può inoltrare dati aziendali.

Livello cloud / aziendale:

• Eseguito su: Il tuo backend + Rokid OpenAPI ove pertinente
• Responsabilità tipica: Archivia i dati aziendali, autentica gli utenti, collega sistemi ERP/CMMS/CRM e può utilizzare moduli Rokid OpenAPI come le API di messaggistica o dei dispositivi, se attivati.

Valutazione pratica: Per il software enterprise personalizzato, l'architettura utile è di solito “interfaccia indossabile leggera + servizi del dispositivo affidabili + logica di business su smartphone/backend”. Mantenere essenziale l'esperienza sugli occhiali riduce la complessità dell'interfaccia e rende il progetto più facile da mantenere, preservando comunque l'interazione a mani libere dove conta.

Lo stack di sviluppo in sintesi

• Hardware di destinazione nella documentazione enterprise pubblica: Rokid Glass3
• Modello di sviluppo: Sviluppo di applicazioni Android native
• Artefatto del Glasses SDK: com.rokid.security:glass3.open.sdk
• Artefatto del Phone SDK: com.rokid.security:phone.sdk
• Dipendenza attualmente indicata nel Quick Start: 2.2.0-E per entrambi gli SDK
• Voce più recente visibile nel changelog al momento della ricerca: V2.2.0-E, datata 6 agosto 2026, con OTA consigliata 1.19.e006-20260806-150201 o successiva.
• Strumenti consigliati: Android Studio 2022+, JDK 17+
• Ambiente della demo: Android SDK 34, JDK 17, smartphone Android, Rokid Glass3
• Sistema di coordinate del display degli occhiali: Fisso 480 x 640 verticale
• Trasporti locali principali: Bluetooth classico e Wi-Fi P2P
• Autenticazione cloud: Enterprise API Key per Rokid OpenAPI e alcuni servizi online
• Piattaforma smartphone supportata: Android; le FAQ pubbliche indicano che iOS e HarmonyOS nativo non sono supportati dal Glass3 SDK

Che cosa si può realizzare con Rokid AI Glasses Enterprise?

L'SDK pubblico è abbastanza ampio da supportare più di una singola applicazione dimostrativa. Il prodotto esatto che realizzi dipende da quali funzionalità combini e da quanta logica mantieni sul dispositivo indossabile.

Assistenza sul campo guidata: mostrare un'istruzione alla volta, confermare il completamento, acquisire foto o video e restituire prove strutturate a un sistema di gestione degli ordini di lavoro.

Ispezione e conformità: presentare checklist, utilizzare l'acquisizione da fotocamera o il riconoscimento, allegare prove con data e ora ed effettuare l'escalation delle anomalie.

Flussi di lavoro di magazzino e logistica: mostrare informazioni di prelievo o sulle attività, scambiare comandi leggeri tramite Bluetooth e utilizzare integrazioni di scansione specializzate ove necessario.

Assistenza visiva remota: ricevere un flusso video in diretta sul lato companion o integrare un canale dedicato di collaborazione remota. Rokid ha rimosso le chiamate RTC dal Phone SDK principale nella versione 2.1.7-E, quindi la collaborazione in tempo reale va progettata in base ad Android e Web: il Remote Collaboration SDK di Rokid o un tuo trasporto approvato, anziché dare per scontato che sia integrata nell'SDK di base.

Assistente IA aziendale: combinare input vocale, TTS, chat IA o servizi di IA aziendali con un'interfaccia specifica per il flusso di lavoro, invece di esporre gli utenti a un chatbot generico.

Acquisizione di prove e documentazione: attivare immagini, video o audio, trasferire i contenuti multimediali più pesanti tramite P2P e sincronizzare i risultati con un backend.

Dispositivo indossabile dedicato a un unico scopo: avviare automaticamente l'applicazione aziendale dopo il riavvio e associare gli eventi hardware supportati ad azioni del flusso di lavoro, previa convalida sul firmware di destinazione.

Passo dopo passo: come sviluppare software personalizzato per Rokid AI Glasses Enterprise

Passo 1: definire il flusso di lavoro prima di scegliere l'architettura

Parti dal processo operativo, non dall'elenco degli SDK. Annota esattamente che cosa l'operatore deve vedere, dire, acquisire e confermare. Poi decidi quale dispositivo deve occuparsi di ciascuna responsabilità. Un'applicazione indossabile ben delimitata di solito mostra informazioni concise e acquisisce input, mentre lo smartphone o il backend gestiscono la logica di business più pesante.

App autonoma per gli occhiali:

• Ideale per: Flusso di lavoro locale semplice, acquisizione lato dispositivo, funzionamento offline o con connettività limitata
• Vantaggi: Meno componenti, esperienza indossabile diretta
• Compromesso: Devi gestire più logica di archiviazione/rete sugli occhiali; alcune funzioni online richiedono comunque credenziali o connettività

Occhiali + smartphone Android:

• Ideale per: La maggior parte dei progetti pilota aziendali, contenuti multimediali in diretta, trasferimento di file, controllo remoto, companion per app aziendali
• Vantaggi: Il percorso di connettività meglio documentato; lo smartphone può gestire autenticazione, rete e interfacce che non hanno posto nella lente
• Compromesso: Richiede uno smartphone Android e una logica di riconnessione robusta

Occhiali + smartphone + backend:

• Ideale per: Integrazione ERP/CMMS/CRM, audit trail, ordini di lavoro gestiti centralmente, servizi di IA
• Vantaggi: La soluzione più adatta a flussi di lavoro aziendali scalabili e alla governance dei dati
• Compromesso: Richiede più lavoro di integrazione, sicurezza e ingegneria backend

Raccomandazione: Per una prima proof of concept B2B, usa il modello occhiali + smartphone Android + backend, a meno che il caso d'uso non tragga un chiaro vantaggio da un dispositivo indossabile autonomo. Questo modello ricalca da vicino il flusso a due dispositivi documentato da Rokid e lascia al team di sviluppo la possibilità di spostare rete, credenziali e archiviazione dei dati lontano dagli occhiali.

Passo 2: procurarsi l'hardware e gli accessi corretti

Prima di installare Android Studio, verifica che l'hardware sia effettivamente sul percorso software enterprise. Le FAQ di Rokid indicano che le build enterprise/work contengono di solito una “e” nella versione di sistema. Anche la documentazione dell'SDK distingue tra sistemi enterprise e consumer, quindi l'identificazione del firmware fa parte della configurazione del progetto e non è un dettaglio da rimandare.

Rokid AI Glasses Enterprise (l'hardware Rokid Glasses) con la build di sistema / il firmware enterprise (versione di sistema che termina con “e”).

Il cavo dati di debug per Glass3. Rokid avverte esplicitamente che il normale cavo di ricarica può alimentare gli occhiali ma non può essere utilizzato da Android Studio per il debug.

Uno smartphone Android, se utilizzi il Phone SDK.

Un PC di sviluppo con Android Studio e JDK 17.

Un account enterprise e una API Key, se il progetto utilizzerà Rokid OpenAPI o funzionalità online che richiedono autenticazione.

L'accesso alla versione OTA esatta che intendi distribuire sull'intera flotta del progetto pilota.

Non saltare la verifica del cavo: Rokid indica il cavo dati di debug come obbligatorio perché consente ad Android Studio di riconoscere gli occhiali, installare APK e consultare i log. Se gli occhiali si ricaricano ma non compaiono come dispositivo, controlla il cavo prima di mettere mano a Gradle, ADB o all'SDK.

Passo 3: preparare l'ambiente di sviluppo Android

Il Quick Start di Rokid consiglia Android Studio 2022 o successivo e JDK 17 o successivo, e afferma che il Glass3 SDK supporta Android 8.0 o successivo. La guida ufficiale alla demo utilizza attualmente Android SDK 34. Le FAQ di Rokid, separatamente, consigliano Android 7.0 / API 24 o successivo e invitano a verificare la configurazione Gradle nel pacchetto SDK e nella demo attuali. In un progetto reale, considera i file Gradle della demo come riferimento per la versione esatta che stai integrando.

1. Installa Android Studio 2022 o una versione più recente.

1. Installa e seleziona JDK 17 o una versione più recente per Gradle.

1. Installa la versione di Android SDK richiesta dall'attuale demo di Rokid. La guida alla demo attuale indica SDK 34.

1. Abilita il normale debug Android sullo smartphone di sviluppo.

1. Collega Glass3 con il cavo dati di debug e verifica che Android Studio rilevi un dispositivo simile a “Rokid RG-glasses”.

1. Installa lo strumento di proiezione / mirroring dello schermo di Rokid se vuoi controllare l'interfaccia indossabile dal PC. Rokid consiglia vivamente la proiezione durante lo sviluppo.

Passo 4: eseguire la demo ufficiale di Rokid prima di creare la propria applicazione

Questo è il passaggio pratico più importante dell'intero processo. La demo ufficiale verifica l'ambiente di sviluppo, i binari dell'SDK, le autorizzazioni, i collegamenti hardware e la combinazione di versioni prima che il tuo codice diventi un'ulteriore variabile.

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

# Glasses demo
cd glassdemo
./gradlew assembleDebug

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

Il repository contiene due progetti Android separati: uno per gli occhiali e uno per lo smartphone Android. Rokid consiglia di eseguire prima la demo lato smartphone e poi quella lato occhiali. Una volta installate entrambe, cerca Glass3 dalla demo sullo smartphone e stabilisci la connessione.

1. Inizializzazione dell'SDK. Criterio di superamento: entrambi i progetti si avviano e riportano uno stato SDK valido.
2. Bluetooth. Criterio di superamento: lo smartphone trova Glass3 e vi si connette.
3. Messaggistica. Criterio di superamento: messaggi di testo o di controllo possono transitare tra smartphone e occhiali.
4. Trasferimento di file di piccole dimensioni. Criterio di superamento: un file di piccole dimensioni può essere scambiato senza errori.
5. Wi-Fi P2P. Criterio di superamento: è possibile stabilire un canale P2P per le operazioni a elevata larghezza di banda.
6. Contenuti multimediali. Criterio di superamento: foto, video o anteprima dal vivo possono essere attivati e ricevuti.

Perché è importante dal punto di vista commerciale: Delimitare una proof of concept per un cliente diventa molto più semplice se prima si convalidano le funzioni di base del dispositivo. Puoi così dedicare il tempo del progetto al flusso di lavoro vero e proprio, all'integrazione e all'esperienza utente, invece di diagnosticare una configurazione SDK non verificata.

Passo 5: creare i propri progetti e aggiungere il repository Maven di Rokid

Quando la demo funziona, crea o apri i tuoi progetti Android. Rokid pubblica gli artefatti dell'SDK tramite il proprio repository Maven. Aggiungi il repository insieme a Google e Maven Central, quindi aggiungi la dipendenza per gli occhiali all'app indossabile e la dipendenza per lo smartphone all'app companion.

// 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"
}

L'attuale Quick Start di Rokid indica la versione 2.2.0-E, con OTA consigliata 1.19.e006-20260806-150201 o successiva. I team aziendali dovrebbero fissare e testare una combinazione nota di SDK + OTA, invece di aggiornare automaticamente i componenti in modo indipendente.

Regola per il controllo delle versioni: Prima di un rilascio pilota o di produzione, registra in un'unica matrice di compatibilità la build OTA degli occhiali, la versione del Glasses SDK, la versione del Phone SDK, il commit della demo e le versioni di eventuali SDK specializzati. Ripeti i test di base di connessione e dei contenuti multimediali ogni volta che uno di questi componenti cambia.

Passo 6: dichiarare solo le autorizzazioni Android necessarie al flusso di lavoro

Il Quick Start di Rokid elenca le autorizzazioni comuni per accesso alla rete, Wi-Fi, fotocamera, microfono, archiviazione, Bluetooth e dispositivi nelle vicinanze. Nelle versioni moderne di Android, dichiarare un'autorizzazione nel manifest non basta per le autorizzazioni pericolose. Le app per smartphone e per occhiali devono richiedere le autorizzazioni necessarie in fase di esecuzione e gestire correttamente l'eventuale rifiuto.

• Scansione/connessione Bluetooth: Rilevamento dei dispositivi, associazione, piccoli messaggi e controllo
• Wi-Fi nelle vicinanze / Wi-Fi Direct: Connessione P2P per file, immagini, video e flussi in tempo reale
• Fotocamera: Acquisizione di foto/video e flussi di riconoscimento visivo
• Microfono: Registrazione audio, ASR e interazione vocale
• Rete / Internet: API di backend, servizi online di Rokid, sincronizzazione cloud
• Archiviazione: Gestione dei contenuti multimediali e dei file trasferiti, a seconda del comportamento della versione Android / dell'SDK di destinazione

Consiglio per la produzione: Non copiare alla cieca l'intero manifest della demo. Ridurre al minimo le autorizzazioni semplifica la revisione di sicurezza e riduce la probabilità che gli utenti neghino un'autorizzazione di cui il flusso di lavoro non ha effettivamente bisogno.

Passo 7: inizializzare il Glasses SDK e registrare l'identità dell'app

L'applicazione per gli occhiali si collega al servizio di sicurezza di Rokid, quindi registra un identificatore client. La regola architetturale importante è che lo stesso client ID deve essere noto all'applicazione companion sullo smartphone quando i due lati si scambiano messaggi specifici dell'applicazione.

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

Dopo l'inizializzazione, si accede alle funzionalità lato occhiali tramite i punti di ingresso dei servizi esposti da GlassSdk. I gruppi di API pubbliche includono funzioni comuni/del dispositivo, Bluetooth classico, P2P, messaggistica, contenuti multimediali, gestione dei file, voce/IA, riconoscimento e altri servizi. Non inizializzare tutte le funzionalità all'avvio. Ottieni e attiva solo i servizi necessari per la schermata o la fase del flusso di lavoro corrente.

Controllo dello stato: Usa GlassSdk.isReady() come semplice segnale diagnostico prima di chiamare i servizi delle funzionalità. Se restituisce false, correggi l'inizializzazione o il collegamento al servizio prima di testare le funzioni di livello superiore.

Passo 8: inizializzare l'Android Phone SDK con client ID corrispondenti

Sul lato smartphone, inizializza il motore mobile di Rokid e registra i client ID con cui lo smartphone comunicherà. Il Phone SDK di Rokid è il livello di connessione e controllo per rilevamento dei dispositivi, Bluetooth/P2P, messaggistica, file, ricezione di contenuti multimediali, sincronizzazione della configurazione e operazioni correlate.

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

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

Se alcune funzionalità online richiedono API Key Credentials, la demo contiene informazioni di autenticazione segnaposto che devono essere sostituite con credenziali ottenute tramite la procedura commerciale di Rokid. Tieni i segreti cloud fuori dal controllo del codice sorgente ed evita di incorporare chiavi API di piattaforma a lunga durata in un'applicazione client distribuibile.

Passo 9: connettersi prima tramite Bluetooth, poi usare il P2P per la larghezza di banda

Rokid documenta due modalità di trasporto locale con compiti diversi. Il Bluetooth classico è adatto a rilevamento, connessione, messaggi di controllo e file di piccole dimensioni. Wi-Fi P2P è il canale migliore per immagini, file di grandi dimensioni, video e contenuti multimediali in tempo reale. Usare il trasporto sbagliato è un modo facile per creare un'applicazione che funziona in una demo ma risulta inaffidabile sul campo.

Bluetooth classico:

• Da usare per: Rilevamento, associazione, comandi di controllo, messaggi JSON compatti, file di piccole dimensioni
• Ruolo nella progettazione: Piano di controllo a bassa larghezza di banda

Wi-Fi P2P:

• Da usare per: File di grandi dimensioni, immagini, video, flussi audio/video, sincronizzazione ad alto throughput
• Ruolo nella progettazione: Piano dati ad alta larghezza di banda

Wi-Fi diretto degli occhiali:

• Da usare per: Accesso al backend da un'applicazione per gli occhiali quando il dispositivo è connesso al Wi-Fi
• Ruolo nella progettazione: Utile per alcuni flussi autonomi; occorre comunque progettare il comportamento offline e i tentativi di ripetizione

Un'app aziendale robusta dovrebbe trattare le connessioni come macchine a stati anziché come eventi una tantum. Gestisci esplicitamente la perdita del Bluetooth, la chiusura del P2P, la sospensione dello smartphone, i cambi di rete Wi-Fi e il riavvio degli occhiali. L'utente dovrebbe ricevere uno stato semplice come “riconnessione in corso” o “sincronizzazione in sospeso”, non un'eccezione Android o un errore silenzioso.

Passo 10: definire un piccolo protocollo applicativo per i messaggi di business

Rokid fornisce i servizi di trasporto e messaggistica, ma la tua applicazione ha comunque bisogno di un contratto che stabilisca il significato di un messaggio di business. Mantieni questo contratto compatto, versionato e indipendente dall'interfaccia. JSON è una scelta pratica per i primi progetti perché è facile da ispezionare, anche se il formato esatto del payload è una scelta di progettazione della tua applicazione e non un requisito di Rokid.

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

Al completamento, gli occhiali potrebbero restituire un piccolo messaggio di stato che fa riferimento all'ID dell'ordine di lavoro e al numero del passaggio. Il file multimediale vero e proprio dovrebbe viaggiare sul canale P2P per file/contenuti multimediali, anziché essere incorporato nel messaggio di controllo. Questa separazione mantiene reattivo il canale dei comandi e semplifica i tentativi di ripetizione.

Passo 11: progettare l'interfaccia degli occhiali per 480 x 640, non come un'app per smartphone

Il display di Glass3 utilizza un sistema di coordinate fisso verticale da 480 x 640. Le FAQ di Rokid consigliano di collocare il contenuto principale nella regione centrale da 480 x 400, di usare i 160 pixel superiori e gli 80 pixel inferiori per le informazioni secondarie e di spostare verso il basso i contenuti importanti, perché nei circa 40 pixel superiori possono comparire riflessi ottici. Il sistema operativo non prevede la normale rotazione del display, quindi i layout larghi vanno progettati all'interno dell'area verticale.

Mostra un'attività, un'istruzione o una decisione alla volta. Le dashboard lunghe sono poco adatte alla lente.

Usa uno sfondo nero quando possibile. Rokid lo consiglia per ridurre lo sfarfallio percepito durante l'avvio o le transizioni.

Non collocare testo o pulsanti critici nell'area di riflesso dei circa 40 px superiori.

Rendi evidenti i cambiamenti di stato senza affidarti a codifiche cromatiche complesse. Rokid consiglia il verde come stile visivo principale.

Fornisci uno stato di connessione chiaro e uno stato “sincronizzato / in sospeso” chiaro per i dati aziendali.

Mantieni gli elementi interattivi abbastanza semplici da poter essere usati con l'input hardware supportato o con la voce, senza imporre una navigazione precisa di tipo touch.

Implicazione per il business: Il display è piccolo, ma per il lavoro procedurale questo può essere un vantaggio. Incoraggia i team software a eliminare le informazioni non essenziali e a mostrare solo l'azione successiva di cui l'operatore ha bisogno.

Passo 12: aggiungere funzioni di fotocamera, foto, video e anteprima dal vivo

Il Glasses SDK espone funzionalità multimediali per foto, video, audio e anteprima. Il Phone SDK può ricevere flussi multimediali dagli occhiali. Le FAQ di Rokid indicano un flusso video predefinito a 1080P a circa 15-19 fotogrammi al secondo, con una latenza di riproduzione sullo smartphone di circa 300 ms, e osservano che l'output può essere H.264 o NV21 decodificato a seconda dell'API e del percorso della demo. Considera questi valori come indicazioni sull'implementazione attuale e non come uno SLA garantito.

Usa l'acquisizione di immagini fisse per le prove di ispezione, la prova di completamento e la successiva elaborazione con l'IA.

Usa H.264 quando lo smartphone o il backend devono principalmente inoltrare o archiviare il flusso. Il changelog 2.1.8-E di Rokid ha aggiunto il controllo sulla decodifica automatica da H.264 a NV21, così da evitare decodifiche non necessarie.

Usa NV21 quando una pipeline di visione artificiale lato smartphone ha bisogno di fotogrammi decodificati.

Usa Wi-Fi P2P per l'anteprima dal vivo e il trasferimento dei contenuti multimediali, anziché il Bluetooth classico.

Se nel video registrato ti servono le immagini della fotocamera insieme alla sovrapposizione a schermo, esamina le attuali API AR Mix / di registrazione AR di Rokid e verifica che corrispondano alla versione dell'SDK installata.

Un dettaglio pratico delle FAQ di Rokid è importante per i flussi di raccolta delle prove: dopo un caricamento P2P riuscito, le immagini sugli occhiali possono essere eliminate dal sistema. Considera la copia ricevuta correttamente sullo smartphone o sul backend come fonte di riferimento aziendale e conferma il completamento del caricamento prima di far avanzare l'ordine di lavoro.

Passo 13: aggiungere voce, TTS e IA in modo mirato

La voce può essere preziosa quando gli operatori non possono usare le mani, ma dovrebbe essere legata ad azioni esplicite del flusso di lavoro. La documentazione dell'SDK lato occhiali espone funzionalità di ASR, TTS, gestione dei comandi offline e chat IA. Attualmente, le FAQ indicano che il TTS offline richiede l'SDK 2.2.0 o successivo, anche se il changelog riporta il servizio TTS offline a partire dalla 2.1.2; testalo sulla versione che hai fissato. L'ASR offline a vocabolario libero non è attualmente supportato per impostazione predefinita. Per la trascrizione vocale offline, Rokid indirizza gli sviluppatori verso servizi ASR/TTS privati, anziché dichiarare un percorso ASR offline integrato.

Comandi vocali offline:

• Uso ideale: Comandi brevi e fissi come “avanti”, “indietro”, “acquisisci”
• Nota di progettazione enterprise: Adatti a un controllo a mani libere deterministico

ASR online:

• Uso ideale: Trascrizione vocale a forma libera
• Nota di progettazione enterprise: Richiede la configurazione di rete/servizi e dovrebbe prevedere un comportamento di ripiego

TTS / TTS offline:

• Uso ideale: Lettura di indicazioni, avvisi o brevi conferme
• Nota di progettazione enterprise: Utile quando il display deve restare essenziale

Chat IA / IA privata:

• Uso ideale: Assistenza contestuale o interpretazione
• Nota di progettazione enterprise: Mantieni il modello al servizio del flusso di lavoro. Verifica la gestione dei dati, la latenza e i limiti delle risposte.

Passo 14: collegare in modo sicuro il flusso di lavoro al backend

Le questioni relative al backend sono due e distinte: come la tua applicazione raggiunge i sistemi aziendali e se utilizzare Rokid OpenAPI. La tua applicazione può inviare dati tramite lo smartphone associato, oppure un'applicazione per gli occhiali può accedere direttamente a Internet quando Glass3 è connesso al Wi-Fi. Per i sistemi aziendali, le API di backend standard sono normalmente il punto di integrazione più pulito, perché credenziali, log di audit, convalida dei dati e regole di business restano lato server.

Rokid OpenAPI è un livello di piattaforma separato. La documentazione ufficiale richiede un account enterprise attivato e una API Key. Le richieste si autenticano con un token Bearer, le chiavi create hanno una scadenza e la validità predefinita è di un mese, salvo diversa configurazione. Rokid avverte esplicitamente di non esporre le chiavi API in repository pubblici o nei client.

Regola di sicurezza: Usa un proxy lato server per le credenziali della piattaforma Rokid ogni volta che l'architettura lo consente. Un APK per smartphone o per occhiali può essere ispezionato. Non dare per scontato che nascondere una chiave API nel codice Kotlin o nativo la renda segreta.

Gli attuali moduli Rokid OpenAPI includono, tra le altre funzioni enterprise, le API di messaggistica e dei dispositivi (tieni presente che queste API di messaggistica e dei dispositivi sono accessibili solo se i dispositivi sono registrati nella console Lingmou di Rokid). Ad esempio, l'API dei dispositivi può interrogare le unità Glass registrate, mentre l'API dei messaggi può inviare un messaggio di business a un dispositivo di destinazione. Usa questi servizi solo quando rispondono a un'esigenza reale di implementazione. Un backend aziendale personalizzato resta la sede corretta per ERP, CMMS, CRM, gestione delle identità e orchestrazione dei flussi di lavoro.

Passo 15: configurare comportamenti enterprise come l'avvio automatico e la gestione dei tasti

Un dispositivo indossabile diventa più utile nelle operazioni quando l'utente non deve navigare ogni mattina in un launcher di tipo consumer. Rokid documenta un meccanismo di avvio automatico che può lanciare un'applicazione configurata dopo l'accensione sui sistemi enterprise supportati. Documenta inoltre la personalizzazione degli eventi hardware e, nel changelog 2.1.9-E, API di ascolto/intercettazione degli eventi.

Usa l'avvio automatico per flussi di lavoro dedicati di ispezione, sicurezza o industriali, in cui gli occhiali devono aprirsi direttamente nell'applicazione aziendale.

Ritarda brevemente dopo l'avvio le operazioni che dipendono dall'SDK e verifica che i servizi siano pronti prima di avviare il flusso di lavoro.

Associa gli eventi dei tasti supportati a un numero ridotto di azioni significative, come conferma, acquisizione o annullamento.

Convalida ogni funzione di avvio automatico o di intercettazione sul firmware enterprise di destinazione, perché alcuni comportamenti a livello di sistema dipendono dalla versione.

Prevedi sempre un percorso di supporto/ripristino. Un flusso di lavoro bloccato da cui un amministratore non può uscire rappresenta un rischio operativo.

Passo 16: implementare comportamenti offline, di ripetizione e di ripristino

Una demo presuppone spesso un accesso perfetto a Bluetooth, Wi-Fi e cloud. Un'implementazione sul campo non può farlo. Salva in modo persistente lo stato minimo del flusso di lavoro necessario per superare una disconnessione dello smartphone, un errore P2P o un'interruzione temporanea della rete. Ogni azione di business dovrebbe essere idempotente quando possibile, in modo che un nuovo tentativo non generi eventi duplicati sugli ordini di lavoro o record multimediali doppi.

Memorizza nella cache l'ID dell'ordine di lavoro corrente, l'ID del passaggio e l'ultima azione confermata.

Metti in coda i risultati non inviati con uno stato visibile di “sincronizzazione in sospeso”.

Usa ID di operazione univoci, così che il backend possa rifiutare i duplicati in modo sicuro.

Riconnetti prima il Bluetooth, poi ricostruisci il P2P solo se è necessario un trasferimento ad alta larghezza di banda.

Non contrassegnare mai come completato un passaggio che dipende da contenuti multimediali finché la copia di destinazione non è stata confermata.

Fornisci un ripiego sicuro per l'utente quando l'ASR online o l'IA non sono disponibili. I comandi offline fissi possono comunque coprire la navigazione di base.

Passo 17: testare su hardware reale con una matrice di test enterprise

Gli emulatori non bastano per un progetto con occhiali, perché ottica, comportamento termico, Bluetooth, P2P, fotocamera, microfono e vestibilità influiscono tutti sull'esperienza software. Testa l'intero sistema sull'esatta OTA enterprise prevista per il progetto pilota.

• Avvio e avvio automatico: Avvio a freddo, lancio dell'app, disponibilità dell'SDK, ripristino in caso di collegamento lento al servizio
• Bluetooth: Prima associazione, riconnessione, sospensione dello smartphone, ripristino dopo l'uscita dal raggio d'azione
• P2P: Connessioni/disconnessioni ripetute, file di grandi dimensioni, streaming dal vivo, cambi di rete Wi-Fi
• Autorizzazioni: Nuova installazione, autorizzazione negata, concessione successiva, differenze tra versioni di Android
• Contenuti multimediali: Qualità di foto/video, conferma di ricezione dei file, ripetizione dei caricamenti non riusciti, pulizia dell'archiviazione
• Voce: Ambiente rumoroso, assenza di rete, frase non supportata, interruzione del TTS
• Interfaccia / ottica: Leggibilità, area di riflesso superiore, testi lunghi, visibilità dello stato, affaticamento dell'utente
• Prestazioni: Sessioni lunghe, temperatura della CPU, memoria disponibile, sopravvivenza dei processi
• Backend: Risposta lenta, richiesta duplicata, token scaduto, server non disponibile
• Sicurezza: Gestione delle credenziali, oscuramento dei dati nei log, smarrimento del dispositivo, revoca dell'account

Le FAQ di Rokid suggeriscono in particolare di monitorare la memoria e la temperatura della CPU durante l'analisi dei problemi di prestazioni e avvertono che una memoria disponibile molto bassa rende più probabile la terminazione dei processi in background. È un ulteriore motivo per mantenere l'app per gli occhiali essenziale e spostare altrove i servizi non indispensabili.

Passo 18: preparare il pacchetto del progetto pilota e controllare la baseline di distribuzione

Durante lo sviluppo, gli APK possono essere installati tramite Android Studio usando il cavo dati di debug per Glass3. Un'implementazione in produzione richiede un processo di rilascio più rigoroso. Rokid non documenta alcun controllo delle policy di tipo MDM (come modalità kiosk, cancellazione remota o policy sulle app). Documenta invece la registrazione dei dispositivi e il monitoraggio del loro stato tramite la console Lingmou e OpenAPI, mentre la versione 2.2.0-E consente l'installazione di APK tramite un'app di scansione QR. Concorda con Rokid o con il distributore il meccanismo di distribuzione, i diritti di provisioning, il firmware enterprise e la politica di aggiornamento prima di impegnarti su un'architettura di rollout.

1. Congela le versioni di SDK e OTA testate per il progetto pilota.

1. Crea APK di release firmati per le applicazioni per occhiali e smartphone.

1. Documenta client ID, nomi dei pacchetti e configurazione degli ambienti di backend.

1. Effettua il provisioning delle chiavi API e dei segreti di backend tramite un'infrastruttura sicura, non nel codice sorgente.

1. Stabilisci chi può aggiornare gli occhiali, l'app per smartphone e il backend, e in quale ordine.

1. Esegui test di regressione dopo ogni modifica di OTA o SDK prima di aggiornare la flotta.

1. Predisponi un percorso di supporto per log, identità dei dispositivi, diagnostica della connettività e rollback.

Esempio di architettura: un'app personalizzata di ispezione per l'assistenza sul campo

Quello che segue è un esempio pratico di progettazione costruito a partire dalle funzionalità documentate da Rokid. Non si tratta di un flusso di lavoro Rokid pronto all'uso. Mostra come lo stack di sviluppo possa trasformare gli occhiali in un endpoint aziendale dedicato.

1. Avvio. Azione tecnica: l'app per gli occhiali si avvia automaticamente e verifica che l'SDK sia pronto. Valore per il business: l'operatore parte direttamente dal flusso di lavoro aziendale.
2. Assegnazione dell'attività. Azione tecnica: lo smartphone/backend invia il riepilogo dell'ordine di lavoro come messaggio compatto. Valore per il business: non è necessaria alcuna ricerca manuale su uno smartphone.
3. Guida. Azione tecnica: gli occhiali mostrano un'istruzione nell'area centrale del display. Valore per il business: le mani restano libere per l'attività.
4. Conferma. Azione tecnica: l'operatore pronuncia un comando fisso o usa un evento hardware supportato. Valore per il business: interazione rapida e deterministica.
5. Acquisizione delle prove. Azione tecnica: gli occhiali scattano una foto o registrano un breve filmato. Valore per il business: la prova visiva viene allegata al passaggio corretto.
6. Trasferimento. Azione tecnica: i contenuti multimediali viaggiano via P2P; un piccolo messaggio di stato conferma il caricamento. Valore per il business: i dati pesanti restano fuori dal canale di controllo a bassa larghezza di banda.
7. Sincronizzazione. Azione tecnica: lo smartphone o il backend inviano il risultato all'API del CMMS/ERP. Valore per il business: i sistemi aziendali esistenti restano il sistema di riferimento.
8. Eccezione. Azione tecnica: se necessario, lo smartphone riceve uno streaming dal vivo oppure l'app attiva il canale di assistenza remota approvato. Valore per il business: un supervisore può vedere ciò che vede l'operatore.
9. Completamento. Azione tecnica: il backend conferma il completamento e restituisce l'attività successiva. Valore per il business: l'utente riceve uno stato finale chiaro e l'audit trail è completo.

Perché il software personalizzato cambia il business case di Rokid AI Glasses Enterprise

Il valore principale per le aziende deriva dal modellare il dispositivo attorno a un processo operativo esistente o dal riprogettare tale processo per il lavoro a mani libere.

Interfaccia su misura: eliminare i menu di tipo consumer e mostrare solo le informazioni necessarie nel passaggio di lavoro corrente.

Integrazione con i sistemi aziendali: collegare le prove acquisite e le azioni degli operatori a ERP, CMMS, CRM o piattaforme personalizzate esistenti.

Acquisizione di dati a mani libere: usare fotocamera, voce e input indossabile senza dover tornare continuamente a uno smartphone o a un tablet.

Connettività controllata: usare il Bluetooth per i comandi e il P2P per i dati ad alta larghezza di banda, invece di far passare ogni funzione da un unico canale.

Limiti personalizzati per l'IA: usare l'IA dove aggiunge valore, mantenendo regole del flusso di lavoro, autorizzazioni e governance dei dati sotto il controllo dell'azienda.

Comportamento da dispositivo dedicato: l'avvio automatico e la gestione degli eventi possono ridurre gli attriti nelle implementazioni monouso, se supportati dal firmware enterprise.

Architettura espandibile: partire da una proof of concept locale, poi aggiungere integrazione backend, API di piattaforma, collaborazione remota o SDK specializzati man mano che il flusso di lavoro matura.

L'argomento per l'acquisto: Per le organizzazioni che hanno bisogno di un'esperienza applicativa standard e fissa, lo sviluppo personalizzato potrebbe non essere necessario. Per le organizzazioni che vogliono che gli occhiali con IA diventino parte di un flusso di lavoro operativo controllato, il Glass3 SDK documentato è il motivo per cui l'hardware diventa più interessante. L'azienda acquista un endpoint adattabile, non solo un display indossabile o una fotocamera.

Limiti e rischi tecnici da pianificare

• SDK incentrato su Android: Il Glass3 SDK pubblico è destinato ad Android nativo. Le FAQ di Rokid indicano che iOS e HarmonyOS nativo non sono supportati. Un'integrazione uni-app è possibile solo costruendo un proprio bridge verso l'SDK Android nativo.
• Display compatto: L'area verticale da 480 x 640 è adatta a indicazioni concise, non a dashboard aziendali dense. Una buona progettazione del flusso di lavoro è indispensabile.
• Discrepanze tra SDK e changelog: Convalida insieme artefatti dell'SDK, demo e OTA, tenendo conto delle differenze di versione tra i changelog in cinese e in inglese.
• Dipendenza dai servizi online: Alcune funzioni di ASR, IA e OpenAPI richiedono accesso alla rete, credenziali enterprise o il provisioning dei servizi.
• Nessun ASR offline a vocabolario libero nelle FAQ attuali: Il TTS offline e le funzioni di comando offline fisse possono supportare un'interazione resiliente, ma la trascrizione vocale offline a forma libera non è attualmente documentata come integrata.
• Complessità del trasporto: Bluetooth e P2P risolvono problemi diversi. Riconnessione, autorizzazioni e sincronizzazione dello stato richiedono un'ingegneria di qualità da produzione.
• RTC rimosso dal nucleo: Rokid ha rimosso le chiamate RTC dal Phone SDK di base nella 2.1.7-E. La collaborazione remota dovrebbe usare il Remote Collaboration SDK di Rokid o una soluzione sviluppata separatamente.
• I dettagli di implementazione richiedono convalida: La documentazione pubblica dell'SDK è solida per lo sviluppo, ma la gestione della flotta in produzione e il provisioning tramite la console Lingmou o l'app di scansione QR vanno confermati per l'ambiente del cliente prima di passare su larga scala.

Pro e contro dello sviluppo enterprise personalizzato

Pro:

• Modello di sviluppo Android nativo
• Artefatti Maven pubblici
• Demo ufficiale occhiali + smartphone
• Bluetooth e P2P
• Messaggistica/file/contenuti multimediali
• Fotocamera e anteprima dal vivo
• Servizi di voce/IA/riconoscimento
• Possibilità di Wi-Fi diretto
• OpenAPI enterprise
• Possibilità di avvio automatico e personalizzazione degli eventi.

Contro:

• Supporto SDK nativo solo per Android
• Display compatto e fisso
• Coordinamento di versioni/OTA
• Alcune funzioni online richiedono un accesso enterprise
• Limitazioni dell'ASR offline
• I dettagli di provisioning/gestione della flotta in produzione richiedono una conferma specifica per il progetto.

Valutazione finale

Rokid AI Glasses Enterprise meritano di essere presi in considerazione quando l'obiettivo dell'azienda è costruire un flusso di lavoro dedicato a mani libere, anziché distribuire un'applicazione consumer generica. L'attuale stack enterprise di Glass3 offre agli sviluppatori Android un percorso documentato per sviluppare sugli occhiali, associarli a uno smartphone Android, trasmettere i dati di controllo via Bluetooth, trasferire i contenuti multimediali tramite Wi-Fi P2P e collegare il flusso di lavoro a sistemi di backend o a determinati servizi Rokid OpenAPI.

I casi d'uso più efficaci sono le ispezioni guidate, l'assistenza sul campo, l'acquisizione di prove, il lavoro procedurale e altre attività in cui l'operatore trae vantaggio dal vedere un'istruzione alla volta mantenendo entrambe le mani libere. Il limite principale non è la mancanza di API, bensì la disciplina ingegneristica richiesta per gestire il display ridotto, lo stato della connettività, le autorizzazioni, la compatibilità tra SDK e OTA e le dipendenze dai servizi online.

Per un acquirente aziendale, la domanda chiave della valutazione è: “Possiamo adattare il nostro flusso di lavoro allo stack di sviluppo documentato e siamo in grado di supportare l'applicazione per tutto il suo ciclo di vita?” Se la risposta è sì, il software personalizzato offre la strada per trasformare Rokid Glass3 da occhiali con IA per uso generale in un dispositivo operativo su misura.

Per le aziende che stanno valutando Rokid AI Glasses Enterprise per ispezioni, assistenza sul campo, logistica, lavoro guidato o flussi di lavoro di IA personalizzati, VR Expert può aiutare a valutare l'hardware, definire una proof of concept e convalidare il percorso di implementazione. Visita la pagina prodotto di Rokid AI Glasses Enterprise per esaminare il dispositivo, la disponibilità e le opzioni di acquisto. Per definire l'ambito di uno sviluppo personalizzato o ricevere consigli sul rollout, contatta VR Expert.