Sítě pro roboty: Wi-Fi, kabel, 5G a proč na latenci záleží

Humanoid je pohyblivý uzel v síti, která byla téměř jistě navržena pro notebooky stojící na místě. Právě z tohoto nesouladu pramení zhruba 95 % všech ticketů ve stylu „robot je dneska nějaký divný". Motorové regulátory jsou v pořádku. Jetson je v pořádku. Model na AI serveru Kentino je v pořádku. Wi-Fi v pořádku není.

Tento článek se věnuje druhé polovině obrázku o dvou krabicích z I01 — konkrétně spoji uprostřed. Robot, kterého jste koupili, je jen tak dobrý jako síť, do které ho dáte, a tu síť bude nejspíš potřeba přestavět, než si zaslouží slovo „v pořádku".

Pro koho: integrátory, vedoucí laboratoří a IT týmy, kterým oznámili, že příští měsíc dorazí humanoid, a které zatím nedošlo, že stávající firemní Wi-Fi všechny pořádně zostudí.

Proč je síť pro roboty samostatný problém

Většina firemních Wi-Fi sítí je dimenzovaná na provoz v lidském měřítku: nárazové stahování, občasný videohovor, dlouhé doby nečinnosti. Humanoid nedělá nic z toho. Generuje souvislý obousměrný tok řídicích zpráv s malým datovým tokem, nárazové dávky obrazových dat směrem k inferenčnímu serveru a vytrvalý pramínek telemetrie. Řídicí tok je malý (kilobajty za sekundu), ale chorobně citlivý na jitter. Obrazové dávky jsou tučné (desítky až stovky megabajtů za sekundu v surové podobě) a potřebují tučnou cestu. Telemetrie je nenáročná a nikoho nezajímá.

Co dělá tento problém jedinečným:

• Uzel se pohybuje. Robot přejde hranici buňky mezi dvěma AP a při roamingu se ztrácejí pakety po dobu 50–500 ms podle konfigurace sítě. Uživatel notebooku si toho nevšimne. Balanční regulátor robota ano.
• RF prostředí je nepřátelské. Laboratoř o 30 m² se dvěma inženýry, třemi notebooky, kávovarem s Wi-Fi a mikrovlnkou je naprosto běžné RF prostředí, které spolehlivě rozcupuje robotí spoj v pásmu 5 GHz. Stínění vlastním tělem robota blokuje signál v nepředvídatelných směrech podle toho, jak se otáčí.
• Rušení mezi roboty se sčítá. Dva G1 ve stejné místnosti na stejném kanálu se nedohodnou po dobrém. Tři už jsou problém. Flotila osmi vyžaduje skutečné plánování.
• Protokoly nad rádiem jsou také křehké. Výchozí konfigurace DDS v ROS 2 spoléhá na IP multicast pro discovery. Wi-Fi zvládá multicast špatně. Výsledkem jsou tickety „uzly se navzájem nevidí", které vypadají jako chyba robota.

Řešit se to dá. Nic z toho ale není vyřešené samo od sebe.

Wi-Fi 6E: dnešní minimum

Poctivým výchozím bodem pro nasazení Wi-Fi v robotice v roce 2026 je Wi-Fi 6E s vyhrazeným 6GHz SSID jen pro roboty. Ne Wi-Fi 6. Ne 5 GHz s tím, že „to doladíme později". 6E, 6 GHz, samostatné SSID, oddělená VLAN.

Důvodem je čistota RF prostředí, ne čísla propustnosti z datasheetu. Pásmo 6 GHz je natolik nové, že ho spotřebitelský šunt ještě nestihl zaplavit. Na 6 GHz není žádný Bluetooth, žádná harmonická z mikrovlnky, žádná patnáct let stará tiskárna vysílající beacony. Rádio Vašeho robota dostane čistý kanál. A ten má větší cenu než jakékoli zlepšení v papírové specifikaci.

Jak vypadá reálné RTT robota na Wi-Fi 6E, měřeno z CPU robota na inferenční server na drátové straně AP:

Čistý 6GHz spoj drží RTT v jednotkách milisekund natolik konzistentně, že uzly ROS 2, gRPC klienti k vLLM i teleoperace působí svižně. Stejný robot přepojený na sdílené 5GHz SSID bude působit „zasekaně" způsobem, který nikdo neumí vyčíslit, dokud se to nezměří.

Wi-Fi 7 v roce 2026: omezená podpora, reálný příslib

Hlavní devízou Wi-Fi 7 je Multi-Link Operation (MLO) — rádio spojí dvě nebo tři pásma (2,4/5/6 GHz) současně a buď sečte propustnost, nebo pakety mezi spoji replikuje kvůli spolehlivosti. Tam, kde je MLO zapnuté, je snížení latence oproti 6E reálné: výrobci uvádějí pokles o 50–75 % a laboratorní měření za řízených podmínek vidí RTT Wi-Fi 7 s MLO v rozmezí 1,5–4 ms proti 3–6 ms u Wi-Fi 6E. Hodnoty pod jednu milisekundu se občas objevují v marketingu, ale na robotickém hardwaru je nikdo nezopakoval.

Háček je v rádiu robota. V polovině roku 2026 se hlavní humanoidní platformy (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) dodávají s Wi-Fi 6 nebo 6E. Žádná z nich v základní výbavě Wi-Fi 7 neuvádí. Postavit Wi-Fi 7 AP před robota s 6E znamená mít Wi-Fi 7 backhaul a 6E spoj k robotovi — což je v pořádku, ale platíte za schopnost, kterou zatím nevyužijete.

Kdy začne Wi-Fi 7 pro roboty hrát roli:

• Až bude robot standardně dodáván s modulem Wi-Fi 7 (očekáváme u platforem z roku 2027).
• Až MLO dokáže replikovat řídicí tok současně přes 5 GHz i 6 GHz a zabít tak výpadky v jednom pásmu.
• Až budete nasazovat flotilu natolik velkou, že úzkým hrdlem bude zahlcení jediného pásma bez ohledu na latenci.

Pro laboratoř s jedním robotem v roce 2026: 6E stačí. Pro flotilu plánovanou od roku 2027 dál: specifikujte AP rovnou jako Wi-Fi 7, ať síť za osmnáct měsíců nekupujete znovu.

Rozmístění a hustota AP

Instinkt velí pověsit jeden AP na strop do rohu místnosti. Výsledkem je půlmetrová hluchá zóna za laboratorním stolem, kde robot ztratí signál přesně během dema, které jste si naplánovali.

Pravidla, která fungují:

Přímá viditelnost je důležitější než vysílací výkon. AP s 30 dBm za ocelovým rackem doručí horší signál než AP s 20 dBm pověšený na stropě uprostřed místnosti. Roboti jsou nízcí — anténa na hrudi ve výšce 1,2 m vidí jiné RF prostředí než notebook na stole v 0,7 m a horší než telefon v 1,5 m. AP nad 2,5 m, roboti pod 1,5 m a žádné překážky velikosti člověka v dominantní dráze.

Vyhrazené SSID pro robotiku. Nediskutovatelné. SSID pro roboty má vlastní VLAN, vlastní QoS profil, vlastní rozsah DHCP a žádný uživatelský provoz. Robot na firemní Wi-Fi funguje ve vývoji asi týden — pak se marketingová stážistka připojí k videohovoru a robot spadne.

Stínění tělem — problém antény

Trup humanoida je ocelovo-plastová krabice zhruba 30 cm široká. Anténa rádia obvykle sídlí někde uvnitř hrudního panelu, často vzadu nebo na boku. Když se robot od AP odvrátí, stane se z jeho těla částečná Faradayova klec.

Ztráta síly signálu je typicky 6–15 dB podle umístění antény a podílu kovu v hrudi. To stačí k tomu, aby se hraniční spoj pouhým otočením překlopil z „funguje bez problémů" na „každých pár sekund vypadává". Čtyřnozí roboti trpí méně, protože jsou nižší a plošší a anténa bývá na hraně šasi s čistším výhledem vzhůru.

Co pomáhá:

• Anténa na hlavě nebo ramenou, ne na hrudi. Některé humanoidy pro výzkum umožňují anténu přemístit nebo přidat externí. Většina spotřebitelských modelů ne. Pokud je spolehlivost rádia podmínkou nasazení, zeptejte se před nákupem.
• Dva AP s diverzitou. S AP na protilehlých stěnách je robot „čelem" k jednomu z nich bez ohledu na natočení. Přepnutí řeší roaming — špatně, ale pořád lépe než žádný signál.
• Níže umístěné antény na straně AP. Pokud máte AP na stropě ve 3 m a anténa robota je v 1,0 m, je elevační úhel tak strmý, že hruď blokuje velkou část dráhy. AP na stěně ve 2 m dávají plošší a snazší cestu.

Kabel: jak to skutečně dělají seriózní týmy

Každý seriózní robotický tým má kabel. Většina o něm nemluví, protože kazí estetiku dema ve stylu „podívej, bez drátů". Kdokoli dělá reálnou integraci, robota připojí.

Tím kabelem je USB-C, ethernetový kabel M12 X-code nebo u výzkumných jednotek kroucená pupeční šňůra vedoucí napájení i data zároveň. Propustnost 1 Gbps a více; latence je pod jednu milisekundu obousměrně, často pod 200 µs. To je o dva řády lepší než ten nejlepší Wi-Fi spoj.

Důvodem, proč se při vývoji připojujete kabelem, není propustnost; je to odstranění jedné proměnné. Když Wi-Fi zlobí, nepoznáte, jestli je pomalý Váš ROS 2 uzel, pomalý model, nebo zkažený éter. Zapojte kabel a éter zmizí. Všechno ostatní se ladí snáz.

Unitree G1 EDU i Booster T1 mají pro připojení kabelem věrohodné řešení. H1 se připojuje kabelem nepohodlně. PM01 a SE01 podporují vývojové připojení přes standardní USB-C nebo Ethernet. Čtyřnozí roboti (Go2) se kabelem připojují zřídka, protože se počítá s venkovním nasazením; pokud na nich ale děláte seriózní RL práci uvnitř, stejně se to vyplatí.

Privátní 5G sítě: kdy se vyplatí

Privátní 5G — vlastní licencovaná nebo sdílená mobilní síť na pozemku firmy — se dostalo do kategorie „reálný produkt" v roce 2025 a v roce 2026 se nasazuje ve velkém. Technologie funguje.

Kdy privátní 5G dává smysl:

• Velké venkovní areály. Areály o mnoha hektarech, doly, rozsáhlé zemědělství, přístavy. Wi-Fi buňky se sem neškálují; počet AP a náročnost měření převýší cenu jedné sítě s malými buňkami.
• Kampusy s více budovami. Jakmile se robot musí přesouvat zevnitř ven a zpět nebo mezi budovami, roaming Wi-Fi začne být ošklivý. 5G mobilitu zvládá nativně.
• Nasazení postavená na mobilitě. Inspekční roboti ujíždějící kilometry, autonomní mobilní roboti ve velkých skladech, zkrátka cokoli, kde rádiový spoj musí jednotku následovat napříč terénem.
• Smíšená flotila s dalšími 5G prvky. Pokud už areál má privátní 5G pro vysokozdvižné vozíky, AGV nebo senzorové sítě, přidání robotů je jen přírůstkový náklad, ne nový projekt.

Kdy je to zbytečné:

• Jedna laboratoř, jedna budova, jeden až čtyři roboti. Wi-Fi 6E to zvládne za €3–8 tis. v AP. Privátní 5G to zvládne za €60–200 tis. v malých buňkách, EPC/5GC, licencích na spektrum a vztahu s dodavatelem. Ten poměr nesedí.
• Čistě vývojová prostředí. Kabel plus Wi-Fi Vám dá všechno, co by dalo 5G, a nic navíc ke správě.
• Nemáte síťový tým. Privátní 5G není „nastavit a zapomenout". Je to další produkční systém, který se musí provozovat, monitorovat a aktualizovat.

Rozpočet na latenci: co který workload přežije

Vzorec je jasný: uzavřené smyčky patří lokálně nebo na kabel, vnímání s uvažováním snese Wi-Fi, konverzace snese i WAN. Architektonickou chybou je posadit kód sousedící s motorovou smyčkou na cestu, kterou může zasáhnout síťový jitter. Druhou chybou je platit za přenos s 5 ms, když latence modelu je 400 ms — ušetřili jste 30 ms ze 430 ms celkem. Optimalizujte dominantní člen.

Vzorec „jednou nohou vždycky v cloudu"

I při tvrdě on-prem nasazení bývá robot jen zřídka úplně odstřižený od sítě. Co legitimně chce WAN:

• Telemetrie do vlastního monitorovacího stacku (Prometheus / Grafana / Datadog). Užitečná, nenáročná na pásmo, přežije jakékoli RTT.
• Aktualizace modelů a firmwaru. Stahování nových vah VLM, kontejnerových obrazů, záplat OS. Nárazové, dá se dělat v noci.
• Mapy a data o prostředí. Půdorys, synchronizace mračen bodů, záloha paměti scény.
• Záložní vzdálená teleoperace. Někdy; po bezpečnostním posouzení.

Vzorec zní: on-prem na prvním místě pro horkou cestu, odchozí WAN za firewallem pro studenou cestu. Robot nikdy nepotřebuje příchozí WAN adresu. Server ji nepotřebuje také. Pouze odchozí spojení, povolené cíle ze seznamu, TLS, žádné výjimky.

Multicast, mDNS, DDS — a proč to na Wi-Fi bolí

ROS 2 se dodává s DDS jako výchozím middlewarem. DDS používá k objevování účastníků IP multicast. Wi-Fi vysílá multicast nejnižší společnou rychlostí ke všem klientům daného BSSID, což:

1. Plýtvá vysílacím časem.
2. Vypadá pro firmware AP jako záplava.
3. Často končí zahozením na firemních AP, které mají zapnuté potlačení multicastu.

Výsledkem je „moje ROS 2 uzly se vidí po Ethernetu, ale ne po Wi-Fi" — dobře zdokumentovaná a naprosto zbytečná porucha. Naměřená ztrátovost multicastového ROS 2 provozu na Wi-Fi se pohybuje kolem 1–3 % i na zdravém spoji; na Ethernetu je nulová. Dva ROS 2 roboti na jedné Wi-Fi dokážou spustit discovery bouři, která rozhodí celý AP.

Opravy v pořadí podle doporučení:

1. Použijte Fast-DDS Discovery Server. Spusťte discovery server (typicky na inferenčním serveru nebo na vyhrazeném VM), nasměrujte na něj všechny ROS 2 uzly přes unicast a z objevování se stane běžný klient-server provoz, který Wi-Fi zvládá bez potíží.
2. Statická konfigurace peerů přes XML profil. Natvrdo zadaná IP protistrany. Křehké, ale pro pevnou dvojici to funguje.
3. Zapněte IGMP snooping a převod multicastu na unicast na AP. Aruba, Ruckus, Cisco Meraki i novější firmware UniFi to podporují. Řekněte to síťaři; jsou to dvě zaškrtávací políčka.
4. Změňte implementaci RMW. Někteří uživatelé přecházejí z Cyclone DDS na Fast-DDS nebo na Zenoh-bridge právě proto, aby unikli sémantice multicastového discovery. Poslední možnost; znamená to integrační náklady.

QoS, DSCP a jak si zajistit prioritu

SSID pro roboty má vlastní VLAN; VLAN má vlastní QoS profil. Další vrstvou je zajistit, aby se síť shodla na tom, že robotí provoz je důležitější než synchronizace Dropboxu marketingového oddělení.

Standardní postup:

• Řídicí provoz robota označte DSCP jako EF (Expedited Forwarding, DSCP 46). Řídicí tok je malý a kritický na latenci; EF je pro něj učebnicová třída.
• Obrazové toky označte AF41 (DSCP 34). Video v reálném čase, vysoká propustnost, nižší priorita než řízení.
• Telemetrii a stahování modelů nechte na výchozím (DSCP 0). Žádné zvláštní zacházení.
• Mapování WMM na AP musí značky respektovat. Většina firemních AP (Aruba, Cisco Meraki, Ruckus) to při zapnutém DSCP-trust dělá automaticky. UniFi vyžaduje v novějším firmwaru explicitní nastavení.

Konkrétní síťová architektura pro robotickou laboratoř

Funkční sestava pro laboratoř s 1–4 roboty, kalibrovaná na hardwarovou realitu z I01:

Referenční síť laboratoře: roboti → vyhrazené 6GHz AP → 10GbE switch → AI server Kentino. Výstup do internetu za firewallem, pouze odchozí.

Pro 1–4 roboty v jedné místnosti vyjde taková sestava na €4–12 tis. za síťové prvky podle třídy dodavatele. Ruckus a Aruba zvládají RF nejlépe v hustém nebo nepřátelském prostředí. Cisco Meraki vyhrává jednoduchostí za cenu opakovaných poplatků. UniFi vyhrává cenou a pro práci v jedné laboratoři bohatě stačí.

Poruchy zhruba v pořadí, v jakém Vás potkají

• Roaming mezi AP zabije spojení. Robot překročí hranici buňky, asociace na 100–400 ms vypadne, ROS 2 socket se zotaví, ale v logu zůstane díra v řídicím toku. Řešením je překryv buněk, rychlý roaming 802.11k/v/r a hlavně to nespoléhat se na síť u řízení v uzavřené smyčce.
• Rušení mezi roboty na sdílených kanálech. Tři G1 na stejném 6GHz kanálu si navzájem šlapou po vysílacím čase. Naplánujte nepřekrývající se 80MHz kanály v pásmu 6 GHz (v EU jich je sedm, v USA více).
• Konstrukce budovy. Železobetonové stěny uberou 20–30 dB. Ocelové dveře serverovny 40 dB. RF site survey vždy, než AP pověsíte.
• Vypršení DHCP zápůjčky uprostřed úlohy. Dlouho běžící sezení robota, obnovení DHCP selže, IP se změní, sockety se rozpadnou. Statická rezervace DHCP pro robota. Vždycky.
• Úsporné režimy. Úsporný režim Wi-Fi v rádiu robota přidává latenci výměnou za výdrž baterie. Vypněte ho explicitně. Výdrž je problém baterie; neplaťte za ni jitterem.
• Nesoulad MTU. SDK výrobce robota používá 1500, Vaše síť 9000, dochází k fragmentaci a výkon se tiše sesype. Sjednoťte MTU po celé trase.

Poctivé shrnutí

Nejužitečnější věta celého článku: 95 % „problémů s robotem" hlášených v prvním měsíci nasazení jsou problémy s konfigurací Wi-Fi. Robot je v pořádku. Model je v pořádku. Wi-Fi v pořádku není, SSID je sdílené s kanceláří, chybí vyhrazená VLAN, multicast se valí všude, AP visí na špatných místech a integrátor tři týdny ladí úplně jinou vrstvu.

Najměte si síťaře včas. Zaplaťte mu víc, než si myslíte. Zkušený síťový inženýr, který umí navrhnout plán Wi-Fi 6E, nastavit QoS po celé trase a vyladit DDS discovery, má na tomto projektu stejnou cenu jako zkušený robotik — a sehnat ho je mnohem těžší.

---

Tento text je součástí Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.