Is 'Design for Simulation' Making Robots S.T.U.P.P.I.D.?

W świecie robotyki humanoidalnej, gdzie stawki idą w miliardy dolarów, właśnie wybucha ideologiczna wojna o fundamentalnym znaczeniu. Po jednej stronie barykady stoją tytani AI, tacy jak NVIDIA, forsujący koncepcję „Design for Simulation” (DFS) – zasadę, według której hardware należy budować tak, by był jak najłatwiejszy do okiełznania w wirtualnym treningu. Po drugiej stronie stanął weteran branży, który bez ogródek nazywa to podejście po prostu „S.T.U.P.P.I.D.”.

Rękawicę rzucił dr Scott Walter, inżynier z czterdziestoletnim stażem w dziedzinie symulacji i współzałożyciel dwóch firm z tej branży. W swojej miażdżącej krytyce Walter przekonuje, że pozwalanie, by ograniczenia oprogramowania dyktowały kształt fizycznych maszyn, to niebezpieczny i uwsteczniający trend. Na tę okazję ukuł nawet złośliwy akronim: S.T.U.P.P.I.D., czyli Simulation Throttled Underperforming Product Integration Design (Projektowanie Produktu Upośledzone i Ograniczone przez Symulację).

To bezpośrednie uderzenie w filozofię, której twarzą jest m.in. dr Jim Fan, Senior Research Scientist w firmie NVIDIA. Fan od dawna argumentuje, że aby nowoczesne uczenie przez wzmacnianie (Reinforcement Learning – RL) mogło skalować się w odpowiednim tempie, sprzęt i symulacja muszą być projektowane równolegle. „Jeśli twój robot nie daje się dobrze symulować, możesz pożegnać się z RL” – stwierdził Fan, stawiając symulację w roli absolutnego priorytetu w procesie projektowym.

Walter uważa jednak, że to klasyczne stawianie wozu przed koniem. Jako dowód wskazuje konkretne przypadki: firma Unitree Robotics miała rzekomo uprościć konstrukcję stawu skokowego w swoim nowym humanoidzie H2. Zamiast zaawansowanego mechanicznie układu równoległego znanego z modelu G1, postawiono na układ szeregowy, który jest znacznie bardziej „przyjazny dla RL”. Inne przykłady to rezygnacja z dłoni napędzanych skomplikowanymi systemami ścięgien czy celowe ograniczanie możliwości inteligentnych silników, by ich praca była bardziej liniowa i przewidywalna dla symulatora. Według Waltera inżynierowie tak bardzo boją się tzw. „luki sim-to-real” (rozbieżności między symulacją a rzeczywistością), że wolą naginać rzeczywistość do modelu, zamiast udoskonalać model, by odzwierciedlał on faktyczną złożoność świata.

Dlaczego to ma znaczenie?

To nie jest tylko akademicka sprzeczka o śrubki i kody – to debata o samą duszę inżynierii robotycznej. Jeśli podejście „najpierw symulacja” wygra, ryzykujemy stworzenie generacji robotów, które co prawda łatwo wytrenować, ale które w świecie fizycznym będą fundamentalnie mniej sprawne, mniej wydajne i mniej wytrzymałe. To przedkładanie wygody programistów nad realne osiągi maszyny.

Krytyka Waltera to wezwanie do broni dla inżynierów: zamiast „kastrować” sprzęt, by pasował do obecnych ograniczeń narzędzi, powinniśmy budować lepsze symulatory. Jak to ujął sam zainteresowany: „Nie projektujemy mostów tak, żeby oprogramowanie do analizy strukturalnej było zadowolone”. Ostatecznym celem jest zbudowanie lepszego robota, a nie takiego, który po prostu ładnie wygląda w Isaac Sim. Najlepsze projekty zawsze będą rodzić się z pytania o to, czego potrzebuje maszyna, by działać, a nie co jest w stanie przetrawić procesor graficzny.