Why Some Robots Feel Instant and Others Feel Laggy

A robot feels instant when each step finishes before the next one is due, under ROS 2, a shared-memory middleware, or one program. Lag is rarely raw speed; it is the wait that appears when work piles up behind something slower. So a shared-memory middleware such as HORUS helps only when the pile-up is data moving between programs, not when your own code is slow. The rest of this post is for someone whose first robot works but responds like a slow website, and who wants to know which part to blame.

You press the key and the robot moves. Not straight away. There is a beat first, short enough that you cannot time it with a stopwatch and long enough that you feel it every single time. Then you stop pressing the key and the robot keeps going for a moment after you stopped, which is worse.

Somebody else's demo video does not do this. Their arm looks like it is attached to the person's hand. Yours looks like a video call with a poor connection. The motion arrives, it just arrives late, and by the time it does you have already corrected for it and now you are fighting your own robot.

The confusing part is that the computer does not look busy. Nothing sits at the top of the process list. The camera reports that it is running at the rhythm it promised. Your own code returns quickly when you time it. Every part insists it is fine and the whole thing still behaves like it is thinking about it.

You have read the word latency and it did not help, because nobody ever says which latency they mean.

Why do some robots feel instant and others feel laggy?

Because feeling instant is about the whole chain from sensor to motor keeping a steady rhythm, not about any single part being quick. Every robot has the same chain: something senses, something decides, something moves. A robot feels instant when each link hands over before the next link needs it, over and over, at the same pace. A robot feels laggy when one link takes longer than its slot, because the chain runs at the speed of its slowest member.

That is how a robot with a quick computer, quick code and quick motors still ends up feeling like it is underwater. If the camera picture sits in a queue before your code sees it, your code is deciding about the past. The decision is correct for a world that existed a moment ago, and the arm arrives where the ball used to be.

The second half of the answer is steadiness. A robot that is always slightly behind feels sluggish but predictable, and a person adapts within a minute. A robot that is sometimes behind and sometimes not feels broken, because there is nothing to adapt to.

What does lag actually mean inside a robot?

Lag is the age of the information a robot is acting on. Put a stopwatch on one decision: the moment light hit the camera sensor, and the moment a wheel actually changed speed because of what that light showed. Everything between those two moments is the lag, and most of it is not computing. It is waiting.

The waiting happens in queues. A picture is taken, then waits to be handed to the next program, then waits behind the picture before it, then waits for the program that reads it to finish whatever it was already doing. Stack three such handovers and the picture your robot is reasoning about was taken several beats before the robot acts on it.

There is a second word that belongs next to this one and matters more than the first. Jitter is how much the lag varies from one cycle to the next. Steady lag can be planned around. Varying lag cannot, because nothing in the robot knows how stale the picture is this time. Latency, jitter and determinism explained simply untangles all three words properly.

What are your actual options for making a robot feel instant?

There are six things you can do, and the first two cost nothing. You can send less data, which usually means a smaller picture, since a smaller picture is cheaper at every step of the chain. You can merge two programs into one, so a handover that used to be a message becomes a direct call. Then comes the middleware question, where two answers sit next to each other: ROS 2 packs each message up and delivers a copy to every program that asked for it, giving you drivers, navigation and tools in return, while HORUS is an open-source real-time robotics middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised at all, published under Apache-2.0, validated in simulation, and carrying no navigation or drivers of its own.

The last three options are blunter. Buy a quicker computer, which helps only if thinking was the wait. Protect the important work so other programs cannot interrupt it. Or accept the lag and design the robot around it.

How do these options compare side by side?

Read the last column first, because it eliminates faster than the others. Most first robots can strike three rows immediately, and the real choice is usually between two neighbours.

Does this feel different for a hobbyist and for a company?

Yes, because the two are judged by different people to different standards. On a hobby robot, you are the only person who ever feels the lag, and you adapt to it without noticing within a day of driving the thing. That is a legitimate answer rather than a cop-out: a robot that is slightly behind and always behind by the same amount is perfectly usable, and chasing it costs weekends you meant to spend on the part you actually cared about.

On a product, the lag is felt by somebody who did not build the robot and has no patience for its excuses. It shows up in ways nobody predicted. A person hands the robot a cup and lets go too early. An operator over-corrects on a joystick and the machine swings past the target. Somebody presses stop and the robot travels a hand's width further than expected, which is the moment lag stops being an annoyance.

So decide who feels it. If the answer is only you, spend the effort elsewhere and revisit the question when somebody else is in the room.

Does your hardware decide how instant a robot can feel?

Hardware sets a floor you cannot argue with, and most robots sit nowhere near their floor. A camera that produces a new picture on its own rhythm cannot tell you anything about the moments in between. A motor controller that accepts commands on its own schedule ignores whatever you send between its slots. Those limits are physical and no software changes them.

Above the floor, hardware matters less than people expect. A small board with several programs passing large pictures around has a queueing problem rather than a thinking problem, and a stronger board queues faster while still queueing. A robot spread across a compute box and a laptop has a different problem again, because the network adds a wait that changes with the room you are standing in.

The most useful thing to know about your own machine is where the big data lives and whether it has to cross a wire to be useful. Whether your robot should run one computer or several is the decision sitting underneath that, and it changes which fixes are available to you at all.

How much of this should you fix before your first demo?

Fix only what somebody watching would notice, and leave the rest. Before a demo the two changes worth making are both cheap. Send a smaller picture. Close anything that is watching the robot without needing to, because a live video preview on your laptop costs the robot real work, and shutting it before you present is the highest-value minute on this page.

What is not worth doing before a demo is changing the foundation. Swapping how programs talk to each other in the week before you show something is how demos get cancelled. That change is worth making afterwards, once you know which parts of the robot are staying.

There is a middle case worth naming. When the demo is teleoperation, with a person driving and watching a screen, the lag is the demo. Nobody can drive through a delay they can feel, and no amount of good behaviour elsewhere covers it up. In that single case, fix the lag first and add features afterwards.

What skill level does fixing lag actually take?

Less than people assume for the first two thirds, and considerably more for the last third. Sending less data, closing a viewer and merging two programs are all changes a beginner can make in an afternoon, and between them they resolve most first-robot lag outright. None of them requires knowing anything about how messages get delivered.

The next step up is being able to tell waiting apart from working, which means stamping a picture with the time it was taken and checking how old it is when it finally gets used. That is ordinary programming rather than systems expertise, and it is the most valuable skill in this whole subject, because it turns an argument into an observation.

The last third is genuinely hard: choosing how programs exchange data, keeping important work from being interrupted, and reasoning about what the machine does when it is busy. That needs somebody comfortable reading below their own code. Most robots never get there. What a control loop is and why its timing matters is the right read before you do.

What happens to lag as a robot gets more demanding?

Lag stops being uniform and becomes occasional, which is a far harder problem to live with. A simple robot is either late or it is not, and the amount is the same every cycle, so you stop noticing. Add a camera, then a model, then logging, then a dashboard, and the robot develops moods. It behaves for ten minutes and then misses, and the misses cluster around whatever else was happening: a file being written, an unusually large picture, a second program waking up to do its housekeeping.

The way people describe this is that the robot got worse on the day they added something unrelated. That is nearly always the story, and the unrelated something is nearly always competing for the same machine.

The other thing that changes is who suffers. Early on, lag makes a robot feel slow. Later, lag makes a robot wrong, because a decision made on a stale picture is not a late decision, it is a decision about a world that has moved. Why your robot slows down as you add features follows that progression.

What do you give up by chasing instant response?

You give up simplicity, and simplicity is worth more than most teams admit while they are chasing a beat. Every step towards instant response makes a robot harder to understand. Merging two programs means a crash in one now takes the other down with it. Sharing memory between programs means two of them can read the same picture while it is being replaced, which is a class of bug that appears only when the machine is busy and never while you are watching for it.

You give up choices as well. Structuring everything around a single machine makes it awkward to move part of the robot onto a second machine later, and moving work off the robot is often the better answer for anything not on a deadline.

And you give up time that could have gone into making the robot do more. A robot that responds instantly and does one thing loses to a robot that is slightly behind and does five. Chase the lag when it is stopping the robot doing its job, not because instant sounds better than adequate.

When is ROS 2 the better choice?

Nearly always for a first robot, and specifically whenever the lag is not coming from messages. If the parts of your robot exchange joint angles, velocity commands and status readings, ROS 2 delivers those long before the next cycle needs them, and the messaging layer is not what you are feeling. If you need mapping, navigation or a visualiser, ROS 2 hands you those and a shared-memory middleware such as HORUS does not, so choosing on lag alone would cost you months of writing them yourself.

ROS 2 also wins whenever the robot spans machines. A compute board talking to a laptop, or a robot reporting to a fleet service, needs a network transport, and shared memory ends at the boundary of one computer, so it has nothing at all to offer that link.

The default is the default because it answers most robots well. The case for anything else begins when several programs on one board pass pictures every cycle, and it begins nowhere else. Everything before that point is your own code, your sensor, or a viewer somebody left open.

Is a faster computer the fix?

No, and here is why: a quicker computer only helps when the robot was genuinely thinking, and most lag is waiting rather than thinking. When a picture spends its life in a queue behind another picture, a machine with more cores works through that queue and the queue is still a queue. People buy the upgrade, feel a small improvement because everything got a little brisker, and conclude they were right, when what they actually bought was a smaller version of the same shape.

There is a version of this that does work. If your robot runs a model that genuinely occupies the machine, then thinking really is the wait, and a stronger machine shortens it directly. That is the one clean case, and it is easy to recognise.

The test costs you ten minutes. Turn off the heaviest thinking step and drive the robot with a placeholder decision instead. If the lag vanishes, buy the computer. If the robot still feels late with nothing to think about, the wait was never thinking and no hardware will remove it.

Does real-time mean the robot is fast?

Partly, but not the way you think: real-time means arriving on time rather than arriving quickly, and those two come apart constantly. A system that always answers within its slot is real-time even when the slot is generous. A system that usually answers immediately and occasionally takes much longer is not, and the occasional case is exactly what a robot falls over on.

The distinction matters because it changes what you aim at. Aiming at the typical case makes demos look good. Aiming at the worst case makes robots that do not surprise anybody. A gripper that closes on the same beat every time is more useful than one that is usually quicker and sometimes late, because everything else can be built around a beat you can count on.

Most robots do not need hard guarantees, and claiming them is a bigger commitment than teams expect, reaching down into the operating system and the hardware. What real-time really means in robotics sets out which flavour you are likely to need.

How do you work out which kind of lag you have?

Time one picture from end to end, then compare that against how long your own code takes. Stamp a picture when the camera produces it, carry the stamp along with the picture, and read the stamp at the moment the decision is made. Then time your own decision step on its own. If your decision fills almost the whole gap, you have a thinking problem and your own code is where to look. If the gap is far wider than your decision, the picture spent that time waiting, and no amount of rewriting your code will touch it.

Then run the three cheap experiments. Close every viewer and see whether the robot settles. Send a smaller picture and see whether the lag shrinks along with it. Merge two programs that always run together and see whether the beat steadies. Each takes an afternoon, and between them they tell you which of the lines below is yours.

Here is the whole decision in five lines.

• If you are the only person who ever feels the lag -> leave it alone, because adapting costs nothing and a rewrite costs a month.
• If your own decision step fills the gap -> fix your code or your model, because the messaging layer is not involved.
• If closing a viewer makes the robot settle -> you have a delivery problem, because the cost is growing with the number of watchers.
• If several programs on one board read the same pictures every cycle -> a shared-memory middleware, because copying is the part that grows badly.
• If the lag only appears over Wi-Fi -> fix the network link, because shared memory stops at the edge of one computer.

The HORUS Fit Framework scores any option on five axes rather than a score out of ten: ecosystem size, setup effort, team size fit, deployment target, and licence. For a first robot, setup effort and ecosystem size decide it, while deployment target tells you whether shared memory is even relevant to the machine you own.

If your robot ever grows into that fourth line, having the option already on your shelf beats searching for one under pressure. Star HORUS so it is in your list when you start building.