# Virtuelle Roboter Benedikt Merkle <div> <p style="font-size:10pt; color:grey"> August 2024<br> </p></div> Einen Roboter zu bauen, so zeigen [[EXP LC 00-01 Experimenting with the LIDAR Carrier|die Experimente von Thomas Nyckel]], ist ein schwieriges Unterfangen. Die Implementierung eines Mechanismus, zumal eines sich autonom fortbewegenden bzw. Karten erzeugenden, muss eine Vielzahl von Faktoren der realen Welt navigieren. Thomas' LIDAR Carrier kombiniert zwei voneinander getrennte Systeme: einen sich autonom bewegenden, mobilen Roboter, der sich mittels eines frontal montierten Ultraschallsensor vor Hindernissen zu schützen sucht und den darauf montierten Verbund aus LIDAR Sensor und Einplatienencomputer, welcher den Raum, der vom ersten System navigiert wird, kartiert. Die Frage, die sich angesichts dieses Setup aufdrängt ist: warum nicht beide Systeme - Mobilität und Kartographie - miteinander verbinden? Dieser Schritt wäre mit einem Zuwachs an Komplexität verbunden, deren Reduzierung bisher aufgrund des schieren Zeitaufwand nicht angegangen wurde. Für uns, die Amateur_innen des VHLs, ist bereits die Recherche der benötigten Bauteile eine aufwändige Angelegenheit. Parallel dazu warten unterschiedliche Hersteller mit Bausätzen auf, die mit mehr oder weniger ausgearbeiteten Begleitmaterialien zu pädagogischen Bastelprojekten einladen, an deren Ende exakt jener Verbund aus mobilem System und Kartographie steht, der auch uns interessiert. Einer der bekanntesten, zu pädagogischen sowie experimentellen Zwecken eingesetzte Bausatz ist der Turtlebot, 2010 in der Willow Garage in Menlo Park entwickelt. Das offene Robot Operating System (ROS) das seitdem zum Standard aller DIY-Robotik Projekte wurde und als Middleware zwischen mechanischen Aktuatoren und Computerprozessen vermittelt, ging ebenfalls aus dieser Entwicklung hervor. Willow Garage wurde 2014 aufgelöst, der Turtlebot jedoch weiterentwickelt und erscheint mittlerweile in [Version 4](https://clearpathrobotics.com/turtlebot-4/), bereitgestellt und vertrieben durch "Clearpath Robotics, by Rockwell Automation". Die neuste Version erinnert auch optisch an jenes kommerzielle Produkt, das dem autonomen Fahren und Kartieren bereits lange vor jedem halbwegs einsatzbereiten Personenbevörderungsmittel zu breiter Popularisierung verhalf: einen Staubsaugroboter. Ich habe an dieser Stelle immer die Bemerkung eines Bochumer Kollegen, Till Heilman, im Ohr, der im Rahmen eines Workshops sinngemäß anmerkte, dass es für sich genommen keinen Wert habe, den Staubsauger zu erklären. Insbesondere für geisteswissenschaftliche Ansätze, die sich den Details aktueller Technologie nur mühsam nähern können, ufert exploratives Vorgehen, wie es in den Laboratorien der Robotik praktiziert wird, leicht aus und wird zu einem endlosen Projekt. Ergebnis dieser Mühen ist der Nachvollzug einer populären und gewöhnlichen Technologie, deren Eigenheiten seit Jahren von Akteur_innen des häuslichen Alltags weitaus detaillierter erkundet wurde, als dies in spontan ersonnenen Anordnungen eines Medienlabors möglich wäre. Andernorts werden daher in einem Verbund aus Medienwissenschaft, Soziologie uÄ, genannt Medienethnologie, Fragen an genau jene neuen Medienpraktiker_innen des Alltags gestellt, gewissermaßen die "tacit knowledge" aktueller Medienpraktiken abgefragt. Dabei bleibt jedoch die Frage nach der Technik meist auf der Strecke und das finde ich schade. So oder so - weder die Verirrung im Spielzeug des "hands-on", noch die gänzliche Verlagerung des Interesses des Fragens auf die Seite der Nutzung führen, so scheint es, heute noch zur Technik. Dazu sind digitale Systeme zweierlei zugleich zuviel: zuviel gewöhnlich und zuviel komplex. Was also tun? Eine lohnenswerte Aufgabe, die im Rahmen geisteswissenschaftlicher Forschungen realistisch zu erarbeiten ist, stellt meiner Meinung nach die Suche und Identifizierung von grundlegenden Problemstellungen dar, die einen anderen Bereich wissenschaftlicher Aktivität über längere Zeit beschäftigten und strukturierten. Die Problemstellung - "Verbinde Fahren (Zeit) und Kartieren (Raum)!" - ist eine der populärsten Szenen der Robotik. Soviel ist allein schon angesichts der unzähligen Baukastenprojekten, die auf die spielerische Lösung genau jener Problemstellung abzielen, ersichtlich. Wie wäre sich dieser Problemstellung zu nähern, ohne dafür entweder eine zeitaufwändige Einarbeitung in ein Grundlagenstudium der Robotik oder mehrere 1000€ für einen DIY-Staubsaugroboterbausatz ohne Saugfunktion in Kauf zu nehmen? Auch in Robotik Laboratorien wird bei weitem nicht alles sofort am physischen Prototypen erprobt. Ein zentraler Teil der Exploration neuer Systeme findet in diesem Feld der Wissenschaft im virtuellen Raum statt. ROS stellt hierfür eine Schnittstelle zur ebenfalls offenen 2D/3D Simulationssoftware Gazebo her. Mit dieser speziell für die Anwendung in der Robotik entwickelten Software lassen sich Systeme simulieren und für die physische Implementierung vorbereiten. Josh Newans, dessen Anleitungen mir diesen Bereich eröffnet haben, fasst das Zusammenspiel simulierter Welten in Gazebo mit den für Anwendungen im physischen Raum entwickelten Tools von ROS folgendermaßen zusammen: > With Gazebo, we can create a virtual "world", and load simulated versions of our robots into it. Simulated sensors can detect the environment, and publish the data to the same ROS topics that real sensors would, allowing easy testing of algorithms. Then, forces can be applied to the simulated actuators on the robot, taking into account things like friction. > > (https://articulatedrobotics.xyz/tutorials/ready-for-ros/gazebo) Ein notwendiger Zwischenschritt also, gewissermaßen eine Entwurfsskizze, deren technisches Setup das Setting einer Trockenübung beschreibt: Bewegungsabläufe (Computerprozesse) werden so projektiert, als befände sich das simulierte Gerät bereits im neuen, unbekannten Wesen, der Hardware. Eine geradezu optimale Ausgangslage für die Arbeit an einem Ort wie dem "Virtual Humanities Lab". Am Punkt der Entwurfsskizze der Robotik kann angesetzt werden, um Fragen an die Verbindung von Zeit und Raum ("Welt") im autonom sich bewegenden Fahrzeug zu stellen. ## ROS und Gazebo Angeleitet hat mich für die folgenden Ausführungen das fantastisch zusammengestellte Projekt ["Articulated Robotics" von Josh Newans](https://articulatedrobotics.xyz/category/build-a-mobile-robot-with-ros), das auf niedrigem Niveau in die Komplexitäten autonom navigierender Fahrzeuge einführt. Newans Projekt geht weit über das hinaus, was ich hier präsentieren werde - es simuliert komplexere Steuerungen und Sensoren im virtuellen Raum und leitet zudem detailliert zur Implementierung der Systeme im physischen Raum an. Newans Texte sind hoch informativ und geben neben Anleitungen zur Programmierung auch Einblick in den grundlegenden Aufbau der genutzten Systeme. Ich werde garnicht erst versuchen, Teile dieser Ressource hier zu verdoppeln, sondern werde Newans zitieren und mich ansonsten darauf beschränken, zu zeigen, was mir unter seiner Anleitung in Bezug auf das Projekt eines autonomen LIDAR-Carriers möglich wurde. Die Aufgabe, die ich mir eingangs stellte, war es, jene fehlende Verbindung zwischen der Navigation des Carriers und der mittels SLAM (Simultaneous Localization and Mapping, Überbegriff der Verfahren der statistischen Selbstverortung mit algorithmischen Methoden) erzeugten LIDAR-Karte, im virtuellen Raum zu simulieren. Dazu war zunächst ein virtuelles Modell eines mobilen Roboters nötig. Dieses soll zwischen simulierter Umgebung in Gazebo und dem SLAM System in ROS gebroadcastet werden können. Zu diesem Zweck kommt das "Universal Robot Description Format (URDF)" zum Einsatz. URDF nutzt die Extensible Markup Language (XML), eine Auszeichnungssprache, um Daten in einer hierarchischen Struktur zu definieren, die für Mensch und Maschinen gleichermaßen lesbar ist. Hier werden "tags" definiert, die ROS und Gazebo darüber informieren, mit was für einem Roboter sie es zu tun haben. >In URDF, a robot is made up of a series of rigid components called _links_, and the links are joined together in a parent-child tree structure, where the relationships between different links are called _joints_. Das Modell eines Roboters mit einfachem Differentialantrieb und einer Lenkrolle wird folglich definiert als Verbund aus "links" und "joints", denen teilweise Materialeingenschaften, Friktion und Farben zugeteilt werden. ![[rviz_gazebo_bot.png]] *Das mittels URDF Spezifikation konstruierte Modell in RVIZ und Gazebo.* Diese Definition des Roboters wird von ROS gebroadcastet, wobei jene *joits*, die als bewegliche Teile des Roboters definiert wurden, als zeitlicher, dynamischer Prozess protokolliert werden. >[T]here is a ROS node called `robot_state_publisher` which can take in a URDF file and automatically broadcast all the transforms from it. It will also publish the full contents of the URDF file to the topic `/robot_description` so that any other nodes that need it can all use the same file. In the URDF file each joint can be defined as "fixed", or one of a variety of movable types (e.g. continuous spinning, limited rotation, linear sliding). For the joints that are fixed, `robot_state_publisher` can just publish a static transform, but for the ones that move it needs an external value (e.g an angle or distance) to calculate the dynamic transform for that point in time. To get these values, it subscribes to a topic called `/joint_states`, which will contain `JointState` messages. > >(https://articulatedrobotics.xyz/tutorials/ready-for-ros/tf) Die `JointState` Nachrichten werden sowohl in ROS-Anwendungen wie RVIZ als auch, via eines Plugins, in Gazebo empfangen und verarbeitet. Auf dieselbe Weise lassen sich Sensoren im URDF definieren. Für den LIDAR-Sensor an der Oberseite des Roboters sieht der Code folgendermaßen aus. ```xml <gazebo reference="laser_frame"> <material>Gazebo/Red</material> <sensor name="laser" type="ray"> <pose> 0 0 0 0 0 0 </pose> <visualize>true</visualize> <update_rate>10</update_rate> <ray> <scan> <horizontal> <samples>360</samples> <min_angle>-3.14</min_angle> <max_angle>3.14</max_angle> </horizontal> </scan> <range> <min>0.3</min> <max>12</max> </range> </ray> <plugin name="laser_controller" filename="libgazebo_ros_ray_sensor.so"> <ros> <argument>~/out:=scan</argument> </ros> <output_type>sensor_msgs/LaserScan</output_type> <frame_name>laser_frame</frame_name> </plugin> </sensor> </gazebo> </robot> ``` Ersichtlich wird, dass für die Definition für Gazebo auf eine Bibliothek zurückgegriffen wird, wo ein template für einen "ray_sensor" zur Verfügung steht. Der Sensor broadcastet Output unter dem thema "/scan", das fortan den unterschiedlichen Anwendungen zur Verfügung steht. Des weiteren wird in dieser Definition aber auch grundlegendes der 2D-LIDAR Technologie notiert, formschön auf allerknappstem Raum kondensiert. Ein ray, also ein punktförmiger Strahl, der sich horizontal dreht und dabei mit einer bestimmten Reichweite eine bestimmte Zahl von Samples, also Proben entnimmt. ## SLAM im virtuellen Raum Gazebo ist ein erstaunlich einfach zu bedienendes Tool, wenn es darum geht, räumliche Settings zu bauen. Problemlos lassen sich hier Raumpläne entwerfen und ein Hindernisparcour für den Roboter konstruieren. Diese Umgebung lässt sich daraufhin mittels des simulierten LIDAR Sensors kartieren. Dazu wird der Roboter mittels Steuerung über die Tastatur so lange durch den Raum navigiert, bis eine Karte alle Hindernisse erfasst hat. ![[SLAM mapping.gif]] *Der Vorgang des Mappings eines in Gazebo gebauten Parcours.* Daraufhin lässt sich der "ROS Navigation Stack" [Nav2](https://docs.nav2.org/index.html) (ein weiteres, sehr erfolgreiches Open-Source Projekt, das von mehreren großen Namen der Industrie gefördert wird und tiefe Einblicke in die Entwicklung erlaubt) starten und auf Grundlage der erzeugten Karte kann nun die simulierte Umgebung autonom, mittels Algorithmen zur Pfadfindung navigiert werden. Dijkstra- und A*-Algorithmus sind dabei die Grundalgorithmen der Pfadfindung. Mit ihnen lassen sich die kürzesten Wege zwischen zwei Knoten in gewichteten Graphen bestimmen. ![[SLAM nav.gif]] *Navigation des kartierten, virtuellen Parcours. Nav2 errechnet eine sogenannte "costmap", eine Karte mit Gewichtungen, die Kollisionszonen in der näheren Umgebung von Hindernissen repräsentiert und zur Planung des Pfads genutzt wird. In RVIZ wird diese Karte farbig dargestellt.* Interessant bei dieser Übung ist der direkte, visuelle Vergleich der Bewegung des Roboters in Gazebo und RVIZ: In Gazebo werden die vom Navigation Stack errechneten Befehlen an die Motoren als perfekte, glatte Bewegungen durchgeführt, während RVIZ die prekäre Überlagerung von Raum und Zeit darstellt, welche der LIDAR Sensor realisiert. Die roten Indikationspunkte des Laserscans flackern und entfernen sich bei zu abrupter Bewegung von der im SLAM Verfahren erzeugten Karte, um bei Stillstand sich erneut zu stabilisieren. ## Ausblick: Experimente im virtuellen Raum Dieser Aufbau ermöglicht es, ohne viel Zeit und Kosten, Experimentalanordnungen für ein autonom navigierendes LIDAR-System zu konstruieren. Es lässt sich beispielsweise untersuchen, wie Navigation mit einer unvollständigen Karte abläuft, es lassen sich Labyrinthe bauen, die die Kartierung der horizontal drehbar gelagerten Laserpunktwolke an ihre Grenzen bringen, es lässt sich der LIDAR Sensor selbst im URDF modifizieren usw. Denkbar wäre eine Seminarsitzung mit Studierenden, während der zwei Gruppen gebildet werden. In beiden Gruppen wird gemeinsam an einem vorbereiteten Gerät mit Gazebo und RVIZ ein besonders vertrackter Parcours für den Roboter gebaut. Nach einer vorgegebenen Zeit wird die erzeugte, simulierte Welt der jeweils anderen Gruppe übergeben, die nun im Plenum, am Beamer, allein im SLAM-Modus, also in dem Modus, in dem auch der Roboter in die Welt geworfen wird, den Parcours zu navigieren hat. Auf diese Weise, indem am Punkt der Entwurfsskizze von Robotikprojekten angesetzt wird, lässt sich eine Technologie schrittweise als Technik adressieren. Eine Skizze, in ihrer Funktion als potentielle Realisation, muss alle relevanten Faktoren der Implementierung im Realen spezifizieren. Gleichzeitig weist jede Stelle der Spezifizierung Spielräume auf, die für eine *erfolgreiche* Implementierung fein zu justieren sind, wie bereits Thomas Experimente mit dem Carrier bewiesen, [[EXP LC 01-01 Rewriting the Carrier's Program to Make it Move as Slow as Possible|der am Ende nur im Schneckentempo zu bewegen war, da alles andere den sensiblen Sensor arg überforderte]]