Mein Kapitel über Robotikforschung

Dieser Beitrag erzählt von meiner Robotikreise, beginnend mit der Entdeckung meiner Leidenschaft für Robotik im FRC während der High School im 2015 bis zu meiner Zeit als wissenschaftlicher Mitarbeiter im Human Centered Robotics (HCR) Lab der Colorado School of Mines von Februar 2021 bis September 2021. Beachten Sie, dass das HCR Lab seit Ende 2022 von der Colorado School of Mines zur 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 auf Robotik und intelligenten Systemen. Und ich schloss im Frühling 2022 ab.

Ich hatte das Glück, meine Leidenschaft früh in meinem Leben zu finden. Während der High School verbrachte ich viel Zeit damit, herauszufinden, was ich mochte und worin ich gut sein könnte. Nach einigen Versuchen und Irrtümern konnte ich herausfinden, dass meine Leidenschaft die Informatik war. Aber es war auch während dieser Zeit, dass ich entdeckte, dass ich eine überwältigende Liebe zum Bauen durch Code hatte.

An der Mines hatte ich die Gelegenheit, im Human Centered Robotics (HCR) Lab unter Dr. Hao Zhang zu arbeiten. Ich traf Dr. Zhang zum ersten Mal im Frühling 2020 in seiner Klasse “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) Klasse

Die Human Centered Robotics (CSCI473) Klasse an der Mines war eine der wenigen Klassen aus meiner College-Erfahrung, die einen tiefgreifenden Einfluss auf mich hatte. Die Klasse wurde von Dr. Hao Zhang unterrichtet. Unsere gesamte Note für die Klasse bestand aus nur drei Projekten, von denen jedes ein herausforderndes Problem darstellte, das grundlegende Konzepte der Robotik einführte. Diese Projekte bestanden aus:

1. Lernen des Robot Operating System (ROS)
2. Verstärkendes Lernen für Robotern, die Wände folgen
3. Roboters Verständnis menschlichen Verhaltens mithilfe von skelettbasierten 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 nur unsere Entwicklungsumgebung einrichten und ein Einführungstutorial zu Gazebo folgen. Dies beinhaltete:

• Einrichtung von ROS Melodic, was ich auf meinem 2011 HP Laptop gemacht habe, der dafür gut genug war
• Installation und Konfiguration von ROS und Gazebo
• Durcharbeiten des gazebosim-Tutorials und des e-manuals-Tutorials.

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

Diese Aufgabe, obwohl sie einfach klang, war schwieriger als sie aussah. Dieses Projekt führte mich schließlich in das Konzept von offenen und geschlossenen Regelkreisen ein. Für die vollständige Projektbeschreibung schauen Sie sich csci473-p1.pdf an oder Sie können mehr über dieses Projekt und meine Lösung auf der ROS Move Turtle Projektseite erfahren.

Verstärkendes Lernen für Robotern, die Wände folgen

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

In diesem Projekt werden die Studierenden Verstärkungslernalgorithmen entwerfen und implementieren, um einem autonomen mobilen Roboter beizubringen, einer Wand zu folgen und Kollisionen mit Hindernissen zu vermeiden. Die Studierenden werden die Gazebo-Simulation in ROS Melodic verwenden, um einen omnidirektionalen mobilen Roboter namens Triton zu simulieren, und eine Umgebungsmappe, die Ihnen zur Verfügung gestellt wird. Die Studierenden werden einen Laser-Entfernungssensor am Roboter verwenden, um Sensorik und Lernen durchzuführen, wobei der Roboter mit Lenk- und Geschwindigkeitsbefehlen gesteuert wird. Die Studierenden sind verpflichtet, dieses Projekt in C++ oder Python in ROS Melodic, das auf Ubuntu 18.04 LTS läuft (d.h. die gleiche Entwicklungsumgebung, die in Projekt 1 verwendet wurde), zu programmieren. Außerdem sind die Studierenden verpflichtet, einen Bericht im Format der Standard-IEEE-Robotik-Konferenzen mit LATEX zu schreiben.

Für den Verstärkungslernalgorithmus wurden wir angewiesen, Q-Learning zu verwenden. Wir verwendeten auch die Stingray Gazebo-Simulationsumgebung, die von der Klasse bereitgestellt wurde. Stingray bestand aus dem Triton-Modell und der physikalischen Logik. Uns wurde auch ein Labyrinth zur Verfügung gestellt, dem der Roboter folgen sollte. Alles in allem sah die Umgebung so aus:

Ich habe meine Lösung nie auf GitHub oder im Internet veröffentlicht, weil sie nicht sehr gut und stark fehlerhaft war. Außerdem ist es ziemlich schwierig und nervig, 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. Sie können es hier ansehen:

Für die vollständige Projektbeschreibung schauen Sie sich csci473-p2.pdf an.

Roboters Verständnis menschlichen Verhaltens mithilfe von skelettbasierten Darstellungen

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

In diesem Projekt werden die Studierenden mehrere skelettbasierte Darstellungen (Lieferung 1) implementieren und Support Vector Machines (SVMs) (Lieferung 2) verwenden, um menschliches Verhalten mithilfe eines öffentlichen Aktivitätsdatensatzes zu klassifizieren, der von einem Kinect V1-Sensor gesammelt wurde. Darüber hinaus sind die Studierenden verpflichtet, einen Bericht im Format der Standard-IEEE-Robotik-Konferenzen mit LATEX in Lieferung 3 zu schreiben.

Dieses Projekt war herausfordernd, aber nicht so schwierig wie das zweite Projekt. Das Hauptziel war es, Daten des Kinect V1-Sensors aus dem MSR Daily Activity 3D Dataset und Support Vector Machines zu verwenden, um bestimmte menschliche Aktionen/Verhaltensweisen zu klassifizieren. Für die vollständige Projektbeschreibung schauen Sie sich csci473-p3.pdf an oder Sie können mehr über dieses Projekt und meine Lösung im Blogbeitrag Predict Human Actions Using LIBSVM erfahren.

CSCI473 Fazit

CSCI473 ist eine der besten Klassen, die ich während meines Bachelorstudiums an der Mines besucht habe. All diese Projekte haben mir viel beigebracht und mir ermöglicht, einen coolen Katalog von Projekten zu haben, auf den ich zurückblicken und auf meinem Lebenslauf verweisen kann. Es war auch die erste Klasse, in der ich das Gefühl hatte, in meinem Element zu sein, da ich nie ein guter Prüfer war, aber beim Abschluss von Projekten hervorragend abschnitt. Auch durch diese Klasse lernte ich Dr. Hao Zhang kennen, der mir schließlich half, eine Stelle als wissenschaftlicher Mitarbeiter im Human-Centered Robotics (HCR) Lab der Mines zu sichern.

CS Field Session (Sommer 2020)

Im Sommer 2020, zwischen dem Abschluss von CSCI473 und dem Eintritt in das HCR Lab, belegte ich CSCI370 oder “Fortgeschrittene Softwaretechnik” als Teil meines Informatik-Bachelorprogramms an der Colorado School of Mines. CSCI370 ist ein Kurs, der die Studierenden dazu bringt, softwarebezogene Lösungen für ein Unternehmen zu entwerfen, zu implementieren und zu dokumentieren. Es ermöglicht den Studierenden, ihr Wissen aus dem Unterricht auf reale Probleme der Informatik anzuwenden. Sie können mehr über den Kurs hier erfahren.

Im Kurs dürfen Sie entscheiden, an welchem Projekt/Unternehmen Sie arbeiten möchten. Der Kurs stellte PDFs zur Verfügung, die jedes Projekt und Unternehmen detailliert beschrieben. Letztendlich entschied ich mich, an einem Projekt zu arbeiten, das von einem Unternehmen namens Lunar Outpost veröffentlicht wurde, das “Echtzeit-Radschlupfdetektion und Fehlerkorrekturen für verbesserte lunare Navigation” heißt. Da der Name lang ist, nennen wir das Projekt “Radschlupfdetektion”.

Das Problem

Lunar Outpost ist ein Startup, das versucht, autonome Mondrover zu entwickeln. Auf dem Mond gibt es viel Mondstaub, der dafür bekannt ist, viel Radschlupf zu verursachen. Dies ist nicht ideal, da Radschlupf dazu führen kann, dass autonome Systeme ihren Standort in der realen Welt verlieren. Auf der Erde wird dies durch die Verwendung von GPS-Daten gelöst, um jegliche Abweichung, die durch Radschlupf verursacht wird, zu korrigieren. Aber das Problem mit GPS ist, dass es nur funktioniert, wenn 30+ Navigationssatelliten ständig die Erde umkreisen und einzigartige Signale übertragen, die es Computern ermöglichen, ihre Position zu berechnen. Aber auf dem Mond gibt es derzeit kein GPS. In Anbetracht dessen muss eine andere Methode als GPS verwendet werden, um Radschlupf 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 im Team durchgeführt werden. Das Team bestand aus fünf weiteren Studierenden der Colorado School of Mines:

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

Das Projekt erforderte, dass wir etwas über ROS, C++, Python, Linux, Raspberry Pi und Arduino wussten. 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 meiner Human Centered Robotics (CSCI473) Klasse im Frühling 2020 verwendet hatte. Daher half ich frühzeitig, alle über ROS und die Entwicklung dafür auf den neuesten Stand zu bringen.

Herausforderungen

In diesem Projekt gab es viele Herausforderungen. Aber die größte Herausforderung, der wir gegenüberstanden, war der Mangel an Zugang zu einem echten Roboter für Tests. Dies war auf COVID zurückzuführen, das alles remote machte und uns daran hinderte, im Labor/Gebäuden des Lunar Outpost zu arbeiten. Daher mussten wir Simulationen verwenden.

Außerdem haben wir einige akademische Forschungen vom WVU Navigation Lab durchgesehen, um eine Vorstellung davon zu bekommen, wie das Problem des Radschlupfs 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 wir erwartet hatten.

Eine weitere Herausforderung, der wir gegenüberstanden, war die Menge an Zeit, die wir für dieses Projekt hatten. CSCI370 ist ein einmonatiger Kurs. Aber das Problem selbst ist ein massives Problem, das viele Unternehmen und Akademiker seit Jahrzehnten zu lösen/zu perfektionieren versuchen. Ein Monat ist also bei weitem nicht genug Zeit, um dieses Problem zu lösen. Aber trotz all dieser Herausforderungen haben wir durchgehalten und sichergestellt, dass wir liefern.

Fazit

Nach der Bearbeitung aller Forschung und Entwicklung haben wir festgestellt, dass es fast unmöglich ist, die richtigen Mondphysiken digital zu simulieren, sodass der Versuch, diesen Algorithmus in einer Simulation zu testen, nicht gut ist und keine bedeutende Forschung zur Radschlupferkennung im Weltraum und auf dem Mond liefern wird. Wir kamen zu dem Schluss, dass es viel wichtiger ist, eine geeignete Testumgebung mit etwas wie Sand und echter Hardware, wie einem Husky-Roboter, einzurichten. Wir haben den Code zur Radschlupferkennung aktualisiert, damit er als ROS-Knoten funktioniert, und er funktionierte ordnungsgemäß und konnte leicht in echte Hardware zum Testen importiert werden. Dieses Projekt ermöglichte es mir, eine Führungsrolle zu übernehmen, meine Kollegen in der ROS-Entwicklung zu schulen und Erfahrungen mit Python, ROS und Gazebo zu sammeln, während ich ein komplexes Problem angegangen bin, dem ich zuvor nie begegnet war. Am wichtigsten ist, dass diese Erfahrung meine Leidenschaft für Robotik weiter gefestigt und meinen Wunsch verstärkt hat, Forschung auf diesem Gebiet zu betreiben, und den Grundstein für das gelegt hat, was als Nächstes in meiner Robotik-Reise kommen würde.

Beginn im HCR-Labor

Nach dem Abschluss von CSCI473, meinem CS Field Session im Sommer 2020, und meinem Herbstsemester 2020 beschloss ich, Forschung im Bereich Robotik zu betreiben. Ich hatte so großartige Erfahrungen sowohl mit CSCI473 als auch mit dem CS Field Session, dass ich beschloss, Forschung für das HCR-Labor zu machen. Da ich Dr. Zhang im Jahr zuvor getroffen hatte, beschloss ich, ihm eine E-Mail zu schreiben und nach möglichen Möglichkeiten im Labor im Januar 2021 zu fragen. Innerhalb von etwa 2 Wochen zeigte Dr. Zhang Interesse, präsentierte mir Forschungsoptionen und bot mir eine Rolle im Labor an. Ich begann dann im Februar 2021 im Labor zu arbeiten.

Einführungsvideo

Hier ist mein Einführungsvideo, das ich einige Monate nach meinem Eintritt ins HCR-Labor aufgenommen habe. Es wurde im Mai 2021 aufgenommen und behandelt die Forschung, auf die ich mich im HCR-Labor während des Sommers 2021 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 handelt sich um einen dreieckigen Omni-Rad-Ground-Roboter, der von NVIDIA’s Jetson Nano betrieben wird.

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

• NVIDIA Jetson Nano
• NVIDIA’s 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 zwischen 2018 und 2020 als Roboter für Bildungszwecke entworfen, gebaut und hergestellt. Als ich beitrat, war der Triton bereits recht etabliert, und das Labor überlegte, eine neue Version davon zu erstellen. Das Hauptproblem mit dem Triton war jedoch seine Software. Der Triton konnte sich bewegen, aufladen und funktionierte in einem grundlegenden Sinne, aber er tat nicht wirklich etwas Intelligentes. Es fehlte ihm sogar die Fähigkeit, fortgeschrittenere Bewegungen auszuführen.

Um dieses Problem anzugehen, richtete das Labor einen Bereich ein, in dem wir den Triton verfolgen konnten. Dazu schufen sie einen 2 Meter mal 2 Meter großen Bereich mit 8 Optitrack Flex (Infrarot) Kameras in einer quadratischen Form, etwa 6-7 Fuß über dem Boden.

Zusätzlich zu diesem Bereich hatte jeder Triton drei graue Kugeln an der Oberseite seiner Körper angebracht.

Mit diesem Setup hatten wir effektiv unser eigenes GPS-System im kleinen Maßstab aufgebaut, das es uns ermöglichte, die genauen Koordinaten in Metern eines Triton in unserem Interessensbereich zu erhalten. Durch die Verwendung der Optitrack Infrarotkameras und der Optitrack grauen Kugeln in einer dreieckigen Form konnten wir die genauen Koordinaten eines Triton in unserem Bereich bestimmen. Dies ermöglichte es uns, ein geschlossenes Regelungssystem für eine bessere Genauigkeit in der Bewegung anzuwenden.

Das Optitrack-System lieferte Positions- und Orientierungsdaten mit etwa 120 Hz und sub-millimeter 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) im Zentrum des Verfolgungsbereichs lag, wobei die X- und Y-Achsen an die Geometrie des Raumes ausgerichtet waren. Aber trotz dieser präzisen Positionsdaten hatte der Triton immer noch Schwierigkeiten mit der Bewegung.

Mit diesem Setup war eine Kernfunktion, die wir dem Triton bieten wollten, die Fähigkeit, zu einer bestimmten Koordinate zu bewegen. Der Benutzer oder ihre Software konnte eine (x, y) Koordinate innerhalb ihres Interessensbereichs angeben. Dann würde sich der Roboter so schnell, genau und nahtlos wie möglich zu dieser Koordinate bewegen. Als ich beitrat, existierte diese Funktion, funktionierte jedoch 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 aufgenommen, also habe ich diese einfache Animation erstellt, die dir die alte Bewegungslogik in Aktion zeigt. In Anbetracht dessen, was sind die Probleme mit dieser Methode?

1. Es ist wirklich langsam
2. Es lässt den Roboter viel Platz einnehmen, nur um zu einem bestimmten Punkt zu gelangen. Das machte es uns schwer, diese Lösung zu verwenden, wenn mehrere Tritons sich bewegten.

Warum trat dieses Verhalten auf? Das Problem war, dass der Triton zuerst drehte, seine Alpha änderte, bis er auf den Zielpunkt innerhalb eines bestimmten Fehlers zeigte. Dann sprintete er vorwärts, und nachdem sein Theta um einen bestimmten Betrag vom Ziel abwich, hielt er an und begann erneut zu drehen, bis die Alpha innerhalb des akzeptablen Bereichs für das Ziel war. Dann sprintete er wieder und machte dies weiter, bis er den Punkt erreichte. Außerdem wurde die Dreh- und Sprintgeschwindigkeit, je näher er dem Zielpunkt kam, viel langsamer, um sicherzustellen, dass er nicht über das Ziel hinausschoss. Dies führte dazu, dass der Triton unnatürliche Bewegungen hatte, ewig brauchte, um zu einem Zielpunkt zu gelangen, und so viel Platz benötigte, nur um zu einem bestimmten Zielpunkt zu gelangen. Angesichts all dieser Probleme und wie entscheidend diese Funktion für die Entwicklung des Triton-Projekts war, war meine erste Aufgabe, als ich im HCR-Labor zu arbeiten begann, effektivere Lösungen zu entwickeln, die es dem Triton ermöglichen würden, besser zu einem Zielpunkt zu navigieren.

In Anbetracht dessen verbrachte ich viel Zeit mit der Forschung nach der bestmöglichen Lösung für dieses Problem. Ironischerweise belegte ich einen Kurs mit dem Titel Einführung in Regelungssysteme (EENG307) an der Mines. Zu Beginn dieses Kurses lernten wir das Konzept der Offenen Regelkreise und Geschlossenen Regelkreise. In Anbetracht dessen und nach einigen Diskussionen, die ich mit dem Professor dieses Kurses und meinem klugen Mitbewohner hatte, wurde klar, dass dieses Ziel, den Triton zu einem Zielpunkt zu bringen, ein Problem des geschlossenen Regelkreises war.

Nach umfangreichen Tests und Forschungen entwickelte ich zwei verschiedene Steuerungsansä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 Gewinn 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 Gewinn 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 Gewinne wurden angewendet, um linear und angular Geschwindigkeiten zu erzeugen.

Dies führte dazu, dass der Triton natürlich auf das Ziel zusteuerte, während er gleichzeitig vorwärts bewegte und sanfte, kurvige Pfade erzeugte. Der entscheidende Vorteil war, dass der Roboter immer seine Vorderseite auf das Ziel ausgerichtet hielt, was für kamerabasierten Anwendungen entscheidend war.

Methode 2: X-Y-Koordinatensteuerung

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

• X-Controller: Steuerte direkt die Ost-West-Bewegung basierend auf dem X-Koordinatenfehler
• Y-Controller: Steuerte direkt die Nord-Süd-Bewegung basierend auf dem Y-Koordinatenfehler

Die Implementierung berechnete die X- und Y-Koordinatenfehler unabhängig, wandte separate proportionale Verstärkungen an und transformierte dann diese globalen Geschwindigkeitskomponenten in das lokale Koordinatensystem des Roboters unter Verwendung von Rotationsmatrizen. Diese Transformation war notwendig, da der Antrieb des Roboters mit omnidirektionalen Rädern Geschwindigkeiten in seinem eigenen Referenzrahmen benötigte, nicht in globalen Koordinaten. Diese Methode erzeugte die direktesten Wege zu den Zielen und war erheblich schneller, aber die Ausrichtung des Roboters würde abdriften, da es keine explizite Orientierungssteuerung gab.

Für Methode #1 habe ich in meinem Move Turtle (TurtleSim) Blog ausführlich über diese Methode gesprochen. Ich empfehle dringend, diesen Blog zu lesen, um alle Details darüber zu erfahren, wie PID-Controller im Allgemeinen funktionieren, sowie wie Methode #1 funktioniert. Ich entwickelte Methode #1 mit ROS’s TurtleSim und übertrug dann diesen Code auf den Triton und aktualisierte ihn, um eine realistischere Umgebung zu berücksichtigen.

Methode #2 verwendete einen ganz anderen, aber ebenso effektiven Ansatz. Anstatt über die Ausrichtung des Roboters und die Entfernung zum Ziel nachzudenken, behandelt diese Methode die Bewegung wie ein Koordinatenproblem. Der Controller berechnet kontinuierlich den Fehler in beiden X- und Y-Richtungen separat. Wenn der Roboter beispielsweise von (0,0) nach (2,3) bewegen muss, sieht er dies als Korrektur eines 2-Meter-Fehlers in X und eines 3-Meter-Fehlers in Y. Zwei proportionale Controller arbeiteten gleichzeitig: einer passte die Geschwindigkeit des Roboters in X-Richtung basierend auf dem X-Fehler an, während der andere die Y-Richtungsbewegung basierend auf dem Y-Fehler handhabte. Dies schuf einen direkteren Weg zum Ziel, ähnlich wie der Kopf eines 3D-Druckers sich bewegt, und ermöglichte sanfte diagonale Bewegungen. Der Roboter musste sich nicht explizit drehen, um sein Ziel zu erreichen, was diese Methode besonders effektiv in engen Räumen oder bei präziser Positionierung machte.

Beide Methoden erwiesen sich als erheblich 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 benötigte, dauerte jetzt etwa 8-12 Sekunden. Noch wichtiger ist, dass der Triton jetzt effizienter in engen Räumen navigieren konnte, was sich als nützlich für unsere Multi-Roboter-Szenarien erwies.

Entwicklungsherausforderungen und Debugging

Die Implementierung dieser Controller war nicht einfach und brachte mehrere bedeutende Debugging-Herausforderungen mit sich:

Koordinatensystemtransformationen: Einer der kniffligsten Aspekte war es, die Koordinatentransformationen richtig hinzubekommen. Das Optitrack-System lieferte Daten in seinem eigenen Koordinatenrahmen, der Roboter hatte seinen lokalen Koordinatenrahmen, und ich musste genau zwischen ihnen umrechnen. Frühe Implementierungen hatten Roboter, die in die falsche Richtung bewegten, weil ich die Berechnungen der Rotationsmatrizen durcheinandergebracht hatte.

Echtwelt- vs. Idealverhalten: Die größte Herausforderung bestand darin, reale Faktoren zu berücksichtigen, die in der Lehrbuchkontrolltheorie nicht erscheinen. Die Räder des Roboters hatten unterschiedliche Reibungseigenschaften, die Motoren reagierten nicht identisch, und es gab immer eine gewisse Latenz in der Kommunikationskette vom Optitrack zur Steuerungssoftware zum Arduino des Roboters. Ich verbrachte Wochen damit, proportionale Verstärkungen zu optimieren und Deadband-Filter hinzuzufügen, um diese physikalischen Realitäten zu berücksichtigen.

Oscillation und Stabilitätsprobleme: Meine ersten Implementierungen litten unter Oszillationsproblemen, bei denen Roboter ihre Ziele übertrafen und hin und her wackelten. Dies lehrte mich die Bedeutung von Ableitungsbegriffen in PID-Controllern und die Notwendigkeit einer ordnungsgemäßen Verstärkungseinstellung. Ich entschied mich schließlich für überwiegend proportionale Steuerung mit sorgfältig abgestimmten Verstärkungen anstelle von vollem PID, da die inhärente Dämpfung des Systems für die meisten Anwendungen ausreichend war.

Interferenz zwischen mehreren Robotern: Als mehrere Roboter gleichzeitig betrieben wurden, entdeckte ich unerwartete Interferenzmuster. Roboter “kämpften” manchmal um denselben Raum oder schufen Deadlock-Situationen, in denen sie sich gegenseitig unbegrenzt blockierten. Dies führte mich dazu, Koordinationsmechanismen und Kollisionsvermeidungsalgorithmen zu implementieren.

Multi-Triton-Steuerungssystem

Nachdem ich das Problem der Einzel-Triton-Bewegung gelöst hatte, war die nächste Herausforderung des Labors, mehrere Tritons gleichzeitig zum Arbeiten zu bringen. Dies wurde zu einem meiner Hauptfokusbereiche und stellte einen bedeutenden Beitrag zum Projekt dar.

Das ursprüngliche System konnte nur einen Triton gleichzeitig steuern, was die Forschungsmöglichkeiten erheblich einschränkte. Das Labor wollte Szenarien simulieren, in denen mehrere autonome Fahrzeuge ihre Bewegungen koordinieren mussten, wie 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 Multi-Processing-Ansatz unter Verwendung der Multiprocessing-Bibliothek von Python. Jeder Triton erhielt seinen eigenen dedizierten Prozess, der unabhängig laufen konnte, während er dennoch von einem zentralen Steuersystem koordiniert wurde. Dies ermöglichte es mehreren Tritons, gleichzeitig zu bewegen, ohne sich gegenseitig in ihren Steuerungsschleifen zu stören.

Multi-Roboter-Architekturdesign

Die Systemarchitektur, die ich entwickelte, bestand aus mehreren Schlüsselkomponenten:

Hauptsteuerungsprozess: Dies diente als zentraler Koordinator, der Benutzeroberflächeninteraktionen, Pfadplanung und hochrangige Koordination zwischen Robotern handhabte. Er hielt den globalen Zustand aufrecht und verteilte Befehle an die einzelnen Roboterprozesse.

Individuelle Roboterprozesse: Jeder Triton hatte seinen eigenen dedizierten Python-Prozess, der Folgendes handhabte:

• Echtzeit-PID-Steuerungsberechnungen bei ~50Hz
• Kommunikation mit der Hardware des Roboters (Arduino/Jetson)
• Lokale Pfadausführung und Hindernisvermeidung
• Statusberichterstattung an den Hauptcontroller

Gemeinsame Speicherkommunikation: Ich verwendete die Objekte multiprocessing.shared_memory und Queue von Python, um eine effiziente Kommunikation zwischen Prozessen zu ermöglichen. Dies erlaubte eine Echtzeitkoordination ohne die Überlastung der Netzwerkkommunikation.

Synchronisationsmechanismen: Um Konflikte zu vermeiden, wenn mehrere Roboter koordinieren mussten (wie Kollisionen zu vermeiden), implementierte ich Semaphore und Locks, die es Robotern ermöglichten, exklusiven Zugriff auf bestimmte Bereiche des Arbeitsbereichs zu beantragen.

Die Herausforderung bestand darin, sicherzustellen, dass alle Roboter ihre Steuerungsschleifen unabhängig betreiben konnten, während sie dennoch eine globale Koordination aufrechterhielten. Jeder Roboterprozess führte seine eigenen PID-Berechnungen durch und sendete Motorbefehle direkt an die Hardware, während der Hauptprozess hochrangige Koordination wie Kollisionsvermeidung und Pfadplanung handhabte.

Das Multi-Triton-System eröffnete völlig neue Forschungsperspektiven. Wir konnten jetzt simulieren:

• Fahrzeug-zu-Fahrzeug-Kommunikationsszenarien
• Koordinierte Pfadplanung mit Hindernisvermeidung
• Schwarmrobotikverhalten
• Multi-Agenten-SLAM-Kartierung
• Formationskontrolle und Verhaltensweisen beim Folgen

So sah die Laboreinrichtung mit mehreren Tritons aus, die gleichzeitig liefen:

Ich entwickelte auch eine benutzerfreundliche Schnittstelle, die es Forschern ermöglichte, visuell Pfade für jeden Triton zu definieren. 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 einzurichten, ohne jede Bewegung manuell codieren zu müssen.

Das System konnte bis zu 5 Tritons gleichzeitig steuern, wobei jeder seine eigenen PID-Controller betrieb, während sie durch das zentrale Steuersystem koordiniert wurden. 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 der Steuerung eines einzelnen Roboters bis zur Koordination mehrerer Roboter: Tritons in Action Playlist

Integration des Tiefensensors und Koordinatenkorrektur

Ein weiterer bedeutender Fortschritt, an dem ich arbeitete, bestand darin, die Intel RealSense D435 Tiefenkameras zu nutzen, die an jedem Triton montiert waren. Während das Optitrack-System uns unglaublich präzise Positionsdaten lieferte, wollte ich erkunden, wie die Roboter ihre Bord-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 Nähe zu erkennen und ihre Positionen abzugleichen. Dies würde mehrere Zwecke erfüllen:

1. Fehlerkorrektur: Wenn das Optitrack-System eine Kalibrierungsdrift oder vorübergehende Okklusion hatte, könnten Roboter visuelle Bestätigungen der Positionen des jeweils anderen nutzen, um genaue Koordinatensysteme aufrechtzuerhalten.

2. Verbesserte SLAM: Indem mehrere Roboter mit Tiefensensoren zusammenarbeiteten, könnten wir viel reichhaltigere Karten der Umgebung mit redundanten Datenpunkten erstellen.

3. Kollisionsvermeidung: Echtzeit-Tiefensensorik würde es Robotern ermöglichen, sich gegenseitig zu erkennen und zu vermeiden, selbst wenn das zentrale Kontrollsystem Kommunikationsverzögerungen hatte.

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

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

Computer Vision Experimente

Ich verbrachte beträchtliche Zeit mit Experimenten an einer Computer Vision Pipeline, die in mehreren Phasen arbeitete:

Tiefendatenverarbeitung: Die Intel RealSense D435 lieferte sowohl RGB- als auch Tiefendatenströme. Ich arbeitete hauptsächlich mit den Tiefendaten, die als 640x480 Array von Distanzmessungen bei 30Hz kamen. Die erste Herausforderung bestand darin, diese rauschenden Tiefendaten zu filtern, um bedeutungsvolle geometrische Informationen zu extrahieren.

Objekterkennungsversuche: Ich experimentierte mit mehrstufigen Erkennungsalgorithmen. Ich hatte einige Erfolge beim Segmentieren des Tiefenbildes, um Objekte auf Bodenhöhe zu identifizieren (Wände, Decken usw. herauszufiltern) und nach Objekten mit den richtigen Größenmerkmalen zu suchen, die ungefähr eine Grundfläche von 0,3x0,3 Metern hatten. Ich versuchte, Kantenerkennung und geometrische Analyse zu verwenden, um das charakteristische Triton-Profil zu identifizieren, mit gemischten Ergebnissen.

Markererkennungsexperimente: Die drei reflektierenden Kugeln auf 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 hatte einige vielversprechende Ergebnisse unter kontrollierten Lichtbedingungen, obwohl es nicht durchgängig zuverlässig war.

Koordinatenfusion Forschung: Ich forschte nach Ansätzen zur Fusion von vision-basierten Positionsschätzungen mit den Optitrack-Daten, einschließlich grundlegender Implementierungen von Kalman-Filtern. Das Konzept war, den Optitrack-Daten mehr Gewicht zu geben, wenn sie verfügbar waren, aber auf Vision zurückzugreifen, wenn nötig, obwohl ich dies nicht vollständig zum Laufen brachte, bevor meine Zeit im Labor endete.

Leistungsherausforderungen: Es stellte sich als herausfordernd heraus, all diese Verarbeitung in Echtzeit neben den Steuerungsschleifen des Roboters auszuführen. Ich experimentierte mit Optimierungsansätzen, um die Algorithmen bei 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. Während 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 von mir, in dem ich die Computer Vision-Algorithmen teste:

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

Obwohl ich die Integration der Tiefensensoren nicht abschließen konnte, zeigte das Konzept vielversprechende Anwendungen wie die Simulation von Szenarien für selbstfahrende Autos, bei denen Fahrzeuge sich gegenseitig wahrnehmen müssen, ohne sich ausschließlich auf externe Infrastruktur zu verlassen. Die Forschungsrichtung, die ich zu erkunden begann, könnte potenziell 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 aller Projektdokumentationen. Als ich dem Labor beitrat, war das Wissen über das Triton-Projekt über mehrere Plattformen und Formate verstreut. Kritische Informationen waren verteilt auf:

• Verschiedene Google Drive-Konten von verschiedenen Studenten, die bereits abgeschlossen 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 von bestimmten Personen interpretiert werden konnten

Diese fragmentierte Dokumentation war ein großes Problem. Neue Studenten benötigten Wochen, um herauszufinden, wie sie anfangen sollten, und wertvolles Wissen ging ständig verloren, wenn Leute das Labor verließen oder abschlossen.

Ich nahm es mir vor, dieses Problem systematisch zu lösen. Ich verbrachte unzählige Stunden damit, jedes Stück Dokumentation, Code, Video und Notiz, die mit dem Triton-Projekt zu tun hatten, zu verfolgen. Dann organisierte ich alles in einem zentralen GitLab-Repository mit einer klaren, logischen Struktur.

Die zentralisierte Dokumentation umfasste:

• Bauanleitungen: Schritt-für-Schritt-Anleitungen zum Zusammenbauen von Tritons von Grund auf
• Softwareeinrichtung: Vollständige Anleitungen zur Einrichtung der Entwicklungsumgebung
• Code-Dokumentation: Gut kommentierter Code mit klaren Erklärungen
• Hardware-Spezifikationen: Detaillierte Teilelisten, Verdrahtungsdiagramme und PCB-Designs
• Fehlerbehebungsanleitungen: Häufige Probleme und deren Lösungen
• Video-Tutorials: Ich erstellte und lud Schulungsvideos auf YouTube hoch, einschließlich detaillierter Optitrack-Kalibrierungstutorials:

Ich etablierte auch Dokumentationsstandards, um sicherzustellen, dass zukünftige Beiträge organisiert und zugänglich wären. Die von mir geschaffene Repository-Struktur wurde zur Grundlage für alle nachfolgenden Arbeiten im Labor.

Über die bloße Organisation bestehender Dokumentationen hinaus erstellte ich mehrere originale Anleitungen und Tutorials, die kritische Lücken in der Wissensbasis schlossen. Dazu gehörten detaillierte Einrichtungsanleitungen für neue Labormitglieder, umfassende Fehlerbehebungsanleitungen und Videoanleitungen für komplexe Verfahren.

Die Auswirkungen waren sofort und nachhaltig. Neue Studenten konnten sich in Tagen statt in Wochen einarbeiten. Das Dokumentationsrepository, das ich erstellt habe, wird auch heute noch im Labor verwendet, Jahre nachdem ich gegangen bin. Es wurde zur einzigen Quelle der Wahrheit für das Triton-Projekt und sparte zukünftigen Forschern unzählige Stunden/Tage.

Mentoring und Wissensübertragung

Einer der lohnendsten Aspekte meiner Zeit im HCR-Labor war die Möglichkeit, andere zu betreuen und das Wissen, das ich gewonnen hatte, zu teilen. Als meine Arbeit voranschritt und ich mehr Erfahrung mit den Triton-Systemen sammelte, übernahm ich zunehmend Verantwortung für die Schulung neuer Teammitglieder.

Mentoring von Labor-Nachfolgern

Als ich mich darauf vorbereitete, das Labor 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. Es ging nicht nur darum, ihnen zu zeigen, wie die Dinge funktionierten, sondern sicherzustellen, dass sie die zugrunde liegenden Prinzipien wirklich verstanden, damit sie weiterhin innovativ sein konnten.

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

• Die mathematischen Grundlagen der PID-Regelsysteme
• Die Multi-Processing-Architektur zur Koordination mehrerer Roboter
• Die Integration des Tiefensensors und die Algorithmen der Computer Vision
• Das Dokumentationssystem und wie man es pflegt
• Debugging-Techniken und häufige Fehlermodi

Die Wissensübertragung war unglaublich gründlich. Wir gingen gemeinsam durch echte Debugging-Sitzungen, ich ließ sie den bestehenden Code modifizieren und erweitern, und ich stellte sicher, dass sie in der Lage waren, neue Tritons unabhängig von Grund auf einzurichten.

Mentoring-Programm für Schüler

Vielleicht noch lohnender war meine Erfahrung, einen Schüler durch das Outreach-Programm des Labors zu betreuen. Dies war eine großartige Gelegenheit, jemandem Robotik, Informatik und Forschung in einer prägenden Phase seiner Ausbildung näherzubringen.

Ich entwarf einen umfassenden Lehrplan, der Folgendes abdeckte:

Grundlagen der Informatik:

• Programmierkonzepte unter Verwendung von Python als primäre Sprache
• Einführung in die objektorientierte Programmierung
• Verständnis von Algorithmen und Datenstrukturen

Roboterkonzepte:

• Wie Sensoren funktionieren und wie man mit ihnen interagiert
• Aktuatorsteuerung und Motorsysteme
• Die Grundlagen autonomer Systeme und Regelungstechnik

ROS (Robot Operating System):

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

Praktische Projektarbeit:

• Wir arbeiteten zusammen an der Erstellung eines ROS-Dienstes, der das LED-System am Kopf des Tritons steuerte
• Sie lernte, sauberen, dokumentierten Code zu schreiben, der mit unseren bestehenden Systemen integriert war
• Der LED-Steuerungsdienst, den sie erstellte, wurde ein fester Bestandteil des Triton-Codebases

Was dieses Mentoring besonders machte, war zu beobachten, wie sie sich von nahezu null Kenntnissen über Programmierung zu einem bedeutenden Beitrag zu einem aktiven Forschungsprojekt entwickelte. Sie ging von der Frage “Was ist eine Variable?” zu dem Punkt, an dem sie unabhängig ROS-Kommunikationsprobleme debuggen und ihre eigenen Dienstimplementierungen schreiben konnte.

Das von ihr entwickelte LED-Steuerungssystem ermöglichte es den Forschern, die Farben und Muster der LEDs am Kopf des Tritons einfach über einfache ROS-Befehle zu ändern. Das mag einfach erscheinen, erforderte jedoch ein Verständnis der ROS-Architektur, der Hardware-Interaktion und der richtigen Software-Designmuster. Ihr Beitrag wird auch heute noch im Labor verwendet.

Die Mentorship war für mich ebenso lehrreich wie für sie. Es zwang mich, komplexe Konzepte in verdauliche Stücke 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 Doktoranden, dessen Forschung sich auf Algorithmen für selbstfahrende Autos konzentrierte. Die Softwareverbesserungen, die ich am Triton-System vorgenommen hatte, unterstützten seine Doktorarbeit.

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 halfen Pengs Forschung in mehreren Bereichen:

Studien zur Kreuzungsverwaltung: 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 Positionierung machten diese Studien machbarer.

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, während er weiterhin mit anderen koordinierte, ähnlich wie selbstfahrende Autos möglicherweise arbeiten müssen.

SLAM- und Kartierungsforschung: Die Integration des Tiefensensors lieferte Peng zusätzliche Daten für seine Forschung zur gleichzeitigen Lokalisierung und Kartierung. Mit mehreren Robotern, die koordinierte Sensorfähigkeiten hatten, konnten umfassendere Kartierungsexperimente durchgeführt werden.

Was unsere Zusammenarbeit besonders wertvoll machte, war, dass es nicht nur ich war, der seine Forschung unterstützte, sondern es eine echte Partnerschaft war. 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 im Labor miteinander, debugten Szenarien, diskutierten verschiedene Steuerungsstrategien und erkundeten, was die Triton-Plattform erreichen konnte. 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 Systeme, die ich baute, wurden ein nützlicher Teil von Pengs Dissertation. Zu sehen, wie meine praktischen Ingenieureingaben die Forschung im Bereich der Technologie für autonome Fahrzeuge unterstützten, war wirklich erfüllend. Es verstärkte mein Interesse daran, wie solide Ingenieurarbeit und Forschung zusammenarbeiten können, um nützliche Ergebnisse zu erzielen.

Selbst 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 belohnend.

Perspektive: Die Pre-LLM-Ära der Entwicklung

Es ist erwähnenswert, dass all diese Arbeit während der Pre-LLM-Ära der Softwareentwicklung geleistet wurde. All dies fand zwischen 2020 und 2021 (hauptsächlich 2021) statt, bevor ChatGPT, Claude, Perplexity oder KI-gestützte Entwicklungstools wie Cursor IDE existierten.

Jede Zeile Code wurde von Grund auf neu geschrieben, jeder Algorithmus wurde durch akademische Arbeiten und Lehrbücher recherchiert, und jede Debugging-Sitzung beinhaltete traditionelle Methoden wie Print-Anweisungen, Debugger und methodisches Testen. Wenn ich bei einer Koordinatentransformation oder einem PID-Tuning-Problem feststeckte, konnte ich nicht einfach einen KI-Assistenten fragen, um das Konzept zu erklären oder bei der Fehlersuche zu helfen.

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

Alles manuell recherchieren: Das Verständnis der PID-Regelungstheorie bedeutete, Lehrbücher und akademische Arbeiten zu lesen. Die Koordinatentransformationen zu verstehen, erforderte, die Mathematik von Hand durchzugehen. Jedes Konzept musste vollständig verstanden werden, bevor es implementiert wurde.

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

Aus den Grundprinzipien 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, eine solide Grundlage in nebenläufiger Programmierung, Regelungssystemen und Computer Vision aufzubauen.

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

Rückblickend, während moderne KI-Tools viele Aspekte der Entwicklung beschleunigt hätten, zwang mich die Arbeit ohne sie, tiefere Problemlösungsfähigkeiten und ein gründlicheres Verständnis der zugrunde liegenden Systeme zu entwickeln. Es ist faszinierend zu denken, wie anders dieses Projekt mit den heutigen Entwicklungstools hätte sein können.

Die schwierige Entscheidung zu gehen

So sehr ich die Arbeit im HCR-Labor liebte, stand ich Ende 2021 vor einer schwierigen Entscheidung, die viele Studenten treffen müssen: das Gleichgewicht zwischen mehreren Möglichkeiten und Verantwortlichkeiten. Ich arbeitete gleichzeitig Vollzeit als Softwareingenieur bei eBay, beendete mein Informatikstudium an der Mines und trug zur Forschung im HCR-Labor bei.

Die eBay-Möglichkeit war bedeutend; es war meine erste große Rolle als Softwareingenieur, bot unschätzbare Branchenerfahrung und sicherte mir ein solides Einkommen. Allerdings war es einfach nicht nachhaltig, Vollzeit zu arbeiten, mein Studium abzuschließen und bedeutend zur Forschung beizutragen. Etwas musste sich ändern.

Als ich Dr. Zhang ansprach, um möglicherweise meine Kurslast zu reduzieren, um mich mehr auf die Laborarbeit zu konzentrieren, riet er entschieden davon ab. Seine Argumentation war schlüssig: Mein Studium abzuschließen sollte Priorität haben, und die Branchenerfahrung bei eBay wäre wertvoll für meine berufliche Entwicklung. Er war der Meinung, dass es zwar verlockend sei, Kurse abzubrechen, um sich auf die Forschung zu konzentrieren, dies jedoch nicht die beste langfristige Entscheidung sein könnte.

Also traf ich im September 2021, nach etwa 8 Monaten intensiver Arbeit im Labor, die schwierige Entscheidung, von meiner Rolle als Forschungsassistent zurückzutreten, 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.

Selbst nachdem ich offiziell das Labor verlassen hatte, bot ich weiterhin Unterstützung an, wann immer jemand Hilfe mit den Systemen benötigte, die ich gebaut hatte. Ich aktualisierte die Dokumentation nach Bedarf, beantwortete Fragen zur Fehlersuche und half, Probleme aus der Ferne zu beheben. Die Verbindungen, die ich geknüpft hatte, und die Investition, die ich in den Erfolg des Projekts hatte, verschwanden nicht einfach, weil ich nicht mehr offiziell Teil des Teams war.

Reflexionen und Rückblick

Jetzt, im Jahr 2025, vier Jahre später, denke ich mit gemischten Gefühlen an diese Zeit zurück. Mein Karriereweg führte mich tief in die Webentwicklung und AI/ML-Engineering, Bereiche, die unglaublich lohnend 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 ist ehrlich gesagt meine wahre Leidenschaft. Es gibt etwas daran, mit physischen Systemen zu arbeiten, zu sehen, wie sich dein Code in reale Bewegungen und Verhaltensweisen übersetzt, das Webentwicklung und sogar AI-Arbeit nicht ganz replizieren können.

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

Aber ich erkenne auch, dass jeder Weg seine Kompromisse hat. Die Fähigkeiten, die ich in der Webentwicklung und AI entwickelt habe, waren unglaublich wertvoll. Die Branchenerfahrung lehrte mich über Softwareengineering im großen Maßstab, Benutzererfahrungsdesign und die praktischen Herausforderungen beim Bau 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 in der Art und Weise, wie ich Feedback-Schleifen in Softwaresystemen entwerfe. Die Dokumentations- und Wissensbewahrungskompetenzen, die ich entwickelt habe, waren in jeder Rolle seitdem von unschätzbarem Wert. Die Erfahrung des Mentorings und Lehrens hat geprägt, wie ich mit Junior-Entwicklern arbeite und zum Wissensaustausch im Team beitrage.

Am wichtigsten ist, dass mir die Erfahrung gezeigt hat, dass ich gedeihe, wenn ich an herausfordernden technischen Problemen arbeite, die reale Auswirkungen haben. Ob es darum geht, Algorithmen für die Roboterbewegung zu optimieren oder AI-Systeme zu entwickeln, die den Nutzern helfen, ihre Ziele zu erreichen, die Zufriedenheit kommt von der Lösung schwieriger Probleme, die wichtig sind.

Die nachhaltige Wirkung

Wenn ich auf die Erfahrung im HCR-Labor zurückblicke, bin ich beeindruckt, wie viel ich in relativ kurzer Zeit erreicht habe. Die Systeme, die ich gebaut habe, haben die Funktionsweise der Triton-Plattform grundlegend verändert, und viele dieser Verbesserungen werden noch heute verwendet. Das Dokumentationsrepository, das ich erstellt habe, wurde zur Wissensbasis für das gesamte Projekt. Die Mentorship-Beziehungen, die ich aufgebaut habe, hatten einen nachhaltigen Einfluss auf die Menschen, mit denen ich gearbeitet habe.

Aber vielleicht am bedeutendsten war, dass mir die Erfahrung gezeigt hat, was ich leisten kann, wenn ich an Problemen arbeite, für die ich wirklich leidenschaftlich bin. In diesen acht Monaten habe ich:

• Verbesserte das Robotermovement-Kontrollsystem, das die Plattform eingeschränkt hatte
• Baute ein Multi-Roboter-Koordinationssystem von Grund auf
• Integrierte Computer Vision und Sensorfusion-Fähigkeiten
• Erstellte eine umfassende Dokumentations- und Wissensmanagementsystem
• Mentorte mehrere Personen und half beim Wissenstransfer
• Unterstützte Forschungsarbeiten auf Doktoratsniveau in autonomen Fahrzeugen

Es ging dabei nicht nur um 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 Student im Grundstudium.

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 auf diesem Gebiet, bin begeistert von Fortschritten im Robot Learning und in autonomen Systemen und 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, sind zunehmend relevant für die Robotik. Die Branchenerfahrung, die ich gesammelt habe, hat mir beigebracht, wie man robuste, skalierbare Systeme aufbaut. Vielleicht gibt es eine Zukunft, in der diese verschiedenen Fäden 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 geboten hat. Es war eine prägende Zeit, die sowohl meine technischen Fähigkeiten als auch mein Verständnis dafür, welche Arten von Arbeiten ich am erfüllendsten finde, geprägt hat. 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 da, dienen weiterhin Forschern und ermöglichen wichtige Arbeiten. Und das ist ziemlich wunderbar.