Mein Kapitel über Robotikforschung

Dieser Beitrag schildert meinen Werdegang in der Robotik, beginnend mit der Entdeckung meiner Leidenschaft für Robotik in FRC während der Highschool im 2015 bis zu meiner Zeit als wissenschaftliche Hilfskraft am Human Centered Robotics (HCR) Lab der Colorado School of Mines’s von Februar 2021 bis September 2021. Beachten Sie, dass das HCR Lab seit Ende 2022 von der Colorado School of Mines an die University of Massachusetts Amherst umgezogen ist, zusammen mit seiner Website von hcr.mines.edu zu hcr.cs.umass.edu.

Hintergrund

Ich begann mein Bachelorstudium an der Colorado School of Mines im Herbstsemester 2018. Mein Hauptfach war Informatik mit Schwerpunkt Robotik & Intelligente Systeme. Und ich schloss mein Studium im Frühjahr 2022 ab.

Ich hatte das Glück, meine Leidenschaft früh im Leben zu finden. Während der Highschool verbrachte ich viel Zeit damit, herauszufinden, was mir gefiel und worin ich gut sein könnte. Nach einigen Versuchen und Irrtümern konnte ich herausfinden, dass meine Leidenschaft die Informatik war. Aber in dieser Zeit entdeckte ich auch, dass ich eine überwältigende Liebe dafür hatte, durch Code etwas zu erschaffen.

An der Mines bekam ich die Gelegenheit, im Human Centered Robotics (HCR) Lab der Mines unter Dr. Hao Zhang zu arbeiten. Ich lernte Dr. Zhang erstmals im Frühling 2020 durch seinen Kurs „Human Centered Robotics“ (CSCI473) kennen, und nach dem Chaos von COVID und den Kursarbeiten durfte ich Anfang des Frühlings 2021 in seinem Labor arbeiten.

Kurs Human Centered Robotics (CSCI473)

Der Kurs Human Centered Robotics (CSCI473) an der Mines war einer von nur wenigen Kursen aus meiner College-Zeit, die einen tiefgreifenden Einfluss auf mich hatten. Der Kurs wurde von Dr. Hao Zhang unterrichtet. Unsere gesamte Note für den Kurs setzte sich nur aus drei Projekten zusammen, von denen jedes ein herausforderndes Problem darstellte, das zentrale Konzepte der Robotik vermittelte. Diese Projekte bestanden aus:

1. Erlernen des Robot Operating System (ROS)
2. Reinforcement Learning für das Wandfolgen eines Roboters
3. Verständnis menschlicher Verhaltensweisen durch Roboter mithilfe skelettbasierter Repräsentationen

Erlernen des Robot Operating System (ROS)

Dies war das erste Projekt, das uns zugewiesen wurde. Das Projekt bestand aus drei Aufgaben:

1. Entwicklungsumgebung einrichten
2. Gazebo-Simulator verstehen
3. Ein ROS-„Hello World“ schreiben

Für die Aufgaben 1 und 2 mussten wir lediglich unsere Entwicklungsumgebung einrichten und einem Einführungstutorial zu Gazebo folgen. Dazu gehörte:

• Einrichten von ROS Melodic, was ich auf meinem HP-Laptop von 2011 gemacht habe, der dafür gut genug war
• Installieren und Konfigurieren von ROS und Gazebo
• Durcharbeiten des Tutorials von gazebosim und des Tutorials von e-manual.

Aufgabe 3 hingegen war eine echte Herausforderung. Die Aufgabe bestand darin, turtlesim zu verwenden und die Schildkröte das Mines-„M“-Logo zeichnen zu lassen:

Diese Aufgabe war, obwohl sie einfach klang, schwieriger als sie aussah. Dieses Projekt führte mich schließlich in das Konzept von Open-Loop- und Closed-Loop-Systemen ein. Die vollständige Projektbeschreibung finden Sie in csci473-p1.pdf, oder Sie können auf der Projektseite ROS Move Turtle mehr über dieses Projekt und meine Lösung erfahren.

Reinforcement Learning für das Wandfolgen eines Roboters

Dies war das zweite Projekt, das uns zugewiesen wurde, und es war eines der schwierigsten Projekte, an denen ich je im College gearbeitet habe. Die Projektbeschreibung lautete wie folgt:

In diesem Projekt werden die Studierenden Reinforcement-Learning-Algorithmen entwerfen und implementieren, um einem autonomen mobilen Roboter beizubringen, einer Wand zu folgen und nicht gegen Hindernisse zu fahren. Die Studierenden werden die Gazebo-Simulation in ROS Melodic verwenden, um einen omnidirektionalen mobilen Roboter namens Triton zu simulieren, und dabei eine von Ihnen bereitgestellte Umgebungsmap verwenden. Die Studierenden werden einen Laser-Entfernungsscanner am Roboter verwenden, um Wahrnehmung und Lernen durchzuführen, wobei der Roboter über Lenk- und Geschwindigkeitsbefehle gesteuert wird. Die Studierenden müssen dieses Projekt in C++ oder Python in ROS Melodic auf Ubuntu 18.04 LTS programmieren (d. h. in derselben Entwicklungsumgebung wie in Projekt 1). Außerdem müssen die Studierenden einen Bericht im Format der Standard-IEEE-Robotikkonferenzen unter Verwendung von LATEX verfassen.

Für den Reinforcement-Learning-Algorithmus sollten wir Q-Learning verwenden. Wir nutzten außerdem die von der Klasse bereitgestellte Gazebo-Simulationsumgebung Stingray. Stingray bestand aus dem Triton-Modell und der Physik-Logik. Uns wurde außerdem ein Labyrinth bereitgestellt, dem der Roboter folgen sollte. Insgesamt sah die Umgebung so aus:

Ich habe meine Lösung nie auf GitHub oder im Web veröffentlicht, weil sie nicht sehr gut und stark fehlerhaft war. Außerdem ist es ziemlich schwierig und lästig, den Code in der richtigen Umgebung zum Laufen zu bringen. Ich habe jedoch ein Demo-Video, das ich bei der Klasse eingereicht habe und das meine Lösung zeigt. Sie können es hier ansehen:

Die vollständige Projektbeschreibung finden Sie in csci473-p2.pdf

Verständnis menschlicher Verhaltensweisen durch Roboter mithilfe skelettbasierter Repräsentationen

Für das dritte Projekt lautete die Projektbeschreibung wie folgt:

In diesem Projekt werden die Studierenden mehrere skelettbasierte Repräsentationen implementieren (Lieferung 1) und Support Vector Machines (SVMs) (Lieferung 2) verwenden, um menschliche Verhaltensweisen anhand eines öffentlichen Aktivitätsdatensatzes zu klassifizieren, der von einem Kinect V1- Sensor gesammelt wurde. Zusätzlich müssen die Studierenden einen Bericht im Format der Standard-IEEE-Robotikkonferenzen unter Verwendung von LATEX in Lieferung 3 verfassen.

Dieses Projekt war anspruchsvoll, aber nicht so schwierig wie das zweite Projekt. Das Hauptziel bestand darin, Sensordaten von Kinect V1 aus dem MSR Daily Activity 3D Dataset und Support Vector Machines zu verwenden, um bestimmte menschliche Handlungen/Verhaltensweisen zu klassifizieren. Die vollständige Projektbeschreibung finden Sie in csci473-p3.pdf, oder Sie können auf dem Blogbeitrag Menschliche Handlungen mit LIBSVM vorhersagen mehr über dieses Projekt und meine Lösung erfahren.

Fazit zu CSCI473

CSCI473 ist einer der, wenn nicht sogar der beste Kurs, den ich während meines Bachelorstudiums an Mines belegt habe. All diese Projekte haben mir viel beigebracht und es mir ermöglicht, ein cooles Projektverzeichnis zu haben, auf das ich zurückblicken und das ich in meinem Lebenslauf anführen kann. Es war auch der erste Kurs, in dem ich das Gefühl hatte, wirklich in meinem Element zu sein, da ich nie gut in Prüfungen war, aber beim Abschließen von Projekten glänzte. Durch diesen Kurs lernte ich außerdem Dr. Hao Zhang kennen, der mir später half, eine Stelle als wissenschaftliche Hilfskraft im Human-Centered Robotics (HCR) Lab der Mines zu bekommen.

CS-Feldsession (Sommer 2020)

Während des Sommers 2020, zwischen dem Abschluss von CSCI473 und dem Eintritt in das HCR Lab, belegte ich im Rahmen meines Bachelorstudiums in Informatik an der Colorado School of Mines CSCI370 oder „Advanced Software Engineering“. CSCI370 ist ein Kurs, der Studierende dazu bringt, softwarebezogene Lösungen für ein Unternehmen zu entwerfen, zu implementieren und zu dokumentieren. Er ermöglicht es den Studierenden, ihr Wissen aus den Lehrveranstaltungen auf reale Probleme der Informatik anzuwenden. Mehr über den Kurs erfahren Sie hier.

In dem Kurs kann man selbst entscheiden, an welchem Projekt/bei welchem Unternehmen man arbeiten möchte. Der Kurs stellte PDFs mit Einzelheiten zu jedem Projekt und Unternehmen zur Verfügung. Letztlich entschied ich mich, an einem Projekt eines Unternehmens namens Lunar Outpost mit dem Titel „Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation“ zu arbeiten. Da der Name lang ist, nennen wir das Projekt einfach „Wheel Slippage Detection“.

Das Problem

Lunar Outpost ist ein Start-up, das autonome Mondrover entwickeln will. Auf dem Mond gibt es viel Mondstaub, der bekanntermaßen starkes Durchrutschen der Räder verursacht. Das ist nicht ideal, weil das Durchrutschen der Räder dazu führen kann, dass autonome Systeme ihren tatsächlichen Standort in der realen Welt verlieren. Auf der Erde wird dieses Problem mithilfe von GPS-Daten gelöst, um jede durch das Durchrutschen der Räder verursachte Abweichung zu korrigieren. Das Problem bei GPS ist jedoch, dass es nur funktioniert, weil 30+ Navigationssatelliten ständig die Erde auf ihrer Umlaufbahn umkreisen und einzigartige Signale senden, die es Computern ermöglichen, ihre Position zu berechnen. Auf dem Mond gibt es jedoch derzeit so etwas wie GPS nicht. In Anbetracht dessen muss eine andere Methode als GPS verwendet werden, um das Durchrutschen der Räder zu erkennen. Ein detaillierterer Bericht über das Problem des Projekts kann hier eingesehen werden.

Das Team

Dieses Projekt war kein einfaches Projekt, daher musste es in einem Team durchgeführt werden. Das Team bestand aus fünf anderen Studierenden der Colorado School of Mines:

Dieses Projekt war kein einfaches Projekt, daher musste es in einem Team durchgeführt werden. Dieses Team bestand aus Mehmet Yilmaz (mir), Kane Bruce, Braedon O’Callaghan, Liam Williams und Kevin Grant.

Das Projekt erforderte Kenntnisse in ROS, C++, Python, Linux, Raspberry Pi und Arduino. Die meisten von uns hatten Erfahrung mit einer oder mehreren dieser Technologien, aber ich war der Einzige mit Erfahrung in ROS, da ich ROS in meinem Kurs Human Centered Robotics (CSCI473) während des Frühjahrssemesters 2020 verwendet hatte. Deshalb half ich zu Beginn dabei, alle mit ROS und der Entwicklung dafür vertraut zu machen.

Herausforderungen

In diesem Projekt gab es viele Herausforderungen. Aber die größte Herausforderung, vor der wir standen, war, keinen Zugang zu einem echten Roboter für Tests zu haben. Das lag an COVID, das alles auf remote umstellte und uns daran hinderte, in den Laboren/Gebäuden von Lunar Outpost zu arbeiten. Deshalb mussten wir Simulationen verwenden.

Außerdem haben wir einige wissenschaftliche Forschungsergebnisse aus dem WVU Navigation Lab durchgesehen, um eine Vorstellung davon zu bekommen, wie das Problem des Raddurchdrehens für den Anwendungsfall von Lunar Outpost gelöst werden könnte, was für uns als Studierende im zweiten und dritten Studienjahr schwieriger war, als wir erwartet hatten.

Eine weitere Herausforderung, der wir uns gegenübersahen, war die Zeit, die wir für dieses Projekt hatten. CSCI370 ist ein einmonatiger Kurs. Aber das Problem selbst ist ein riesiges Problem, an dem viele Unternehmen und Wissenschaftler seit Jahrzehnten versuchen, es zu lösen/perfektionieren. Ein Monat ist also bei weitem nicht genug Zeit, um dieses Problem zu lösen. Aber trotz all dieser Herausforderungen haben wir durchgehalten und dafür gesorgt, dass wir etwas abliefern.

Fazit

Nachdem wir uns durch die gesamte Forschung und Entwicklung gearbeitet hatten, stellten wir fest, dass es fast unmöglich ist, die richtige Mondphysik digital zu simulieren, sodass ein echtes Ausprobieren dieses Algorithmus in einer Simulation nicht sinnvoll ist und keine aussagekräftige Forschung zur Erkennung von Raddurchrutschen im Weltraum und auf dem Mond liefern wird. Wir kamen zu dem Schluss, dass der Aufbau einer geeigneten Testumgebung mit etwas wie Sand und echter Hardware, wie einem Husky-Roboter, für diese Art von Forschung weitaus wichtiger ist. Wir haben den Code zur Erkennung von Raddurchrutschen so aktualisiert, dass er als ROS-Node funktioniert, und er funktionierte korrekt und könnte problemlos in echte Hardware zum Testen übernommen werden. Dieses Projekt ermöglichte es mir, eine Führungsrolle zu übernehmen, meine Kommilitoninnen und Kommilitonen in der ROS-Entwicklung zu schulen und Erfahrungen mit Python, ROS und Gazebo zu sammeln, während ich mich einem komplexen Problem stellte, dem ich zuvor noch nie begegnet war. Am wichtigsten ist, dass diese Erfahrung meine Leidenschaft für Robotik weiter gefestigt und meinen Wunsch bestärkt hat, in diesem Bereich zu forschen, und damit die Bühne für das bereitet hat, was als Nächstes auf meiner Robotikreise kommen würde.

Beginn im HCR-Labor

Nachdem ich CSCI473, meine CS Field Session im Sommer 2020 und mein Herbstsemester 2020 abgeschlossen hatte, entschied ich mich, eine Forschung in der Robotik zu verfolgen. Ich hatte sowohl mit CSCI473 als auch mit der CS Field Session so großartige Erfahrungen gemacht, dass ich beschloss, Forschung für das HCR-Labor zu machen. Da ich Dr. Zhang im Jahr zuvor kennengelernt hatte, beschloss ich, ihm eine E-Mail zu schreiben und im Januar 2021 nach möglichen Gelegenheiten im Labor zu fragen. Innerhalb von etwa 2 Wochen zeigte Dr. Zhang Interesse, stellte mir Forschungsoptionen vor und bot mir eine Rolle im Labor an. Ich begann dann im Februar 2021 für das Labor zu arbeiten.

Einführungsvideo

Hier ist mein Einführungsvideo, das ich einige Monate nach meiner Zeit im HCR-Labor aufgenommen habe. Es wurde im Mai 2021 aufgenommen und behandelt die Forschung, auf die ich mich während des Sommers 2021 im HCR-Labor konzentrieren würde:

Mein Projekt

Während meiner Zeit im HCR-Labor konzentrierte ich mich hauptsächlich auf das Triton-Projekt. Das Triton-Projekt ist ein mobiler Roboter, der vom Human Centered Robotics Lab an der Colorado School of Mines entwickelt wurde. Es ist ein dreieckiger Omni-Rad-Bodenroboter, der von NVIDIAs Jetson Nano angetrieben wird.

Der Triton bestand in einer einfachen Übersicht aus den folgenden Teilen:

• NVIDIA Jetson Nano
• NVIDIAs Seed Studio A205 Carrier Board
• Arduino Mega
• 64 GB Micro-SD-Karte
• Benutzerdefinierter 3D-gedruckter Körper
• 3 Mecanum-Räder
• 1 AR-Batterie
• Benutzerdefinierte Schaltkreise für optimierte Stromverteilung und Verkabelung
• Intels Realsense D435-Kamera
• Einige LEDs

Er wurde etwa 2018–2020 entworfen, gebaut und hergestellt als Roboter zu Bildungszwecken. Als ich dazukam, war der Triton bereits ziemlich etabliert, und das Labor zog in Betracht, eine neue Version davon zu bauen. Das Hauptproblem beim Triton war jedoch seine Software. Der Triton konnte sich bewegen, laden und im grundlegenden Sinne funktionieren, tat aber eigentlich nichts Intelligentes. Ihm fehlte sogar die Fähigkeit, fortgeschrittenere Bewegungen auszuführen.

Um damit zu beginnen, richtete das Labor einen Bereich ein, in dem wir den Triton verfolgen konnten. Dafür schufen sie einen Bereich von 2 Metern mal 2 Metern mit 8 Optitrack Flex (Infrarot-)Kameras in einer quadratähnlichen Form etwa 6–7 Fuß über dem Boden.

Zusammen mit dem Aufbau dieses Bereichs hatten alle Tritons drei graue Kugelmarker an der Oberseite ihrer Körper befestigt.

Mit diesem Aufbau hatten wir im Grunde unser eigenes kleines GPS-System geschaffen, das es uns ermöglichte, die exakten Koordinaten eines Triton in Metern in unserem Interessengebiet zu ermitteln. Durch die Verwendung der Optitrack Infrarotkameras und der Optitrack-grauen Kugeln in einer dreieckigen Anordnung konnten wir die exakten Koordinaten eines Triton in unserem Bereich bestimmen. Das ermöglichte es uns, ein geschlossenes Regelungssystem für eine bessere Genauigkeit bei der Bewegung anzuwenden.

Das Optitrack-System lieferte Positions- und Orientierungsdaten mit etwa 120 Hz und submillimetergenauer Genauigkeit, wenn es richtig kalibriert war. Die drei reflektierenden Marker jedes Triton bildeten ein einzigartiges dreieckiges Muster, das das System als starren Körper verfolgen konnte. Das Koordinatensystem wurde so kalibriert, dass (0,0) in der Mitte des Tracking-Bereichs lag, wobei die X- und Y-Achsen an die Geometrie des Raums angepasst waren. Aber trotz dieser präzisen Positionsdaten hatte der Triton weiterhin Probleme mit der Bewegung.

Mit diesem Aufbau wollten wir dem Triton als Kernfunktion die Fähigkeit geben, sich zu einer bestimmten Koordinate zu bewegen. Der Benutzer oder seine Software konnte eine (x, y)-Koordinate innerhalb seines Interessengebiets angeben. Dann sollte sich der Roboter so schnell, genau und nahtlos wie möglich zu dieser Koordinate bewegen. Als ich dazukam, existierte diese Funktion bereits, aber sie funktionierte nicht sehr gut. Hier ist eine einfache Animation, die zeigt, wie die ursprüngliche Bewegungslogik funktionierte:

Ich habe die ursprüngliche Lösung nicht in Aktion aufgezeichnet, also habe ich diese einfache Animation erstellt, die Ihnen die alte Bewegungslogik in Aktion zeigt. Wenn man das weiß, was sind die Probleme mit dieser Methode?

1. Sie ist wirklich langsam
2. Sie bewirkt, dass der Roboter viel Platz einnimmt, nur um zu einem bestimmten Punkt zu gelangen. Das machte es für uns schwierig, diese Lösung zu verwenden, wenn sich mehrere Tritons gleichzeitig bewegten.

Warum trat dieses Verhalten also auf? Das Problem war, dass sich der Triton zuerst drehte und dabei sein Alpha änderte, bis er innerhalb einer bestimmten Fehlertoleranz auf den Zielpunkt zeigte. Dann sprintete er nach vorne, und nachdem sein Theta um einen bestimmten Betrag vom Ziel abgewichen war, hielt er an und begann erneut zu drehen, bis das Alpha wieder innerhalb des akzeptablen Bereichs für das Ziel lag. Dann sprintet er wieder los und macht so weiter, bis er den Punkt erreicht. Außerdem wurden die Dreh- und Sprintgeschwindigkeiten immer langsamer, je näher er dem Zielpunkt kam, um sicherzustellen, dass er nicht darüber hinausschoss. Dies führte dazu, dass der Triton unnatürliche Bewegungen hatte, ewig brauchte, um einen Zielpunkt zu erreichen, und so viel Fläche benötigte, nur um zu einem bestimmten Zielpunkt zu gelangen. Angesichts all dieser Probleme und der Tatsache, wie wichtig diese Funktion für die Entwicklung des Triton-Projekts war, bestand meine erste Aufgabe, als ich im HCR-Labor anfing, darin, wirksamere Lösungen zu entwickeln, die es dem Triton ermöglichen würden, sich besser zu einem Zielpunkt zu navigieren.

Da ich das wusste, verbrachte ich viel Zeit mit der Recherche nach der bestmöglichen Lösung für dieses Problem. Ironischerweise besuchte ich einen Kurs namens Einführung in Regelungssysteme mit Rückkopplung (EENG307) an der Mines. Zu Beginn dieses Kurses lernten wir das Konzept von Offen-Loop-Reglern und Geschlossen-Loop-Reglern kennen. Mit diesem Wissen und nach einigen Gesprächen, die ich mit dem Professor dieses Kurses und meinem klugen Mitbewohner führte, wurde klar, dass dieses Ziel, den Triton zu einem Zielpunkt zu bringen, ein Problem eines geschlossenen Regelungssystems war.

Nachdem ich umfangreiche Tests und Recherchen durchgeführt hatte, entwickelte ich nun zwei unterschiedliche Regleransätze für die Tritons:

Methode 1: Distanz-Theta-Regler

Dieser Ansatz verwendete zwei separate proportionale Regler, die gleichzeitig liefen:

• Distanzregler: Berechnete die euklidische Distanz zum Ziel und wandte einen proportionalen Verstärkungsfaktor an, um die Vorwärts-/Rückwärtsgeschwindigkeit zu bestimmen
• Theta-Regler: Berechnete den Winkel Fehler zwischen der aktuellen Ausrichtung des Roboters und der gewünschten Ausrichtung zum Ziel und wandte einen separaten proportionalen Verstärkungsfaktor für die Rotationsgeschwindigkeit an

Der Algorithmus berechnete kontinuierlich die euklidische Distanz zum Ziel und den Winkel Fehler zwischen der aktuellen Ausrichtung des Roboters und der gewünschten Richtung. Zwei getrennte proportionale Verstärkungsfaktoren wurden angewendet, um jeweils lineare und Winkelgeschwindigkeiten zu erzeugen.

Dies führte dazu, dass sich der Triton natürlich in Richtung des Ziels drehte, während er sich gleichzeitig vorwärts bewegte, wodurch sanfte, gekrümmte Pfade entstanden. Der entscheidende Vorteil war, dass der Roboter seine Vorderseite immer auf das Ziel ausgerichtet hielt, was für kamerabasierte Anwendungen entscheidend war.

Methode 2: X-Y-Koordinatenregler

Dieser Ansatz behandelte den Roboter wie einen 2D-Plotter mit unabhängiger Steuerung der X- und Y-Bewegung:

• X-Regler: Steuerte die Ost-West-Bewegung direkt auf Basis des X-Koordinatenfehlers
• Y-Regler: Steuerte die Nord-Süd-Bewegung direkt auf Basis des Y-Koordinatenfehlers

Die Implementierung berechnete die X- und Y-Koordinatenfehler unabhängig, wandte separate proportionale Verstärkungen an und transformierte dann diese globalen Geschwindigkeitskomponenten mithilfe von Rotationsmatrizen in das lokale Koordinatensystem des Roboters. Diese Transformation war notwendig, weil der Omnidirektantrieb des Roboters Geschwindigkeiten in seinem eigenen Bezugssystem benötigte, nicht in globalen Koordinaten. Diese Methode erzeugte die direktesten Wege zu Zielen und war deutlich schneller, aber die Ausrichtung des Roboters driftete, da keine explizite Orientierungsregelung vorhanden war.

Für Methode #1 bin ich in meinem Move Turtle (TurtleSim) Blog ausführlich auf diese Methode eingegangen. Ich empfehle Ihnen dringend, diesen Blog zu lesen, um alle Details darüber zu erfahren, wie PID-Regler im Allgemeinen funktionieren und wie Methode #1 funktioniert. Ich habe Methode #1 mit ROSs TurtleSim entwickelt, dann diesen Code auf den Triton übertragen und ihn aktualisiert, um eine realistischere Umgebung zu berücksichtigen.

Methode #2 verwendete einen ganz anderen, aber ebenso wirksamen Ansatz. Statt über die Orientierung des Roboters und die Entfernung zum Ziel nachzudenken, behandelt diese Methode die Bewegung wie ein Problem auf einer Koordinatenebene. Der Regler berechnet fortlaufend den Fehler sowohl in X- als auch in Y-Richtung getrennt. Wenn sich der Roboter beispielsweise von (0,0) nach (2,3) bewegen muss, sieht er dies als eine zu korrigierende Abweichung von 2 Metern in X und 3 Metern in Y. Zwei proportionale Regler arbeiteten gleichzeitig: Einer passte die Geschwindigkeit des Roboters in X-Richtung auf Grundlage des X-Fehlers an, während der andere die Bewegung in Y-Richtung auf Grundlage des Y-Fehlers übernahm. Dadurch entstand ein direkterer Weg zum Ziel, ähnlich wie sich der Kopf eines 3D-Druckers bewegt, und es wurden sanfte diagonale Bewegungen ermöglicht. Der Roboter musste sich nicht ausdrücklich drehen, um sein Ziel anzusehen, was diese Methode besonders wirksam in engen Räumen oder bei Anforderungen an präzise Positionierung machte.

Beide Methoden erwiesen sich als deutlich schneller und zuverlässiger als der ursprüngliche Ansatz. Um diese neuen Methoden in Aktion zu sehen, sehen Sie sich die Tritons in Action Playlist an, die alle Tritons mit den neuen Methoden in Aktion zeigt.

Was zuvor 30-45 Sekunden für eine einfache Punkt-zu-Punkt-Bewegung brauchte, dauerte nun etwa 8-12 Sekunden. Noch wichtiger war, dass der Triton nun in engen Räumen effizienter navigieren konnte, was sich für unsere Multi-Roboter-Szenarien als nützlich erwies.

Entwicklungsherausforderungen und Fehlersuche

Die Implementierung dieser Regler war nicht unkompliziert und brachte mehrere erhebliche Herausforderungen bei der Fehlersuche mit sich:

Koordinatensystem-Transformationen: Einer der schwierigsten Aspekte war, die Koordinatentransformationen richtig hinzubekommen. Das Optitrack-System lieferte Daten in seinem eigenen Koordinatensystem, der Roboter hatte sein lokales Koordinatensystem, und ich musste korrekt zwischen ihnen umrechnen. Frühe Implementierungen ließen die Roboter in die falschen Richtungen fahren, weil ich Berechnungen mit Rotationsmatrizen verwechselt hatte.

Realverhalten vs. ideales Verhalten: Die größte Herausforderung bestand darin, reale Faktoren zu berücksichtigen, die in der klassischen Regelungstheorie nicht vorkommen. Die Räder des Roboters hatten unterschiedliche Reibungseigenschaften, die Motoren reagierten nicht identisch, und es gab immer eine gewisse Latenz in der Kommunikationskette von Optitrack über die Steuerungssoftware bis zum Arduino des Roboters. Ich verbrachte Wochen damit, proportionale Verstärkungen zu justieren und Totband-Filter hinzuzufügen, um diese physikalischen Gegebenheiten zu berücksichtigen.

Oszillations- und Stabilitätsprobleme: Meine ersten Implementierungen litten unter Oszillationsproblemen, bei denen die Roboter ihre Ziele überschossen und hin und her schwankten. Dadurch lernte ich die Bedeutung der D-Anteile in PID-Reglern und die Notwendigkeit einer richtigen Verstimmungsanpassung kennen. Schließlich entschied ich mich vor allem für proportionale Regelung mit sorgfältig abgestimmten Verstärkungen statt für volles PID, da die inhärente Dämpfung des Systems für die meisten Anwendungen ausreichte.

Störungen zwischen mehreren Robotern: Wenn mehrere Roboter gleichzeitig betrieben wurden, entdeckte ich unerwartete Interferenzmuster. Roboter „stritten“ sich manchmal um denselben Raum oder erzeugten Blockadesituationen, in denen sie sich unbegrenzt gegenseitig behinderten. Das führte mich dazu, Koordinationsmechanismen und Algorithmen zur Kollisionsvermeidung zu implementieren.

Multi-Triton-Steuerungssystem

Sobald ich das Bewegungsproblem des einzelnen Triton gelöst hatte, bestand die nächste Herausforderung des Labors darin, mehrere Tritons gleichzeitig zusammenarbeiten zu lassen. Dies wurde zu einem meiner Hauptschwerpunkte und entwickelte sich zu einem wesentlichen Beitrag zum Projekt.

Das ursprüngliche System konnte immer nur einen Triton gleichzeitig steuern, was die Forschungsmöglichkeiten stark einschränkte. Das Labor wollte Szenarien simulieren, in denen mehrere autonome Fahrzeuge ihre Bewegungen koordinieren mussten, etwa selbstfahrende Autos, die miteinander kommunizieren, um den Verkehrsfluss zu optimieren und bessere SLAM-(Simultaneous Localization and Mapping)-Karten zu erstellen.

Um dies zu lösen, implementierte ich einen Multiprozess-Ansatz mithilfe der multiprocessing-Bibliothek von Python. Jeder Triton erhielt einen eigenen dedizierten Prozess, der unabhängig laufen konnte, während er dennoch von einem zentralen Steuerungssystem koordiniert wurde. Dadurch konnten sich mehrere Tritons gleichzeitig bewegen, ohne sich gegenseitig in ihren Regelkreisen zu stören.

Entwurf der Multi-Roboter-Architektur

Die von mir entwickelte Systemarchitektur bestand aus mehreren Schlüsselkomponenten:

Hauptsteuerungsprozess: Dieser diente als zentraler Koordinator und übernahm Benutzeroberflächen-Interaktionen, Pfadplanung und die hochrangige Koordination zwischen den Robotern. Er verwaltete den globalen Zustand und verteilte Befehle an die einzelnen Roboterprozesse.

Einzelne Roboterprozesse: Jeder Triton hatte seinen eigenen dedizierten Python-Prozess, der Folgendes übernahm:

• PID-Regelungsberechnungen in Echtzeit mit ~50Hz
• Kommunikation mit der Hardware des Roboters (Arduino/Jetson)
• Lokale Pfadausführung und Hindernisvermeidung
• Statusmeldungen zurück an den Hauptsteuerungsprozess

Kommunikation über gemeinsamen Speicher: Ich verwendete die multiprocessing.shared_memory- und Queue-Objekte von Python, um eine effiziente Kommunikation zwischen den Prozessen zu ermöglichen. Dies erlaubte eine Echtzeit-Koordination ohne den Overhead von Netzwerkkommunikation.

Synchronisierungsmechanismen: Um Konflikte zu vermeiden, wenn mehrere Roboter sich koordinieren mussten (etwa zur Vermeidung von Kollisionen), implementierte ich Semaphoren und Sperren, die es den Robotern erlaubten, exklusiven Zugriff auf bestimmte Bereiche des Arbeitsraums anzufordern.

Die Herausforderung bestand darin sicherzustellen, dass alle Roboter ihre Regelkreise unabhängig betreiben konnten und dennoch eine globale Koordination aufrechterhalten wurde. Jeder Roboterprozess führte seine eigenen PID-Berechnungen aus und sendete Motorbefehle direkt an die Hardware, während der Hauptprozess übergeordnete Koordination wie Kollisionsvermeidung und Pfadplanung übernahm.

Das Multi-Triton-System eröffnete völlig neue Forschungsmöglichkeiten. Wir konnten nun Folgendes simulieren:

• Fahrzeug-zu-Fahrzeug-Kommunikationsszenarien
• Koordinierte Pfadplanung mit Hindernisvermeidung
• Verhaltensweisen in der Schwarmrobotik
• Multi-Agenten-SLAM-Kartierung
• Formationsregelung und Folge-Verhalten

So sah der Laboraufbau mit mehreren gleichzeitig laufenden Tritons aus:

Ich entwickelte außerdem eine benutzerfreundliche Oberfläche, mit der Forscher Pfade für jeden Triton visuell festlegen konnten. Man konnte buchstäblich den Pfad zeichnen, dem jeder Roboter folgen sollte, und sie würden diese Pfade mit perfekter Koordination ausführen. Dies war unglaublich nützlich, um komplexe Experimente aufzusetzen, ohne jede Bewegung manuell programmieren zu müssen.

Das System konnte bis zu 5 Tritons gleichzeitig verarbeiten, wobei jeder seine eigenen PID-Regler ausführte und gleichzeitig über das zentrale Steuerungssystem koordiniert wurde. Die Leistung war beeindruckend, da alle Roboter ihre individuelle Genauigkeit beibehielten und gleichzeitig als Team zusammenarbeiteten.

Hier ist eine Playlist, die die Tritons in Aktion zeigt, von der Einzelrobotersteuerung bis zur Koordination mehrerer Roboter: Tritons in Action Playlist

Integration von Tiefensensoren und Koordinatenkorrektur

Ein weiterer wichtiger Fortschritt, an dem ich arbeitete, betraf die Nutzung der Intel-RealSense-D435-Tiefenkameras, die an jedem Triton montiert waren. Während das Optitrack-System uns unglaublich präzise Positionsdaten lieferte, wollte ich untersuchen, wie die Roboter ihre bordeigenen Sensoren nutzen könnten, um ihr räumliches Bewusstsein zu verbessern und Koordinatenfehler zu korrigieren.

Die Idee war, dass Tritons ihre Tiefensensoren nutzen könnten, um andere Tritons in ihrer Umgebung zu erkennen und ihre Positionen miteinander abzugleichen. Dies würde mehreren Zwecken dienen:

1. Fehlerkorrektur: Wenn das Optitrack-System eine Kalibrierungsdrift oder eine vorübergehende Verdeckung aufwies, könnten die Roboter die visuelle Bestätigung der Positionen der anderen nutzen, um genaue Koordinatensysteme aufrechtzuerhalten.

2. Verbessertes SLAM: Indem mehrere Roboter mit Tiefensensoren zusammenarbeiten, konnten wir deutlich reichhaltigere Karten der Umgebung mit redundanten Datenpunkten erstellen.

3. Kollisionsvermeidung: Echtzeit-Tiefenerfassung würde es Robotern ermöglichen, einander zu erkennen und auszuweichen, selbst wenn das zentrale Steuerungssystem Kommunikationsverzögerungen hätte.

Ich begann damit, mit Algorithmen zu experimentieren, die es den Tritons ermöglichen würden:

• Andere Tritons anhand ihrer markanten dreieckigen Form und reflektierenden Kugelmarker zu erkennen
• Relative Positionen und Ausrichtungen mithilfe von Tiefendaten zu berechnen
• Diese Messungen mit Optitrack-Daten zu vergleichen, um Abweichungen zu identifizieren
• Möglicherweise ihr Koordinatensystem in Echtzeit anzupassen, um die Genauigkeit aufrechtzuerhalten

Computer-Vision-Experimente

Ich verbrachte beträchtliche Zeit damit, mit einer Computer-Vision-Pipeline zu experimentieren, die in mehreren Stufen funktionierte:

Verarbeitung von Tiefendaten: Der Intel RealSense D435 lieferte sowohl RGB- als auch Tiefendatenströme. Ich arbeitete hauptsächlich mit den Tiefendaten, die als 640x480-Array von Entfernungsmessungen mit 30Hz kamen. Die erste Herausforderung bestand darin, diese verrauschten Tiefendaten zu filtern, um aussagekräftige geometrische Informationen zu extrahieren.

Versuche zur Objekterkennung: Ich experimentierte mit mehrstufigen Erkennungsalgorithmen. Ich hatte gewisse Erfolge beim Segmentieren des Tiefenbildes, um Objekte auf Bodenhöhe zu identifizieren (unter Herausfilterung von Wänden, Decke usw.) und nach Objekten mit den richtigen Größenmerkmalen zu suchen, ungefähr mit einer Grundfläche von 0,3x0,3 Metern. Ich versuchte, Kantenerkennung und geometrische Analyse zu verwenden, um das charakteristische Triton-Profil zu identifizieren, mit gemischten Ergebnissen.

Experimente zur Marker-Erkennung: Die drei reflektierenden Kugeln auf jedem Triton schienen das vielversprechendste Erkennungsmerkmal zu sein. Ich experimentierte mit Blob-Erkennungsalgorithmen, um das charakteristische Dreiecksmuster aus drei hellen Punkten im Tiefenbild zu identifizieren. Unter kontrollierten Lichtverhältnissen erzielte ich einige vielversprechende Ergebnisse, obwohl es nicht durchgehend zuverlässig war.

Forschung zur Koordinatenfusion: Ich untersuchte Ansätze zur Fusion visionbasierter Positionsschätzungen mit den Optitrack-Daten, einschließlich grundlegender Kalman-Filter-Implementierungen. Das Konzept war, den Optitrack-Daten, wenn verfügbar, mehr Gewicht zu geben, aber bei Bedarf auf Vision zurückzugreifen, obwohl ich das vor dem Ende meiner Zeit im Labor nicht vollständig zum Laufen brachte.

Leistungsherausforderungen: Es stellte sich als schwierig heraus, all diese Verarbeitung in Echtzeit neben den Steuerungsschleifen des Roboters laufen zu lassen. Ich experimentierte mit Optimierungsansätzen, um die Algorithmen mit etwa 10-15Hz auszuführen, ohne die Verarbeitungsfähigkeiten des Jetson Nano zu überlasten.

Leider musste ich das Labor verlassen, bevor ich diese Computer-Vision-Arbeit vollständig abschließen konnte. Obwohl ich einige vielversprechende frühe Ergebnisse hatte und viel über die Verarbeitung von Tiefensensoren lernte, brachte ich das System nicht in einen vollständig zuverlässigen Zustand. Es blieb eine interessante Forschungsrichtung, auf der andere möglicherweise aufbauen könnten.

Hier ist ein Video von mir beim Testen der Computer-Vision-Algorithmen:

So sah die Tiefensensor-Ansicht während meiner Experimente aus:

Obwohl ich die Arbeit zur Integration des Tiefensensors nicht abschließen konnte, zeigte das Konzept Potenzial für Anwendungen wie die Simulation von Szenarien für selbstfahrende Autos, bei denen Fahrzeuge einander wahrnehmen müssen, ohne sich ausschließlich auf externe Infrastruktur zu verlassen. Die Forschungsrichtung, die ich zu erkunden begann, könnte möglicherweise zu zukünftiger Arbeit im Labor beitragen.

Dokumentation und Wissensbewahrung

Einer meiner wichtigsten Beiträge zum HCR-Labor, und vielleicht der, auf den ich am stolzesten bin, war die Organisation und Bewahrung der gesamten Projektdokumentation. Als ich dem Labor beitrat, war das Wissen über das Triton-Projekt über mehrere Plattformen und Formate verteilt. Kritische Informationen waren verstreut über:

• Verschiedene Google-Drive-Konten, die verschiedenen Studenten gehörten, die bereits ihren Abschluss gemacht hatten
• Alte E-Mails, die in Postfächern vergraben waren
• Zufällige Dropbox-Ordner
• Mehrere GitHub-Repositories
• GitLab-Repositories mit inkonsistenter Organisation
• Handschriftliche Notizen, die nur bestimmte Personen entziffern konnten

Diese fragmentierte Dokumentation war ein riesiges Problem. Neue Studenten verbrachten Wochen allein damit, herauszufinden, wie sie anfangen sollten, und wertvolles Wissen ging ständig verloren, wenn Leute ihren Abschluss machten oder das Labor verließen.

Ich nahm es mir zur Aufgabe, dieses Problem systematisch zu lösen. Ich verbrachte unzählige Stunden damit, jedes einzelne Dokument, jeden Code, jedes Video und jede Notiz zum Triton-Projekt aufzuspüren. Anschließend organisierte ich alles in einem zentralisierten GitLab-Repository mit einer klaren, logischen Struktur.

Die zentralisierte Dokumentation umfasste:

• Bauanleitungen: Schritt-für-Schritt-Anleitungen zum Zusammenbau von Tritons von Grund auf
• Software-Setup: Vollständige Anleitungen zur Einrichtung der Entwicklungsumgebung
• Code-Dokumentation: Gut kommentierter Code mit klaren Erklärungen
• Hardware-Spezifikationen: Detaillierte Stücklisten, Verdrahtungspläne und PCB-Designs
• Fehlerbehebungsanleitungen: Häufige Probleme und ihre Lösungen
• Video-Tutorials: Ich erstellte und lud Lehrvideos auf YouTube hoch, einschließlich detaillierter Optitrack-Kalibrierungstutorials:

Ich etablierte außerdem Dokumentationsstandards, um sicherzustellen, dass zukünftige Beiträge organisiert und zugänglich bleiben würden. Die von mir erstellte Repository-Struktur wurde zur Grundlage für alle nachfolgenden Arbeiten im Labor.

Über die bloße Organisation vorhandener Dokumentation hinaus erstellte ich mehrere originelle Leitfäden und Tutorials, die kritische Lücken im Wissensbestand schlossen. Dazu gehörten detaillierte Einrichtungsanleitungen für neue Labormitglieder, umfassende Fehlerbehebungsleitfäden und Videoanleitungen zu komplexen Verfahren.

Die Wirkung war sofort und nachhaltig. Neue Studenten konnten sich in Tagen statt in Wochen einarbeiten. Das Dokumentations-Repository, das ich erstellt habe, wird vom Labor auch heute noch genutzt, Jahre nachdem ich gegangen bin. Es wurde zur einzigen verlässlichen Quelle für das Triton-Projekt und sparte zukünftigen Forschern unzählige Stunden/Tage.

Mentoring und Wissensweitergabe

Einer der lohnendsten Aspekte meiner Zeit im HCR-Labor war die Gelegenheit, andere zu betreuen und das Wissen weiterzugeben, das ich gewonnen hatte. Während meine Arbeit voranschritt und ich mit den Triton-Systemen immer erfahrener wurde, übernahm ich zunehmend Verantwortung für die Schulung neuer Teammitglieder.

Betreuung von Labor-Nachfolgern

Als ich mich darauf vorbereitete, das Labor schließlich zu verlassen, um mich auf den Abschluss meines Studiums und meine Arbeit bei eBay zu konzentrieren, stellte ich sicher, dass ich zwei Personen gründlich ausbildete, die nach meinem Weggang das Triton-Projekt übernehmen würden. Dabei ging es nicht nur darum, ihnen zu zeigen, wie die Dinge funktionierten, sondern darum, sicherzustellen, dass sie die zugrunde liegenden Prinzipien wirklich verstanden, damit sie weiter innovieren konnten.

Ich verbrachte Wochen damit, eng mit ihnen zusammenzuarbeiten und Folgendes durchzugehen:

• Die mathematischen Grundlagen der PID-Regelsysteme
• Die Multiprozess-Architektur zur Koordination mehrerer Roboter
• Die Integration von Tiefensensoren und die Computer-Vision-Algorithmen
• Das Dokumentationssystem und wie man es pflegt
• Fehlersuchtechniken und häufige Fehlerarten

Die Wissensweitergabe war unglaublich gründlich. Wir gingen gemeinsam reale Debugging-Sitzungen durch, ich ließ sie den bestehenden Code ändern und erweitern, und ich stellte sicher, dass sie in der Lage waren, neue Tritons eigenständig von Grund auf einzurichten.

Mentorenprogramm für die High School

Vielleicht noch lohnender war meine Erfahrung, im Rahmen des Outreach-Programms des Labors einen Highschool-Schüler zu betreuen. Dies war eine großartige Gelegenheit, jemanden in einer prägenden Phase seiner Ausbildung mit Robotik, Informatik und Forschung in Kontakt zu bringen.

Ich entwarf einen umfassenden Lehrplan, der Folgendes abdeckte:

Grundlagen der Informatik:

• Programmierkonzepte mit Python als Hauptsprache
• Einführung in die objektorientierte Programmierung
• Verständnis von Algorithmen und Datenstrukturen

Robotikkonzepte:

• Wie Sensoren funktionieren und wie man sie anbindet
• Aktorsteuerung und Motorsysteme
• Die Grundlagen autonomer Systeme und der Rückkopplungsregelung

ROS (Robot Operating System):

• Verständnis des Publish/Subscribe-Nachrichtensystems
• Erstellen von Knoten und Diensten
• Arbeiten mit Startdateien und Parameternservern

Praktische Projektarbeit:

• Wir arbeiteten zusammen an der Erstellung eines ROS-Dienstes, der das LED-System auf dem Kopf des Tritons steuerte
• Sie lernte, sauberen, dokumentierten Code zu schreiben, der sich in unsere bestehenden Systeme integrierte
• Der von ihr erstellte LED-Steuerungsdienst wurde zu einem dauerhaften Bestandteil der Triton-Codebasis

Was diese Betreuung besonders machte, war zu sehen, wie sie sich von jemandem, der praktisch nichts über Programmierung wusste, zu jemandem entwickelte, der bedeutsamen Code zu einem aktiven Forschungsprojekt beitrug. Sie entwickelte sich von der Frage „Was ist eine Variable?“ bis hin zum eigenständigen Debuggen von ROS-Kommunikationsproblemen und dem Schreiben eigener Service-Implementierungen.

Das von ihr entwickelte LED-Steuerungssystem ermöglichte es Forschern, die Farben und Muster der Kopf-LEDs des Tritons ganz einfach über einfache ROS-Befehle zu ändern. Das klingt vielleicht einfach, erforderte aber ein Verständnis der ROS-Architektur, der Hardware-Anbindung und geeigneter Software-Entwurfsmuster. Ihr Beitrag wird im Labor auch heute noch genutzt.

Die Betreuung war für mich ebenso lehrreich wie für sie. Sie zwang mich dazu, komplexe Konzepte in verdauliche Teile zu zerlegen und wirklich über die Grundlagen dessen nachzudenken, was wir taten. Jemand anderem etwas beizubringen, machte mich zu einem besseren Ingenieur und Forscher.

Zusammenarbeit mit der PhD-Forschung

Einer der beruflich lohnendsten Aspekte meiner Zeit im Labor war die enge Zusammenarbeit mit Peng, einem PhD-Studenten, dessen Forschung sich auf Algorithmen für selbstfahrende Autos konzentrierte. Die Softwareverbesserungen, die ich am Triton-System vorgenommen hatte, unterstützten seine Doktorandenforschung.

Pengs Forschung erforderte eine präzise, zuverlässige Koordination mehrerer Roboter, um Szenarien mit selbstfahrenden Autos zu simulieren. Vor meinen Verbesserungen an der Bewegungssteuerung und den Multi-Roboter-Systemen waren diese Experimente viel schwieriger durchzuführen. Die Roboter waren langsamer, weniger genau und konnten nicht so effektiv zusammenarbeiten.

Meine Beiträge unterstützten Pengs Forschung in mehreren Bereichen:

Studien zum Kreuzungsmanagement: Mit den verbesserten PID-Reglern und der Multi-Roboter-Koordination konnte Peng Kreuzungsszenarien simulieren, in denen mehrere „Fahrzeuge“ (Tritons) ihre Bewegungen koordinieren mussten. Das bessere Timing und die genauere Positionierung machten diese Studien praktikabler.

Fahrzeug-zu-Fahrzeug-Kommunikation: Das von mir entwickelte Multi-Processing-Framework ermöglichte es Peng, Kommunikationsprotokolle zwischen simulierten Fahrzeugen zu implementieren und zu testen. Jeder Triton konnte Entscheidungen treffen und gleichzeitig mit anderen koordinieren, ähnlich wie selbstfahrende Autos möglicherweise arbeiten müssen.

SLAM- und Kartierungsforschung: Die Arbeit zur Integration des Tiefensensors lieferte Peng zusätzliche Daten für seine Forschung zur gleichzeitigen Lokalisierung und Kartierung. Mehrere Roboter mit koordinierten Sensorfähigkeiten ermöglichten umfassendere Kartierungsexperimente.

Was unsere Zusammenarbeit besonders wertvoll machte, war, dass es nicht nur darum ging, dass ich seine Forschung unterstützte, sondern dass es eine echte Partnerschaft war. Pengs Verständnis der theoretischen Aspekte autonomer Fahrzeuge half dabei, meine praktischen Implementierungen zu informieren. Sein Feedback und seine Anforderungen drängten mich dazu, die Systeme robuster und leistungsfähiger zu machen.

Wir verbrachten viele Stunden gemeinsam im Labor, beim Debuggen von Szenarien, beim Besprechen verschiedener Steuerungsstrategien und beim Erkunden dessen, was die Triton-Plattform leisten konnte. Peng wurde sowohl zu einem Kollegen als auch zu einem Freund, und die Arbeit mit ihm lehrte mich viel darüber, wie akademische Forschung tatsächlich funktioniert.

Die von mir gebauten Systeme wurden zu einem nützlichen Bestandteil von Pengs Dissertationsarbeit. Zu sehen, wie meine praktischen Ingenieurbeiträge die Forschung an Technologien für autonome Fahrzeuge unterstützten, war wirklich erfüllend. Es bestärkte mein Interesse daran, wie solide Ingenieursarbeit und Forschung zusammenarbeiten können, um nützliche Ergebnisse zu schaffen.

Auch nachdem ich das Labor verlassen hatte, blieben Peng und ich in Kontakt. Zu wissen, dass meine Arbeit auch nach meinem Weggang weiterhin zu wichtiger Forschung beitrug, war äußerst lohnend.

Perspektive: Die Zeit vor den LLMs in der Entwicklung

Es ist erwähnenswert, dass all diese Arbeit in der Zeit vor den LLMs in der Softwareentwicklung geleistet wurde. All dies fand zwischen 2020 und 2021 statt (hauptsächlich 2021), bevor ChatGPT, Claude, Perplexity oder KI-gestützte Entwicklungstools wie Cursor IDE existierten.

Jede Codezeile wurde von Grund auf neu geschrieben, jeder Algorithmus wurde durch akademische Artikel und Lehrbücher recherchiert, und jede Debugging-Sitzung umfasste traditionelle Methoden wie print-Anweisungen, Debugger und methodisches Testen. Wenn ich bei einem Problem mit einer Koordinatentransformation oder dem PID-Tuning feststeckte, konnte ich nicht einfach einen KI-Assistenten bitten, das Konzept zu erklären oder bei der Fehlersuche zu helfen.

Das machte den Entwicklungsprozess deutlich anspruchsvoller, aber auch lehrreicher. Ich musste:

Alles manuell recherchieren: Das Verständnis der PID-Regelungstheorie bedeutete, Lehrbücher und akademische Arbeiten zu lesen. Das Herausfinden von Koordinatentransformationen erforderte, die Mathematik von Hand durchzuarbeiten. Jedes Konzept musste vor der Implementierung vollständig verstanden werden.

Ohne KI-Unterstützung debuggen: Wenn sich Roboter in unerwartete Richtungen bewegten oder um Ziele herum oszillierten, musste ich die Logik methodisch nachverfolgen, Debug-Ausgaben hinzufügen und Hypothesen einzeln testen. Es gab keine KI, die potenzielle Probleme vorschlagen oder helfen konnte, Fehlermuster zu interpretieren.

Von Grund auf lernen: Ohne die Möglichkeit, schnell zu fragen: „Wie implementiere ich Multi-Processing in Python für Robotik?“, musste ich die zugrunde liegenden Konzepte tiefgehend verstehen. Das zwang mich dazu, ein solides Fundament in nebenläufiger Programmierung, Regelungssystemen und Computer Vision aufzubauen.

Dokumentation war entscheidend: Da ich mich nicht darauf verlassen konnte, dass KI den Code später erklärte, musste ich extrem klare Dokumentationen und Kommentare schreiben. Diese Disziplin erwies sich als unschätzbar, als es darum ging, Wissen an andere weiterzugeben.

Rückblickend hätten moderne KI-Tools viele Aspekte der Entwicklung beschleunigt, aber das Arbeiten ohne sie zwang mich dazu, tiefere Problemlösungsfähigkeiten und ein gründlicheres Verständnis der zugrunde liegenden Systeme zu entwickeln. Es ist faszinierend zu bedenken, wie anders dieses Projekt mit den heutigen verfügbaren Entwicklungstools hätte verlaufen können.

Die schwierige Entscheidung zu gehen

So sehr ich die Arbeit im HCR-Labor auch liebte, stand ich Ende 2021 vor einer schwierigen Entscheidung, die viele Studierende kennen: verschiedene Chancen und Verantwortlichkeiten auszugleichen. Ich arbeitete gleichzeitig Vollzeit als Softwareingenieur bei eBay, schloss mein Informatikstudium an der Mines ab und trug zur Forschung im HCR-Labor bei.

Die Gelegenheit bei eBay war bedeutend; es war meine erste große Rolle als Softwareingenieur, sie bot unschätzbare Branchenerfahrung und verschaffte mir ein solides Einkommen. Allerdings war es einfach nicht nachhaltig, Vollzeitarbeit, den Abschluss meines Studiums und einen sinnvollen Beitrag zur Forschung gleichzeitig aufrechtzuerhalten. Irgendetwas musste nachgeben.

Als ich mit Dr. Zhang darüber sprach, möglicherweise meine Kursbelastung zu reduzieren, um mich mehr auf die Laborarbeit zu konzentrieren, riet er mir entschieden davon ab. Seine Begründung war schlüssig: Der Abschluss meines Studiums sollte Priorität haben, und die Branchenerfahrung bei eBay würde für meine berufliche Entwicklung wertvoll sein. Er fand, dass es zwar verlockend sein könnte, Kurse zugunsten der Forschung aufzugeben, dies langfristig aber vielleicht nicht die beste Entscheidung wäre.

Also traf ich im September 2021, nach etwa 8 Monaten intensiver Arbeit im Labor, die schwierige Entscheidung, meine Rolle als wissenschaftliche Hilfskraft aufzugeben, um mich auf den Abschluss meines Studiums und meine Arbeit bei eBay zu konzentrieren. Es war eine der schwierigeren beruflichen Entscheidungen, die ich zu diesem Zeitpunkt treffen musste.

Auch nachdem ich das Labor offiziell verlassen hatte, unterstützte ich weiterhin immer dann, wenn jemand Hilfe mit den Systemen brauchte, die ich gebaut hatte. Ich aktualisierte bei Bedarf die Dokumentation, beantwortete Fragen zum Debugging und half aus der Ferne bei der Fehlersuche. Die Verbindungen, die ich geknüpft hatte, und mein Einsatz für den Erfolg des Projekts verschwanden nicht einfach, nur weil ich nicht mehr offiziell Teil des Teams war.

Reflexionen und Rückblick

Jetzt, im Jahr 2025, vier Jahre später, finde ich mich dabei, mit gemischten Gefühlen auf diese Zeit zurückzublicken. Mein beruflicher Weg führte mich tief in die Webentwicklung und die AI/ML-Entwicklung, Bereiche, die unglaublich lohnend waren und enorme Möglichkeiten für Wachstum und Wirkung geboten haben.

Doch da ist ein Teil von mir, der sich fragt: „Was wäre wenn?“ Robotik war, und ist ehrlich gesagt immer noch, meine wahre Leidenschaft. Es hat etwas an der Arbeit mit physischen Systemen, daran zu sehen, wie sich dein Code in reale Bewegung und Verhalten übersetzt, das Webentwicklung und sogar KI-Arbeit nicht ganz nachbilden können.

Manchmal frage ich mich, was passiert wäre, wenn ich einen anderen Weg eingeschlagen hätte. Was wäre gewesen, wenn ich einen Weg gefunden hätte, in der Robotikforschung zu bleiben? Was wäre gewesen, wenn ich direkt nach dem Abschluss meines Bachelorstudiums ein Graduiertenstudium begonnen hätte? Was wäre gewesen, wenn ich mich dafür entschieden hätte, die Laborarbeit gegenüber der Branchenerfahrung zu priorisieren?

Aber ich erkenne auch an, dass jeder Weg seine Kompromisse hat. Die Fähigkeiten, die ich in der Webentwicklung und bei KI entwickelt habe, waren unglaublich wertvoll. Die Branchenerfahrung lehrte mich Softwareentwicklung im großen Maßstab, User-Experience-Design und die praktischen Herausforderungen beim Aufbau von Produkten, die Millionen von Menschen nutzen. Diese Erfahrungen haben mich insgesamt zu einem besseren Ingenieur gemacht.

Die Arbeit, die ich im HCR-Labor geleistet habe, beeinflusst weiterhin, wie ich heute Probleme angehe. Das systematische Denken, das für PID-Regelungssysteme erforderlich ist, zeigt sich darin, wie ich in Softwaresystemen Rückkopplungsschleifen entwerfe. Die Dokumentations- und Wissenssicherungsfähigkeiten, die ich entwickelt habe, waren in jeder meiner Rollen seitdem von unschätzbarem Wert. Die Erfahrung des Mentorings und Lehrens hat geprägt, wie ich mit Junior-Entwicklern zusammenarbeite und zum Wissensaustausch im Team beitrage.

Am wichtigsten ist jedoch, dass mir diese Erfahrung gezeigt hat, dass ich dann aufblühe, wenn ich an herausfordernden technischen Problemen arbeite, die reale Auswirkungen haben. Ob es nun darum geht, Roboterbewegungsalgorithmen zu optimieren oder KI-Systeme zu entwickeln, die Nutzern helfen, ihre Ziele zu erreichen: Die Zufriedenheit kommt daher, schwierige Probleme zu lösen, die wichtig sind.

Der bleibende Einfluss

Wenn ich auf die Erfahrung im HCR-Labor zurückblicke, fällt mir auf, wie viel ich in einer relativ kurzen Zeit erreicht habe. Die Systeme, die ich gebaut habe, veränderten grundlegend die Arbeitsweise der Triton-Plattform, und viele dieser Verbesserungen werden noch heute genutzt. Das Dokumentations-Repository, das ich erstellt habe, wurde zur Wissensbasis für das gesamte Projekt. Die Mentoring-Beziehungen, die ich aufgebaut habe, hatten einen nachhaltigen Einfluss auf die Menschen, mit denen ich gearbeitet habe.

Aber vielleicht am bedeutendsten war, dass mir diese Erfahrung zeigte, wozu ich fähig bin, wenn ich an Problemen arbeite, für die ich wirklich leidenschaftlich brenne. In diesen acht Monaten habe ich:

• Verbesserte das Steuerungssystem für die Roboterbewegung, das die Plattform eingeschränkt hatte
• Entwickelte von Grund auf ein System zur Koordination mehrerer Roboter
• Integrierte Fähigkeiten zur Computer Vision und Sensorfusion
• Erstellte ein umfassendes System für Dokumentation und Wissensmanagement
• Betreute mehrere Personen und half bei der Wissensweitergabe
• Unterstützte Forschung auf PhD-Niveau im Bereich autonomer Fahrzeuge

Es ging dabei jedoch nicht nur um die technischen Erfolge, auch wenn diese für mich bedeutungsvoll waren. Es ging darum zu lernen, dass man mit Ausdauer und systematischem Denken auch als Bachelorstudent nützliche Beiträge leisten kann.

Die Zukunft und Robotik

Obwohl mich mein beruflicher Weg in andere Richtungen geführt hat, ist meine Leidenschaft für Robotik unvermindert geblieben. Ich verfolge die Entwicklungen in diesem Bereich weiterhin, freue mich über Fortschritte beim Roboterlernen und bei autonomen Systemen, und arbeite in meiner Freizeit gelegentlich an persönlichen Robotikprojekten.

Wer weiß, was die Zukunft bringt? Die Fähigkeiten, die ich in KI und maschinellem Lernen entwickle, sind für die Robotik zunehmend relevant. Die Berufserfahrung, die ich gesammelt habe, hat mir beigebracht, wie man robuste, skalierbare Systeme aufbaut. Vielleicht gibt es eine Zukunft, in der diese verschiedenen Stränge meiner Erfahrung auf unerwartete Weise zusammenkommen.

Im Moment bin ich dankbar für die Zeit, die ich im HCR-Labor verbracht habe, und für die Erfahrungen, die es mir ermöglicht hat. Es war eine prägende Zeit, die sowohl meine technischen Fähigkeiten als auch mein Verständnis dafür geprägt hat, welche Arten von Arbeit ich am erfüllendsten finde. Auch wenn ich es manchmal vermisse, weiß ich, dass die Lektionen, die ich gelernt habe, und die Ansätze, die ich entwickelt habe, weiterhin alles beeinflussen, was ich tue.

Die Triton-Roboter sind immer noch dort, dienen weiterhin Forschenden und ermöglichen weiterhin wichtige Arbeit. Und das ist wirklich wunderbar.