Do You Need Digital Twins, or Just a Simulator?

Most robotics teams need a simulator, not a digital twin, because a twin only answers questions about one particular machine nobody can reach. A simulator tests a design; a twin tracks one serial number and needs permanent upkeep. That flips when a customer's robot fails and nobody can reach it, though a stack like ROS 2 or HORUS only carries the data either way. The rest is for a team weighing a twin programme against a simulator, a recording pipeline, and the engineers it would take from other work.

You have a simulator. It mostly works. Somebody on the commercial side has started asking for a digital twin, and the request arrived without a definition — it came from a customer's tender document, or a conference talk, or a competitor's website. Now it is a line on the roadmap and you are the one who has to cost it.

The awkward part is that you cannot argue against it without sounding like the engineer who says no to everything. A twin sounds like more of what you already have, and more is usually better. Meanwhile the simulator you own is trusted by nobody: the arm settles differently in it than on the bench, the wheels grip a floor that does not exist, and the last three field failures were things nobody had thought to simulate at all.

So there are two readings of the request. Either the business wants a better picture of the machines, or it has noticed a real gap that neither the simulator nor the logs currently close. Those need very different answers, and telling them apart is the whole job.

Do you need a digital twin, or will a simulator do?

A simulator is enough for almost every team, and a digital twin only earns its cost once robots are somewhere you cannot walk to. The distinction is not detail, it is identity. A simulator answers questions about a class of machine: does this gripper close on a soft box without crushing it, does the base tip when it turns on a ramp, does the arm stop before it hits the table. A digital twin answers questions about one machine with a serial number on it: why does the unit in the Bristol depot drop a box every fortnight when the other nine never do. If your robots are in the building with you, nobody needs the second kind of question, because walking over and watching is quicker. The mistake is hearing "digital twin" as "better simulator" and treating it as an upgrade. It is a different product, with a different owner, a data pipeline attached to real machines, and an upkeep bill that never stops. Work out which of those two questions your team keeps failing to answer.

What is the difference between a simulator and a digital twin?

A simulator models how a kind of robot behaves; a digital twin models one specific robot, fed by that robot's own data so the model ages along with the machine. Three parts make something a twin. There is a model: the shape, the joints, the motors, what happens when the controller asks for a movement. There is a live return path from the physical machine — what it was told to do, what it did, how warm it got, what it was carrying. And there is something that consumes the difference between those two, either nudging the model back into agreement or raising a flag when the machine has drifted away from it. Take out the second part and you have a simulator. Take out the third and you have a simulator with an expensive plumbing project bolted to it. Most things announced internally as digital twins ship the first two and never finish the third, which is why so many end as a rotating render on a dashboard nobody opens twice. The longer definition of the term is worth reading first.

What are the real options between a plain simulator and a full twin?

There are about six options, differing by order of commitment rather than quality. The first is a physics simulator alone, run against a model of your design, with no link to any individual machine. The second is recorded run replay: keep what each robot saw and did, then push it back through your software the next morning. The third wires the simulator to the software the robots really run, so you test your own code with the world swapped underneath — ROS 2 does this with a simulation clock and shared message definitions, and HORUS, an open-source real-time middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers so messages between programs on one machine are never serialised, keeps one message path whether readings come from a simulator or a sensor, under Apache-2.0 and validated in simulation. Neither is a simulator or a twin platform. The fourth is a vendor twin product for a fleet bought from that vendor. The fifth is a hand-built model of the one subsystem that keeps surprising you. The sixth is a full fleet programme with dashboards and a team.

How do these options compare side by side?

They compare on commitment and on who maintains them, not on how good the pictures look.

Two rows can be true at once; start with the cheaper one.

What do teams try first, and why does it stop working?

Most teams start by making the simulator prettier, and it stops working because visual detail was never the thing that was wrong. Someone imports better meshes and sets up proper lighting. The renders look convincing, confidence goes up, and then a robot in the field does something the simulator never suggested was possible — a wheel slips on a floor cleaned an hour earlier, or a box that was supposed to be rigid sags in the middle. Nothing in the mesh work touched any of that. The second thing teams try is adding physics detail: softer contacts, more friction parameters, a motor curve from a datasheet. That helps a little and introduces a new problem, because the extra parameters have to be set from measurements nobody took, so the model is now more precise and no more correct. The thing that moves the needle is dull: record real runs, replay them against your software, and write down where the simulator and the machine disagree. Teams skip it because it produces a document rather than a demo.

Who is a digital twin actually for?

A digital twin is for the company that supports machines it cannot reach, and specifically for the person who gets phoned when one of them misbehaves. If your robots live in a lab you can walk into, a twin has no job that a bench, a camera and a set of logs do not already do better. If your robots live in customer sites in three countries, and your support engineer's only tool is a phone call to somebody who does not know what a joint limit is, a twin stops being a marketing word and becomes the only way to see what is happening. A second, smaller audience is the team whose machines cannot be interrupted for testing — a production line, a hospital, a farm mid-harvest — where the only safe place to try a change is against a model of that particular installation. Everyone else is offered a twin because it is what the industry sells. Be clear about which of those three you are before anyone builds anything, because the answer decides who owns the thing afterwards.

What hardware do you need before a twin makes sense?

You need deployed machines and a working return path for their data; without both, a twin has nothing to be a twin of. The hardware question usually gets asked as a compute question — do we need a bigger workstation, do we need a graphics card — and that is the least important part. What matters is whether each robot can record what it saw and did without losing data when the network is unhappy, and whether that record reaches you. Teams discover, halfway through a twin project, that their robots log only what someone once needed for a demo, that timestamps from different processes disagree, and that the connection at the customer site drops for hours every night. Those three things are the actual project. Fix them and you have most of the value before any modelling starts, because a faithful record of what a machine did is already the cheapest twin there is. Skip them and every disagreement between model and machine will be impossible to attribute.

How long does each option take before it pays anything back?

A simulator pays back in days, replay in weeks, and a full twin not until a second or third year, which is why the order matters more than the choice. Standing up a simulator against a model of your robot has an immediate return: you can try a behaviour before the hardware exists. Recorded run replay takes longer, because logging has to become something the robots do always rather than when someone remembers, but the first time a field failure gets reproduced at a desk it has paid for itself. A twin runs on a different clock entirely. The model has to be built, validated against measurements, then kept current through firmware updates, a replaced gripper and a new battery supplier — and the value only appears once enough machines are out there for one to go strange. Teams get burned funding a twin on the simulator's timeline, then cancelling it in month five when it has produced a render and no answers. If the calendar cannot carry a multi-year commitment with a named owner, pick a shorter option and mean it.

What skills does your team need for each option?

A simulator needs someone comfortable with a robot description and a physics engine; a twin needs that person, plus a data engineer, plus somebody whose job is to keep saying the model has gone stale. That third role is the one nobody hires and the one that decides whether the project survives. On the simulator side the skills are learnable in weeks by anyone who already writes control code: describing links and joints, setting up contacts, working out why the arm sinks through the table. Replay needs different habits rather than harder ones — disciplined logging, agreed timestamps, and the patience to keep formats stable so last year's recording still opens. A twin adds an unglamorous specialism: comparing model output against measured behaviour and reporting where the two diverge, as both keep changing. It is closer to metrology than to graphics. Teams staff twins with the person who makes the nicest visualisations and then wonder why nobody trusts the model.

What do you give up if you commit to a digital twin?

You give up one engineer's attention permanently, and you give up the ability to change your machine quickly. The first is obvious once stated: a model nobody maintains is worse than no model, because people keep trusting it after it has stopped being true. So somebody is on the hook for updating it every time the hardware team swaps a component, which they will do without telling you. The second cost surprises teams. A twin makes hardware changes expensive, because each change invalidates part of the model and triggers a round of re-validation. Companies that have lived with this describe a slow pull toward freezing the design, which is fine for a mature product and poison for one still finding its shape. There is a third, quieter cost: attention. A twin programme generates dashboards, dashboards generate meetings, and the meetings end up being about the model rather than the machines. That argues for not starting one while the robot is still changing every month.

When is ROS 2 the better choice?

ROS 2 is the better choice when you want a simulator and your robot's software to understand each other without you writing the bridge. That is the common case here, and it is not close. The simulators most teams reach for ship ROS 2 integration as a first-class feature: sensor plugins publishing the message types your code already reads, a clock that steps the world and your controllers together, and years of packages for the boring middle — transforms, robot descriptions, visualisation, recording. If your plan involves an off-the-shelf simulator, a mobile base from a supplier, and any intention of hiring people who already know robotics, ROS 2 is the shorter road and HORUS is not the answer to this particular problem. ROS 2 is also better when a customer, a university partner or a funder expects it because that is what everyone around them uses. Choose otherwise only for a specific reason — several languages sharing one computer, or a control loop that cannot afford the copies — and even then the simulator half of your setup will probably still be ROS 2 shaped.

Will a digital twin fix a simulation nobody trusts?

No, and here is why: trust in a model comes from having measured where it is wrong, and a twin adds data without adding that measurement. The reason nobody trusts your simulator is not that it lacks a live feed. It is that no one has sat down, run the same motion in both places, and written the differences down. Bolt a stream of real robot data onto an unvalidated model and you get an unvalidated model that updates — the disagreements are now moving as well as unexplained. Teams then reach for automatic correction, tuning parameters until output matches the machine, which feels like progress and often makes things worse, because the fitted parameters absorb sensor errors and timing skew along with real physics. The unfashionable fix works: pick a handful of motions, run them on hardware and in the model, and record where the two diverge. A model that is wrong in written-down ways beats one nobody has checked, because an engineer can subtract a known error.

Is a photorealistic model what makes a twin useful?

Partly, but not the way you think. Visual fidelity matters, just not for the reason it usually gets funded. It matters when the robot's own perception is the thing under test — a camera-based pick, a model that reads labels on boxes, anything where lighting and texture change the answer. There, rendering quality does real work, and a plain-looking simulation will teach your vision system the wrong lessons. Everywhere else it is a communication tool: it makes the project legible to people who do not read plots, which genuinely helps when you need funding, and does nothing for finding out why a gearbox is running warm. The trouble is that the rendering budget crowds out the measurement budget, because renders demo well and comparison reports do not. A useful test is to ask what question the picture answers that a chart would not. If the answer is that it helps a customer understand what you do, fund it as marketing. If the answer is that your perception stack behaves differently under it, fund it as engineering and validate it.

How should your team decide between the two?

Ask three questions in order, and most teams have their answer inside ten minutes. First: is there a specific robot, somewhere you cannot easily get to, whose behaviour you need to explain to somebody? If not, you want a simulator and better recordings, and can decline the twin. Second: does data come back from that machine today, dependably, including on nights the customer's network misbehaves? If not, that is the entire project, and modelling waits. Third: who will say out loud that the model has gone stale, and will anyone act when they do? Where all three land well, start with the smallest version that answers one real question: one subsystem, one measured comparison, one report on where model and machine differ. Teams that navigate this well have usually settled how honest their simulation needs to be long before the word twin came up, and know what to do when simulation and hardware disagree.

Decide by situation rather than by ambition:

• If you have no robots outside your own building -> a simulator, because there is no individual machine to be a twin of.
• If field failures happen once and cannot be reproduced -> recorded run replay, because a recording is the cheapest twin there is.
• If the same control code must run against simulated and real readings -> a stack with one message path, because translation hides differences.
• If a customer or an investor needs to see the fleet -> a fleet product, because that is a communication tool, not engineering.
• If one subsystem causes most of your surprises -> model only that, because a whole-machine twin answers a narrow question no better.
• If nobody has been named to keep the model current -> neither, yet, because an unmaintained model is worse than none.

When two of those lines fit, weigh the candidates 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 benchmarks, just five honest questions about your situation rather than the software. If your answers keep landing on one machine, several languages, and code that must behave the same whether readings are simulated or real, star HORUS on GitHub so it is in your list when you start building.