The Offloading Trap

A mobile robot manipulates objects. Its onboard processor is too slow — the full software pipeline exceeds the computation budget, draining the battery before the task completes. The obvious solution: offload computation to a remote GPU server.

Pohland et al. measure what happens. Remote computation is fast. But the data transfer is large — sensor streams, point clouds, images — and the transmission delay degrades manipulation accuracy. The robot computes faster but acts on stale information. The offloaded pipeline runs in less time but produces worse outcomes.

Larger onboard processors solve the computation problem but create the battery problem. A more powerful onboard GPU finishes faster but significantly reduces operational time between charges. The robot can think better but for shorter periods.

The structural trap: every solution to one constraint worsens another. Onboard computation is slow but current. Remote computation is fast but delayed. Powerful onboard computation is both fast and current but short-lived. The constraints form a triangle — latency, compute power, energy — and no configuration satisfies all three.

Multiple robots sharing pooled remote resources add another layer. Pooling amortizes server costs but introduces contention — when two robots need the GPU simultaneously, one waits. The queuing delay compounds the transmission delay, further degrading the already-marginal accuracy of remote execution.

The finding is not that offloading fails. It is that the success metric for computation (speed) and the success metric for manipulation (accuracy under real-time constraints) point in different directions when a network sits between them. Offloading optimizes the wrong metric.