What Is a Digital Twin in Robotics, Really?

A digital twin is a simulation of one specific robot kept in step with the real machine, and most teams need an ordinary simulator instead. The word names a promise, not a product, and it pays only once a fleet is deployed and one unit's failure must be reproduced. Before that, a simulator plus honest logs, carried by a stack like ROS 2 or HORUS, does the same job. The rest of this post is for a team being asked to fund a digital twin and needing to know what that money actually buys.

Somebody in the meeting said digital twin and the room nodded. Nobody asked what it meant, because everyone had heard it before — in a vendor deck, a conference talk, a customer's procurement document — and asking now would look like not keeping up. So the item went onto the roadmap with a name and no definition, and you are the person who has to turn it into work.

The reading afterwards does not help. One page says a digital twin is a live model of a physical asset updated from its own sensors. Another says it is a detailed simulation you develop against. A third shows a dashboard with a slowly rotating render of a factory floor. Those are three different projects with three different budgets, and all three are called the same thing.

Meanwhile you already have a simulator nobody quite trusts, a folder of recorded runs nobody replays, and a machine in the lab that behaves differently on Tuesdays. Somewhere in there is the real problem the word is reaching for. It would be useful to know which one it is before committing a quarter of engineering time to it.

Do you actually need a digital twin, or is a simulator enough?

For most robotics teams a simulator is enough, and a digital twin earns its cost only once robots are out in the world and one particular machine starts misbehaving. The difference is not detail, it is identity. A simulator answers questions about a kind of robot: will this arm reach the top shelf, does the base tip on that ramp, does the controller settle or wobble. A twin answers questions about one robot in particular: why does unit seven in the Rotterdam warehouse drop boxes when the other eleven do not, and what happens if its gripper timing is changed. Until there is a fleet, or a machine you cannot walk over to and touch, there is no unit seven and nobody ever asks the second question. Teams skip this test because the word sounds like a better simulator, so building one feels like an upgrade rather than a change of subject with its own owner, budget and never-ending upkeep bill. Ask which of those two questions your team keeps failing to answer.

What is a digital twin in robotics, in plain terms?

A digital twin is a model of one particular robot, fed by that robot's own data, so the model drifts along with the machine instead of staying at factory settings. Three parts make it a twin rather than a simulation. There is a model of the machine: its shape, its joints, its motors, how it responds when told to move. There is a stream of real data coming back from the physical robot: what it was commanded to do, what it actually did, how warm it got, what it was carrying. And there is something that uses the difference between the two, either correcting the model so it keeps matching or raising a flag when the machine has stopped matching the model. Remove the second part and what remains is a simulator. Remove the third and what remains is a simulator with an expensive data pipeline attached. Most projects announced as digital twins ship the first two parts and never finish the third, which is why so many end up as a rotating render on a dashboard nobody opens twice.

What are the actual options for building a robot digital twin?

Six routes come up in practice and they are not the same size of project. First is a physics simulator on its own, run against a model of your robot, with no live link to any individual machine. Second is recorded run replay: keep everything the robot saw and did, then push it back through your software at your desk tomorrow. Third is wiring a simulator to the software the robot really runs, so the twin is your own code with the world swapped underneath it. ROS 2 does this with a simulation clock and shared message types, and HORUS — an open-source real-time middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between programs on one machine are not serialised, Apache-2.0 and itself validated in simulation — does it by keeping one message path whether readings arrive from a simulator or a sensor. Neither supplies the simulator. Fourth is a vendor's twin platform for a fleet bought from that vendor. Fifth is a hand-built model of the single subsystem that keeps surprising you. Sixth is a commercial fleet product with dashboards and alerting.

How do the digital twin options compare?

Read the last two columns first. Every row below is useful to somebody, so what matters is not which is best but which describe a situation you are not in, and those can be struck out in a minute. Notice that the rows stack rather than compete: replay and a simulator wired to your real stack are the pair most teams end up running together, and a vendor platform usually sits on top of whatever was built underneath. Notice too that the cheapest row answers a surprising share of the questions people build twins to ask, which is worth establishing before the budget conversation rather than after it.

Who on a robotics team actually benefits from a digital twin?

The people who benefit are the ones who cannot reach the robot. Field support gets the most: a customer describes a fault over the phone, and instead of flying an engineer out, somebody replays that unit's own recent behaviour against a model and sees the gripper closing a fraction late. Operations benefit next, because a model fed by real data can flag a machine drifting away from how its siblings behave before anything actually breaks. Control engineers benefit least, which surprises people, because the questions they ask are about the design rather than about one unit, and a plain simulator answers those without any of the plumbing. The person who benefits most in the short term is nobody on the engineering team at all: it is the person who has to explain the fleet to a customer or a regulator, and a twin gives them something to point at. That is a real benefit and worth naming honestly, but it should be funded as a communication project rather than smuggled in as engineering work.

What hardware do you need to run a digital twin?

Less than the marketing implies for the model, and far more than anyone budgets for the data. If the twin only models joints, motors, batteries and commands, an ordinary developer laptop runs it comfortably and always will. The moment camera images enter the picture, a machine with a serious graphics card becomes necessary, and that requirement lands on every engineer who wants to run the twin rather than on one shared server. The real hardware question is on the other side. A twin needs data flowing back from every deployed robot, which means storage that grows every day, a link home that keeps working on a customer's network, and somewhere to put recordings that may be commercially sensitive. Teams size the simulator and forget the pipeline, then discover six months in that keeping the data is the expensive half. If your robots are on machines you do not own, on networks you do not control, solve that before modelling anything, because a twin with no fresh data is just a simulator with a more expensive name.

How long does it take before a digital twin pays for itself?

Longer than a quarter, and the payoff arrives as a single event rather than as a gradual return. A rotating render of the robot takes a couple of weeks. A model that responds roughly like the machine takes a few months. A model whose disagreements with the machine are known and written down takes longer than that, and it is the only version worth having. Then nothing happens for a while, because the twin repays you the first time a robot in the field does something inexplicable and someone reproduces it at a desk instead of booking a flight. If that moment never comes, the twin never pays. The mistake is treating it as a deliverable with an end date. A twin that stops being updated turns harmful within months, because the machine gets new firmware and a replaced gripper, and the model quietly stops describing anything real while still looking authoritative. Budget upkeep or do not start, the same way you would with any part of the stack you plan to own for years.

What skills does a team need to keep a digital twin honest?

Three kinds of person, and the third is the one nobody hires. You need somebody who understands the physics of the machine well enough to say why the model is wrong, which is usually a mechanical engineer rather than a software one. You need somebody who owns data plumbing: getting recordings off robots, keeping them, and making them replayable months later without a specific person's laptop. And you need somebody with the standing to declare the twin untrustworthy and be believed, because the failure mode of every twin project is a model everyone has quietly stopped checking but nobody wants to say so. That third role is political rather than technical, and it is the reason twin projects survive or rot. If your team is small enough that all three roles are the same person, the honest read is that you are not staffed for a twin yet and should put the effort into recorded runs and a simulator you trust, which delivers most of the same value with a fraction of the standing commitment.

What does it look like when a digital twin goes wrong?

It goes wrong quietly, which is what makes it dangerous. The failure is not a crash but a slow separation: the fleet gets a firmware update that changes how the motors respond, the model does not, and for a few weeks the twin keeps producing answers that look reasonable and are not. Nobody notices because nothing visibly breaks. The second stage is worse and has a name worth remembering: trust inversion, where an engineer sees the twin and the machine disagree and assumes the machine is faulty. At that point the model has stopped being a tool and become an authority, and teams start replacing perfectly good hardware to make reality match the picture. The third stage is abandonment, when someone finally checks, finds the twin has been wrong for a quarter, and stops using it while the dashboard keeps running for customers. Guard against all of it with one dull habit: run a known routine on a real machine and on the twin, and publish where they disagree.

What do you give up by committing to a digital twin?

You give up engineering attention, which for most teams is the scarcest thing they have. A twin is a second system that has to keep working, with its own bugs, its own upgrades and its own on-call awkwardness, and it competes directly with the robot for the same people. You also give up flexibility in the machine itself, subtly and without noticing: once a model exists and someone depends on it, changing a gripper or a sensor now carries the extra cost of updating the twin, and teams start choosing the change that keeps the model valid. That is a real tax on hardware iteration and it is rarely written down. Third, you give up simplicity in the data story. Recording everything from deployed robots raises questions about what customers agreed to, how long recordings are kept and who may look at them, and those questions land on somebody who did not ask for them. None of this argues against a twin. It argues for starting one when the fleet exists rather than before, when the same effort would go further elsewhere.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost anyone whose twin work is really simulation work, and that is most teams reading this. The simulation ecosystem lives there: models of common sensors somebody already validated, a simulation clock so your code cannot tell whether time is real, mature recording and replay tools, and the descriptions of robots that hardware vendors publish in ROS 2 formats because that is what their customers ask for. If your plan involves an existing simulator, a bought robot, and a team who will hire from the general robotics pool, use ROS 2 and spend the saved effort on making the model match the machine. HORUS is not the answer in that situation, because a messaging layer does not contain sensor models, a simulator or a fleet dashboard, and pretending otherwise would cost you months. The narrower case where a different stack helps is a single machine mixing languages, where the same control code must run against simulated and real readings with no translation step in between. Which simulator pairs with your stack is a separate decision worth making deliberately.

Is a digital twin just a simulator with better marketing?

Partly, but not the way you think. Plenty of things sold as digital twins are simulators with a live data feed bolted on and a nicer render, and being sceptical about the word is healthy. What the sceptical reading misses is that one specific capability is genuinely new and genuinely hard: a model that keeps itself aligned with a particular machine as that machine ages, so it can answer questions about that machine rather than about the design. Nobody gets that from a simulator, at any level of detail, because a simulator has no idea which robot it is pretending to be. The honest position is that the word covers two things, one of which is oversold and one of which is undersold. The oversold half is the visualisation. The undersold half is the boring measurement work that establishes where the model and the machine disagree, which almost nobody funds because it produces no screenshots. Judge any twin proposal by how much of its budget goes to the second half.

Will a digital twin let you stop testing on the real robot?

No, and here is why: a twin is built from what you already understand about the machine, and the failures that hurt come from what you do not. A model contains the friction someone measured, the delays someone characterised, the loads someone anticipated. It does not contain the loose cable that intermittently browns out a motor controller, the sunlight angle that blinds a sensor at four in the afternoon, or the floor that turns slightly tacky when the loading bay door is open. Those are the failures that stop deployments, and none of them are in any model because nobody knew to put them there. What a twin genuinely does is change the mix. It lets you cover the many boring variations cheaply, so real-robot time gets spent on the awkward, physical, surprising cases instead of on the hundredth repetition of a routine that already works. That is a large win and worth having. It is not a replacement, and every team that has tried to make it one has rediscovered why simulation and hardware disagree.

How do you decide whether your team needs a digital twin?

Ask one question first: is there a specific robot, somewhere you cannot easily reach, whose individual behaviour you need to explain? If the answer is no, you need a simulator and better recordings, and you can stop reading procurement decks about twins for another year. If the answer is yes, ask the second question: does data actually flow back from that machine today, reliably, including when the customer's network misbehaves? If not, that is the whole project and modelling can wait. If data does flow, ask the third: who will say the model has gone stale, and does anyone listen to them? Those three questions kill most twin proposals in about ten minutes, which is the point of asking them. Where all three land well, start with the smallest possible version — one subsystem, one measured comparison, one report that says where model and machine differ — and grow it only when somebody asks it a question it cannot answer. The teams that do well here also tend to have settled how honest their simulation needs to be before anyone said the word twin.

Decide by situation rather than by ambition:

• If you have no robots in the field yet -> a plain simulator, because there is no individual machine for a twin to be about.
• If failures happen once and cannot be reproduced -> recorded run replay, because the recording is the cheapest twin there is.
• If the same code must run against simulated and real readings -> a stack that keeps one message path, because translation between the two is where the differences hide.
• If a customer or a regulator needs a picture of the fleet -> a fleet product, because that is a communication tool and should be funded as one.
• If one subsystem causes most of your surprises -> model only that, because a whole-machine twin will not answer a narrow question any better.
• If nobody owns keeping the model current -> nothing yet, because an unmaintained twin is worse than none.

When two of those lines describe your team, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and keep whichever loses on the fewest. No scores and no numbers, just five honest questions about your situation instead of about the software. If your answers keep landing on one machine, several languages, and code that must behave the same whether the readings are simulated or real, star HORUS on GitHub so it is in your list when you start building.