Programmierung von Servicerobotern

Was wir für den Kunden tun

Wir nehmen Ihre Serviceplattform – einen Roboter für Lieferung, Desinfektion oder Empfang – und schreiben für sie die Betriebssoftware und die Verhaltensszenarien. Die Programmierung von Servicerobotern bedeutet bei uns das Aufsetzen des Stacks auf dem Bordrechner, die Einrichtung der Treiber von Lidar, Kameras und Fahrwerk, den Aufbau der Raumkarte und der Routenlogik. Wir produzieren weder das Fahrwerk selbst noch drucken wir das Gehäuse – es transportiert und desinfiziert die Anlage des Kunden, während wir die Steuerschicht vorbereiten, die sie das vorhersagbar tun lässt. Zur Arbeit gehört die Integration mit Ihren Systemen: Aufzug rufen, Türen öffnen, Bestellung ausgeben, Statusmeldungen über API ans Buchungssystem übergeben. Am Ende erhalten Sie keine Demo, sondern eine eingerichtete Maschine, die die vorgegebenen Aufgaben in Ihrem Gebäude abarbeitet.

Wie das im Kern funktioniert

Der Roboter baut die Raumkarte fortlaufend anhand von Lidar- und Odometriedaten auf und präzisiert sie, und lokalisiert sich dann in Echtzeit auf dieser Karte. Über der Lokalisierung arbeitet der Planer: Er legt einen globalen Weg zum Ziel und berechnet zugleich die lokale Bahn neu und umfährt Menschen, Wagen und temporäre Hindernisse. Jede Anwendungsaktion – in ein Zimmer fahren, an der Theke stehen, eine Warteschlange umfahren – wird durch ein eigenes Szenario mit Bedingungen und Störungsreaktionen beschrieben. Wir stellen Geschwindigkeitsschwellen, Sicherheitszonen und das Verhalten bei Zielverlust ein, damit die Maschine anhält und kein Hindernis rammt. Dieses gesamte Zusammenspiel aus Navigation und Szenarien ist genau das, was die Hardware des Kunden in einen funktionierenden Serviceroboter verwandelt.

Woher die Servicerobotik stammt

Als Ausgangspunkt gilt der Roboter Shakey, der am Stanford Research Institute (SRI) von 1966 bis 1972 entwickelt wurde. Es war der erste mobile Allzweckroboter, der über sein eigenes Handeln nachdenken konnte: Er nahm die Umgebung wahr, erstellte einen Plan, zerlegte den Befehl in Schritte und erholte sich nach einem Fehler. Die kommerzielle Servicerobotik startete später: Joseph Engelberger gründete 1984 die Transitions Research Corporation und stellte 1988 den ersten Krankenhausroboter HelpMate im Krankenhaus von Danbury (Connecticut) auf. HelpMate verteilte Medikamente und Proben selbst über die Etagen, und innerhalb eines Jahrzehnts arbeiteten solche Maschinen bereits in mehr als hundert Krankenhäusern. Genau diese Linie – vom Forschungsroboter Shakey zum Serienmodell HelpMate – hat die Logik von Navigation und Szenarien vorgegeben, auf der die gesamte heutige Servicetechnik beruht.

Warum der Softwareanteil kritisch ist

Bei einem Serviceroboter ist die Physik des Fahrwerks zweitrangig – das Ergebnis bestimmt die Genauigkeit der Lokalisierung und die Qualität der Szenarien. Ein Positionierfehler von zehn Zentimetern bedeutet, dass die Maschine den Türdurchgang verfehlt oder neben der Ausgabetheke stehen bleibt; eine Diskrepanz zwischen Karte und Realität führt zum Festfahren im Korridor. Deshalb beeinflussen die Einstellung der Planerparameter, die Sensorrausch-Filterung und die Kalibrierung der Sicherheitszonen das Ergebnis stärker als die Eigenschaften der Motoren. Der Roboter fährt und desinfiziert mit seiner Hardware, aber geführt wird er von der Software, und gerade von ihr hängt ab, ob er ohne Kollisionen und Bedienereingriff ankommt. Eine fachgerechte Programmierung von Servicerobotern ist keine zusätzliche Option zur Plattform, sondern die Bedingung, ohne die sie eine unbewegliche Ansammlung von Baugruppen bleibt.

Auf welchem Stack wir arbeiten

Das Basiswerkzeug ist ROS2, ein offenes Framework für die Robotik: Darauf bauen die Knotenarchitektur, der Nachrichtenaustausch zwischen Sensoren und Steuerung sowie Start und Diagnose der Module auf. Die Navigation setzen wir auf dem Stack Nav2 um – das ist die reguläre Lösung für ROS2, zuständig für Kartenaufbau, Lokalisierung, globale und lokale Wegplanung sowie Verhaltensbäume. Das Zusammenspiel von ROS2 und Nav2 deckt die gesamte Route des Roboters ab: vom Empfang der Punktwolke des Lidars bis zum konkreten Befehl an den Antrieb. Die Anwendungslogik – Aufgabenreihenfolge, Reaktionen auf Ereignisse, Integration mit Aufzügen und Buchungssystemen – schreiben wir über diesem Stack für das konkrete Objekt des Kunden. Der Stack ist quelloffen und gepflegt, weshalb die Lösung nicht an einen einzelnen Anbieter gebunden ist und sich gemeinsam mit dem Ökosystem weiterentwickelt.

Wann die wichtigsten Werkzeuge entstanden

ROS (Robot Operating System) selbst entstand im Unternehmen Willow Garage: Das Projektrepository wurde am 7. November 2007 angelegt, und die Version 1.0 erschien 2010 und wurde rasch zum Branchenstandard für Forschung und Entwicklung. Die erste Generation hatte architektonische Einschränkungen für Serien- und Mehrroboteraufgaben, weshalb sie neu geschrieben wurde: Die erste Distribution ROS2 unter dem Namen Ardent Apalone erschien am 8. Dezember 2017. Nav2 entwickelte sich als Nachfolger des alten ROS-Navigationsstacks, überarbeitet für ROS2 unter Verwendung von Ansätzen aus dem autonomen Fahren. Diese Daten sind praktisch wichtig: Wir arbeiten auf der aktuellen zweiten Generation, die für den industriellen Betrieb ausgelegt ist, und nicht auf einem veralteten Zweig. Der Stack ist von Zeit und Community erprobt, was die Risiken beim langen Betrieb Ihrer Plattform senkt.

Warum Sie das uns anvertrauen können

Hinter der Entwicklung steht ein Team mit einer gesammelten IT-Erfahrung von mehr als 45 Jahren, und für uns ist ein Roboter vor allem eine technische und keine Marketingaufgabe. Wir versprechen keine Wunder von Ihrer Hardware: Wir schätzen nüchtern ein, wozu die Plattform fähig ist, und treiben die Software bis an diese Grenze. Jedes Szenario durchläuft eine Prüfung in der Simulation und am Prüfstand, bevor der Roboter in den Arbeitsbereich mit Menschen ausfährt – der scharfe Start erfolgt erst nach dem Durchfahren von Ausnahmesituationen. Wir verantworten die Steuerschicht: Navigation, Szenarien, Integrationen und die Einrichtung der Anlage des Kunden, während die Hardwareproduktion bei ihrem Hersteller bleibt. Dieser aufgeteilte Ansatz schafft einen klaren Verantwortungsbereich und ein Ergebnis, das sich reproduzieren lässt, statt nur bei einer einzigen Vorführung gut auszusehen.