HCR Lab Robotikforschung

Dieser Blogbeitrag dokumentiert meine Robotikreise während meines Grundstudiums an der Colorado School of Mines, von der Entdeckung meiner Leidenschaft in CSCI473, über mein CS Field Session Projekt im Sommer 2020, bis zu meiner Forschungsarbeit im Human Centered Robotics (HCR) Labor von Februar 2021 bis September 2021.

Hintergrund

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

Ich hatte das Glück, meine Leidenschaft früh im Leben zu finden. Während der High School verbrachte ich viel Zeit damit herauszufinden, was mir gefällt und worin ich gut sein könnte. Nach einigen Versuchen und Fehlern erkannte ich, dass meine Leidenschaft Informatik war. Aber es war auch in dieser Zeit, dass ich entdeckte, dass ich eine überwältigende Liebe zum Bauen durch Code habe.

An den Mines erhielt ich die Möglichkeit, im Human Centered Robotics (HCR) Labor von Mines unter Dr. Hao Zhang zu arbeiten. Ich traf Dr. Zhang erstmals im Frühling 2020 durch seinen Kurs „Human Centered Robotics“ (CSCI473) und nach dem Chaos von COVID und dem Unterricht konnte ich Anfang Frühling 2021 in seinem Labor arbeiten.

Human Centered Robotics (CSCI473) Kurs

Der Human Centered Robotics (CSCI473) Kurs von Mines war einer der wenigen Kurse meiner College-Erfahrung, die einen tiefgreifenden Einfluss auf mich hatten. Der Kurs wurde von Dr. Hao Zhang gelehrt. Unsere gesamte Note für den Kurs bestand aus nur drei Projekten, von denen jedes ein herausforderndes Problem präsentierte, das Kernkonzepte der Robotik einführte. Diese Projekte bestanden aus:

1. Lernen des Robot Operating System (ROS)
2. Verstärkendes Lernen für das Folgen von Wänden durch Roboter
3. Robotisches Verständnis menschlicher Verhaltensweisen mittels skelettbasierter Darstellungen

🧩 Lernen 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. Dies beinhaltete:

• Einrichtung von ROS Melodic, was ich auf meinem HP-Laptop von 2011 erledigte, der ausreichend war
• Installation und Konfiguration von ROS und Gazebo
• Durcharbeiten des gazebosim-Tutorials und des e-manual-Tutorials.

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

Diese Aufgabe klang zwar einfach, war aber schwieriger als sie aussah. Dieses Projekt führte mich schließlich in das Konzept von Open-Loop- und Closed-Loop-Systemen ein. Mehr über dieses Projekt und meine Lösung erfährst du auf der Projektseite ROS Move Turtle.

🧩 Verstärkendes Lernen für das Folgen von Wänden durch Roboter

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

In diesem Projekt werden die Studierenden Verstärkungslern‑Algorithmen entwerfen und implementieren, um einem autonomen mobilen Roboter das Folgen einer Wand und das Vermeiden von Kollisionen beizubringen. Die Studierenden werden die Gazebo‑Simulation in ROS Melodic nutzen, um einen omnidirektionalen mobilen Roboter namens Triton zu simulieren, und eine bereitgestellte Umgebungs­karte verwenden. Die Studierenden werden einen Laserscanner am Roboter einsetzen, um Sensorik und Lernen durchzuführen, wobei der Roboter mittels Lenk‑ und Geschwindigkeitsbefehlen gesteuert wird. Die Studierenden müssen dieses Projekt in C++ oder Python in ROS Melodic auf Ubuntu 18.04 LTS programmieren (d. h. dieselbe Entwicklungsumgebung wie in Projekt 1). Außerdem müssen die Studierenden einen Bericht nach dem Format von Standard‑IEEE‑Robotik‑Konferenzen mit LATEX schreiben.

Für den Verstärkungslern‑Algorithmus wurden wir angewiesen, Q-Learning zu 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 zudem ein Labyrinth für den Roboter zur Verfügung gestellt. Insgesamt sah die Umgebung so aus:

Für die vollständige Projektbeschreibung siehe csci473-p2.pdf. 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 ärgerlich, den Code in der richtigen Umgebung zum Laufen zu bringen. Ich habe jedoch ein Demovideo, das ich der Klasse eingereicht habe und das meine Lösung zeigt. Du kannst es hier ansehen:

🧩 Robotisches Verständnis menschlicher Verhaltensweisen mittels skelettbasierter Darstellungen

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

In diesem Projekt werden die Studierenden mehrere skelettbasierte Darstellungen (Liefergegenstand 1) implementieren und Support Vector Machines (SVMs) (Liefergegenstand 2) verwenden, um menschliche Verhaltensweisen anhand eines öffentlichen Aktivitätsdatensatzes, der mit einem Kinect‑V1‑Sensor aufgenommen wurde, zu klassifizieren. Zusätzlich müssen die Studierenden einen Bericht nach dem Format von Standard‑IEEE‑Robotik‑Konferenzen mit LATEX im Liefergegenstand 3 schreiben.

Dieses Projekt war herausfordernd, aber nicht so schwierig wie das zweite Projekt. Das Hauptziel war, Kinect V1-Sensordaten aus dem MSR Daily Activity 3D Dataset und Support Vector Machines zu nutzen, um bestimmte menschliche Aktionen/Verhaltensweisen zu klassifizieren. Mehr über dieses Projekt und meine Lösung erfährst du auf der Projektseite Predict Human Actions Using LIBSVM.

CSCI473 Fazit

CSCI473 ist einer, wenn nicht sogar der beste Kurs, den ich während meines Grundstudiums an den Mines belegt habe. All diese Projekte lehrten mich viel und ermöglichten mir ein tolles Portfolio von Projekten, auf das ich in meinem Lebenslauf zurückgreifen kann. Es war auch der erste Kurs, in dem ich das Gefühl hatte, in meinem Element zu sein, da ich nie ein guter Prüfling war, aber bei der Umsetzung von Projekten glänzte. Durch diesen Kurs traf ich auch Dr. Hao Zhang, der mir schließlich half, eine Position als Forschungsassistent im Human‑Centered Robotics (HCR) Labor von Mines zu sichern.

CS Field Session (Sommer 2020)

Im Sommer 2020, zwischen dem Abschluss von CSCI473 und dem Einstieg ins HCR‑Labor, belegte ich CSCI370 oder „Advanced Software Engineering“ als Teil meines Informatik‑Grundstudiums an der Colorado School of Mines. CSCI370 ist ein Kurs, in dem die Studierenden Software‑Lösungen für ein Unternehmen entwerfen, implementieren und dokumentieren. Er ermöglicht es den Studierenden, ihr im Studium erworbenes Wissen auf reale Informatik‑Probleme anzuwenden. Mehr über den Kurs erfährst du hier.

Im Kurs kannst du entscheiden, an welchem Projekt/Unternehmen du arbeiten möchtest. Der Kurs stellte PDFs bereit, die jedes Projekt und Unternehmen detailliert beschreiben. Letztendlich entschied ich mich für ein Projekt, das von einem Unternehmen namens Lunar Outpost veröffentlicht wurde, mit dem Titel „Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation“. Da der Name lang ist, geben wir dem Projekt den Alias „Wheel Slippage Detection“.

Das Problem

Lunar Outpost ist ein Startup, das autonome Mondrover entwickeln will. Auf dem Mond gibt es viel Mondstaub, der für erhebliche Raddurchrutschungen bekannt ist. Das ist nicht ideal, weil Raddurchrutschen autonome Systeme dazu bringen kann, ihre reale Position zu verlieren. Auf der Erde wird das durch die Nutzung von GPS‑Daten gelöst, um etwaige durch Raddurchrutschen verursachte Abweichungen zu korrigieren. Das Problem beim GPS ist jedoch, dass es nur funktioniert, weil 30+ Navigationssatelliten die Erde ständig umkreisen und eindeutige Signale senden, die es Computern ermöglichen, ihre Position zu berechnen. Auf dem Mond gibt es jedoch derzeit kein GPS. Daher muss eine andere Methode als GPS verwendet werden, um Raddurchrutschen zu erkennen. Ein detaillierterer Bericht über das Problem des Projekts kann hier eingesehen werden.

Das Team

Dieses Projekt war nicht einfach, daher musste es im Team durchgeführt werden. Das Team bestand aus fünf Mitstudierenden der Colorado School of Mines:

Dieses Projekt war nicht einfach, daher musste es im 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 in einem oder mehreren dieser Technologien, aber ich war der Einzige mit ROS‑Erfahrung, da ich ROS in meinem Human Centered Robotics (CSCI473) Kurs im Frühling 2020 verwendet habe. Deshalb habe ich zu Beginn allen geholfen, sich mit ROS vertraut zu machen und zu lernen, wie man dafür entwickelt.

Herausforderungen

In diesem Projekt gab es viele Herausforderungen. Die größte Herausforderung war jedoch, dass wir keinen Zugriff auf einen realen Roboter für Tests hatten. Das lag an COVID, das alles remote machte und uns daran hinderte, im Labor/Gebäude von Lunar Outpost zu arbeiten. Deshalb mussten wir Simulationen verwenden.

Also, wir haben einige akademische Forschungen vom WVU Navigationslabor durchgesehen, um eine Vorstellung davon zu bekommen, wie das Problem des Raddurchrutschens für den Anwendungsfall des Lunar Outpost gelöst werden könnte. Was für uns, als Bachelor‑Studenten im zweiten und dritten Jahr, schwieriger war als erwartet.

Eine weitere Herausforderung war die Zeit, die wir für dieses Projekt zur Verfügung hatten. CSCI370 ist ein einmonatiger Kurs. Aber das Problem selbst ist ein riesiges Problem, das viele Unternehmen und Wissenschaftler seit Jahrzehnten zu lösen bzw. zu perfektionieren versuchen. Ein Monat ist also bei weitem nicht genug Zeit, um dieses Problem zu lösen. Trotzdem haben wir trotz all dieser Herausforderungen durchgehalten und dafür gesorgt, dass wir liefern konnten.

Fazit

Nach der Durcharbeitung aller Forschung und Entwicklung stellten wir fest, dass es fast unmöglich ist, die korrekte Mondphysik digital zu simulieren, sodass das Ausprobieren dieses Algorithmus in einer Simulation keinen Sinn ergibt und keine bedeutende Forschung zur Erkennung von Raddurchrutschen im Weltraum und auf dem Mond liefern wird. Wir kamen zu dem Schluss, dass das Einrichten 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 aktualisiert, sodass er als ROS‑Node funktioniert, und er funktionierte korrekt und konnte leicht in echte Hardware für Tests importiert werden. Dieses Projekt ermöglichte es mir, eine Führungsrolle zu übernehmen, meine Mitstudierenden in ROS‑Entwicklung zu schulen und Erfahrung mit Python, ROS und Gazebo zu sammeln, während ich ein komplexes Problem anging, dem ich zuvor nie begegnet war. Am wichtigsten ist, dass diese Erfahrung meine Leidenschaft für Robotik weiter gefestigt und meinen Wunsch bestärkt hat, Forschung in diesem Bereich zu betreiben, und den Grundstein für das legte, was in meiner Robotik‑Reise als Nächstes kommen würde.

Einstieg im HCR‑Labor

Nach dem Abschluss von CSCI473, meiner CS‑Feldsession im Sommer 2020 und meinem Herbstsemester 2020 entschied ich mich, Forschung im Bereich Robotik zu betreiben. Ich hatte so großartige Erfahrungen sowohl mit CSCI473 als auch mit der CS‑Feldsession, dass ich beschloss, im HCR‑Labor zu forschen. Da ich Dr. Zhang bereits im Vorjahr kennengelernt hatte, schrieb ich ihm eine E‑Mail und fragte nach möglichen Möglichkeiten im Labor im Januar 2021. Innerhalb von etwa zwei 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 ein paar Monate nach meinem Einstieg im HCR‑Labor aufgenommen habe. Es wurde im Mai 2021 aufgenommen und behandelt die Forschung, auf die ich mich im Sommer 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‑Wheel‑Bodenroboter, angetrieben von NVIDIAs Jetson Nano.

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

• NVIDIA Jetson Nano
• NVIDIAs Seed Studio A205 Trägerplatine
• Arduino Mega
• 64 GB Micro‑SD‑Karte
• Individuell 3D‑gedruckter Körper
• 3 Mecanum‑Räder
• 1 AR‑Batterie
• Individuelle Schaltungen für optimierte Stromverteilung und Verkabelung
• Intels Realsense D435 Kamera
• Einige LEDs

Er wurde etwa 2018–2020 als Bildungsroboter entworfen, gebaut und hergestellt. Als ich eintrat, war der Triton bereits ziemlich etabliert, und das Labor erwog, eine neue Version davon zu erstellen. Das Hauptproblem des Triton war jedoch seine Software. Der Triton konnte sich bewegen, laden und grundlegend funktionieren, aber er führte nichts Intelligentes aus. Es fehlte ihm sogar die Fähigkeit, komplexere Bewegungen auszuführen.

Zusätzlich zu diesem aufgebauten Bereich hatte jeder Triton drei graue Kugel‑Marker am oberen Teil seines Körpers befestigt.

Mit diesem Aufbau hatten wir effektiv unser eigenes GPS‑System im Kleinformat gebaut, das uns ermöglichte, die genauen Koordinaten in Metern eines Tritons in unserem Interessensbereich zu erhalten. Durch die Verwendung der Optitrack Infrarotkameras und der grauen Optitrack‑Kugeln in einer dreieckigen Anordnung konnten wir die genauen Koordinaten eines Tritons in unserem Bereich bestimmen. Dies ermöglichte es uns, ein Closed‑Loop‑System für höhere Bewegungsgenauigkeit anzuwenden.

Das Optitrack‑System lieferte Positions‑ und Orientierungsdaten mit etwa 120 Hz und sub‑millimetergenauer Genauigkeit, wenn es korrekt kalibriert war. Die drei reflektierenden Marker jedes Tritons bildeten ein einzigartiges dreieckiges Muster, das das System als starren Körper verfolgen konnte. Das Koordinatensystem wurde so kalibriert, dass (0,0) im Zentrum des Verfolgungsbereichs lag, wobei die X‑ und Y‑Achsen an die Raumgeometrie ausgerichtet waren. Trotz dieser präzisen Positionsdaten hatte der Triton jedoch weiterhin Schwierigkeiten mit der Bewegung.

Mit diesem Aufbau wollten wir dem Triton eine Kernfunktion bereitstellen: die Fähigkeit, zu einer bestimmten Koordinate zu fahren. Der Benutzer oder seine Software konnte eine (x, y)‑Koordinate innerhalb des Interessensbereichs angeben. Dann würde der Roboter zu dieser Koordinate so schnell, genau und nahtlos wie möglich fahren. Als ich eintrat, existierte diese Funktion, funktionierte jedoch nicht gut. Hier ist eine einfache Animation, die zeigt, wie die ursprüngliche Bewegungslogik funktionierte:

Ich habe die ursprüngliche Lösung nicht in Aktion aufgenommen, also habe ich diese einfache Animation erstellt, die die alte Bewegungslogik in Aktion zeigt. In Anbetracht dessen, was sind die Probleme mit dieser Methode?

1. Sie ist wirklich langsam
2. Sie lässt den Roboter viel Platz beanspruchen, nur um zu einem bestimmten Punkt zu fahren. Das machte es schwierig, diese Lösung zu verwenden, wenn mehrere Tritons gleichzeitig unterwegs waren.

Warum trat dieses Verhalten also auf? Das Problem war, dass der Triton zuerst drehte und dabei sein Alpha änderte, bis er innerhalb einer bestimmten Fehlertoleranz zum Zielpunkt ausgerichtet war. Dann sprintte er vorwärts, und nachdem sein Theta um einen bestimmten Betrag vom Ziel abwich, hielt er an und begann erneut zu drehen, bis das Alpha innerhalb des akzeptablen Bereichs für das Ziel lag. Dann sprintte er wieder und wiederholte diesen Vorgang, bis er den Punkt erreichte. Außerdem wurde die Dreh‑ und Sprintgeschwindigkeit immer langsamer, je näher er dem Zielpunkt kam, um ein Überschießen zu verhindern. Dies führte dazu, dass der Triton unnatürliche Bewegungen zeigte, ewig brauchte, um einen Zielpunkt zu erreichen, und so viel Fläche benötigte, um zu einem bestimmten Zielpunkt zu gelangen. Angesichts all dieser Probleme und der wesentlichen Bedeutung dieser Funktion für die Entwicklung des Triton‑Projekts war meine erste Aufgabe im HCR‑Labor, effektivere Lösungen zu entwickeln, die dem Triton eine bessere Navigation zu einem Zielpunkt ermöglichen.

In Anbetracht dessen verbrachte ich viel Zeit mit der Recherche nach der bestmöglichen Lösung für dieses Problem. Ironischerweise belegte ich an der Mines einen Kurs namens Einführung in Regelungssysteme (EENG307). Zu Beginn dieses Kurses lernten wir das Konzept von Open‑Loop‑Reglern und Closed‑Loop‑Reglern kennen. In Anbetracht dessen und nach einer Diskussion mit dem Professor dieses Kurses und meinem klugen Mitbewohner wurde klar, dass das Ziel, den Triton zu einem Zielpunkt zu bringen, ein Closed‑Loop‑Systemproblem ist.

Nach umfangreichen Tests und Forschungen entwickelte ich zwei unterschiedliche Regleransätze für die Tritons:

Methode 1: Distance‑Theta‑Regler

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

• Distance‑Regler: Berechnete die euklidische Distanz zum Ziel und wendete einen proportionalen Verstärkungsfaktor an, um die Vorwärts‑/Rückwärts‑Geschwindigkeit zu bestimmen
• Theta‑Regler: Berechnete den Winkel­fehler zwischen der aktuellen Ausrichtung des Roboters und der gewünschten Ausrichtung zum Ziel und wendete 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 separate proportionale Verstärkungen wurden angewendet, um jeweils lineare und Winkelgeschwindigkeiten zu erzeugen.

Dies führte dazu, dass der Triton natürlich zum Ziel drehte, während er gleichzeitig vorwärts fuhr, wodurch glatte Kurvenbahnen entstanden. Der Hauptvorteil war, dass der Roboter stets seine Vorderseite zum Ziel ausgerichtet hielt, was für kamera‑basierte Anwendungen entscheidend war.

Methode 2: X‑Y‑Koordinaten‑Regler

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

• X‑Regler: Steuerte die Ost‑West‑Bewegung direkt basierend auf dem X‑Koordinaten‑Fehler
• Y‑Regler: Steuerte die Nord‑Süd‑Bewegung direkt basierend auf dem Y‑Koordinaten‑Fehler

Die Implementierung berechnete X‑ und Y‑Koordinatenfehler unabhängig, wendete separate proportionale Verstärkungen an und transformierte dann diese globalen Geschwindigkeitskomponenten in den lokalen Koordinatenrahmen des Roboters mittels Rotationsmatrizen. Diese Transformation war notwendig, weil das Omni‑Rad‑Antriebssystem des Roboters Geschwindigkeiten in seinem eigenen Referenzrahmen benötigte, nicht in globalen Koordinaten. Diese Methode erzeugte die direktesten Pfade zu den Zielen und war deutlich schneller, jedoch würde die Ausrichtung des Roboters driften, da keine explizite Orientierungssteuerung vorhanden war.

Für Methode #1 habe ich in meinem Move Turtle (TurtleSim) Blog ausführlich über diese Methode geschrieben. Ich empfehle dringend, diesen Blog zu lesen, um alle Details darüber zu erhalten, wie PID‑Regler im Allgemeinen funktionieren und wie Methode #1 funktioniert. Ich entwickelte Methode #1 mit ROS’ TurtleSim und übertrug dann diesen Code auf den Triton und aktualisierte ihn, um einer realistischeren Umgebung Rechnung zu tragen.

Method #2 verwendete einen ganz anderen, aber ebenso effektiven Ansatz. Anstatt über die Orientierung des Roboters und die Entfernung zum Ziel nachzudenken, behandelt diese Methode die Bewegung wie ein Koordinatenebenen‑Problem. Der Regler berechnet kontinuierlich den Fehler in beiden X‑ und Y‑Richtungen separat. Zum Beispiel, wenn der Roboter von (0,0) nach (2,3) fahren muss, sieht er dies als Korrektur eines 2‑Meter‑Fehlers in X und eines 3‑Meter‑Fehlers in Y. Zwei proportionale Regler arbeiteten gleichzeitig: einer passte die Geschwindigkeit des Roboters in X‑Richtung basierend auf dem X‑Fehler an, während der andere die Bewegung in Y‑Richtung basierend auf dem Y‑Fehler steuerte. Dies erzeugte einen direkteren Pfad zum Ziel, ähnlich wie sich ein 3D‑Druckkopf bewegt, und ermöglichte glatte diagonale Bewegungen. Der Roboter musste sich nicht explizit drehen, um sein Ziel anzusehen, was diese Methode besonders effektiv in engen Räumen oder bei präziser Positionierung macht.

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

Was früher 30–45 Sekunden für eine einfache Punkt‑zu‑Punkt‑Bewegung dauerte, dauerte nun etwa 8–12 Sekunden. Noch wichtiger ist, dass der Triton nun effizienter in engen Räumen navigieren konnte, was für unsere Multi‑Roboter‑Szenarien nützlich wurde.

Entwicklungsherausforderungen und Fehlersuche

Die Implementierung dieser Regler war nicht einfach und beinhaltete mehrere bedeutende Fehlersuch‑Herausforderungen:

Koordinatensystem‑Transformationen: Einer der kniffligsten Aspekte war, die Koordinatentransformationen korrekt zu erhalten. Das Optitrack‑System lieferte Daten in seinem eigenen Koordinatenrahmen, der Roboter hatte seinen lokalen Koordinatenrahmen, und ich musste zwischen ihnen genau konvertieren. Frühe Implementierungen ließen Roboter in die falschen Richtungen fahren, weil ich Rotationsmatrix‑Berechnungen verwechselt hatte.

Real‑World vs. Ideales Verhalten: Die größte Herausforderung bestand darin, reale Faktoren zu berücksichtigen, die in der Lehrbuch‑Regelungstheorie nicht vorkommen. Die Räder des Roboters hatten unterschiedliche Reibungseigenschaften, die Motoren reagierten nicht identisch, und es gab stets eine gewisse Latenz in der Kommunikationskette vom Optitrack über die Steuerungssoftware bis zum Arduino des Roboters. Ich verbrachte Wochen damit, proportionale Verstärkungen zu justieren und Deadband‑Filter hinzuzufügen, um diesen physikalischen Realitäten Rechnung zu tragen.

Oszillation‑ und Stabilitätsprobleme: Meine ersten Implementierungen litten unter Oszillationsproblemen, bei denen Roboter ihre Ziele überschossen und hin‑und‑her wackelten. Das lehrte mich die Bedeutung von Derivat‑Termen in PID‑Reglern und die Notwendigkeit einer ordentlichen Verstärkungs‑Abstimmung. Ich entschied mich schließlich für überwiegend proportionale Regelung mit sorgfältig abgestimmten Verstärkungen statt vollem PID, da die inhärente Dämpfung des Systems für die meisten Anwendungen ausreichend war.

Mehrroboter‑Interferenz: Als mehrere Roboter gleichzeitig arbeiteten, entdeckte ich unerwartete Interferenzmuster. Roboter „kämpften“ manchmal um denselben Raum oder erzeugten Deadlock‑Situationen, in denen sie sich gegenseitig unendlich blockierten. Das führte dazu, dass ich Koordinationsmechanismen und Kollisionsvermeidungs‑Algorithmen implementierte.

Multi‑Triton‑Steuerungssystem

Nachdem ich das Bewegungsproblem des einzelnen Tritons gelöst hatte, bestand die nächste Herausforderung des Labors darin, mehrere Tritons gleichzeitig zusammenarbeiten zu lassen. Dies wurde zu einem meiner Hauptfokusbereiche und erwies sich als bedeutender Beitrag zum Projekt.

Das ursprüngliche System konnte 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, ähnlich wie selbstfahrende Autos miteinander kommunizieren, um den Verkehrsfluss zu optimieren und bessere SLAM‑Karten (Simultaneous Localization and Mapping) zu erstellen.

Um dies zu lösen, implementierte ich einen Multi‑Processing‑Ansatz mit der Python‑Multiprocessing‑Bibliothek. Jeder Triton erhielt seinen eigenen dedizierten Prozess, der unabhängig laufen konnte, während er dennoch von einem zentralen Steuerungssystem koordiniert wurde. Dies ermöglichte es mehreren Tritons, gleichzeitig zu bewegen, ohne die Regelkreise der anderen zu stören.

Multi‑Roboter‑Architekturdesign

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

Haupt‑Controller‑Prozess: Dieser diente als zentrale Koordinator, der Benutzeroberflächen‑Interaktionen, Pfadplanung und hoch‑level Koordination zwischen Robotern handhabte. Er hielt den globalen Zustand aufrecht und verteilte Befehle an einzelne Roboter‑Prozesse.

Individuelle Roboter‑Prozesse: Jeder Triton hatte seinen eigenen dedizierten Python‑Prozess, der Folgendes behandelte:

• Echtzeit‑PID‑Regelungsberechnungen bei ~50 Hz
• Kommunikation mit der Hardware des Roboters (Arduino/Jetson)
• Lokale Pfadausführung und Hindernisvermeidung
• Statusberichte zurück an den Haupt‑Controller

Gemeinsame Speicher‑Kommunikation: Ich nutzte Python’s multiprocessing.shared_memory und Queue‑Objekte, um eine effiziente Kommunikation zwischen Prozessen zu ermöglichen. Dies erlaubte eine Echtzeit‑Koordination ohne den Overhead der Netzwerkkommunikation.

Synchronisations‑Mechanismen: Um Konflikte zu verhindern, wenn mehrere Roboter koordinieren mussten (wie das Vermeiden von Kollisionen), implementierte ich Semaphoren und Locks, die es Robotern ermöglichten, exklusiven Zugriff auf bestimmte Bereiche des Arbeitsraums anzufordern.

Die Herausforderung bestand darin, sicherzustellen, dass alle Roboter ihre Regelkreise unabhängig betreiben konnten, während gleichzeitig die globale Koordination erhalten blieb. Jeder Roboter‑Prozess führte eigene PID‑Berechnungen durch und sendete Motorbefehle direkt an die Hardware, während der Haupt‑Prozess die hoch‑level Koordination wie Kollisionsvermeidung und Pfadplanung übernahm.

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

• Fahrzeug‑zu‑Fahrzeug‑Kommunikationsszenarien
• Koordinierte Pfadplanung mit Hindernisvermeidung
• Schwarmrobotik‑Verhalten
• Multi‑Agent‑SLAM‑Kartierung
• Formations‑Steuerung und Folgeverhalten

Hier sieht man, wie das Labor-Setup mit mehreren gleichzeitig laufenden Tritons aussah:

Ich entwickelte außerdem eine benutzerfreundliche Oberfläche, die es Forschern ermöglichte, Pfade für jeden Triton visuell zu definieren. Man konnte buchstäblich den Pfad zeichnen, den jeder Roboter folgen sollte, und sie führten diese Pfade mit perfekter Koordination aus. Das war unglaublich nützlich, um komplexe Experimente einzurichten, ohne jede Bewegung manuell zu programmieren.

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

Hier ist eine Playlist, die die Tritons in Aktion zeigt, von Einzel‑Roboter‑Steuerung bis hin zur Multi‑Roboter‑Koordination: Tritons in Action Playlist

Integration von Tiefensensoren und Koordinatenkorrektur

Ein weiterer bedeutender Fortschritt, an dem ich arbeitete, beinhaltete die Nutzung der Intel RealSense D435 Tiefenkameras, die an jedem Triton montiert sind. Während das Optitrack‑System uns unglaublich präzise Positionsdaten lieferte, wollte ich untersuchen, wie die Roboter ihre eingebauten 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 deren Positionen zu kreuzen. Dies würde mehreren Zwecken dienen:

1. Fehlerkorrektur: Wenn das Optitrack‑System einen Kalibrierungs‑Drift oder eine temporäre Verdeckung hatte, könnten Roboter die visuelle Bestätigung der Positionen der anderen nutzen, um genaue Koordinatensysteme aufrechtzuerhalten.
2. Verbessertes SLAM: Durch mehrere Roboter mit Tiefensensoren, die zusammenarbeiten, könnten wir wesentlich reichhaltigere Karten der Umgebung mit redundanten Datenpunkten erstellen.
3. Kollisionsvermeidung: Echtzeit‑Tiefenerfassung würde es Robotern ermöglichen, einander zu erkennen und zu vermeiden, selbst wenn das zentrale Steuerungssystem Kommunikationsverzögerungen hatte.

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

• Andere Tritons anhand ihrer charakteristischen dreieckigen Form und reflektierenden Kugelmarkierungen erkennen
• Relative Positionen und Orientierungen mithilfe von Tiefendaten berechnen
• Diese Messungen mit Optitrack-Daten vergleichen, um Abweichungen zu identifizieren
• Gegebenenfalls ihr Koordinatensystem in Echtzeit anpassen, um Genauigkeit zu erhalten

Experimente zur Computer Vision

Ich habe beträchtliche Zeit damit verbracht, eine 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 Distanzmessungen bei 30 Hz kamen. Die erste Herausforderung bestand darin, diese verrauschten Tiefendaten zu filtern, um sinnvolle geometrische Informationen zu extrahieren.

Versuche der Objekterkennung: Ich experimentierte mit mehrstufigen Erkennungsalgorithmen. Ich hatte einige Erfolge beim Segmentieren des Tiefenbildes, um Objekte auf Bodenniveau zu identifizieren (Wände, Decke usw. herausfiltern) und nach Objekten mit den richtigen Größenmerkmalen zu suchen, etwa ein Fußabdruck von 0,3 × 0,3 Meter. Ich versuchte, Kantenerkennung und geometrische Analyse zu nutzen, um das charakteristische Triton‑Profil zu identifizieren, mit gemischten Ergebnissen.

Experimente zur Markererkennung: Die drei reflektierenden Kugeln an jedem Triton schienen das vielversprechendste Erkennungsmerkmal zu sein. Ich experimentierte mit Blob‑Erkennungsalgorithmen, um das charakteristische dreieckige Muster von drei hellen Punkten im Tiefenbild zu identifizieren. Ich erzielte einige vielversprechende Ergebnisse unter kontrollierten Lichtbedingungen, obwohl es nicht durchgehend zuverlässig war.

Forschung zur Koordinatenfusion: Ich recherchierte Ansätze zur Fusion von visionbasierten Positionsschätzungen mit den Optitrack‑Daten, einschließlich einfacher Kalman‑Filter‑Implementierungen. Das Konzept war, Optitrack‑Daten, wenn verfügbar, stärker zu gewichten und bei Bedarf auf Vision zurückzugreifen, obwohl ich das nicht vollständig zum Laufen brachte, bevor meine Zeit im Labor endete.

Leistungsherausforderungen: Es erwies sich als Herausforderung, all diese Verarbeitung in Echtzeit neben den Steuerungsschleifen des Roboters laufen zu lassen. Ich experimentierte mit Optimierungsansätzen, um die Algorithmen mit etwa 10‑15 Hz 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 potenziell aufbauen könnten.

Hier ist ein Video, in dem ich die Computer‑Vision‑Algorithmen teste:

So sah die Ansicht des Tiefensensors während meiner Experimente aus:

Während ich die Integration des Tiefensensors nicht abgeschlossen habe, zeigte das Konzept Potenzial für Anwendungen wie die Simulation von selbstfahrenden Autos, bei denen Fahrzeuge voneinander wissen müssen, ohne ausschließlich auf externe Infrastruktur zu setzen. Die von mir begonnene Forschungsrichtung könnte künftig zur Arbeit im Labor beitragen.

Dokumentation und Wissensbewahrung

Einer meiner wichtigsten Beiträge zum HCR‑Lab und vielleicht der, auf den ich am meisten stolz bin, war das Organisieren und Bewahren aller Projektdokumentationen. Als ich dem Labor beitrat, war das Wissen zum Triton‑Projekt über mehrere Plattformen und Formate verstreut. Kritische Informationen waren verteilt über:

• Verschiedene Google‑Drive‑Konten verschiedener, bereits graduierter Studierender
• Alte E‑Mails, die im Posteingang vergraben waren
• Zufällige Dropbox‑Ordner
• Mehrere GitHub‑Repositories
• GitLab‑Repositories mit inkonsistenter Organisation
• Handschriftliche Notizen, die nur bestimmte Personen interpretieren konnten

Diese fragmentierte Dokumentation war ein großes Problem. Neue Studierende verbrachten Wochen damit, herauszufinden, wie sie anfangen sollten, und wertvolles Wissen ging ständig verloren, wenn Personen graduerten oder das Labor verließen.

Ich nahm es selbst in die Hand, dieses Problem systematisch zu lösen. Ich verbrachte unzählige Stunden damit, jedes Dokument, jeden Code, jedes Video und jede Notiz zum Triton‑Projekt aufzuspüren. Anschließend organisierte ich alles in ein zentralisiertes GitLab‑Repository mit einer klaren, logischen Struktur.

Die zentralisierte Dokumentation enthielt:

• Bauanleitungen: Schritt‑für‑Schritt‑Anleitungen zum Zusammenbauen von Tritons von Grund auf
• Software‑Einrichtung: Vollständige Anleitungen zur Einrichtung der Entwicklungsumgebung
• Code‑Dokumentation: Gut kommentierter Code mit klaren Erklärungen
• Hardware‑Spezifikationen: Detaillierte Stücklisten, Schaltpläne und PCB‑Designs
• Fehlerbehebungs‑Anleitungen: Häufige Probleme und deren Lösungen
• Video‑Tutorials: Ich erstellte und lud Lehrvideos auf YouTube hoch, darunter detaillierte Optitrack‑Kalibrierungs‑Tutorials:

Ich etablierte außerdem Dokumentationsstandards, um sicherzustellen, dass zukünftige Beiträge organisiert und zugänglich sind. Die von mir erstellte Repository‑Struktur wurde zur Grundlage aller nachfolgenden Arbeiten im Labor.

Über das reine Organisieren bestehender Dokumentation hinaus erstellte ich mehrere originale Anleitungen und Tutorials, die kritische Lücken im Wissensbestand schlossen. Diese umfassten detaillierte Installationsanweisungen für neue Labormitglieder, umfassende Fehlerbehebungs‑Anleitungen und Video‑Durchgänge komplexer Verfahren.

Die Wirkung war sofort und nachhaltig. Neue Studierende konnten sich in Tagen statt Wochen einarbeiten. Das von mir erstellte Dokumentations‑Repository wird noch heute vom Labor genutzt, Jahre nachdem ich gegangen bin. Es wurde zur einzigen Wahrheitsquelle für das Triton‑Projekt und sparte zukünftigen Forschern unzählige Stunden/Tage.

Mentoring und Wissensaustausch

Einer der lohnendsten Aspekte meiner Zeit im HCR‑Lab war die Möglichkeit, andere zu betreuen und das erworbene Wissen zu teilen. Als meine Arbeit voranschritt und ich erfahrener mit den Triton‑Systemen wurde, übernahm ich zunehmend die Verantwortung für die Schulung neuer Teammitglieder.

Nachfolger im Labor betreuen

Als ich mich darauf vorbereitete, das Labor schließlich zu verlassen, um mein Studium und meine Arbeit bei eBay abzuschließen, stellte ich sicher, dass ich zwei Personen gründlich schulte, die das Triton‑Projekt nach meinem Weggang übernehmen würden. Dabei ging es nicht nur darum, ihnen zu zeigen, wie die Dinge funktionierten, sondern sicherzustellen, dass sie die zugrunde liegenden Prinzipien wirklich verstanden, um weiter innovativ zu sein.

• Die mathematischen Grundlagen der PID‑Steuerungssysteme
• Die Multi‑Processing‑Architektur zur Koordination mehrerer Roboter
• Die Integration des Tiefensensors und die Computer‑Vision‑Algorithmen
• Das Dokumentationssystem und dessen Pflege
• Debugging‑Techniken und häufige Fehlermodi

Der Wissensaustausch war unglaublich gründlich. Wir gingen gemeinsam reale Debugging‑Sitzungen durch, ich ließ sie den bestehenden Code modifizieren und erweitern, und ich stellte sicher, dass sie neue Tritons eigenständig von Grund auf einrichten konnten.

Mentorenprogramm für die High School

Vielleicht noch lohnender war meine Erfahrung, einen High‑School‑Schüler im Rahmen des Outreach‑Programms des Labors zu betreuen. Das war eine großartige Gelegenheit, jemandem Robotik, Informatik und Forschung in einer prägenden Phase seiner Ausbildung näherzubringen.

Ich entwickelte einen umfassenden Lehrplan, der Folgendes abdeckte:

Grundlagen der Informatik:

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

Roboter‑Konzepte:

• Wie Sensoren funktionieren und wie man sie anbindet
• Aktuatorsteuerung und Motorsysteme
• Grundlagen autonomer Systeme und Rückkopplungssteuerung

ROS (Robot Operating System):

• Verständnis des Publish/Subscribe‑Nachrichtensystems
• Erstellen von Nodes und Services
• Arbeiten mit Launch‑Dateien und Parameter‑Servern

Praktische Projektarbeit:

• Wir arbeiteten zusammen an der Erstellung eines ROS‑Service, der das LED‑System auf dem Kopf des Tritons steuerte
• Sie lernte, sauberen, dokumentierten Code zu schreiben, der in unsere bestehenden Systeme integriert wurde
• Der von ihr erstellte LED‑Steuerungs‑Service wurde zu einem festen Bestandteil des Triton‑Codebases

Was diese Mentorschaft besonders besonders machte, war zu beobachten, wie sie von praktisch keinerlei Programmierkenntnissen zu bedeutenden Beiträgen in einem aktiven Forschungsprojekt überging. Sie entwickelte sich von der Frage „Was ist eine Variable?“ zu selbstständigem 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 LED‑Leuchten am Kopf des Tritons einfach über einfache ROS‑Befehle zu ändern. Das mag simpel klingen, erforderte jedoch das Verständnis der ROS‑Architektur, der Hardware‑Schnittstelle und korrekter Software‑Design‑Muster. Ihr Beitrag wird noch heute im Labor genutzt.

Die Mentorschaft war für mich genauso lehrreich wie für sie. Sie zwang mich, komplexe Konzepte in verdauliche Stücke zu zerlegen und wirklich über die Grundlagen dessen nachzudenken, was wir taten. Jemanden anderen zu unterrichten machte mich zu einem besseren Ingenieur und Forscher.

Zusammenarbeit mit PhD-Forschung

One of the most professionally rewarding aspects of my time in the lab was working closely with Peng, a PhD student whose research focused on self-driving car algorithms. The software improvements I had made to the Triton system helped support his doctoral research.

Pengs Forschung erforderte präzise, zuverlässige Multi‑Roboter‑Koordination, um Szenarien für selbstfahrende 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:

Intersection Management Studies: 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 präzisere Positionierung machten diese Studien machbarer.

Vehicle-to-Vehicle Communication: 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 operieren müssen.

SLAM and Mapping Research: Die Integration des Tiefensensors lieferte Peng zusätzliche Daten für seine Forschung zur gleichzeitigen Lokalisierung und Kartierung (SLAM). Der Einsatz mehrerer Roboter mit koordinierter Sensorkapazität ermöglichte umfassendere Kartierungsexperimente.

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

Wir verbrachten viele Stunden gemeinsam im Labor, debuggen Szenarien, diskutierten verschiedene Steuerungsstrategien und erkundeten, was die Triton‑Plattform leisten kann. Peng wurde sowohl ein Kollege als auch ein Freund, und die Zusammenarbeit mit ihm lehrte mich viel darüber, wie akademische Forschung tatsächlich funktioniert.

Die von mir entwickelten Systeme wurden zu einem nützlichen Teil von Pengs Dissertation. Zu sehen, dass meine praktischen Ingenieurbeiträge die Forschung im Bereich autonomer Fahrzeugtechnologie unterstützten, war sehr erfüllend. Es bestärkte mein Interesse daran, wie solide Ingenieurarbeit und Forschung zusammenwirken können, um nützliche Ergebnisse zu erzielen.

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

Perspektive: Die Vor‑LLM‑Ära der Entwicklung

Es ist erwähnenswert, dass all diese Arbeit während der Vor‑LLM‑Ära der Softwareentwicklung erledigt wurde. All dies fand zwischen 2020 und 2021 (hauptsächlich 2021) statt, bevor es ChatGPT, Claude, Perplexity oder KI‑gestützte Entwicklungswerkzeuge wie Cursor IDE gab.

Jede Codezeile wurde von Grund auf geschrieben, jeder Algorithmus wurde durch akademische Fachartikel und Lehrbücher recherchiert, und jede Debug‑Sitzung beinhaltete traditionelle Methoden wie Print‑Anweisungen, Debugger und methodisches Testen. Wenn ich bei einer Koordinatentransformation oder einem PID‑Abstimmungsproblem feststeckte, konnte ich nicht einfach einen KI‑Assistenten um Erklärung des Konzepts oder Hilfe beim Debuggen bitten.

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

Alles manuell recherchieren: Das Verständnis der PID‑Steuerungstheorie bedeutete, Lehrbücher und Fachartikel zu lesen. Das Erarbeiten von Koordinatentransformationen erforderte das Durchrechnen der Mathematik von Hand. Jeder Begriff musste vollständig verstanden werden, bevor er implementiert werden konnte.

Debuggen ohne KI‑Unterstützung: Wenn Roboter sich in unerwartete Richtungen bewegten oder um Ziele oszillierten, musste ich die Logik methodisch nachverfolgen, Debug‑Ausgaben hinzufügen und Hypothesen einzeln testen. Es gab keine KI, die potenzielle Probleme vorschlug oder Fehlermuster interpretierte.

Aus den ersten Prinzipien 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, ein solides Fundament in nebenläufiger Programmierung, Regelungssystemen und Computer Vision aufzubauen.

Dokumentation war entscheidend: Da ich nicht darauf vertrauen konnte, dass KI den Code später erklärt, musste ich äußerst klare Dokumentation und Kommentare schreiben. Diese Disziplin erwies sich als unschätzbar wertvoll beim Wissensaustausch mit anderen.

Rückblickend, obwohl moderne KI‑Werkzeuge viele Aspekte der Entwicklung beschleunigt hätten, zwang mich das Arbeiten ohne sie, tiefere Problemlösungsfähigkeiten und ein gründlicheres Verständnis der zugrunde liegenden Systeme zu entwickeln. Es ist faszinierend zu überlegen, wie anders dieses Projekt mit den heutigen Entwicklungswerkzeugen ausgesehen hätte.

Die schwierige Entscheidung zu gehen

So sehr ich es liebte, im HCR‑Labor zu arbeiten, stand ich Ende 2021 vor einer schwierigen Entscheidung, der viele Studierende gegenüberstehen: das Gleichgewicht zwischen mehreren Möglichkeiten und Verpflichtungen. Ich arbeitete gleichzeitig Vollzeit als Software‑Ingenieur bei eBay, schloss mein Informatikstudium an den Mines ab und trug zur Forschung im HCR‑Labor bei.

Die eBay‑Möglichkeit war bedeutend; es war meine erste größere Position als Software‑Ingenieur, bot unschätzbare Industrieerfahrung und ein solides Einkommen. Dennoch war es einfach nicht nachhaltig, Vollzeit zu arbeiten, mein Studium abzuschließen und gleichzeitig sinnvoll zur Forschung beizutragen. Etwas musste nachgeben.

Als ich Dr. Zhang ansprach, um meine Kursbelastung zu reduzieren und mich stärker auf die Laborarbeit zu konzentrieren, riet er dringend davon ab. Seine Begründung war logisch: Das Abschließen meines Studiums sollte Priorität haben, und die Industrieerfahrung bei eBay wäre für meine berufliche Entwicklung wertvoll. Er meinte, dass das Abbrechen von Kursen zugunsten der Forschung, obwohl verlockend, langfristig nicht die beste Entscheidung sei.

Also traf ich im September 2021, nach etwa acht Monaten intensiver Laborarbeit, die schwierige Entscheidung, meine Tätigkeit als Forschungsassistent zurückzuziehen, um mich auf den Abschluss meines Studiums und meine Arbeit bei eBay zu konzentrieren. Es war eine der härteren beruflichen Entscheidungen, die ich zu diesem Zeitpunkt treffen musste.

Auch nachdem ich das Labor offiziell verlassen hatte, bot ich weiterhin Unterstützung an, wann immer jemand Hilfe bei den von mir entwickelten Systemen benötigte. Ich aktualisierte die Dokumentation nach Bedarf, beantwortete Fragen zum Debuggen und half bei der Fehlersuche aus der Ferne. Die Verbindungen, die ich aufgebaut hatte, und die Investition in den Erfolg des Projekts verschwanden nicht einfach, weil ich nicht mehr offiziell Teil des Teams war.

Reflexionen und Rückblick

Jetzt, im Jahr 2025, vier Jahre später, reflektiere ich über jene Zeit mit gemischten Gefühlen. Mein Karriereweg führte mich tief in die Webentwicklung und KI/ML‑Ingenieurwesen, Bereiche, die unglaublich bereichernd waren und enorme Möglichkeiten für Wachstum und Einfluss boten.

Dennoch gibt es einen Teil von mir, der sich fragt „was wäre, wenn“. Robotik war, und ehrlich gesagt ist sie immer noch, meine wahre Leidenschaft. Es gibt etwas am Arbeiten mit physischen Systemen, daran zu sehen, wie dein Code in reale Bewegungen und Verhalten übersetzt wird, das Webentwicklung und sogar KI‑Arbeit nicht ganz nachahmen können.

Manchmal frage ich mich, was passiert wäre, wenn ich einen anderen Weg gewählt hätte. Was wäre, wenn ich einen Weg gefunden hätte, in der Robotikforschung zu bleiben? Was wäre, wenn ich sofort nach meinem Bachelorstudium ein Aufbaustudium aufgenommen hätte? Was wäre, wenn ich die Laborarbeit über die Industrieerfahrung gestellt hätte?

Aber ich erkenne auch, dass jeder Weg seine Kompromisse hat. Die Fähigkeiten, die ich in der Webentwicklung und KI erworben habe, waren unglaublich wertvoll. Die Industrieerfahrung lehrte mich Software‑Engineering im großen Maßstab, User‑Experience‑Design und die praktischen Herausforderungen beim Bau von Produkten, die von Millionen Menschen genutzt werden. 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‑Regelsysteme erforderlich ist, spiegelt sich in der Gestaltung von Feedback‑Schleifen in Softwaresystemen wider. Die von mir entwickelten Fähigkeiten zur Dokumentation und Wissensbewahrung waren in jeder nachfolgenden Rolle von unschätzbarem Wert. Die Erfahrung im Mentoring und Unterrichten hat meine Zusammenarbeit mit Junior‑Entwicklern und meinen Beitrag zum Wissensaustausch im Team geprägt.

Am wichtigsten lehrte mich die Erfahrung, dass ich aufblühe, wenn ich an herausfordernden technischen Problemen mit realer Wirkung arbeite. Ob es nun darum geht, Roboterbewegungsalgorithmen zu optimieren oder KI‑Systeme zu bauen, die Nutzern helfen, ihre Ziele zu erreichen – die Befriedigung entsteht daraus, schwierige, bedeutungsvolle Probleme zu lösen.

Der bleibende Einfluss

Rückblickend auf die HCR‑Lab‑Erfahrung bin ich erstaunt, wie viel ich in relativ kurzer Zeit erreicht habe. Die von mir entwickelten Systeme haben die Funktionsweise der Triton‑Plattform grundlegend verändert, und viele dieser Verbesserungen werden noch heute genutzt. Das von mir erstellte Dokumentations‑Repository wurde zur Wissensdatenbank für das gesamte Projekt. Die Mentoring‑Beziehungen, die ich aufgebaut habe, hatten nachhaltige Auswirkungen auf die Menschen, mit denen ich zusammenarbeitete.

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

• Verbesserte das Roboterbewegungs‑Steuerungssystem, das die Plattform eingeschränkt hatte
• Erstellte ein Multi‑Roboter‑Koordinationssystem von Grund auf
• Integrierte Computer‑Vision‑ und Sensor‑Fusionsfähigkeiten
• Erstellte ein umfassendes Dokumentations‑ und Wissensmanagementsystem
• Betreute mehrere Personen und half beim Wissenstransfer
• Unterstützte PhD‑Forschung im Bereich autonomer Fahrzeuge

Das war nicht nur über die technischen Errungenschaften, obwohl diese für mich bedeutend waren. Es ging darum zu lernen, dass man mit Beharrlichkeit und systematischem Denken nützliche Beiträge leisten kann, selbst als Grundstudium‑Student.

Die Zukunft und Robotik

Während meine Karriere mich in andere Richtungen geführt hat, hat meine Leidenschaft für Robotik nicht nachgelassen. Ich verfolge weiterhin Entwicklungen in diesem Bereich, bin begeistert von Fortschritten im Robot‑Lernen und autonomen Systemen, und ich arbeite gelegentlich in meiner Freizeit an persönlichen Robotikprojekten.

Wer weiß, was die Zukunft bringt? Die Fähigkeiten, die ich in KI und maschinellem Lernen entwickle, werden für die Robotik immer relevanter. Die Branchenerfahrung, die ich gesammelt habe, hat mir gezeigt, wie man robuste, skalierbare Systeme baut. Vielleicht gibt es eine Zukunft, in der diese verschiedenen Fäden meiner Erfahrung auf unerwartete Weise zusammenkommen.

Für den Moment bin ich dankbar für die Zeit, die ich im HCR‑Labor verbracht habe, und die Erfahrungen, die es bot. Es war eine prägende Phase, die sowohl meine technischen Fähigkeiten als auch mein Verständnis dafür, welche Art von Arbeit ich am erfüllendsten finde, geformt hat. Obwohl ich es manchmal vermisse, weiß ich, dass die Lektionen, die ich gelernt habe, und die Ansätze, die ich entwickelt habe, weiterhin alles, was ich tue, beeinflussen.

Die Roboter sind immer noch da, dienen weiterhin Forschern und ermöglichen weiterhin wichtige Arbeit. Und das ist ziemlich wunderbar.