How to Make a Cloud Read a Drone's Mind (and Cut Data Usage by 94%)

Why Do Connected Machines Waste So Much Bandwidth?

Imagine a friend who is riding the bus home. Every single second, they call you. "Still on the bus." Click. Ring. "Still on the bus." Click. Ring. "Still on the bus." You would block their number. Then you would unblock it, because what if the bus actually crashes or something unexpected happened to them?

That is why and how most remote machines talk to the cloud currently. A delivery drone, a warehouse robot, a wind turbine: they all send a steady stream of readings to a base station, many times a second. Most of those readings say the same thing: nothing new, everything is going as expected. The network pays full price for zero news.

Before we dive deep into the article, now is the time for an honest disclaimer. I did not actually build a drone and took the measurements; these were all simulator generated. Continuing from my previous test use case, I used CartPole, a tiny simulated cart with a pole on top, and what gets sent are a few numbers, not a video stream. The drone is the motivation, and the simulation does not change the moral of the story I want to tell here at all — the core still remains the same.

What I did build is a simple way to send only the surprises. By the end of this tutorial you will know:

• what a world model is,

• how two copies of the same world model can keep a remote machine and the cloud in sync,

• how to build it in PyTorch, with code you can run on a laptop,

• and how much data it really saved, measured honestly against the obvious alternatives, including the ones that made my fancy AI look silly for a while.

No background on anything special needed. I explain every word the first time it shows up. If you read my first article on world models, you will recognise a few old friends. If not, you will still be fine, you can trust me on that.

···

What Is a World Model?

Simply put, a world model is a program that can imagine it is a neural network that has learned to predict what happens next. You hand it two things: the situation right now, and the action being taken. It hands you back the situation one moment later. It does not learn this from a physics textbook. It learns it by watching a lot of examples, the way you learned that a dropped cup falls down without anyone handing you an equation.

The neat part is what you can do once you have one. You can feed the model's own answer back into it as the next situation, and then again, and again. The model plays the future forward in its head, with no real machine involved. I will call that imagining.

One detail matters for later. The model in this article is not allowed to see everything. It sees only two numbers: where the cart is and how far the pole is tilted. It never sees speeds. This is on purpose, because a camera tells you where things are, not how fast they are going. To work out a speed, you need to remember where things were a moment ago. So the model carries a small memory: sixty-four numbers that it updates at every step, like a scribbled note passed from one moment to the next. (The technical name is a GRU. You can forget that if you like.)

The Test Bed: A Cart, a Pole, and Some Wind

CartPole is one of the oldest toy problems in AI. A cart slides along a rail. A pole is balanced on top of it, doing its best to fall over. You can push the cart left or right, 50 times a second. If you have ever balanced a broom on your hand, you already understand the game. I made two changes to make it feel more like a drone.

First, the cart does not just balance in place. It follows a planned route: a smooth swing back and forth along the rail, like a drone flying a known path. Second, I added wind: random gusts that shove the pole at random moments. The cloud cannot feel the wind. That matters in a minute.

And both the cart and the cloud know the same rulebook for how to push. It is a simple rule: move the cart under the falling pole, with a gentle pull towards the planned route. The rule only uses the two numbers the model can see, plus the change since the last step, which works as a stand-in for speed.

How to Save the Bandwidth

Now the trick. Give the drone and the cloud the same world model, the same route, and the same rulebook.

Then the cloud does not need to be told what the drone is doing. It can imagine it. Step by step, the cloud runs its own copy of the world model and pictures where the drone should be right now. In a calm world, that picture is close to the truth. The cloud closes its eyes, and still knows where the drone is. The data sent drops to nearly nothing. High fives all round.

Unfortunately, the real world immediately disagrees.

Why Does the Cloud's Imagination Drift?

Two reasons. The first is the obvious one: wind. A gust hits the real pole. The cloud feels nothing, so in its daydream the drone keeps flying beautifully while the real one gets shoved sideways.

The second reason is the sneaky one, and it is more important: the world model itself is never perfect. Even in completely still air, every imagined step is off by a tiny amount. The next step is built on top of that tiny error, and the next one on top of that. Small mistakes snowball. Left alone long enough, every imagined future turns into fiction. (In my previous article, the model's imagined pole ended up lying flat on the floor after 100 steps, while the real one never wobbled.)

So the drone has to send updates, but there is a trap. Suppose the drone sends a plain update: "I moved two metres left." The cloud dutifully adds that to its own picture of where the drone was. But its picture is already wrong. The update lands on the wrong starting point, and the error survives, now wearing a fake moustache.

What the drone actually needs to tell the cloud is not where it is. It is how wrong the cloud currently is. And to know that, the drone has to know what the cloud believes. Which sounds impossible, until you notice something.

···

Shadow Tracking: How the Drone Reads the Cloud's Mind

The cloud's imagination is not a mystery. It is a small program, running a model the drone also owns, fed inputs the drone also knows. So the drone simply runs a second copy of the cloud's imagination on its own computer. I call that copy the shadow.

The shadow is not a guess about what the cloud believes. It is what the cloud believes: the same model, the same starting point, the same messages, the same arithmetic. Feed two identical programs identical inputs and you get identical outputs. That is just how computers work, and for once it is working in our favour.

So at every step the drone holds two pictures:

1. Reality: where the drone really is, from its own sensors.

2. The shadow: where the cloud thinks the drone is.

It compares them, and the rule is simple:

gap = | reality − shadow |, and a correction is sent only if the gap is bigger than the limit.

The limit (engineers call it a threshold) is how much error you are willing to live with. Smaller gap, stay silent. Bigger gap, send the difference: two numbers, one for the cart position and one for the pole angle. Both the cloud and the shadow apply that correction at the same moment, so they stay identical twins.

Here is that idea as real code, the heart of the whole thing:

Four lines. The drone stays completely silent until the picture goes wrong by more than the limit. And since the drone always knows what the cloud believes, the cloud can never be secretly wrong by more than the limit. The code even checks, at every step of every test game, that the shadow and the cloud hold exactly the same numbers:

It never failed, across roughly two million checks.

···

How to Build the World Model in PyTorch

The full code is on GitHub in the 02_silent_edge folder. In this article I only include the snippets that matter. My first version of the model was not good. How it failed is the story worth telling, because the fixes are the most useful lessons here.

Version one: good in the lab, beaten by a straight line

The first model predicted each next step from scratch. I measured how many corrections it needed and compared it to two very dumb alternatives, which I will call the baselines (the simple methods your clever idea has to beat, or it is not clever):

• No AI ("freeze"): the cloud assumes the drone has not moved since the last message.

• Straight line: the cloud assumes the drone keeps moving at the speed it had between the last two messages.

The result was humbling. My AI lost to the straight line: a neural network was beaten by a ruler. While investigating it, I realized two big things were going wrong, plus one small one. Fixing them made the difference.

Fix number one: just tell the cloud which way you pushed

In version one, the cloud also had to guess which way the drone pushed at every step, by running the rulebook on its own imagined picture. Although it sounds elegant, in reality it was a disaster.

The rulebook flips between "push left" and "push right" almost every single step. So the tiniest difference in the imagined picture flipped the guess, and the cloud guessed wrong between 15 and 45 percent of the time. Every wrong guess shoved the imagination off in the wrong direction.

The fix is almost insultingly simple: send the push. One bit per step, which is 50 bits per second. A bit is the smallest piece of data there is, a yes or no. It is tiny, but it is not free, so every result later in this article includes that in the bill.

Fix number two: do not make a neural network relearn a straight line

Version one also carried a small amount of "neural noise": tiny errors that a network adds when it re-invents even the easy parts of the motion. The fix is a good general rule:

If a simple formula already explains most of the behaviour, let the network not learn the formula from scratch, rather let it learn only what the formula gets wrong.

Most of the time, a cart coasts in a straight line. So the model now starts with the straight-line guess ("keep moving as you moved last step") and the neural network only learns a correction on top:

next position = now + (now − one step ago) + learned correction

And here it is in the code:

One more small trick: the correction starts at exactly zero before training. So an untrained model is the straight-line guess, and training can only make it better, never start from a mess.

Fix number three (a small one): train it to imagine, not just to predict

A model can be great at guessing one step ahead and still terrible at imagining thirty, because imagining means feeding its own mistakes back to itself. So during training I made it do exactly that: after eight real steps to warm up its memory, it has to imagine the next 32 on its own, and it is graded on the whole daydream.

That second line is the one that matters. The model's output becomes its next input. That is the difference between a model that predicts and a model that imagines.

How much did these changes help? After 32 imagined steps on games it had never seen, the plain straight line was off by about 22 centimetres. The model with the learned correction was off by about 4 millimetres. The whole model has 13,954 numbers and trains in about 13 minutes on a prehistoric graphics card.

A sneaky problem: the model's memory gets confused by corrections

Remember that the model keeps a memory that calculates speeds from how positions change. Now imagine the cloud gets a correction: suddenly the position jumps. The memory reads that jump as "the drone just sped up enormously", and its speed estimate is now wrong, even though the position is right.

The fix costs no extra data. Both sides know when the last correction happened, so both can assume the error grew evenly since then, undo that share of it in the last few steps, and replay those steps through the model. The memory is rebuilt from the repaired history, like fixing a typo on page two and re-reading the story so the ending still makes sense.

···

Results: How Much Bandwidth Did the World Model Save?

I ran 100 test games for every combination of settings, each up to 10 seconds long, on routes and wind patterns the model had never seen. Four approaches were compared:

• Streaming everything: send the full state at every step. That is 50 messages a second, or 3,200 bits per second (two numbers of 32 bits each, 50 times a second).

• No AI (freeze): send a correction when the gap is too big; the cloud assumes nothing moved.

• Straight line: same, but the cloud keeps moving at the last known speed.

• World model: same send rule, with the one-bit push sent every step.

Each one was tested at three limits for how far the cloud's picture may drift. Tight means 2 centimetres or 0.01 radians of pole tilt. Medium is 5 centimetres or 0.02 radians. Loose is 10 centimetres or 0.03 radians. (A radian is just another way to measure an angle. 0.01 of one is about half a degree.)

The world model sent the fewest bits in every single combination I tested: all 3 limits at all 5 wind strengths. There are two ways to read the numbers, and I want to show you both.

Against streaming everything, the saving is

saving = 1 − (bits sent ÷ bits needed to stream everything)

which comes out at 87% at the tight limit, 93% at the medium limit and 94.5% at the loose limit.

But streaming is an easy target. Beating "send everything" is like winning a race against a man who is carrying a fridge. The fairer comparison is against the best of the two simple methods. Against those, the world model sent 69% fewer bits at the tight limit, 53% fewer at the medium limit and 26.5% fewer at the loose limit.

Notice that the advantage shrinks as the limit gets looser. At the loose limit every method sends few corrections, and a growing slice of the world model's bill is the fixed 50 bits per second for the push: more than a quarter of its 176 bits. The tighter your accuracy requirement, the more a good model is worth.

Also notice that the straight line does worse than freezing at the tight limit. The speed it works out from two messages is noisy, and a noisy speed sends the guess flying. Being a little clever can be worse than being lazy.

One more claim, and this one is not a measurement but a consequence of the design: because the drone always knows exactly what the cloud believes, the cloud was never further off than the limit, at any step of any test game.

What Does One Gust Look Like?

Here is one gust of wind, seen from the inside. The top plot is the pole angle. The black line is reality. The red line is the cloud with corrections. The grey dashed line is what the cloud would believe if it never received a single correction.

The plot underneath shows how wrong the cloud is, as a percentage of the limit. It climbs until it crosses 100%, a correction goes out, and it drops back to zero. Again, and again.

Two things stand out. First, the never-corrected line drifts away from reality steadily, even between gusts. That is the model's own tiny mistakes adding up, the second cause of drift from earlier. Second, right after the strongest gust, there is a short burst of corrections rather than a single one. The cloud's memory needs a few corrections to catch up with the new speed. Then everything goes quiet again.

When Does the Shared World Model Stop Saving Data?

Stronger wind means more surprises, and more surprises mean more corrections. That is how it should work. The bottom row of the plot above shows exactly that.

At the tight limit, the world model went from 4.1 corrections per second in still air to 6.7 in the strongest wind I tested. The simple baselines stayed between 19 and 24 corrections per second the whole way.

So the cost rises gently, in proportion to how unpredictable the world becomes, instead of falling off a cliff. That is the behaviour you want. But there is a catch, and I am going to put it in writing: the strongest wind I tested is also the strongest wind the model saw during training. Beyond that, I have no measurements, and I would not assume the curve stays so polite. (In that strongest wind, the pole also fell in some of the games, so games lasted 380 of a possible 500 steps on average. All methods faced exactly the same games, so the comparison is still fair.)

Here are four other limits, stated plainly.

Bits are not packets. The push costs one bit a step. If you send each bit in its own network packet, the packet's envelope is far bigger than the one-bit letter inside it, and you would send 50 packets a second, the same number as streaming. The savings here are real in the amount of data, not in the number of packets. To save packets too, you would batch the pushes (which makes the cloud run a fraction of a second behind), or attach them to the corrections, or skip them entirely in systems where the cloud is the one issuing the commands.

The network was perfect. No delays, no lost messages. If one correction is lost, the drone's shadow and the real cloud silently disagree, and the drone has no idea. Real systems fix this with receipts ("message received!") and an occasional full reset. Both cost data.

Both copies must do exactly the same arithmetic. My copies ran on the same computer. Two different computers can disagree in the very last decimal place, and over many steps that small gap can grow. Regular resets cover this as well.

It is a cart in a simulator. CartPole has two visible numbers and well-behaved physics. A real drone has far more of both, and a noisier world.

None of these kill the idea. They are the parts of it that a real deployment has to pay for.

Why Not Just Use Physics Equations?

A fair question. If you know the exact equations for your machine, use them: a physics solver is cheaper, faster and needs no training. A world model earns its place when the dynamics are too complicated to pin down and only partly understood, or available only as recorded data. CartPole has tidy textbook equations. A delivery drone in a crosswind, carrying a parcel of unknown weight, does not.

···

Key Takeaways

If you do not want to learn more than five things from this article, make them these:

1. Send surprises, not commentary. If the receiver could already guess the message, do not send it.

2. Keep a shadow copy of the other side. Two identical programs with identical inputs give identical outputs, so the sender can know exactly what the receiver believes. That turns guesswork into bookkeeping.

3. Do not make a neural network relearn what a formula already knows. Start with the straight line; let the network learn the bend.

4. Train for the job you will actually do. If the model has to imagine, train it on imagining, not just on one-step guesses.

5. Compare against dumb baselines, not just against "send everything". Mine beat streaming easily and still lost to a straight line for a while. The baseline is where you find out if your idea is real.

The cheapest message is the one you never send. The second cheapest is the one that carries only what the other side could not have worked out on its own.

The cloud can close its eyes now. The drone will tap it on the shoulder if anything interesting happens.

···

All images in this article have been generated using Claude Opus. All the code is in the 02_silent_edge folder of the CartPole-Daydream repository: four scripts, no command-line options. Run collect_data.py, train.py and imagine.py in that order, or skip straight to imagine.py, because a trained model is included. The first article in this series, on how to build the world model from scratch, is here.