Sieci dla robotów: Wi-Fi, przewody, 5G i znaczenie opóźnień

Humanoid to mobilny węzeł w sieci, która niemal na pewno została zaprojektowana z myślą o nieruchomo stojących laptopach. Ta rozbieżność odpowiada za około 95% zgłoszeń typu „robot dziś dziwnie się zachowuje”, jakie kiedykolwiek Państwo założą. Sterowniki silników są w porządku. Jetson jest w porządku. Model na serwerze AI Kentino jest w porządku. To Wi-Fi nie jest w porządku.

Ten artykuł dotyczy drugiej połowy I01— przedstawionego tam schematu z dwoma urządzeniami, a konkretnie łącza pośrodku. Zakupiony robot jest tylko tak dobry, jak sieć, w której pracuje, a tę sieć najprawdopodobniej trzeba przebudować, zanim zasłuży na określenie „w porządku”.

Dla kogo: integratorzy, kierownicy laboratoriów i zespoły IT, którym zapowiedziano dostawę humanoida w przyszłym miesiącu i które nie zdążyły jeszcze przyjąć do wiadomości, że istniejąca firmowa sieć Wi-Fi okryje wszystkich wstydem.

Dlaczego sieć dla robotów to osobny problem

Większość firmowych sieci Wi-Fi jest wymiarowana pod ruch generowany przez ludzi: skokowe pobieranie plików, okazjonalne wideokonferencje, długie okresy bezczynności. Humanoid nie robi nic z tych rzeczy. Generuje ciągły, dwukierunkowy strumień komunikatów sterujących o niskiej przepływności, nieregularne serie danych obrazowych wysyłanych do serwera inferencyjnego oraz stały, cienki strumień telemetrii. Strumień sterujący jest niewielki (kilobajty na sekundę), ale chorobliwie wrażliwy na jitter. Serie obrazów są obszerne (dziesiątki do setek megabajtów na sekundę w postaci surowej) i wymagają szerokiej ścieżki. Telemetria jest wyrozumiała i nikogo nie ekscytuje.

Co czyni ten problem wyjątkowym:

• Węzeł się porusza. Robot przechodzi przez granicę komórek między punktami dostępowymi, a zdarzenie roamingu powoduje utratę pakietów przez 50–500 ms, zależnie od konfiguracji sieci. Użytkownik laptopa tego nie zauważy. Kontroler równowagi robota — owszem, może zauważyć.
• Środowisko radiowe jest wrogie. Laboratorium o powierzchni 30 m² z dwoma inżynierami, trzema laptopami, ekspresem do kawy z Wi-Fi i kuchenką mikrofalową to całkowicie normalne środowisko radiowe, które bezlitośnie zniszczy łącze robota w paśmie 5 GHz. Tłumienie przez korpus samego robota blokuje sygnał w nieprzewidywalnych kierunkach, gdy robot się obraca.
• Zakłócenia między robotami się kumulują. Dwa roboty G1 w tym samym pomieszczeniu na tym samym kanale nie będą ze sobą grzecznie współpracować. Trzy to już problem. Flota ośmiu wymaga rzetelnego planowania.
• Protokoły powyżej warstwy radiowej także są kruche. Domyślna konfiguracja DDS w ROS 2 opiera się na multicastach IP przy wykrywaniu uczestników. Wi-Fi obsługuje multicast źle. Połączenie tych dwóch rzeczy generuje zgłoszenia „węzły się nawzajem nie widzą”, które wyglądają jak błędy robota.

Wszystko to da się rozwiązać. Nic z tego nie jest rozwiązane domyślnie.

Wi-Fi 6E: dzisiejsze minimum

Uczciwym punktem wyjścia dla sieci Wi-Fi pod robotykę w 2026 roku jest Wi-Fi 6E z dedykowanym SSID w paśmie 6 GHz wyłącznie dla robotów. Nie Wi-Fi 6. Nie 5 GHz w wersji „poprawimy to później”. 6E, 6 GHz, osobny SSID, odizolowany VLAN.

Chodzi o czystość widma radiowego, a nie o przepustowość z nagłówków. Pasmo 6 GHz jest na tyle nowe, że konsumencka tandeta jeszcze go nie zalała. Na 6 GHz nie ma Bluetootha, nie ma harmonicznych z kuchenki mikrofalowej, nie ma 15-letniej drukarki rozgłaszającej ramki. Radio robota dostaje czysty kanał. Ten czysty kanał jest wart więcej niż jakakolwiek poprawa w specyfikacji.

Tak wyglądają realne czasy RTT robota w sieci Wi-Fi 6E, mierzone od procesora robota do serwera inferencyjnego po przewodowej stronie punktu dostępowego:

Czyste łącze 6 GHz zapewnia jednocyfrowe wartości RTT w milisekundach na tyle stabilnie, że węzły ROS 2, klienci gRPC łączący się z vLLM i teleoperacja działają responsywnie. Ten sam robot przeniesiony na współdzielony SSID 5 GHz będzie sprawiał wrażenie „ociężałego” w sposób, którego nikt nie potrafi ująć liczbowo, dopóki tego nie zmierzy.

Wi-Fi 7 w 2026 roku: ograniczone wsparcie, realna obietnica

Sztandarową funkcją Wi-Fi 7 jest Multi-Link Operation (MLO) — radio łączy dwa lub trzy pasma (2.4/5/6 GHz) jednocześnie i albo agreguje przepustowość, albo replikuje pakiety na wielu łączach dla zwiększenia niezawodności. Spadek opóźnień w Wi-Fi 7 względem 6E jest realny tam, gdzie MLO jest włączone: producenci podają 50–75% redukcji opóźnień, a pomiary laboratoryjne w kontrolowanych warunkach pokazują RTT dla Wi-Fi 7 z MLO w zakresie 1.5–4 ms wobec 3–6 ms w Wi-Fi 6E. Wartości poniżej milisekundy pojawiają się czasem w materiałach marketingowych, lecz nie zostały odtworzone na sprzęcie robotycznym.

Haczykiem jest radio w samym robocie. W połowie 2026 roku popularne platformy humanoidalne (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) są dostarczane z Wi-Fi 6 lub 6E. Żadna z nich nie deklaruje Wi-Fi 7 w wersji podstawowej. Postawienie punktu dostępowego Wi-Fi 7 przed robotem z Wi-Fi 6E daje backhaul w standardzie Wi-Fi 7 i łącze robota w 6E — to nie szkodzi, ale płaci się wtedy za możliwości, których na razie nie da się wykorzystać.

Kiedy Wi-Fi 7 zacznie mieć znaczenie dla robotów:

• Gdy robot będzie standardowo wyposażony w moduł Wi-Fi 7 (spodziewane w platformach z 2027 roku).
• Gdy MLO będzie mogło replikować strumień pakietów warstwy sterowania jednocześnie w pasmach 5 GHz i 6 GHz, eliminując zaniki w pojedynczym paśmie.
• Gdy wdrażana flota będzie na tyle duża, że wąskim gardłem stanie się przeciążenie jednego pasma, niezależnie od opóźnień.

Dla laboratorium z jednym robotem w 2026 roku: 6E wystarczy. Dla floty planowanej od 2027 roku: warto już dziś specyfikować punkty dostępowe w standardzie Wi-Fi 7, aby nie kupować sieci po raz drugi za osiemnaście miesięcy.

Rozmieszczenie i gęstość punktów dostępowych

Odruchem jest zamontowanie jednego punktu dostępowego pod sufitem w rogu pomieszczenia. Efektem jest półmetrowa martwa strefa za stołem laboratoryjnym, w której robot traci sygnał dokładnie podczas zaplanowanej prezentacji.

Sprawdzone zasady praktyczne:

Bezpośrednia widoczność bije moc. Punkt dostępowy 30 dBm za stalowym rackiem daje gorszy sygnał niż punkt 20 dBm zamontowany pod sufitem na środku pomieszczenia. Roboty są niskie — antena na wysokości klatki piersiowej, 1.2 m, widzi inne środowisko radiowe niż laptop na biurku na wysokości 0.7 m i gorsze niż telefon na 1.5 m. Punkty dostępowe powyżej 2.5 m, roboty poniżej 1.5 m, żadnych przeszkód wielkości człowieka na głównej ścieżce sygnału.

Dedykowany SSID dla robotyki. Kwestia nienegocjowalna. SSID robotów ma własny VLAN, własny profil QoS, własny zakres DHCP i żadnego ruchu użytkowego. Wpięcie robota do firmowego Wi-Fi sprawdza się na etapie prac rozwojowych przez tydzień, po czym stażysta z marketingu dołącza do wideokonferencji, a robot się przewraca.

Tłumienie przez korpus — problem anteny

Tors humanoida to stalowo-plastikowa skrzynia o szerokości około 30 cm. Antena radiowa znajduje się zwykle gdzieś wewnątrz płyty piersiowej, często z tyłu lub z boku. Gdy robot odwraca się od punktu dostępowego, jego korpus staje się częściową klatką Faradaya.

Strata mocy sygnału wynosi zwykle 6–15 dB, zależnie od umiejscowienia anteny i zawartości metalu w korpusie. To wystarczy, aby graniczne łącze przeszło ze stanu „działa dobrze” w stan „zrywa się co kilka sekund” wyłącznie wskutek obrotu. Roboty czworonożne cierpią mniej, bo są niższe i bardziej płaskie, a antena znajduje się zazwyczaj na krawędzi podwozia, z czystszym widokiem ku górze.

Co pomaga:

• Antena na głowie lub barkach, nie na klatce piersiowej. Część humanoidów klasy badawczej pozwala przenieść antenę lub dodać antenę zewnętrzną. Większość jednostek klasy konsumenckiej — nie. Jeśli niezawodność radiowa jest wymogiem wdrożenia, prosimy zapytać o to przed zakupem.
• Dwa punkty dostępowe z dywersyfikacją. Przy punktach dostępowych na przeciwległych ścianach robot jest „zwrócony” do jednego z nich niezależnie od orientacji. Roaming między punktami obsługuje przełączenie — kiepsko, ale lepiej niż brak sygnału.
• Niżej zamontowane anteny po stronie punktu dostępowego. Jeśli punkty dostępowe wiszą pod sufitem na 3 m, a antena robota jest na 1.0 m, kąt elewacji jest na tyle stromy, że klatka piersiowa blokuje znaczną część ścieżki. Punkty montowane na ścianie na wysokości 2 m dają bardziej płaską i łatwiejszą ścieżkę.

Przewód: jak pracują poważne zespoły

Każdy poważny zespół robotyczny ma przewód. Większość o nim nie mówi, bo psuje on estetykę pokazu w stylu „patrzcie, bez kabli”. Każdy, kto wykonuje realną pracę integracyjną, podpina robota kablem.

Przewodem jest kabel USB-C, kabel Ethernet M12 X-code albo — w jednostkach klasy badawczej — spiralny kabel pępowinowy prowadzący jednocześnie zasilanie i dane. Przepustowość wynosi 1 Gbps lub więcej, a opóźnienie to podmilisekundowy czas obiegu, często poniżej 200 µs. To o dwa rzędy wielkości lepiej niż najlepsze łącze Wi-Fi.

Powodem stosowania przewodu podczas prac rozwojowych nie jest przepustowość, lecz wyeliminowanie zmiennej. Gdy Wi-Fi jest kapryśne, nie sposób stwierdzić, czy wolno działa węzeł ROS 2, czy model, czy po prostu eter jest zły. Po podpięciu kabla eteru nie ma. Wszystko inne staje się łatwiejsze do diagnozowania.

Unitree G1 EDU i Booster T1 mają wiarygodnie rozwiązane podpinanie przewodu. H1 podłącza się niewygodnie. PM01 i SE01 obsługują przewodową pracę rozwojową przez standardowe USB-C lub Ethernet. Roboty czworonożne (Go2) rzadko pracują na przewodzie, bo ich zastosowania są zewnętrzne; przy poważnej pracy z uczeniem ze wzmocnieniem w pomieszczeniu i tak warto to rozważyć.

Prywatne sieci 5G: kiedy się opłacają

Prywatne 5G — własna sieć komórkowa na terenie obiektu, w paśmie licencjonowanym lub współdzielonym — weszło w fazę „realnego produktu” w 2025 roku i w 2026 jest wdrażane na szeroką skalę. Technologia działa.

Kiedy prywatne 5G ma sens:

• Duże obiekty na otwartej przestrzeni. Zakłady o powierzchni wielu hektarów, górnictwo, wielkoobszarowe rolnictwo, porty. Komórki Wi-Fi nie skalują się w takich warunkach; liczba punktów dostępowych i nakład pracy na pomiary przewyższają koszt jednej sieci 5G opartej na małych komórkach.
• Kampusy złożone z wielu budynków. Gdy robot musi przemieszczać się z wnętrza na zewnątrz i z powrotem albo między budynkami, roaming Wi-Fi robi się nieprzyjemny. 5G obsługuje mobilność natywnie.
• Wdrożenia nastawione na mobilność. Roboty inspekcyjne pokonujące kilometry, autonomiczne roboty mobilne w dużych magazynach, wszystko, gdzie łącze radiowe musi podążać za jednostką w terenie.
• Mieszana flota z innymi urządzeniami 5G. Jeśli obiekt ma już prywatne 5G dla wózków widłowych, pojazdów AGV lub sieci czujników, dołożenie robotów to koszt przyrostowy, a nie nowy projekt.

Kiedy to przesada:

• Jedno laboratorium, jeden budynek, od jednego do czterech robotów. Wi-Fi 6E wykona to zadanie za 3–8 tys. EUR wydane na punkty dostępowe. Prywatne 5G zrobi to za 60–200 tys. EUR na małe komórki, EPC/5GC, licencje na widmo i współpracę z dostawcą. Proporcje się nie zgadzają.
• Czyste środowiska deweloperskie. Przewód plus Wi-Fi daje wszystko to, co dałoby 5G, i nic więcej do zarządzania.
• Brak zespołu sieciowego. Prywatnego 5G nie da się „ustawić i zapomnieć”. To dodatkowy system produkcyjny, który trzeba eksploatować, monitorować i aktualizować.

Budżet opóźnień: które obciążenia co wytrzymują

Wzorzec jest jasny: praca w pętli zamkniętej odbywa się lokalnie lub po przewodzie, percepcja połączona z wnioskowaniem zniesie Wi-Fi, a rozmowa zniesie WAN. Błędem architektonicznym jest umieszczanie kodu sąsiadującego z pętlą silników na ścieżce narażonej na jitter sieciowy. Drugim błędem jest płacenie za transmisję o opóźnieniu 5 ms, gdy opóźnienie modelu wynosi 400 ms — oszczędza się wtedy 30 ms z 430 ms całości. Optymalizować należy człon dominujący.

Wzorzec „zawsze jedną nogą w chmurze”

Nawet przy rygorystycznym wdrożeniu lokalnym robot rzadko bywa całkowicie odcięty od sieci. Elementy, które zasadnie potrzebują WAN:

• Telemetria do własnego stosu monitorującego (Prometheus / Grafana / Datadog). Przydatna, niewymagająca pasma, zniesie dowolny RTT.
• Aktualizacje modeli i firmware. Pobieranie nowych wag modeli VLM, obrazów kontenerów, poprawek systemu. Ruch skokowy, można go realizować nocą.
• Dane map i otoczenia. Plan pomieszczeń, synchronizacja chmury punktów, kopia zapasowa pamięci sceny.
• Awaryjna teleoperacja zdalna. Czasami; z zastrzeżeniem przeglądu bezpieczeństwa.

Wzorzec brzmi: lokalnie w pierwszej kolejności dla ścieżki gorącej, wyjście do WAN za zaporą dla ścieżki zimnej. Robot nigdy nie potrzebuje adresu przychodzącego z WAN. Serwer również go nie potrzebuje. Wyłącznie ruch wychodzący, cele z listy dozwolonych, TLS, bez wyjątków.

Multicast, mDNS, DDS — i dlaczego Wi-Fi czyni je bolesnymi

ROS 2 domyślnie korzysta z DDS jako warstwy pośredniczącej. DDS używa multicastu IP do wykrywania uczestników. Wi-Fi obsługuje multicast, nadając go z najniższą prędkością wspólną dla wszystkich klientów danego BSSID, co:

1. Marnuje czas antenowy.
2. Wygląda dla firmware punktu dostępowego jak zalew pakietów.
3. Bywa odrzucane przez korporacyjne punkty dostępowe z włączoną supresją multicastu.

Efektem jest „moje węzły ROS 2 widzą się po Ethernecie, ale nie po Wi-Fi” — dobrze udokumentowana i całkowicie możliwa do uniknięcia awaria. Zmierzone straty pakietów multicastowych ROS 2 w Wi-Fi sięgają 1–3% nawet na zdrowych łączach; w Ethernecie wynoszą zero. Dwa roboty z ROS 2 w tej samej sieci Wi-Fi potrafią wywołać burze wykrywania destabilizujące punkt dostępowy.

Rozwiązania, w kolejności od najlepszego:

1. Zastosowanie serwera wykrywania Fast-DDS. Wystarczy uruchomić serwer wykrywania (zwykle na serwerze inferencyjnym lub na dedykowanej maszynie wirtualnej), skierować do niego wszystkie węzły ROS 2 przez unicast i wykrywanie staje się zwykłym ruchem klient–serwer, z którym Wi-Fi radzi sobie dobrze.
2. Statyczna konfiguracja węzłów przez profil XML. Adres IP drugiej strony wpisuje się na sztywno. Rozwiązanie kruche, ale sprawdza się przy stałej parze urządzeń.
3. Włączenie IGMP snooping i konwersji multicast-na-unicast na punkcie dostępowym. Obsługują to Aruba, Ruckus, Cisco Meraki oraz nowsze wersje firmware UniFi. Wystarczy powiedzieć inżynierowi sieciowemu; to dwa pola wyboru.
4. Zmiana implementacji RMW. Część użytkowników przechodzi z Cyclone DDS na Fast-DDS lub na Zenoh-bridge właśnie po to, by uciec od semantyki wykrywania opartej na multicaście. Ostateczność; wiąże się z kosztem integracji.

QoS, DSCP i uzyskiwanie priorytetu

SSID robotów ma własny VLAN, a VLAN ma własny profil QoS. Kolejną warstwą jest upewnienie się, że sieć zgadza się z tezą, iż ruch robotów jest ważniejszy niż synchronizacja Dropboxa działu marketingu.

Standardowy schemat:

• Ruch sterujący robota oznaczany jako EF (Expedited Forwarding, DSCP 46). Strumień warstwy sterowania jest mały i krytyczny pod względem opóźnień; EF to podręcznikowa klasa dla takiego ruchu.
• Strumienie obrazu oznaczane jako AF41 (DSCP 34). Wideo w czasie rzeczywistym, wysoka przepustowość, niższy priorytet niż sterowanie.
• Telemetria i pobieranie modeli oznaczane domyślnie (DSCP 0). Bez specjalnego traktowania.
• Mapowanie WMM na punkcie dostępowym musi respektować te oznaczenia. Większość korporacyjnych punktów dostępowych (Aruba, Cisco Meraki, Ruckus) robi to automatycznie po włączeniu zaufania do DSCP. UniFi wymaga jawnej konfiguracji w nowszych wersjach firmware.

Konkretna architektura sieci dla laboratorium robotycznego

Działająca konfiguracja dla laboratorium z 1–4 robotami, dopasowana do realiów sprzętowych z artykułu I01 :

Referencyjna sieć laboratoryjna: roboty → dedykowane punkty dostępowe 6 GHz → przełącznik 10 GbE → serwer AI Kentino. Ruch wychodzący za zaporą, wyłącznie na zewnątrz.

Dla 1–4 robotów w jednym pomieszczeniu taka konfiguracja to wydatek rzędu 4–12 tys. EUR na sprzęt sieciowy, zależnie od klasy producenta. Ruckus i Aruba najlepiej radzą sobie z sygnałem radiowym w gęstych lub nieprzyjaznych środowiskach. Cisco Meraki wygrywa prostotą, kosztem opłat cyklicznych. UniFi wygrywa ceną i w pełni wystarcza do pracy w pojedynczym laboratorium.

Tryby awarii, mniej więcej w kolejności, w jakiej dadzą się we znaki

• Roaming między punktami dostępowymi zabija strumień. Robot przekracza granicę komórki, asocjacja zrywa się na 100–400 ms, gniazdo ROS 2 się odbudowuje, ale w logach pojawia się luka w strumieniu sterującym. Zaradzić można nakładającymi się komórkami, szybkim roamingiem 802.11k/v/r oraz przede wszystkim nieopieraniem sterowania w pętli zamkniętej na sieci.
• Zakłócenia między robotami na współdzielonych kanałach. Trzy roboty G1 na tym samym kanale 6 GHz odbierają sobie nawzajem czas antenowy. Należy zaplanować nienakładające się kanały 80 MHz w paśmie 6 GHz (w UE jest ich siedem, w USA więcej).
• Konstrukcja budynku. Ściany żelbetowe tłumią 20–30 dB. Stalowe drzwi serwerowni tłumią 40 dB. Pomiary radiowe obiektu przed montażem punktów dostępowych — za każdym razem.
• Wygaśnięcie dzierżawy DHCP w trakcie zadania. Długa sesja robota, odnowienie DHCP się nie udaje, adres IP się zmienia, gniazda się rozpadają. Statyczne rezerwacje DHCP dla robota. Zawsze.
• Tryby oszczędzania energii. Oszczędzanie energii w radiu Wi-Fi robota zwiększa opóźnienia w imię czasu pracy na baterii. Należy je jawnie wyłączyć. Czas pracy na baterii to problem baterii; nie warto płacić za niego jitterem.
• Niezgodność MTU. SDK producenta robota używa 1500, infrastruktura sieciowa 9000, dochodzi do fragmentacji, a wydajność po cichu się załamuje. MTU należy ujednolicić na całej trasie.

Szczerze mówiąc

Najbardziej użyteczne zdanie w tym artykule: 95% „problemów z robotem” zgłaszanych w pierwszym miesiącu wdrożenia to problemy z konfiguracją Wi-Fi. Robot jest w porządku. Model jest w porządku. To Wi-Fi nie jest w porządku: SSID jest współdzielony z biurem, nie ma dedykowanego VLAN-u, multicast szaleje, punkty dostępowe wiszą w złych miejscach, a integrator przez trzy tygodnie diagnozuje niewłaściwą warstwę.

Warto zatrudnić specjalistę od sieci wcześnie i zapłacić mu więcej, niż się wydaje rozsądne. Starszy inżynier sieciowy, który potrafi rozplanować sieć Wi-Fi 6E, skonfigurować QoS na całej trasie i dostroić wykrywanie DDS, jest w tym projekcie wart tyle samo co starszy robotyk, a znacznie trudniej go znaleźć.

---

To część Kentino Wiki — serii referencyjnej o mocy obliczeniowej AI, robotyce i systemach, które je łączą. Uwagi i sprostowania prosimy kierować na adres info@kentino.com.