Jak opracować dedykowane oprogramowanie dla Rokid AI Glasses Enterprise

Podsumowanie

Rokid AI Glasses Enterprise można przekształcić w urządzenie biznesowe zaprojektowane do konkretnych zadań, zamiast używać go wyłącznie z fabrycznie skonfigurowanymi aplikacjami. Aktualna dokumentacja Rokid Sprite Enterprise udostępnia Glasses SDK dla aplikacji działających bezpośrednio na Glass3, Phone SDK dla towarzyszących aplikacji na Androida oraz usługi OpenAPI do integracji po stronie chmury. Razem warstwy te obsługują łączność z urządzeniem, przesyłanie wiadomości i plików, aparat i rejestrowanie multimediów, wideo na żywo, funkcje głosowe, usługi AI, rozpoznawanie, stan urządzenia oraz procesy biznesowe.

Dla zespołu programistów praktyczna ścieżka wygląda znajomo: tworzenie natywnych projektów na Androida w Android Studio, dodanie repozytorium Maven firmy Rokid i zależności SDK, uruchomienie oficjalnego demo Rokid składającego się z dwóch projektów, nawiązanie połączenia Bluetooth do wykrywania i sterowania, przełączenie na Wi-Fi P2P przy dużych plikach oraz audio/wideo, a następnie połączenie procesu z backendem firmy. Możliwa jest też samodzielna aplikacja na okulary, jeśli dany przypadek użycia nie wymaga telefonu towarzyszącego.

Poza samym SDK główna wartość wynika z zastąpienia ogólnego doświadczenia urządzenia noszonego kontrolowanym procesem pracy. Technik może otrzymać zlecenie pracy, zobaczyć na wyświetlaczu kolejną instrukcję, potwierdzić krok głosem lub przyciskiem sprzętowym, zarejestrować dowód wizualny i wysłać wynik do systemu CMMS, ERP lub własnej platformy. Dzięki temu okulary sprawdzają się przy inspekcjach, serwisie terenowym, pracy z instrukcjami krok po kroku, logistyce, dokumentacji i w innych procesach wymagających wolnych rąk. Główne zastrzeżenia to natywne SDK obsługujące wyłącznie Androida, kompatybilność wersji i aktualizacji OTA, wymóg klucza API dla wybranych usług online oraz kompaktowy wyświetlacz 480 x 640, który wymaga przemyślanego projektu interfejsu.

Co Rokid udostępnia programistom

Rokid dzieli stos rozwiązań dla firm na dwustronne SDK oraz osobną platformę OpenAPI. Zrozumienie tego podziału przed napisaniem kodu pozwala uniknąć częstego błędu: prób zmuszenia okularów do robienia wszystkiego, podczas gdy telefon lub backend lepiej nadają się do obsługi sieci, uwierzytelniania, przechowywania danych czy integracji z systemami biznesowymi.

Aplikacja na okulary:

• Działa na: Rokid Glass3
• Typowe zadania: Renderuje interfejs na okularach i korzysta z funkcji po stronie okularów, takich jak aparat/multimedia, stan urządzenia, wiadomości, głos, AI i rozpoznawanie, za pośrednictwem Glasses SDK.

Aplikacja towarzysząca:

• Działa na: telefonie z Androidem
• Typowe zadania: Wykrywa Glass3 i łączy się z nimi, zarządza Bluetooth i Wi-Fi P2P, wymienia wiadomości/pliki, odbiera strumienie multimediów i może przekazywać dane biznesowe.

Warstwa chmurowa / biznesowa:

• Działa na: Twoim backendzie + Rokid OpenAPI, jeśli ma zastosowanie
• Typowe zadania: Przechowuje dane biznesowe, uwierzytelnia użytkowników, łączy systemy ERP/CMMS/CRM i może korzystać z modułów Rokid OpenAPI, takich jak API wiadomości lub urządzeń, jeśli zostały udostępnione.

Praktyczny wniosek: W przypadku dedykowanego oprogramowania biznesowego przydatna architektura to zwykle „cienki interfejs na okularach + niezawodne usługi urządzenia + logika biznesowa w telefonie/backendzie”. Skupienie interfejsu okularów na tym, co najważniejsze, zmniejsza jego złożoność i ułatwia utrzymanie projektu, a jednocześnie zachowuje obsługę bez użycia rąk tam, gdzie ma to znaczenie.

Stos programistyczny w skrócie

• Docelowy sprzęt w publicznej dokumentacji dla firm: Rokid Glass3
• Model tworzenia oprogramowania: Natywne tworzenie aplikacji na Androida
• Artefakt Glasses SDK: com.rokid.security:glass3.open.sdk
• Artefakt Phone SDK: com.rokid.security:phone.sdk
• Zależność podana w aktualnym Quick Start: 2.2.0-E dla obu SDK
• Najnowszy widoczny wpis w dzienniku zmian w momencie przygotowywania artykułu: V2.2.0-E z datą 6 sierpnia 2026 r., z zalecaną wersją OTA 1.19.e006-20260806-150201 lub nowszą.
• Zalecane narzędzia: Android Studio 2022+, JDK 17+
• Środowisko demo: Android SDK 34, JDK 17, telefon z Androidem, Rokid Glass3
• Układ współrzędnych wyświetlacza okularów: Stały, 480 x 640, pionowy
• Główne lokalne kanały transmisji: Klasyczny Bluetooth i Wi-Fi P2P
• Uwierzytelnianie w chmurze: Firmowy klucz API (Enterprise API Key) dla Rokid OpenAPI i wybranych usług online
• Obsługiwana platforma telefonu: Android; według publicznego FAQ Glass3 SDK nie obsługuje iOS ani natywnego HarmonyOS

Co można zbudować z Rokid AI Glasses Enterprise?

Publiczne SDK jest na tyle rozbudowane, że pozwala na znacznie więcej niż jedną aplikację demonstracyjną. To, jaki dokładnie produkt powstanie, zależy od tego, które funkcje połączysz i ile logiki pozostawisz na okularach.

Serwis terenowy z instrukcjami krok po kroku: wyświetlanie jednej instrukcji naraz, potwierdzanie wykonania, robienie zdjęć lub nagrywanie wideo oraz przesyłanie ustrukturyzowanych dowodów do systemu zleceń pracy.

Inspekcje i zgodność z przepisami: prezentowanie list kontrolnych, korzystanie z aparatu lub rozpoznawania, dołączanie dowodów ze znacznikiem czasu i eskalowanie nieprawidłowości.

Procesy magazynowe i logistyczne: wyświetlanie informacji o kompletacji lub zadaniach, wymiana prostych poleceń przez Bluetooth i korzystanie ze specjalistycznych integracji skanowania tam, gdzie są potrzebne.

Zdalne wsparcie wizualne: odbieranie strumienia wideo na żywo po stronie aplikacji towarzyszącej lub integracja dedykowanej ścieżki zdalnej współpracy. Rokid usunął połączenia RTC z podstawowego Phone SDK w wersji 2.1.7-E, dlatego współpracę w czasie rzeczywistym należy projektować w oparciu o Remote Collaboration SDK firmy Rokid (Android i web) lub własny zatwierdzony kanał transmisji, a nie zakładać, że jest wbudowana w podstawowe SDK.

Asystent AI dla firm: połączenie wprowadzania mowy, TTS, czatu AI lub firmowych usług AI z interfejsem dopasowanym do konkretnego procesu, zamiast udostępniania użytkownikom ogólnego chatbota.

Rejestrowanie dowodów i dokumentacja: wyzwalanie zdjęć, wideo lub nagrań audio, przesyłanie większych plików multimedialnych przez P2P i synchronizacja wyników z backendem.

Dedykowane urządzenie jednozadaniowe: automatyczne uruchamianie firmowej aplikacji po restarcie i przypisywanie obsługiwanych zdarzeń sprzętowych do działań w procesie, pod warunkiem weryfikacji na docelowym oprogramowaniu układowym.

Krok po kroku: jak opracować dedykowane oprogramowanie dla Rokid AI Glasses Enterprise

Krok 1: Zdefiniuj proces pracy przed wyborem architektury

Zacznij od procesu operacyjnego, a nie od listy SDK. Zapisz dokładnie, co pracownik musi zobaczyć, powiedzieć, zarejestrować i potwierdzić. Następnie zdecyduj, które urządzenie ma odpowiadać za poszczególne zadania. Dobrze zaprojektowana aplikacja na okulary zwykle wyświetla zwięzłe informacje i przyjmuje dane wejściowe, a cięższą logiką biznesową zajmuje się telefon lub backend.

Samodzielna aplikacja na okulary:

• Najlepsze zastosowanie: Prosty lokalny proces, rejestrowanie po stronie urządzenia, praca offline lub przy ograniczonej łączności
• Zalety: Mniej komponentów, bezpośrednia obsługa na okularach
• Kompromis: Więcej logiki przechowywania danych i komunikacji sieciowej trzeba obsłużyć na okularach; niektóre funkcje online nadal wymagają danych uwierzytelniających lub łączności

Okulary + telefon z Androidem:

• Najlepsze zastosowanie: Większość pilotaży w firmach, multimedia na żywo, przesyłanie plików, zdalne sterowanie, aplikacja biznesowa jako aplikacja towarzysząca
• Zalety: Najlepiej udokumentowana ścieżka łączności; telefon może obsługiwać uwierzytelnianie, komunikację sieciową i interfejs, który nie pasuje do wyświetlacza okularów
• Kompromis: Wymaga telefonu z Androidem i solidnej logiki ponownego łączenia

Okulary + telefon + backend:

• Najlepsze zastosowanie: Integracja z ERP/CMMS/CRM, ścieżka audytu, centralnie zarządzane zlecenia pracy, usługi AI
• Zalety: Najlepiej sprawdza się w skalowalnych procesach biznesowych i zarządzaniu danymi
• Kompromis: Wymaga więcej pracy przy integracji, bezpieczeństwie i backendzie

Rekomendacja: Przy pierwszym proof of concept B2B zastosuj model okulary + telefon z Androidem + backend, chyba że dany przypadek użycia wyraźnie zyskuje na samodzielnych okularach. Model ten ściśle odpowiada udokumentowanemu przez Rokid przepływowi z dwoma urządzeniami i daje zespołowi programistów możliwość przeniesienia komunikacji sieciowej, danych uwierzytelniających i przechowywania danych poza okulary.

Krok 2: Zapewnij odpowiedni sprzęt i dostęp

Przed instalacją Android Studio upewnij się, że sprzęt rzeczywiście działa na oprogramowaniu w wersji dla firm. Według FAQ Rokid wersje dla firm/do pracy zwykle zawierają literę „e” w numerze wersji systemu. Dokumentacja SDK również rozróżnia systemy dla firm i konsumenckie, więc identyfikacja oprogramowania układowego jest częścią konfiguracji projektu, a nie sprawą drugorzędną.

Rokid AI Glasses Enterprise (sprzęt Rokid Glasses) z systemem / oprogramowaniem układowym w wersji dla firm (numer wersji systemu kończący się literą „e”).

Kabel do transmisji danych i debugowania Glass3. Rokid wyraźnie ostrzega, że zwykły kabel ładujący może zasilać okulary, ale Android Studio nie może go używać do debugowania.

Telefon z Androidem, jeśli korzystasz z Phone SDK.

Komputer programistyczny z Android Studio i JDK 17.

Konto firmowe i klucz API, jeśli projekt będzie korzystał z Rokid OpenAPI lub funkcji online wymagających uwierzytelnienia.

Dostęp do dokładnie tej wersji OTA, którą planujesz wdrożyć na wszystkich urządzeniach pilotażowych.

Nie pomijaj sprawdzenia kabla: Rokid wymienia kabel do transmisji danych i debugowania jako wymagany, ponieważ umożliwia on Android Studio rozpoznanie okularów, instalację plików APK i przeglądanie logów. Jeśli okulary się ładują, ale nie pojawiają się jako urządzenie, sprawdź kabel, zanim zaczniesz debugować Gradle, ADB lub SDK.

Krok 3: Przygotuj środowisko programistyczne Androida

Quick Start Rokid zaleca Android Studio 2022 lub nowsze, JDK 17 lub nowszy i podaje, że Glass3 SDK obsługuje Androida 8.0 lub nowszego. Oficjalny przewodnik po demo korzysta obecnie z Android SDK 34. FAQ Rokid osobno zaleca Androida 7.0 / API 24 lub nowszego i radzi sprawdzić konfigurację Gradle w aktualnym pakiecie SDK i demo. W prawdziwym projekcie traktuj pliki Gradle z demo jako źródło prawdy dla konkretnego wydania, które integrujesz.

1. Zainstaluj Android Studio 2022 lub nowsze.

1. Zainstaluj JDK 17 lub nowszy i wybierz go dla Gradle.

1. Zainstaluj wersję Android SDK wymaganą przez aktualne demo Rokid. Obecny przewodnik po demo wymienia SDK 34.

1. Włącz standardowe debugowanie Androida na telefonie programistycznym.

1. Podłącz Glass3 kablem do transmisji danych i debugowania i sprawdź, czy Android Studio widzi urządzenie docelowe o nazwie podobnej do „Rokid RG-glasses”.

1. Zainstaluj narzędzie Rokid do projekcji / dublowania ekranu, jeśli chcesz podglądać interfejs okularów na komputerze. Rokid zdecydowanie zaleca korzystanie z projekcji podczas tworzenia oprogramowania.

Krok 4: Uruchom oficjalne demo Rokid przed utworzeniem własnej aplikacji

To najważniejszy praktyczny krok w całym procesie. Oficjalne demo potwierdza poprawność środowiska programistycznego, plików binarnych SDK, uprawnień, połączeń sprzętowych i zestawu wersji, zanim Twój własny kod stanie się kolejną zmienną.

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

# Demo dla okularów
cd glassdemo
./gradlew assembleDebug

# Demo dla telefonu
cd ../glass3sdkphonedemo
./gradlew assembleDebug

Repozytorium zawiera dwa osobne projekty na Androida: jeden dla okularów i jeden dla telefonu z Androidem. Rokid zaleca najpierw uruchomić demo po stronie telefonu, a potem demo po stronie okularów. Po zainstalowaniu obu wyszukaj Glass3 w demo na telefonie i nawiąż połączenie.

1. Inicjalizacja SDK. Warunek zaliczenia: oba projekty uruchamiają się i zgłaszają prawidłowy stan SDK.
2. Bluetooth. Warunek zaliczenia: telefon wykrywa Glass3 i łączy się z nimi.
3. Przesyłanie wiadomości. Warunek zaliczenia: wiadomości tekstowe lub sterujące mogą być przesyłane między telefonem a okularami.
4. Przesyłanie małych plików. Warunek zaliczenia: mały plik można wymienić bez błędów.
5. Wi-Fi P2P. Warunek zaliczenia: można nawiązać kanał P2P dla operacji wymagających dużej przepustowości.
6. Multimedia. Warunek zaliczenia: można wyzwolić i odebrać zdjęcie, wideo lub podgląd na żywo.

Dlaczego ma to znaczenie biznesowe: Zakres proof of concept dla klienta znacznie łatwiej określić, gdy podstawowe funkcje urządzenia zostały wcześniej zweryfikowane. Czas projektu można wtedy poświęcić na właściwy proces, integrację i doświadczenie użytkownika, zamiast diagnozować niezweryfikowaną konfigurację SDK.

Krok 5: Utwórz własne projekty i dodaj repozytorium Maven firmy Rokid

Gdy demo działa, utwórz lub otwórz własne projekty na Androida. Rokid publikuje artefakty SDK w swoim repozytorium Maven. Dodaj je obok repozytoriów Google i Maven Central, a następnie dodaj zależność dla okularów do aplikacji na okulary, a zależność dla telefonu do aplikacji towarzyszącej.

// settings.gradle - uproszczony przykład
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
        maven { url 'https://maven.rokid.com/repository/maven-public/' }
    }
}

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

// Aplikacja na telefon z Androidem
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

Aktualny Quick Start Rokid podaje wersję 2.2.0-E z zalecaną wersją OTA 1.19.e006-20260806-150201 lub nowszą. Zespoły w firmach powinny przypiąć i przetestować znaną kombinację SDK + OTA, zamiast automatycznie aktualizować komponenty niezależnie od siebie.

Zasada kontroli wersji: Przed wydaniem pilotażowym lub produkcyjnym zapisz w jednej macierzy kompatybilności wersję OTA okularów, wersję Glasses SDK, wersję Phone SDK, commit demo oraz wersje wszelkich specjalistycznych SDK. Powtarzaj podstawowe testy połączenia i multimediów za każdym razem, gdy zmieni się którykolwiek z tych komponentów.

Krok 6: Deklaruj tylko te uprawnienia Androida, których potrzebuje Twój proces

Quick Start Rokid wymienia typowe uprawnienia dotyczące dostępu do sieci, Wi-Fi, aparatu, mikrofonu, pamięci, Bluetooth i urządzeń w pobliżu. W nowoczesnych wersjach Androida zadeklarowanie uprawnienia w manifeście nie wystarcza w przypadku uprawnień niebezpiecznych. Aplikacje na telefon i okulary muszą prosić o wymagane uprawnienia w czasie działania i prawidłowo obsługiwać odmowę.

• Skanowanie/łączenie Bluetooth: Wykrywanie urządzeń, parowanie, krótkie wiadomości i sterowanie
• Urządzenia Wi-Fi w pobliżu / Wi-Fi Direct: Połączenie P2P dla plików, zdjęć, wideo i strumieni w czasie rzeczywistym
• Aparat: Robienie zdjęć/nagrywanie wideo i procesy rozpoznawania wizualnego
• Mikrofon: Nagrywanie dźwięku, ASR i interakcja głosowa
• Sieć / internet: API backendu, usługi online Rokid, synchronizacja z chmurą
• Pamięć: Obsługa multimediów i przesłanych plików, w zależności od zachowania docelowej wersji Androida / SDK

Wskazówka dla wdrożeń produkcyjnych: Nie kopiuj bezrefleksyjnie całego manifestu z demo. Ograniczenie uprawnień do minimum ułatwia przegląd bezpieczeństwa i zmniejsza ryzyko, że użytkownicy odrzucą uprawnienie, którego proces w rzeczywistości nie potrzebuje.

Krok 7: Zainicjalizuj Glasses SDK i zarejestruj tożsamość aplikacji

Aplikacja na okulary łączy się z usługą bezpieczeństwa Rokid, a następnie rejestruje identyfikator klienta. Ważna zasada architektoniczna: ten sam identyfikator klienta jest znany również aplikacji towarzyszącej na telefonie, gdy obie strony wymieniają wiadomości specyficzne dla aplikacji.

// Struktura poglądowa, uproszczona na podstawie procesu inicjalizacji Rokid
if (!GlassSdk.isReady()) {
    GlassSdk.bindSecurityService(context, object : IServiceConnectionCallback {
        override fun onServiceConnected() {
            GlassSdk.registerClient("FieldServiceApp", messageCallback)
        }
    })
}

Po inicjalizacji funkcje po stronie okularów są dostępne przez punkty wejścia usług udostępniane przez GlassSdk. Grupy publicznego API obejmują funkcje ogólne/urządzenia, klasyczny Bluetooth, P2P, wiadomości, multimedia, obsługę plików, głos/AI, rozpoznawanie i inne usługi. Nie inicjalizuj wszystkich funkcji przy starcie. Pobieraj i aktywuj tylko usługi wymagane dla bieżącego ekranu lub etapu procesu.

Kontrola stanu: Używaj GlassSdk.isReady() jako prostego sygnału diagnostycznego przed wywołaniem usług poszczególnych funkcji. Jeśli zwraca false, napraw inicjalizację lub powiązanie usługi, zanim zaczniesz testować funkcje wyższego poziomu.

Krok 8: Zainicjalizuj Android Phone SDK z pasującymi identyfikatorami klienta

Po stronie telefonu zainicjalizuj silnik mobilny Rokid i zarejestruj identyfikatory klientów, z którymi telefon będzie się komunikować. Phone SDK firmy Rokid to warstwa połączeń i sterowania odpowiedzialna za wykrywanie urządzeń, Bluetooth/P2P, wiadomości, pliki, odbieranie multimediów, synchronizację konfiguracji i powiązane operacje.

// Zarys na poziomie aplikacji
val engineParam = EngineParam.Builder()
    .setClientIds(listOf("FieldServiceApp"))
    .setApiKeyCredentials(apiKeyCredentials)
    .build()
IMobileEngine.initSDK(engineParam)

// Kontrola diagnostyczna
val ready = PSecuritySDK.getMobileEngineService().isInit()

Jeśli wybrane funkcje online wymagają API Key Credentials, demo zawiera zastępcze dane uwierzytelniające, które należy zastąpić danymi uzyskanymi w ramach procesu biznesowego Rokid. Nie przechowuj sekretów chmurowych w systemie kontroli wersji i unikaj osadzania długoterminowych kluczy API platformy w dystrybuowanej aplikacji klienckiej.

Krok 9: Najpierw połącz się przez Bluetooth, a potem korzystaj z P2P, gdy potrzebna jest przepustowość

Rokid dokumentuje dwa wzorce lokalnej transmisji o różnym przeznaczeniu. Klasyczny Bluetooth nadaje się do wykrywania, łączenia, wiadomości sterujących i małych plików. Wi-Fi P2P to lepszy kanał dla zdjęć, dużych plików, wideo i multimediów w czasie rzeczywistym. Wybór niewłaściwego kanału to prosty sposób na stworzenie aplikacji, która działa w demo, ale w terenie sprawia wrażenie zawodnej.

Klasyczny Bluetooth:

• Zastosowanie: Wykrywanie, parowanie, polecenia sterujące, zwięzłe wiadomości JSON, małe pliki
• Rola w projekcie: Płaszczyzna sterowania o niskiej przepustowości

Wi-Fi P2P:

• Zastosowanie: Duże pliki, zdjęcia, wideo, strumienie audio/wideo, synchronizacja o wysokiej przepustowości
• Rola w projekcie: Płaszczyzna danych o wysokiej przepustowości

Bezpośrednie Wi-Fi okularów:

• Zastosowanie: Dostęp do backendu z aplikacji na okulary, gdy urządzenie jest połączone z Wi-Fi
• Rola w projekcie: Przydatne w wybranych samodzielnych procesach; nadal należy zaprojektować działanie offline i ponawianie prób

Solidna aplikacja biznesowa powinna traktować połączenia jak maszyny stanów, a nie jednorazowe zdarzenia. Jawnie obsługuj utratę połączenia Bluetooth, zamknięcie kanału P2P, uśpienie telefonu, zmiany sieci Wi-Fi i restart okularów. Użytkownik powinien otrzymać prosty komunikat o stanie, np. „ponowne łączenie” lub „oczekuje na synchronizację”, a nie wyjątek Androida czy cichą awarię.

Krok 10: Zdefiniuj prosty protokół aplikacji dla wiadomości biznesowych

Rokid zapewnia usługi transmisji i wiadomości, ale Twoja aplikacja nadal potrzebuje kontraktu określającego, co oznacza dana wiadomość biznesowa. Taki kontrakt powinien być zwięzły, wersjonowany i niezależny od interfejsu. JSON to praktyczny wybór we wczesnych projektach, ponieważ łatwo go analizować, choć dokładny format danych jest kwestią projektu aplikacji, a nie wymogiem Rokid.

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

Po wykonaniu kroku okulary mogą zwrócić krótki komunikat o stanie, który odwołuje się do identyfikatora zlecenia pracy i numeru kroku. Sam plik multimedialny powinien być przesyłany ścieżką plików/multimediów P2P, a nie osadzany w wiadomości sterującej. Taki podział zapewnia responsywność kanału poleceń i upraszcza ponawianie prób.

Krok 11: Projektuj interfejs okularów pod 480 x 640, a nie jak aplikację na telefon

Wyświetlacz Glass3 korzysta ze stałego pionowego układu współrzędnych 480 x 640. FAQ Rokid zaleca umieszczanie głównej treści w centralnym obszarze 480 x 400, wykorzystywanie górnych 160 pikseli i dolnych 80 pikseli na informacje dodatkowe oraz przesuwanie ważnych treści niżej, ponieważ w górnych mniej więcej 40 pikselach mogą pojawiać się odbicia optyczne. System nie zapewnia standardowego obracania ekranu, więc szerokie układy trzeba projektować w obrębie pionowego obszaru roboczego.

Wyświetlaj jedno zadanie, instrukcję lub decyzję naraz. Długie pulpity nawigacyjne słabo sprawdzają się na wyświetlaczu okularów.

W miarę możliwości używaj czarnego tła. Rokid zaleca je, aby ograniczyć odczuwalne migotanie podczas uruchamiania lub przejść.

Nie umieszczaj kluczowego tekstu ani przycisków w górnym obszarze odbić o wysokości ok. 40 px.

Zmiany stanu powinny być oczywiste bez stosowania złożonego kodowania kolorami. Rokid zaleca zieleń jako główny styl wizualny.

Zapewnij czytelną informację o stanie połączenia oraz wyraźny stan „zsynchronizowano / oczekuje” dla danych biznesowych.

Elementy interakcji powinny być na tyle proste, by dało się nimi sterować za pomocą obsługiwanych przycisków sprzętowych lub głosu, bez wymuszania precyzyjnej nawigacji w stylu dotykowym.

Wnioski dla biznesu: Wyświetlacz jest mały, ale w pracy proceduralnej może to być zaleta. Skłania zespoły programistów do usuwania zbędnych informacji i pokazywania tylko kolejnej czynności, której potrzebuje pracownik.

Krok 12: Dodaj funkcje aparatu, zdjęć, wideo i podglądu na żywo

Glasses SDK udostępnia funkcje multimedialne do zdjęć, wideo, dźwięku i podglądu. Phone SDK może odbierać strumienie multimediów z okularów. FAQ Rokid podaje domyślny strumień wideo 1080P przy około 15–19 klatkach na sekundę z opóźnieniem odtwarzania na telefonie wynoszącym około 300 ms i zaznacza, że w zależności od API i ścieżki demo wyjściem może być H.264 lub zdekodowany NV21. Traktuj te wartości jako aktualne wskazówki implementacyjne, a nie gwarantowane SLA.

Używaj zdjęć do dokumentowania inspekcji, potwierdzania wykonania prac i późniejszego przetwarzania przez AI.

Używaj H.264, gdy telefon lub backend ma głównie przekazywać lub zapisywać strumień. Dziennik zmian Rokid dla wersji 2.1.8-E dodał kontrolę nad automatycznym dekodowaniem H.264 do NV21, dzięki czemu można uniknąć zbędnego dekodowania.

Używaj NV21, gdy potok widzenia komputerowego po stronie telefonu potrzebuje zdekodowanych klatek.

Do podglądu na żywo i przesyłania multimediów używaj Wi-Fi P2P, a nie klasycznego Bluetooth.

Jeśli w nagraniu potrzebny jest obraz z aparatu wraz z nakładką ekranową, zapoznaj się z aktualnymi API Rokid AR Mix / nagrywania AR i dopasuj je do zainstalowanej wersji SDK.

Jeden praktyczny szczegół z FAQ Rokid jest istotny dla procesów dokumentowania dowodów: po udanym przesłaniu przez P2P zdjęcia na okularach mogą zostać usunięte przez system. Za wiążące źródło danych biznesowych uznawaj kopię pomyślnie odebraną przez telefon lub backend i potwierdzaj zakończenie przesyłania, zanim przejdziesz do kolejnego etapu zlecenia pracy.

Krok 13: Dodawaj głos, TTS i AI w przemyślany sposób

Głos może być cenny, gdy pracownicy nie mogą używać rąk, ale powinien być powiązany z konkretnymi działaniami w procesie. Dokumentacja SDK po stronie okularów udostępnia funkcje ASR, TTS, obsługi poleceń offline i czatu AI. Według aktualnego FAQ offline TTS wymaga SDK 2.2.0 lub nowszego, choć dziennik zmian wymienia usługę offline TTS od wersji 2.1.2 — przetestuj ją na przypiętej wersji. Otwarte rozpoznawanie mowy offline (ASR) nie jest obecnie domyślnie obsługiwane. W przypadku zamiany mowy na tekst offline Rokid kieruje programistów do prywatnych usług ASR/TTS, zamiast deklarować wbudowaną ścieżkę offline ASR.

Polecenia głosowe offline:

• Dobre zastosowanie: Krótkie, stałe polecenia, takie jak „dalej”, „wstecz”, „zrób zdjęcie”
• Uwaga projektowa dla firm: Dobre do deterministycznego sterowania bez użycia rąk

ASR online:

• Dobre zastosowanie: Swobodna zamiana mowy na tekst
• Uwaga projektowa dla firm: Wymaga konfiguracji sieci/usług i powinno mieć zachowanie awaryjne

TTS / offline TTS:

• Dobre zastosowanie: Odczytywanie komunikatów, ostrzeżeń lub krótkich potwierdzeń
• Uwaga projektowa dla firm: Przydatne, gdy wyświetlacz ma pozostać minimalistyczny

Czat AI / prywatna AI:

• Dobre zastosowanie: Pomoc kontekstowa lub interpretacja
• Uwaga projektowa dla firm: Model powinien pozostawać podporządkowany procesowi. Zweryfikuj obsługę danych, opóźnienia i granice odpowiedzi.

Krok 14: Bezpiecznie połącz proces z backendem

Kwestie związane z backendem są dwie: jak Twoja aplikacja komunikuje się z systemami biznesowymi oraz czy korzystasz z Rokid OpenAPI. Aplikacja może wysyłać dane przez sparowany telefon lub aplikacja na okulary może łączyć się z internetem bezpośrednio, gdy Glass3 są połączone z Wi-Fi. W przypadku systemów firmowych standardowe API backendu są zwykle najczystszym punktem integracji, ponieważ dane uwierzytelniające, logi audytowe, walidacja danych i reguły biznesowe pozostają po stronie serwera.

Rokid OpenAPI to osobna warstwa platformy. Oficjalna dokumentacja wymaga aktywowanego konta firmowego i klucza API. Żądania są uwierzytelniane tokenem Bearer, utworzone klucze wygasają, a domyślny okres ważności wynosi jeden miesiąc, chyba że skonfigurowano inaczej. Rokid wyraźnie ostrzega przed ujawnianiem kluczy API w publicznych repozytoriach lub aplikacjach klienckich.

Zasada bezpieczeństwa: Wszędzie tam, gdzie pozwala na to architektura, używaj serwerowego proxy dla danych uwierzytelniających platformy Rokid. Plik APK na telefon lub okulary można przeanalizować. Nie zakładaj, że ukrycie klucza API w kodzie Kotlin lub natywnym sprawia, że staje się on tajny.

Aktualne moduły Rokid OpenAPI obejmują m.in. API wiadomości i urządzeń, a także inne funkcje dla firm (uwaga: dostęp do API wiadomości i urządzeń jest możliwy tylko wtedy, gdy urządzenia są zarejestrowane w konsoli Lingmou firmy Rokid). Na przykład API urządzeń pozwala sprawdzać zarejestrowane egzemplarze Glass, a API wiadomości umożliwia wysłanie wiadomości biznesowej do wskazanego urządzenia. Korzystaj z tych usług tylko wtedy, gdy odpowiadają na rzeczywistą potrzebę wdrożeniową. Właściwym miejscem dla ERP, CMMS, CRM, zarządzania tożsamością i orkiestracji procesów pozostaje własny backend firmy.

Krok 15: Skonfiguruj zachowania dla firm, takie jak autostart i obsługa przycisków

Urządzenie noszone staje się bardziej przydatne w codziennej pracy, gdy użytkownik nie musi każdego ranka przechodzić przez launcher w stylu konsumenckim. Rokid dokumentuje mechanizm autostartu, który w obsługiwanych systemach dla firm może uruchamiać skonfigurowaną aplikację po starcie systemu. Dokumentuje też dostosowywanie zdarzeń sprzętowych, a w dzienniku zmian wersji 2.1.9-E — API do nasłuchiwania i przechwytywania zdarzeń.

Używaj autostartu w dedykowanych procesach inspekcyjnych, ochrony lub przemysłowych, w których okulary powinny otwierać się bezpośrednio w aplikacji biznesowej.

Po starcie systemu odczekaj chwilę z operacjami zależnymi od SDK i przed rozpoczęciem procesu sprawdź gotowość usług.

Przypisz obsługiwane zdarzenia przycisków do niewielkiej liczby znaczących działań, takich jak potwierdzenie, zrobienie zdjęcia czy anulowanie.

Weryfikuj każdą funkcję autostartu lub przechwytywania na docelowym oprogramowaniu układowym dla firm, ponieważ niektóre zachowania na poziomie systemu zależą od wersji.

Zawsze zachowuj ścieżkę wsparcia/odzyskiwania. Zablokowany proces, z którego administrator nie może wyjść, stanowi ryzyko operacyjne.

Krok 16: Zaprojektuj działanie offline, ponawianie prób i odzyskiwanie

Demo często zakłada idealne połączenie Bluetooth, Wi-Fi i dostęp do chmury. We wdrożeniu terenowym nie można tego zakładać. Zapisuj minimalny stan procesu potrzebny do przetrwania rozłączenia telefonu, awarii P2P lub chwilowego braku sieci. Każde działanie biznesowe powinno w miarę możliwości być idempotentne, aby ponowienie nie tworzyło zduplikowanych zdarzeń zleceń pracy ani rekordów multimediów.

Przechowuj w pamięci podręcznej identyfikator bieżącego zlecenia pracy, identyfikator kroku i ostatnie potwierdzone działanie.

Kolejkuj niewysłane wyniki z widocznym stanem „oczekuje na synchronizację”.

Używaj unikalnych identyfikatorów operacji, aby backend mógł bezpiecznie odrzucać duplikaty.

Najpierw przywracaj połączenie Bluetooth, a P2P odbudowuj tylko wtedy, gdy potrzebna jest transmisja o wysokiej przepustowości.

Nigdy nie oznaczaj kroku zależnego od multimediów jako wykonanego, dopóki nie zostanie potwierdzony odbiór kopii docelowej.

Zapewnij bezpieczne dla użytkownika rozwiązanie awaryjne na wypadek niedostępności ASR online lub AI. Stałe polecenia offline nadal mogą obsłużyć podstawową nawigację.

Krok 17: Testuj na prawdziwym sprzęcie z użyciem macierzy testów dla firm

Emulatory nie wystarczą w projekcie dla okularów, ponieważ optyka, zachowanie termiczne, Bluetooth, P2P, aparat, mikrofon i wygoda noszenia wpływają na działanie oprogramowania. Przetestuj cały system na dokładnie tej wersji OTA dla firm, która jest planowana na pilotaż.

• Uruchamianie i autostart: Zimny start, uruchomienie aplikacji, gotowość SDK, odzyskiwanie przy wolnym wiązaniu usługi
• Bluetooth: Pierwsze parowanie, ponowne połączenie, uśpienie telefonu, odzyskiwanie po wyjściu poza zasięg
• P2P: Wielokrotne łączenie/rozłączanie, duży plik, strumień na żywo, zmiany sieci Wi-Fi
• Uprawnienia: Świeża instalacja, odmowa uprawnienia, późniejsze przyznanie, różnice między wersjami Androida
• Multimedia: Jakość zdjęć/wideo, potwierdzenie odbioru pliku, ponowienie nieudanego przesyłania, czyszczenie pamięci
• Głos: Hałaśliwe otoczenie, brak sieci, nieobsługiwana fraza, przerwanie TTS
• Interfejs / optyka: Czytelność, górny obszar odbić, długi tekst, widoczność stanu, zmęczenie użytkownika
• Wydajność: Długa sesja, temperatura procesora, dostępna pamięć, przetrwanie procesu
• Backend: Wolna odpowiedź, zduplikowane żądanie, wygasły token, niedostępny serwer
• Bezpieczeństwo: Obsługa danych uwierzytelniających, maskowanie danych w logach, utrata urządzenia, odebranie dostępu do konta

FAQ Rokid wprost zaleca monitorowanie pamięci i temperatury procesora podczas diagnozowania problemów z wydajnością i ostrzega, że bardzo mała ilość dostępnej pamięci zwiększa prawdopodobieństwo zamknięcia procesów działających w tle. To kolejny powód, by aplikacja na okulary była skoncentrowana na najważniejszych zadaniach, a zbędne usługi zostały przeniesione gdzie indziej.

Krok 18: Przygotuj pilotaż i kontroluj bazową konfigurację wdrożenia

Podczas tworzenia oprogramowania pliki APK można instalować przez Android Studio za pomocą kabla do transmisji danych i debugowania Glass3. Wdrożenie produkcyjne wymaga bardziej rygorystycznego procesu wydawania. Rokid nie dokumentuje kontroli zasad w stylu MDM (takich jak tryb kiosku, zdalne czyszczenie czy zasady dotyczące aplikacji). Zamiast tego dokumentuje rejestrację urządzeń i śledzenie ich stanu za pomocą konsoli Lingmou i OpenAPI, a wersja 2.2.0-E umożliwia instalację plików APK przez aplikację skanującą kody QR. Przed zatwierdzeniem architektury wdrożenia uzgodnij z Rokid lub dystrybutorem mechanizm wdrażania, uprawnienia do provisioningu, oprogramowanie układowe dla firm i politykę aktualizacji.

1. Zamroź przetestowane wersje SDK i OTA na czas pilotażu.

1. Utwórz podpisane wydania APK aplikacji na okulary i telefon.

1. Udokumentuj identyfikatory klientów, nazwy pakietów i konfigurację środowisk backendu.

1. Udostępniaj klucze API i sekrety backendu przez bezpieczną infrastrukturę, a nie w kodzie źródłowym.

1. Określ, kto może aktualizować okulary, aplikację na telefon i backend oraz w jakiej kolejności.

1. Po każdej zmianie OTA lub SDK przeprowadzaj testy regresyjne, zanim zaktualizujesz flotę urządzeń.

1. Stwórz ścieżkę wsparcia obejmującą logi, identyfikację urządzeń, diagnostykę łączności i przywracanie poprzednich wersji.

Przykładowa architektura: dedykowana aplikacja do inspekcji w serwisie terenowym

Poniżej znajduje się praktyczny przykład projektu opartego na udokumentowanych funkcjach Rokid. Nie jest to gotowy proces oferowany przez Rokid. Przykład pokazuje, jak stos programistyczny może zamienić okulary w dedykowane urządzenie końcowe do zastosowań biznesowych.

1. Start. Działanie techniczne: aplikacja na okulary uruchamia się automatycznie i sprawdza gotowość SDK. Wartość biznesowa: pracownik zaczyna bezpośrednio w firmowym procesie.
2. Przydzielenie zadania. Działanie techniczne: telefon/backend wysyła podsumowanie zlecenia pracy w formie zwięzłej wiadomości. Wartość biznesowa: nie trzeba niczego ręcznie wyszukiwać w telefonie.
3. Prowadzenie. Działanie techniczne: okulary wyświetlają jedną instrukcję w centralnym obszarze ekranu. Wartość biznesowa: ręce pozostają wolne do wykonania zadania.
4. Potwierdzenie. Działanie techniczne: pracownik wypowiada stałe polecenie lub używa obsługiwanego zdarzenia sprzętowego. Wartość biznesowa: szybka, deterministyczna interakcja.
5. Rejestrowanie dowodów. Działanie techniczne: okulary robią zdjęcie lub nagrywają krótki klip. Wartość biznesowa: dowód wizualny zostaje dołączony do właściwego kroku.
6. Przesyłanie. Działanie techniczne: multimedia są przesyłane przez P2P; krótki komunikat o stanie potwierdza przesłanie. Wartość biznesowa: duże ilości danych nie obciążają kanału sterowania o niskiej przepustowości.
7. Synchronizacja. Działanie techniczne: telefon lub backend przesyła wynik do API systemu CMMS/ERP. Wartość biznesowa: istniejące systemy biznesowe pozostają nadrzędnym systemem ewidencji.
8. Wyjątek. Działanie techniczne: w razie potrzeby telefon odbiera strumień na żywo lub aplikacja uruchamia zatwierdzoną ścieżkę zdalnej pomocy. Wartość biznesowa: przełożony widzi to, co widzi pracownik.
9. Zakończenie. Działanie techniczne: backend potwierdza wykonanie i zwraca kolejne zadanie. Wartość biznesowa: użytkownik otrzymuje jasny stan końcowy, a ścieżka audytu jest kompletna.

Dlaczego dedykowane oprogramowanie zmienia uzasadnienie biznesowe dla Rokid AI Glasses Enterprise

Główna wartość dla firm wynika z dopasowania urządzenia do istniejącego procesu operacyjnego lub przeprojektowania tego procesu z myślą o pracy bez użycia rąk.

Interfejs zaprojektowany do konkretnych zadań: usunięcie menu konsumenckich i wyświetlanie tylko informacji wymaganych na bieżącym etapie pracy.

Integracja z systemami biznesowymi: powiązanie zarejestrowanych dowodów i działań pracowników z istniejącymi systemami ERP, CMMS, CRM lub własnymi platformami.

Rejestrowanie danych bez użycia rąk: korzystanie z aparatu, głosu i sterowania na okularach bez ciągłego sięgania po telefon czy tablet.

Kontrolowana łączność: Bluetooth dla poleceń i P2P dla danych wymagających dużej przepustowości, zamiast przepychania wszystkich funkcji przez jeden kanał.

Własne granice dla AI: wykorzystanie AI tam, gdzie wnosi wartość, przy zachowaniu kontroli firmy nad regułami procesów, uprawnieniami i zarządzaniem danymi.

Zachowanie dedykowanego urządzenia: autostart i obsługa zdarzeń mogą ograniczyć niedogodności we wdrożeniach jednozadaniowych, jeśli obsługuje je oprogramowanie układowe dla firm.

Rozszerzalna architektura: rozpoczęcie od lokalnego proof of concept, a następnie dodawanie integracji z backendem, API platformy, zdalnej współpracy lub specjalistycznych SDK w miarę dojrzewania procesu.

Argument zakupowy: Dla organizacji, które potrzebują standardowej, niezmiennej aplikacji, tworzenie dedykowanego oprogramowania może być zbędne. Dla organizacji, które chcą, aby okulary AI stały się częścią kontrolowanego procesu operacyjnego, to właśnie udokumentowane Glass3 SDK sprawia, że sprzęt staje się bardziej interesujący. Firma kupuje elastyczne urządzenie końcowe, a nie tylko wyświetlacz czy kamerę do noszenia.

Ograniczenia i ryzyka techniczne, które warto uwzględnić w planach

• SDK skoncentrowane na Androidzie: Publiczne Glass3 SDK jest przeznaczone dla natywnego Androida. Według FAQ Rokid iOS i natywny HarmonyOS nie są obsługiwane. Integracja z uni-app jest możliwa tylko poprzez zbudowanie własnego mostu do natywnego SDK dla Androida.
• Kompaktowy wyświetlacz: Pionowy obszar 480 x 640 nadaje się do zwięzłych komunikatów, a nie do gęstych pulpitów biznesowych. Dobry projekt procesu jest niezbędny.
• Niezgodności między SDK a dziennikiem zmian: Weryfikuj artefakty SDK, demo i OTA łącznie, biorąc pod uwagę różnice w wersjach między chińskim a angielskim dziennikiem zmian.
• Zależność od usług online: Wybrane funkcje ASR, AI i OpenAPI wymagają dostępu do sieci, firmowych danych uwierzytelniających lub udostępnienia usług.
• Brak otwartego ASR offline w aktualnym FAQ: Offline TTS i stałe polecenia offline mogą wspierać niezawodną interakcję, ale swobodna zamiana mowy na tekst offline nie jest obecnie udokumentowana jako funkcja wbudowana.
• Złożoność transmisji: Bluetooth i P2P rozwiązują różne problemy. Ponowne łączenie, uprawnienia i synchronizacja stanu wymagają inżynierii na poziomie produkcyjnym.
• Usunięcie RTC z podstawowego SDK: Rokid usunął połączenia RTC z podstawowego Phone SDK w wersji 2.1.7-E. Zdalna współpraca powinna korzystać z Remote Collaboration SDK firmy Rokid lub osobno opracowanego rozwiązania.
• Szczegóły wdrożenia wymagają weryfikacji: Publiczna dokumentacja SDK dobrze opisuje tworzenie oprogramowania, ale zarządzanie flotą w środowisku produkcyjnym i provisioning przez konsolę Lingmou lub aplikację skanującą kody QR należy potwierdzić dla środowiska klienta przed skalowaniem.

Zalety i wady tworzenia dedykowanego oprogramowania dla firm

Zalety:

• Natywny model tworzenia aplikacji na Androida
• Publiczne artefakty Maven
• Oficjalne demo dla okularów + telefonu
• Bluetooth i P2P
• Wiadomości/pliki/multimedia
• Aparat i podgląd na żywo
• Usługi głosowe/AI/rozpoznawania
• Możliwość bezpośredniego połączenia Wi-Fi
• OpenAPI dla firm
• Możliwości autostartu i dostosowywania zdarzeń.

Wady:

• Natywne SDK obsługujące wyłącznie Androida
• Kompaktowy, stały wyświetlacz
• Konieczność koordynacji wersji/OTA
• Wybrane funkcje online wymagają dostępu dla firm
• Ograniczenia ASR offline
• Szczegóły provisioningu w środowisku produkcyjnym/zarządzania flotą wymagają potwierdzenia dla konkretnego projektu.

Ostateczna ocena

Rokid AI Glasses Enterprise warto rozważyć, gdy celem firmy jest zbudowanie dedykowanego procesu pracy bez użycia rąk, a nie wdrożenie ogólnej aplikacji konsumenckiej. Obecny stos Glass3 dla firm zapewnia programistom Androida udokumentowaną ścieżkę tworzenia aplikacji na okulary, parowania ich z telefonem z Androidem, przesyłania danych sterujących przez Bluetooth, przesyłania multimediów przez Wi-Fi P2P oraz łączenia procesu z systemami backendowymi lub wybranymi usługami Rokid OpenAPI.

Najlepsze zastosowania to inspekcje z instrukcjami krok po kroku, serwis terenowy, rejestrowanie dowodów, prace proceduralne i inne zadania, w których pracownikowi pomaga widok jednej instrukcji naraz przy zachowaniu obu rąk wolnych. Głównym ograniczeniem nie jest brak API, lecz dyscyplina inżynierska wymagana w związku z małym wyświetlaczem, stanem łączności, uprawnieniami, kompatybilnością SDK/OTA i zależnością od usług online.

Dla kupującego po stronie biznesu kluczowe pytanie brzmi: „Czy możemy odwzorować nasz proces w udokumentowanym stosie programistycznym i czy jesteśmy w stanie wspierać aplikację przez cały jej cykl życia?”. Jeśli odpowiedź brzmi „tak”, dedykowane oprogramowanie pozwala przekształcić Rokid Glass3 z uniwersalnych okularów AI w urządzenie operacyjne zaprojektowane do konkretnych zadań.

Firmom rozważającym Rokid AI Glasses Enterprise do inspekcji, serwisu terenowego, logistyki, pracy z instrukcjami krok po kroku lub dedykowanych procesów AI, VR Expert może pomóc w ocenie sprzętu, zdefiniowaniu proof of concept i weryfikacji ścieżki wdrożenia. Odwiedź stronę produktu Rokid AI Glasses Enterprise, aby zapoznać się z urządzeniem, dostępnością i opcjami zakupu. W sprawie określenia zakresu prac nad dedykowanym oprogramowaniem lub doradztwa przy wdrożeniu skontaktuj się z VR Expert.