Why Robot Fleet Connectivity Matters as Much as Autonomy
Robot fleet connectivity decides whether data leaving a robot arrives on time. Every change of network path costs measurable time. A Wi-Fi re-authentication on an 802.1X network can take hundreds of milliseconds. A TCP upload can sit idle for seconds after the internet connection returns. An MQTT broker with a 60-second keepalive shows a lost robot as online for 90 seconds. Perception, path planning and the safety controller run on the robot and never wait on a network. Telemetry, fault reports, remote assistance video, training logs and model updates all cross a radio.
If your team has traced a stopped robot or a late log upload back to the network, your fleet is not alone. Automate.org points out that a mobile robot depends on wireless connectivity for every route calculation, task assignment and status update.
The short version: autonomy runs on the robot, but fleet operations run over a network path that changes many times per shift. Combining every internet connection a robot can reach keeps one session and one address through those changes. The robot’s own software decides which traffic waits for dock Wi-Fi.
This article explains what a change of network path does to fleet traffic, and why the effects reach five different teams. The article also shows how Speedify keeps fleet traffic moving. Speedify is software that combines every network a machine can reach (Wi-Fi, 4G/5G cellular, Ethernet, Starlink and satellite) into one connection. Speedify splits traffic packet by packet across every internet connection, and a Speedify server puts the packets back together. One robot gets the combined capacity of every connection and keeps one address while individual connections change.
How Wi-Fi Roams and Cellular Handovers Interrupt a Robot’s Network Path
Each roam or handover stops data for a moment. On Wi-Fi, the client decides when to roam, not the access point. Most clients stay on the current access point until the signal falls below a threshold. The client then scans, picks a new access point and authenticates again, which can take hundreds of milliseconds on an 802.1X network. The 802.11r standard cuts a handover to tens of milliseconds, but support on robot radios varies.
A warehouse robot repeats the process at dozens of access points per shift. Outdoors, LTE handovers are break-before-make. A clean handover interrupts data for tens of milliseconds. A handover after the radio has already lost the cell can take seconds.
How TCP, MQTT and Video React When the Network Path Changes
The gap is short, but each protocol turns the gap into a longer problem:
- TCP uploads stall after the connection returns. TCP retransmits on a timer that doubles after every miss. On Linux the timer starts at 200 ms, so retries land at about 0.2, 0.6, 1.4, 3 and 6.2 seconds. An internet connection that returns just after a retry leaves the upload idle until the next retry.
- MQTT sessions time out late. An MQTT broker closes a client’s connection after one and a half keepalive intervals without traffic. The keepalive setting decides how long a lost robot still looks online.
- Failover changes the robot’s IP address. A move from Wi-Fi to an LTE modem sends packets from a new IP address, usually behind carrier NAT. Every TCP session opened over Wi-Fi resets.
- Video drops quality on purpose. WebRTC’s congestion control cuts the sending rate when more than 10% of packets go missing, then recovers about 5% per update. A handover can cost the operator seconds of blurry video. RoboticsTomorrow describes teleoperation teams outgrowing browser-grade video stacks for this reason.
- Large uploads restart. An upload tool without resume support starts over after a reset session. Over metered cellular, the restarted upload is paid for twice.
Why Network Problems Show Up as Five Unrelated Fleet Tickets
Each effect lands in a different team’s queue:
- Navigation: a robot stopped behind racking.
- Teleoperation: a remote assist froze mid-maneuver.
- Data: training logs arrived days late.
- Field service: a robot went offline after a customer changed the site’s Wi-Fi.
- Finance: a cellular overage after bulk logs went out over cellular instead of waiting for Wi-Fi.
With no owner for the network path, nobody connects the five tickets.
How Speedify Chooses an Internet Connection for Each Packet
Speedify sends each packet to the internet connection where the packet would arrive soonest. Multi-WAN and SD-WAN routers work differently: each session is locked to one internet connection. One large upload then never uses more than one connection, and a failing connection resets every session on that connection.
Speedify works one layer below sessions. Inside a single TCP connection or UDP stream, each packet can take a different internet connection. A Speedify server puts the packets back in order and forwards the traffic to your services.
The arrival estimate counts the connection’s one-way delay plus the time the connection’s queue needs to drain. The reason is in-order delivery. The receiver hands packets on in sequence, so one packet on a distant connection holds up every packet behind the late packet. The tunneled TCP then reads the stall as loss. In testing, a 25 ms connection paired with a 0.2 ms connection carried 134 Mbps when each packet went to the connection with the most free room. With each packet sent by expected arrival, the same pair carried 522 Mbps.
Internet connections within about a millisecond of each other count as one choice, and packets rotate among the connections in that group. Always picking the momentary best connection sends long bursts down one path, and the bursts widen the reordering the far end has to absorb. On eight identical 100 Mbps connections, greedy selection reached 380 Mbps. Rotating within the group reached 656 Mbps, with each connection carrying about 12.5% of the traffic.
The design has a cost. Traffic takes an extra hop through the Speedify server, so a single healthy internet connection can measure slightly lower latency than the combined connection. Speedify accepts the hop for two gains. One session uses the capacity of every connection. And a connection change removes capacity instead of resetting the session.
How Much Bandwidth Combining Internet Connections Adds to a Robot Fleet
Combining internet connections adds capacity, not only failover. In Speedify’s test matrix of emulated internet connections, TCP download over combined 100 Mbps connections scaled almost linearly. Two connections carried 190.9 Mbps, four carried 379.9 Mbps and eight carried 760.2 Mbps. The totals reached 91% to 94% of the measured single-connection capacities added together.
Speedify grades each result against a measured single-connection reference over the same path, not against the nominal rate. A shaped 100 Mbps connection never delivers 100 Mbps of TCP payload.
On Linux, Speedify also terminates TCP locally. The data then crosses the combined connection in segments of up to about 65 kB instead of 1,460 bytes, about 47 times fewer packets. The saving is large: one internet connection through Speedify measured 5% faster than the same internet connection with no tunnel.
Speedify lets a site use public or private 4G/5G and Wi-Fi together. Where the Speedify server runs follows where the traffic needs to go:
- Warehouses and factories: private 5G and facility Wi-Fi combined on premises at a Speedify Self-Hosted Server, next to the fleet manager. The traffic stays in your own infrastructure, with no Speedify bandwidth cap.
- Robotaxis, delivery robots and road vehicles: public 5G from more than one carrier plus depot Wi-Fi, combined in the cloud at a Speedify Dedicated Server. A Dedicated Server is a private instance with a static IPv4 address and up to 1 Gbps of throughput.
How Speedify Keeps Metered Cellular From Raising the Fleet’s Bill
Speedify ranks internet connections by cost, so metered or capped connections carry traffic only when the fleet needs the capacity. Robot fleets usually buy cellular on custom or pooled business plans, with a monthly allowance and an overage rate. Satellite plans can charge per gigabyte. On a flat-rate plan, every internet connection can simply be Primary.
Speedify puts each internet connection in one of three cost tiers:
- Primary, such as facility Wi-Fi or a flat-rate line, carries traffic first.
- Secondary, such as cellular on a pooled plan, joins only when the Primary connections run out of room. Two conditions must hold for a full second: every Primary connection is full, and the Primary connections together deliver less than 35 Mbps.
- Backup, such as a per-gigabyte satellite plan, carries traffic only when nothing cheaper works.
The tier decides which internet connections are candidates. The tier never changes the speed ranking among the candidates, so nobody has to tune an exchange rate between milliseconds and money. Spilling onto a Secondary connection needs both conditions at once, because a busy Primary connection is full most of the time.
How to Prioritize Robot Fleet Traffic on a Combined Connection
Not every byte leaving a robot has the same needs:
| Traffic | What the traffic needs | Typical treatment |
|---|---|---|
| Telemetry, fault reports, safety logs | Small and steady, and has to arrive during incidents, when the radio environment is at the worst | Every available internet connection, highest priority |
| Teleoperation and supervision video | Low delay and a steady bitrate | Fastest delivery, kept clear of bulk transfers |
| Diagnostics and remote access | Short, interactive sessions | Interactive priority |
| Sensor logs and training data | The largest volume, and can wait | Dock Wi-Fi and other unmetered connections |
| Model and policy updates | Large, and has to finish | The full combined connection, continuing through roams instead of restarting |
Speedify does not inspect payloads. The robot’s own software classifies the traffic. The Speedify embedded daemon reports each change to the robot’s internet connections on a local socket. A bulk upload can then wait for dock Wi-Fi.
By default, a combined connection delivers packets in one sequence, so one late packet holds up everything behind the late packet. Speedify can also order each flow separately. A retransmission on a log upload then delays only the upload, not the teleoperation video next to the upload. Per-flow ordering costs four bytes per packet.
Where Speedify Runs on a Robot, and Where the Safety Boundary Sits
The Speedify embedded daemon runs inside the robot’s software image on Linux and QNX, as a supervised service. The robot’s routing sends selected traffic into Speedify. Fleet services see traffic from the Speedify server’s address.
Each robot keeps one session identity across restarts, and the Speedify server leases the robot’s tunnel address to that session. A robot that restarts, or that loses and regains every internet connection, receives the same address. MQTT brokers, WebRTC sessions and the fleet manager keep seeing the same robot. A failing internet connection is not an outage: the failing connection reconnects on a separate backoff timer while the other connections carry traffic.
Robots are provisioned, not set up by hand. A robot shows an activation code, somebody approves the robot in a browser, and the robot receives a token. A robot nobody has approved keeps offering fresh codes, backing off from 30 seconds to 15 minutes. Giving up after ten minutes would turn into a site visit.
Each robot also gets a server build that matches the robot’s own software version. A robot on two-year-old firmware never meets an incompatible server. Upgrades roll out as a drain: new sessions start on the new build, and existing sessions finish on the old build.
Two limits apply. During a change of internet connection, traffic can slow briefly while packets move. And Speedify carries operational traffic but is not certified as a safety communication channel. If every internet connection fails at once, the combined connection is down until a connection returns, and the robot still needs an independent safe-stop behavior.
How to Check Whether Your Robot Fleet Has a Network Path Problem
- Plot a week of offline events by location. Clusters at the same spots every shift point at the network, not the robots.
- Line up cellular bills against fleet size. Bills that swing while the fleet stays flat mean bulk data is reaching cellular.
Next Steps: Plan a Robot Fleet Pilot With Speedify
A first conversation with the Speedify team covers four questions. Which internet connections can each robot model reach? Which traffic leaves the robot? Where do fleet services run? How much CPU and memory can the onboard computer spare? A pilot then runs the checks above on your own robots, before and after.
Speedify for physical AI covers the deployment options, from the Speedify SDK inside the robot’s image to Speedify for Routers on a retrofit. Contact Us to book a demo with the Speedify team or to plan a pilot on your own hardware.
Speedify Business Solutions
Speedify Teams
Speedify for Routers
Speedify Embedded Solutions and Integrations
Add Speedify to your own app or hardware with the Speedify SDK. Your product then combines internet connections, fails over automatically when one drops, and encrypts the traffic, using the same technology as the Speedify app.