Robot Networking: Wi-Fi, Tethers, 5G, and Why Latency Matters

A humanoid is a mobile node on a network that was almost certainly designed for laptops sitting still. That mismatch is the source of roughly 95% of the "the robot is weird today" tickets you will ever file. The motor controllers are fine. The Jetson is fine. The model on the K-AI server is fine. The Wi-Fi is not fine.

This article is about the second half of I01's two-box picture — specifically, the link in the middle. The robot you bought is only as good as the network you put it on, and the network you put it on probably needs to be rebuilt before it earns the word "fine."

Audience: integrators, lab leads, and IT teams who have been told a humanoid is arriving next month and have not yet absorbed that the existing corporate Wi-Fi is going to embarrass everyone.

Why robot networking is its own problem

Most enterprise Wi-Fi is dimensioned for human-scale traffic patterns: bursty downloads, occasional video calls, long idle periods. A humanoid does none of those. It generates a continuous duplex stream of low-rate control messages, intermittent bursts of image data heading to the inference server, and a steady trickle of telemetry. The control stream is small (kilobytes per second) but pathologically jitter-sensitive. The image bursts are fat (tens to hundreds of megabytes per second when raw) and need a fat path. Telemetry is forgiving and bores everyone.

What makes the problem unique:

• The node moves. The robot walks across the cell boundary between APs, and the roaming event drops packets for 50–500 ms depending on how the network is configured. A laptop's user does not notice. A robot's balance controller might.
• RF is hostile. A 30 m² lab with two engineers, three laptops, an espresso machine with Wi-Fi, and a microwave oven is a perfectly normal RF environment that will absolutely savage a 5 GHz robot link. Body shadowing from the robot itself blocks signal in unpredictable directions as it turns.
• Multi-robot interference compounds. Two G1s in the same room on the same channel will not cooperate gracefully. Three is a problem. A fleet of eight needs real planning.
• The protocols above the radio are also fragile. ROS 2's default DDS configuration relies on IP multicast for discovery. Wi-Fi handles multicast badly. The combination produces "the nodes can't see each other" tickets that look like robot bugs.

This is solvable. None of it is solved by default.

Wi-Fi 6E: the current floor

The honest 2026 starting point for a robotics Wi-Fi deployment is Wi-Fi 6E with a dedicated 6 GHz SSID for the robots only. Not Wi-Fi 6. Not 5 GHz "we'll fix it later." 6E, 6 GHz, separate SSID, isolated VLAN.

The reason is RF cleanliness, not headline throughput. The 6 GHz band is new enough that consumer junk has not flooded it yet. There is no Bluetooth on 6 GHz, no microwave oven harmonic, no 15-year-old printer broadcasting beacons. Your robot's radio gets a clean channel. That clean channel is worth more than any spec-sheet improvement.

What real Wi-Fi 6E robot RTT looks like, measured from the robot's CPU to the inference server on the wired side of the AP:

A clean 6 GHz link delivers single-digit-millisecond RTT consistently enough that ROS 2 nodes, gRPC clients to vLLM, and teleop feel responsive. The same robot moved to a shared 5 GHz SSID will feel "laggy" in a way no one can put a number on until they measure.

Wi-Fi 7 in 2026: limited support, real promise

Wi-Fi 7's headline feature is Multi-Link Operation (MLO) — the radio bonds two or three bands (2.4/5/6 GHz) simultaneously and either aggregates throughput or replicates packets across links for reliability. The latency reduction in Wi-Fi 7 vs 6E is real where MLO is enabled: vendors quote 50–75% latency drops, and bench measurements under controlled conditions see Wi-Fi 7 MLO RTT in the 1.5–4 ms range vs 3–6 ms on Wi-Fi 6E. Sub-millisecond is occasionally claimed in marketing, which has not been reproduced on robot hardware.

The catch is the robot radio. As of mid-2026, mainstream humanoid platforms (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) ship with Wi-Fi 6 or 6E. None of them advertise Wi-Fi 7 on the base SKU. Putting a Wi-Fi 7 AP in front of a Wi-Fi 6E robot gives you a Wi-Fi 7 backhaul and a 6E robot link — fine, but you are paying for capability you cannot use yet.

When Wi-Fi 7 starts to matter for robots:

• When the robot ships with a Wi-Fi 7 module by default (expected on 2027 platforms).
• When MLO can replicate the control-plane packet stream across 5 GHz and 6 GHz simultaneously, killing single-band fade events.
• When you are deploying a fleet large enough that congestion on a single band is the bottleneck, regardless of latency.

For a single-robot lab in 2026: 6E is enough. For a fleet build planned for 2027 onward: spec the APs as Wi-Fi 7 today so you do not re-buy the network in eighteen months.

AP placement and density

The instinct is to mount one AP on the ceiling at the corner of the room. The result is a half-meter dead zone behind the lab bench where the robot loses signal during exactly the demo you scheduled.

Rules of thumb that work:

Line-of-sight beats power. A 30 dBm AP behind a steel rack delivers worse signal than a 20 dBm AP mounted on the ceiling in the middle of the room. Robots are short — a chest-mounted antenna at 1.2 m sees a different RF environment than a laptop on a desk at 0.7 m, and worse than a phone at 1.5 m. APs above 2.5 m, robots below 1.5 m, no people-sized obstacles in the dominant path.

Dedicated robotics SSID. Non-negotiable. The robot SSID has its own VLAN, its own QoS profile, its own DHCP scope, and no consumer traffic. Mixing the robot onto the staff Wi-Fi works in development for one week, after which a marketing intern joins a video call and the robot falls over.

Body shadowing — the antenna problem

A humanoid's torso is a steel and plastic box about 30 cm wide. The radio antenna typically lives somewhere inside the chest plate, often on the back or one side. When the robot turns away from the AP, the body becomes a partial Faraday shield.

The signal-strength loss is typically 6–15 dB depending on antenna placement and the metal content of the chest. That is enough to flip a marginal link from "works fine" to "drops every few seconds" purely by rotation. Quadrupeds suffer less because they are lower and flatter and the antenna is usually on a chassis edge with cleaner sky view.

What helps:

• Antenna on the head or shoulders, not the chest. Some research-tier humanoids let you relocate or add an external antenna. Most consumer-tier units do not. Ask before buying if RF reliability is a deployment requirement.
• Two APs with diversity. With APs on opposite walls, the robot is "in front of" one of them regardless of orientation. The AP roam handles the switch — badly, but better than no signal.
• Lower antennas on the AP side. If your APs are ceiling-mounted at 3 m and the robot antenna is at 1.0 m, the elevation angle is steep enough that the chest blocks a lot of the path. Wall-mounted APs at 2 m get a flatter, easier path.

The tether: how serious teams develop

Every serious robotics team has a tether. Most never talk about it because it spoils the "look ma, no wires" demo aesthetic. Anyone doing real integration work plugs the robot in.

The tether is a USB-C cable, an M12 X-code Ethernet cable, or in research-tier units a coiled umbilical carrying power and data together. Bandwidth is 1 Gbps or higher; latency is sub-millisecond round trip, often under 200 µs. That is two orders of magnitude better than the best Wi-Fi link.

The reason you tether during development is not the bandwidth; it is the elimination of the variable. When the Wi-Fi is flaky, you cannot tell whether your ROS 2 node is slow, the model is slow, or the air is bad. Plug in, and there is no air. Everything else gets easier to debug.

The Unitree G1 EDU and Booster T1 both ship with credible tether stories. The H1 is awkward to tether. The PM01 and SE01 support development tethering through standard USB-C or Ethernet. Quadrupeds (Go2) are rarely tethered because the use case is outdoor; if you are doing serious indoor RL work on one, you might want to anyway.

5G private networks: when it is worth it

Private 5G — your own licensed or shared-spectrum cellular network on-premise — entered "real product" territory in 2025 and is shipping at scale by 2026. The technology works.

When private 5G makes sense:

• Large outdoor sites. Multi-hectare facilities, mining, large agriculture, ports. Wi-Fi cells do not scale here; the AP count and survey effort exceed the cost of a single small-cell 5G network.
• Multi-building campuses. When the robot has to move from indoor to outdoor and back, or between buildings, Wi-Fi roaming gets ugly. 5G handles mobility natively.
• Mobility-first deployments. Inspection robots traversing kilometres, autonomous mobile robots in large warehouses, anything where the radio link must follow the unit across geography.
• Mixed-fleet with other 5G assets. If the site already has private 5G for forklifts, AGVs, or sensor networks, adding robots to it is incremental cost, not a new project.

When it is overkill:

• Single lab, single building, one to four robots. Wi-Fi 6E does this job for €3–8k of APs. Private 5G does it for €60–200k of small cells, EPC/5GC, spectrum licensing, and a vendor relationship. The ratio is wrong.
• Pure development environments. Tether plus Wi-Fi gives you everything 5G would and nothing extra to manage.
• You do not have a network team. Private 5G is not "set and forget." It is an additional production system to operate, monitor, and update.

The latency budget: which workloads survive what

The pattern is clear: closed-loop work goes local or tethered, perception with thinking can take Wi-Fi, conversation can take WAN. The architectural mistake is putting motor-loop-adjacent code on a path that can hit network jitter. The other mistake is paying for 5 ms transport when the model latency is 400 ms — you saved 30 ms on a 430 ms total. Optimize the dominant term.

The "always one foot in the cloud" pattern

Even on a hard on-prem deployment, the robot is rarely fully air-gapped. Things that legitimately want WAN:

• Telemetry to your own monitoring stack (Prometheus / Grafana / Datadog). Useful, low-bandwidth, can survive any RTT.
• Model and firmware updates. Pulling new VLM weights, container images, OS patches. Bursty, can be done at night.
• Map and environment data. Floorplan, point cloud sync, scene memory backup.
• Remote teleop fallback. Sometimes; subject to security review.

The pattern is on-prem-first for the hot path, WAN egress firewalled for the cold path. The robot does not need an inbound WAN address ever. The server does not need an inbound WAN address either. Outbound only, allow-listed destinations, TLS, no exceptions.

Multicast, mDNS, DDS — and why Wi-Fi makes them hurt

ROS 2 ships with DDS as the default middleware. DDS uses IP multicast for participant discovery. Wi-Fi handles multicast by transmitting at the lowest common rate to all clients on the BSSID, which:

1. Wastes airtime.
2. Looks like a flood to the AP firmware.
3. Often gets dropped by enterprise APs with multicast suppression turned on.

The result is "my ROS 2 nodes can see each other on Ethernet but not on Wi-Fi" — a well-documented and entirely avoidable failure. Measured Wi-Fi packet loss for multicast ROS 2 traffic runs 1–3% even on healthy links; Ethernet sits at zero. Two ROS 2 robots on the same Wi-Fi can spawn discovery storms that destabilize the AP.

The fixes, in order of preference:

1. Use the Fast-DDS Discovery Server. Run a discovery server (typically on the inference server or a dedicated VM), point all ROS 2 nodes at it via unicast, and discovery becomes a normal client-server flow that Wi-Fi handles fine.
2. Static peer configuration via XML profile. Hardcode the IP of the other side. Brittle, but works for a fixed pair.
3. Enable IGMP snooping and multicast-to-unicast conversion on the AP. Aruba, Ruckus, Cisco Meraki, and recent UniFi firmware all support this. Tell the network engineer; it is two checkboxes.
4. Switch RMW implementation. Some users move from Cyclone DDS to Fast-DDS or to Zenoh-bridge specifically to escape multicast discovery semantics. Last resort; it is an integration cost.

QoS, DSCP, and getting prioritized

The robot SSID has its own VLAN; the VLAN has its own QoS profile. The next layer is making sure the network agrees that robot traffic is more important than the marketing team's Dropbox sync.

Standard pattern:

• DSCP-mark robot control traffic as EF (Expedited Forwarding, DSCP 46). The control-plane stream is small and latency-critical; EF is the textbook class for it.
• Image streams marked AF41 (DSCP 34). Real-time video, high throughput, lower priority than control.
• Telemetry and model fetches marked default (DSCP 0). No special treatment.
• AP WMM mapping must respect the markings. Most enterprise APs (Aruba, Cisco Meraki, Ruckus) do this automatically when DSCP-trust is enabled. UniFi requires explicit configuration in recent firmware.

Concrete network architecture for a robotics lab

A working build for a 1–4 robot lab, calibrated to the I01 hardware reality:

Reference lab network: robots → 6 GHz dedicated APs → 10 GbE switch → K-AI server. Egress firewalled, outbound only.

For 1–4 robots in a single room, this build lands at €4–12k of network gear depending on vendor tier. Ruckus and Aruba do RF best in dense or hostile environments. Cisco Meraki wins on simplicity at a recurring-cost penalty. UniFi wins on price and is fine for single-lab work.

Failure modes, in roughly the order they will bite

• AP roaming kills a flow. Robot crosses cell boundary, association drops for 100–400 ms, ROS 2 socket recovers, but a control-stream gap appears in the logs. Mitigate with overlapping cells, 802.11k/v/r fast roaming, and not relying on the network for closed-loop control in the first place.
• Multi-robot interference on shared channels. Three G1s on the same 6 GHz channel walk on each other's airtime. Plan non-overlapping 80 MHz channels in 6 GHz (there are seven in EU, more in US).
• Building structure. Reinforced concrete walls drop 20–30 dB. Server-room steel doors drop 40 dB. RF site survey before you mount APs, every time.
• DHCP lease expiry mid-task. Long-running robot session, DHCP renew fails, IP changes, sockets break. Static DHCP reservations for the robot. Always.
• Power-save modes. Wi-Fi power save on the robot radio adds latency for the sake of battery life. Disable explicitly. Battery life is a battery problem; do not pay for it in jitter.
• MTU mismatch. Robot vendor SDK uses 1500, your fabric uses 9000, fragmentation happens, performance collapses silently. Match the MTU end-to-end.

The honest take

The single most useful sentence in this article: 95% of "robot problems" reported in the first month of deployment are Wi-Fi configuration problems. The robot is fine. The model is fine. The Wi-Fi is not fine, the SSID is shared with the office, there is no dedicated VLAN, multicast is rampant, the APs are in the wrong place, and the integrator is debugging the wrong layer for three weeks.

Hire the network person early. Pay them more than you think. The senior network engineer who can lay out a Wi-Fi 6E plan, configure QoS end-to-end, and tune the DDS discovery is worth the same as a senior roboticist on this project and is much harder to find.

---

This is part of the Kentino Wiki, a reference series on AI compute, robotics, and the systems that connect them. Comments and corrections welcome at info@kentino.com.