A robot cannot wait for the cloud

The robot has one more room to inspect. It crosses the doorway, the metal door closes behind it and the connection begins to drop. On the operator’s screen, nothing alarming happens: the last image is still there. Inside the room, however, the robot has reached a situation that the screen cannot show.

This is a hypothetical inspection, but a useful way to think about edge AI: running computation near the machine instead of depending on a distant service for every answer. The important question is what work survives the interruption. Follow the robot from the lost connection through the moment it comes back, and the idea becomes more concrete.

The robot and the assistant live on different clocks

A chat assistant can spend 10 seconds researching while we wait. A moving robot may have to react before that answer exists. Its deadline comes from speed, stopping distance and the space around it. A thoughtful answer that arrives after the robot needed to brake is not useful for that part of the job.

Not every decision is that urgent. Choosing tomorrow’s inspection order can take time; responding to an obstacle cannot use the same schedule. Separating the jobs keeps immediate control local while a larger planner helps with decisions that can wait. The local controllers and protective behaviour still need their own verification.

Try delaying or removing the connection in the model below. The remote part changes, but the local core stays in place. The point is to decide what the robot can do while help is unavailable, instead of discovering the answer after the door closes.

Figure 1

The door closes. What remains on the robot?

Change the remote connection and follow the local path that stays available.

Choose a situation

ConnectedThe answer is lateConnection lost

1. SensorsCurrent observations
2. Local computeBounded task and control
3. Remote planningHelpful when available

The robot can ask for slower planning help.

What changed?

The planning service is reachable.

In this example

Immediate response stays local; remote planning adds support.

What it means for the work

The service helps without owning every movement.

The robot needs a defined response while it waits.

What changed?

The remote result arrives more slowly.

In this example

The example keeps the local path working.

What it means for the work

A late plan needs checking against the situation that exists now.

Losing assistance should not leave the next step undefined.

What changed?

The remote service is unavailable.

In this example

The local core remains; task rules decide whether to act or wait.

What it means for the work

The operator needs a waiting state, or an explicit unknown state.

Smaller models help, if the useful behaviour stays

How do we fit useful AI onto a small computer? Gemini Robotics On-Device and Hugging Face’s SmolVLA offer concrete examples of locally usable robotics models. Their tasks and hardware differ, so I see them as starting points to investigate, rather than interchangeable software for any robot. ^{[1] [2]}

Distillation and quantization are two ways of reducing the load. A smaller model can learn from a larger teacher; numerical weights can be stored with fewer bits. Hinton and colleagues’ work and AWQ explain those approaches. For our robot, the follow-up is practical: what happens to a partly hidden object or an unfamiliar camera view after compression? ^{[3] [4]}

SmolVLA also separates action execution from inference, allowing work to continue while the next calculation is prepared. That makes the arrangement useful to study, and leaves another question. If someone moves an object, which queued movements still make sense? The robot needs a chance to look again before a smooth sequence becomes an outdated one.

The test has to last longer than the demonstration

Leave the robot working for a while. The camera is producing data, motors are drawing power and the computer is warming up. The model shares battery and memory with everything that keeps the machine running. A quick result on an idle computer tells only part of the story of a long inspection.

I would measure the time and energy needed to finish a useful task, including the occasional slow response. A good average can hide the delay that matters. The goal is not the smallest model at any cost. It is a machine whose resources match the work it has promised to do, including what happens when a deadline is missed.

The hardware detail below brings that physical budget into view. Cooling, battery capacity and camera input are part of the AI design. They help explain why a model can fit in storage and still be a poor fit for the robot’s working day.

When the connection returns, the past comes with it

The door opens and messages begin arriving. One image is old; a task may already be complete. Reconnecting does not turn either into new work. The operator needs to know when the image was taken and whether the instruction was accepted, not simply that the network icon is green.

ROS 2 provides communication policies for reliability, deadlines and message lifespan. The application still has to interpret them. A late image may explain an earlier stop without showing that the passage is clear now. A delayed completion report should close its original task instead of setting off another attempt. ^[5]

Waiting and catching up therefore belong in the design. Depending on the tested task rules, the robot might stop, finish a permitted observation or wait at an agreed place. After reconnecting, both sides compare what happened before choosing what remains. The flow below separates immediate response from slower planning so they do not get confused.

Figure 2

Two time scales, two responsibilities

Local response

1. 01Sense

   Use current physical observations.

   ↓
2. 02Apply limits

   Keep protective control independent.

   ↓
3. 03Act or wait

   Follow the defined local behaviour.

Optional planning support

1. 01Describe the task

   Send only the context the planner needs.

   ↓
2. 02Consider alternatives

   Allow time for a broader plan.

   ↓
3. 03Check the result

   Check freshness and permission before use.

The useful measure is the work we recover

These interruptions are part of the research I want to pursue through NODERIQ. We can start in simulation: delay an observation, lose the connection and change a task before bringing it back. Then ask what work was saved, what was repeated and whether the person understood the state. That is a proposed evaluation, not a field result. ^[6]

A technician should not have to restart the whole inspection because a door interrupted the link. Nor should the screen leave them guessing whether the last instruction ran. Smaller models can help. The complete benefit comes when a robot and a person can return to the same job without losing the thread of what already happened.

Figure 3

The research behind the story

Further reading	The useful idea	The next question
Gemini Robotics On-Device · 2025	The useful idea A robotics model designed for local inference and reduced network dependence.	The next question What response time and resource use does our robot actually achieve?
SmolVLA · 2025	The useful idea Combines a compact VLA architecture with asynchronous action execution.	The next question How does the action queue respond when the scene changes?
AWQ · 2023	The useful idea Reduces weight storage with activation-aware low-bit quantization.	The next question Which task behaviours change after compression?

Sources

1. Google DeepMind: Gemini Robotics On-Device deepmind.google
2. Hugging Face: SmolVLA huggingface.co
3. Hinton, Vinyals and Dean: Distilling the Knowledge in a Neural Network arxiv.org
4. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration arxiv.org
5. ROS 2: Quality of Service Settings docs.ros.org
6. Neura Parse: NODERIQ Research Programme neuraparse.com