Roboter-Vernetzung: WLAN, Kabel, 5G – und warum Latenz zählt

Ein Humanoid ist ein mobiler Knoten in einem Netzwerk, das fast sicher für stillstehende Laptops ausgelegt wurde. Diese Diskrepanz ist die Ursache für rund 95 % aller Tickets nach dem Muster „der Roboter ist heute komisch“, die Sie je schreiben werden. Die Motorcontroller sind in Ordnung. Der Jetson ist in Ordnung. Das Modell auf dem Kentino KI-Server ist in Ordnung. Das WLAN ist nicht in Ordnung.

Dieser Beitrag widmet sich der zweiten Hälfte des Zwei-Kästen-Bildes aus I01– genauer gesagt der Verbindung dazwischen. Der Roboter, den Sie gekauft haben, ist nur so gut wie das Netzwerk, in das Sie ihn stellen. Und dieses Netzwerk muss vermutlich erst umgebaut werden, bevor es das Wort „in Ordnung“ verdient.

Zielgruppe: Integratoren, Laborleitungen und IT-Teams, denen man gesagt hat, dass nächsten Monat ein Humanoid eintrifft, und die noch nicht verinnerlicht haben, dass das bestehende Firmen-WLAN alle Beteiligten blamieren wird.

Warum Roboter-Netzwerke ein Problem für sich sind

Die meisten Unternehmens-WLANs sind auf menschliche Verkehrsmuster ausgelegt: stoßweise Downloads, gelegentliche Videocalls, lange Leerlaufphasen. Ein Humanoid macht nichts davon. Er erzeugt einen durchgehenden bidirektionalen Strom kleiner Steuernachrichten, zwischendurch Schübe von Bilddaten Richtung Inferenzserver und ein stetiges Rinnsal an Telemetrie. Der Steuerstrom ist klein (Kilobyte pro Sekunde), reagiert aber krankhaft empfindlich auf Jitter. Die Bildschübe sind fett (zweistellige bis dreistellige Megabyte pro Sekunde im Rohformat) und brauchen einen fetten Pfad. Telemetrie ist gutmütig und langweilt alle.

Was dieses Problem besonders macht:

• Der Knoten bewegt sich. Der Roboter läuft über die Zellgrenze zwischen zwei Access Points, und das Roaming-Ereignis verwirft je nach Netzwerkkonfiguration für 50–500 ms Pakete. Der Nutzer eines Laptops merkt das nicht. Der Gleichgewichtsregler eines Roboters womöglich schon.
• Die Funkumgebung ist feindlich. Ein 30 m² großes Labor mit zwei Ingenieuren, drei Laptops, einer Espressomaschine mit WLAN und einem Mikrowellenherd ist eine vollkommen normale Funkumgebung – und sie zerlegt eine 5-GHz-Roboterverbindung zuverlässig. Die Abschattung durch den Roboterkörper selbst blockiert das Signal beim Drehen in unvorhersehbare Richtungen.
• Störungen zwischen mehreren Robotern verstärken sich. Zwei G1 im selben Raum auf demselben Kanal vertragen sich nicht elegant. Drei sind ein Problem. Eine Flotte von acht braucht echte Planung.
• Auch die Protokolle oberhalb des Funks sind fragil. Die Standard-DDS-Konfiguration von ROS 2 nutzt IP-Multicast für die Discovery. WLAN geht mit Multicast schlecht um. Die Kombination erzeugt Tickets nach dem Muster „die Nodes sehen sich nicht“, die wie Roboterfehler aussehen.

Das ist alles lösbar. Gelöst ist davon standardmäßig nichts.

Wi-Fi 6E: die heutige Untergrenze

Der ehrliche Ausgangspunkt für ein Robotik-WLAN im Jahr 2026 ist Wi-Fi 6E mit einer eigenen 6-GHz-SSID ausschließlich für die Roboter. Nicht Wi-Fi 6. Kein 5 GHz nach dem Motto „das richten wir später“. 6E, 6 GHz, eigene SSID, isoliertes VLAN.

Der Grund ist die saubere Funkumgebung, nicht der Durchsatz auf dem Datenblatt. Das 6-GHz-Band ist neu genug, dass es der Consumer-Ramsch noch nicht geflutet hat. Auf 6 GHz gibt es kein Bluetooth, keine Oberwelle eines Mikrowellenherds, keinen 15 Jahre alten Drucker, der Beacons verschickt. Das Funkmodul Ihres Roboters bekommt einen sauberen Kanal. Dieser saubere Kanal ist mehr wert als jede Verbesserung auf dem Spezifikationsblatt.

So sehen realistische Wi-Fi-6E-Werte für die Round-Trip-Zeit eines Roboters aus, gemessen von der CPU des Roboters bis zum Inferenzserver auf der Kabelseite des Access Points:

Eine saubere 6-GHz-Verbindung liefert einstellige Millisekundenwerte konstant genug, dass sich ROS-2-Nodes, gRPC-Clients an vLLM und Teleoperation reaktionsschnell anfühlen. Derselbe Roboter an einer geteilten 5-GHz-SSID fühlt sich „träge“ an, auf eine Weise, die niemand beziffern kann, bevor gemessen wird.

Wi-Fi 7 im Jahr 2026: begrenzte Unterstützung, echtes Potenzial

Das Schlüsselmerkmal von Wi-Fi 7 ist Multi-Link Operation (MLO): Das Funkmodul bündelt zwei oder drei Bänder (2.4/5/6 GHz) gleichzeitig und aggregiert entweder den Durchsatz oder dupliziert Pakete über mehrere Verbindungen, um die Zuverlässigkeit zu erhöhen. Die geringere Latenz von Wi-Fi 7 gegenüber 6E ist real, sofern MLO aktiv ist: Hersteller nennen 50–75 % weniger Latenz, und Messungen unter kontrollierten Bedingungen zeigen für Wi-Fi 7 mit MLO RTT-Werte von 1.5–4 ms gegenüber 3–6 ms bei Wi-Fi 6E. Im Marketing ist gelegentlich von unter einer Millisekunde die Rede – auf Roboterhardware ließ sich das nicht reproduzieren.

Der Haken ist das Funkmodul im Roboter. Mit Stand Mitte 2026 kommen die gängigen Humanoid-Plattformen (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) mit Wi-Fi 6 oder 6E. Keine davon bewirbt Wi-Fi 7 in der Basisausstattung. Ein Wi-Fi-7-Access-Point vor einem Wi-Fi-6E-Roboter bringt Ihnen ein Wi-Fi-7-Backhaul und eine 6E-Roboterverbindung – in Ordnung, aber Sie bezahlen für Fähigkeiten, die Sie noch nicht nutzen können.

Ab wann Wi-Fi 7 für Roboter relevant wird:

• Wenn der Roboter ab Werk ein Wi-Fi-7-Modul mitbringt (erwartet bei den Plattformen von 2027).
• Wenn MLO den Steuerdatenstrom gleichzeitig über 5 GHz und 6 GHz duplizieren kann und damit Einbrüche in einem einzelnen Band abfängt.
• Wenn Sie eine Flotte betreiben, die groß genug ist, dass die Überlastung eines einzelnen Bandes zum Engpass wird – unabhängig von der Latenz.

Für ein Labor mit einem Roboter im Jahr 2026 reicht 6E. Für einen Flottenaufbau ab 2027: Spezifizieren Sie die Access Points schon heute als Wi-Fi 7, damit Sie das Netzwerk nicht in achtzehn Monaten neu kaufen müssen.

Platzierung und Dichte der Access Points

Der erste Reflex ist, einen Access Point an der Zimmerecke unter die Decke zu schrauben. Das Ergebnis ist eine halbmeterbreite Funklücke hinter der Laborbank, in der der Roboter genau während der geplanten Vorführung das Signal verliert.

Bewährte Faustregeln:

Sichtverbindung schlägt Sendeleistung. Ein Access Point mit 30 dBm hinter einem Stahlrack liefert ein schlechteres Signal als einer mit 20 dBm mitten an der Decke. Roboter sind niedrig – eine Antenne auf Brusthöhe bei 1.2 m sieht eine andere Funkumgebung als ein Laptop auf dem Schreibtisch bei 0.7 m und eine schlechtere als ein Smartphone bei 1.5 m. Access Points über 2.5 m, Roboter unter 1.5 m, keine menschengroßen Hindernisse im Hauptpfad.

Eigene Robotik-SSID. Nicht verhandelbar. Die Roboter-SSID bekommt ein eigenes VLAN, ein eigenes QoS-Profil, einen eigenen DHCP-Bereich und keinerlei Consumer-Verkehr. Den Roboter im Mitarbeiter-WLAN mitlaufen zu lassen, funktioniert in der Entwicklung genau eine Woche – dann tritt ein Marketing-Praktikant einem Videocall bei und der Roboter fällt um.

Abschattung durch den Körper – das Antennenproblem

Der Rumpf eines Humanoiden ist ein Kasten aus Stahl und Kunststoff von rund 30 cm Breite. Die Funkantenne sitzt üblicherweise irgendwo hinter der Brustplatte, oft auf der Rückseite oder an einer Flanke. Dreht sich der Roboter vom Access Point weg, wirkt der Körper wie ein teilweiser Faradayscher Käfig.

Der Signalverlust liegt je nach Antennenposition und Metallanteil des Brustkorbs typischerweise bei 6–15 dB. Das genügt, um eine grenzwertige Verbindung allein durch eine Drehung von „läuft“ auf „bricht alle paar Sekunden ab“ kippen zu lassen. Vierbeiner leiden weniger, weil sie niedriger und flacher gebaut sind und die Antenne meist an einer Chassiskante mit freierem Blick nach oben sitzt.

Was hilft:

• Antenne am Kopf oder an den Schultern statt an der Brust. Einige Humanoide der Forschungsklasse lassen sich mit einer anderen oder zusätzlichen externen Antenne bestücken. Die meisten Consumer-Geräte nicht. Fragen Sie vor dem Kauf nach, wenn Funkzuverlässigkeit eine Anforderung ist.
• Zwei Access Points für Diversität. Mit Access Points an gegenüberliegenden Wänden steht der Roboter unabhängig von seiner Ausrichtung immer „vor“ einem davon. Das Roaming übernimmt den Wechsel – schlecht, aber besser als kein Signal.
• Niedrigere Antennen auf der Access-Point-Seite. Hängen Ihre Access Points bei 3 m an der Decke und sitzt die Roboterantenne bei 1.0 m, ist der Elevationswinkel so steil, dass der Brustkorb einen großen Teil des Pfades blockiert. Wandmontierte Access Points auf 2 m ergeben einen flacheren, einfacheren Pfad.

Die Kabelverbindung: so arbeiten ernsthafte Teams

Jedes ernsthafte Robotikteam hat ein Kabel. Die meisten reden nicht darüber, weil es die Ästhetik der kabellosen Vorführung verdirbt. Wer echte Integrationsarbeit leistet, steckt den Roboter an.

Die Verbindung ist ein USB-C-Kabel, ein M12-X-kodiertes Ethernet-Kabel oder – bei Geräten der Forschungsklasse – eine gewendelte Nabelschnur, die Strom und Daten gemeinsam führt. Die Bandbreite liegt bei 1 Gbps oder darüber, die Latenz bei unter einer Millisekunde im Roundtrip, oft unter 200 µs. Das ist zwei Größenordnungen besser als die beste WLAN-Verbindung.

Der Grund, während der Entwicklung mit Kabel zu arbeiten, ist nicht die Bandbreite, sondern das Ausschalten einer Variablen. Wenn das WLAN unzuverlässig ist, können Sie nicht sagen, ob Ihr ROS-2-Node langsam ist, das Modell langsam ist oder die Luft schlecht. Stecken Sie an, und es gibt keine Luft mehr. Alles andere lässt sich danach leichter debuggen.

Unitree G1 EDU und Booster T1 bringen beide belastbare Lösungen für den Kabelbetrieb mit. Der H1 lässt sich nur umständlich anbinden. PM01 und SE01 unterstützen den Entwicklungsbetrieb per Kabel über Standard-USB-C oder Ethernet. Vierbeiner (Go2) werden selten verkabelt, weil der Einsatz draußen stattfindet; wer damit ernsthaft im Innenbereich an Reinforcement Learning arbeitet, sollte es trotzdem erwägen.

Private 5G-Netze: wann sie sich lohnen

Privates 5G – ein eigenes lizenziertes oder gemeinsam genutztes Mobilfunknetz vor Ort – hat 2025 das Stadium eines echten Produkts erreicht und wird 2026 in großem Maßstab ausgeliefert. Die Technik funktioniert.

Wann privates 5G sinnvoll ist:

• Große Außengelände. Areale von mehreren Hektar, Bergwerke, großflächige Landwirtschaft, Häfen. WLAN-Zellen skalieren hier nicht; Anzahl der Access Points und Aufwand für die Ausleuchtung übersteigen die Kosten eines einzelnen 5G-Small-Cell-Netzes.
• Campus mit mehreren Gebäuden. Wenn der Roboter von drinnen nach draußen und zurück oder zwischen Gebäuden wechseln muss, wird WLAN-Roaming unschön. 5G beherrscht Mobilität von Haus aus.
• Einsätze, bei denen Mobilität im Vordergrund steht. Inspektionsroboter, die Kilometer zurücklegen, autonome mobile Roboter in großen Lagern – überall dort, wo die Funkverbindung der Einheit über größere Entfernungen folgen muss.
• Gemischte Flotten mit weiteren 5G-Geräten. Gibt es am Standort bereits privates 5G für Gabelstapler, fahrerlose Transportsysteme oder Sensornetze, sind Roboter nur noch ein zusätzlicher Kostenpunkt und kein neues Projekt.

Wann es übertrieben ist:

• Ein Labor, ein Gebäude, ein bis vier Roboter. Wi-Fi 6E erledigt das für 3–8 Tsd. € an Access Points. Privates 5G kostet 60–200 Tsd. € für Small Cells, EPC/5GC, Spektrumslizenzen und eine Herstellerbeziehung. Das Verhältnis stimmt nicht.
• Reine Entwicklungsumgebungen. Kabel plus WLAN liefert alles, was 5G böte – und nichts zusätzlich zu verwalten.
• Sie haben kein Netzwerkteam. Privates 5G ist nicht „einrichten und vergessen“. Es ist ein weiteres Produktivsystem, das betrieben, überwacht und aktualisiert werden will.

Das Latenzbudget: welche Workloads was aushalten

Das Muster ist eindeutig: Arbeit im geschlossenen Regelkreis läuft lokal oder über Kabel, Wahrnehmung mit Denkleistung verträgt WLAN, Konversation verträgt WAN. Der Architekturfehler besteht darin, Code in der Nähe des Motorregelkreises auf einen Pfad zu legen, der Netzwerk-Jitter abbekommen kann. Der zweite Fehler ist, 5 ms Transportzeit zu bezahlen, während die Modelllatenz bei 400 ms liegt – Sie haben 30 ms von insgesamt 430 ms gespart. Optimieren Sie den dominanten Term.

Das Muster „immer ein Fuß in der Cloud“

Selbst bei einem konsequenten On-Premise-Aufbau ist der Roboter selten vollständig vom Netz getrennt. Was legitim ins WAN will:

• Telemetrie an den eigenen Monitoring-Stack (Prometheus / Grafana / Datadog). Nützlich, bandbreitenarm, verträgt jede RTT.
• Modell- und Firmware-Updates. Neue VLM-Gewichte, Container-Images, Betriebssystem-Patches. Stoßweise, nachts erledigbar.
• Karten- und Umgebungsdaten. Grundriss, Abgleich von Punktwolken, Sicherung des Szenengedächtnisses.
• Rückfallebene für Teleoperation. Manchmal – vorbehaltlich einer Sicherheitsprüfung.

Das Muster lautet: On-Premise zuerst für den heißen Pfad, WAN-Ausgang per Firewall gesichert für den kalten Pfad. Der Roboter braucht niemals eine eingehende WAN-Adresse. Der Server ebenso wenig. Nur ausgehend, nur freigegebene Ziele, TLS, keine Ausnahmen.

Multicast, mDNS, DDS – und warum WLAN sie schmerzhaft macht

ROS 2 bringt DDS als Standard-Middleware mit. DDS nutzt IP-Multicast, um Teilnehmer zu finden. WLAN verschickt Multicast mit der niedrigsten gemeinsamen Datenrate an alle Clients der BSSID, was:

1. Sendezeit verschwendet.
2. Für die Firmware des Access Points wie ein Flood aussieht.
3. Von Enterprise-Access-Points mit aktivierter Multicast-Unterdrückung oft verworfen wird.

Das Ergebnis lautet „meine ROS-2-Nodes sehen sich über Ethernet, aber nicht über WLAN“ – ein gut dokumentierter und vollständig vermeidbarer Fehler. Gemessen liegt der Paketverlust für Multicast-ROS-2-Verkehr im WLAN selbst auf gesunden Strecken bei 1–3 %; bei Ethernet liegt er bei null. Zwei ROS-2-Roboter im selben WLAN können Discovery-Stürme auslösen, die den Access Point destabilisieren.

Die Abhilfen, nach Präferenz geordnet:

1. Nutzen Sie den Fast-DDS Discovery Server. Betreiben Sie einen Discovery-Server (üblicherweise auf dem Inferenzserver oder einer eigenen VM), richten Sie alle ROS-2-Nodes per Unicast darauf aus – und aus der Discovery wird ein ganz normaler Client-Server-Ablauf, mit dem WLAN gut zurechtkommt.
2. Statische Peer-Konfiguration per XML-Profil. Die IP der Gegenstelle fest eintragen. Spröde, funktioniert aber für ein festes Paar.
3. IGMP-Snooping und Multicast-zu-Unicast-Umsetzung am Access Point aktivieren. Aruba, Ruckus, Cisco Meraki und aktuelle UniFi-Firmware unterstützen das alle. Sagen Sie es dem Netzwerktechniker; es sind zwei Häkchen.
4. RMW-Implementierung wechseln. Manche wechseln von Cyclone DDS zu Fast-DDS oder zur Zenoh-Bridge, eigens um der Multicast-Discovery zu entkommen. Letztes Mittel, denn es kostet Integrationsaufwand.

QoS, DSCP und wie Sie Priorität bekommen

Die Roboter-SSID hat ein eigenes VLAN, das VLAN hat ein eigenes QoS-Profil. Die nächste Ebene sorgt dafür, dass das Netzwerk auch akzeptiert, dass Roboterverkehr wichtiger ist als die Dropbox-Synchronisation des Marketingteams.

Bewährtes Vorgehen:

• Steuerungsverkehr des Roboters per DSCP als EF markieren (Expedited Forwarding, DSCP 46). Der Steuerdatenstrom ist klein und latenzkritisch; EF ist die Lehrbuchklasse dafür.
• Bildströme als AF41 markieren (DSCP 34). Echtzeitvideo, hoher Durchsatz, niedrigere Priorität als die Steuerung.
• Telemetrie und Modellabrufe mit dem Standardwert markieren (DSCP 0). Keine Sonderbehandlung.
• Das WMM-Mapping am Access Point muss die Markierungen respektieren. Die meisten Enterprise-Access-Points (Aruba, Cisco Meraki, Ruckus) erledigen das automatisch, sobald DSCP-Trust aktiviert ist. UniFi verlangt in aktueller Firmware eine ausdrückliche Konfiguration.

Konkrete Netzwerkarchitektur für ein Robotiklabor

Ein funktionierender Aufbau für ein Labor mit 1–4 Robotern, abgestimmt auf die Hardware-Realität aus I01 :

Referenznetz im Labor: Roboter → eigene 6-GHz-Access-Points → 10-GbE-Switch → Kentino KI-Server. Ausgang per Firewall gesichert, nur ausgehend.

Für 1–4 Roboter in einem Raum landet dieser Aufbau je nach Herstellerklasse bei 4–12 Tsd. € an Netzwerktechnik. Ruckus und Aruba beherrschen die Funkseite in dichten oder schwierigen Umgebungen am besten. Cisco Meraki punktet mit Einfachheit, erkauft sie aber mit laufenden Kosten. UniFi punktet beim Preis und genügt für ein einzelnes Labor.

Fehlerbilder, ungefähr in der Reihenfolge, in der sie zuschlagen

• Roaming zerreißt eine Verbindung. Der Roboter überquert eine Zellgrenze, die Assoziation bricht für 100–400 ms ab, der ROS-2-Socket erholt sich, aber im Log klafft eine Lücke im Steuerdatenstrom. Gegenmittel: überlappende Zellen, schnelles Roaming nach 802.11k/v/r – und den Regelkreis erst gar nicht über das Netzwerk zu führen.
• Störungen zwischen mehreren Robotern auf geteilten Kanälen. Drei G1 auf demselben 6-GHz-Kanal treten sich gegenseitig auf die Sendezeit. Planen Sie nicht überlappende 80-MHz-Kanäle im 6-GHz-Band (in der EU gibt es sieben, in den USA mehr).
• Gebäudestruktur. Stahlbetonwände dämpfen um 20–30 dB. Stahltüren von Serverräumen um 40 dB. Vor der Montage der Access Points jedes Mal eine Funkausleuchtung.
• Ablaufende DHCP-Lease mitten in der Aufgabe. Lange Robotersitzung, die DHCP-Verlängerung scheitert, die IP ändert sich, Sockets brechen. Feste DHCP-Reservierung für den Roboter. Immer.
• Stromsparmodi. Das WLAN-Energiesparen im Funkmodul des Roboters erkauft Akkulaufzeit mit zusätzlicher Latenz. Ausdrücklich deaktivieren. Akkulaufzeit ist ein Akkuproblem; bezahlen Sie sie nicht mit Jitter.
• Unterschiedliche MTU. Das Hersteller-SDK des Roboters nutzt 1500, Ihre Infrastruktur 9000, es kommt zur Fragmentierung und die Leistung bricht stillschweigend ein. Die MTU durchgängig angleichen.

Die ehrliche Einschätzung

Der nützlichste Satz dieses Beitrags lautet: 95 % der „Roboterprobleme“, die im ersten Monat nach der Inbetriebnahme gemeldet werden, sind Probleme der WLAN-Konfiguration. Der Roboter ist in Ordnung. Das Modell ist in Ordnung. Das WLAN ist nicht in Ordnung, die SSID wird mit dem Büro geteilt, es gibt kein eigenes VLAN, Multicast wuchert, die Access Points hängen an den falschen Stellen – und der Integrator debuggt drei Wochen lang die falsche Schicht.

Holen Sie die Netzwerkfachkraft früh an Bord. Bezahlen Sie sie besser, als Sie denken. Die erfahrene Netzwerkingenieurin, die eine Wi-Fi-6E-Planung aufsetzen, QoS durchgängig konfigurieren und die DDS-Discovery abstimmen kann, ist in diesem Projekt so viel wert wie eine erfahrene Robotikfachkraft – und deutlich schwerer zu finden.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Anmerkungen und Korrekturen gern an info@kentino.com.