Roboter nehmen Menschen so einiges an Arbeit ab – wenn sie denn funktionieren. Sobald jedoch ein Fehler auftritt, beginnt die aufwendige Suche nach der Ursache. Denn anders als bei klassischer Softwareentwicklung gibt es bei Robotern noch mehr Orte, wo sich Bugs, also Fehler verstecken können. Insbesondere sobald die Entwicklung vorangeschritten ist und die Interaktion des Roboters mit seiner Umgebung betrachtet wird. Ein Erfahrungsbericht aus der Forschung.
27. November 2023
© iStock/tickcharoen04
Gibt es vielleicht Probleme mit der generellen Stromzufuhr? Sind alle Sensoren funktionstüchtig? Kommen die erfassten Daten korrekt in der Software, also dem Gehirn des Roboters, an? Oder wurde vielleicht einfach vergessen, eine bestimmte Funktionalität zu aktivieren? Im Rahmen eines Forschungsprojekts wurde in der Analyse einer Diskussionsrunde mit Mitarbeiterinnen und Mitarbeitern aus der Robotik offensichtlich, dass das Debuggen (die Fehlersuche und -behebung) von Robotern oft zu Frustration führt. Dafür gibt es mehrere Gründe:
Aus Mangel an spezialisierten und bekannten Hilfsmitteln werden für das Debugging von Robotern hauptsächlich generische Methoden aus der Softwareentwicklung verwendet, wie beispielsweise die Ausgabe von Sensordaten in der Kommandozeile. Bei manchen Sensoren wie beispielsweise einem Laser-Scanner zeigt diese Ausgabe allerdings eine scheinbar unendlich große Matrix an Zahlen, die unmöglich von Menschen interpretiert werden kann. Für diesen Fall existieren Visualisierungswerkzeuge, wie z.B. RViz. Hier werden die gesammelten Informationen des Roboters dargestellt und damit die subjektive Umgebung des Roboters konstruiert.
Um diese subjektive Umgebung allerdings mit der realen Umgebung des Roboters abzugleichen, müssen Entwicklerinnen und Entwickler gleichzeitig einen Simulator verwenden, bzw. den Roboter im Labor beobachten. Durch diesen visuellen Kontextwechsel ist es in Echtzeit kaum zu beurteilen, ob beispielsweise der Kamerawinkel richtig eingestellt ist. Wiederholungen und Aufnahmen jedoch kosten Zeit und Nerven, genau wie jeder Versuch der Fehlerbehebung. Denn wird eine Softwareänderung ausprobiert, muss der gesamte Code zunächst erneut verpackt und neu auf den Roboter aufgespielt werden.
Wie kommt es also, dass trotz all dieser Probleme weiterhin keine spezifischen Hilfsmittel für Roboter-Debugging verwendet werden? Zum einen gibt es kaum Tools, die das Debugging im Vordergrund haben. Diverse Simulations- und Visualisierungswerkzeuge bieten zwar nützliche Funktionen, die allerdings zur Lokalisierung eines Fehlers teilweise zu komplexe oder zu wenig detaillierte Informationen liefern. Zum anderen wurde das Problem in der Forschung zwar erkannt und es wurden wiederholt Ansätze entwickelt, diese konnten sich im Markt jedoch nicht etablieren. Und weil ein Entwickler bereits ein Visualisierungstool, einen Simulator und die Konsole gleichzeitig betrachten muss, ist die Skepsis verständlich, ein weiteres Tool zu integrieren.
Im Rahmen einer Masterarbeit in Kooperation mit der LMU München wurde am Fraunhofer-Institut für Kognitive Systeme IKS nun versucht, das Problem Debugging in der Robotik aus einer anwendungsnahen Perspektive zu betrachten. Es folgten zunächst Gespräche mit Entwicklerinnen und Entwicklern sowie ausführliche Literaturrecherche. So konnten schließlich 14 Anforderungen entwickelt werden, denen eine hilfreiche Debugging-Software entsprechen sollte. Dazu gehört zum Beispiel die Visualisierung von Sensordaten direkt in der Simulation des Roboters, sowie die Integration in eines der ohnehin bereits genutzten Tools. Daraufhin begann die Entwicklung eines Prototyps.
Als Basis der Entwicklung dient Unity, eine große Game-Engines (Framework zur Spieleentwicklung) samt deren Robotik-Erweiterung, die es ermöglicht, einen Roboter zu importieren und zu simulieren. Dies erfolgt über die Netzwerk-Verbindung zwischen Unity und dem ROS-Workspace des Roboters. Das Robot Operating System (ROS) ist das Betriebssystem eines Roboters, in dessen Rahmen die Software-Seite des Roboters entwickelt wird. Im Unity-basierten Prototyp ist die Visualisierung von gesammelten Daten sowohl in 2D als auch in 3D möglich.
Des Weiteren ist ein visueller Überblick über die Architektur des Roboters integriert, aus dem ersichtlich wird, welche funktionalen Bausteine aktiv sind, woher jeder dieser Bausteine seine Informationen erhält, wohin er sie sendet, und welche Datenmengen jeweils fließen. All diese Informationen werden nahezu in Echtzeit zwischen Unity und ROS ausgetauscht.
In einem Nutzertest mit 16 Teilnehmerinnen und Teilnehmern wurde der Prototyp gegenüber den unter Robotik-Entwicklern beliebten Tools RViz und RQT evaluiert. Sowohl bei Nutzerinnen mit Robotererfahrung als auch bei unerfahrenen Testern konnte eine signifikant bessere Performance und höhere Usability (Nutzerfreundlichkeit) festgestellt werden. Dies galt gleichermaßen für alle Erfahrungslevel. Besonders erfahrene Nutzerinnen griffen jedoch auch während des Testexperiments bevorzugt auf Daten aus der Konsole zurück und begründeten das mit schlechten Erfahrungen mit den bereits bekannten Visualisierungstools.
Mit den ersten Ergebnissen dieses Projektes wurde ein grundlegender Baustein gelegt, um den Traum eines Roboter-Entwicklers zu erreichen: In einer idealen Situation, könnte man einfach eine spezielle Augmented-Reality-Brille aufsetzen, den installierten Roboter vor sich betrachten und in Echtzeit Informationen über dessen innere Vorgänge erhalten. Denn Unity als Game-Engine ist dafür bekannt, eine einfache Weiterentwicklung von Software für erweiterte und virtuelle Realität zu unterstützen. Neben der schnelleren Lokalisation von Fehlern, könnte Debugging damit letztendlich sogar Spaß machen.
