Haushaltsroboter: Was individuelle Software im Alltag leisten könnte

Ein Roboter kann eine beeindruckende Vorführung absolvieren und trotzdem noch nicht zu deinem Alltag passen. Vielleicht soll er während einer Besprechung leise bleiben, einen Raum grundsätzlich auslassen oder einen Auftrag erst nach deiner Bestätigung beginnen. Solche Regeln entstehen aus dem Leben vor Ort. Sie stehen selten vollständig in der Produktbeschreibung eines Geräts.

Genau hier wird individuelle Software interessant: Sie könnte freigegebene Roboterfunktionen mit deinen Abläufen verbinden. Ob daraus eine hilfreiche Anwendung wird, hängt allerdings vom konkreten Modell, seinen Schnittstellen und der vorgesehenen Umgebung ab. Eine hübsche Bedienoberfläche allein macht aus einem Gerät noch keinen verlässlichen Haushaltshelfer.

Der Unterschied zwischen einer Gerätefunktion und deinem Ablauf

Ein Hersteller definiert zunächst, welche Aufgaben seine Hardware überhaupt ausführen darf. Dazu können beispielsweise eine Fahrt zu einem Ziel, das Abfragen des Akkustands oder das Starten eines vorhandenen Reinigungsprogramms gehören. Welche Befehle extern verfügbar sind, muss für das einzelne Gerät geprüft werden. Eine Funktion in der Hersteller-App ist nicht automatisch auch für eigene Software zugänglich.

Dein Ablauf besteht aus zusätzlichen Bedingungen: Wer darf starten? Ist der Raum freigegeben? Was passiert bei einer Unterbrechung? An wen geht eine verständliche Rückmeldung? Für solche Verknüpfungen kann eine kleine Anwendung genügen. Wenn die vorhandene Hersteller-App deinen Bedarf bereits vollständig erfüllt, ist eine zusätzliche Entwicklung möglicherweise überflüssig.

Vier mögliche Aufgaben für individuelle Software

• Haushaltsroutinen: Unterstützte Reinigungsfunktionen mit Zeitfenstern und deiner ausdrücklichen Raumfreigabe verbinden. Ein geplanter Termin darf dabei verschoben werden, ohne dass jemand komplizierte Regeln bearbeiten muss.
• Serviceabläufe: Bei geeigneter Transporthardware einen freigegebenen Auftrag annehmen, seinen Fortschritt anzeigen und eine zuständige Person über eine Unterbrechung informieren. Tragfähigkeit und zulässige Einsatzbedingungen bleiben Grenzen des Geräts.
• Gemeinsame Bedienung: Unterschiedliche Berechtigungen für Bewohner, Mitarbeitende oder betreuende Personen abbilden. Eine Person darf beispielsweise Aufträge starten, während nur die verantwortliche Stelle Bereiche und Betriebszeiten verändert.
• Verständliche Rückmeldungen: Aus technischen Zuständen klare Hinweise machen: Auftrag wartet auf Freigabe, Weg nicht verfügbar oder Akku wird geladen. Eine Nachricht sollte erklären, was ein Mensch als Nächstes tun kann.

Diese Beispiele beschreiben mögliche Projektziele. Sie sind keine zugesagten Funktionen eines bestimmten Roboters. Vor jeder Umsetzung braucht es den Nachweis, dass die dafür erforderlichen Zustände und Befehle tatsächlich über eine erlaubte Schnittstelle verfügbar sind.

Fiktives Praxisbeispiel: die Reinigung nach der Besprechung

Ein kleines Büro nutzt einen Reinigungsroboter mit dokumentierter Schnittstelle. Der Besprechungsraum soll erst gereinigt werden, wenn ein Mitarbeiter ihn freigibt. Eine starre Startzeit hilft wenig, weil Gespräche länger dauern können. Die gewünschte Ergänzung wäre eine einfache Schaltfläche in der internen Raumübersicht. Das folgende Beispiel ist eine Projektskizze, keine CAZ-Kundenreferenz.

• Freigeben: Ein berechtigter Mitarbeiter bestätigt, dass der Raum für den vorgesehenen Betrieb vorbereitet ist. Die Software zeigt das geplante Programm und fragt bei Bedarf nochmals nach.
• Prüfen: Die Anwendung liest die vom Gerät bereitgestellten Zustände. Ist der Roboter nicht verfügbar oder der Akku ungeeignet, bleibt der Auftrag sichtbar in der Warteschlange.
• Ausführen: Nur die unterstützte Reinigungsfunktion wird gestartet. Die eigene Anwendung zeigt deren Rückmeldungen; sie ersetzt weder die Navigation noch die Schutzfunktionen des Herstellers.
• Abschließen: Erst eine passende Abschlussmeldung setzt den Auftrag auf erledigt. Fehlt sie, erscheint eine offene Aufgabe statt einer grünen Erfolgsmeldung. Ein Mensch entscheidet über das weitere Vorgehen.

Der Nutzen wäre hier gut überprüfbar: weniger manuelle Abstimmung und ein klarer Auftragsstatus. Ob tatsächlich Zeit gespart wird, zeigt ein begrenzter Versuch mit den Beteiligten. Wenn das Vorbereiten und Nacharbeiten mehr Aufwand erzeugt als die bisherige Lösung, sollte der Ablauf angepasst oder verworfen werden.

Assistenz beginnt mit Selbstbestimmung

Für Menschen mit Unterstützungsbedarf könnte eine verständliche Bedienung besonders wertvoll sein: große Schaltflächen, eindeutige Rückmeldungen und eine jederzeit erreichbare Möglichkeit zum Abbrechen. Welche Darstellung hilft, sollte gemeinsam mit den späteren Nutzern erprobt werden. Eine Sprachsteuerung kann ergänzen, muss aber weder die einzige Bedienmöglichkeit sein noch dauerhaft mithören.

Mögliche Assistenzfunktionen sind etwa selbst gewählte Alltagserinnerungen oder der angeforderte Kontakt zu einer festgelegten Bezugsperson. Ein versendeter Hinweis ist jedoch keine bestätigte Hilfeleistung. Wer darauf reagiert und was bei Nichterreichbarkeit passiert, gehört zum Konzept. Eine allgemeine Assistenzanwendung ersetzt keine Pflege, keine medizinische Diagnose und kein zugelassenes Notrufsystem.

Die Schnittstelle entscheidet, was wirklich möglich ist

Eine API ist der dokumentierte Zugang, über den Programme Daten austauschen oder bestimmte Funktionen anfordern. Ein SDK ergänzt diesen Zugang um Werkzeuge und Beispielcode. Hersteller können den Umfang nach Modell, Produktvariante oder Entwicklungsfreigabe begrenzen. Vor einem Kauf sollte deshalb geklärt sein, ob genau die benötigten Funktionen für dein Projekt zugänglich sind.

Dass Hersteller Entwicklungszugänge bereitstellen, zeigt beispielsweise das offizielle Unitree SDK2. Das ist ein konkretes Softwarepaket mit eigenen Voraussetzungen, kein Beleg für beliebige Haushaltsfunktionen. Auch die REST-Schnittstelle von Home Assistant zeigt, wie sich Zustände abfragen und verfügbare Dienste ansprechen lassen. Eine solche Haussteuerung öffnet aber keine ansonsten geschlossene Roboterschnittstelle.

Ebenso wichtig ist die physische Eignung. Software vergrößert weder die Traglast noch die Reichweite eines Arms und beseitigt keine ungeeigneten Treppen, Bodenverhältnisse oder Engstellen. Für ein sinnvolles Konzept betrachten wir deshalb das Gerät und seinen Einsatzort gemeinsam.

Privatsphäre und Kontrolle gehören in die erste Skizze

Ein Roboter in privaten Räumen verdient besondere Aufmerksamkeit. Zuerst wird geklärt, welche Sensoren für die Aufgabe nötig sind, wo Daten verarbeitet werden und wer darauf zugreifen kann. Ein Statusbericht benötigt nicht automatisch ein Kamerabild. Für die Rückmeldung über einen abgeschlossenen Auftrag muss auch nicht der gesamte Tagesablauf gespeichert werden.

Zur Planung gehören festgelegte Zugänge, möglichst wenige gespeicherte Daten und nachvollziehbare Löschregeln. Eine Verarbeitung vor Ort kann sinnvoll sein, ist aber nicht bei jedem Hersteller verfügbar. Cloud-Abhängigkeiten, benötigte Konten und das Verhalten ohne Internet sollten deshalb vor der Entwicklung bekannt sein. Betroffene Menschen müssen verstehen können, wann das System aktiv ist und wie sie es abschalten.

Was sich vor einer Investition klären lässt

• Eine konkrete Aufgabe: Welcher wiederkehrende Arbeitsschritt soll leichter werden, und woran erkennen die Beteiligten eine Verbesserung?
• Eine geeignete Grundlage: Welches Modell, welche Schnittstelle und welche Freigaben sind vorhanden? Wer stellt Hardware und einen geeigneten Testbereich bereit?
• Ein realistischer Betrieb: Wer übernimmt Betreuung, Updates und Störungen? Welche laufenden Hersteller- oder Cloud-Kosten sind zu berücksichtigen?
• Eine überprüfbare Entscheidung: Welche Ergebnisse muss ein Pilot liefern, bevor zusätzliche Funktionen oder weitere Geräte sinnvoll werden?

CAZ kann diese Fragen mit dir strukturieren und auf kompatiblen Schnittstellen individuelle Bedienoberflächen, Verbindungen zu vorhandenen Systemen und abgestimmte Abläufe entwickeln. Welche Leistungen wir konkret übernehmen, wird für das einzelne Vorhaben vereinbart. Du bekommst einen klar umrissenen ersten Schritt mit einem Ziel, das sich überprüfen lässt.

Beschreibe uns zum Einstieg die Aufgabe, das vorhandene oder erwogene Gerät und die Umgebung. Dafür brauchst du kein fertiges Pflichtenheft. Der technische Begleitartikel erklärt, wie aus Schnittstellen und Simulation ein überprüfbarer Pilot wird.