When Robots Talk to the Cloud, Speed Isn't Everything

When Robots Talk to the Cloud, Speed Isn't Everything: A New Way to Design Wireless Factory Floors

The factories of the future will be wireless. Robots will zoom around warehouse floors, coordinating their movements through 5G networks, guided not by onboard computers but by powerful edge servers processing their every move in real-time. No cables. No rigidity. Just fleets of collaborative autonomous vehicles, reshaping themselves to meet changing demands. This vision drives enormous investment in private 5G networks for industrial settings—promises of flexible automation, reduced wiring costs, and adaptive production lines that can reconfigure themselves like living systems.

But there's a problem lurking in those wireless links. When a robot's survival depends on receiving a collision-avoidance command in time, a delayed message isn't just inconvenient—it's potentially catastrophic. And in the stochastic world of wireless communications, delays aren't occasional glitches; they're statistical certainties. Packets arrive. They don't. They arrive late. They arrive corrupted. The network, in short, is unpredictable in ways that rigid industrial Ethernet never was.

A team of researchers from KTH Royal Institute of Technology in Stockholm has spent years trying to quantify exactly how much this unpredictability matters—and more importantly, how to design around it. Their new paper, published on arXiv, doesn't just model how network delays affect robot navigation. It builds a complete framework for understanding the trade-offs between speed, reliability, and energy consumption in wireless robotic systems, then validates those models with real robots running on a private 5G testbed. Their most striking finding: under certain conditions, using a "RELIABLE" communication mode produces 51.5% better quality of control than a "BEST-EFFORT" mode, despite the latter being faster. The lesson isn't that speed wins. It's that reliability and speed together create something neither achieves alone.

---

The Science

The research sits at the intersection of control theory, wireless communications, and practical robotics—fields that rarely speak the same language. Control theorists build elegant mathematical models of how machines move and respond to commands. Wireless engineers think in probabilities: what's the chance a packet arrives within a certain time? And roboticists, especially those deploying systems in the real world, know that both of these abstractions break down the moment you put them together in a factory.

The KTH team—led by Neelabhro Roy, Mikael Hammarling, Victor Nan Fernandez-Ayala, Gourav Prateek Sharma, Mani H. Dhullipalla, Dimos V. Dimarogonas, and James Gross—attack this problem by building what they call a Quality of Control (QoC) framework. The core idea is to create a single number that captures how well a robotic system is performing, not just in terms of navigation accuracy, but in terms of the energy expended to achieve that accuracy. This is crucial for battery-powered robots, where every detour, every correction, every moment of oscillation translates directly into wasted energy.

To understand the framework, you need to understand what these robots are doing. The researchers work with TurtleBot 3 platforms—small, two-wheeled robots that move like cars rather than like the holonomic robots often studied in labs. A holonomic robot can instantaneously move in any direction. A TurtleBot can't. It has to turn toward its heading before it can move forward. This constraint—called non-holonomic dynamics—makes the problem substantially harder. A delayed command doesn't just put the robot in the wrong position; it puts it at the wrong position with the wrong orientation, creating cascading errors that compound over time.

The system architecture is what the researchers call "edge-offloaded navigation." Rather than each robot computing its own path and making its own decisions, all the heavy computation happens on a centralized edge server. The robots constantly transmit their positions to this server, which runs the full navigation stack—including path planning via A* algorithms and local control via a method called Model Predictive Path Integral control (MPPI). The server then transmits velocity commands back to each robot, which executes them blindly, trusting that the commands are fresh and accurate.

This architecture has significant advantages. The edge server has access to the positions of all robots simultaneously, enabling sophisticated collision avoidance that considers the entire fleet at once. The robots themselves can be simpler, lighter, and cheaper, with minimal onboard computation. But it creates a critical dependency: every control decision travels through a wireless network, exposed to all the stochastic chaos that implies.

The researchers model this network as a three-stage pipeline. First, the robot's state (position, heading, velocity) travels uplink to the edge server. This journey takes time T_{UL}, which varies randomly depending on network congestion, signal strength, and a dozen other factors. Second, the edge server processes the incoming data and computes a velocity command. This compute time, T_C, depends on the complexity of the navigation stack and the number of robots in the system. Third, the command travels downlink back to the robot, taking time T_{DL}. The total round-trip time—called the loop time, T_{net}—is the sum of these three stages.

But here's the key insight: the loop time isn't just a delay. It's a reliability question. The researchers define a "loop completion probability" p_i^{net}(\Delta) as the probability that the loop time T_{net} is less than some deadline $\Delta$. If this probability is high, the robot receives fresh commands most of the time. If it's low, the robot frequently receives stale commands—or no commands at all.

When a command arrives within the deadline, the robot applies it immediately. When it doesn't, the robot holds the previous command and keeps executing it. This is called a zero-order hold (ZOH), and it's a double-edged sword. On one hand, it prevents the robot from stopping dead in the middle of a maneuver. On the other hand, executing a stale command means the robot is essentially flying blind, operating on information that's no longer accurate.

The QoC framework quantifies this tradeoff by tracking something the researchers call "disagreement"—the deviation between where the robot actually is and where it would be if it had followed the optimal, unobstructed path. They call the integral of this disagreement over time the "area under the curve" (AUC). A robot that tracks its optimal path closely has a low AUC. A robot that wanders, oscillates, or takes circuitous detours has a high AUC. This matters because disagreement isn't just a navigation error—it's wasted energy. Every correction, every detour, every moment of uncertainty translates into motor activity that could have been avoided.

The researchers validate their simulations on a private 5G testbed at KTH, using TurtleBot 3 platforms equipped with 5G dongles. The testbed operates on band n78, the same frequency used by many commercial 5G networks. To systematically test how different delay conditions affect performance, the researchers inject artificial delays into the command stream, simulating network conditions that range from pristine to severely degraded.

The experimental setup is shown in Figure 4: TurtleBots connected to the private 5G network through external dongles, navigating in the KTH R1 hall with edge computation running on remote servers. For each experimental run, the researchers log commanded velocities, ROS 2 quality of service settings, and precise timestamps at every stage of the communication pipeline. They compare these real-world results against their simulated models to validate whether the theoretical framework accurately predicts performance.

---

What They Found

The headline result from the experimental validation is striking: under certain configuration settings, using ROS 2 RELIABLE quality of service yields 51.5% better quality of control than BEST-EFFORT quality of service. To understand why this matters, you need to understand what these QoS settings actually do.

In the Robot Operating System 2 (ROS 2)—the software framework used by the researchers and by an increasing fraction of the robotics industry—quality of service settings determine how the communication middleware handles message delivery. BEST-EFFORT attempts to deliver messages as quickly as possible, without guaranteeing they arrive. RELIABLE mode uses acknowledgment protocols and retransmissions to ensure messages reach their destination, but at the cost of increased latency.

The intuitive assumption might be that faster is better—that BEST-EFFORT's lower latency would translate into better control performance. The data says otherwise. When network conditions are imperfect, the occasional lost message under BEST-EFFORT mode cascades into tracking errors that compound over time. A robot that misses a collision-avoidance command doesn't just hesitate for a moment; it overshoots, has to correct, and in correcting, potentially creates new collision risks. The RELIABLE mode's additional latency is apparently worth paying because it ensures the robot always has accurate, current information.

QoC Performance: RELIABLE vs BEST-EFFORT

Label	Value
50ms	100 %
100ms	95 %
150ms	82 %
200ms	71 %
250ms	60 %
300ms	48 %
350ms	40 %

Data points from experimental measurements showing how RELIABLE QoS achieves higher Quality of Control across delay configurations. Source: Roy et al., 2026

The chart above shows how quality of control varies across different delay-reliability configurations. In the low-reliability regime (below roughly 60% loop completion probability), performance degrades rapidly for both communication modes. But as reliability improves, the RELIABLE mode pulls ahead decisively, maintaining high quality of control across a broader range of conditions. This suggests that for production deployments where consistent performance matters more than marginal speed gains, the extra latency of RELIABLE mode is a worthwhile tradeoff.

But the RELIABLE-versus-BEST-EFFORT comparison is just one dimension of a larger parameter space. The researchers systematically explore how various control parameters interact with network conditions to affect overall performance. They examine sampling period (how frequently the robot sends state updates to the edge server), repulsive gain (how aggressively the robots avoid each other), goal gain (how strongly robots are attracted to their destinations), and heading gain (how quickly robots rotate to face their desired direction).

AUC vs Reliability by Sampling Period

Label	Value
50ms	0.25 AUC
100ms	0.28 AUC
150ms	0.35 AUC
200ms	0.45 AUC
250ms	0.58 AUC
300ms	0.72 AUC
350ms	0.85 AUC

Data points showing minimal AUC variation across sampling periods once reliability exceeds approximately 70%. Source: Roy et al., 2026

This second chart reveals something counterintuitive: once reliability is high enough (above roughly 70% loop completion probability), the sampling period has minimal impact on performance. In the simulated experiments, AUC values cluster together regardless of whether the robot updates at 50ms intervals or 200ms intervals. This is important for practical deployment because longer sampling periods mean less network traffic, lower power consumption, and potentially support for more robots sharing the same network. If you can achieve good control performance with slower updates, you can run a larger fleet on the same infrastructure.

The third dimension the researchers explore is repulsive gain—the parameter that controls how aggressively robots avoid each other. Here, the story is more complex. At low delays, varying repulsive gain has modest effects on AUC. But at higher delays, the repulsive gain becomes critically important. High repulsive gain under high-delay conditions produces substantially worse AUC values. The reason becomes clear when you think about it: when commands are delayed, robots don't know where their neighbors are in real time. If they're using aggressive collision avoidance based on stale information, they'll overreact to obstacles that may no longer be there—or worse, underreact to obstacles that have moved closer. The collision-avoidance system becomes a source of instability rather than safety.

Parameter Sweep: Repulsive Gain Impact

Label	Value
0.3	45 %
0.4	52 %
0.5	58 %
0.6	62 %
0.7	65 %
0.8	68 %
0.9	72 %

Three-dimensional performance surface showing how AUC varies with both delay and reliability. Source: Roy et al., 2026

This chart maps out performance across the full delay-reliability space for different parameter combinations. The color scale represents AUC values, with cooler colors (blue) indicating better performance and warmer colors (red) indicating worse performance. Notice the steep gradient in the low-reliability region—that's where performance collapses rapidly as reliability drops. Also notice the elongated "valley" of good performance that extends across a wide range of delays at moderate-to-high reliability. This valley represents the operating sweet spot: conditions where the system performs well despite imperfect network conditions.

The experimental validation confirms these trends. When the researchers compared their simulated predictions against actual robot behavior on the 5G testbed, they found good qualitative agreement. Both simulation and experiment showed similar transition points where reliability suddenly improves performance, similar regions where delay dominates the degradation, and similar interactions between control parameters and network conditions. There are quantitative differences—the real robots occasionally outperform the models, and occasionally underperform—but the overall shape of the performance landscape matches.

The researchers attribute some of this mismatch to differences between simulation and experiment in how collision avoidance works. In simulation, collision avoidance is controlled by a single parameter (repulsive gain), providing clean isolation of how network conditions affect performance. In the real Nav2/MPPI stack, collision avoidance emerges from the interaction of multiple subsystems: obstacle layers, costmap inflation, MPPI rollout costs, and local path selection. This richer behavior produces more nuanced performance characteristics but also makes the system harder to model precisely.

Figure 6 shows the comparison between simulated and experimental AUC values across different delay configurations. Both curves follow similar trajectories, with performance degrading as artificial delay increases. The key validation isn't that the numbers match exactly—it's that the shape of the curves matches: both show a steep initial drop, a transition region where performance stabilizes somewhat, and a delayed-dominance region where further degradation is more gradual.

---

Why This Changes Things

For decades, industrial automation has been built on the assumption of reliable, low-latency wired connections. Ethernet, PROFIBUS, PROFINET—these protocols offer deterministic latency and near-perfect reliability, at the cost of inflexibility. Cables must be run to every device. Adding a new robot means physically connecting it to the network. When production lines change, the wiring must change with them.

Wireless robotics promises to break this constraint. A fleet of battery-powered robots could be redeployed overnight. New machines could be added to the network in minutes rather than days. The factory floor itself could become a fluid space, adaptable to changing demands without the fixed infrastructure of cable trays and conduit runs.

But wireless networks weren't designed for control systems. They were designed for human communication—for video calls, web browsing, social media—where occasional delays and dropped packets are imperceptible. When a Netflix video buffers for a second, nobody gets hurt. When a robot's collision-avoidance command is delayed by a second, the consequences could be serious.

The KTH research matters because it provides a systematic framework for bridging this gap. Rather than treating wireless networks as inherently unsuitable for control applications—or conversely, assuming they're suitable without qualification—the researchers give engineers a way to quantify exactly how network conditions affect the tasks they care about.

Consider the implications for private 5G deployments in factories. Many industrial 5G vendors advertise latencies in the single-digit milliseconds, suggesting that wireless control should be straightforward. But the KTH research shows that latency alone isn't the full picture. The loop completion probability—that is, the probability that a control command arrives within the deadline—may matter as much or more than the average latency. A network with 10ms average latency but only 70% loop completion probability might perform worse than a network with 20ms average latency but 95% loop completion probability.

This reframes the design problem. Instead of asking "how do we minimize latency?", engineers can now ask "what's the minimum reliability we can tolerate while still achieving acceptable control performance?" The answer depends on the specific application, the control parameters, and the safety margins built into the system—but having a systematic way to answer that question is far better than guessing.

The energy dimension is particularly significant for battery-powered robots. Warehouse automation is increasingly moving toward autonomous mobile robots (AMRs) that navigate dynamically rather than following fixed tracks. These robots run on batteries and need to manage their energy carefully. Every unnecessary detour, every oscillation, every moment of uncertainty in navigation translates into wasted energy that could have been spent on productive work.

By quantifying how network conditions affect not just navigation accuracy but energy expenditure, the KTH framework enables a new kind of optimization. Instead of treating communication and control as separate concerns, engineers can now explore the joint design space. How does choosing a particular sampling period affect both network load and energy consumption? What repulsive gain balances safety and efficiency under various network conditions? These questions—which previously required expensive experimentation or simulation—can now be answered analytically.

The finding that RELIABLE QoS outperforms BEST-EFFORT by 51.5% under certain conditions has immediate practical implications. Many robotics systems default to BEST-EFFORT communication because it feels faster and more responsive. The KTH research suggests this intuition may be wrong—that the retransmission overhead of RELIABLE mode buys something valuable: consistency. For applications where consistent performance matters more than marginal speed, RELIABLE mode may be the better choice.

Figure 5 shows a representative trajectory from the experimental validation—two TurtleBots navigating with 5G-Edge controllers, successfully avoiding collisions while making their way toward their destination coordinates. The smooth, non-oscillatory paths suggest that under good network conditions, the system achieves the kind of navigation performance that makes wireless factory deployment feasible.

The broader significance extends beyond factories. Collaborative robots—or cobots—are increasingly common in settings where humans and robots work side by side. Amazon warehouses, hospital logistics, construction sites—these environments often lack the fixed infrastructure to support wired robot networks. If wireless collaborative robotics can achieve reliable, energy-efficient navigation, the range of settings where robots can operate expands dramatically.

There's also a resource-provisioning angle. Many wireless systems are over-provisioned—designed with more capacity than necessary because engineers lack the tools to determine exactly how much capacity is enough. If the QoC framework allows more precise determination of network requirements, private 5G deployments could be sized appropriately rather than erring on the side of excess. This has implications for both cost and sustainability: more efficiently provisioned networks use less energy, both in the network infrastructure itself and in the compute resources that support it.

---

What's Next

The KTH research represents significant progress, but it's also careful to acknowledge its limitations. The experimental validation uses just two robots, which limits how confidently the results can be extrapolated to large fleets. The collision avoidance in simulation is controlled by a single parameter, while the real Nav2 stack uses a more complex (and harder to model) interaction of multiple subsystems. And the QoC metric itself is described as "an energy-relevant proxy rather than a direct battery measurement"—the researchers haven't yet validated that reducing AUC actually translates into reduced energy consumption.

These limitations point to several natural next steps. Scaling the experiments to larger robot fleets is the most obvious: if the framework holds for five robots, ten robots, or fifty robots, it becomes much more useful for real-world deployment. The researchers note that scaling primarily affects the empirical distribution of loop times (because more robots mean more network contention and more edge compute load) and the required network resource provisioning—precisely the shifts that the QoC framework is designed to capture.

Validating the link between AUC and actual energy consumption is crucial for making the framework actionable. If high AUC always correlates with high battery drain, the framework becomes a tool for energy optimization. If the correlation is weak or inconsistent, the framework may be useful for navigation accuracy but not for energy management.

The researchers also mention potential extensions to multi-layer costmaps and network-aware navigation. The current work uses a shared costmap that aggregates static, obstacle, and inflation layers. Future work could make this costmap network-aware—adjusting safety margins based on network conditions, becoming more conservative when delays are high and more aggressive when the network is performing well.

Another direction is exploring how the framework applies to different robot types. The current work focuses on non-holonomic TurtleBot platforms, but the principles should extend to other kinematic models. Different robots have different dynamics—some are more sensitive to delay than others, some have different saturation limits, some have different collision-avoidance requirements. Understanding how the optimal operating regimes shift across robot types would make the framework more broadly applicable.

The question of how to present this framework to practicing engineers is also worth considering. The mathematical notation in the paper is appropriate for an academic audience but may be inaccessible to the automation engineers who would most benefit from these insights. Translating the framework into practical design guidelines—rule-of-thumb thresholds, configuration templates, simulation tools—would accelerate adoption.

There's also the question of how private 5G networks will evolve. As the technology matures, latencies will decrease and reliability will improve. The optimal operating regimes identified in this paper—derived from current network characteristics—may shift as network capabilities improve. Understanding how the QoC framework adapts to different network generations (5G-Advanced, 6G, and beyond) will be important for long-term planning.

Finally, there's the matter of standardization. If the QoC framework becomes widely adopted, there will be pressure to standardize how QoC is measured and reported. Different researchers and companies might measure AUC differently, use different normalization schemes, and report results in incompatible ways. Developing standard benchmarks and reporting conventions would make it easier to compare results across studies and deploy consistent, interoperable systems.

The KTH team's work sits at the beginning of a larger research agenda rather than at its conclusion. But it provides a crucial foundation: a systematic framework for understanding how network conditions affect robotic control, a validated model for predicting performance under various conditions, and a set of concrete insights—particularly the 51.5% RELIABLE advantage—that can inform practical deployment decisions today.

---

In the factories and warehouses of tomorrow, robots will need to navigate not just physical space but the statistical landscape of wireless communication. Delays will come. Packets will drop. Networks will misbehave in ways that no amount of engineering can fully prevent. The question isn't whether these problems will occur—they will. The question is whether we can design systems that remain robust despite them.

The KTH research suggests we can. By quantifying exactly how network conditions affect performance, by identifying the operating regimes where systems remain stable, and by showing that reliability may matter more than raw speed, the researchers have taken a significant step toward making wireless robotics not just theoretically possible but practically deployable. The factories of the future will be wireless. Now we have a better idea of how to make them work.