WBA-FM
Jak działa
1) Przygotowanie zbioru ruchów referencyjnych — typowo motion capture człowieka (AMASS, KIT, własne MoCap). 2) Retargeting ludzkich kości na morfologię robota (rozwiązanie różnic w długości segmentów i zakresie stawów). 3) Trening w symulatorze fizycznym (Isaac Gym, MuJoCo) metodą reinforcement learning z nagrodą za śledzenie pozy referencyjnej, równowagę i wykonalność fizyczną. 4) Wdrożenie na realnym robocie — często z dodatkową, lekką warstwą kompensacji sim-to-real. 5) WBA-FM jest sterowane wysokopoziomową polityką, która wysyła mu cele (poza, trajektoria, kierunek), a nie konkretne wartości momentów.
Rozwiązany problem
Klasyczne sterowanie humanoidem wymaga ręcznie strojonych kontrolerów per część ciała (PD na ramieniu, MPC na nodze, ZMP na balansie). Skalowanie na nowe zadania i nową morfologię jest kosztowne, a koordynacja całego ciała pozostaje krucha. WBA-FM zastępuje ten stos jedną siecią, która uczy się skoordynowanego ruchu z danych.
Komponenty
Przetwarza odczyty czujników stawów (pozycje, prędkości, momenty), IMU oraz stan końcówek na ukrytą reprezentację stanu robota.
Oficjalna
Koduje cel z poziomu wyższej polityki: pozę referencyjną, trajektorię końcówki, kierunek marszu, prędkość. Zwykle odpowiada za różne reprezentacje celu (keyframes, parametry zadania).
Oficjalna
Rdzeń sieci — zwykle transformer lub MLP — generujący skoordynowane polecenia dla wszystkich stawów. Wyjście to momenty lub pozycje docelowe (w zależności od typu sterowania robota).
Głowica wartości używana podczas treningu reinforcement learning. Estymuje zwrot z obecnego stanu i akcji, prowadzi optymalizację polityki. Nieaktywna na wdrożeniu.
Oficjalna
Implementacja
Człowiek i robot mają różną liczbę stawów, długości segmentów i zakresy ruchu. Naiwna projekcja MoCap prowadzi do niewykonalnych pozycji.
Symulacja niedokładnie odwzorowuje tarcie, luzy mechaniczne i opóźnienia komunikacyjne — co prowadzi do niestabilności na realnym robocie.
WBA-FM trenowany na jednym humanoidie (np. Unitree H1) słabo przenosi się na inny (np. Tesla Optimus). Limituje generalizację cross-embodiment.
Ewolucja
Oussama Khatib formalizuje operational-space whole-body control: ręcznie strojone kontrolery sterujące wieloma celami priorytyzowanymi (balans + ruch ramieniem). Podstawa robotyki humanoidalnej przez ~20 lat.
Stanford (Fu et al., CoRL 2024) publikuje HST — transformer trenowany RL w symulacji na masowych danych MoCap, sterujący całym ciałem humanoida w czasie rzeczywistym. Przełom: neuronowa polityka zastępuje cały klasyczny stos WBC.
Seria prac (Stanford, CMU, NVIDIA) rozszerza paradygmat: różne warianty whole-body controllerów wytrenowanych na MoCap, optymalizujące balance, manipulację i lokomocję wspólnie.
MindOn w architekturze Mind-0 wprowadza nazwę Whole-Body Action Foundation Model dla niskopoziomowego modelu trenowanego na dziesiątkach tysięcy godzin MoCap. Deklaruje sub-3 cm dokładność śledzenia końcówki i globalną spójność ruchu. Pełni rolę uniwersalnego interfejsu wykonawczego dla heterogenicznej floty.
Złożoność obliczeniowa
Złożoność czasowa: O(N · L · d²) na krok sterowania. Złożoność przestrzenna: O(N · d² + N · L · d) ≈ O(N · d²).
Wąskie gardło obliczeniowe
Ponieważ okno kontekstu jest małe i stałe (np. 8 kroków), mechanizm uwagi NIE jest wąskim gardłem — inaczej niż w LLM. Koszt dominują gęste mnożenia w warstwach projekcji i FFN (O(d²)). Na wdrożeniu krytyczna jest latencja pojedynczego forward-pass w pętli 50-200 Hz, nie przepustowość: każdy krok musi zmieścić się w budżecie czasu jednego cyklu sterowania.
Paradygmat wykonania
Każdy forward-pass aktywuje całą sieć i generuje polecenia dla wszystkich stawów jednocześnie. Sterowanie pracuje typowo w 50-200 Hz w pętli zamkniętej.
Równoległość
Trening RL (PPO) zrównolegla się masowo na dziesiątkach tysięcy symulowanych środowisk naraz (Isaac Gym), stąd across_devices. Pojedynczy forward-pass jest w pełni równoległy wewnątrz sieci (across_tokens dla okna kontekstu). Sekwencyjna pozostaje wyłącznie pętla sterowania w czasie rzeczywistym.
Wymagania sprzętowe
Trening RL w symulacji wymaga dziesiątek tysięcy równoległych środowisk (Isaac Gym) — GPU klasy data center.
Wdrażany model jest mały (single MLP/Transformer) — działa na embedded compute robota (Jetson Orin, x86 mini-PC).