Wprowadzenie
Jeszcze kilkanaście lat temu większość robotów wykonywała przede wszystkim precyzyjnie zaprogramowane sekwencje ruchów. Współczesne systemy robotyczne coraz częściej muszą natomiast działać w środowisku, którego nie można całkowicie przewidzieć: rozpoznawać obiekty, interpretować dane z wielu sensorów, wybierać sposób wykonania zadania, reagować na zmiany, a w niektórych przypadkach również uczyć się na podstawie danych lub doświadczenia.
Właśnie w tym miejscu sztuczna inteligencja w robotyce zaczyna odgrywać szczególną rolę.
Nie oznacza to jednak, że każdy autonomiczny robot wykorzystuje AI ani że każdy algorytm działający w robocie jest sztuczną inteligencją. Regulator sterujący silnikiem, obliczenia kinematyczne, klasyczny algorytm planowania ruchu czy system lokalizacji mogą działać bez uczenia maszynowego. Z drugiej strony współczesny robot może łączyć takie klasyczne metody z sieciami neuronowymi, uczeniem ze wzmocnieniem, modelami wizyjnymi czy dużymi modelami multimodalnymi.
Springer Handbook of Robotics traktuje te obszary osobno: obok architektury i programowania systemów robotycznych wyróżnia AI Reasoning Methods for Robotics oraz Robot Learning. To ważne rozróżnienie, ponieważ pokazuje, że inteligencja robota może obejmować zarówno reprezentację wiedzy i podejmowanie decyzji, jak i uczenie zachowania na podstawie danych lub doświadczenia.
W tym artykule prześledzimy cały proces: od danych z sensorów, przez percepcję i reprezentację otoczenia, aż do decyzji, planowania, uczenia i wykonania ruchu przez fizycznego robota. Zobaczymy również, czym różnią się klasyczne algorytmy robotyczne od machine learningu, czym jest reinforcement learning, Sim-to-Real i Embodied AI oraz jak do robotyki wchodzą modele VLM, LLM i VLA.
Czym jest sztuczna inteligencja w robotyce?
W najprostszym ujęciu robot jest systemem fizycznym, który odbiera informacje ze środowiska, przetwarza je i wykonuje działanie. Sensory dostarczają danych, algorytmy określają stan robota i otoczenia, a układy sterowania przekładają wynik obliczeń na ruch napędów.
Sztuczna inteligencja pojawia się wtedy, gdy część tego procesu wymaga bardziej złożonego wnioskowania, rozpoznawania wzorców, podejmowania decyzji, przewidywania albo uczenia się na podstawie danych lub doświadczenia.
Nie należy jednak utożsamiać AI wyłącznie z sieciami neuronowymi. Robotyka korzysta zarówno z metod klasycznej sztucznej inteligencji — takich jak reprezentacja wiedzy, wnioskowanie i planowanie — jak również ze współczesnego machine learningu, reinforcement learningu i modeli głębokiego uczenia. Springer Handbook of Robotics poświęca osobne rozdziały metodom wnioskowania AI oraz uczeniu robotów, co dobrze pokazuje szerokość tego obszaru.
Nowsze opracowania dotyczące AI dla robotyki dodatkowo rozszerzają ten obraz o percepcję opartą na deep learningu, modele multimodalne, reinforcement learning oraz foundation models wykorzystywane do rozumowania i sterowania robotami
Najważniejsze jest jednak zrozumienie jednej rzeczy:
AI nie zastępuje całej robotyki. Jest jedną z warstw systemu, która współpracuje z sensoryką, modelami matematycznymi, planowaniem, sterowaniem i fizyczną konstrukcją robota.
Automatyzacja, autonomia i sztuczna inteligencja to nie to samo
Te trzy pojęcia są często używane zamiennie, chociaż opisują różne właściwości systemu.
Robot może wykonywać zadanie automatycznie, nie wykorzystując przy tym sztucznej inteligencji. Może również posiadać pewien stopień autonomii dzięki klasycznym algorytmom lokalizacji, planowania i sterowania. Z kolei zastosowanie modelu AI nie oznacza automatycznie, że cały robot jest autonomiczny.
Dlatego proponuję od razu wprowadzić czytelne rozróżnienie:
Robot wykonuje wcześniej określoną sekwencję lub reaguje według zaprogramowanych reguł.
Robot samodzielnie realizuje zadanie, wykorzystując informacje o swoim stanie i otoczeniu.
System wykorzystuje metody wnioskowania, rozpoznawania wzorców, predykcji lub uczenia.
Robot inteligentny nadal potrzebuje klasycznej robotyki
Nawet najbardziej zaawansowany model AI nie poruszy fizycznego robota bez pozostałych elementów systemu.
Model wizyjny może rozpoznać kubek na stole, ale robot nadal musi określić jego położenie w przestrzeni. System decyzyjny może wybrać polecenie „podnieś kubek”, ale następnie trzeba obliczyć ruch manipulatora, zaplanować trajektorię, sterować napędami i kontrolować rezultat za pomocą sensorów.
W praktyce nowoczesny robot może więc łączyć:
klasyczne modele matematyczne + algorytmy robotyczne + systemy sterowania + metody AI.
To właśnie integracja tych warstw jest jednym z najważniejszych wyzwań współczesnej robotyki. Badania i projekty dotyczące inteligentnych robotów coraz częściej łączą percepcję, planowanie, uczenie i sterowanie w jeden system, zamiast traktować sztuczną inteligencję jako niezależny moduł. W zależności od konstrukcji robota warstwa wykonawcza może wykorzystywać między innymi kinematykę prostą i odwrotną, klasyczne układy sterowania takie jak regulator PID oraz komunikację pomiędzy modułami realizowaną przez ROS 2.
Od sensora do działania – gdzie AI znajduje się w systemie robota?
Sztuczna inteligencja nie znajduje się w robocie w jednym konkretnym miejscu. W zależności od konstrukcji systemu może wspierać percepcję, estymację stanu, podejmowanie decyzji, planowanie, uczenie zachowania, a czasem również bezpośrednie generowanie poleceń ruchu.
Jednocześnie wiele etapów może być realizowanych bez AI, za pomocą klasycznych metod robotycznych.
Dobrze pokazuje to struktura Springer Handbook of Robotics. W części poświęconej fundamentom robotyki osobno występują: sensing and estimation, motion planning, motion control, architektury systemów robotycznych, metody wnioskowania AI oraz robot learning. Oznacza to, że inteligentne zachowanie robota jest wynikiem współpracy wielu warstw, a nie działania jednego „modułu AI”.
Najprostszy model całego procesu można przedstawić tak: świat fizyczny → sensory → dane → percepcja i estymacja → decyzja → planowanie → sterowanie → ruch → ponowny pomiar
Sensor dostarcza danych, ale jeszcze nie „rozumie” otoczenia
Pierwszym etapem jest pomiar.
Robot może wykorzystywać LiDAR, kamerę 3D, IMU, enkodery, czujniki siły, mikrofony, sensory dotykowe lub inne urządzenia pomiarowe. Każdy z nich opisuje jednak tylko określony fragment rzeczywistości.
Kamera dostarcza pikseli lub danych głębi. LiDAR mierzy odległości i może tworzyć reprezentację geometryczną otoczenia. IMU rejestruje między innymi przyspieszenia i prędkości kątowe, natomiast enkodery informują o ruchu kół albo stawów.
Same dane nie odpowiadają jeszcze na pytanie: „Co znajduje się przed robotem i jakie ma to znaczenie dla wykonywanego zadania?”
To rozróżnienie jest szczególnie ważne przy rozmowie o AI. Sensor mierzy. Algorytm interpretuje pomiar.
Percepcja – od pomiaru do informacji o świecie
Kolejną warstwą jest percepcja robota.
Jej zadaniem jest przekształcenie danych sensorycznych w informacje, które mogą zostać wykorzystane przez kolejne części systemu.
Dla obrazu z kamery może to oznaczać rozpoznanie obiektu, określenie jego położenia, segmentację fragmentów sceny lub śledzenie człowieka. Dla danych 3D może chodzić o rozpoznawanie powierzchni, przeszkód czy elementów otoczenia.
Właśnie tutaj współczesne AI odgrywa bardzo dużą rolę. Deep learning jest wykorzystywany między innymi do klasyfikacji, detekcji i segmentacji obiektów w danych 2D i 3D. Nowsze podejścia rozszerzają tę warstwę o modele multimodalne, które mogą łączyć informacje wizualne z językiem.
Przykładowo kamera może dostarczyć obraz zawierający tysiące lub miliony wartości liczbowych, podczas gdy kolejny moduł systemu potrzebuje znacznie bardziej użytecznej informacji: „przed robotem znajduje się człowiek”
albo:
„na stole znajduje się czerwony kubek”.
AI może więc stanowić pomost pomiędzy surowym pomiarem a semantycznym opisem otoczenia.
Robot musi również określić własny stan
Rozumienie otoczenia nie wystarcza. Robot musi również wiedzieć możliwie dokładnie, co dzieje się z nim samym.
Może potrzebować informacji o swoim położeniu, orientacji, prędkości, konfiguracji stawów albo kontakcie kończyn z podłożem.
W tym celu dane pochodzące z wielu sensorów mogą być łączone w procesie estymacji stanu. Springer Handbook of Robotics traktuje sensing and estimation jako jeden z podstawowych fundamentów systemów robotycznych, jeszcze przed planowaniem i sterowaniem.
W robocie mobilnym częścią tego problemu może być lokalizacja oraz SLAM — jednoczesne budowanie mapy i określanie położenia robota.
Ważne jest jednak ponowne rozróżnienie: estymacja stanu nie musi wykorzystywać sztucznej inteligencji.
Może być realizowana przez klasyczne modele probabilistyczne i algorytmy matematyczne. Metody uczenia maszynowego mogą tę warstwę uzupełniać lub w niektórych rozwiązaniach zastępować część klasycznych modeli, ale nie należy nazywać każdej lokalizacji robota „AI”.
Decyzja odpowiada na pytanie: co robot powinien zrobić?
Kiedy robot posiada już informacje o swoim stanie i otoczeniu, może przejść do następnego problemu:: „Co powinienem teraz zrobić, aby osiągnąć cel?”
Na tym poziomie mogą pojawić się zarówno bardzo proste reguły, jak i rozbudowane systemy decyzyjne.
Robot może przykładowo otrzymać zadanie dostarczenia przedmiotu do innego pomieszczenia. System musi wtedy określić, jaka sekwencja działań prowadzi do celu i jak reagować na zmianę sytuacji.
Metody AI w robotyce obejmują między innymi reprezentację wiedzy, wnioskowanie oraz planowanie działań. Jednocześnie planowanie ruchu może korzystać z klasycznych algorytmów wyszukiwania, optymalizacji i metod geometrycznych. Springer Handbook of Robotics rozdziela właśnie motion planning od AI reasoning methods, co dobrze pokazuje, że planowanie robota nie zawsze oznacza zastosowanie AI.
Plan działania trzeba przełożyć na fizyczny ruch
Decyzja: „podnieś przedmiot” nie jest jeszcze poleceniem, które można bezpośrednio wysłać do silników.
Robot musi określić, gdzie znajduje się obiekt, gdzie powinien znaleźć się chwytak, jak ustawić poszczególne stawy, jaką trajektorię wykonać oraz jak uniknąć kolizji i ograniczeń mechanicznych.
Tutaj ponownie pojawiają się klasyczne elementy robotyki: kinematyka → planowanie ruchu → generowanie trajektorii → sterowanie.
AI może pomagać w części tych problemów, ale fizyczne wykonanie zadania nadal musi uwzględniać dynamikę, ograniczenia napędów, opóźnienia i rzeczywistą konstrukcję robota.
To właśnie dlatego współczesne systemy AI dla robotyki obejmują nie tylko percepcję, ale również lokalizację, planowanie, sterowanie i uczenie zachowania.
Ruch zamyka pętlę – i cały proces zaczyna się ponownie
Najważniejszym elementem całego schematu jest fakt, że robot działa w świecie fizycznym.
Jeżeli manipulator przesunie ramię, zmieni się położenie jego stawów. Jeżeli robot kroczący wykona krok, zmieni się jego orientacja i pozycja. Jeśli mobilna platforma skręci, kamera i LiDAR zaczną obserwować otoczenie z innego miejsca.
Sensory ponownie wykonują pomiary. System otrzymuje więc nowe dane, aktualizuje swój stan, interpretuje sytuację i podejmuje kolejne działanie.
Powstaje zamknięta pętla: obserwacja → interpretacja → decyzja → działanie → nowa obserwacja.
To jeden z najważniejszych powodów, dla których AI w robotyce różni się od AI działającej wyłącznie na danych cyfrowych. Decyzja algorytmu może bezpośrednio zmienić fizyczny świat, z którego za chwilę zostaną pobrane kolejne dane.
Sztuczna inteligencja może uczestniczyć w kilku etapach procesu, ale inteligentne zachowanie robota jest wynikiem współpracy sensorów, algorytmów, planowania, sterowania i fizycznej maszyny.
Ludzie, obiekty, przeszkody, powierzchnie, światło, dźwięk oraz inne elementy rzeczywistego środowiska.
Kamera, LiDAR, IMU, enkodery oraz inne czujniki obserwują robota i jego otoczenie.
Obrazy, chmury punktów, odległości, przyspieszenia, orientacja oraz pozycje stawów.
System rozpoznaje obiekty, ludzi, przeszkody lub inne istotne elementy sceny.
Robot interpretuje sytuację, przewiduje możliwe skutki i wybiera następne działanie.
System określa kolejność działań, drogę robota lub trajektorię potrzebną do osiągnięcia celu.
Kontrolery przekładają plan na konkretne polecenia dla napędów, stawów, kół lub chwytaka.
Robot jedzie, chodzi, porusza ramieniem, chwyta przedmiot albo wykonuje inne działanie.
Percepcja robota – jak AI pomaga rozumieć otoczenie?
Robot nie podejmuje decyzji bezpośrednio na podstawie „surowego świata”. Najpierw musi odebrać dane z sensorów, a następnie przekształcić je w informację użyteczną dla dalszego działania. Właśnie ten etap nazywamy percepcją.
W praktyce oznacza to przejście od prostego pomiaru do odpowiedzi na pytania: co znajduje się w otoczeniu? gdzie to się znajduje? czy stanowi przeszkodę, cel czy element tła? czy sytuacja zmienia się w czasie?
Współczesna sztuczna inteligencja w robotyce odgrywa szczególną rolę właśnie na tym etapie, ponieważ pomaga wydobyć sens z dużej liczby danych pochodzących z kamer, LiDAR-u i innych sensorów.
Percepcja nie jest tym samym co sam pomiar
Kamera rejestruje obraz, LiDAR mierzy odległości, a IMU informuje między innymi o przyspieszeniach i prędkościach kątowych. Sam pomiar nie oznacza jednak jeszcze, że robot „wie”, co znajduje się w jego otoczeniu.
Dopiero algorytmy percepcji mogą przekształcić te pomiary w bardziej użyteczne informacje o sytuacji. W zależności od zastosowania system może próbować ustalić, co znajduje się w otoczeniu, gdzie znajduje się dany obiekt oraz jak zmienia się jego położenie.
To rozróżnienie jest szczególnie ważne przy rozmowie o sztucznej inteligencji. Dane z sensora mogą być wejściem dla modelu AI, ale sam sensor nie interpretuje jeszcze znaczenia obserwowanej sytuacji.
„Percepcja robota – jak AI pomaga rozumieć otoczenie?”
„Percepcja nie jest tym samym co sam pomiar”
Computer vision – jak robot rozpoznaje obraz”Zamiast ciągu:
„Percepcja 3D – robot musi rozumieć przestrzeń”
„Fuzja danych – jeden sensor to często za mało”
Semantyczne rozumienie otoczenia
Zbudowanie geometrycznego modelu przestrzeni nie oznacza jeszcze, że robot wie, co znajduje się w jego otoczeniu. Mapa może wskazywać ściany, przeszkody i wolną przestrzeń, a kamera 3D może określić położenie powierzchni oraz obiektów. Dla wykonania bardziej złożonego zadania potrzebna jest jednak dodatkowa informacja: czym są obserwowane elementy i jakie znaczenie mają w danej sytuacji.
W tym miejscu pojawia się semantyczne rozumienie otoczenia. Polega ono na przypisywaniu obserwowanym fragmentom sceny określonych kategorii lub znaczeń, takich jak człowiek, stół, krzesło, drzwi, kubek czy podłoga. Dzięki temu reprezentacja świata może zostać rozszerzona z poziomu czystej geometrii do modelu zawierającego informacje użyteczne podczas realizacji zadania.
Różnicę można przedstawić bardzo prosto. System geometryczny może określić: „W odległości 1,8 m znajduje się obiekt o określonym kształcie i wymiarach.”
System wykorzystujący informację semantyczną może natomiast dodać:
„Ten obiekt jest stołem, a znajdujący się na nim mniejszy obiekt został rozpoznany jako kubek.”
To istotna zmiana. Robot przestaje pracować wyłącznie na współrzędnych, odległościach i chmurach punktów, a zaczyna korzystać z reprezentacji opisującej znaczenie poszczególnych elementów sceny.
Jedną z metod wykorzystywanych do tworzenia takiej reprezentacji jest segmentacja semantyczna obrazu. Algorytm przypisuje poszczególnym pikselom określoną klasę, dzięki czemu możliwe jest rozróżnienie na przykład podłogi, ściany, człowieka, mebli czy innych elementów otoczenia. Jeżeli informacja ta zostanie połączona z danymi pochodzącymi z kamery 3D lub LiDAR-u, klasy wykrytych elementów mogą zostać powiązane również z ich położeniem w przestrzeni.
- geometria odpowiada na pytanie: gdzie znajduje się obiekt i jaki ma kształt,
- percepcja wizualna pozwala określić, co zostało zaobserwowane,
- informacja semantyczna przypisuje elementowi sceny określoną klasę lub znaczenie,
- relacje przestrzenne pozwalają określić, że przedmiot znajduje się na stole, człowiek stoi obok robota albo drzwi znajdują się przed nim.
Takie informacje mogą być również nanoszone na mapę. Powstaje wtedy mapa semantyczna, która poza geometrią przestrzeni zawiera wiedzę o wybranych elementach środowiska. Zamiast mapy opisującej jedynie przeszkody i wolne obszary robot może dysponować reprezentacją wskazującą, gdzie znajduje się przejście, stół, stanowisko robocze albo określony typ obiektu.
Rozwinięciem klasycznego SLAM są systemy określane jako Semantic SLAM, w których lokalizacja i budowanie mapy są łączone z informacją o znaczeniu obserwowanych elementów. Dzięki temu mapa może stać się nie tylko geometrycznym odwzorowaniem przestrzeni, ale również strukturą przydatną podczas wykonywania zadań przez robota.
Warto jednak zachować tutaj ważne rozróżnienie. Sam fakt, że algorytm przypisał obiektowi etykietę „kubek”, nie oznacza jeszcze, że robot rozumie kubek w taki sposób jak człowiek. Rozpoznana klasa jest przede wszystkim informacją, którą mogą wykorzystać kolejne elementy systemu.
Jeżeli robot otrzyma polecenie:
„Podnieś czerwony kubek ze stołu”,
system percepcji może najpierw wykryć stół i znajdujące się na nim obiekty. Następnie może zostać wskazany obiekt należący do klasy „kubek”, określony jego kolor oraz położenie w przestrzeni. Dopiero na podstawie tak przygotowanej reprezentacji kolejne moduły mogą ocenić, czy obiekt znajduje się w zasięgu manipulatora i jak należy zaplanować działanie.
Semantyczne rozumienie sceny tworzy więc ważne połączenie pomiędzy percepcją a działaniem. Robot nie otrzymuje już jedynie zbioru pomiarów, lecz uporządkowaną reprezentację otoczenia, z której mogą korzystać systemy planowania i sterowania.
Semantyczne rozumienie sceny tworzy więc ważne połączenie pomiędzy percepcją a działaniem. Robot nie otrzymuje już jedynie zbioru pomiarów, lecz uporządkowaną reprezentację otoczenia, z której mogą korzystać systemy planowania i sterowania.
Jak robot podejmuje decyzje?
Percepcja pozwala robotowi zebrać informacje o otoczeniu, rozpoznać obiekty i określić własne położenie. To jednak dopiero początek. Aby robot mógł wykonać zadanie autonomicznie, musi jeszcze wykorzystać uzyskane informacje do wyboru odpowiedniego działania.
W robotyce podejmowanie decyzji nie oznacza jednego algorytmu pełniącego funkcję „mózgu” robota. W praktyce decyzja może powstawać na kilku poziomach. System może najpierw określić cel zadania, następnie wybrać sposób jego realizacji, zaplanować trasę lub ruch manipulatora, a na najniższym poziomie przekazać odpowiednie polecenia do układów sterowania.
Co ważne, nie każda decyzja robota wymaga sztucznej inteligencji. W wielu systemach wykorzystywane są reguły logiczne, automaty stanów, drzewa zachowań, klasyczne algorytmy planowania oraz metody optymalizacyjne. Modele uczenia maszynowego mogą być jednym z elementów tego procesu, ale nie muszą zastępować całej klasycznej architektury sterowania.
Stan robota i reprezentacja świata
Zanim system wybierze działanie, musi posiadać możliwie aktualną informację o tym, w jakim stanie znajduje się robot i co dzieje się wokół niego.
Stan robota może obejmować między innymi jego położenie, orientację, prędkość, konfigurację stawów, informacje o aktualnie wykonywanym zadaniu oraz stan poszczególnych podzespołów. Jednocześnie reprezentacja otoczenia może zawierać położenie przeszkód, wolną przestrzeń, wykryte obiekty, ludzi, elementy infrastruktury oraz inne informacje istotne dla realizacji celu.
Można więc przyjąć, że przed podjęciem działania system potrzebuje odpowiedzi na trzy podstawowe pytania:
- Gdzie jestem? – czyli jaki jest aktualny stan i położenie robota.
- Co znajduje się wokół mnie? – czyli jak wygląda aktualna reprezentacja otoczenia.
- Jaki mam cel? – czyli jaki stan końcowy lub zadanie powinno zostać osiągnięte.
Dopiero zestawienie tych informacji pozwala rozpocząć wybór działania.
Dobrym przykładem jest robot mobilny, który otrzymał polecenie dotarcia do określonego miejsca. System zna aktualną pozycję robota oraz pozycję celu, natomiast mapa zawiera informacje o ścianach i przeszkodach. Algorytm planowania może na tej podstawie wyznaczyć trasę. Jeżeli jednak na drodze pojawi się nowa przeszkoda, reprezentacja otoczenia zostaje zaktualizowana, a dotychczasowy plan może przestać być prawidłowy. Wtedy konieczne staje się ponowne zaplanowanie dalszego ruchu.
W systemie Nav2 dla ROS 2 taki proces jest rozdzielony pomiędzy kilka współpracujących elementów. Osobne komponenty mogą odpowiadać za reprezentację środowiska, planowanie trasy, sterowanie ruchem oraz wykonywanie zachowań awaryjnych. Drzewa zachowań (Behavior Trees) są natomiast wykorzystywane do koordynowania kolejności tych działań. Dokumentacja Nav2 pokazuje na przykład scenariusze, w których trasa jest ponownie obliczana podczas ruchu albo uruchamiane są odpowiednie procedury po niepowodzeniu wcześniejszego działania.
Podobne podejście występuje podczas manipulacji. W MoveIt 2 wykorzystywana jest tzw. Planning Scene – reprezentacja zawierająca aktualny stan robota oraz model otaczającego go świata. Na jej podstawie mogą być sprawdzane między innymi ograniczenia ruchu i możliwość wystąpienia kolizji podczas planowania trajektorii manipulatora.
Załóżmy, że robot humanoidalny ma podnieść przedmiot ze stołu. System musi znać nie tylko położenie przedmiotu, ale również aktualną konfigurację ramienia, położenie stołu i innych przeszkód oraz ograniczenia kinematyczne robota. Dopiero wtedy można sprawdzić, czy przedmiot znajduje się w przestrzeni roboczej i czy możliwe jest wykonanie ruchu bez kolizji.
W platformach badawczych, takich jak Unitree Go2 EDU, dostęp do SDK umożliwia tworzenie własnego oprogramowania wykorzystującego dane robota i implementowanie własnych algorytmów wyższego poziomu. Sama platforma sprzętowa nie określa jednak sposobu podejmowania decyzji – zależy on od zaprojektowanego przez programistę systemu oraz zastosowanych algorytmów. Oficjalna dokumentacja Unitree udostępnia osobny przewodnik programistyczny dla Go2 SDK.
Reprezentacja stanu robota i świata jest więc punktem wyjścia dla procesu decyzyjnego. System musi najpierw wiedzieć, jaka jest aktualna sytuacja. Dopiero później może porównać dostępne możliwości i określić, jakie działanie powinno zostać wykonane.
Reguły, algorytmy i modele decyzyjne
Robot może podejmować decyzje na wiele sposobów. Nie zawsze jest do tego potrzebna sztuczna inteligencja. W klasycznych systemach robotycznych logika działania może być zapisana bezpośrednio przez programistę, natomiast w bardziej zaawansowanych rozwiązaniach decyzje mogą wynikać z algorytmów planowania, optymalizacji albo modeli wyuczonych na danych.
Najprostszym rozwiązaniem są reguły warunkowe. System otrzymuje określony stan lub zdarzenie i wykonuje przypisaną do niego reakcję. Przykładowo: jeżeli przed robotem zostanie wykryta przeszkoda, należy zatrzymać ruch; jeżeli poziom baterii spadnie poniżej ustalonej wartości, należy rozpocząć procedurę powrotu do stacji ładowania.
Przy bardziej złożonych zadaniach liczba możliwych sytuacji szybko rośnie. Dlatego logika robota może zostać uporządkowana za pomocą automatów stanów (Finite State Machines – FSM) lub drzew zachowań (Behavior Trees – BT).
- reguły warunkowe określają reakcję systemu na konkretne zdarzenie lub stan,
- automat stanów opisuje możliwe stany robota oraz warunki przechodzenia pomiędzy nimi,
- drzewo zachowań pozwala hierarchicznie organizować działania, warunki i reakcje na powodzenie lub niepowodzenie poszczególnych czynności,
- algorytmy planowania mogą wyszukiwać rozwiązanie prowadzące od aktualnego stanu do określonego celu,
- modele uczone mogą wybierać działanie na podstawie wzorców poznanych podczas treningu.
Automat stanów może być wystarczający w prostym robocie. Przykładowa maszyna transportowa może przechodzić kolejno przez stany: oczekiwanie → jazda do celu → dostarczenie ładunku → powrót → ładowanie. Każde przejście następuje po spełnieniu wcześniej zdefiniowanego warunku.
Wraz ze wzrostem złożoności systemu utrzymanie dużej liczby stanów i przejść staje się jednak coraz trudniejsze. Dokumentacja Nav2 wskazuje właśnie tę różnicę jako jedną z zalet drzew zachowań: złożone zadania można budować z mniejszych, wielokrotnie wykorzystywanych elementów, zamiast tworzyć ogromną sieć stanów i przejść.
Drzewa zachowań – decyzja jako hierarchia
Drzewo zachowań można potraktować jako strukturę opisującą kolejność sprawdzania warunków i wykonywania działań. Poszczególne elementy drzewa mogą odpowiadać na przykład za sprawdzenie, czy droga jest wolna, wyznaczenie trasy, rozpoczęcie ruchu albo uruchomienie procedury awaryjnej.
W Nav2 drzewa zachowań są wykorzystywane do koordynowania nawigacji robota. Mogą sterować między innymi obliczaniem trasy, podążaniem za nią, ponownym planowaniem oraz zachowaniami uruchamianymi w przypadku niepowodzenia.
- sprawdź, czy cel jest dostępny,
- wyznacz trasę do celu,
- rozpocznij jazdę,
- monitoruj przeszkody i poprawność trasy,
- jeżeli trasa przestanie być prawidłowa – zaplanuj ją ponownie,
- jeżeli wykonanie zadania się nie powiedzie – uruchom zachowanie naprawcze.
Taka logika nadal nie musi wykorzystywać uczenia maszynowego. „Decyzja” robota wynika tutaj z zaprogramowanej struktury oraz aktualnych danych przekazywanych przez system percepcji.
Gdzie w procesie decyzyjnym pojawia się AI?
Sztuczna inteligencja zaczyna odgrywać większą rolę wtedy, gdy nie chcemy lub nie możemy wcześniej opisać wszystkich możliwych sytuacji za pomocą sztywnych reguł.
Model uczony może na przykład pomagać:
- oceniać sytuację na podstawie dużej liczby zmiennych,
- przewidywać zachowanie innych obiektów lub ludzi,
- wybierać działanie na podstawie doświadczeń zdobytych podczas treningu,
- dostosowywać zachowanie do warunków, które nie zostały dokładnie zaprogramowane wcześniej.
Nie oznacza to jednak, że model AI musi przejąć kontrolę nad całym robotem. W praktycznych architekturach metody klasyczne i modele uczone mogą działać obok siebie. Model może na przykład rozpoznać sytuację albo zaproponować cel działania, podczas gdy planowanie ruchu, kontrola kolizji i wykonanie trajektorii pozostają realizowane przez deterministyczne algorytmy robotyczne.
To rozróżnienie jest szczególnie istotne w systemach, w których wymagane jest przewidywalne i bezpieczne zachowanie. Im bliżej fizycznego wykonania ruchu, tym większe znaczenie mają ograniczenia kinematyczne, dynamika robota, kontrola kolizji oraz układy sterowania.
Dlatego proces decyzyjny robota najlepiej traktować nie jako pojedynczą „inteligentną decyzję”, lecz jako hierarchię współpracujących warstw – od wyboru celu, przez planowanie zadania i ruchu, aż po wykonanie poleceń przez układy sterowania.
Planowanie zadania i planowanie ruchu
Po określeniu aktualnego stanu robota, reprezentacji otoczenia oraz celu system musi przejść od odpowiedzi na pytanie „co należy zrobić?” do odpowiedzi „jak dokładnie to wykonać?”
W robotyce są to dwa różne poziomy planowania.
Planowanie zadania dotyczy kolejności czynności potrzebnych do osiągnięcia celu. Jeżeli robot ma przenieść przedmiot z jednego miejsca do drugiego, zadanie może zostać rozłożone na etapy: podejście do obiektu, jego lokalizacja, ustawienie manipulatora, wykonanie chwytu, podniesienie przedmiotu, przemieszczenie go oraz odłożenie w miejscu docelowym.
Planowanie ruchu dotyczy natomiast sposobu fizycznego wykonania wybranej czynności. System musi obliczyć taką zmianę położenia robota lub jego manipulatora, aby osiągnąć wymagany cel bez przekroczenia ograniczeń konstrukcji i – jeśli jest to wymagane – bez kolizji z otoczeniem.
Można to przedstawić w uproszczony sposób:
- planowanie zadania odpowiada na pytanie: jakie czynności i w jakiej kolejności należy wykonać,
- planowanie ruchu odpowiada na pytanie: jak przemieścić robota lub jego elementy pomiędzy kolejnymi stanami,
- sterowanie odpowiada za wykonanie zaplanowanego ruchu przez rzeczywiste napędy robota.
Od polecenia do sekwencji działań
Załóżmy, że robot otrzymuje zadanie: „Podnieś kubek ze stołu i włóż go do pojemnika.”
Dla człowieka jest to jedno polecenie. Dla systemu robotycznego może ono oznaczać konieczność wykonania całej sekwencji wzajemnie zależnych operacji.
Przykładowy przebieg może wyglądać następująco:
- zlokalizowanie kubka i określenie jego pozycji,
- wybór odpowiedniego sposobu chwytu,
- przemieszczenie manipulatora do pozycji poprzedzającej chwyt,
- zamknięcie chwytaka i sprawdzenie, czy przedmiot został uchwycony,
- podniesienie kubka bez kolizji ze stołem,
- przemieszczenie przedmiotu do pojemnika,
- odłożenie kubka i zwolnienie chwytu.
Każdy z tych etapów może wymagać osobnego planowania oraz sprawdzenia, czy poprzednia czynność zakończyła się powodzeniem
Właśnie do takich złożonych problemów został zaprojektowany MoveIt Task Constructor. Jest to framework rozwijany w ramach MoveIt 2, który pozwala rozkładać skomplikowane zadania manipulacyjne na wiele zależnych od siebie etapów. Poszczególne etapy mogą generować rozwiązania, przekazywać informacje dalej oraz łączyć różne części zadania w kompletny plan.
Planowanie ruchu manipulatora
Kiedy wiadomo już, jaka czynność ma zostać wykonana, trzeba znaleźć możliwy sposób jej realizacji.
W przypadku ramienia robota nie wystarczy wskazać położenia końcówki manipulatora. System musi uwzględnić aktualne ustawienie wszystkich stawów, zakres ich ruchu, geometrię robota oraz elementy znajdujące się w otoczeniu.
W MoveIt 2 centralną rolę odgrywa Planning Scene, która zawiera aktualny stan robota oraz reprezentację świata potrzebną podczas obliczania planu ruchu. Na jej podstawie mogą być wykonywane między innymi obliczenia kinematyki prostej i odwrotnej, sprawdzanie ograniczeń oraz kontrola potencjalnych kolizji.
Planowanie ruchu nie polega więc wyłącznie na połączeniu punktu początkowego z końcowym. Algorytm może poszukiwać rozwiązania w wielowymiarowej przestrzeni konfiguracji robota, w której każda kombinacja kątów stawów odpowiada określonemu położeniu całego mechanizmu.
Dlatego dwa ruchy prowadzące chwytak do tego samego miejsca mogą być bardzo różne. Jeden może powodować kolizję ramienia ze stołem, drugi przekraczać dopuszczalny zakres stawu, a trzeci prowadzić do celu bezpiecznie i zgodnie z ograniczeniami robota.
Planowanie ruchu robota mobilnego
Podobne rozróżnienie występuje w robotach mobilnych. System może otrzymać cel: „jedź do punktu B”, ale musi jeszcze znaleźć możliwą trasę i sterować robotem w taki sposób, aby rzeczywiście nią podążał.
W Nav2 planowanie i wykonanie ruchu zostały rozdzielone na wyspecjalizowane komponenty. Planner Server może odpowiadać za obliczenie ścieżki, natomiast Controller Server realizuje lokalne sterowanie potrzebne do jej wykonania. Osobne elementy mogą zajmować się również wygładzaniem ścieżki, reakcją na problemy czy zmianą sposobu działania.
Jest to ważne również z punktu widzenia sztucznej inteligencji. AI może na przykład pomóc robotowi określić cel zadania, rozpoznać obiekt albo wybrać odpowiednią strategię. Nie oznacza to jednak, że model AI musi samodzielnie obliczać każdą trajektorię stawów czy sterować każdym silnikiem.
W wielu praktycznych systemach wysokopoziomowa decyzja może być podejmowana przez jeden moduł, natomiast samo wykonanie pozostaje realizowane przez wyspecjalizowane algorytmy planowania, kinematyki i sterowania.
Dobrym przykładem platformy, na której takie zagadnienia mogą być badane, jest Unitree G1 EDU. Robot może być wyposażony w manipulatory i chwytaki, a jego konstrukcja obejmuje od 23 do 43 napędzanych stopni swobody zależnie od konfiguracji. Producent przewiduje również wersje z trójpalczastą dłonią Dex3-1 oraz rozwiązaniami przeznaczonymi do manipulacji obiektami.
W przypadku takiej platformy polecenie wysokiego poziomu, np. „podnieś przedmiot”, musi zostać ostatecznie przełożone na serię konkretnych ruchów wielu stawów. To właśnie pokazuje różnicę pomiędzy decyzją, planowaniem zadania i planowaniem ruchu.
Po obliczeniu planu pozostaje jeszcze jedno istotne zagadnienie: robot pracuje w świecie, który może zmienić się już podczas wykonywania zadania. Dlatego system musi umieć reagować na nowe przeszkody, błędy wykonania i informacje napływające z sensorów.
Reakcja na zmiany w otoczeniu
Nawet poprawnie zaplanowany ruch nie gwarantuje wykonania zadania. Robot działa bowiem w świecie, który może zmieniać się już po rozpoczęciu ruchu. Na trasie może pojawić się człowiek, przedmiot może zostać przesunięty, chwyt może okazać się niepewny, a rzeczywiste położenie robota może nieznacznie różnić się od przewidywanego.
Nawet poprawnie zaplanowany ruch nie gwarantuje wykonania zadania. Robot działa bowiem w świecie, który może zmieniać się już po rozpoczęciu ruchu. Na trasie może pojawić się człowiek, przedmiot może zostać przesunięty, chwyt może okazać się niepewny, a rzeczywiste położenie robota może nieznacznie różnić się od przewidywanego.
Powstaje w ten sposób zamknięta pętla: percepcja → ocena sytuacji → decyzja → plan → działanie → nowy pomiar → ponowna ocena sytuacji
Jeżeli nowe dane wskazują, że wcześniejsze założenia przestały być aktualne, system może odpowiednio zmodyfikować swoje zachowanie.
- kontynuować działanie – jeżeli sytuacja rozwija się zgodnie z planem,
- skorygować ruch – jeżeli wystąpiła niewielka różnica pomiędzy stanem oczekiwanym a rzeczywistym,
- zmniejszyć prędkość lub zatrzymać robota – jeżeli pojawiło się zagrożenie lub przeszkoda,
- ponownie zaplanować trasę albo ruch – jeżeli dotychczasowy plan nie może być dalej wykonany,
- wybrać inne zachowanie – gdy wykonanie pierwotnego zadania nie jest możliwe albo zakończyło się niepowodzeniem.
Dobrym przykładem jest robot mobilny poruszający się w korytarzu. W chwili rozpoczęcia zadania droga do celu może być całkowicie wolna. Kilka sekund później na trasie pojawia się jednak człowiek.
Robot nie powinien w takiej sytuacji bezwarunkowo realizować wcześniej obliczonej ścieżki. Dane z sensorów aktualizują reprezentację otoczenia, a system nawigacji może zmienić lokalny sposób poruszania się, wyznaczyć nową trasę, poczekać na zwolnienie przejścia albo zatrzymać robota.
W Nav2 mechanizm ponownego planowania może być częścią drzewa zachowań. Oficjalna dokumentacja pokazuje zarówno cykliczne obliczanie nowej ścieżki, jak i kontrolowanie, czy aktualna ścieżka pozostaje prawidłowa. Dostępne są również drzewa zachowań przeznaczone do nawigacji z ponownym planowaniem i procedurami odzyskiwania po błędzie.
Nie każda reakcja wymaga jednak ponownego planowania całego zadania. Czasami odpowiedź musi nastąpić znacznie szybciej.
Nav2 udostępnia między innymi Collision Monitor, który może korzystać z danych z takich źródeł jak skaner laserowy, chmura punktów, czujniki podczerwieni czy sonar. Możliwe jest zdefiniowanie obszarów wokół robota, w których wykrycie przeszkody powoduje na przykład ograniczenie prędkości albo zatrzymanie. Taka warstwa może działać niezależnie od głównego procesu planowania nawigacji.
Korekta ruchu manipulatora
Podobna sytuacja występuje podczas manipulacji obiektami. Jeżeli robot ma sięgnąć po przedmiot, jego rzeczywiste położenie może nieznacznie różnić się od pozycji ustalonej przed rozpoczęciem ruchu. W takim przypadku przydatne staje się sterowanie wykorzystujące aktualną informację zwrotną z sensorów.
W MoveIt Servo polecenia ruchu mogą być przekazywane do manipulatora na bieżąco. System obsługuje jednocześnie między innymi kontrolę kolizji, ograniczenia pozycji i prędkości stawów oraz wykrywanie zbliżania się do osobliwości kinematycznych. Dokumentacja wskazuje również zastosowanie tego mechanizmu w sterowaniu wizyjnym (visual servoing) i sterowaniu w zamkniętej pętli.
Oznacza to, że robot nie zawsze musi najpierw obliczyć kompletną trajektorię, a następnie odtworzyć ją bez zmian. W niektórych zadaniach kolejne polecenia mogą być korygowane na podstawie aktualnego położenia robota i informacji napływających z otoczenia.
Reakcja nie oznacza jeszcze uczenia się
Warto tutaj rozdzielić dwa pojęcia, które mogą wydawać się podobne.
Robot, który zauważa przeszkodę i wyznacza nową trasę, reaguje na zmianę otoczenia, ale nie musi się przy tym niczego uczyć. Algorytm może wykonywać dokładnie te same zaprogramowane procedury za każdym razem, gdy wystąpi podobna sytuacja.
Uczenie pojawia się dopiero wtedy, gdy doświadczenia lub zebrane dane wpływają na model albo sposób późniejszego działania systemu.
To rozróżnienie jest szczególnie ważne dla naszego artykułu:
- reakcja – system dostosowuje działanie do aktualnej sytuacji,
- ponowne planowanie – system wyznacza nowy sposób osiągnięcia tego samego celu,
- uczenie – wcześniejsze dane lub doświadczenia powodują zmianę modelu albo strategii działania.
W praktyce zaawansowany robot może wykorzystywać wszystkie te mechanizmy jednocześnie. Sensory stale dostarczają nowych danych, system percepcji aktualizuje reprezentację świata, warstwa decyzyjna ocenia sytuację, plan może zostać zmodyfikowany, a układy sterowania korygują rzeczywisty ruch.
Dzięki temu autonomia robota nie polega na wykonaniu jednej wcześniej przygotowanej sekwencji. Jest to ciągły proces obserwacji, podejmowania decyzji, działania i ponownej oceny rezultatu.
Machine learning w robotyce – czego może nauczyć się robot?
W poprzedniej części robot reagował na zmiany otoczenia według wcześniej zaprojektowanych reguł, algorytmów planowania i mechanizmów sterowania. Uczenie maszynowe wprowadza inną możliwość: zamiast zapisywać wszystkie zależności ręcznie, część zachowania systemu może zostać wyprowadzona z danych.
Nie oznacza to jednak, że robot „uczy się wszystkiego sam”. Najczęściej trenowany jest konkretny model realizujący określone zadanie – na przykład rozpoznawanie obiektów, przewidywanie ich położenia albo wybór działania. Pozostałe elementy robota mogą nadal korzystać z klasycznej kinematyki, planowania ruchu i regulatorów.
Warto też rozdzielić dwa etapy:
- trening modelu – etap, podczas którego algorytm analizuje dane i modyfikuje swoje parametry, aby lepiej realizować określone zadanie,
- inferencję – wykorzystanie wcześniej wytrenowanego modelu przez działającego robota do przetwarzania nowych danych i generowania wyniku.
To rozróżnienie jest szczególnie ważne w robotyce. Robot pracujący w hali produkcyjnej nie musi uczyć swojej sieci neuronowej od początku za każdym razem, gdy zobaczy nowy obraz. Może korzystać z wcześniej wytrenowanego modelu i wykonywać jego inferencję w czasie rzeczywistym. Tak właśnie zorganizowane są między innymi pakiety Isaac ROS DNN Inference, które pozwalają uruchamiać modele sieci neuronowych jako elementy systemu ROS 2.
Klasyczne algorytmy a uczenie maszynowe
Różnicę pomiędzy klasycznym programowaniem a uczeniem maszynowym można dobrze pokazać na przykładzie rozpoznawania obiektu.
W tradycyjnym podejściu programista może próbować zdefiniować cechy, które pozwalają rozpoznać dany przedmiot: jego kolor, kształt, wielkość czy określone właściwości obrazu. Następnie tworzony jest algorytm wykorzystujący te reguły.
W uczeniu maszynowym model otrzymuje dużą liczbę przykładów i podczas treningu sam dostosowuje swoje parametry tak, aby odnajdywać zależności potrzebne do rozwiązania zadania. W przypadku sieci neuronowych mogą to być tysiące, miliony, a w dużych modelach nawet miliardy parametrów.
Nie oznacza to jednak, że podejście oparte na ML jest zawsze lepsze.
- klasyczne algorytmy są często przewidywalne, łatwiejsze do analizy i bardzo skuteczne w dobrze zdefiniowanych problemach,
- uczenie maszynowe jest szczególnie przydatne tam, gdzie trudno ręcznie opisać wszystkie zależności występujące w danych,
- systemy hybrydowe łączą modele uczone z klasyczną robotyką, wykorzystując mocne strony obu podejść.
Dobrym przykładem jest percepcja. Rozpoznanie człowieka, narzędzia czy przypadkowo ułożonego przedmiotu na podstawie obrazu może być bardzo trudne do opisania zestawem prostych reguł. Model sieci neuronowej może zostać wytrenowany na wielu przykładach i następnie wykonywać detekcję nowych obiektów podczas pracy robota.
Współczesne środowiska robotyczne coraz częściej umożliwiają bezpośrednie łączenie takich modeli z klasycznym ROS 2. NVIDIA Isaac ROS zawiera pakiety przeznaczone do inferencji sieci neuronowych, detekcji obiektów, segmentacji oraz innych elementów percepcji AI. Wynik modelu może następnie zostać przekazany do kolejnych komponentów odpowiedzialnych za lokalizację, planowanie lub sterowanie.
Czego robot może nauczyć się z danych?
Zakres jest znacznie szerszy niż samo rozpoznawanie obrazu. W zależności od zastosowanego modelu i sposobu treningu system robotyczny może nauczyć się między innymi:
- rozpoznawania i klasyfikowania obiektów znajdujących się w otoczeniu,
- segmentowania sceny i rozróżniania jej poszczególnych elementów,
- określania pozycji i orientacji obiektów potrzebnych podczas manipulacji,
- przewidywania zmian zachodzących w otoczeniu,
- wyboru odpowiedniego działania w zależności od obserwowanego stanu,
- wykonywania określonego zachowania na podstawie demonstracji lub doświadczenia zdobytego podczas treningu.
Widać więc, że uczenie maszynowe może występować na różnych poziomach architektury robota. Jeden model może wspierać percepcję, drugi przewidywać ruch obiektów, a jeszcze inny generować bezpośrednio politykę sterowania.
W najnowszych rozwiązaniach granica ta staje się jeszcze mniej wyraźna. Aktualna dokumentacja Isaac ROS opisuje możliwość wdrażania na robotach zarówno polityk wytrenowanych metodami reinforcement learning, jak i modeli Vision-Language-Action (VLA). Model uczony może więc znajdować się nie tylko w warstwie percepcji, lecz również znacznie bliżej procesu wyboru i wykonania działania.
Nie każdy model uczy się jednak w ten sam sposób. Zależy to przede wszystkim od tego, jakie dane są dostępne oraz jaką informację otrzymuje algorytm podczas treningu. Dlatego kolejnym krokiem jest rozróżnienie podstawowych sposobów uczenia modeli.
Uczenie nadzorowane i nienadzorowane
To, czego model może się nauczyć, zależy nie tylko od architektury algorytmu, ale również od sposobu przygotowania danych treningowych. Jednym z podstawowych podziałów w uczeniu maszynowym jest rozróżnienie na uczenie nadzorowane i nienadzorowane. Obie grupy metod są stosowane również w robotyce, jednak służą do rozwiązywania innych problemów.
Uczenie nadzorowane – model zna prawidłową odpowiedź
W uczeniu nadzorowanym (supervised learning) każdemu przykładowi treningowemu przypisana jest informacja o oczekiwanym wyniku. Model otrzymuje więc jednocześnie dane wejściowe oraz odpowiadającą im etykietę lub wartość, której powinien się nauczyć.
Najprostszy przykład to rozpoznawanie obiektów na obrazie. Zbiór treningowy może zawierać tysiące zdjęć wraz z informacją, co znajduje się na każdym z nich. Podczas treningu parametry modelu są modyfikowane tak, aby jego odpowiedzi coraz lepiej odpowiadały prawidłowym oznaczeniom.
Oficjalna dokumentacja scikit-learn zalicza do uczenia nadzorowanego między innymi problemy klasyfikacji i regresji – model uczy się zależności pomiędzy danymi wejściowymi a znanym wynikiem.
W robotyce w ten sposób można trenować modele realizujące między innymi:
- klasyfikację obiektów – określenie, do jakiej kategorii należy obserwowany przedmiot,
- detekcję obiektów – rozpoznanie obiektu oraz wskazanie jego położenia w obrazie,
- segmentację semantyczną – przypisanie poszczególnych fragmentów obrazu do określonych klas,
- estymację pozy obiektu – przewidywanie jego położenia i orientacji potrzebnych podczas manipulacji,
- przewidywanie określonych parametrów na podstawie danych z sensorów.
Największą zaletą takiego podejścia jest jasne określenie celu treningu. Problemem może być natomiast przygotowanie odpowiednio dużego i dobrze oznaczonego zbioru danych. W przypadku robotyki oznaczanie danych może być szczególnie kosztowne, ponieważ potrzebne są nie tylko obrazy, ale również informacje przestrzenne, stany robota, trajektorie czy dane z wielu zsynchronizowanych sensorów.
Uczenie nienadzorowane – szukanie struktury w danych
W uczeniu nienadzorowanym (unsupervised learning) model otrzymuje dane bez przypisanych prawidłowych odpowiedzi. Jego zadaniem jest znalezienie występujących w nich struktur, podobieństw lub regularności.
Może to oznaczać na przykład grupowanie podobnych obserwacji, wykrywanie nietypowych przypadków albo tworzenie bardziej zwartej reprezentacji dużego zbioru danych. Dokumentacja scikit-learn wyodrębnia uczenie nienadzorowane jako osobną grupę metod obejmującą między innymi klasteryzację, dekompozycję i wykrywanie struktur w danych.
W zastosowaniach robotycznych takie podejście może być wykorzystywane na przykład do:
- grupowania podobnych obserwacji zbieranych przez sensory,
- wykrywania anomalii i nietypowych stanów maszyny lub otoczenia,
- redukcji wymiarowości danych przed ich dalszym przetwarzaniem,
- odkrywania powtarzających się struktur w dużych zbiorach danych sensorycznych.
Trzeba jednak zwrócić uwagę na istotne ograniczenie. Jeżeli algorytm sam podzieli obserwowane obiekty na kilka grup, nie musi wiedzieć, co te grupy oznaczają. Może wykryć, że pewne obrazy lub chmury punktów są do siebie podobne, ale nie otrzymuje automatycznie informacji, że jedna grupa reprezentuje ludzi, druga krzesła, a trzecia narzędzia.
Coraz ważniejsze uczenie samonadzorowane
Pomiędzy prostym podziałem na uczenie nadzorowane i nienadzorowane znajduje się obecnie bardzo ważna grupa metod określanych jako uczenie samonadzorowane (self-supervised learning).
W tym przypadku nie trzeba ręcznie przygotowywać etykiety dla każdego przykładu. System tworzy zadanie treningowe na podstawie samych danych. Może na przykład próbować przewidzieć brakujący fragment informacji, porównać różne obserwacje tej samej sceny albo nauczyć się reprezentacji opisującej podobieństwo pomiędzy kolejnymi pomiarami.
Dla robotyki jest to szczególnie interesujące, ponieważ robot może generować ogromne ilości danych podczas normalnej pracy: obrazy z kamer, chmury punktów, dane z IMU, stany stawów czy trajektorie ruchu. Ręczne oznaczenie całego takiego zbioru byłoby praktycznie niemożliwe.
Dlatego we współczesnym robot learning coraz częściej wykorzystywane są metody pozwalające korzystać z danych w sposób bardziej automatyczny. Środowiska badawcze, takie jak NVIDIA Isaac Lab, są rozwijane właśnie z myślą o różnych sposobach uczenia robotów – od reinforcement learning przez uczenie z demonstracji po generowanie dużych zbiorów danych w symulacji.
Najważniejsza różnica
Możemy więc uprościć ten podział następująco:
- uczenie nadzorowane – model otrzymuje dane oraz prawidłową odpowiedź, której ma się nauczyć,
- uczenie nienadzorowane – model analizuje dane bez gotowych etykiet i poszukuje występującej w nich struktury,
- uczenie samonadzorowane – informacja potrzebna do treningu jest tworzona na podstawie samych danych, bez konieczności ręcznego oznaczania każdego przykładu.
W każdym z tych przypadków robot może nauczyć się reprezentacji danych, ale nie oznacza to jeszcze, że nauczył się wykonywać całe zadanie ruchowe.
Jeżeli chcemy, aby robot nauczył się na przykład chwytać przedmiot, otwierać szufladę albo wykonywać sekwencję manipulacji, możemy pokazać mu prawidłowy sposób wykonania zadania i wykorzystać zarejestrowane działania jako materiał treningowy.
To prowadzi do kolejnego ważnego podejścia: uczenia na podstawie demonstracji.
Uczenie na danych demonstracyjnych
Nie wszystkie zachowania robota muszą być projektowane poprzez ręczne określanie kolejnych reguł ani wypracowywane metodą prób i błędów. Innym podejściem jest uczenie z demonstracji (Learning from Demonstration – LfD), nazywane również uczeniem przez naśladowanie (imitation learning).
W takim przypadku robot otrzymuje przykłady prawidłowego wykonania zadania. Demonstrację może przeprowadzić człowiek sterujący robotem za pomocą teleoperacji albo inny system zdolny do wygenerowania poprawnej trajektorii. Podczas wykonywania zadania rejestrowane są obserwacje robota oraz odpowiadające im działania.
Przykładowa demonstracja manipulacji może zawierać:
- obrazy z kamer pokazujące aktualne otoczenie i położenie przedmiotu,
- stan robota – na przykład pozycje i prędkości poszczególnych stawów,
- polecenia sterujące wykonywane przez operatora podczas demonstracji,
- trajektorię ruchu przedstawiającą kolejne etapy realizacji zadania,
- informacje o zakończeniu zadania pozwalające określić, które demonstracje zostały wykonane prawidłowo.
Na podstawie wielu takich przykładów model może nauczyć się zależności pomiędzy tym, co robot obserwuje, a tym, jakie działanie powinien w danej chwili wykonać.
To podejście jest już wykorzystywane w praktycznych frameworkach robotycznych. Dokumentacja LeRobot pokazuje kompletny proces: teleoperowane wykonanie zadania jest rejestrowane jako zbiór danych, następnie na tych danych trenowana jest polityka sterowania, a wyuczony model może zostać uruchomiony na rzeczywistym robocie. Jako przykład przedstawiane jest chwytanie elementu i odkładanie go do pojemnika.
Polityka (policy) oznacza w tym kontekście funkcję lub model, który na podstawie aktualnych obserwacji określa działanie robota. Może więc otrzymać obraz z kamery i informacje o stanie manipulatora, a następnie wygenerować polecenia dotyczące kolejnego ruchu.
Robot nie kopiuje nagrania ruchu
Uczenie z demonstracji nie musi oznaczać prostego zapamiętania jednej trajektorii.
Jeżeli model został wytrenowany na odpowiednio zróżnicowanych danych, może nauczyć się reagować na sytuacje podobne do tych, które występowały podczas demonstracji. Jeżeli przedmiot zostanie umieszczony nieco dalej albo pod innym kątem, polityka może wygenerować zmodyfikowane działanie zamiast odtwarzać dokładnie tę samą sekwencję pozycji stawów.
Dlatego jakość zbioru demonstracji ma ogromne znaczenie. Dokumentacja LeRobot zaleca zbieranie wielu epizodów zadania oraz stopniowe zwiększanie różnorodności danych – na przykład poprzez zmianę położenia chwytanego przedmiotu.
Możemy więc uprościć cały proces do następującego schematu:
- 1. Człowiek wykonuje zadanie – robot jest sterowany za pomocą teleoperacji.
- 2. System rejestruje demonstrację – zapisywane są obserwacje, stany robota i wykonane działania.
- 3. Powstaje zbiór danych zawierający wiele przykładów realizacji tego samego zadania.
- 4. Trenowana jest polityka ucząca się zależności pomiędzy obserwacją a działaniem.
- 5. Wytrenowany model steruje robotem podczas samodzielnego wykonywania podobnego zadania.
Behavior cloning – naśladowanie zachowania eksperta
Jedną z najprostszych metod imitation learning jest behavior cloning. Problem można potraktować podobnie do uczenia nadzorowanego: obserwacja stanowi dane wejściowe, natomiast działanie wykonane przez operatora jest oczekiwaną odpowiedzią.
Model uczy się więc odwzorowania: obserwacja → działanie
Jeżeli człowiek wielokrotnie pokazuje robotowi, jak zbliżyć chwytak do przedmiotu, zamknąć palce i przenieść obiekt, model może próbować nauczyć się generowania podobnych działań w nowych obserwacjach.
Takie podejście ma jednak ograniczenie. Robot może znaleźć się w sytuacji, która nie występowała w danych demonstracyjnych. Nawet niewielki błąd wykonania może przesunąć go do stanu, którego model wcześniej nie widział, a kolejne błędy mogą się kumulować. Dlatego odpowiednia różnorodność danych oraz sposób ich zbierania mają bardzo duże znaczenie.
Demonstracje robotów humanoidalnych
Uczenie z demonstracji jest szczególnie interesujące w przypadku robotów humanoidalnych i manipulacyjnych, ponieważ ręczne programowanie każdej możliwej interakcji z przedmiotami staje się bardzo złożone.
Dobrym przykładem jest Unitree G1. Aktualna dokumentacja NVIDIA Isaac Lab przedstawia kompletny eksperymentalny workflow uczenia z demonstracji dla G1, obejmujący jednocześnie lokomocję i manipulację. Demonstracje mogą zostać zarejestrowane za pomocą teleoperacji, następnie oznaczone i wykorzystane do wygenerowania większego zbioru danych służącego do treningu polityki. W przykładzie robot wykonuje zadania typu pick and place, łącząc przemieszczanie całego ciała z manipulacją obiektem.
To dobrze pokazuje, jak zmienia się sposób programowania bardziej zaawansowanych robotów. Zamiast opisywać ręcznie każdy ruch stawu, można dostarczyć przykłady prawidłowego wykonania zadania i wykorzystać je do wytrenowania modelu.
Nie oznacza to jednak, że klasyczna robotyka przestaje być potrzebna. Podczas zbierania demonstracji i wykonywania ruchów nadal wykorzystywane mogą być kinematyka odwrotna, sterowanie, ograniczenia ruchu oraz informacje o stanie robota. Uczenie z demonstracji staje się kolejną warstwą systemu, a nie zamiennikiem całej architektury robotycznej.
Nie oznacza to jednak, że klasyczna robotyka przestaje być potrzebna. Podczas zbierania demonstracji i wykonywania ruchów nadal wykorzystywane mogą być kinematyka odwrotna, sterowanie, ograniczenia ruchu oraz informacje o stanie robota. Uczenie z demonstracji staje się kolejną warstwą systemu, a nie zamiennikiem całej architektury robotycznej.
Dane treningowe w robotyce
W uczeniu maszynowym model jest w dużej mierze tak dobry, jak dane, na których został wytrenowany. W robotyce problem jest szczególnie wymagający, ponieważ dane nie pochodzą zwykle z jednego źródła. Robot może jednocześnie rejestrować obraz z kilku kamer, informacje o głębi, dane z IMU, położenie stawów, prędkości napędów, siły działające na chwytak oraz polecenia sterujące.
Zbiór treningowy robota jest więc często wielomodalnym zapisem jego interakcji z otoczeniem, a nie tylko kolekcją zdjęć.
Współczesny format LeRobotDataset został zaprojektowany właśnie z myślą o takich danych. Pozwala przechowywać wielomodalne szeregi czasowe, sygnały sensoryczno-ruchowe, nagrania z wielu kamer oraz informacje opisujące poszczególne epizody wykonywanych zadań.
Co może znaleźć się w zbiorze danych robota?
Pojedynczy fragment treningowy może zawierać jednocześnie informacje o tym, co robot obserwował, w jakim był stanie oraz jakie działanie wykonał.
- obrazy z kamer RGB i kamer głębi – pokazujące wygląd oraz geometrię obserwowanej sceny,
- dane z LiDAR-u – opisujące odległości i przestrzenną strukturę otoczenia,
- dane z IMU – zawierające informacje o ruchu i orientacji robota,
- pozycje i prędkości stawów – odczytywane między innymi za pomocą enkoderów,
- siły, momenty i informacje dotykowe – szczególnie istotne podczas manipulacji przedmiotami,
- polecenia sterujące – opisujące działania wykonywane przez robota,
- informację o zadaniu – określającą cel danego epizodu lub polecenie, które robot miał wykonać.
W przypadku uczenia polityki sterowania bardzo ważna jest zależność pomiędzy obserwacją a działaniem. Model musi wiedzieć, co robot widział w danym momencie i jakie polecenie zostało wtedy wykonane.
Dlatego dane pochodzące z różnych sensorów muszą być odpowiednio zsynchronizowane w czasie. Jeżeli obraz z kamery zostanie błędnie połączony ze stanem stawów zarejestrowanym kilkaset milisekund wcześniej, model otrzyma nieprawidłową informację o zależności pomiędzy obserwacją i ruchem.
Liczba danych nie wystarczy
Duży zbiór danych nie musi automatycznie oznaczać dobrego zbioru treningowego.
Jeżeli robot był podczas wszystkich demonstracji ustawiony w tym samym miejscu, obiekt zawsze znajdował się w identycznej pozycji, a oświetlenie pozostawało niezmienne, model może nauczyć się bardzo wąskiego rozwiązania działającego tylko w warunkach zbliżonych do treningowych.
Znacznie ważniejsza staje się różnorodność danych.
- różne położenia i orientacje obiektów pomagają modelowi radzić sobie ze zmianą układu sceny,
- różne warunki oświetleniowe i tła ograniczają uzależnienie modelu od wyglądu jednej konkretnej lokalizacji,
- różne trajektorie wykonania zadania pokazują, że ten sam cel może zostać osiągnięty na więcej niż jeden sposób,
- sytuacje częściowo nieudane mogą dostarczać informacji o stanach, które pojawiają się po błędzie,
- różne konfiguracje otoczenia zwiększają szansę, że model poradzi sobie z sytuacją niewystępującą dokładnie w zbiorze treningowym.
To właśnie tutaj pojawia się jeden z najważniejszych problemów robot learning – generalizacja. Model powinien działać poprawnie nie tylko na danych, które już widział, lecz również w nowych, choć wystarczająco podobnych sytuacjach.
Dane trzeba również kontrolować
W przypadku demonstracji wykonanych przez człowieka nie każda próba musi być poprawna. Operator może wykonać niepotrzebny ruch, źle chwycić przedmiot albo przerwać zadanie.
Dlatego przed rozpoczęciem treningu dane mogą wymagać kontroli, odrzucenia błędnych epizodów oraz sprawdzenia, czy rejestrowane sygnały są kompletne i poprawnie zsynchronizowane.
Format LeRobotDataset jest zorganizowany właśnie wokół epizodów – czyli pojedynczych przebiegów zadania. Pozwala to między innymi zachować granice poszczególnych prób oraz usuwać nieudane lub przerwane nagrania podczas przygotowywania datasetu.
Istotny jest również podział danych na zbiory wykorzystywane do treningu i późniejszej oceny modelu. Jeżeli skuteczność będzie sprawdzana wyłącznie na tych samych przykładach, które model widział podczas treningu, trudno stwierdzić, czy rzeczywiście nauczył się ogólnej zależności, czy jedynie bardzo dobrze dopasował się do znanych danych.
Skąd wziąć wystarczająco dużo danych?
Zbieranie rzeczywistych danych robotycznych jest kosztowne. Każdy epizod wymaga fizycznego wykonania zadania, a tysiące powtórzeń oznaczają czas pracy robota, operatora oraz rzeczywistych mechanizmów.
Dlatego coraz większe znaczenie ma generowanie danych syntetycznych w symulacji.
NVIDIA Isaac Lab Mimic umożliwia na przykład wykorzystanie niewielkiej liczby demonstracji człowieka do automatycznego wygenerowania kolejnych demonstracji tego samego zadania w zmienionych konfiguracjach przestrzennych. Celem jest zwiększenie różnorodności datasetu i poprawienie odporności wyuczonej polityki na zmiany położenia obiektów.
Symulacja pozwala również zmieniać warunki treningowe na skalę, której uzyskanie w świecie rzeczywistym byłoby znacznie trudniejsze. W środowiskach robot learning można modyfikować między innymi masę obiektów, tarcie, parametry napędów, początkowe pozycje, charakterystykę sensorów czy warunki obserwacji. Isaac Lab udostępnia domain randomization właśnie jako mechanizm zwiększający odporność polityk na takie zmiany.
Powstaje jednak kolejny problem: symulator nigdy nie odwzorowuje rzeczywistości idealnie. Model świetnie działający w środowisku wirtualnym może zachowywać się gorzej po przeniesieniu na fizycznego robota.
To zagadnienie określane jest jako Sim-to-Real i wrócimy do niego w osobnej części artykułu.
Dane stają się częścią technologii robota
W klasycznym oprogramowaniu robotycznym znaczną część zachowania definiował programista. W systemach wykorzystujących uczenie maszynowe coraz większa część funkcjonalności zależy również od tego, jakie doświadczenia zostały zapisane w danych treningowych.
Dlatego tworzenie nowoczesnego systemu AI dla robota obejmuje nie tylko wybór modelu, lecz także:
- zaprojektowanie sposobu zbierania danych,
- dobór odpowiednich sensorów i obserwacji,
- synchronizację danych,
- zapewnienie różnorodności przykładów,
- kontrolę jakości datasetu,
- ocenę działania modelu na sytuacjach niewystępujących podczas treningu.
Demonstracje są jednym sposobem pozyskania doświadczeń. Robot może jednak uczyć się również inaczej – samodzielnie wykonywać działania, obserwować ich konsekwencje i otrzymywać informację o tym, czy przybliżyły go do osiągnięcia celu.
To prowadzi nas do jednej z najważniejszych metod współczesnego robot learning: reinforcement learning.
Reinforcement learning – jak robot uczy się metodą prób i błędów?
W uczeniu z demonstracji robot otrzymywał przykłady pokazujące, jak należy wykonać zadanie. Reinforcement learning wykorzystuje inne podejście. Zamiast pokazywać modelowi prawidłowe działanie w każdej sytuacji, definiowane są środowisko, dostępne działania oraz sposób oceniania rezultatów.
Reinforcement learning (RL), czyli uczenie ze wzmocnieniem, polega na tym, że agent wielokrotnie oddziałuje ze środowiskiem, obserwuje konsekwencje swoich działań i otrzymuje informację w postaci nagrody. Celem treningu jest znalezienie takiej strategii działania, która prowadzi do maksymalizacji oczekiwanej nagrody w dłuższej perspektywie. Taki właśnie cykl: obserwacja → działanie → nowa obserwacja → nagroda jest podstawą standardowego modelu środowiska RL.
W robotyce metoda ta jest szczególnie interesująca, ponieważ wiele zachowań trudno opisać za pomocą ręcznie przygotowanych reguł. Utrzymywanie równowagi, dynamiczne chodzenie, manipulowanie przedmiotami czy koordynowanie wielu stawów wymaga uwzględnienia ogromnej liczby możliwych stanów i działań.
Nie oznacza to jednak, że robot powinien wykonywać tysiące przypadkowych prób bezpośrednio w rzeczywistym świecie. Współczesne środowiska, takie jak NVIDIA Isaac Lab, pozwalają trenować polityki RL w symulacji, często w wielu równoległych środowiskach jednocześnie. Dopiero później wytrenowana polityka może zostać oceniona i potencjalnie przeniesiona do fizycznego robota.
Agent, środowisko, akcja i nagroda
Aby zrozumieć reinforcement learning, warto najpierw uporządkować kilka podstawowych pojęć. W klasycznym ujęciu agent obserwuje środowisko, wybiera działanie, a następnie otrzymuje nową obserwację oraz nagrodę opisującą konsekwencję wykonanej akcji.
- agent – system, który uczy się podejmować działania; w robotyce może nim być polityka sterująca robotem,
- środowisko – świat, z którym agent wchodzi w interakcję; może to być symulator albo rzeczywisty robot i jego otoczenie,
- obserwacja – informacje dostępne agentowi, na przykład pozycje i prędkości stawów, orientacja korpusu, dane z sensorów lub obraz z kamery,
- akcja – działanie wybrane przez agenta, na przykład zadana pozycja stawu, prędkość, moment obrotowy albo polecenie dla kontrolera,
- nagroda – wartość informująca, na ile wykonane działanie było korzystne z punktu widzenia zadania,
- polityka – strategia określająca, jakie działanie powinno zostać wybrane na podstawie aktualnej obserwacji.
Schemat interakcji wygląda więc następująco: obserwacja → polityka → akcja → środowisko → nowa obserwacja + nagroda → polityka → kolejna akcja
Proces powtarza się wielokrotnie, a podczas treningu parametry polityki są modyfikowane tak, aby coraz częściej wybierane były działania prowadzące do korzystnego rezultatu.
Nagroda mówi robotowi, czego oczekujemy
Jednym z najważniejszych elementów reinforcement learning jest funkcja nagrody (reward function). Nie opisuje ona dokładnie każdego ruchu, który robot powinien wykonać. Zamiast tego określa, jakie rezultaty są pożądane, a jakie nie.
Załóżmy, że chcemy nauczyć robota kroczącego poruszania się do przodu. Nagroda może uwzględniać kilka różnych kryteriów:
- ruch z oczekiwaną prędkością może zwiększać nagrodę,
- utrzymywanie prawidłowej orientacji korpusu może być premiowane,
- upadek robota może powodować dużą karę i zakończenie epizodu,
- nadmierne momenty w stawach mogą być karane w celu ograniczenia nieefektywnych ruchów,
- gwałtowne lub niestabilne ruchy mogą obniżać całkowitą wartość nagrody.
To nie jest wyłącznie przykład teoretyczny. Isaac Lab udostępnia gotowe komponenty funkcji nagrody dla robotów, obejmujące między innymi karanie niepożądanej orientacji korpusu, nadmiernych momentów stawowych, przyspieszeń czy określonych rodzajów ruchu.
W praktyce nagroda jest często sumą wielu składników. Jeden z nich zachęca robota do osiągnięcia głównego celu, natomiast pozostałe ograniczają zachowania, które technicznie mogłyby prowadzić do wysokiej nagrody, lecz byłyby niepożądane z punktu widzenia rzeczywistej maszyny.
Robot nie otrzymuje instrukcji każdego ruchu
To zasadnicza różnica w stosunku do uczenia z demonstracji.
W demonstracji człowiek może pokazać: „w tym stanie wykonaj taki ruch”.
W reinforcement learning agent otrzymuje raczej informację: „ten rezultat był lepszy, a tamten gorszy”.
Algorytm musi znaleźć strategię prowadzącą do dobrego wyniku poprzez wielokrotne interakcje ze środowiskiem.
Dlatego RL może doprowadzić do rozwiązania, którego programista nie opisał ręcznie. Jednocześnie oznacza to, że sposób zdefiniowania nagrody ma ogromne znaczenie. Źle zaprojektowana funkcja nagrody może doprowadzić do zachowania zgodnego matematycznie z celem treningowym, ale niezgodnego z rzeczywistą intencją projektanta.
W Isaac Lab środowisko RL jest właśnie rozszerzone o elementy charakterystyczne dla tego rodzaju treningu: obserwacje, akcje, nagrody, warunki zakończenia epizodu, curriculum oraz generowanie poleceń.
Epizod – jedna próba wykonania zadania
Trening jest zazwyczaj podzielony na epizody. Epizod może rozpocząć się od ustawienia robota w określonym stanie początkowym i zakończyć po osiągnięciu celu, upadku, wystąpieniu błędu albo przekroczeniu maksymalnego czasu.
Następnie środowisko zostaje zresetowane i rozpoczyna się kolejna próba.
W symulacji proces ten może być wykonywany bardzo szybko i równolegle dla wielu kopii robota. Isaac Lab został zaprojektowany właśnie do masowo równoległego treningu środowisk RL, dzięki czemu w tym samym czasie mogą być generowane doświadczenia z bardzo dużej liczby interakcji.
To jedna z przyczyn, dla których reinforcement learning stał się tak ważny w badaniach nad lokomocją robotów kroczących i humanoidalnych. W rzeczywistym świecie wykonanie milionów prób byłoby czasochłonne, kosztowne i mogłoby prowadzić do uszkodzenia mechaniki. W symulacji wiele nieudanych prób może zostać przeprowadzonych bez fizycznych konsekwencji.
Samo zgromadzenie doświadczeń nie wystarcza jednak. Algorytm musi jeszcze wykorzystać je do modyfikowania polityki, tak aby z czasem wzrastało prawdopodobieństwo wyboru skutecznych działań.
To prowadzi nas do kolejnego pytania: jak na podstawie nagród robot rzeczywiście uczy się zachowania?
Jak robot uczy się zachowania?
W reinforcement learning sama nagroda nie mówi robotowi dokładnie, jaki ruch powinien wykonać. Informuje jedynie, czy konsekwencja danego działania była korzystna. Zadaniem algorytmu jest więc stopniowe znalezienie takiej polityki, która coraz częściej prowadzi do wysokiej nagrody.
Politykę można traktować jako funkcję: obserwacja → działanie
Jeżeli robot otrzymuje informacje o orientacji korpusu, pozycjach stawów, prędkościach oraz zadanej prędkości ruchu, polityka może na tej podstawie generować kolejne polecenia dla napędów.
Podczas treningu proces jest wielokrotnie powtarzany. Robot wykonuje działanie, środowisko przechodzi do nowego stanu, obliczana jest nagroda, a zebrane doświadczenia są wykorzystywane do aktualizacji parametrów polityki. Oficjalna architektura Isaac Lab opisuje właśnie taki przepływ: obserwacje trafiają do polityki, model generuje akcje, symulator wykonuje kolejny krok fizyki, a następnie obliczane są nowe obserwacje i nagrody.
Od przypadkowych prób do skutecznej polityki
Na początku treningu działania robota mogą być mało skuteczne. W miarę gromadzenia doświadczeń algorytm ocenia jednak, które sposoby działania częściej prowadzą do dobrych rezultatów.
Można to uprościć do następującego procesu:
- robot obserwuje aktualny stan – na przykład orientację, położenie stawów i zadany kierunek ruchu,
- polityka wybiera działanie – generowane są polecenia dla wybranych stopni swobody,
- środowisko wykonuje kolejny krok – zmienia się położenie i stan robota,
- obliczana jest nagroda – system ocenia rezultat działania,
- algorytm aktualizuje politykę – zwiększana jest szansa wyboru działań prowadzących do lepszych wyników,
- proces jest powtarzany przez bardzo dużą liczbę interakcji.
Nie jest to więc nauka przez zapamiętanie jednej poprawnej trajektorii. Celem jest znalezienie strategii, która będzie działała dla wielu różnych stanów środowiska.
Eksploracja i wykorzystanie zdobytej wiedzy
Podczas treningu pojawia się ważny problem: agent nie może zawsze wykonywać tylko tych działań, które już uważa za najlepsze. Wtedy mógłby nigdy nie odkryć skuteczniejszego rozwiązania.
Dlatego w reinforcement learning występuje kompromis pomiędzy:
- eksploracją – sprawdzaniem nowych działań i zachowań, które mogą prowadzić do lepszego wyniku,
- eksploatacją – korzystaniem z zachowań, które według dotychczasowych doświadczeń są już skuteczne.
W praktycznych algorytmach mechanizm ten może być realizowany na różne sposoby. Jednym z bardzo często wykorzystywanych obecnie algorytmów w robotyce jest PPO – Proximal Policy Optimization. Isaac Lab udostępnia środowiska treningowe współpracujące między innymi z bibliotekami implementującymi PPO i wykorzystuje ten algorytm w gotowych zadaniach lokomocji robotów kroczących i humanoidalnych.
Przykład – nauka chodzenia robota humanoidalnego
Dobrym przykładem jest Unitree G1. Isaac Lab zawiera gotowe środowiska treningowe dla tego robota, zarówno dla poruszania się po płaskiej powierzchni, jak i po nierównym terenie. Zadaniem polityki może być śledzenie zadanej prędkości ruchu przy jednoczesnym utrzymywaniu stabilnej lokomocji.
Podczas treningu polityka otrzymuje obserwacje opisujące stan robota, a następnie generuje działania sterujące. Kolejne próby mogą obejmować różne prędkości, konfiguracje i zaburzenia.
W wyniku treningu nie powstaje zapisana lista: lewa noga → prawa noga → lewa noga → prawa noga.
Powstaje polityka, która na podstawie aktualnego stanu może generować odpowiednie działania dla wielu różnych sytuacji.
To szczególnie istotne w przypadku humanoida, ponieważ zachowanie równowagi wymaga ciągłego reagowania na niewielkie odchylenia i zmiany dynamiki całego ciała.
Polityka może sterować robotem na różnych poziomach
Model wytrenowany metodą RL nie zawsze musi wysyłać bezpośrednio momenty obrotowe do silników. W zależności od architektury systemu jego akcją może być na przykład:
- zadana pozycja stawu,
- zadana prędkość stawu,
- moment obrotowy,
- punkt docelowy dla kontrolera niższego poziomu.
Isaac Lab podkreśla, że wyjście polityki może zostać użyte bezpośrednio jako akcja robota albo jako wartość zadana dla klasycznego kontrolera.
To ponownie pokazuje ważną zasadę całego naszego artykułu: uczenie maszynowe i klasyczne sterowanie nie muszą ze sobą konkurować. Bardzo często działają razem.
Polityka RL może odpowiadać za wyuczony sposób poruszania się, natomiast niższa warstwa sterowania nadal realizuje zadane pozycje lub momenty z dużą częstotliwością.
Trening kończy się powstaniem modelu
Po zakończeniu procesu uczenia parametry polityki zostają zapisane. Podczas późniejszej pracy robot nie musi ponownie wykonywać całego treningu. Wykorzystuje gotowy model i na podstawie bieżących obserwacji wykonuje inferencję, generując kolejne działania.
Dopiero wtedy wytrenowana polityka może zostać wykorzystana w rzeczywistym systemie robotycznym.
I właśnie w tym miejscu pojawia się największe praktyczne wyzwanie reinforcement learning: zachowanie skuteczne w symulacji nie zawsze działa identycznie na fizycznym robocie.
To prowadzi nas bezpośrednio do ograniczeń RL oraz problemu przenoszenia wyuczonych zachowań do świata rzeczywistego.
Ograniczenia reinforcement learning w świecie rzeczywistym
Reinforcement learning pozwala wytrenować zachowania, które trudno byłoby zaprogramować ręcznie, jednak przeniesienie takiego podejścia z eksperymentu do rzeczywistego robota wiąże się z istotnymi ograniczeniami. Największym problemem jest to, że podczas treningu agent potrzebuje bardzo dużej liczby interakcji ze środowiskiem, a wiele z nich – szczególnie na początku – prowadzi do nieudanych działań.
W symulacji robot może przewrócić się tysiące razy, uderzyć w przeszkodę albo wykonać nieprawidłowy ruch bez większych konsekwencji. W rzeczywistym świecie każda taka próba oznacza zużycie mechaniki, ryzyko uszkodzenia robota oraz potencjalne zagrożenie dla otoczenia.
Dlatego bezpośrednie uczenie z losowej eksploracji na fizycznym robocie jest w wielu zastosowaniach niepraktyczne albo niedopuszczalne.
- duża liczba wymaganych interakcji – skuteczna polityka może wymagać ogromnej liczby kroków treningowych,
- bezpieczeństwo eksploracji – podczas uczenia agent może wybierać działania nieprzewidywalne lub niebezpieczne dla rzeczywistej maszyny,
- zużycie mechaniczne – wielokrotne upadki, uderzenia i gwałtowne ruchy powodują rzeczywiste obciążenie napędów oraz konstrukcji,
- dobór funkcji nagrody – niewłaściwie określony cel może doprowadzić do zachowania zgodnego z matematyczną nagrodą, ale niezgodnego z intencją projektanta,
- różnica pomiędzy symulacją a rzeczywistością – polityka skuteczna w świecie wirtualnym może zachowywać się inaczej po uruchomieniu na prawdziwym robocie.
Symulator nie zna rzeczywistości idealnie
Model fizyczny może bardzo dokładnie odwzorowywać robota, ale zawsze pozostaje przybliżeniem rzeczywistego świata. Tarcie, luzy mechaniczne, charakterystyka napędów, masa poszczególnych elementów, opóźnienia komunikacji czy szumy sensorów mogą różnić się od parametrów przyjętych podczas treningu.
Problem dotyczy również samych obserwacji.
W symulatorze możemy mieć dostęp do idealnej informacji o prędkości, pozycji lub orientacji każdego elementu. Fizyczny robot zna natomiast swój stan wyłącznie na podstawie rzeczywistych sensorów i algorytmów estymacji.
Dokumentacja Isaac Lab dotycząca transferu polityki na Unitree G1 zwraca uwagę właśnie na ten problem. Polityka przeznaczona do rzeczywistego robota powinna korzystać z informacji, które faktycznie mogą być uzyskane z jego sensorów. Zmienna dostępna bezpośrednio w symulatorze nie zawsze jest możliwa do równie dokładnego pomiaru na fizycznej platformie.
Polityka może nauczyć się „złego skrótu”
Jeszcze inne zagrożenie wynika z konstrukcji funkcji nagrody.
Jeżeli system zostanie premiowany wyłącznie za osiągnięcie określonego rezultatu, może znaleźć sposób, którego projektant nie przewidział. Zachowanie może spełniać matematyczne kryterium zadania, a jednocześnie być niestabilne, energochłonne albo niebezpieczne dla mechaniki robota.
Dlatego projektowanie środowiska RL obejmuje zwykle nie tylko nagrodę za osiągnięcie celu, lecz także dodatkowe ograniczenia i kary dotyczące między innymi stabilności, energii, momentów działających w stawach czy niepożądanych kontaktów.
Reinforcement learning nie eliminuje więc potrzeby wiedzy inżynierskiej. Wręcz przeciwnie – dobrze zaprojektowane środowisko treningowe wymaga znajomości mechaniki, sterowania, sensorów oraz rzeczywistego zachowania robota.
Jak ogranicza się różnicę pomiędzy treningiem a rzeczywistym robotem?
Jedną z podstawowych technik jest celowe zwiększanie różnorodności warunków występujących podczas treningu. Zamiast uczyć politykę zawsze na jednym idealnym modelu, można losowo zmieniać wybrane parametry.
W Isaac Lab mechanizmy domain randomization pozwalają modyfikować między innymi tarcie, parametry napędów czy właściwości fizyczne obiektów. Dzięki temu polityka nie przyzwyczaja się do jednej dokładnej konfiguracji symulatora i ma większą szansę działać poprawnie również wtedy, gdy rzeczywisty robot nieznacznie różni się od modelu.
Nie jest to jednak gwarancja sukcesu. Wytrenowaną politykę trzeba nadal testować i stopniowo weryfikować przed wykorzystaniem jej na rzeczywistym sprzęcie. Współczesne workflow Isaac Lab przewidują osobny etap wdrażania polityk z symulacji na fizyczne roboty, w tym również integrację z ROS i rzeczywistymi kontrolerami.
Reinforcement learning jest narzędziem, a nie uniwersalnym rozwiązaniem
RL sprawdza się szczególnie dobrze w problemach, w których trudno ręcznie zaprojektować pełną strategię działania, a jednocześnie możliwe jest stworzenie środowiska pozwalającego na wielokrotne wykonywanie prób.
Nie oznacza to jednak, że każda funkcja robota powinna być wyuczona.
W rzeczywistym systemie polityka RL może odpowiadać za określony fragment zachowania – na przykład lokomocję – podczas gdy lokalizacja, bezpieczeństwo, planowanie zadania czy kontrola wyższego poziomu są realizowane innymi metodami.
Ponownie wracamy więc do jednej z głównych zasad tego artykułu: współczesny robot nie jest jednym modelem AI, lecz systemem łączącym uczenie maszynowe z klasyczną robotyką, sterowaniem i oprogramowaniem czasu rzeczywistego.
Największym wyzwaniem pozostaje jednak przeniesienie zachowania wyuczonego w środowisku wirtualnym do prawdziwego świata. Ten proces określany jest jako Sim-to-Real.
Symulacja i Sim-to-Real – jak przenieść wyuczone zachowanie do prawdziwego robota?
Reinforcement learning pokazuje, że robot może nauczyć się złożonego zachowania poprzez bardzo dużą liczbę interakcji ze środowiskiem. W praktyce przeprowadzenie wszystkich tych prób na fizycznej maszynie byłoby jednak kosztowne, powolne i często niebezpieczne. Dlatego znaczna część procesu uczenia robotów odbywa się dziś w środowiskach symulacyjnych.
Symulator pozwala stworzyć wirtualnego robota wraz z jego mechaniką, sensorami i otoczeniem. Następnie można wielokrotnie wykonywać zadanie, zmieniać warunki eksperymentu i rejestrować wyniki bez narażania rzeczywistego sprzętu.
Frameworki takie jak NVIDIA Isaac Lab zostały zaprojektowane właśnie z myślą o robot learning. Umożliwiają między innymi trening reinforcement learning, uczenie z demonstracji, symulację fizyki oraz późniejsze wdrażanie wytrenowanych polityk na rzeczywistych robotach.
Dlaczego roboty uczą się w symulatorach?
Najważniejszą zaletą symulacji jest możliwość wykonania ogromnej liczby prób bez fizycznych konsekwencji.
Robot humanoidalny uczący się chodzenia może podczas treningu wielokrotnie stracić równowagę. Manipulator może nie trafić w obiekt, a robot mobilny wybrać nieprawidłową trasę. W symulatorze takie niepowodzenia oznaczają przede wszystkim kolejne dane treningowe. W świecie rzeczywistym mogą prowadzić do uszkodzenia napędów, mechaniki lub otoczenia.
Symulacja daje również możliwość równoległego uruchamiania wielu kopii tego samego robota. Zamiast wykonywać kolejne próby pojedynczo, setki lub tysiące środowisk mogą generować doświadczenia jednocześnie. Jest to jedna z istotnych przewag symulacji podczas treningu polityk robotycznych.
- bezpieczeństwo – nieudane próby nie powodują fizycznego uszkodzenia robota,
- duża liczba eksperymentów – trening może obejmować ogromną liczbę interakcji ze środowiskiem,
- równoległe środowiska – wiele kopii robota może uczyć się jednocześnie,
- kontrola warunków – można dokładnie zmieniać parametry robota, otoczenia i zadania,
- powtarzalność – ten sam eksperyment można wielokrotnie uruchamiać w kontrolowanych warunkach,
- automatyczne generowanie danych – symulator może dostarczać informacje, których pozyskanie z rzeczywistego świata byłoby trudne lub kosztowne.
Symulacja pozwala przygotować robota na różne warunki
Środowisko treningowe nie musi za każdym razem wyglądać identycznie. Można celowo zmieniać parametry, z którymi robot będzie miał do czynienia.
Przykładowo podczas treningu robota kroczącego mogą być zmieniane:
- tarcie podłoża,
- masa wybranych elementów robota,
- parametry napędów,
- ukształtowanie terenu,
- pozycja początkowa robota,
- zakłócenia i charakterystyka pomiarów sensorycznych.
Takie celowe różnicowanie warunków określa się jako domain randomization. Isaac Lab udostępnia mechanizmy tego typu właśnie w celu zwiększenia odporności wytrenowanych polityk i przygotowania ich do działania poza jednym idealnym scenariuszem symulacyjnym.
Nie chodzi więc o stworzenie jednego perfekcyjnego wirtualnego świata. Często korzystniejsze jest nauczenie robota działania w wielu nieco różnych światach, tak aby wyuczona polityka nie była nadmiernie dopasowana do jednego zestawu parametrów.
Symulacja jest również etapem testowania
Zanim polityka zostanie uruchomiona na rzeczywistym sprzęcie, może zostać sprawdzona w innym środowisku symulacyjnym. Takie podejście określane jest jako Sim-to-Sim.
Isaac Lab opisuje testowanie polityk pomiędzy różnymi silnikami fizycznymi jako przydatny etap poprzedzający wdrożenie na prawdziwym robocie. Jeżeli polityka działa wyłącznie w dokładnie tym środowisku, w którym została wytrenowana, może to wskazywać na zbyt silne uzależnienie od właściwości konkretnej symulacji.
Nie rozwiązuje to jednak najważniejszego problemu.
Nawet bardzo zaawansowany symulator pozostaje modelem rzeczywistości. Rzeczywisty robot ma inne opóźnienia, niedokładności sensorów, rzeczywiste luzy mechaniczne, różnice parametrów napędów oraz kontakty z otoczeniem, których nie da się idealnie odwzorować.
Właśnie różnicę pomiędzy zachowaniem systemu w symulacji a zachowaniem fizycznego robota określa się jako Sim-to-Real gap.
I to jest kluczowe zagadnienie następnej części.