IROS 2026: zapomnij o saltach. Te problemy zdecydują, czy roboty zaczną pracować
Grafika wyróżniająca: RoboMorrow. Autorska okładka redakcyjna, nie zdjęcie z wydarzenia.
Najważniejszy robot na konferencji nie musi robić salta. Może po prostu lepiej poradzić sobie z przedmiotem, którego wcześniej nie widział, albo pozwolić badaczom odtworzyć eksperyment bez tygodni ręcznego poprawiania konfiguracji. Właśnie takie zmiany śledzimy w raporcie RoboMorrow z IROS 2026.
Konferencja IEEE/RSJ IROS odbywa się w Pittsburghu od 27 września do 1 października. Poniższe wydanie ma stan na 28 września 2026. Bazuje na programie i opublikowanych pracach, nie na naszej obecności na miejscu. Nie nazywamy wcześniejszego preprintu „dzisiejszą premierą” tylko dlatego, że autorzy prezentują go na konferencji. [18]
Co jest potwierdzone, a co pozostaje na radarze
W programie Georgia Tech znajdują się między innymi AGILE, OG-VLA i KEYGEN. To użyteczny punkt wejścia do trzech problemów: przenoszenia umiejętności z symulacji na sprzęt, rozumienia przestrzeni przez modele sterujące robotem oraz uogólniania umiejętności na nowe obiekty. Sam wpis w programie nie potwierdza jednak przebiegu konkretnej prezentacji ani niezawodności gotowego produktu.
W tym raporcie rozdzielamy publikację naukową, demonstrację i wdrożenie. Artykuł może zawierać kontrolowany eksperyment. Film może pokazywać pojedynczy sukces. Wdrożenie wymaga jeszcze odpowiedzi na pytania o powtarzalność, obsługę wyjątków i utrzymanie systemu. Te poziomy mogą się uzupełniać, ale nie są zamienne.
| Obszar | Materiał źródłowy | Co warto sprawdzić |
|---|---|---|
| Rozwój umiejętności humanoida | AGILE — workflow uczenia i oceny | Czy wynik da się odtworzyć na nowej konfiguracji? |
| Przestrzeń i polecenia językowe | OG-VLA — reprezentacja ortograficzna | Jak zmiana widoku wpływa na manipulację? |
| Uogólnianie między obiektami | KEYGEN — reprezentacje oparte na punktach kluczowych | Czy umiejętność przenosi się na inny przedmiot tej samej kategorii? |
AGILE: mniej ręcznego ratowania eksperymentu
Autorzy AGILE proponują uporządkowany workflow obejmujący weryfikację środowiska, trening, ocenę i wdrożenie. W pracy opisują testy na Unitree G1 i Booster T1. Nazwa projektu AGILE nie oznacza tu firmy Agile Robots ani robota Agile ONE. [19]
To ważny, choć mało widowiskowy problem. Jeżeli eksperyment działa tylko na komputerze jego autora, trudno rozwijać na tej podstawie produkt. Każda zmiana robota, zadania lub środowiska może ponownie uruchamiać długą serię ręcznych poprawek. Uporządkowany proces oceny daje szansę zauważyć regresję wcześniej, zanim pojawi się ona na fizycznym urządzeniu.
Dla czytelnika niebędącego specjalistą sens jest prosty: nie pytamy wyłącznie, czy nowa umiejętność wygląda dobrze. Pytamy, czy zespół ma powtarzalny sposób sprawdzenia, kiedy działa i kiedy przestaje działać. To ten drugi element ułatwia przejście od prezentacji do systematycznego rozwoju.
Nie wyciągamy z tej pracy wniosku, że dowolny G1 po instalacji programu nadaje się do samodzielnej pracy przemysłowej. Wynik badawczy jest związany z opisanymi zadaniami, sprzętem i warunkami eksperymentu. Przeniesienie go do innego procesu wymaga osobnej oceny.
OG-VLA: robot musi rozumieć także geometrię
OG-VLA łączy możliwości modeli vision-language-action z reprezentacją przestrzenną. Autorzy wykorzystują obserwacje RGB-D i widoki ortograficzne, by ograniczać wrażliwość na zmianę ustawienia kamery. Pierwsza wersja preprintu pochodzi z czerwca 2025 roku; obecność w programie IROS 2026 nie zmienia tej daty. [20]
Wyobraźmy sobie polecenie: „odłóż przedmiot do pudełka”. Zrozumienie słów nie wystarcza. Robot musi jeszcze ustalić położenie przedmiotu i celu, wybrać orientację chwytaka i wykonać ruch w świecie fizycznym. Drobna zmiana widoku może być dla modelu większym problemem, niż sugeruje płynny język jego odpowiedzi.
Z punktu widzenia wdrożenia ciekawy jest więc nie sam wynik na jednej scenie, ale odporność na zmianę perspektywy. Czy po przesunięciu kamery trzeba zbierać dane od nowa? Czy reprezentacja zachowuje informację przydatną do precyzyjnego chwytu? Czy ograniczenia pojawiają się przy zasłonięciu przedmiotu? Takie pytania pomagają czytać wyniki bez mylenia językowej sprawności z fizyczną niezawodnością.
Warto też uważać na procenty w streszczeniach prac. Poprawa względem konkretnej metody bazowej nie jest tym samym co odsetek poprawnie wykonanych zadań. W tym raporcie nie przepisujemy wartości procentowych do nagłówka bez kontekstu zestawu testowego i sposobu pomiaru.
KEYGEN: inny kubek nie powinien oznaczać całego projektu od nowa
KEYGEN dotyczy reprezentacji obiektów i uogólniania umiejętności na poziomie kategorii. Projekt wykorzystuje punkty kluczowe do opisywania obiektów. To inny problem niż samo rozpoznanie, że na zdjęciu znajduje się kubek lub narzędzie. [21]
Dla manipulacji istotne są relacje potrzebne do działania. Przedmiot może mieć inny rozmiar, materiał lub kształt, a mimo to należeć do tej samej funkcjonalnej kategorii. Badanie takich reprezentacji może ograniczać potrzebę przygotowywania osobnego zachowania dla każdej sztuki. To potencjalny kierunek, nie obietnica działania na dowolnym przedmiocie.
Praktyczny sprawdzian polegałby na wybraniu obiektów, których zespół nie używał do dostrajania rozwiązania. Ważne, by zestaw nie składał się jedynie z niemal identycznych wariantów. Dopiero wyraźne opisanie różnic pozwala ocenić, jak szerokie jest deklarowane uogólnianie.
Dlaczego nie robimy newsa z każdej demonstracji
Przed publikacją osobnego materiału potrzebujemy źródła pierwotnego, rozpoznanej platformy i jasnego opisu tego, co pokazano. Szczególnie ostrożnie podchodzimy do zdania „zadziałało za pierwszym razem”. Może ono dotyczyć pierwszej próby po długim przygotowaniu, a nie braku treningu czy integracji. Bez opisu procedury nie da się tego rozstrzygnąć.
Nie łączymy też automatycznie filmów różnych generacji. Materiał z Digit v4 nie jest testem Digit 5. Osobną, potwierdzoną historię o architekturze i terminach nowej generacji opisujemy w analizie Digit 5. Oznaczenie platformy jest częścią faktu, a nie drobnym szczegółem podpisu.
Pięć pytań, które zamieniają konferencyjny zachwyt w ocenę
Pierwsze: czy test obejmował nowe obiekty i warunki, czy tylko te, na których dopracowano metodę? Drugie: ile było prób, także nieudanych? Trzecie: kiedy i w jaki sposób interweniował operator? Czwarte: co dzieje się po błędzie — automatyczny powrót, restart czy ręczne ustawienie robota? Piąte: które elementy rozwiązania są dostępne do odtworzenia?
Te pytania nie mają umniejszać badaniom. Pomagają ustalić, co dokładnie zostało osiągnięte. Nawet ograniczony eksperyment może być wartościowy, jeżeli jasno pokazuje nową możliwość i jej granice. Problem zaczyna się wtedy, gdy ograniczony wynik zostaje przedstawiony jako gotowa odpowiedź na dowolne zadanie.
Dla firmy planującej zakup warto dodać jeszcze warunek operacyjny: czy zespół potrafi utrzymywać rozwiązanie po wdrożeniu? Demonstracja nie odpowie sama na pytania o aktualizacje, diagnostykę, części i odpowiedzialność za cały proces. To kolejny etap, nie automatyczna konsekwencja publikacji naukowej.
Stan raportu i następne aktualizacje
28.09.2026 — wydanie bazowe: potwierdzone daty konferencji, trzy wybrane kierunki badawcze, źródła prac i kryteria oceny demonstracji. Nie dodano wpisów z przyszłych dni ani twierdzeń o wydarzeniach, których przebiegu nie potwierdziliśmy.
Ten adres służy jako punkt odniesienia dla kolejnych zweryfikowanych aktualizacji. Data zmiany będzie oznaczać rzeczywiste uzupełnienie materiału, nie automatyczne odświeżenie datownika. Zobacz również niemiecki ekosystem Physical AI i poradnik zakupu humanoidów.
Źródła i metodologia
Analiza redakcyjna na podstawie podlinkowanych źródeł, stan na 28 września 2026 r. Dane producentów i sprzedawców nie są wynikami testów RoboMorrow. Nie otrzymaliśmy tych robotów do niezależnego testu.
Georgia Tech — IROS 2026 programme and dates · Zhao et al. — AGILE, arXiv:2603.20147 · Singh et al. — OG-VLA, arXiv:2506.01196 · KEYGEN — authors’ project page · Agility — Digit 5 announcement, 15.09.2026