Robotnetværk: Wi-Fi, tethers, 5G og hvorfor latenstid er vigtig

En humanoid er en mobil node på et netværk, der næsten helt sikkert er designet til bærbare computere, der sidder stille. Denne uoverensstemmelse er kilden til cirka 95% af de "robotten er mærkelig i dag"-sager, du nogensinde vil indgive. Motorstyringerne er fine. Jetson'en er fin. Modellen på K-AI-serveren er fin. Wi-Fi'en er ikke fin.

Denne artikel handler om anden halvdel af I01s billede med to bokse — specifikt linket i midten. Den robot, du har købt, er kun så god som det netværk, du har sat den på, og det netværk, du har sat den på, skal sandsynligvis genopbygges, før den fortjener ordet "fin".

Målgruppe: integratorer, laboratorieledere og IT-teams, der har fået at vide, at en humanoid ankommer næste måned, og som endnu ikke har fattet, at det eksisterende virksomheds-Wi-Fi vil bringe alle i forlegenhed.

Hvorfor robotnetværk er sit eget problem

Det meste Wi-Fi-netværk i virksomheder er dimensioneret til trafikmønstre i menneskelig skala: downloads med høj hastighed, lejlighedsvise videoopkald og lange perioder med inaktivitet. En humanoid gør ingen af ​​disse ting. Den genererer en kontinuerlig duplexstrøm af lavhastighedskontrolbeskeder, intermitterende udbrud af billeddata på vej til inferensserveren og en jævn strøm af telemetri. Kontrolstrømmen er lille (kilobyte pr. sekund), men patologisk jitterfølsom. Billedudbrudene er fede (tiere til hundredvis af megabyte pr. sekund i råformat) og kræver en fed sti. Telemetri er tilgivende og keder alle.

Hvad gør problemet unikt:

• Knuden bevæger sig. Robotten går over cellegrænsen mellem adgangspunkter, og roaminghændelsen taber pakker i 50-500 ms afhængigt af, hvordan netværket er konfigureret. En bærbar computers bruger bemærker det ikke. En robots balancecontroller kan muligvis.
• RF er fjendtlig. Et 30 m² laboratorium med to teknikere, tre bærbare computere, en espressomaskine med Wi-Fi og en mikrobølgeovn er et helt normalt RF-miljø, der absolut vil ødelægge et 5 GHz robotlink. Kropsskygger fra selve robotten blokerer signalet i uforudsigelige retninger, når den drejer.
• Multi-robot interferensforbindelser. To G1'ere i samme rum på samme kanal vil ikke samarbejde problemfrit. Tre er et problem. En flåde på otte kræver grundig planlægning.
• Protokollerne over radioen er også skrøbelige. ROS 2's standard DDS-konfiguration er afhængig af IP-multicast til registrering. Wi-Fi håndterer multicast dårligt. Kombinationen producerer "noderne kan ikke se hinanden"-tickets, der ligner robotfejl.

Dette kan løses. Intet af det er løst som standard.

Wi-Fi 6E: den nuværende etage

Det ærlige udgangspunkt for en robotbaseret Wi-Fi-implementering i 2026 er Wi-Fi 6E med en dedikeret 6 GHz SSID kun til robotterneIkke Wi-Fi 6. Ikke 5 GHz. "Det fikser vi senere." 6E, 6 GHz, separat SSID, isoleret VLAN.

Årsagen er RF-renhed, ikke headline-gennemstrømning. 6 GHz-båndet er nyt nok til, at det ikke er blevet oversvømmet af forbrugerskrot endnu. Der er ingen Bluetooth på 6 GHz, ingen mikrobølgeovnsharmoniske signaler, ingen 15 år gamle printere, der sender beacons. Din robots radio får en ren kanal. Den rene kanal er mere værd end nogen forbedring på specifikationsbladet.

Sådan ser en rigtig Wi-Fi 6E-robots RTT ud, målt fra robottens CPU til inferensserveren på den kabelforbundne side af adgangspunktet:

En ren 6 GHz-forbindelse leverer en RTT på et enkeltcifret millisekund, der er konsekvent nok til, at ROS 2-noder, gRPC-klienter til vLLM og teleop føles responsive. Den samme robot, der flyttes til et delt 5 GHz SSID, vil føles "laggy" på en måde, som ingen kan sætte et tal på, før de måler.

Wi-Fi 7 i 2026: begrænset understøttelse, ægte løfte

Wi-Fi 7's hovedfunktion er Multi-Link Operation (MLO) – radioen binder to eller tre bånd (2.4/5/6 GHz) samtidigt og enten aggregerer dataoverførslen eller replikerer pakker på tværs af links for pålidelighed. Latensreduktionen i Wi-Fi 7 vs. 6E er reel, hvor MLO er aktiveret: leverandører angiver latensfald på 50-75%, og benchmålinger under kontrollerede forhold viser Wi-Fi 7 MLO RTT i området 1.5-4 ms vs. 3-6 ms på Wi-Fi 6E. Sub-millisekunder hævdes lejlighedsvis i markedsføring, hvilket ikke er blevet reproduceret på robothardware.

Fangsten er robotradioenFra midten af ​​2026 leveres almindelige humanoide platforme (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) med Wi-Fi 6 eller 6E. Ingen af ​​dem reklamerer for Wi-Fi 7 på basis-SKU'en. Hvis du placerer et Wi-Fi 7 AP foran en Wi-Fi 6E-robot, får du en Wi-Fi 7 backhaul og et 6E-robotlink – fint, men du betaler for funktioner, du ikke kan bruge endnu.

Når Wi-Fi 7 begynder at betyde noget for robotter:

• Når robotten leveres med et Wi-Fi 7-modul som standard (forventes på 2027-platforme).
• Når MLO kan replikere kontrolplanets pakkestrøm på tværs af 5 GHz og 6 GHz samtidigt, hvilket dræber enkeltbånds-fade-hændelser.
• Når du implementerer en flåde, der er stor nok til, at overbelastning på et enkelt bånd er flaskehalsen, uanset latenstid.

For et laboratorium med én robot i 2026: 6E er nok. For en flådeopbygning planlagt til 2027 og fremefter: Specificér adgangspunkterne som Wi-Fi 7 i dag, så du ikke genkøber netværket om atten måneder.

AP-placering og -tæthed

Instinktet er at montere et AP i loftet i hjørnet af rummet. Resultatet er en halv meter død zone bag laboratoriebordet, hvor robotten mister signal under præcis den demonstration, du havde planlagt.

Tommelfingerregler der virker:

Synslinje er bedre end strøm. Et 30 dBm AP bag et stålstativ leverer et dårligere signal end et 20 dBm AP monteret i loftet midt i rummet. Robotter er korte – en brystmonteret antenne på 1.2 m ser et andet RF-miljø end en bærbar computer på et skrivebord på 0.7 m, og dårligere end en telefon på 1.5 m. AP'er over 2.5 m, robotter under 1.5 m, ingen forhindringer på størrelse med mennesker i den dominerende rute.

Dedikeret robot-SSID. Ikke til forhandling. Robottens SSID har sit eget VLAN, sin egen QoS-profil, sit eget DHCP-scope og ingen forbrugertrafik. Robotten blandes med medarbejdernes Wi-Fi og arbejder under udvikling i en uge, hvorefter en marketingpraktikant deltager i et videoopkald, og robotten falder omkuld.

Kropsskygging — antenneproblemet

En humanoids torso er en stål- og plastikkasse, der er omkring 30 cm bred. Radioantennen sidder typisk et sted inde i brystpladen, ofte på bagsiden eller den ene side. Når robotten vender sig væk fra adgangspunktet, bliver kroppen til et delvist Faraday-skjold.

Signalstyrketab er typisk 6-15 dB afhængigt af antennens placering og brystkassens metalindhold. Det er nok til at ændre et marginalt link fra "fungerer fint" til "falder hvert par sekunder" udelukkende ved rotation. Firbenede dyr lider mindre, fordi de er lavere og fladere, og antennen er normalt placeret på en chassiskant med renere udsyn til himlen.

Hvad hjælper:

• Antenne på hovedet eller skuldrene, ikke brystet. Nogle humanoider på forskningsniveau giver dig mulighed for at flytte eller tilføje en ekstern antenne. Det gør de fleste enheder på forbrugerniveau ikke. Spørg inden køb, om RF-pålidelighed er et krav til implementering.
• To AP'er med diversitet. Med AP'er på modsatte vægge er robotten "foran" en af ​​dem uanset retning. AP-roamingen håndterer kontakten – dårligt, men bedre end intet signal.
• Nederste antenner på AP-siden. Hvis dine AP'er er loftmonteret i 3 m afstand, og robotantennen er i 1.0 m afstand, er elevationsvinklen stejl nok til, at brystkassen blokerer en stor del af vejen. Vægmonterede AP'er i 2 m afstand får en fladere og nemmere vej.

Tråden: hvordan seriøse teams udvikler sig

Alle seriøse robotteams har en ledning. De fleste taler aldrig om det, fordi det ødelægger demo-æstetikken med "se dig, mand, ingen ledninger". Enhver, der laver rigtigt integrationsarbejde, tilslutter robotten.

Kabelforbindelsen er et USB-C-kabel, et M12 X-code Ethernet-kabel eller i forskningsenheder en spiralformet navlestreng, der bærer strøm og data sammen. Båndbredden er 1 Gbps eller højere; latenstiden er rundtur på under et millisekund, ofte under 200 µs. Det er to størrelsesordener bedre end det bedste Wi-Fi-link.

Grunden til, at du tetherer under udvikling, er ikke båndbredden; det er elimineringen af ​​variablen. Når Wi-Fi'en er ustabil, kan du ikke se, om din ROS 2-node er langsom, modellen er langsom, eller om internettet er dårligt. Sæt stikket i, og der er ingen internet. Alt andet bliver lettere at debugge.

Både Unitree G1 EDU og Booster T1 har troværdige tether-historier. H1 er besværlig at tethere. PM01 og SE01 understøtter udviklingstethering via standard USB-C eller Ethernet. Firbenede dyr (Go2) er sjældent tetheret, fordi brugen er udendørs; hvis du laver seriøst indendørs RL-arbejde på en, vil du måske alligevel gøre det.

5G private netværk: når det er det værd

Privat 5G – dit eget licenserede eller delte mobilnetværk på stedet – trådte ind i "rigtigt produkt"-territorium i 2025 og leveres i stor skala i 2026. Teknologien virker.

Når privat 5G giver mening:

• Store udendørs pladser. Anlæg på flere hektar, minedrift, stor landbrug, havne. Wi-Fi-celler kan ikke skaleres her; antallet af adgangspunkter og undersøgelsesindsatsen overstiger omkostningerne ved et enkelt 5G-netværk med små celler.
• Campusser med flere bygninger. Når robotten skal bevæge sig fra indendørs til udendørs og tilbage, eller mellem bygninger, bliver Wi-Fi-roaming grimt. 5G håndterer mobilitet indbygget.
• Mobilitetsførste implementeringer. Inspektionsrobotter, der tilbagelægger kilometervis, autonome mobile robotter i store lagre, alt hvor radioforbindelsen skal følge enheden på tværs af geografi.
• Blandet flåde med andre 5G-aktiver. Hvis stedet allerede har privat 5G til gaffeltrucks, AGV'er eller sensornetværk, er tilføjelsen af ​​robotter en ekstra omkostning og ikke et nyt projekt.

Når det er overdrevet:

• Enkelt laboratorium, enkelt bygning, en til fire robotter. Wi-Fi 6E klarer dette job for AP'er til en værdi af 3-8 euro. Privat 5G klarer det for små celler, EPC/5GC, spektrumlicenser og et leverandørforhold til en værdi af 60-200 euro. Forholdet er forkert.
• Rene udviklingsmiljøer. Tether plus Wi-Fi giver dig alt, hvad 5G ville tilbyde, og intet ekstra at administrere.
• Du har ikke et netværksteam. Privat 5G er ikke noget, man bare "indstiller og glemmer". Det er et ekstra produktionssystem, der skal betjenes, overvåges og opdateres.

Latensbudgettet: hvilke arbejdsbelastninger overlever hvad

Mønsteret er tydeligt: ​​closed-loop-arbejde foregår lokalt eller tethered, perception med tænkning kan tage Wi-Fi, samtale kan tage WAN. Den arkitektoniske fejl er at placere motor-loop-tilstødende kode på en sti, der kan ramme netværksjitter. Den anden fejl er at betale for 5 ms transport, når modellens latenstid er 400 ms - du sparede 30 ms på en total på 430 ms. Optimer det dominerende led.

Mønsteret "altid med én fod i skyen"

Selv ved en hård on-prem implementering er robotten sjældent fuldstændigt luftgap-baseret. Ting, der legitimt ønsker WAN:

• Telemetri til din egen overvågningsstak (Prometheus / Grafana / Datadog). Nyttig, lav båndbredde, kan overleve enhver RTT.
• Model- og firmwareopdateringer. Udtrækning af nye VLM-vægte, containerbilleder, OS-patches. Bursty, kan udføres om natten.
• Kort- og miljødata. Plantegning, punktskysynkronisering, backup af scenehukommelse.
• Fjernbetjent teleop-fallback. Nogle gange; med forbehold for sikkerhedsgennemgang.

Mønsteret er on-prem-first for den varme sti, WAN-udgang firewallbeskyttet for den kolde sti. Robotten behøver aldrig en indgående WAN-adresse. Serveren behøver heller ikke en indgående WAN-adresse. Kun udgående, tilladte destinationer, TLS, ingen undtagelser.

Multicast, mDNS, DDS — og hvorfor Wi-Fi skader dem

ROS 2 leveres med DDS som standard middleware. DDS bruger IP multicast til deltagerregistrering. Wi-Fi håndterer multicast ved at sende med den laveste fælles hastighed til alle klienter på BSSID'et, hvilket:

1. Spilder sendetid.
2. Det ser ud til, at AP-firmwaren er blevet oversvømmet.
3. Bliver ofte tabt af virksomheds-AP'er med multicast-undertrykkelse slået til.

Resultatet er "mine ROS 2-noder kan se hinanden på Ethernet, men ikke på Wi-Fi" - en veldokumenteret og fuldstændig undgåelig fejl. Målt Wi-Fi-pakketab for multicast ROS 2-trafik ligger på 1-3%, selv på sunde forbindelser; Ethernet ligger på nul. To ROS 2-robotter på det samme Wi-Fi kan forårsage opdagelsesstorme, der destabiliserer adgangspunktet.

Rettelserne, i prioriteret rækkefølge:

1. Brug Fast-DDS Discovery Server. Kør en discovery-server (typisk på inferensserveren eller en dedikeret VM), peg alle ROS 2-noder mod den via unicast, og discovery bliver et normalt klient-server-flow, som Wi-Fi håndterer fint.
2. Statisk peer-konfiguration via XML-profil. Hardkode IP'en på den anden side. Skrøbelig, men virker med et fast par.
3. Aktivér IGMP snooping og multicast-til-unicast-konvertering på AP'et. Aruba, Ruckus, Cisco Meraki og nyere UniFi-firmware understøtter alle dette. Fortæl netværksingeniøren, at det er to afkrydsningsfelter.
4. Implementering af RMW-skift. Nogle brugere skifter fra Cyclone DDS til Fast-DDS eller til Zenoh-bridge specifikt for at undgå semantikken ved multicast-opdagelse. Sidste udvej; det er en integrationsomkostning.

QoS, DSCP og prioritering

Robottens SSID har sit eget VLAN; VLAN'et har sin egen QoS-profil. Det næste lag er at sikre, at netværket accepterer, at robottrafik er vigtigere end marketingteamets Dropbox-synkronisering.

Standardmønster:

• DSCP-mærk robotstyringstrafik som EF (Expedited Forwarding, DSCP 46). Kontrolplanstrømmen er lille og latenstidskritisk; EF er lærebogsklassen til den.
• Billedstrømme markeret AF41 (DSCP 34). Video i realtid, høj kapacitet, lavere prioritet end kontrol.
• Telemetri- og modelhentninger markeret som standard (DSCP 0). Ingen særlig behandling.
• AP WMM-kortlægning skal respektere markeringerne. De fleste enterprise AP'er (Aruba, Cisco Meraki, Ruckus) gør dette automatisk, når DSCP-trust er aktiveret. UniFi kræver eksplicit konfiguration i den seneste firmware.

Konkret netværksarkitektur til et robotlaboratorium

En fungerende model til et robotlaboratorium med 1-4 robotter, kalibreret til I01 hardware-virkelighed:

Referencelaboratorienetværk: robotter → 6 GHz dedikerede AP'er → 10 GbE switch → K-AI server. Udgående firewall, kun udgående.

For 1-4 robotter i et enkelt rum ender denne build på €4-12 netværksudstyr afhængigt af leverandørniveau. Ruckus og Aruba klarer sig bedst med RF i tætte eller fjendtlige miljøer. Cisco Meraki vinder på enkelhed til en tilbagevendende omkostningstab. UniFi vinder på pris og er fin til arbejde i et enkelt laboratorium.

Fejltilstande, omtrent i den rækkefølge de vil bide

• AP-roaming ødelægger et flow. Robot krydser cellegrænsen, associationen falder i 100-400 ms, ROS 2-socket genoprettes, men der opstår et gab i kontrolstrømmen i loggene. Reducer problemet med overlappende celler, 802.11k/v/r hurtig roaming og ikke at være afhængig af netværket til closed-loop-kontrol i første omgang.
• Interferens fra flere robotter på delte kanaler. Tre G1'ere på den samme 6 GHz-kanal går på hinandens sendetid. Planlæg ikke-overlappende 80 MHz-kanaler i 6 GHz (der er syv i EU, flere i USA).
• Bygningsstruktur. Armerede betonvægge falder med 20-30 dB. Ståldøre i serverrum falder med 40 dB. Undersøg RF-stedet, før du monterer AP'er, hver gang.
• DHCP-lease udløber midt i opgaven. Langvarig robotsession, DHCP-fornyelse mislykkes, IP-ændringer, sockets afbrydes. Statiske DHCP-reservationer for robotten. Altid.
• Strømsparetilstande. Wi-Fi-strømbesparelse på robotradioen øger latenstid for at forlænge batterilevetiden. Deaktiver eksplicit. Batterilevetiden er et batteriproblem; betal ikke for det i jitter.
• MTU-uoverensstemmelse. Robotleverandørens SDK bruger 1500, din struktur bruger 9000, fragmentering sker, ydeevnen kollapser lydløst. Match MTU'en end-to-end.

Den ærlige holdning

Den absolut mest brugbare sætning i denne artikel: 95 % af de "robotproblemer", der rapporteres i den første måned efter implementeringen, er problemer med Wi-Fi-konfigurationen. Robotten er fin. Modellen er fin. Wi-Fi'en er ikke fin, SSID'et deles med kontoret, der er intet dedikeret VLAN, multicast er udbredt, AP'erne er på det forkerte sted, og integratoren fejlfinder det forkerte lag i tre uger.

Ansæt netværkspersonen tidligt. Betal dem mere, end du tror. Den erfarne netværksingeniør, der kan udarbejde en Wi-Fi 6E-plan, konfigurere QoS end-to-end og finjustere DDS-registreringen, er det samme værd som en erfaren robottekniker på dette projekt og er meget sværere at finde.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.