Roboter programmieren: Von der Schnittstelle zum sinnvollen Pilotprojekt

Du möchtest einen Roboter in einen eigenen Ablauf einbinden. Der erste praktische Schritt ist eine überprüfbare Frage: Kann die vorgesehene Hardware die Aufgabe ausführen und lässt sich diese Funktion über eine erlaubte Schnittstelle ansprechen? Erst wenn beides geklärt ist, lohnt sich die Planung der eigentlichen Anwendung.

Dieser Artikel beschreibt einen möglichen Entwicklungsweg von der Bestandsaufnahme bis zum begrenzten Pilotbetrieb. CAZ bereitet sich auf dieses Arbeitsfeld vor und bietet Machbarkeitsklärung sowie individuelle Softwarearbeit auf kompatiblen Herstellerschnittstellen an. An fiktiven Beispielen zeigen wir, welche Fragen sich vor einer Investition klären lassen und wie daraus ein überschaubares Vorhaben wird.

1. Den Zugang prüfen, bevor Funktionen versprochen werden

Zum Einstieg benötigen wir die genaue Modellbezeichnung, Hardwarevariante, Firmware und verfügbare Herstellerdokumentation. Dazu kommen Lizenzbedingungen, Zugangsdaten für eine Entwicklungsumgebung und gegebenenfalls eine ausdrückliche Freigabe. Entscheidend ist, ob eine Funktion nur in einer Vorführung sichtbar war oder tatsächlich für die eigene Anwendung bereitsteht.

• Lesen: Welche Zustände kann die Anwendung abfragen, etwa Verfügbarkeit, Akkustand oder Auftragsfortschritt? Sind Aktualität und mögliche Fehlermeldungen dokumentiert?
• Anfordern: Welche Aufträge darf sie auslösen? Gibt es definierte Voraussetzungen, Grenzen und Rückmeldungen zur Annahme eines Befehls?
• Unterbrechen: Wie lassen sich laufende Aufträge kontrolliert abbrechen? Was geschieht bei Verbindungsverlust oder wenn eine andere Bedienung die Kontrolle übernimmt?
• Betreiben: Sind die benötigten Funktionen lokal erreichbar oder an Herstellerkonten, Cloud-Verbindungen, Lizenzen und bestimmte Softwareversionen gebunden?

Als öffentliches Herstellerbeispiel enthält das Unitree SDK2 für Python Schnittstellen und Beispielprogramme. Für ein konkretes Vorhaben müssten trotzdem Modell, Ausführung, Betriebsmodus und zugelassene Funktionen geprüft werden. Eine SDK-Veröffentlichung ist weder eine Freigabe für jeden Einsatz noch eine Zusage von CAZ, dieses System bereits zu unterstützen.

2. API, SDK und ROS 2 haben verschiedene Aufgaben

Die API beschreibt die verfügbare Kommunikation mit einem System. Ein SDK liefert dazu beispielsweise Bibliotheken, Datentypen und Beispielprogramme. Eine eigene Anwendung kann auf dieser Grundlage einen vorhandenen Auftrag anfordern und seinen Zustand anzeigen. Sie muss dafür nicht zwangsläufig die Motoren oder die Navigation selbst steuern.

ROS 2 stellt Bausteine für verteilte Robotiksoftware bereit. Die offizielle Beschreibung von ROS 2 Actions erläutert länger laufende Aufgaben mit Ziel, Fortschrittsmeldungen und Ergebnis. Auch eine Abbruchanfrage ist vorgesehen; ob und wie sie angenommen wird, entscheidet die jeweilige Umsetzung. Sie ist keine garantierte Sicherheitsfunktion. Ob ein bestimmtes Gerät ROS 2 unterstützt, bleibt eine separate Hersteller- und Integrationsfrage.

Für eine kleine Ergänzung kann eine direkte Hersteller-API ausreichen. Bei mehreren Sensoren, Komponenten oder Entwicklungswerkzeugen kann ROS 2 passen. Die Entscheidung folgt dem Projekt: Welche Daten werden benötigt, welche bestehenden Komponenten lassen sich verwenden und wer kann die Lösung später betreuen? Ein zusätzliches Framework sollte einen konkreten Nutzen haben.

3. Einen Ablauf mit klaren Zuständen beschreiben

Ein Auftrag benötigt mehr als eine Starttaste. Für eine fiktive Anwendung könnten die Zustände lauten: angefragt, wartet auf Freigabe, angenommen, läuft, unterbrochen, abgeschlossen oder fehlgeschlagen. Zu jedem Zustand wird festgelegt, welche Aktion erlaubt ist und welche Rückmeldung erwartet wird. So erkennt die Oberfläche auch den Unterschied zwischen einem gesendeten Befehl und einer erledigten Aufgabe.

Ein verlorenes Netzwerkpaket darf nicht versehentlich zwei Aufträge auslösen. Deshalb braucht die Anwendung eindeutige Auftragskennungen und eine festgelegte Behandlung von Wiederholungen, soweit die Geräteschnittstelle das unterstützt. Fehlt eine verlässliche Rückmeldung, muss diese Grenze sichtbar werden. Eine optimistische Erfolgsmeldung löst das technische Problem nicht.

4. Erst die Abläufe testen, dann reale Bewegung

Schon ohne angeschlossenen Roboter lassen sich Bedienung und Fehlerbehandlung mit nachgebildeten Schnittstellen prüfen. Ein Testsystem liefert etwa einen niedrigen Akkustand, antwortet verspätet oder lehnt einen Auftrag ab. Damit wird sichtbar, ob die Anwendung verständlich reagiert und ihre internen Zustände konsistent hält.

Für räumliche und physikalische Szenarien kann eine Robotiksimulation hinzukommen. Die offizielle Gazebo-Einführung beschreibt das Arbeiten mit Welten, Robotermodellen und Erweiterungen sowie die Anbindung an ROS. Voraussetzung ist ein für die Fragestellung brauchbares Modell. Ein beliebiger ähnlich aussehender Roboter liefert noch keine belastbare Aussage über die eigene Hardware.

5. Fiktiver Pilot: ein klar begrenzter Transportauftrag

Angenommen, ein Betrieb verfügt über einen für solche Transporte geeigneten mobilen Roboter. Seine freigegebene Schnittstelle erlaubt Fahrten zwischen eingerichteten Stationen. Ein erster Pilot könnte eine einzige Strecke im vorbereiteten Testbereich und einen definierten, zulässigen Gegenstand umfassen. Mitarbeitende übernehmen das Be- und Entladen. Das ist ein Planungsbeispiel, kein bestehendes CAZ-Projekt.

• Vorbereitung: Verantwortliche Person, zulässige Last, Teststrecke und Betriebsbedingungen festlegen. Herstelleranleitung und vorhandene Schutzfunktionen bilden die Grundlage.
• Freigabe: Ein berechtigter Mensch prüft die vereinbarten Voraussetzungen und startet den Auftrag. Die Anwendung verlangt keine zusätzliche Greiffunktion, die das Gerät gar nicht bereitstellt.
• Beobachtung: Auftragsannahme, Fortschritt und tatsächliches Ende getrennt erfassen. Unterbrechungen und notwendige menschliche Eingriffe werden ebenfalls dokumentiert.
• Auswertung: Wiederholbare Ergebnisse, Fehlersituationen und Betreuungsaufwand mit dem bisherigen Ablauf vergleichen. Erst danach über Erweiterungen entscheiden.

Die Abnahme umfasst auch unangenehme Fälle: Der Zielpunkt ist nicht verfügbar, die Verbindung bricht ab oder ein Auftrag wird bewusst zurückgezogen. Solche Versuche gehören in einen geeigneten, beaufsichtigten Testaufbau. Welche Prüfungen sicher möglich sind, wird mit den für Hardware und Betrieb verantwortlichen Personen vereinbart.

6. Zugriffsschutz und körperliche Sicherheit getrennt betrachten

Für den Zugriffsschutz braucht es begrenzte Berechtigungen, geschützte Zugangsdaten und nachvollziehbare Zuständigkeiten. Die offizielle ROS-2-Sicherheitseinführung demonstriert authentifizierte und verschlüsselte Kommunikation mit Zertifikaten und entsprechender Konfiguration. Solche Funktionen müssen passend eingerichtet werden; der Einsatz von ROS 2 allein macht ein Netzwerk nicht geschützt.

Davon zu unterscheiden sind Gefährdungen durch Bewegung, Lasten oder ein ungeeignetes Einsatzumfeld. Eine gewöhnliche Schaltfläche in einer App ersetzt keine erforderliche sicherheitsgerichtete Stoppfunktion. Schutzkonzept, Verantwortlichkeiten und mögliche Auswirkungen einer Änderung auf die bestimmungsgemäße Verwendung müssen vor einem realen Einsatz geklärt werden. Softwareentwicklung allein ist kein Nachweis der Sicherheit des Gesamtsystems.

Allgemeine Assistenz ist ebenfalls von medizinischen Anwendungen zu trennen. Erinnerungen oder organisatorische Hilfen erlauben keine Diagnose, Medikamentenentscheidung oder körpernahe Pflege durch ein dafür ungeeignetes System. Sobald ein Projekt solche Aufgaben berührt, sind andere Anforderungen und zuständige Fachleute einzubeziehen.

7. Eine verständliche Bedienung und einen betreubaren Betrieb bauen

Für Nutzer zählen klare Begriffe und verlässliche Rückmeldungen. Die Anwendung sollte zeigen, welcher Auftrag aktiv ist, wer ihn ausgelöst hat und welche Entscheidung gerade benötigt wird. Bei einer unklaren Lage ist eine verständliche Aufforderung zur Prüfung hilfreicher als ein unbekannter Fehlercode. Berechtigungen verhindern, dass jede Person sämtliche Einstellungen verändert.

Auch nach einem erfolgreichen Versuch bleibt Arbeit: Versionen dokumentieren, Änderungen testen und Zugänge bei Personalwechseln entziehen. Ein Herstellerupdate kann erneute Kompatibilitätsprüfungen notwendig machen. Zur Übergabe gehören deshalb vereinbarte Zuständigkeiten, Betriebsanleitung und ein Verfahren für Störungen. Umfang und Kosten dieser Betreuung werden gesondert besprochen.

Was CAZ für die erste Prüfung braucht

Schick uns Modell und Dokumentation, eine kurze Beschreibung der Aufgabe sowie Angaben zur vorgesehenen Umgebung. Hilfreich sind außerdem vorhandene Systeme, die verbunden werden sollen, und ein Ansprechpartner für die Hardware. Daraus lässt sich ein überschaubarer Prüfauftrag formulieren. Fehlende Schnittstellen oder ungeeignete Hardware können dabei auch gegen eine Umsetzung sprechen.

Unser Beitrag kann eine Machbarkeitsbewertung, eine eigene Bedienoberfläche oder die Verbindung zu bestehender Software sein. Die konkrete Zusage erfolgt nach Prüfung der Voraussetzungen. Welche Alltagsaufgaben dafür grundsätzlich interessant sein könnten, zeigt der Artikel Haushaltsroboter und individuelle Software.