So entwickeln Sie individuelle Software für Rokid AI Glasses Enterprise

Zusammenfassung

Rokid AI Glasses Enterprise lässt sich zu einem zweckgebundenen Business-Gerät ausbauen, statt nur mit vorkonfigurierten Anwendungen genutzt zu werden. Die aktuelle Sprite-Enterprise-Dokumentation von Rokid stellt ein Glasses SDK für Anwendungen bereit, die direkt auf Glass3 laufen, ein Phone SDK für Android-Begleit-Apps sowie OpenAPI-Dienste für cloudseitige Integrationen. Zusammen unterstützen diese Ebenen Gerätekonnektivität, Messaging, Dateiübertragung, Kamera- und Medienaufnahme, Live-Video, Sprachfunktionen, KI-Dienste, Erkennung, Gerätestatus und Enterprise-Workflows.

Für ein Entwicklungsteam ist der praktische Weg vertraut: native Android-Projekte in Android Studio erstellen, Rokids Maven-Repository und die SDK-Abhängigkeiten hinzufügen, die offizielle Zwei-Projekt-Demo von Rokid ausführen, Bluetooth für Erkennung und Steuerung einrichten, für große Dateien sowie Audio/Video auf Wi-Fi P2P wechseln und anschließend den Workflow mit dem Backend des Unternehmens verbinden. Eine eigenständige Brillen-App ist ebenfalls möglich, wenn der Anwendungsfall kein Begleit-Smartphone erfordert.

Über das SDK hinaus entsteht der Hauptnutzen dadurch, dass ein generisches Wearable-Erlebnis durch einen kontrollierten Workflow ersetzt wird. Ein Techniker kann einen Arbeitsauftrag empfangen, die nächste Anweisung im Display sehen, einen Schritt per Sprache oder Hardware-Eingabe bestätigen, visuelle Nachweise erfassen und das Ergebnis an ein CMMS, ERP oder eine individuelle Plattform senden. Damit wird die Brille relevant für Inspektionen, Außendienst, angeleitete Arbeit, Logistik, Dokumentation und andere freihändige Prozesse. Die wichtigsten Einschränkungen sind die ausschließliche Unterstützung des nativen SDK für Android, Versions- und OTA-Kompatibilität, API-Key-Anforderungen für ausgewählte Online-Dienste sowie ein kompaktes 480 x 640-Display, das ein durchdachtes UI-Design erfordert.

Was Rokid Entwicklern zur Verfügung stellt

Rokid unterteilt den Enterprise-Stack in ein zweiseitiges SDK und eine separate OpenAPI-Plattform. Wer diese Aufteilung versteht, bevor er Code schreibt, vermeidet einen häufigen Fehler: die Brille alles erledigen lassen zu wollen, obwohl ein Smartphone oder Backend besser für Netzwerk, Authentifizierung, Speicherung oder die Integration von Geschäftssystemen geeignet ist.

Brillen-Anwendung:

• Läuft auf: Rokid Glass3
• Typische Aufgabe: Stellt die Wearable-Oberfläche dar und greift über das Glasses SDK auf brillenseitige Funktionen wie Kamera/Medien, Gerätestatus, Nachrichten, Sprache, KI und Erkennung zu.

Begleit-Anwendung:

• Läuft auf: Android-Smartphone
• Typische Aufgabe: Erkennt Glass3 und verbindet sich damit, verwaltet Bluetooth und Wi-Fi P2P, tauscht Nachrichten/Dateien aus, empfängt Medienstreams und kann Geschäftsdaten weiterleiten.

Cloud-/Geschäftsebene:

• Läuft auf: Ihrem Backend + Rokid OpenAPI, sofern relevant
• Typische Aufgabe: Speichert Geschäftsdaten, authentifiziert Benutzer, bindet ERP-/CMMS-/CRM-Systeme an und kann nach entsprechender Bereitstellung Rokid-OpenAPI-Module wie Messaging- oder Geräte-APIs nutzen.

Praktisches Fazit: Für individuelle Unternehmenssoftware ist die sinnvolle Architektur in der Regel „schlanke Wearable-Oberfläche + zuverlässige Gerätedienste + Geschäftslogik auf Smartphone/Backend“. Ein fokussiertes Brillen-Erlebnis reduziert die UI-Komplexität und erleichtert die Wartung des Projekts, während die freihändige Interaktion dort erhalten bleibt, wo sie wichtig ist.

Der Entwicklungs-Stack im Überblick

• Zielhardware laut öffentlicher Enterprise-Dokumentation: Rokid Glass3
• Entwicklungsmodell: Native Android-Anwendungsentwicklung
• Glasses-SDK-Artefakt: com.rokid.security:glass3.open.sdk
• Phone-SDK-Artefakt: com.rokid.security:phone.sdk
• Im aktuellen Quick Start angegebene Abhängigkeit: 2.2.0-E für beide SDKs
• Neuester sichtbarer Changelog-Eintrag zum Zeitpunkt der Recherche: V2.2.0-E vom 6. August 2026 mit empfohlener OTA 1.19.e006-20260806-150201 oder neuer.
• Empfohlene Tools: Android Studio 2022+, JDK 17+
• Demo-Umgebung: Android SDK 34, JDK 17, Android-Smartphone, Rokid Glass3
• Koordinatensystem des Brillendisplays: Fest 480 x 640, Hochformat
• Primäre lokale Übertragungswege: Classic Bluetooth und Wi-Fi P2P
• Cloud-Authentifizierung: Enterprise-API-Key für Rokid OpenAPI und ausgewählte Online-Dienste
• Unterstützte Smartphone-Plattform: Android; laut öffentlicher FAQ werden iOS und natives HarmonyOS vom Glass3 SDK nicht unterstützt

Was lässt sich mit Rokid AI Glasses Enterprise entwickeln?

Das öffentliche SDK ist umfangreich genug, um mehr als nur eine einzelne Demo-Anwendung zu ermöglichen. Welches Produkt Sie genau entwickeln, hängt davon ab, welche Funktionen Sie kombinieren und wie viel Logik Sie auf dem Wearable belassen.

Angeleiteter Außendienst: jeweils eine Anweisung anzeigen, den Abschluss bestätigen, Fotos oder Videos aufnehmen und strukturierte Nachweise an ein Arbeitsauftragssystem zurückgeben.

Inspektion und Compliance: Checklisten anzeigen, Kameraaufnahme oder Erkennung nutzen, Nachweise mit Zeitstempel anhängen und Abweichungen eskalieren.

Lager- und Logistik-Workflows: Kommissionier- oder Aufgabeninformationen anzeigen, schlanke Befehle über Bluetooth austauschen und bei Bedarf spezialisierte Scan-Integrationen nutzen.

Visuelle Fernunterstützung: einen Live-Videostream auf der Begleitseite empfangen oder einen eigenen Pfad für die Fernzusammenarbeit integrieren. Rokid hat RTC-Anrufe in Version 2.1.7-E aus dem Kern-Phone-SDK entfernt. Echtzeit-Zusammenarbeit sollte daher auf Android und Web aufgebaut werden – über Rokids Remote Collaboration SDK oder Ihren eigenen freigegebenen Übertragungsweg –, statt davon auszugehen, dass sie im Basis-SDK enthalten ist.

Enterprise-KI-Assistent: Spracheingabe, TTS, KI-Chat oder unternehmenseigene KI-Dienste mit einer workflowspezifischen Oberfläche kombinieren, statt die Nutzer mit einem generischen Chatbot zu konfrontieren.

Nachweiserfassung und Dokumentation: Bild-, Video- oder Audioaufnahmen auslösen, größere Mediendateien über P2P übertragen und Ergebnisse mit einem Backend synchronisieren.

Dediziertes Einzweck-Wearable: die Unternehmensanwendung nach einem Neustart automatisch starten und unterstützte Hardware-Ereignisse Workflow-Aktionen zuordnen – vorbehaltlich einer Validierung auf der Ziel-Firmware.

Schritt für Schritt: So entwickeln Sie individuelle Software für Rokid AI Glasses Enterprise

Schritt 1: Den Workflow definieren, bevor die Architektur gewählt wird

Beginnen Sie mit dem betrieblichen Prozess, nicht mit der SDK-Liste. Halten Sie genau fest, was die Mitarbeitenden sehen, sagen, erfassen und bestätigen müssen. Entscheiden Sie dann, welches Gerät für welche Aufgabe zuständig sein soll. Eine sinnvoll abgegrenzte Wearable-Anwendung zeigt in der Regel knappe Informationen an und erfasst Eingaben, während das Smartphone oder Backend die aufwendigere Geschäftslogik übernimmt.

Eigenständige Brillen-App:

• Am besten geeignet für: Einfache lokale Workflows, geräteseitige Erfassung, Betrieb offline oder bei eingeschränkter Konnektivität
• Vorteile: Weniger Komponenten, direktes Wearable-Erlebnis
• Kompromiss: Mehr Speicher-/Netzwerklogik muss auf der Brille umgesetzt werden; einige Online-Funktionen benötigen weiterhin Zugangsdaten oder Konnektivität

Brille + Android-Smartphone:

• Am besten geeignet für: Die meisten Enterprise-Pilotprojekte, Live-Medien, Dateiübertragung, Fernsteuerung, Begleit-App für Geschäftsanwendungen
• Vorteile: Am besten dokumentierter Konnektivitätspfad; das Smartphone kann Authentifizierung, Netzwerk und Oberflächen übernehmen, die nicht ins Brillendisplay gehören
• Kompromiss: Erfordert ein Android-Smartphone und eine robuste Logik für Wiederverbindungen

Brille + Smartphone + Backend:

• Am besten geeignet für: ERP-/CMMS-/CRM-Integration, Audit-Trail, zentral verwaltete Arbeitsaufträge, KI-Dienste
• Vorteile: Am besten geeignet für skalierbare Geschäfts-Workflows und Data Governance
• Kompromiss: Mehr Aufwand für Integration, Sicherheit und Backend-Entwicklung

Empfehlung: Verwenden Sie für einen ersten B2B-Proof-of-Concept das Modell Brille + Android-Smartphone + Backend, sofern der Anwendungsfall nicht eindeutig von einem eigenständigen Wearable profitiert. Es entspricht weitgehend dem dokumentierten Zwei-Geräte-Ablauf von Rokid und gibt dem Entwicklungsteam Spielraum, Netzwerk, Zugangsdaten und Datenspeicherung von der Brille auszulagern.

Schritt 2: Die richtige Hardware und die nötigen Zugänge beschaffen

Prüfen Sie vor der Installation von Android Studio, ob die Hardware tatsächlich auf dem Enterprise-Softwarepfad läuft. Laut Rokids FAQ enthalten Enterprise-/Work-Builds in der Regel ein „e“ in der Systemversion. Auch die SDK-Dokumentation unterscheidet zwischen Enterprise- und Consumer-Systemen; die Identifizierung der Firmware ist daher Teil der Projekteinrichtung und kein nachträglicher Gedanke.

Rokid AI Glasses Enterprise (die Rokid-Glasses-Hardware) mit Enterprise-System-Build/-Firmware (Systemversion mit „e“ am Ende).

Das Glass3-Daten-Debug-Kabel. Rokid weist ausdrücklich darauf hin, dass das normale Ladekabel die Brille zwar mit Strom versorgen, von Android Studio aber nicht zum Debuggen genutzt werden kann.

Ein Android-Smartphone, wenn Sie das Phone SDK verwenden.

Ein Entwicklungs-PC mit Android Studio und JDK 17.

Ein Enterprise-Konto und ein API-Key, wenn das Projekt Rokid OpenAPI oder Online-Funktionen nutzen soll, die eine Authentifizierung erfordern.

Zugriff auf genau die OTA-Version, die Sie in der gesamten Pilotflotte einsetzen möchten.

Überspringen Sie die Kabelprüfung nicht: Rokid führt das Daten-Debug-Kabel als erforderlich auf, da es Android Studio ermöglicht, die Brille zu erkennen, APKs zu installieren und Logs einzusehen. Wenn die Brille lädt, aber nicht als Gerät erscheint, prüfen Sie das Kabel, bevor Sie Gradle, ADB oder das SDK debuggen.

Schritt 3: Die Android-Entwicklungsumgebung vorbereiten

Rokids Quick Start empfiehlt Android Studio 2022 oder neuer sowie JDK 17 oder neuer und gibt an, dass das Glass3 SDK Android 8.0 oder neuer unterstützt. Der offizielle Demo-Leitfaden verwendet derzeit Android SDK 34. Rokids FAQ empfiehlt an anderer Stelle Android 7.0 / API 24 oder neuer und rät, die Gradle-Konfiguration im aktuellen SDK-Paket und in der Demo zu prüfen. Behandeln Sie bei einem echten Projekt die Gradle-Dateien der Demo als maßgebliche Quelle für das genaue Release, das Sie integrieren.

1. Installieren Sie Android Studio 2022 oder neuer.

1. Installieren Sie JDK 17 oder neuer und wählen Sie es für Gradle aus.

1. Installieren Sie die Android-SDK-Version, die die aktuelle Rokid-Demo voraussetzt. Der derzeitige Demo-Leitfaden nennt SDK 34.

1. Aktivieren Sie das normale Android-Debugging auf dem Entwicklungs-Smartphone.

1. Verbinden Sie Glass3 über das Daten-Debug-Kabel und prüfen Sie, ob Android Studio ein Zielgerät ähnlich „Rokid RG-glasses“ erkennt.

1. Installieren Sie Rokids Tool zur Bildschirmprojektion/-spiegelung, wenn Sie die Wearable-Oberfläche vom PC aus prüfen möchten. Rokid empfiehlt die Projektion während der Entwicklung ausdrücklich.

Schritt 4: Rokids offizielle Demo ausführen, bevor Sie eine eigene Anwendung erstellen

Dies ist der wichtigste praktische Schritt im gesamten Prozess. Die offizielle Demo bestätigt Entwicklungsumgebung, SDK-Binärdateien, Berechtigungen, Hardwareverbindungen und Versionskombination, bevor Ihr eigener Code als weitere Variable hinzukommt.

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

# Brillen-Demo
cd glassdemo
./gradlew assembleDebug

# Smartphone-Demo
cd ../glass3sdkphonedemo
./gradlew assembleDebug

Das Repository enthält zwei separate Android-Projekte: eines für die Brille und eines für das Android-Smartphone. Rokid empfiehlt, zuerst die smartphoneseitige Demo und dann die brillenseitige Demo auszuführen. Sobald beide installiert sind, suchen Sie in der Smartphone-Demo nach Glass3 und stellen die Verbindung her.

1. SDK-Initialisierung. Erfolgskriterium: Beide Projekte starten und melden einen gültigen SDK-Status.
2. Bluetooth. Erfolgskriterium: Das Smartphone findet Glass3 und verbindet sich damit.
3. Messaging. Erfolgskriterium: Text- oder Steuernachrichten können zwischen Smartphone und Brille übertragen werden.
4. Übertragung kleiner Dateien. Erfolgskriterium: Eine kleine Datei lässt sich fehlerfrei austauschen.
5. Wi-Fi P2P. Erfolgskriterium: Für bandbreitenintensive Vorgänge kann ein P2P-Kanal aufgebaut werden.
6. Medien. Erfolgskriterium: Foto, Video oder Live-Vorschau lassen sich auslösen und empfangen.

Warum das wirtschaftlich wichtig ist: Ein Proof of Concept für Kunden lässt sich deutlich leichter abgrenzen, wenn die grundlegenden Gerätefunktionen zuerst validiert werden. Die Projektzeit kann dann in den eigentlichen Workflow, die Integration und die Benutzererfahrung fließen, statt in die Fehlersuche bei einem ungeprüften SDK-Setup.

Schritt 5: Eigene Projekte erstellen und Rokids Maven-Repository hinzufügen

Sobald die Demo funktioniert, erstellen oder öffnen Sie Ihre eigenen Android-Projekte. Rokid veröffentlicht die SDK-Artefakte über sein Maven-Repository. Fügen Sie das Repository neben Google und Maven Central hinzu und ergänzen Sie dann die Brillen-Abhängigkeit in der Wearable-App und die Smartphone-Abhängigkeit in der Begleit-App.

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

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

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

Rokids aktueller Quick Start zeigt Version 2.2.0-E mit einer empfohlenen OTA von 1.19.e006-20260806-150201 oder neuer. Enterprise-Teams sollten eine bekannte Kombination aus SDK und OTA festschreiben und testen, statt Komponenten automatisch und unabhängig voneinander zu aktualisieren.

Regel zur Versionskontrolle: Halten Sie vor einem Pilot- oder Produktionsrelease den OTA-Build der Brille, die Glasses-SDK-Version, die Phone-SDK-Version, den Demo-Commit und alle Versionen spezialisierter SDKs in einer gemeinsamen Kompatibilitätsmatrix fest. Wiederholen Sie die grundlegenden Verbindungs- und Medientests, sobald sich eine dieser Komponenten ändert.

Schritt 6: Nur die Android-Berechtigungen deklarieren, die Ihr Workflow benötigt

Rokids Quick Start nennt gängige Berechtigungen für Netzwerkzugriff, WLAN, Kamera, Mikrofon, Speicher, Bluetooth und Geräte in der Nähe. Unter modernen Android-Versionen reicht es bei gefährlichen Berechtigungen nicht aus, sie im Manifest zu deklarieren. Ihre Smartphone- und Brillen-Apps müssen die erforderlichen Berechtigungen zur Laufzeit anfordern und eine Ablehnung sauber behandeln.

• Bluetooth-Scan/-Verbindung: Geräteerkennung, Kopplung, kleine Nachrichten und Steuerung
• WLAN in der Nähe / Wi-Fi Direct: P2P-Verbindung für Dateien, Bilder, Videos und Echtzeitstreams
• Kamera: Foto-/Videoaufnahme und visuelle Erkennungsabläufe
• Mikrofon: Audioaufnahme, ASR und Sprachinteraktion
• Netzwerk / Internet: Backend-APIs, Rokid-Online-Dienste, Cloud-Synchronisierung
• Speicher: Umgang mit Medien und übertragenen Dateien, je nach Verhalten der Ziel-Android-Version bzw. des SDK

Hinweis für die Produktion: Kopieren Sie nicht blind das gesamte Demo-Manifest. Eine Minimierung der Berechtigungen erleichtert die Sicherheitsprüfung und verringert die Wahrscheinlichkeit, dass Nutzer eine Berechtigung ablehnen, die der Workflow gar nicht benötigt.

Schritt 7: Das Glasses SDK initialisieren und die App-Identität registrieren

Die Brillen-Anwendung bindet sich an den Sicherheitsdienst von Rokid und registriert anschließend eine Client-ID. Die wichtige Architekturregel lautet: Dieselbe Client-ID muss der Begleit-App auf dem Smartphone bekannt sein, wenn beide Seiten anwendungsspezifische Nachrichten austauschen.

// Veranschaulichende Struktur, vereinfacht nach Rokids Initialisierungsablauf
if (!GlassSdk.isReady()) {
    GlassSdk.bindSecurityService(context, object : IServiceConnectionCallback {
        override fun onServiceConnected() {
            GlassSdk.registerClient("FieldServiceApp", messageCallback)
        }
    })
}

Nach der Initialisierung wird über Service-Einstiegspunkte, die GlassSdk bereitstellt, auf brillenseitige Funktionen zugegriffen. Zu den öffentlichen API-Gruppen gehören allgemeine/Gerätefunktionen, Classic Bluetooth, P2P, Messaging, Medien, Dateiverarbeitung, Sprache/KI, Erkennung und weitere Dienste. Initialisieren Sie nicht alle Funktionen beim Start. Rufen Sie nur die Dienste ab und aktivieren Sie nur diejenigen, die für den aktuellen Bildschirm oder Workflow-Schritt erforderlich sind.

Statusprüfung: Verwenden Sie GlassSdk.isReady() als einfaches Diagnosesignal, bevor Sie Funktionsdienste aufrufen. Liefert es false, beheben Sie zunächst Probleme mit der Initialisierung oder der Service-Bindung, bevor Sie übergeordnete Funktionen testen.

Schritt 8: Das Android Phone SDK mit passenden Client-IDs initialisieren

Initialisieren Sie auf der Smartphone-Seite die Rokid Mobile Engine und registrieren Sie die Client-IDs, mit denen das Smartphone kommunizieren soll. Rokids Phone SDK ist die Verbindungs- und Steuerungsebene für Geräteerkennung, Bluetooth/P2P, Messaging, Dateien, Medienempfang, Konfigurationssynchronisierung und verwandte Vorgänge.

// Grundgerüst auf Application-Ebene
val engineParam = EngineParam.Builder()
    .setClientIds(listOf("FieldServiceApp"))
    .setApiKeyCredentials(apiKeyCredentials)
    .build()
IMobileEngine.initSDK(engineParam)

// Diagnoseprüfung
val ready = PSecuritySDK.getMobileEngineService().isInit()

Wenn ausgewählte Online-Funktionen API Key Credentials erfordern, enthält die Demo Platzhalter-Authentifizierungsdaten, die durch Zugangsdaten ersetzt werden müssen, die Sie über Rokids Geschäftsprozess erhalten. Halten Sie Cloud-Geheimnisse aus der Versionsverwaltung heraus und vermeiden Sie es, langlebige Plattform-API-Keys in eine verteilbare Client-Anwendung einzubetten.

Schritt 9: Zuerst über Bluetooth verbinden, dann P2P für Bandbreite nutzen

Rokid dokumentiert zwei lokale Übertragungsmuster mit unterschiedlichen Aufgaben. Classic Bluetooth eignet sich für Erkennung, Verbindungsaufbau, Steuernachrichten und kleine Dateien. Wi-Fi P2P ist der bessere Kanal für Bilder, große Dateien, Videos und Echtzeitmedien. Wer den falschen Übertragungsweg wählt, erhält leicht eine Anwendung, die in der Demo funktioniert, sich im Außeneinsatz aber unzuverlässig anfühlt.

Classic Bluetooth:

• Verwenden für: Erkennung, Kopplung, Steuerbefehle, kompakte JSON-Nachrichten, kleine Dateien
• Rolle im Design: Steuerungsebene mit geringer Bandbreite

Wi-Fi P2P:

• Verwenden für: Große Dateien, Bilder, Videos, Audio-/Videostreams, Synchronisierung mit hohem Durchsatz
• Rolle im Design: Datenebene mit hoher Bandbreite

Direktes WLAN der Brille:

• Verwenden für: Backend-Zugriff aus einer Brillen-Anwendung, wenn das Gerät mit einem WLAN verbunden ist
• Rolle im Design: Nützlich für ausgewählte eigenständige Abläufe; Offline- und Wiederholungsverhalten trotzdem einplanen

Eine robuste Enterprise-App sollte Verbindungen als Zustandsautomaten behandeln statt als einmalige Ereignisse. Behandeln Sie Bluetooth-Verlust, P2P-Abbau, Ruhezustand des Smartphones, WLAN-Wechsel und Neustarts der Brille explizit. Nutzer sollten einen einfachen Status wie „Verbindung wird wiederhergestellt“ oder „Synchronisierung ausstehend“ sehen – keine Android-Exception und keinen stillen Fehler.

Schritt 10: Ein kleines Anwendungsprotokoll für Geschäftsnachrichten definieren

Rokid stellt die Übertragungs- und Nachrichtendienste bereit, doch Ihre Anwendung benötigt trotzdem eine Vereinbarung darüber, was eine Geschäftsnachricht bedeutet. Halten Sie diese Vereinbarung kompakt, versioniert und unabhängig von der Oberfläche. JSON ist für frühe Projekte eine praktische Wahl, weil es sich leicht prüfen lässt – das genaue Payload-Format ist jedoch eine Designentscheidung Ihrer Anwendung und keine Vorgabe von Rokid.

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

Nach Abschluss könnte die Brille eine kleine Statusnachricht zurücksenden, die auf die Arbeitsauftrags-ID und die Schrittnummer verweist. Die Mediendatei selbst sollte über den P2P-Datei-/Medienpfad übertragen werden, statt in die Steuernachricht eingebettet zu werden. Diese Trennung hält den Befehlskanal reaktionsschnell und vereinfacht Wiederholungsversuche.

Schritt 11: Die Brillen-Oberfläche für 480 x 640 gestalten, nicht wie eine Smartphone-App

Das Glass3-Display verwendet ein festes Koordinatensystem von 480 x 640 im Hochformat. Rokids FAQ empfiehlt, Hauptinhalte im zentralen Bereich von 480 x 400 zu platzieren, die oberen 160 Pixel und die unteren 80 Pixel für sekundäre Informationen zu nutzen und wichtige Inhalte nach unten zu verschieben, da in den oberen etwa 40 Pixeln optische Reflexionen auftreten können. Das Betriebssystem bietet keine normale Bildschirmdrehung, daher müssen breite Layouts innerhalb der Hochformat-Fläche gestaltet werden.

Zeigen Sie jeweils nur eine Aufgabe, Anweisung oder Entscheidung an. Lange Dashboards passen schlecht zum Brillendisplay.

Verwenden Sie nach Möglichkeit einen schwarzen Hintergrund. Rokid empfiehlt dies, um wahrgenommenes Flackern beim Start oder bei Übergängen zu verringern.

Platzieren Sie keine wichtigen Texte oder Schaltflächen im Reflexionsbereich der oberen ca. 40 px.

Machen Sie Zustandsänderungen deutlich erkennbar, ohne sich auf komplexe Farbcodierungen zu verlassen. Rokid empfiehlt Grün als primären visuellen Stil.

Sorgen Sie für einen klar erkennbaren Verbindungsstatus und einen eindeutigen Status „synchronisiert / ausstehend“ für Geschäftsdaten.

Halten Sie Interaktionsziele so einfach, dass sie sich mit unterstützten Hardware-Eingaben oder per Sprache bedienen lassen, ohne präzise Touch-Navigation zu erzwingen.

Auswirkung auf das Geschäft: Das Display ist klein, doch das kann bei prozeduraler Arbeit ein Vorteil sein. Es ermutigt Softwareteams, nicht wesentliche Informationen zu entfernen und nur die nächste Aktion anzuzeigen, die die Mitarbeitenden benötigen.

Schritt 12: Kamera-, Foto-, Video- und Live-Vorschau-Funktionen hinzufügen

Das Glasses SDK stellt Medienfunktionen für Foto, Video, Audio und Vorschau bereit. Das Phone SDK kann Medienstreams von der Brille empfangen. Rokids FAQ nennt einen Standard-Videostream in 1080P mit etwa 15 bis 19 Bildern pro Sekunde und rund 300 ms Wiedergabelatenz auf dem Smartphone und weist darauf hin, dass die Ausgabe je nach API und Demo-Pfad H.264 oder dekodiertes NV21 sein kann. Betrachten Sie diese Werte als aktuelle Implementierungshinweise und nicht als garantiertes SLA.

Nutzen Sie Einzelbildaufnahmen für Inspektionsnachweise, Abschlussbelege und spätere KI-Verarbeitung.

Verwenden Sie H.264, wenn das Smartphone oder Backend den Stream hauptsächlich weiterleiten oder speichern muss. Mit dem Changelog 2.1.8-E hat Rokid eine Steuerung der automatischen H.264-zu-NV21-Dekodierung eingeführt, sodass unnötige Dekodierung vermieden werden kann.

Verwenden Sie NV21, wenn eine Computer-Vision-Pipeline auf dem Smartphone dekodierte Frames benötigt.

Nutzen Sie für Live-Vorschau und Medienübertragung Wi-Fi P2P statt Classic Bluetooth.

Wenn Sie in der Aufnahme Kamerabild plus Bildschirm-Overlay benötigen, prüfen Sie Rokids aktuelle AR-Mix-/AR-Recording-APIs und stimmen Sie sie auf die installierte SDK-Version ab.

Ein praktisches Detail aus Rokids FAQ ist für Nachweis-Workflows wichtig: Nach einem erfolgreichen P2P-Upload können Bilder auf der Brille vom System gelöscht werden. Betrachten Sie die erfolgreich empfangene Kopie auf dem Smartphone oder im Backend als maßgebliche Geschäftsquelle und bestätigen Sie den Abschluss des Uploads, bevor Sie den Arbeitsauftrag fortsetzen.

Schritt 13: Sprache, TTS und KI gezielt einsetzen

Sprache kann wertvoll sein, wenn Mitarbeitende ihre Hände nicht benutzen können, sollte aber an explizite Workflow-Aktionen gekoppelt sein. Die brillenseitige SDK-Dokumentation stellt ASR, TTS, Offline-Befehlsverarbeitung und KI-Chat-Funktionen bereit. Laut aktueller FAQ erfordert Offline-TTS SDK 2.2.0 oder neuer, obwohl der Changelog den Offline-TTS-Dienst bereits ab 2.1.2 aufführt; testen Sie dies mit Ihrer festgeschriebenen Version. Offene Offline-ASR wird derzeit standardmäßig nicht unterstützt. Für Offline-Spracherkennung verweist Rokid Entwickler auf private ASR-/TTS-Dienste, statt einen integrierten Offline-ASR-Pfad anzugeben.

Offline-Befehlswörter:

• Sinnvoller Einsatz: Kurze feste Befehle wie „weiter“, „zurück“, „aufnehmen“
• Hinweis zum Enterprise-Design: Gut geeignet für deterministische freihändige Steuerung

Online-ASR:

• Sinnvoller Einsatz: Freie Sprache-zu-Text-Umwandlung
• Hinweis zum Enterprise-Design: Erfordert Netzwerk-/Dienst-Einrichtung und sollte ein Fallback-Verhalten haben

TTS / Offline-TTS:

• Sinnvoller Einsatz: Vorlesen von Hinweisen, Warnungen oder kurzen Bestätigungen
• Hinweis zum Enterprise-Design: Nützlich, wenn das Display minimal bleiben soll

KI-Chat / private KI:

• Sinnvoller Einsatz: Kontextbezogene Unterstützung oder Interpretation
• Hinweis zum Enterprise-Design: Lassen Sie das Modell im Hintergrund des Workflows arbeiten. Validieren Sie Datenverarbeitung, Latenz und Antwortgrenzen.

Schritt 14: Den Workflow sicher mit Ihrem Backend verbinden

Beim Backend gibt es zwei getrennte Fragen: wie Ihre eigene Anwendung Ihre Geschäftssysteme erreicht und ob Sie Rokid OpenAPI nutzen. Ihre Anwendung kann Daten über das gekoppelte Smartphone senden, oder eine Brillen-Anwendung greift direkt auf das Internet zu, wenn Glass3 mit einem WLAN verbunden ist. Für Unternehmenssysteme sind Standard-Backend-APIs in der Regel der sauberste Integrationspunkt, weil Zugangsdaten, Audit-Logs, Datenvalidierung und Geschäftsregeln auf dem Server verbleiben.

Rokid OpenAPI ist eine separate Plattformebene. Die offizielle Dokumentation setzt ein aktiviertes Enterprise-Konto und einen API-Key voraus. Anfragen authentifizieren sich mit einem Bearer-Token, erstellte Keys laufen ab, und die Standardgültigkeit beträgt einen Monat, sofern nichts anderes konfiguriert ist. Rokid warnt ausdrücklich davor, API-Keys in öffentlichen Repositorys oder Clients offenzulegen.

Sicherheitsregel: Verwenden Sie für Rokid-Plattform-Zugangsdaten einen serverseitigen Proxy, wann immer die Architektur dies zulässt. Ein Smartphone- oder Brillen-APK kann untersucht werden. Gehen Sie nicht davon aus, dass ein API-Key geheim bleibt, nur weil er in Kotlin- oder nativem Code versteckt ist.

Zu den aktuellen Rokid-OpenAPI-Modulen gehören neben weiteren Enterprise-Funktionen Messaging- und Geräte-APIs (beachten Sie, dass auf diese Messaging- und Geräte-APIs nur zugegriffen werden kann, wenn die Geräte in Rokids Lingmou-Konsole registriert sind). So kann etwa die Geräte-API registrierte Glass-Einheiten abfragen, während die Nachrichten-API eine Geschäftsnachricht an ein Zielgerät senden kann. Nutzen Sie diese Dienste nur, wenn sie eine echte Anforderung des Einsatzes lösen. Ein eigenes Unternehmens-Backend bleibt der richtige Ort für ERP, CMMS, CRM, Identitätsmanagement und Workflow-Orchestrierung.

Schritt 15: Enterprise-Verhalten wie Autostart und Tastenbelegung konfigurieren

Ein Wearable wird im Betrieb nützlicher, wenn Nutzer sich nicht jeden Morgen durch einen Launcher im Consumer-Stil navigieren müssen. Rokid dokumentiert einen Autostart-Mechanismus, der auf unterstützten Enterprise-Systemen eine konfigurierte Anwendung nach dem Hochfahren starten kann. Außerdem dokumentiert Rokid die Anpassung von Hardware-Ereignissen sowie im Changelog 2.1.9-E APIs zum Abhören und Abfangen von Ereignissen.

Nutzen Sie Autostart für dedizierte Inspektions-, Sicherheits- oder Industrie-Workflows, bei denen die Brille direkt in der Geschäftsanwendung starten soll.

Verzögern Sie SDK-abhängige Vorgänge nach dem Hochfahren kurz und prüfen Sie die Bereitschaft der Dienste, bevor Sie den Workflow starten.

Ordnen Sie unterstützte Tastenereignisse einer kleinen Zahl sinnvoller Aktionen zu, etwa Bestätigen, Aufnehmen oder Abbrechen.

Validieren Sie jede Autostart- oder Abfangfunktion auf der Ziel-Enterprise-Firmware, da manches Verhalten auf Systemebene versionsabhängig ist.

Sehen Sie immer einen Support-/Wiederherstellungspfad vor. Ein gesperrter Workflow, den ein Administrator nicht verlassen kann, ist ein betriebliches Risiko.

Schritt 16: Offline-, Wiederholungs- und Wiederherstellungsverhalten entwickeln

Eine Demo setzt oft perfektes Bluetooth, WLAN und Cloud-Zugriff voraus. Ein Einsatz im Feld kann das nicht. Speichern Sie den minimalen Workflow-Zustand dauerhaft, der nötig ist, um eine Trennung vom Smartphone, einen P2P-Ausfall oder einen vorübergehenden Netzwerkausfall zu überstehen. Jede Geschäftsaktion sollte nach Möglichkeit idempotent sein, damit Wiederholungen keine doppelten Arbeitsauftragsereignisse oder Mediendatensätze erzeugen.

Speichern Sie die aktuelle Arbeitsauftrags-ID, die Schritt-ID und die zuletzt bestätigte Aktion im Cache.

Stellen Sie nicht gesendete Ergebnisse mit sichtbarem Status „Synchronisierung ausstehend“ in eine Warteschlange.

Verwenden Sie eindeutige Vorgangs-IDs, damit das Backend Duplikate sicher ablehnen kann.

Stellen Sie zuerst die Bluetooth-Verbindung wieder her und bauen Sie P2P nur dann neu auf, wenn eine Übertragung mit hoher Bandbreite erforderlich ist.

Markieren Sie einen medienabhängigen Schritt erst dann als abgeschlossen, wenn der Empfang der Zielkopie bestätigt wurde.

Bieten Sie einen nutzersicheren Fallback, wenn Online-ASR oder KI nicht verfügbar ist. Feste Offline-Befehle können die Kernnavigation weiterhin abdecken.

Schritt 17: Auf echter Hardware mit einer Enterprise-Testmatrix testen

Emulatoren reichen für ein Brillenprojekt nicht aus, weil Optik, thermisches Verhalten, Bluetooth, P2P, Kamera, Mikrofon und Tragekomfort allesamt das Softwareerlebnis beeinflussen. Testen Sie das Gesamtsystem auf genau der Enterprise-OTA, die für das Pilotprojekt vorgesehen ist.

• Hochfahren und Autostart: Kaltstart, App-Start, SDK-Bereitschaft, Wiederherstellung bei langsamer Service-Bindung
• Bluetooth: Erstkopplung, Wiederverbindung, Ruhezustand des Smartphones, Wiederherstellung nach Verlassen der Reichweite
• P2P: Wiederholtes Verbinden/Trennen, große Datei, Livestream, WLAN-Wechsel
• Berechtigungen: Neuinstallation, verweigerte Berechtigung, spätere Erteilung, Unterschiede zwischen Android-Versionen
• Medien: Foto-/Videoqualität, Empfangsbestätigung für Dateien, Wiederholung fehlgeschlagener Uploads, Speicherbereinigung
• Sprache: Laute Umgebung, kein Netzwerk, nicht unterstützte Formulierung, Unterbrechung der TTS
• UI / Optik: Lesbarkeit, oberer Reflexionsbereich, lange Texte, Sichtbarkeit des Status, Ermüdung der Nutzer
• Leistung: Lange Sitzungen, CPU-Temperatur, verfügbarer Arbeitsspeicher, Überleben von Prozessen
• Backend: Langsame Antwort, doppelte Anfrage, abgelaufenes Token, Server nicht erreichbar
• Sicherheit: Umgang mit Zugangsdaten, Schwärzung in Logs, Geräteverlust, Entzug von Konten

Rokids FAQ empfiehlt ausdrücklich, bei der Leistungsanalyse Arbeitsspeicher und CPU-Temperatur zu überwachen, und warnt, dass sehr wenig verfügbarer Arbeitsspeicher das Beenden von Hintergrundprozessen wahrscheinlicher macht. Das ist ein weiterer Grund, die Brillen-App fokussiert zu halten und nicht wesentliche Dienste auszulagern.

Schritt 18: Das Pilotprojekt paketieren und die Bereitstellungsbasis kontrollieren

Während der Entwicklung lassen sich APKs über Android Studio mit dem Glass3-Daten-Debug-Kabel installieren. Eine Produktivbereitstellung erfordert einen strengeren Release-Prozess. Rokid dokumentiert keine richtlinienbasierte Steuerung im Stil eines MDM (etwa Kioskmodus, Fernlöschung oder App-Richtlinien). Stattdessen dokumentiert Rokid die Geräteregistrierung und Statusverfolgung über die Lingmou-Konsole und OpenAPI, während Version 2.2.0-E die APK-Installation über eine QR-Scan-App ermöglicht. Stimmen Sie Bereitstellungsmechanismus, Provisioning-Rechte, Enterprise-Firmware und Update-Richtlinie mit Rokid oder dem Distributor ab, bevor Sie sich auf eine Rollout-Architektur festlegen.

1. Frieren Sie die getesteten SDK- und OTA-Versionen für das Pilotprojekt ein.

1. Erstellen Sie signierte Release-APKs für die Brillen- und Smartphone-Anwendungen.

1. Dokumentieren Sie Client-IDs, Paketnamen und die Konfiguration der Backend-Umgebung.

1. Stellen Sie API-Keys und Backend-Geheimnisse über eine sichere Infrastruktur bereit, nicht über den Quellcode.

1. Legen Sie fest, wer die Brille, die Smartphone-App und das Backend aktualisieren darf und in welcher Reihenfolge.

1. Führen Sie nach jeder OTA- oder SDK-Änderung Regressionstests durch, bevor Sie die Flotte aktualisieren.

1. Richten Sie einen Support-Pfad für Logs, Geräteidentität, Konnektivitätsdiagnose und Rollback ein.

Beispielarchitektur: eine individuelle Inspektions-App für den Außendienst

Das folgende Beispiel ist ein praxisnaher Entwurf, der aus den dokumentierten Funktionen von Rokid zusammengestellt wurde. Es handelt sich nicht um einen fertigen Rokid-Workflow. Es zeigt, wie der Entwickler-Stack die Brille in einen dedizierten geschäftlichen Endpunkt verwandeln kann.

1. Start. Technische Aktion: Die Brillen-App startet automatisch und prüft die SDK-Bereitschaft. Geschäftlicher Nutzen: Mitarbeitende starten direkt im Unternehmens-Workflow.
2. Aufgabe zuweisen. Technische Aktion: Smartphone/Backend sendet eine Zusammenfassung des Arbeitsauftrags als kompakte Nachricht. Geschäftlicher Nutzen: Kein manuelles Nachschlagen auf einem Smartphone erforderlich.
3. Anleiten. Technische Aktion: Die Brille zeigt eine Anweisung im zentralen Displaybereich an. Geschäftlicher Nutzen: Die Hände bleiben für die Aufgabe frei.
4. Bestätigen. Technische Aktion: Mitarbeitende sprechen einen festen Befehl oder nutzen ein unterstütztes Hardware-Ereignis. Geschäftlicher Nutzen: Schnelle, deterministische Interaktion.
5. Nachweis erfassen. Technische Aktion: Die Brille nimmt ein Foto oder einen kurzen Clip auf. Geschäftlicher Nutzen: Der visuelle Nachweis wird dem richtigen Schritt zugeordnet.
6. Übertragen. Technische Aktion: Medien werden über P2P übertragen; eine kleine Statusnachricht bestätigt den Upload. Geschäftlicher Nutzen: Große Datenmengen belasten den Steuerkanal mit geringer Bandbreite nicht.
7. Synchronisieren. Technische Aktion: Smartphone oder Backend übermittelt das Ergebnis an die CMMS-/ERP-API. Geschäftlicher Nutzen: Die bestehenden Geschäftssysteme bleiben das führende System.
8. Ausnahme. Technische Aktion: Bei Bedarf empfängt das Smartphone einen Livestream, oder die App löst den freigegebenen Fernunterstützungspfad aus. Geschäftlicher Nutzen: Eine Führungskraft kann sehen, was der Mitarbeiter sieht.
9. Abschließen. Technische Aktion: Das Backend bestätigt den Abschluss und gibt die nächste Aufgabe zurück. Geschäftlicher Nutzen: Nutzer erhalten einen klaren Endzustand, und der Audit-Trail ist vollständig.

Warum individuelle Software den Business Case für Rokid AI Glasses Enterprise verändert

Der wichtigste Nutzen für Unternehmen ergibt sich daraus, das Gerät an einen bestehenden betrieblichen Prozess anzupassen oder diesen Prozess für freihändiges Arbeiten neu zu gestalten.

Zweckgebundene Oberfläche: Consumer-Menüs entfernen und nur die Informationen anzeigen, die im aktuellen Arbeitsschritt benötigt werden.

Integration in Geschäftssysteme: erfasste Nachweise und Aktionen der Mitarbeitenden mit bestehenden ERP-, CMMS-, CRM- oder individuellen Plattformen verbinden.

Freihändige Datenerfassung: Kamera, Sprache und Wearable-Eingaben nutzen, ohne immer wieder zu einem Smartphone oder Tablet greifen zu müssen.

Kontrollierte Konnektivität: Bluetooth für Befehle und P2P für Daten mit hoher Bandbreite nutzen, statt alle Funktionen über einen einzigen Kanal zu zwingen.

Individuelle KI-Grenzen: KI dort einsetzen, wo sie Mehrwert schafft, während Workflow-Regeln, Berechtigungen und Data Governance unter der Kontrolle des Unternehmens bleiben.

Dediziertes Geräteverhalten: Autostart und Ereignisbehandlung können bei Einzweck-Einsätzen Reibungsverluste verringern, sofern die Enterprise-Firmware dies unterstützt.

Erweiterbare Architektur: mit einem lokalen Proof of Concept beginnen und dann, wenn der Workflow ausgereifter ist, Backend-Integration, Plattform-APIs, Fernzusammenarbeit oder spezialisierte SDKs ergänzen.

Das Kaufargument: Für Organisationen, die ein standardisiertes, festes App-Erlebnis benötigen, ist individuelle Entwicklung möglicherweise unnötig. Für Organisationen, die KI-Brillen zum Teil eines kontrollierten betrieblichen Workflows machen wollen, ist das dokumentierte Glass3 SDK der Grund, warum die Hardware interessanter wird. Das Unternehmen kauft einen anpassbaren Endpunkt, nicht nur ein tragbares Display oder eine Kamera.

Einschränkungen und technische Risiken, die Sie einplanen sollten

• Android-fokussiertes SDK: Das öffentliche Glass3 SDK richtet sich an natives Android. Laut Rokids FAQ werden iOS und natives HarmonyOS nicht unterstützt. Eine uni-app-Integration ist nur möglich, wenn Sie eine eigene Bridge zum nativen Android-SDK entwickeln.
• Kompaktes Display: Die Hochformat-Fläche von 480 x 640 eignet sich für knappe Hinweise, nicht für dichte Enterprise-Dashboards. Gutes Workflow-Design ist unerlässlich.
• Abweichungen zwischen SDK und Changelog: Validieren Sie SDK-Artefakte, Demo und OTA gemeinsam und berücksichtigen Sie dabei Versionsunterschiede zwischen den chinesischen und englischen Changelogs.
• Abhängigkeit von Online-Diensten: Ausgewählte ASR-, KI- und OpenAPI-Funktionen erfordern Netzwerkzugang, Enterprise-Zugangsdaten oder eine Bereitstellung der Dienste.
• Keine offene Offline-ASR laut aktueller FAQ: Offline-TTS und feste Offline-Befehlsfunktionen können eine robuste Interaktion unterstützen, eine freie Offline-Spracherkennung ist derzeit jedoch nicht als integrierte Funktion dokumentiert.
• Komplexität der Übertragungswege: Bluetooth und P2P lösen unterschiedliche Probleme. Wiederverbindung, Berechtigungen und Zustandssynchronisierung erfordern Engineering in Produktionsqualität.
• Kern-RTC entfernt: Rokid hat RTC-Anrufe in 2.1.7-E aus dem Basis-Phone-SDK entfernt. Für Fernzusammenarbeit sollte Rokids Remote Collaboration SDK oder eine separat entwickelte Lösung genutzt werden.
• Bereitstellungsdetails müssen validiert werden: Die öffentliche SDK-Dokumentation ist bei der Entwicklung stark, doch Flottenmanagement im Produktivbetrieb und Provisioning über die Lingmou-Konsole oder die QR-Scan-App sollten vor der Skalierung für die Umgebung des Kunden bestätigt werden.

Vor- und Nachteile für individuelle Enterprise-Entwicklung

Vorteile:

• Natives Android-Entwicklungsmodell
• Öffentliche Maven-Artefakte
• Offizielle Demo für Brille + Smartphone
• Bluetooth und P2P
• Messaging/Dateien/Medien
• Kamera und Live-Vorschau
• Sprach-/KI-/Erkennungsdienste
• Direktes WLAN möglich
• Enterprise-OpenAPI
• Möglichkeiten für Autostart und Ereignisanpassung.

Nachteile:

• Native SDK-Unterstützung nur für Android
• Kompaktes, festes Display
• Abstimmung von Versionen/OTA
• Ausgewählte Online-Funktionen erfordern Enterprise-Zugang
• Einschränkung bei Offline-ASR
• Details zu Provisioning/Flottenmanagement im Produktivbetrieb müssen projektspezifisch bestätigt werden.

Fazit

Rokid AI Glasses Enterprise ist eine Überlegung wert, wenn das Ziel des Unternehmens darin besteht, einen dedizierten freihändigen Workflow aufzubauen, statt eine generische Consumer-Anwendung einzusetzen. Der aktuelle Glass3-Enterprise-Stack bietet Android-Entwicklern einen dokumentierten Weg, auf der Brille zu entwickeln, sie mit einem Android-Smartphone zu koppeln, Steuerdaten über Bluetooth zu senden, Medien über Wi-Fi P2P zu übertragen und den Workflow mit Backend-Systemen oder ausgewählten Rokid-OpenAPI-Diensten zu verbinden.

Die stärksten Anwendungsfälle sind angeleitete Inspektionen, Außendienst, Nachweiserfassung, prozedurale Arbeit und andere Aufgaben, bei denen Mitarbeitende davon profitieren, jeweils eine Anweisung zu sehen und dabei beide Hände frei zu haben. Die wichtigste Einschränkung ist nicht ein Mangel an APIs. Es ist die technische Disziplin, die rund um das kleine Display, den Verbindungsstatus, Berechtigungen, die SDK-/OTA-Kompatibilität und Abhängigkeiten von Online-Diensten erforderlich ist.

Für Käufer im Unternehmen lautet die entscheidende Bewertungsfrage: „Können wir unseren Workflow auf den dokumentierten Entwickler-Stack abbilden, und können wir die Anwendung über ihren gesamten Lebenszyklus hinweg betreuen?“ Lautet die Antwort Ja, bietet individuelle Software den Weg, Rokid Glass3 von einer universellen KI-Brille in ein zweckgebundenes Betriebsgerät zu verwandeln.

Für Unternehmen, die Rokid AI Glasses Enterprise für Inspektionen, Außendienst, Logistik, angeleitete Arbeit oder individuelle KI-Workflows prüfen, kann VR Expert bei der Bewertung der Hardware, der Definition eines Proof of Concept und der Validierung des Bereitstellungswegs unterstützen. Auf der Produktseite zu Rokid AI Glasses Enterprise finden Sie Informationen zum Gerät, zur Verfügbarkeit und zu den Kaufoptionen. Für die Planung individueller Entwicklungen oder Beratung zum Rollout kontaktieren Sie VR Expert.