A robot executes a sequence of perception, decision, and control tasks. Each task can be executed:

• Onboard: on microcontrollers, CPUs, or GPUs physically mounted on the robot.
• Offboard: on a remote computer/cloud/edge server, communicating via a network link.

From Lessons 1–3, you already know that computing platforms differ in throughput and determinism, and that interfaces have bounded data rates. Here we study how placement of tasks changes system behavior.

flowchart TD
  S["Robot task arrives"] --> Q["Is task safety-critical or hard real-time?"]
  Q -->|yes| OB["Run onboard"]
  Q -->|no| R["Is required compute > onboard capacity?"]
  R -->|no| OB
  R -->|yes| N["Is network latency/bandwidth acceptable?"]
  N -->|no| OB2["Simplify task or add onboard accelerator"]
  N -->|yes| OFF["Run offboard (edge/cloud)"]
  OFF --> H["Send result back"]
  OB --> U["Actuate / log"]
  OB2 --> U
  H --> U
        

The key trade-off: onboard computing provides low-latency determinism and autonomy, while offboard computing provides high compute/memory and easier upgrades.

Suppose a task produces an input data packet of size \( S \) (bits), requiring an algorithm with \( C \) floating-point operations (FLOPs). Let onboard compute rate be \( f_{\text{on}} \) FLOPs/s and offboard compute rate \( f_{\text{off}} \).

Onboard execution time:

\[ T_{\text{on}} = \frac{C}{f_{\text{on}}}. \]

For offboard execution, data must be transmitted to the remote computer and results returned. Let uplink/downlink bandwidths be \( B_u \), \( B_d \) (bits/s), propagation/stack delay be \( T_p \), and output packet size \( S_r \).

Offboard round-trip time:

\[ T_{\text{off}} = \underbrace{\frac{S}{B_u}}_{\text{upload}} + \underbrace{T_p}_{\text{prop./stack}} + \underbrace{\frac{C}{f_{\text{off}}}}_{\text{remote compute}} + \underbrace{T_p}_{\text{prop./stack}} + \underbrace{\frac{S_r}{B_d}}_{\text{download}}. \]

A task should be offloaded only if \( T_{\text{off}} < T_{\text{on}} \), i.e.

\[ \frac{S}{B_u} + \frac{S_r}{B_d} + 2T_p + \frac{C}{f_{\text{off}}} < \frac{C}{f_{\text{on}}}. \]

Rearranging gives a useful threshold on computational intensity \( \rho = \frac{C}{S} \) (FLOPs per bit):

\[ \rho > \frac{1/B_u + (S_r/S)(1/B_d) + 2T_p/S} {1/f_{\text{on}} - 1/f_{\text{off}}}. \]

Intuitively: tasks with high compute-per-bit (large \( \rho \)) are good candidates for offboard computing, provided the network is stable.

Students already know how delays affect linear control. If sensing or control is offboard, the loop experiences a delay \( T_d \approx T_{\text{off}} \).

Consider a continuous-time plant \( G(s) \) and controller \( K(s) \). With a pure time delay, the open-loop transfer becomes

\[ L_d(s) = K(s)\,G(s)\,e^{-sT_d}. \]

The delay contributes a phase lag of \( -\omega T_d \) radians at frequency \( \omega \). Let the original (delay-free) crossover frequency be \( \omega_c \), where \( |K(j\omega_c)G(j\omega_c)| = 1 \).

Proposition (Delay reduces phase margin): If delay-free phase margin is \( \phi_m \), then the phase margin with delay satisfies \( \phi_m^{(d)} = \phi_m - \omega_c T_d \).

Proof: At \( \omega_c \), the delay-free loop phase is \( \angle L(j\omega_c) = -\pi + \phi_m \). Multiplying by \( e^{-j\omega_c T_d} \) adds phase \( -\omega_c T_d \), so

\[ \angle L_d(j\omega_c) = (-\pi + \phi_m) - \omega_c T_d = -\pi + (\phi_m - \omega_c T_d). \]

Therefore the new phase margin is \( \phi_m^{(d)} = \phi_m - \omega_c T_d \). ∎

A sufficient stability condition is \( \phi_m^{(d)} > 0 \Rightarrow T_d < \phi_m/\omega_c \). Thus offboard control is safe only when network delay is well below this bound.

flowchart TD
  P["Plant G(s)"] --> Y["Output y"]
  Y --> S["Sensor"]
  S --> D1["Delay T_d"]
  D1 --> C["Controller K(s) offboard"]
  C --> D2["Delay T_d"]
  D2 --> A["Actuator"]
  A --> P
        

Practical takeaway: high-rate stabilizing control (inner loops) should be onboard; offboard computing is better for slower tasks such as planning or heavy perception, where \( T_d \) is tolerable.

Let onboard power draw for computing be \( P_{\text{on}} \) (W), radio transmit/receive powers \( P_{tx}, P_{rx} \), and CPU/GPU offboard power ignored from robot’s battery perspective.

Energy for onboard execution:

\[ E_{\text{on}} = P_{\text{on}}\,T_{\text{on}}. \]

Energy for offboard execution:

\[ E_{\text{off}} = P_{tx}\left(\frac{S}{B_u}\right) + P_{rx}\left(\frac{S_r}{B_d}\right) + P_{\text{idle}}\left(2T_p + \frac{C}{f_{\text{off}}}\right), \]

where \( P_{\text{idle}} \) is robot power while waiting. Offloading saves energy if \( E_{\text{off}} < E_{\text{on}} \).

Reliability is also different. Suppose the probability the network is available during a task window is \( p_n \). If the offboard task is required for safe operation, the system success probability becomes \( p_{\text{succ}} = p_n \). With onboard redundancy (task can run onboard if link fails), success probability is

\[ p_{\text{succ}} = 1 - (1-p_n)(1-p_{\text{on}}), \]

where \( p_{\text{on}} \) is onboard task success. This motivates degraded safe modes onboard.

Consider \( N \) tasks. Let decision variable \( x_i \in \{0,1\} \) where \( x_i = 1 \) means task \( i \) runs offboard, else onboard.

Each task has compute \( C_i \), input size \( S_i \), and deadline \( D_i \). Define onboard and offboard times \( T_{\text{on},i} \) and \( T_{\text{off},i} \) as in Section 2.

A basic placement objective minimizing total expected completion time:

\[ \min_{\mathbf{x}} \sum_{i=1}^N \Big[(1-x_i)T_{\text{on},i} + x_iT_{\text{off},i}\Big] \quad \text{s.t.} \quad (1-x_i)T_{\text{on},i} + x_iT_{\text{off},i} \le D_i,\;\forall i. \]

This is a 0–1 constrained optimization (like knapsack). A greedy heuristic: offload tasks with the largest positive time savings \( \Delta_i = T_{\text{on},i} - T_{\text{off},i} \), while respecting deadlines and network capacity.

We compute \( T_{\text{on}} \), \( T_{\text{off}} \), and decide placement for a set of tasks using the greedy rule.

import numpy as np

# Task specs: (C_i FLOPs, S_i bits, S_r_i bits, deadline D_i s)
tasks = [
    (8e8, 5e6, 2e5, 0.20),   # heavy compute, moderate data
    (1e7, 2e6, 1e5, 0.05),   # light compute, tight deadline
    (5e8, 1e7, 5e5, 0.50)    # heavy compute, large input
]

f_on  = 2e9    # onboard FLOPs/s
f_off = 2e11   # offboard FLOPs/s (edge GPU)

B_u, B_d = 50e6, 80e6  # uplink/downlink bits/s
T_p = 0.008           # propagation/stack delay (s)

P_on = 12.0           # onboard compute power (W)
P_tx, P_rx = 2.5, 1.8 # radio powers (W)
P_idle = 6.0          # idle robot power while waiting (W)

def times_and_energy(C, S, Sr):
    T_on = C / f_on
    T_off = S/B_u + 2*T_p + C/f_off + Sr/B_d

    E_on = P_on * T_on
    E_off = P_tx*(S/B_u) + P_rx*(Sr/B_d) + P_idle*(2*T_p + C/f_off)
    return T_on, T_off, E_on, E_off

results = []
for i, (C,S,Sr,D) in enumerate(tasks):
    T_on, T_off, E_on, E_off = times_and_energy(C,S,Sr)
    results.append((i, T_on, T_off, E_on, E_off, D))

# Greedy by time savings while meeting deadlines
results.sort(key=lambda r: r[1]-r[2], reverse=True)

placement = {}
for i, T_on, T_off, E_on, E_off, D in results:
    if T_off <= D:
        placement[i] = "offboard" if T_off < T_on else "onboard"
    else:
        placement[i] = "onboard"  # must keep onboard to meet deadline

for r in results:
    i, T_on, T_off, E_on, E_off, D = r
    print(f"Task {i}: Ton={T_on:.3f}s, Toff={T_off:.3f}s, "
          f"Eon={E_on:.2f}J, Eoff={E_off:.2f}J, D={D:.2f}s -> {placement[i]}")
      

You can vary \( B_u,B_d,T_p,f_{\text{on}} \) and observe phase-margin limits from Section 3.

Below is a minimal UDP ping-style latency estimator. It illustrates how to empirically estimate \( T_p \) in \( T_{\text{off}} \).

#include <iostream>
#include <chrono>
#include <cstring>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <unistd.h>

int main() {
    const char* server_ip = "192.168.1.10";
    const int port = 9000;
    const int N = 100;

    int sock = socket(AF_INET, SOCK_DGRAM, 0);
    if (sock < 0) { std::cerr << "socket error\n"; return 1; }

    sockaddr_in server{};
    server.sin_family = AF_INET;
    server.sin_port = htons(port);
    inet_pton(AF_INET, server_ip, &server.sin_addr);

    char msg[32] = "ping";
    char buf[64];

    double rtt_sum = 0.0;
    for (int i = 0; i < N; ++i) {
        auto t0 = std::chrono::steady_clock::now();
        sendto(sock, msg, strlen(msg), 0,
               (sockaddr*)&server, sizeof(server));

        socklen_t len = sizeof(server);
        recvfrom(sock, buf, sizeof(buf), 0,
                 (sockaddr*)&server, &len);
        auto t1 = std::chrono::steady_clock::now();

        double rtt = std::chrono::duration<double>(t1 - t0).count();
        rtt_sum += rtt;
    }

    std::cout << "Avg RTT: " << (rtt_sum / N) << " s\n";
    close(sock);
    return 0;
}
      

In practice, measure RTT under load, then use \( T_p \approx \text{RTT}/2 \).

This client sends a serialized sensor packet to an offboard service and times the round trip. It complements the C++ RTT example.

import java.io.*;
import java.net.*;
import java.util.Arrays;

public class OffboardClient {
    public static void main(String[] args) throws Exception {
        String host = "192.168.1.10";
        int port = 9100;

        byte[] sensorPacket = new byte[5000]; // example payload
        Arrays.fill(sensorPacket, (byte)1);

        try (Socket socket = new Socket(host, port)) {
            DataOutputStream out = new DataOutputStream(socket.getOutputStream());
            DataInputStream in   = new DataInputStream(socket.getInputStream());

            long t0 = System.nanoTime();

            out.writeInt(sensorPacket.length);
            out.write(sensorPacket);
            out.flush();

            int replyLen = in.readInt();
            byte[] reply = new byte[replyLen];
            in.readFully(reply);

            long t1 = System.nanoTime();
            double rtt = (t1 - t0) * 1e-9;

            System.out.println("Round-trip time: " + rtt + " s");
        }
    }
}
      

The reply could be a perception result or plan. You would then evaluate \( T_{\text{off}} \) against deadlines.

Matlab can compute the maximum admissible delay before instability. For a known \( G(s) \), \( K(s) \):

% Example plant and controller (students know linear control)
s = tf('s');
G = 1/(s*(0.5*s+1));     % simple second-order-like plant
K = 5*(s+2)/(s+10);      % lead/lag-ish controller

L = series(K,G);
[GM, PM, wgc, wpc] = margin(L);

Td_max = PM*pi/180 / wgc;  % Td < PM / wgc (Section 3)
fprintf('Phase margin = %.2f deg, wgc = %.2f rad/s, Td_max = %.3f s\n', PM, wgc, Td_max);

% In Simulink:
% - Use Transfer Fcn blocks for G and K
% - Insert a Transport Delay block of value Td
% - Sweep Td to verify closed-loop stability boundary.
      

This directly implements the bound \( T_d < \phi_m/\omega_c \).

Problem 1 (Offload Threshold): A perception task needs \( C=2\times 10^{10} \) FLOPs and sends \( S=8\times 10^6 \) bits to a server. Onboard compute rate is \( f_{\text{on}}=5\times 10^9 \) FLOPs/s, offboard is \( f_{\text{off}}=2\times 10^{11} \) FLOPs/s. Network has \( B_u=40\,\text{Mbps} \), \( B_d=80\,\text{Mbps} \), \( S_r=2\times 10^5 \) bits, and \( T_p=5\,\text{ms} \). Decide onboard vs offboard by comparing times.

Solution:

\[ T_{\text{on}} = \frac{2\times 10^{10}}{5\times 10^9} = 4\text{ s}. \]

\[ T_{\text{off}} = \frac{8\times 10^6}{40\times 10^6} +2(0.005) +\frac{2\times 10^{10}}{2\times 10^{11}} +\frac{2\times 10^5}{80\times 10^6}. \]

\[ T_{\text{off}} = 0.20 + 0.01 + 0.10 + 0.0025 = 0.3125\text{ s}. \]

Since \( T_{\text{off}} < T_{\text{on}} \), this task should be offloaded (if deadlines allow).

Problem 2 (Delay Stability Bound): A delay-free closed loop has crossover frequency \( \omega_c=12\,\text{rad/s} \) and phase margin \( \phi_m=50^\circ \). Find the maximum admissible round-trip delay for offboard control.

Solution:

\[ T_d < \frac{\phi_m}{\omega_c} = \frac{50\pi/180}{12} = \frac{0.8727}{12} \approx 0.0727\text{ s}. \]

So the delay must be below about \( 73 \) ms. If measured RTT is 120 ms, stabilizing control must be onboard.

Problem 3 (Energy Offload Criterion): A task requires \( T_{\text{on}}=0.8 \text{ s} \) onboard at \( P_{\text{on}}=10\text{ W} \). Offboard time is \( T_{\text{off}}=0.3\text{ s} \). The upload takes 0.15 s with \( P_{tx}=3\text{ W} \), download takes 0.02 s with \( P_{rx}=2\text{ W} \), waiting power is \( P_{\text{idle}}=5\text{ W} \). Is offloading energy-saving?

Solution:

\[ E_{\text{on}} = P_{\text{on}}T_{\text{on}} = 10\times 0.8 = 8\text{ J}. \]

\[ E_{\text{off}} = 3(0.15) + 2(0.02) + 5(0.3-0.15-0.02) = 0.45 + 0.04 + 5(0.13) = 1.14\text{ J}. \]

Yes: \( E_{\text{off}} < E_{\text{on}} \). Offloading saves significant battery energy here.

Problem 4 (Compute-Placement Feasibility): Two tasks have deadlines \( D_1=0.05\text{ s}, D_2=0.3\text{ s} \). Their times are: \( T_{\text{on},1}=0.04, T_{\text{off},1}=0.06 \), \( T_{\text{on},2}=0.5, T_{\text{off},2}=0.25 \). Find a feasible placement minimizing total time.

Solution:

Task 1 cannot be offloaded because \( T_{\text{off},1} = 0.06 > D_1 \). So it must be onboard. Task 2 meets its deadline either way, but offboard is faster. Therefore:

\[ x_1=0,\quad x_2=1. \]

Total time \( = T_{\text{on},1}+T_{\text{off},2}=0.04+0.25=0.29 \) s.

We compared onboard and offboard computing with explicit models for execution time, communication latency, bandwidth, energy, and reliability. Using linear-control delay analysis, we proved that offboard delays reduce phase margin by \( \omega_c T_d \) and derived the stability bound \( T_d < \phi_m/\omega_c \). Offboard computing is thus best for compute-heavy but delay-tolerant tasks, while safety-critical real-time control should remain onboard.