Section 55.3: Edge vs. cloud-robot computation; asynchronous inference

For Edge vs. cloud-robot computation; asynchronous inference, deployment quality is measured by the command stream, safety monitor state, and replayable evidence behind each command.

A Careful Control Loop
Technical illustration for Section 55.3: Edge vs. cloud-robot computation; asynchronous inference.
Figure 55.3A: Edge vs. cloud-robot computation tradeoff: latency-sensitive reactive control runs on-board, heavier perception and planning modules stream to a nearby edge server, and a cloud backend handles periodic policy updates and telemetry aggregation.
Big Picture

Edge vs. cloud-robot computation; asynchronous inference matters because compute placement is a safety and reliability decision. The section treats evaluation, uncertainty, safety, and deployment as one closed-loop contract rather than as separate checklist items.

Problem First

Cloud inference can add model capacity, but network loss, privacy constraints, and variable latency can break closed-loop control.

The practical question is therefore specific: which observation arrives, which state estimate is trusted, which action is allowed, which monitor can interrupt it, and which artifact proves the claim afterward?

Same-Artifact Rule

Every compared number in this section should be co-computed by one script on one task panel, with one seed plan and one saved artifact. That artifact carries success, failure, latency, safety, and robustness fields together.

Edge vs. cloud-robot computation; asynchronous inference evidence contract A closed-loop evidence diagram connecting observations, state estimates, actions, monitors, and a single result artifact. Observation sensor stream State estimate Action policy output Monitor barrier or alert One artifact metrics and logs
The evidence contract for Edge vs. cloud-robot computation; asynchronous inference keeps the observation, estimate, action, monitor decision, and result artifact in one traceable path.

Theory

Compute placement is a control allocation problem. Safety-critical loops must remain local, while cloud services are appropriate only when latency, privacy, and availability constraints still preserve the action contract.

A compact rule is to keep a computation local when it is both action critical and deadline sensitive. One simple score is

$$R = w_1 \cdot \text{criticality} + w_2 \cdot \text{latency sensitivity} + w_3 \cdot \text{availability risk} + w_4 \cdot \text{privacy cost}.$$

High-$R$ functions belong on the robot or on a trusted edge node. Low-$R$ functions, such as batch summarization, fleet analytics, or nonurgent semantic search, can move to the cloud.

Mechanism

The mechanism is observe, estimate, choose, constrain, execute, monitor, log, and review. Each verb has an owner in the deployment architecture and a field in the evaluation artifact.

Worked Example

A home robot may safely ask the cloud to summarize a room inventory, but it may not rely on the cloud to decide whether to brake before contacting a person or a wall. That distinction is architectural, not cosmetic.

tasks = {
    "emergency_stop": {"criticality": 5, "latency": 5, "availability": 5, "privacy": 2},
    "global_semantic_search": {"criticality": 1, "latency": 2, "availability": 2, "privacy": 3},
    "task_replanning": {"criticality": 3, "latency": 3, "availability": 3, "privacy": 2},
}

def placement_score(v):
    return v["criticality"] + v["latency"] + v["availability"] + v["privacy"]

placement = {
    name: ("local_or_edge" if placement_score(vals) >= 12  # score >= 12 means high combined criticality, latency, and availability demand; must stay local
           else "cloud_ok")
    for name, vals in tasks.items()
}
print(placement)
{'emergency_stop': 'local_or_edge', 'global_semantic_search': 'cloud_ok', 'task_replanning': 'local_or_edge'}
Code Fragment 55.3.1 shows a simple placement rule that maps task properties to compute location.

The expected output should separate what must remain available during network loss from what can tolerate delay. If a remote service appears in the local-or-edge set, the design implication is immediate: the system needs a colocated implementation or a safe degraded fallback.

Library Shortcut

The hand-built record is about 24 lines. In a production run, DVC, MLflow, Weights and Biases Artifacts, or a ROS 2 bag plus metadata file reduces the tracking code to a few calls while handling versioning, file storage, run ids, and reproducible retrieval. The hand-built version remains useful because it shows which fields the tool must preserve.

Practical Recipe

  1. Write the observation, action, monitor, metric, and artifact fields before selecting a model.
  2. Run a deterministic smoke test and one named perturbation from the panel.
  3. Log success, safety events, latency, energy or resource use, and recovery status in the same row group.
  4. Compare only methods evaluated by the same script on the same panel and seed plan.
  5. Attach a short postmortem to each failed rollout so the artifact remains useful after the plot is forgotten.
Common Failure Mode

Cloud dependence often sneaks in indirectly, through remote tokenization, centralized map lookup, or authentication handshakes that block local decision-making. Audit the entire dependency path, not just the planner call.

Practical Example

An embodied AI team applying Edge vs. cloud-robot computation; asynchronous inference should review a single run folder containing configuration, model version, rollout traces, monitor transitions, video or sensor replay, and the metric table. The review asks whether the evidence supports the deployment decision, not whether one isolated number looks good.

Research Frontier

Asynchronous robot foundation models increasingly split fast local control from slower cloud reasoning, with caches, fallbacks, and confidence-gated requests.

Self Check

Can you name the metric contract, perturbation panel, monitor state, and artifact id for Edge vs. cloud-robot computation; asynchronous inference? If any field is missing, the claim is not yet audit-ready.

Edge vs. cloud-robot computation; asynchronous inference becomes operational when the metric is tied to a runtime interface. The interface names the sensor stream, state estimate, action representation, timing budget, safety or robustness monitor, and deployment artifact.

The disciplined habit is to separate three claims. The conceptual claim explains why the method should help. The systems claim explains which interface it changes. The evidence claim records which measurement would convince a skeptical builder.

Practical Tool Choices For This Section
Tool or LibraryRole in Edge vs. cloud-robot computation; asynchronous inference
edge acceleratorsKeep perception and control close to sensors and actuators.
message queuesDecouple cloud planners from local control loops.
ROS 2 QoSSets reliability and freshness contracts for robot messages.

Cross-References

For Edge vs. cloud-robot computation; asynchronous inference, connect benchmark design, sim-to-real transfer, uncertainty, and safety barriers through the deployment artifact that will be checked before release.

Lab: Build The Artifact First

Create a JSON or Parquet artifact for five rollouts of Edge vs. cloud-robot computation; asynchronous inference. Include fields for configuration, seed, perturbation, metric values, monitor state, and a short failure label. Then rerun the same panel with one changed policy setting and verify that both methods can be compared row by row.

When a cloud-edge architecture fails, classify the failure as uplink loss, stale cache, remote timeout, inconsistent model versions, bandwidth collapse, or unsafe fallback routing. Then replay the exact sequence with the network behavior fixed at one perturbation setting.

A Useful Annoyance

For Edge vs. cloud-robot computation; asynchronous inference, schema strictness is cheaper than discovering a missing field during a moving-robot trial; require the log before comparing outcomes.

Key Takeaway

Edge vs. cloud-robot computation; asynchronous inference is valuable when it changes the closed-loop decision and leaves behind evidence that another builder can audit.

Exercise 55.3.1

Design a same-artifact evaluation for this section. Specify the environment, rollout panel, seed plan, metric fields, monitor fields, one perturbation, and one rollback or recovery rule.

Section References

Quigley, M. et al. ROS: an open-source Robot Operating System. ICRA Workshop, 2009.

Use for the robotics middleware lineage behind nodes, topics, services, bags, and deployment boundaries.

OpenTelemetry project documentation. https://opentelemetry.io/docs/

Use for tracing, metrics, and logs when robot deployment evidence must connect software events to runtime behavior.

What's Next

After Edge vs. cloud-robot computation; asynchronous inference, the next section should reuse the artifact schema while changing one deployment interface or failure mode, so comparisons remain auditable.