Balena als Basis: Vom Tablet zum Assistenzgerät
Ein Tablet einschalten, die Anwendung startet, Kamera und Mikrofon stehen bereit: So soll sich unser AvatarMediKi-Prototyp im Alltag verhalten. Hinter diesem Ablauf steckt mehr als eine Webseite im Vollbild. Das Gerät muss sich mit dem Netzwerk verbinden, seine Hardware ansprechen und nach einem Neustart wieder in einen definierten Zustand zurückkehren. Gleichzeitig möchten wir neue Softwarestände testen können, ohne jedes Gerät vor Ort neu einzurichten.
Als technische Grundlage nutzen wir dafür Balena. Im aktuellen Aufbau läuft auf dem Gerät ein Electron-Kiosk unter balenaOS. Die eigentliche Web-Anwendung und die KI-Auswertung betreiben wir auf einem Server. Dieser Beitrag zeigt, wie diese Teile zusammenarbeiten und welche Aufgaben lokal bleiben.
Was Balena in unserem Aufbau übernimmt
balenaOS ist ein Linux-basiertes Betriebssystem für den Betrieb von Container-Anwendungen auf Geräten. Der Balena Supervisor verwaltet die darauf laufenden Dienste und setzt den vorgesehenen Softwarestand um. Über balenaCloud lassen sich Geräte und Releases zentral verwalten.
Für unser Forschungsprojekt ist besonders die nachvollziehbare Verteilung von Software wichtig. Eine neue Version soll auf einem ausgewählten Testgerät geprüft werden können, bevor weitere Geräte sie erhalten. Dazu können wir ein Gerät gezielt auf einen bestimmten Release festlegen. So ist auch bei mehreren Prototypen erkennbar, welcher Stand auf welchem Gerät läuft.
Die Gerätesoftware beschreiben wir mit einem Dockerfile und einer Compose-Konfiguration. Darin ist festgelegt, welche Laufzeitumgebung benötigt wird, wie der Dienst startet und auf welche Schnittstellen des Geräts er zugreifen darf.
Vom Einschalten bis zur Anwendung
Unser Kiosk baut auf dem Projekt avatar-base auf. Der aktuelle Geräte-Container bringt die grafische Umgebung X11, die Audioanbindung und die Electron-Laufzeit mit. Einen vollständigen Linux-Desktop mit Fenstermanager und gewöhnlicher Arbeitsoberfläche benötigen wir für diesen Ablauf nicht.
Nach dem Start bereitet der Container die benötigten Gerätezugriffe vor und startet Electron im Kioskmodus. Electron lädt anschließend die konfigurierte Adresse unserer Web-Anwendung. Auf dem Bildschirm erscheint damit direkt die Oberfläche von AvatarMediKi.
Der Geräte-Container lässt sich für amd64-Tablets und ARM64-Geräte wie den Raspberry Pi bauen. Eine gemeinsame Softwarebasis bedeutet allerdings nicht, dass jede Kamera oder jeder Audiochip automatisch funktioniert. Die konkreten Treiber und die Firmware müssen weiterhin zur Hardware und zum Kernel passen.
Tablet und Kamera im Versuchsaufbau. Der lokale Kiosk verbindet die Web-Anwendung mit den Gerätefunktionen.Zwei Ebenen für die Weiterentwicklung
Eine wichtige Entscheidung betrifft die Aufteilung zwischen Gerät und Server. Auf dem Gerät laufen der Kiosk und seine nativen Systemfunktionen. Die React-Weboberfläche, der Express-Server und der YOLO-Dienst werden im aktuellen Balena-Aufbau auf dem Server betrieben.
Dadurch können wir Änderungen an der Web-Anwendung unabhängig vom Geräteimage ausliefern. Ein überarbeiteter Dialog oder eine neue Ansicht kommt über das Web-Deployment. Ändern wir dagegen die lokale WLAN-Anbindung, die Electron-Laufzeit oder die Geräteunterstützung, benötigen wir einen neuen Balena-Release.
Diese Trennung hat auch eine klare Grenze: Für die serverbasierten Funktionen braucht das Gerät eine funktionierende Verbindung. Deshalb gehört eine lokale Wiederherstellungsoberfläche zum Kiosk. Kann die Webseite nicht geladen werden, bleibt die WLAN-Einrichtung auf dem Gerät erreichbar – einschließlich Bildschirmtastatur.
Wie die Weboberfläche die Hardware erreicht
Eine Web-Anwendung kann nicht ohne Weiteres die Bildschirmhelligkeit ändern, ein WLAN einrichten oder einen Bluetooth-Lautsprecher verbinden. Dafür besitzt unsere Electron-Anwendung eine native Brücke: Die Oberfläche fordert eine vorgesehene Funktion an, und der lokale Anwendungsteil führt sie aus.
Für die Netzwerkverwaltung verwenden wir den NetworkManager des Hostsystems. Der Zugriff erfolgt über D-Bus, eine Schnittstelle zur Kommunikation mit Systemdiensten. Die Audioausgabe wird über PulseAudio angebunden, Bluetooth über BlueZ. Weitere lokale Funktionen liefern beispielsweise den Akkustand oder steuern die Hintergrundbeleuchtung.
Die Brücke stellt festgelegte Funktionen bereit. Die geladene Webseite erhält dadurch keinen allgemeinen Zugriff auf die Shell. Die Herkunft der aufrufenden Seite wird geprüft; die lokale Diagnoseoberfläche läuft zusätzlich in einem getrennten, isolierten Bereich. Der Kiosk-Container selbst benötigt für die Hardwareintegration weitreichende Rechte. Diese Grenze zwischen Container und Weboberfläche ist daher ein wichtiger Teil unserer Architektur.
Einstellungen behalten, Software austauschen
Ein neues Geräteimage soll nicht bedeuten, dass alle Einstellungen erneut vorgenommen werden müssen. Deshalb speichern wir die Electron-Profildaten in einem benannten Volume, das bei regulären Anwendungsupdates erhalten bleibt. Die WLAN-Profile verwaltet NetworkManager auf dem Host.
Damit trennen wir den austauschbaren Softwarestand von den dauerhaft benötigten Gerätedaten. Balena beschreibt dieses Prinzip in seiner Dokumentation zu persistentem Speicher. Für unseren Betrieb ist dabei wichtig, den Namen und die Einbindung des Volumes über Releases hinweg beizubehalten.
Der AvatarMediKi-Prototyp: Tablet, Halterung und Kamera bilden die Gerätebasis für den Kioskbetrieb.Diagnose gehört zur Gerätebasis
Wenn auf einem Prototyp kein Ton zu hören ist, kann die Ursache in der Web-Anwendung, der Audioausgabe oder dem Treiber liegen. Deshalb enthält unser Kiosk eine lokale Diagnoseoberfläche. Dort lassen sich unter anderem Lautsprecher testen, Mikrofonpegel prüfen und eine Kameravorschau öffnen. Diese Werkzeuge sind unabhängig davon verfügbar, ob die gehostete Web-Anwendung gerade erreichbar ist.
Ein lokaler Healthcheck prüft zusätzlich, ob der Kiosk-Dienst antwortet. Das ersetzt keinen Funktionstest von Kamera, Mikrofon oder Anwendung, liefert aber einen ersten Hinweis auf den Zustand des Dienstes. Für gezielte Wartungssitzungen kann optional ein geschützter Bildschirmzugriff aktiviert werden; im Standardbetrieb ist er ausgeschaltet.
Balena liefert uns damit eine verwaltbare Grundlage für die Geräte. Die Arbeit an Treibern, Hardwaretests und Wiederherstellungsabläufen bleibt Teil unserer Entwicklung. Gerade diese Kombination macht aus einem Tablet einen Prototyp, den wir gezielt aktualisieren, untersuchen und im Projekt weiterentwickeln können.
