Mój rozdział o badaniach w robotyce

Ten wpis opowiada o mojej drodze w robotyce, zaczynając od odkrycia mojej pasji do robotyki w FRC podczas szkoły średniej w 2015 roku, aż po mój czas jako asystent badawczy w Human Centered Robotics (HCR) Lab Colorado School of Mines od lutego 2021 do września 2021. Zauważ, że od końca 2022 roku HCR Lab przeniosło się z Colorado School of Mines na University of Massachusetts Amherst, wraz ze swoją stroną z hcr.mines.edu na hcr.cs.umass.edu.

Tło

Rozpocząłem studia licencjackie w Colorado School of Mines w semestrze jesiennym 2018. Moim kierunkiem była Informatyka ze specjalizacją w Robotyce i Inteligentnych Systemach. Ukończyłem studia w semestrze wiosennym 2022.

Miałem szczęście wcześnie odkryć swoją pasję w życiu. W czasie szkoły średniej spędziłem sporo czasu na zastanawianiu się, co lubię i w czym mogę być dobry. Po pewnych próbach i błędach udało mi się ustalić, że moją pasją jest informatyka. Ale to właśnie w tym czasie odkryłem też, że mam przytłaczającą miłość do tworzenia poprzez kod.

W Mines dostałem możliwość pracy w Human Centered Robotics (HCR) Lab Mines pod opieką dr. Hao Zhanga. Poznałem dr. Zhanga po raz pierwszy w semestrze wiosennym 2020 na jego zajęciach „Human Centered Robotics” (CSCI473), a po chaosie związanym z COVID-em i zajęciami, mogłem pracować w jego laboratorium na początku semestru wiosennego 2021.

Zajęcia Human Centered Robotics (CSCI473)

Zajęcia Human Centered Robotics (CSCI473) w Mines były jednymi z niewielu zajęć z mojego okresu studiów, które miały na mnie głęboki wpływ. Zajęcia prowadził dr Hao Zhang. Cała nasza ocena z kursu składała się tylko z trzech projektów, z których każdy przedstawiał trudny problem wprowadzający podstawowe pojęcia robotyki. Projekty te obejmowały:

1. Naukę Robot Operating System (ROS)
2. Uczenie ze wzmocnieniem do podążania robota za ścianą
3. Zrozumienie ludzkich zachowań przez robota z użyciem reprezentacji opartych na szkielecie

Nauka Robot Operating System (ROS)

To był pierwszy projekt, który nam przydzielono. Projekt składał się z trzech zadań:

1. Konfiguracja środowiska programistycznego
2. Zrozumienie symulatora Gazebo
3. Napisanie „Hello World” w ROS

W przypadku zadań 1 i 2 musieliśmy jedynie skonfigurować środowisko programistyczne i przejść przez wprowadzenie do samouczka Gazebo. Obejmowało to:

• Konfigurację ROS Melodic, którą zrobiłem na moim laptopie HP z 2011 roku, który był wystarczający
• Instalację i konfigurację ROS oraz Gazebo
• Przejście przez samouczek gazebosim oraz samouczek e-manual.

Zadanie 3 natomiast było prawdziwym wyzwaniem. Zadanie polegało na użyciu turtlesim i sprawieniu, by żółw narysował logo Mines „M”:

To zadanie, choć brzmiało prosto, było trudniejsze, niż się wydawało. Ten projekt ostatecznie wprowadził mnie w pojęcie systemów otwartej pętli i zamkniętej pętli. Pełny opis projektu znajdziesz w csci473-p1.pdf albo możesz dowiedzieć się więcej o tym projekcie i moim rozwiązaniu na stronie projektu ROS Move Turtle.

Uczenie ze wzmocnieniem do podążania robota za ścianą

To był drugi projekt, który nam przydzielono, i był to jeden z najtrudniejszych projektów, nad którymi pracowałem na studiach. Opis projektu był następujący:

W tym projekcie studenci zaprojektują i zaimplementują algorytmy uczenia ze wzmocnieniem, aby nauczyć autonomicznego robota mobilnego podążania wzdłuż ściany i unikania wjeżdżania w przeszkody. Studenci będą korzystać z symulacji Gazebo w ROS Melodic, aby symulować mobilnego robota wielokierunkowego o nazwie Triton, używając dostarczonej mapy środowiska. Studenci będą używać na robocie skanera laserowego do wykonywania pomiarów i uczenia, przy czym robot będzie sterowany za pomocą poleceń skrętu i prędkości. Studenci mają obowiązek zaprogramować ten projekt w C++ lub Pythonie w ROS Melodic działającym na Ubuntu 18.04 LTS (tj. w tym samym środowisku programistycznym, którego użyto w Projekcie 1). Ponadto studenci mają obowiązek napisać raport zgodny z formatem standardowych konferencji robotycznych IEEE, używając LATEX.

Do algorytmu uczenia ze wzmocnieniem mieliśmy użyć Q-Learning. Korzystaliśmy również ze środowiska symulacyjnego Gazebo Stingray dostarczonego przez zajęcia. Stingray składał się z modelu Triton i logiki fizyki. Otrzymaliśmy także labirynt, którym robot miał podążać. Ogólnie rzecz biorąc, środowisko wyglądało tak:

Nigdy nie opublikowałem mojego rozwiązania na GitHubie ani w sieci, ponieważ nie było zbyt dobre i miało wiele wad. Poza tym uruchomienie kodu we właściwym środowisku jest dość trudne i uciążliwe. Mam jednak film demonstracyjny, który oddałem na zajęcia, pokazujący moje rozwiązanie. Możesz go obejrzeć tutaj:

Pełny opis projektu znajdziesz w csci473-p2.pdf

Zrozumienie ludzkich zachowań przez robota z użyciem reprezentacji opartych na szkielecie

W przypadku trzeciego projektu opis był następujący:

W tym projekcie studenci zaimplementują kilka reprezentacji opartych na szkielecie (Zadanie 1) i użyją maszyn wektorów nośnych (SVM) (Zadanie 2) do klasyfikacji ludzkich zachowań z wykorzystaniem publicznego zbioru danych aktywności zarejestrowanego czujnikiem Kinect V1. Dodatkowo studenci są zobowiązani napisać raport zgodny z formatem standardowych konferencji robotycznych IEEE, używając LATEX w Zadaniu 3.

Ten projekt był wymagający, ale nie tak trudny jak drugi projekt. Głównym celem było użycie danych z czujnika Kinect V1, pochodzących z MSR Daily Activity 3D Dataset, oraz Support Vector Machines do klasyfikacji określonych ludzkich działań/zachowań. Pełny opis projektu znajdziesz w csci473-p3.pdf albo możesz dowiedzieć się więcej o tym projekcie i moim rozwiązaniu we wpisie na blogu Predict Human Actions Using LIBSVM.

Wnioski z CSCI473

CSCI473 to jedne z najlepszych, jeśli nie najlepsze zajęcia, jakie miałem podczas studiów licencjackich w Mines. Wszystkie te projekty wiele mnie nauczyły i pozwoliły mi mieć fajny katalog projektów, do którego mogę wracać i na który mogę się powoływać w moim CV. To były też pierwsze zajęcia, na których czułem, że jestem we właściwym miejscu, ponieważ nigdy nie byłem dobry w zdawaniu testów, ale świetnie radziłem sobie z realizacją projektów. To właśnie dzięki tym zajęciom poznałem też dr. Hao Zhanga, który ostatecznie pomógł mi zdobyć stanowisko asystenta badawczego w Human-Centered Robotics (HCR) Lab Mines.

CS Field Session (lato 2020)

Latem 2020 roku, między ukończeniem CSCI473 a dołączeniem do HCR Lab, wziąłem udział w CSCI370 czyli „Advanced Software Engineering” w ramach mojego programu studiów licencjackich z informatyki w Colorado School of Mines. CSCI370 to kurs, w którym studenci projektują, implementują i dokumentują rozwiązania związane z oprogramowaniem dla firmy. Umożliwia on studentom zastosowanie wiedzy zdobytej na zajęciach do rzeczywistych problemów informatycznych. Więcej o kursie możesz przeczytać tutaj.

Na kursie sam decydujesz, nad jakim projektem/firmą będziesz pracować. Kurs dostarczał pliki PDF opisujące każdy projekt i każdą firmę. Ostatecznie zdecydowałem się pracować nad projektem opublikowanym przez firmę Lunar Outpost zatytułowanym „Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation”. Ponieważ nazwa jest długa, nadajmy projektowi alias „Wykrywanie poślizgu kół”.

Problem

Lunar Outpost to startup próbujący tworzyć autonomiczne łaziki księżycowe. Na Księżycu jest dużo pyłu księżycowego, który jest znany z powodowania dużego poślizgu kół. Nie jest to idealne, ponieważ poślizg kół może sprawić, że systemy autonomiczne stracą orientację co do swojej rzeczywistej lokalizacji. Na Ziemi rozwiązuje się to za pomocą danych GPS, aby skorygować wszelkie przesunięcia spowodowane poślizgiem kół. Problem z GPS polega jednak na tym, że działa on tylko dzięki temu, że ponad 30 satelitów nawigacyjnych nieustannie krąży wokół Ziemi na orbicie i nadaje unikalne sygnały, które pozwalają komputerom obliczyć ich pozycję. Na Księżycu obecnie nie ma czegoś takiego jak GPS. Wiedząc to, trzeba użyć innej metody niż GPS do wykrywania poślizgu kół. Bardziej szczegółowy raport o problemie projektu można zobaczyć tutaj.

Zespół

Ten projekt nie był prostym projektem, więc musiał być wykonany zespołowo. Zespół składał się z pięciu innych studentów Colorado School of Mines:

Ten projekt nie był prostym projektem, więc musiał być wykonany zespołowo. Zespół składał się z Mehmeta Yilmaza (mnie), Kane’a Bruce’a, Braedona O’Callaghana, Liama Williamsa i Kevina Granta.

Projekt wymagał od nas znajomości ROS, C++, Pythona, Linuksa, Raspberry Pi i Arduino. Większość z nas miała doświadczenie z jedną lub kilkoma z tych technologii, ale tylko ja miałem doświadczenie z ROS, ponieważ używałem ROS na zajęciach Human Centered Robotics (CSCI473) w semestrze wiosennym 2020. Z tego powodu na wczesnym etapie pomagałem wszystkim przyspieszyć naukę ROS i tego, jak tworzyć pod niego oprogramowanie.

Wyzwania

W tym projekcie napotkaliśmy wiele wyzwań. Jednak największym wyzwaniem, z jakim się zmagaliśmy, był brak dostępu do prawdziwego robota do testów. Wynikało to z COVID, który sprawił, że wszystko odbywało się zdalnie i uniemożliwił nam pracę w laboratorium/budynkach Lunar Outpost. Z tego powodu musieliśmy korzystać z symulacji.

Ponadto przejrzeliśmy część badań akademickich z WVU Navigation Lab, aby zorientować się, jak można rozwiązać problem poślizgu kół na potrzeby zastosowania Lunar Outpost, co dla nas, jako studentów drugiego i trzeciego roku studiów licencjackich, okazało się trudniejsze, niż się spodziewaliśmy.

Kolejnym wyzwaniem był czas, jaki mieliśmy na pracę nad tym projektem. CSCI370 to miesięczny kurs. Jednak sam problem jest ogromnym zagadnieniem, które wiele firm i środowisko akademickie próbują rozwiązać/dopracować od dziesięcioleci. Tak więc jeden miesiąc to zdecydowanie za mało, aby rozwiązać ten problem. Mimo wszystkich tych wyzwań wytrwaliśmy i dopilnowaliśmy, by dostarczyć gotowe rozwiązanie.

Wnioski

Po przejściu przez całe badania i prace rozwojowe doszliśmy do wniosku, że cyfrowe zasymulowanie prawidłowej fizyki Księżyca jest prawie niemożliwe, więc naprawdę testowanie tego algorytmu w symulacji nie ma sensu i nie przyniesie żadnych znaczących wyników badawczych w zakresie wykrywania poślizgu kół w przestrzeni kosmicznej i na Księżycu. Uznaliśmy, że znacznie ważniejsze dla tego rodzaju badań jest przygotowanie odpowiedniego środowiska testowego z użyciem czegoś takiego jak piasek i prawdziwego sprzętu, na przykład robota Husky. Zaktualizowaliśmy kod wykrywania poślizgu kół, aby działał jako węzeł ROS, i funkcjonował prawidłowo, dzięki czemu można go było łatwo zaimportować do prawdziwego sprzętu w celu testów. Projekt ten pozwolił mi objąć rolę lidera, szkolić moich kolegów w zakresie tworzenia w ROS, a także zdobyć doświadczenie z Pythonem, ROS i Gazebo, jednocześnie mierząc się ze złożonym problemem, z którym nigdy wcześniej się nie spotkałem. Co najważniejsze, to doświadczenie jeszcze bardziej umocniło moją pasję do robotyki i wzmocniło moje pragnienie prowadzenia badań w tej dziedzinie, wyznaczając kierunek tego, co miało nadejść dalej w mojej robotycznej podróży.

Początek w laboratorium HCR

Po ukończeniu CSCI473, mojej letniej sesji terenowej z CS w lecie 2020 roku, oraz semestru jesiennego 2020 roku, postanowiłem zająć się badaniami w robotyce. Miałem tak świetne doświadczenia zarówno z CSCI473, jak i z letnią sesją terenową z CS, że zdecydowałem, iż chcę prowadzić badania dla laboratorium HCR. Ponieważ poznałem dr. Zhanga rok wcześniej, postanowiłem napisać do niego e-mail i zapytać o ewentualne możliwości, jakie laboratorium mogłoby mieć w styczniu 2021 roku. W ciągu około 2 tygodni dr Zhang wyraził zainteresowanie, przedstawił mi opcje badawcze i zaproponował mi rolę w laboratorium. Następnie zacząłem pracę w laboratorium w lutym 2021 roku.

Film wprowadzający

Oto mój film wprowadzający, który nagrałem kilka miesięcy po rozpoczęciu pracy w laboratorium HCR. Został nagrany w maju 2021 roku i obejmuje badania, na których skupiłbym się w laboratorium HCR podczas lata 2021 roku:

Mój projekt

Przez cały czas spędzony w laboratorium HCR skupiałem się głównie na projekcie Triton. Projekt Triton to mobilny robot opracowany przez Human Centered Robotics Lab na Colorado School of Mines. Jest to trójkątny naziemny robot z kołami omni, napędzany przez NVIDIA Jetson Nano.

Triton w prostym ujęciu składał się z następujących części:

• NVIDIA Jetson Nano
• płytka nośna NVIDIA Seed Studio A205
• Arduino Mega
• karta Micro SD 64 GB
• niestandardowy, wydrukowany w 3D korpus
• 3 koła mecanum
• 1 bateria AR
• niestandardowe obwody do zoptymalizowanego rozdziału zasilania i okablowania
• kamera Intel Realsense D435
• kilka diod LED

Został zaprojektowany, zbudowany i wykonany około 2018–2020 roku jako robot do celów edukacyjnych. Gdy dołączyłem, Triton był już dość ugruntowanym projektem i laboratorium rozważało stworzenie jego nowej wersji. Jednak głównym problemem Tritona było oprogramowanie. Triton mógł się poruszać, ładować i działać w podstawowym sensie, ale tak naprawdę nie robił nic inteligentnego. Brakowało mu nawet możliwości wykonywania bardziej zaawansowanych ruchów.

Aby zacząć rozwiązywać ten problem, laboratorium przygotowało obszar, w którym mogliśmy śledzić Tritona. W tym celu utworzono obszar o wymiarach 2 metry na 2 metry z 8 kamerami Optitrack Flex (na podczerwień), rozmieszczonymi w kształcie zbliżonym do kwadratu, około 6–7 stóp nad podłogą.

Oprócz zbudowania tego obszaru, każdy Triton miał na górze korpusu przymocowane trzy szare kulki-sfery.

Dzięki takiemu ustawieniu w praktyce zbudowaliśmy własny niewielki system GPS, który pozwalał nam uzyskać dokładne współrzędne w metrach Tritona w naszym obszarze zainteresowania. Korzystając z kamer na podczerwień Optitrack oraz szarych kul Optitrack w układzie trójkątnym, mogliśmy precyzyjnie wskazać dokładne współrzędne Tritona w naszym obszarze. Pozwoliło nam to zastosować system zamkniętej pętli dla lepszej dokładności ruchu.

System Optitrack zapewniał dane o położeniu i orientacji z częstotliwością około 120 Hz oraz dokładnością submilimetrową po prawidłowej kalibracji. Trzy odblaskowe znaczniki każdego Tritona tworzyły unikalny trójkątny wzór, który system mógł śledzić jako ciało sztywne. Układ współrzędnych był skalibrowany tak, że punkt (0,0) znajdował się w centrum obszaru śledzenia, a osie X i Y były wyrównane z geometrią pomieszczenia. Jednak mimo tych precyzyjnych danych pozycjonowania Triton nadal miał problemy z ruchem.

W tej konfiguracji jedną z podstawowych funkcji, którą chcieliśmy zapewnić Tritonowi, była możliwość poruszania się do określonej współrzędnej. Użytkownik lub jego oprogramowanie mogło podać współrzędną (x, y) w obrębie obszaru zainteresowania. Następnie robot miał przemieścić się do tej współrzędnej tak szybko, dokładnie i płynnie, jak to możliwe. Kiedy dołączyłem, ta funkcja istniała, ale nie działała zbyt dobrze. Oto prosta animacja pokazująca, jak działała pierwotna logika ruchu:

Nie nagrałem pierwotnego rozwiązania w działaniu, więc stworzyłem tę prostą animację, aby pokazać stary sposób działania logiki ruchu. Wiedząc to, jakie są problemy z tą metodą?

1. Jest naprawdę powolna
2. Sprawia, że robot zajmuje dużo przestrzeni tylko po to, by dotrzeć do konkretnego punktu. To utrudniało nam korzystanie z tego rozwiązania, gdy poruszało się wiele Tritonów.

Dlaczego więc takie zachowanie występowało? Problem polegał na tym, że Triton najpierw się obracał, zmieniając swój alpha, aż wskazywał punkt docelowy z określonym marginesem błędu. Następnie ruszał sprintem do przodu, a gdy jego theta odchylała się od celu o określoną wartość, zatrzymywał się i zaczynał ponownie się obracać, aż alpha znów mieściła się w akceptowalnym zakresie dla docelowego punktu. Potem znowu sprintował i powtarzał to aż do osiągnięcia punktu. Ponadto, im bardziej zbliżał się do punktu docelowego, tym wolniejsze stawały się prędkości obracania i sprintu, aby upewnić się, że nie przekroczy celu. Skutkowało to nienaturalnym ruchem Tritona, bardzo długim czasem dotarcia do punktu docelowego oraz koniecznością posiadania ogromnej przestrzeni tylko po to, by osiągnąć konkretny cel. Zatem biorąc pod uwagę wszystkie te problemy i to, jak istotna była ta funkcja dla rozwoju projektu Triton, kiedy rozpocząłem pracę w HCR Lab, moim pierwszym zadaniem było opracowanie skuteczniejszych rozwiązań, które pozwoliłyby Tritonowi lepiej nawigować do punktu docelowego.

Wiedząc to, poświęciłem dużo czasu na badania nad najlepszym możliwym sposobem rozwiązania tego problemu. Paradoksalnie brałem na Mines udział w kursie Introduction to Feedback Control Systems (EENG307). Na początku tego kursu poznaliśmy pojęcie sterowników otwartej pętli oraz sterowników zamkniętej pętli. Wiedząc o tym i po rozmowie, jaką odbyłem z wykładowcą tego kursu oraz moim inteligentnym współlokatorem, stało się jasne, że ten cel, jakim było doprowadzenie Tritona do punktu docelowego, jest problemem systemu zamkniętej pętli.

Teraz, po szeroko zakrojonych testach i badaniach, opracowałem dwa odrębne podejścia sterujące dla Tritonów:

Metoda 1: Sterownik odległość-theta

To podejście wykorzystywało dwa oddzielne sterowniki proporcjonalne działające jednocześnie:

• Sterownik odległości: Obliczał euklidesową odległość do celu i stosował wzmocnienie proporcjonalne, aby wyznaczyć prędkość do przodu/do tyłu
• Sterownik theta: Obliczał błąd kątowy między aktualnym kierunkiem robota a pożądanym kierunkiem do celu, stosując oddzielne wzmocnienie proporcjonalne dla prędkości obrotowej

Algorytm nieustannie obliczał euklidesową odległość do celu oraz błąd kątowy między aktualnym kierunkiem robota a pożądanym kierunkiem. Dwa oddzielne wzmocnienia proporcjonalne były stosowane odpowiednio do generowania prędkości liniowej i kątowej.

To spowodowało, że Triton naturalnie obracał się w stronę celu, jednocześnie poruszając się do przodu, tworząc płynne zakrzywione trajektorie. Kluczową zaletą było to, że robot zawsze utrzymywał swoją przednią stronę skierowaną w stronę celu, co miało kluczowe znaczenie w zastosowaniach opartych na kamerze.

Metoda 2: Sterownik współrzędnych X-Y

To podejście traktowało robota jak dwuwymiarowy ploter, z niezależnym sterowaniem ruchem w osi X i Y:

• Sterownik X: Bezpośrednio sterował ruchem wschód-zachód na podstawie błędu współrzędnej X
• Sterownik Y: Bezpośrednio sterował ruchem północ-południe na podstawie błędu współrzędnej Y

Implementacja obliczała błędy współrzędnych X i Y niezależnie, stosowała osobne wzmocnienia proporcjonalne, a następnie przekształcała te globalne składowe prędkości do lokalnego układu współrzędnych robota za pomocą macierzy rotacji. To przekształcenie było konieczne, ponieważ napęd omni-wheel robota wymagał prędkości w jego własnym układzie odniesienia, a nie w globalnych współrzędnych. Metoda ta dawała najbardziej bezpośrednie trajektorie do celów i była znacząco szybsza, ale kierunek ustawienia robota dryfował, ponieważ nie było jawnej kontroli orientacji.

W przypadku metody #1 opisałem tę metodę bardzo szczegółowo w moim blogu Move Turtle (TurtleSim). Gorąco polecam przeczytanie tego wpisu, aby poznać wszystkie szczegóły działania regulatorów PID ogólnie, a także sposób działania metody #1. Opracowałem metodę #1 z użyciem TurtleSim w ROS, a następnie przeniosłem ten kod na Tritona i zaktualizowałem go tak, aby uwzględniał bardziej rzeczywiste środowisko.

Metoda #2 używała dość odmiennego, ale równie skutecznego podejścia. Zamiast myśleć o orientacji robota i odległości do celu, metoda ta traktuje ruch jak problem na płaszczyźnie współrzędnych. Sterownik nieustannie oblicza błąd osobno w kierunkach X i Y. Na przykład, jeśli robot musi przejść z punktu (0,0) do (2,3), traktuje to jako konieczność skorygowania błędu 2 metrów w osi X i 3 metrów w osi Y. Dwa regulatory proporcjonalne działały jednocześnie: jeden regulował prędkość robota w kierunku X na podstawie błędu X, a drugi obsługiwał ruch w kierunku Y na podstawie błędu Y. Tworzyło to bardziej bezpośrednią drogę do celu, podobną do ruchu głowicy drukarki 3D, i pozwalało na płynne ruchy po przekątnej. Robot nie musiał jawnie obracać się w stronę celu, co czyniło tę metodę szczególnie skuteczną w ciasnych przestrzeniach lub tam, gdzie wymagane jest precyzyjne pozycjonowanie.

Obie metody okazały się znacząco szybsze i bardziej niezawodne niż pierwotne podejście. Aby zobaczyć te nowe metody w działaniu, sprawdź playlistę Tritons in Action, która pokazuje wszystkie Tritony w akcji z nowymi metodami.

To, co wcześniej zajmowało 30–45 sekund przy prostym ruchu z punktu do punktu, teraz trwało około 8–12 sekund. Co ważniejsze, Triton mógł teraz sprawniej poruszać się w ciasnych przestrzeniach, co okazało się przydatne w naszych scenariuszach wielorobotowych.

Wyzwania rozwojowe i debugowanie

Wdrożenie tych regulatorów nie było proste i wiązało się z kilkoma poważnymi wyzwaniami debugowania:

Transformacje układów współrzędnych: Jednym z najtrudniejszych aspektów było poprawne wykonanie transformacji współrzędnych. System Optitrack dostarczał dane we własnym układzie współrzędnych, robot miał swój lokalny układ współrzędnych, a ja musiałem dokładnie przekształcać je między sobą. Wczesne implementacje powodowały, że roboty poruszały się w złych kierunkach, ponieważ pomieszałem obliczenia macierzy rotacji.

Zachowanie w rzeczywistości vs. idealne: Największym wyzwaniem było uwzględnienie czynników rzeczywistych, które nie pojawiają się w podręcznikowej teorii sterowania. Koła robota miały różne charakterystyki tarcia, silniki nie reagowały identycznie, a w łańcuchu komunikacji od Optitrack do oprogramowania sterującego, a następnie do Arduino robota zawsze występowało pewne opóźnienie. Spędziłem tygodnie na dostrajaniu wzmocnień proporcjonalnych i dodawaniu filtrów martwej strefy, aby uwzględnić te fizyczne realia.

Problemy z oscylacją i stabilnością: Moje pierwsze implementacje cierpiały na problemy z oscylacją, w których roboty przejeżdżały poza cel i chwiały się tam i z powrotem. Nauczyło mnie to, jak ważne są człony różniczkujące w regulatorach PID oraz potrzeba właściwego strojenia wzmocnień. Ostatecznie zdecydowałem się głównie na sterowanie proporcjonalne z precyzyjnie dostrojonymi wzmocnieniami zamiast pełnego PID, ponieważ wewnętrzne tłumienie systemu było wystarczające w większości zastosowań.

Zakłócenia między robotami: Gdy wiele robotów pracowało jednocześnie, odkryłem nieoczekiwane wzorce zakłóceń. Roboty czasami „walczyły” o tę samą przestrzeń albo tworzyły sytuacje zakleszczenia, w których blokowały się wzajemnie bez końca. Doprowadziło mnie to do wdrożenia mechanizmów koordynacji i algorytmów unikania kolizji.

System sterowania wieloma Tritonami

Gdy rozwiązałem problem ruchu pojedynczego Tritona, kolejnym wyzwaniem w laboratorium było sprawienie, by wiele Tritonów działało jednocześnie. Stało się to jednym z moich głównych obszarów zainteresowania i ostatecznie stanowiło znaczący wkład w projekt.

Pierwotny system mógł sterować tylko jednym Tritonem naraz, co poważnie ograniczało możliwości badawcze. Laboratorium chciało symulować scenariusze, w których wiele autonomicznych pojazdów musiało koordynować swoje ruchy, na przykład samochody autonomiczne komunikujące się ze sobą w celu optymalizacji przepływu ruchu i tworzenia lepszych map SLAM (jednoczesnej lokalizacji i mapowania).

Aby to rozwiązać, wdrożyłem podejście wieloprocesowe z wykorzystaniem biblioteki multiprocessing w Pythonie. Każdy Triton otrzymał własny, dedykowany proces, który mógł działać niezależnie, a jednocześnie był koordynowany przez centralny system sterowania. Umożliwiło to jednoczesny ruch wielu Tritonów bez zakłócania swoich pętli sterowania.

Projekt architektury wielorobotowej

Zaprojektowana przeze mnie architektura systemu składała się z kilku kluczowych komponentów:

Główny proces sterujący: Służył jako centralny koordynator, obsługując interakcje interfejsu użytkownika, planowanie ścieżek i koordynację wysokiego poziomu między robotami. Utrzymywał stan globalny i rozdzielał polecenia do poszczególnych procesów robotów.

Pojedyncze procesy robotów: Każdy Triton miał własny dedykowany proces Pythona, który obsługiwał:

• Obliczenia sterowania PID w czasie rzeczywistym z częstotliwością ~50 Hz
• Komunikację ze sprzętem robota (Arduino/Jetson)
• Lokalną realizację ścieżki i unikanie przeszkód
• Raportowanie stanu do głównego sterownika

Komunikacja w pamięci współdzielonej: Użyłem obiektów multiprocessing.shared_memory i Queue w Pythonie, aby umożliwić wydajną komunikację między procesami. Zapewniło to koordynację w czasie rzeczywistym bez narzutu komunikacji sieciowej.

Mechanizmy synchronizacji: Aby zapobiec konfliktom, gdy wiele robotów musiało się koordynować (na przykład unikać kolizji), wdrożyłem semafory i blokady, które pozwalały robotom żądać wyłącznego dostępu do określonych obszarów przestrzeni roboczej.

Wyzwaniem było zapewnienie, że wszystkie roboty mogą niezależnie obsługiwać swoje pętle sterowania, a jednocześnie zachowywać globalną koordynację. Każdy proces robota wykonywał własne obliczenia PID i wysyłał polecenia silników bezpośrednio do sprzętu, podczas gdy proces główny obsługiwał koordynację wyższego poziomu, taką jak unikanie kolizji i planowanie ścieżek.

System wielotritonowy otworzył zupełnie nowe możliwości badawcze. Teraz mogliśmy symulować:

• Scenariusze komunikacji pojazd-pojazd
• Koordynowane planowanie ścieżek z unikaniem przeszkód
• Zachowania robotyki roju
• Mapowanie SLAM wieloagentowe
• Sterowanie formacją i zachowania podążania

Oto, jak wyglądało stanowisko laboratoryjne z wieloma Tritonami działającymi jednocześnie:

Opracowałem również przyjazny dla użytkownika interfejs, który pozwalał badaczom wizualnie definiować ścieżki dla każdego Tritona. Można było dosłownie narysować ścieżkę, którą miał podążać każdy robot, a następnie wykonywały one te trajektorie z doskonałą koordynacją. Było to niezwykle przydatne przy przygotowywaniu złożonych eksperymentów bez konieczności ręcznego kodowania każdego ruchu.

System mógł obsługiwać jednocześnie do 5 Tritonów, z których każdy uruchamiał własne regulatory PID, a jednocześnie był koordynowany przez centralny system sterowania. Wydajność była imponująca, a wszystkie roboty zachowywały swoją indywidualną dokładność, jednocześnie pracując razem jako zespół.

Oto playlista pokazująca Tritony w akcji, od sterowania pojedynczym robotem po koordynację wielu robotów: Tritons in Action Playlist

Integracja czujnika głębi i korekcja współrzędnych

Kolejnym ważnym osiągnięciem, nad którym pracowałem, było wykorzystanie kamer głębi Intel RealSense D435 zamontowanych na każdym Tritonie. Chociaż system Optitrack dostarczał nam niezwykle precyzyjnych danych pozycjonowania, chciałem zbadać, jak roboty mogą używać swoich pokładowych czujników, aby poprawić świadomość przestrzenną i korygować błędy współrzędnych.

Pomysł polegał na tym, że Tritony mogły używać swoich czujników głębi do wykrywania innych Tritonów w swoim otoczeniu i porównywania ich pozycji. Miało to służyć kilku celom:

1. Korekcja błędów: Jeśli system Optitrack miałby jakikolwiek dryf kalibracji lub tymczasową utratę widoczności, roboty mogłyby używać wizualnego potwierdzenia pozycji innych, aby utrzymywać dokładne układy współrzędnych.

2. Ulepszony SLAM: Dzięki temu, że wiele robotów z czujnikami głębi pracuje razem, moglibyśmy tworzyć znacznie bogatsze mapy środowiska z nadmiarowymi punktami danych.

3. Unikanie kolizji: Pomiar głębi w czasie rzeczywistym pozwoliłby robotom wykrywać się nawzajem i omijać siebie nawet wtedy, gdy centralny system sterowania miałby opóźnienia komunikacyjne.

Zacząłem eksperymentować z algorytmami, które pozwoliłyby Tritonom:

• Wykrywać inne Tritony za pomocą ich charakterystycznego trójkątnego kształtu i odblaskowych znaczników kulistych
• Obliczać względne pozycje i orientacje na podstawie danych głębi
• Porównywać te pomiary z danymi Optitrack, aby identyfikować rozbieżności
• Potencjalnie dostosowywać swój układ współrzędnych w czasie rzeczywistym, aby utrzymać dokładność

Eksperymenty z wizją komputerową

Spędziłem dużo czasu, eksperymentując z potokiem wizji komputerowej, który działał w kilku etapach:

Przetwarzanie danych głębi: Intel RealSense D435 dostarczał zarówno strumienie danych RGB, jak i danych głębi. Pracowałem głównie z danymi głębi, które miały postać tablicy 640x480 pomiarów odległości z częstotliwością 30 Hz. Pierwszym wyzwaniem było odfiltrowanie tych zaszumionych danych głębi, aby wydobyć sensowną informację geometryczną.

Próby wykrywania obiektów: Eksperymentowałem z wieloetapowymi algorytmami detekcji. Odniosłem pewien sukces, segmentując obraz głębi, aby identyfikować obiekty na poziomie podłogi (z odfiltrowaniem ścian, sufitu itd.) i szukając obiektów o odpowiednich cechach rozmiaru, mniej więcej o podstawie 0,3x0,3 metra. Próbowałem używać wykrywania krawędzi i analizy geometrycznej do identyfikacji charakterystycznego profilu Tritona, z mieszanymi wynikami.

Eksperymenty z rozpoznawaniem znaczników: Trzy odblaskowe kule na każdym Tritonie wydawały się najbardziej obiecującą cechą wykrywania. Eksperymentowałem z algorytmami wykrywania blobów, aby zidentyfikować charakterystyczny trójkątny układ trzech jasnych punktów w obrazie głębi. Uzyskałem obiecujące wyniki w kontrolowanych warunkach oświetleniowych, choć nie było to konsekwentnie niezawodne.

Badania nad fuzją współrzędnych: Badałem podejścia do łączenia szacunków pozycji opartych na wizji z danymi Optitrack, w tym podstawowe implementacje filtru Kalmana. Koncepcja polegała na tym, aby nadawać większą wagę danym Optitrack, gdy są dostępne, ale w razie potrzeby przechodzić na wizję, choć nie udało mi się tego w pełni uruchomić przed końcem mojego czasu w laboratorium.

Wyzwania wydajnościowe: Uruchomienie całego tego przetwarzania w czasie rzeczywistym równolegle z pętlami sterowania robota okazało się trudne. Eksperymentowałem z metodami optymalizacji, aby algorytmy działały z częstotliwością około 10-15 Hz, nie przeciążając możliwości obliczeniowych Jetson Nano.

Niestety, musiałem opuścić laboratorium, zanim mogłem w pełni ukończyć tę pracę z zakresu wizji komputerowej. Choć miałem kilka obiecujących wczesnych wyników i nauczyłem się dużo o przetwarzaniu danych z czujników głębi, nie doprowadziłem systemu do w pełni niezawodnego stanu. Pozostał on interesującym kierunkiem badań, na którym inni mogliby potencjalnie budować.

Oto film przedstawiający, jak testuję algorytmy wizji komputerowej:

Tak wyglądał widok z czujnika głębi podczas moich eksperymentów:

Choć nie ukończyłem pracy nad integracją czujnika głębi, koncepcja wykazywała potencjał do zastosowań takich jak symulowanie scenariuszy samochodów autonomicznych, gdzie pojazdy muszą być świadome siebie nawzajem, nie polegając wyłącznie na zewnętrznej infrastrukturze. Kierunek badań, który zacząłem eksplorować, mógłby potencjalnie przyczynić się do przyszłych prac w laboratorium.

Dokumentacja i zachowanie wiedzy

Jednym z moich najważniejszych wkładów do HCR Lab, a być może tym, z którego jestem najbardziej dumny, było uporządkowanie i zachowanie całej dokumentacji projektowej. Kiedy dołączyłem do laboratorium, wiedza o projekcie Triton była rozproszona po wielu platformach i formatach. Krytyczne informacje były rozrzucone po:

• Różnych kontach Google Drive należących do różnych studentów, którzy ukończyli studia
• Starych e-mailach ukrytych w skrzynkach odbiorczych
• Losowych folderach Dropbox
• Wielu repozytoriach GitHub
• Repozytoriach GitLab o niespójnej organizacji
• Ręcznie pisanych notatkach, które tylko konkretne osoby potrafiły zinterpretować

Ta rozproszona dokumentacja była ogromnym problemem. Nowi studenci spędzali tygodnie tylko na próbach zrozumienia, od czego zacząć, a cenna wiedza była stale tracona, gdy ludzie kończyli studia lub odchodzili z laboratorium.

Postanowiłem rozwiązać ten problem systematycznie. Spędziłem niezliczone godziny na odnajdywaniu każdego fragmentu dokumentacji, kodu, filmu i notatki związanych z projektem Triton. Następnie uporządkowałem wszystko w scentralizowanym repozytorium GitLab z jasną, logiczną strukturą.

Scentralizowana dokumentacja obejmowała:

• Instrukcje budowy: Instrukcje krok po kroku dotyczące składania Tritonów od podstaw
• Konfigurację oprogramowania: Kompleksowe przewodniki po konfiguracji środowiska deweloperskiego
• Dokumentację kodu: Dobrze skomentowany kod z jasnymi wyjaśnieniami
• Specyfikacje sprzętowe: Szczegółowe listy części, schematy połączeń i projekty PCB
• Przewodniki rozwiązywania problemów: Typowe problemy i ich rozwiązania
• Samouczki wideo: Tworzyłem i przesyłałem filmy instruktażowe na YouTube, w tym szczegółowe samouczki kalibracji Optitrack:

Ustanowiłem także standardy dokumentacji, aby zapewnić, że przyszłe wkłady będą uporządkowane i dostępne. Struktura repozytorium, którą stworzyłem, stała się podstawą dla wszystkich późniejszych prac w laboratorium.

Poza samym porządkowaniem istniejącej dokumentacji stworzyłem kilka oryginalnych przewodników i samouczków, które wypełniły krytyczne luki w bazie wiedzy. Obejmowały one szczegółowe instrukcje konfiguracji dla nowych członków laboratorium, obszerne przewodniki rozwiązywania problemów oraz wideo-przeglądy złożonych procedur.

Wpływ był natychmiastowy i trwały. Nowi studenci mogli wejść na odpowiedni poziom w ciągu dni, a nie tygodni. Repozytorium dokumentacji, które stworzyłem, jest nadal używane przez laboratorium do dziś, wiele lat po moim odejściu. Stało się pojedynczym źródłem prawdy dla projektu Triton i zaoszczędziło niezliczone godziny/dni przyszłym badaczom.

Mentoring i przekazywanie wiedzy

Jednym z najbardziej satysfakcjonujących aspektów mojego czasu w HCR Lab była możliwość mentorskiego wspierania innych i dzielenia się wiedzą, którą zdobyłem. W miarę jak moja praca postępowała i nabierałem większego doświadczenia z systemami Triton, przyjmowałem coraz większą odpowiedzialność za szkolenie nowych członków zespołu.

Mentoring następców w laboratorium

Gdy przygotowywałem się do ostatecznego odejścia z laboratorium, aby skupić się na ukończeniu studiów i mojej pracy w eBay, dopilnowałem, aby dokładnie przeszkolić dwie osoby, które miały przejąć projekt Triton po moim odejściu. Nie chodziło tylko o pokazanie im, jak wszystko działa, ale o upewnienie się, że naprawdę rozumieją podstawowe zasady, aby mogli nadal wprowadzać innowacje.

Spędziłem z nimi tygodnie, pracując bardzo blisko i przechodząc przez:

• Matematyczne podstawy systemów sterowania PID
• Architekturę wieloprocesową do koordynacji wielu robotów
• Integrację czujników głębi i algorytmy wizji komputerowej
• System dokumentacji i sposób jego utrzymania
• Techniki debugowania i typowe tryby awarii

Przekazywanie wiedzy było niezwykle gruntowne. Wspólnie przechodziliśmy przez rzeczywiste sesje debugowania, kazałem im modyfikować i rozszerzać istniejący kod i dopilnowałem, aby potrafili samodzielnie konfigurować nowe Tritony od podstaw.

Program mentoringu dla uczniów szkoły średniej

Być może jeszcze bardziej satysfakcjonujące było moje doświadczenie mentoringu ucznia szkoły średniej w ramach programu outreach laboratorium. Była to świetna okazja, aby na etapie kształtowania się edukacji wprowadzić kogoś w świat robotyki, informatyki i badań naukowych.

Opracowałem kompleksowy program nauczania, który obejmował:

Podstawy informatyki:

• Pojęcia programowania z użyciem Pythona jako głównego języka
• Wprowadzenie do programowania obiektowego
• Zrozumienie algorytmów i struktur danych

Pojęcia z robotyki:

• Jak działają czujniki i jak się z nimi komunikować
• Sterowanie aktuatorami i systemami silnikowymi
• Podstawy systemów autonomicznych i sterowania ze sprzężeniem zwrotnym

ROS (Robot Operating System):

• Zrozumienie systemu komunikatów publish/subscribe
• Tworzenie węzłów i usług
• Praca z plikami launch i serwerami parametrów

Praktyczna praca nad projektem:

• Współpracowaliśmy nad stworzeniem usługi ROS, która sterowała systemem LED na głowie Tritona
• Nauczyła się pisać czysty, udokumentowany kod, który integrował się z naszymi istniejącymi systemami
• Usługa sterowania LED, którą stworzyła, stała się stałą częścią bazy kodu Tritona

To, co czyniło ten mentoring szczególnie wyjątkowym, to obserwowanie jej rozwoju od osoby praktycznie nic nie wiedzącej o programowaniu do kogoś, kto wnosił wartościowy kod do aktywnego projektu badawczego. Przeszła drogę od pytania „Czym jest zmienna?” do samodzielnego debugowania problemów komunikacyjnych ROS i pisania własnych implementacji usług.

System sterowania LED, który opracowała, pozwalał badaczom z łatwością zmieniać kolory i wzory diod LED na głowie Tritona za pomocą prostych poleceń ROS. Może to brzmieć prosto, ale wymagało zrozumienia architektury ROS, integracji z hardware’em oraz odpowiednich wzorców projektowych oprogramowania. Jej wkład jest nadal wykorzystywany w laboratorium do dziś.

Mentoring był dla mnie równie edukacyjny, jak dla niej. Zmuszał mnie do rozbijania złożonych pojęć na przyswajalne kawałki i naprawdę przemyślenia podstaw tego, co robiliśmy. Nauczanie kogoś innego sprawiło, że stałem się lepszym inżynierem i badaczem.

Współpraca z badaniami doktoranckimi

Jednym z najbardziej satysfakcjonujących zawodowo aspektów mojego czasu w laboratorium była ścisła współpraca z Pengiem, doktorantem, którego badania koncentrowały się na algorytmach samochodów autonomicznych. Udoskonalenia oprogramowania, które wprowadziłem do systemu Triton, pomogły wesprzeć jego badania doktorskie.

Badania Penga wymagały precyzyjnej, niezawodnej koordynacji wielu robotów, aby symulować scenariusze samochodów autonomicznych. Przed moimi ulepszeniami w zakresie sterowania ruchem i systemów wielorobotowych przeprowadzanie tych eksperymentów było znacznie trudniejsze. Roboty były wolniejsze, mniej dokładne i nie potrafiły współpracować tak skutecznie.

Mój wkład pomógł badaniom Penga w kilku obszarach:

Badania nad zarządzaniem skrzyżowaniami: Dzięki ulepszonym regulatorom PID i koordynacji wielu robotów Peng mógł symulować scenariusze skrzyżowań, w których wiele „pojazdów” (Tritonów) musiało koordynować swoje ruchy. Lepsze wyczucie czasu i pozycjonowanie sprawiły, że badania te stały się bardziej wykonalne.

Komunikacja pojazd-pojazd: Ramy wieloprocesowe, które opracowałem, pozwoliły Pengowi implementować i testować protokoły komunikacyjne między symulowanymi pojazdami. Każdy Triton mógł podejmować decyzje, jednocześnie koordynując działania z innymi, podobnie jak samochody autonomiczne mogą musieć działać.

Badania SLAM i mapowania: Prace nad integracją czujnika głębi dostarczyły Pengowi dodatkowych danych do jego badań nad jednoczesną lokalizacją i mapowaniem. Posiadanie wielu robotów z koordynowanymi zdolnościami wykrywania pozwoliło na bardziej kompleksowe eksperymenty mapowania.

To, co czyniło naszą współpracę szczególnie wartościową, to fakt, że nie było to tylko moje pomaganie jego badaniom — to było prawdziwe partnerstwo. Zrozumienie przez Penga teoretycznych aspektów pojazdów autonomicznych pomagało ukierunkować moje praktyczne implementacje. Jego uwagi i wymagania popychały mnie do tworzenia bardziej odpornych i wydajnych systemów.

Spędziliśmy razem wiele godzin w laboratorium, debugując scenariusze, omawiając różne strategie sterowania i badając, do czego platforma Triton może doprowadzić. Peng stał się zarówno kolegą, jak i przyjacielem, a praca z nim nauczyła mnie wiele o tym, jak naprawdę wygląda akademickie badanie.

Systemy, które zbudowałem, stały się użyteczną częścią pracy doktorskiej Penga. Widzenie, jak mój praktyczny wkład inżynieryjny wspiera badania nad technologią pojazdów autonomicznych, było naprawdę satysfakcjonujące. Umocniło to moje zainteresowanie tym, jak solidna inżynieria i badania mogą współpracować, aby tworzyć użyteczne rezultaty.

Nawet po tym, jak opuściłem laboratorium, Peng i ja pozostaliśmy w kontakcie. Świadomość, że moja praca nadal przyczyniała się do ważnych badań nawet po moim odejściu, była niezwykle satysfakcjonująca.

Perspektywa: era rozwoju sprzed LLM

Warto zauważyć, że cała ta praca została wykonana w erze rozwoju oprogramowania sprzed LLM. Wszystko to miało miejsce między 2020 a 2021 rokiem (głównie w 2021), zanim istniały ChatGPT, Claude, Perplexity czy narzędzia deweloperskie oparte na AI, takie jak Cursor IDE.

Każda linia kodu była pisana od zera, każdy algorytm był badany na podstawie prac akademickich i podręczników, a każda sesja debugowania wykorzystywała tradycyjne metody, takie jak instrukcje print, debugery i metodyczne testowanie. Kiedy utknąłem na problemie transformacji współrzędnych albo strojenia PID, nie mogłem po prostu zapytać asystenta AI o wyjaśnienie koncepcji lub pomoc w debugowaniu problemu.

To sprawiło, że proces tworzenia był znacznie trudniejszy, ale też bardziej edukacyjny. Musiałem:

Wszystko badać ręcznie: Zrozumienie teorii sterowania PID oznaczało czytanie podręczników i prac akademickich. Rozgryzienie transformacji współrzędnych wymagało ręcznego przechodzenia przez matematykę. Każda koncepcja musiała zostać w pełni zrozumiana przed implementacją.

Debugować bez pomocy AI: Gdy roboty poruszały się w nieoczekiwanych kierunkach albo oscylowały wokół celów, musiałem metodycznie prześledzić logikę, dodać wyjścia debugujące i testować hipotezy jedną po drugiej. Nie było AI, które mogłoby zasugerować potencjalne problemy lub pomóc zinterpretować wzorce błędów.

Uczyć się od podstaw: Bez możliwości szybkiego zapytania „jak zaimplementować wieloprocesowość w Pythonie dla robotyki?” musiałem głęboko zrozumieć leżące u podstaw pojęcia. Zmuszało mnie to do budowania solidnych podstaw w programowaniu współbieżnym, systemach sterowania i wizji komputerowej.

Dokumentacja była kluczowa: Ponieważ nie mogłem polegać na AI, które później wyjaśniłoby kod, musiałem pisać niezwykle jasną dokumentację i komentarze. Ta dyscyplina okazała się bezcenna przy przekazywaniu wiedzy innym.

Patrząc wstecz, choć nowoczesne narzędzia AI przyspieszyłyby wiele aspektów rozwoju, praca bez nich zmusiła mnie do rozwinięcia głębszych umiejętności rozwiązywania problemów i pełniejszego zrozumienia leżących u podstaw systemów. Fascynujące jest myślenie o tym, jak inaczej ten projekt mógłby wyglądać, gdyby dostępne były dzisiejsze narzędzia deweloperskie.

Trudna decyzja o odejściu

Choć bardzo lubiłem pracę w HCR Lab, pod koniec 2021 roku stanąłem przed trudną decyzją, z którą mierzy się wielu studentów: pogodzeniem wielu możliwości i obowiązków. Jednocześnie pracowałem na pełen etat jako inżynier oprogramowania w eBay, kończyłem studia informatyczne w Mines i współpracowałem przy badaniach w HCR Lab.

Możliwość pracy w eBay była znacząca; była to moja pierwsza duża rola jako inżynier oprogramowania, zapewniała bezcenne doświadczenie branżowe i dawała mi stabilny dochód. Jednak próba utrzymania pracy na pełen etat, ukończenia studiów i sensownego wkładu w badania była po prostu nie do utrzymania. Coś musiało ustąpić.

Kiedy zwróciłem się do dr. Zhanga z pytaniem o możliwość zmniejszenia obciążenia zajęciami, aby bardziej skupić się na pracy w laboratorium, zdecydowanie odradził mi taki krok. Jego rozumowanie było trafne: ukończenie studiów powinno być priorytetem, a doświadczenie branżowe w eBay będzie cenne dla mojego rozwoju zawodowego. Uważał, że rezygnacja z zajęć na rzecz badań, choć kusząca, może nie być najlepszą długoterminową decyzją.

Więc we wrześniu 2021 roku, po około 8 miesiącach intensywnej pracy w laboratorium, podjąłem trudną decyzję, by wycofać się z roli asystenta badawczego i skupić się na ukończeniu studiów oraz pracy w eBay. Była to jedna z trudniejszych decyzji zawodowych, jakie musiałem podjąć w tamtym czasie.

Nawet po oficjalnym odejściu z laboratorium nadal służyłem pomocą zawsze, gdy ktoś potrzebował wsparcia przy systemach, które zbudowałem. Aktualizowałem dokumentację, gdy było to potrzebne, odpowiadałem na pytania dotyczące debugowania i pomagałem zdalnie rozwiązywać problemy. Kontakty, które nawiązałem, i zaangażowanie w sukces projektu nie zniknęły tylko dlatego, że nie byłem już oficjalnie częścią zespołu.

Refleksje i spojrzenie wstecz

Teraz, w 2025 roku, cztery lata później, zastanawiam się nad tamtym okresem z mieszanymi emocjami. Moja ścieżka kariery poprowadziła mnie głęboko w rozwój webowy i inżynierię AI/ML, obszary, które były niezwykle satysfakcjonujące i dały ogromne możliwości rozwoju oraz wpływu.

A jednak jest we mnie część, która pyta „co by było, gdyby”. Robotyka była i szczerze mówiąc nadal jest moją prawdziwą pasją. Jest w pracy z systemami fizycznymi, w obserwowaniu, jak twój kod przekłada się na rzeczywisty ruch i zachowanie, coś, czego rozwój webowy, a nawet praca nad AI, nie potrafią całkiem odtworzyć.

Czasem zastanawiam się, co mogłoby się wydarzyć, gdybym obrał inną ścieżkę. Co by było, gdybym znalazł sposób, by pozostać w badaniach nad robotyką? Co by było, gdybym od razu po ukończeniu studiów pierwszego stopnia poszedł na studia magisterskie lub doktoranckie? Co by było, gdybym zdecydował się postawić pracę w laboratorium ponad doświadczenie branżowe?

Ale rozumiem też, że każda ścieżka ma swoje kompromisy. Umiejętności, które rozwinąłem w rozwoju webowym i AI, były niezwykle cenne. Doświadczenie branżowe nauczyło mnie inżynierii oprogramowania na dużą skalę, projektowania doświadczenia użytkownika i praktycznych wyzwań związanych z tworzeniem produktów używanych przez miliony ludzi. Te doświadczenia uczyniły mnie ogólnie lepszym inżynierem.

Praca, którą wykonałem w HCR Lab, nadal wpływa na to, jak dziś podchodzę do problemów. Systematyczne myślenie wymagane w systemach sterowania PID pojawia się w tym, jak projektuję pętle sprzężenia zwrotnego w systemach oprogramowania. Umiejętności dokumentowania i zachowywania wiedzy, które rozwinąłem, były bezcenne w każdej późniejszej roli. Doświadczenie mentoringu i nauczania ukształtowało to, jak pracuję z młodszymi programistami i jak przyczyniam się do dzielenia się wiedzą w zespole.

Najważniejsze jest to, że to doświadczenie nauczyło mnie, iż najlepiej rozwijam się, pracując nad wymagającymi problemami technicznymi, które mają realny wpływ. Niezależnie od tego, czy chodzi o optymalizację algorytmów ruchu robotów, czy budowanie systemów AI, które pomagają użytkownikom osiągać ich cele, satysfakcja płynie z rozwiązywania trudnych problemów, które mają znaczenie.

Trwały wpływ

Patrząc wstecz na doświadczenie w HCR Lab, uderza mnie, jak wiele osiągnąłem w stosunkowo krótkim czasie. Systemy, które zbudowałem, fundamentalnie zmieniły sposób działania platformy Triton, a wiele z tych ulepszeń jest używanych do dziś. Repozytorium dokumentacji, które stworzyłem, stało się bazą wiedzy dla całego projektu. Relacje mentoringowe, które nawiązałem, miały trwały wpływ na ludzi, z którymi pracowałem.

Ale być może najbardziej znaczące było to, że to doświadczenie pokazało mi, do czego jestem zdolny, gdy pracuję nad problemami, które naprawdę mnie pasjonują. W ciągu tych ośmiu miesięcy:

• Udoskonaliłem system sterowania ruchem robota, który ograniczał platformę
• Zbudowałem od podstaw system koordynacji wielu robotów
• Zintegrowałem możliwości widzenia komputerowego i fuzji danych z czujników
• Stworzyłem kompleksowy system dokumentacji i zarządzania wiedzą
• Mentorowałem kilka osób i pomagałem w transferze wiedzy
• Wspierałem badania na poziomie doktoranckim nad pojazdami autonomicznymi

Nie chodziło jednak tylko o osiągnięcia techniczne, choć były one dla mnie znaczące. Chodziło o to, że nauczyłem się, iż dzięki wytrwałości i systematycznemu myśleniu można wnosić użyteczny wkład nawet jako student studiów licencjackich.

Przyszłość i robotyka

Choć moja kariera potoczyła się w innych kierunkach, moja pasja do robotyki nie osłabła. Nadal śledzę rozwój tej dziedziny, ekscytują mnie postępy w uczeniu robotów i systemach autonomicznych, a w wolnym czasie od czasu do czasu pracuję nad osobistymi projektami z zakresu robotyki.

Kto wie, co przyniesie przyszłość? Umiejętności, które rozwijam w dziedzinie AI i uczenia maszynowego, są coraz bardziej istotne dla robotyki. Doświadczenie zawodowe, które zdobyłem, nauczyło mnie, jak budować solidne, skalowalne systemy. Być może nadejdzie przyszłość, w której te różne wątki mojego doświadczenia połączą się w nieoczekiwany sposób.

Na razie jestem wdzięczny za czas spędzony w laboratorium HCR i za doświadczenia, jakie mi ono zapewniło. Był to formujący okres, który ukształtował zarówno moje umiejętności techniczne, jak i moje rozumienie tego, jakiego rodzaju praca daje mi najwięcej spełnienia. Mimo że czasem za tym tęsknię, wiem, że lekcje, których się nauczyłem, i podejścia, które wypracowałem, nadal wpływają na wszystko, co robię.

Roboty Triton nadal tam są, nadal służą badaczom, nadal umożliwiają ważną pracę. I to jest całkiem wspaniałe.