What Is Determinism in Robotics, and Do You Need It?

Determinism means the same inputs always produce the same result in the same order, and most robots need bounded timing rather than that. ROS 2 and HORUS both leave the ordering of messages to the machine unless you constrain it, so determinism is something you build rather than install. The verdict flips when a certification body, a regulator or a customer asks you to prove the robot repeats. The rest of this post is for anyone being told their robot must be deterministic and unsure whether that is a real requirement or a word.

The word turns up in three places and means something different in each. A supplier's datasheet calls a controller deterministic, and you cannot tell whether that is a claim about the chip, about the software, or about nothing at all. A reviewer asks whether your test results are deterministic, and what they mean is that they ran your code twice and got two answers. Somebody senior says the robot has to be deterministic before it goes anywhere near a customer, and when you ask what that means in practice the answer is a shrug and the word safe. Meanwhile your own robot mostly does the same thing, drifts occasionally, and once in a while does something you cannot explain, and you do not know whether that is normal, whether you should care, or how much of your remaining time it deserves. You have read that hard real-time is expensive and probably not for you. You have also read that without determinism you cannot test anything, which sounds like it could be true. Both cannot be entirely right, and nobody seems to write down which half of each to keep.

Do I need a deterministic robot, or a predictable one?

Almost certainly a predictable one, which is a weaker requirement and far cheaper to buy. Determinism, strictly, means that feeding the system the same inputs in the same order produces the same outputs in the same order every time, with nothing left to chance. Predictability means you can say in advance what the robot will do and by when, inside a bound you are willing to defend, even though the details differ between runs. A delivery robot does not need identical wheel commands on two passes down the same corridor. A delivery robot needs to have decided to brake before it reaches the person, on every run, including the bad ones. Those are different requirements with different price tags. Full determinism costs you the ability to let work overlap, obliges you to control the clock, and is usually only achievable in simulation or replay. Predictability costs you one scheduling decision and a bound to check against. The teams that get into trouble ask for determinism, buy the machinery for it, and still cannot say what their robot does when a sensor arrives late.

What does determinism actually mean when it is applied to robots?

Determinism in robotics splits into three separate claims that get muddled together, and pulling them apart ends most arguments about it. The first is value determinism: the same inputs produce the same numbers out, which is what you depend on when you replay a recorded run and expect the same answer. The second is order determinism: steps happen in the same sequence every time, so the planner always sees the detection from the current cycle and never the one before it. The third is timing determinism: every step finishes inside a bound you decided on, so the robot acts while acting still helps. A system can have any one of these without the others. Replay in simulation gives the first two and says nothing about the third. A microcontroller running one loop gives the second and third and can still produce different numbers when a sensor reading differs. So when somebody says a robot must be deterministic, ask which of the three they mean. Once they think it through, the answer is usually the third one.

What are the actual ways to get determinism into a robot?

Seven approaches are in common use, and a shipped robot usually combines about three of them. You can record every input and replay it off the robot, giving repeatable tests without touching the running system. You can run in simulation with a fixed time step and fixed seeds, so a run repeats exactly and two versions of an algorithm can be compared honestly. You can force the critical steps onto one thread in a fixed order, which ROS 2 supports through its executor and callback group settings. You can decide the schedule in advance instead of letting the operating system choose, then defend that schedule to whoever asks. You can put the inner loop on a microcontroller where nothing else competes for the processor. You can keep the sensing-to-acting chain inside one computer and let processes hand messages to each other through shared memory, which is what HORUS does and what ROS 2 approximates by composing nodes into a single process. Or you can accept that part of the system is not repeatable, usually a learned component, and test that part statistically instead.

Which of those approaches suits which kind of project?

The approach that suits you follows from which of the three claims you actually need, not from how serious the word sounds.

Most shipped robots use the first row for testing, one of the middle rows for the loop, and the last row for anything learned.

What should I do if I am a hobbyist building one robot?

Skip determinism and buy repeatable tests instead, because that is what you actually want from the word. A hobby project fails for a different reason than a certified one: not because a deadline was missed by a hair, but because a change made last weekend broke something and nobody can tell which change it was. Recording a run and replaying it through your code answers that in an afternoon and costs nothing but disk. Set the robot down, drive it through the situation that matters, keep the recording, and from then on run every code change through it before touching hardware. That gives you value determinism where it helps and leaves timing alone, which is the right trade when nothing on your robot is heavy enough to hurt anybody. The one exception worth taking seriously is a machine with real mass or a sharp tool on the end, where being late has a physical consequence. At that point the hobby framing stops applying, and the section below on heavier robots is the one to read.

What if my robot runs Linux on a single board computer?

Then your first job is finding out what else is competing for that board, because on a general-purpose operating system the honest answer is always more than you expected. A single board runs your control loop alongside a desktop environment nobody meant to install, a package updater, a logging daemon, and whatever the camera driver does when a frame arrives. Any of those can push your loop aside at the wrong moment, and the result looks like a software fault in your own code. Three steps get most of the way there without exotic tooling. Take away the work that does not belong on the robot at all, starting with anything graphical. Give the loop a priority above the housekeeping so the housekeeping waits instead. And keep the whole sensing-to-acting chain on that one board so nothing in it waits on a network. If those three are done and the loop still gets pushed aside, that is the point where a real-time kernel earns its keep, and whether you need one at all is worth deciding deliberately.

What if I have to ship a product this quarter?

Buy timing determinism on the shortest path only, and write down what the robot does when the bound is missed. A quarter is enough to make one chain predictable and not enough to make a system deterministic, so pick the chain where being late causes harm — usually a sensor, a safety check, and the command that stops a motor — and leave everything else alone. Give that chain a fixed order, keep it on one machine, and make sure it never waits behind work that can afford to wait. Then write the missed-deadline behaviour down explicitly, because that sentence is what a customer, an insurer, or your own team will ask for later: when a reading is older than the current cycle, the robot slows and stops rather than acting on it. Both halves matter. A bound with no defined failure behaviour is a promise you cannot keep, and defined failure behaviour with no bound is a rule that never triggers. Everything else on the machine can stay as varied as it likes.

What if I have never worked on a real-time system before?

Learn one idea first: a deadline is the moment after which a correct answer is worthless. That single notion reorganises the whole topic. It explains why speed is not the point, since a fast average with an occasional long pause is worse for a robot than something slower and even. It explains why a stop check needs a fresh reading and a mapping update does not. It explains why the interesting question about any step is not how long it takes but what happens when it is late. Once deadlines make sense, work out which of your steps have one — there are usually fewer than you expect, and they cluster around the actuators. Everything with a deadline goes on one machine, gets a fixed order, and gets a defined behaviour for the moment it misses. Everything without a deadline can be as varied as it likes. If your robot is already varying between runs in ways you cannot explain, that symptom has its own diagnosis and is worth separating from this decision.

What changes as a robot gets faster and heavier?

Being late stops being an annoyance and becomes the entire safety story. On a small indoor rover, a decision that arrives a cycle late means a slightly wobbly path and nobody notices. Put the same lateness on an arm with reach and mass, and the arm has already moved somewhere it should not be by the time the correction lands. The change is not linear and it does not announce itself. Teams typically discover it when the same software is moved onto a bigger platform and starts producing incidents that never happened before, with no code change to blame. Two things shift at that point. First, the acceptable bound gets shorter, because the machine covers more ground while you think. Second, the cost of being wrong goes from an embarrassing video to an injury, which changes who has to approve your design. That is the moment the word determinism stops being vocabulary and starts being a requirement someone will check. It is much cheaper to have the critical chain identified before that day than after.

What do I give up by insisting on determinism?

Overlap, adaptability, and usually a piece of your schedule. Forcing steps into a fixed order means the slowest one sets the pace for all of them, so a vision stage that used to run alongside planning now makes planning wait. Deciding the schedule in advance means committing to what may be skipped when the machine is busy, which is an uncomfortable conversation and occasionally the wrong call. Requiring identical runs means controlling the clock and the inputs, which pushes most of your testing into simulation and replay, and simulation is a model that will be wrong somewhere you have not looked yet. Leaving part of the ROS package set behind means writing or wrapping drivers that already exist there. And there is a subtler cost: a system built for repeatability resists the kind of casual change that makes early development quick, so a team that buys determinism too early spends months moving slowly to protect a property nobody has asked them for yet. Buy it when someone will check, not before.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever what you need is repeatable testing and a working stack rather than a tightly controlled machine. Concrete cases. You want to record a run and replay it later, and the tooling for that is mature, well documented, and already understood by everyone you might hire. You need navigation, motion planning, or a simulator integration, and all of those live there with years of argument behind them. Your system spans machines by design, with a robot and an offboard computer that both hold state, so HORUS is not the answer, because a shared-memory path between processes stops at the edge of one machine. Your team already knows ROS 2 and the determinism you need is order determinism in one small chain, which is an executor setting rather than a rewrite. Or you are in research, where being able to hand a colleague a recording that reproduces your result matters more than what the robot does at run time. In all of those, work inside ROS 2.

Does a deterministic robot always do the same thing in the real world?

No, and here is why: the world supplies the inputs, and the world does not repeat. Determinism is a property of a system given its inputs, so it promises that identical inputs give identical behaviour and promises nothing at all about a floor with a slightly different friction, a battery a little lower, or a person standing half a step to the left. Two runs on the same corridor never hand the robot the same numbers. This is the misunderstanding that sends teams down expensive paths: they build machinery to guarantee identical execution, deploy it, watch the robot still behave differently outdoors, and conclude the machinery failed. It did not. It removed variation coming from inside the computer, which was worth doing, and left variation coming from the world, which no amount of scheduling touches. The right response to world variation is behaviour that tolerates it: decisions that do not hinge on one reading, margins that absorb a slightly late sensor, and a defined action when the input is missing entirely.

Is determinism the same thing as real-time?

Partly, but not the way you think. The two overlap at timing determinism and diverge everywhere else. Real-time means finishing inside a deadline, and a real-time system must therefore be predictable in its timing, which is one of determinism's three claims. But a real-time system is free to produce different numbers on two runs, and often does, because the sensors differ. Meanwhile a fully deterministic replay running on a laptop has no real-time property whatsoever — the replay can take as long as it likes, and repeat perfectly while doing so. So the two words answer different questions. Real-time asks whether the answer arrives while it is still useful. Determinism asks whether the same question always gets the same answer. Most robot requirements written as "must be deterministic" turn out to be real-time requirements written by somebody reaching for the wrong word, and what the real-time claim actually covers is worth reading before you agree to either.

How do I decide how much determinism to buy?

Ask three questions in order and stop at the first yes. Will somebody outside your team check that the robot behaves the same way, whether that is a certifier, an insurer, or a customer with a test plan? If yes, you need a schedule decided in advance and evidence, and that shapes the whole architecture. If no, next question: does being late cause harm rather than annoyance? If yes, you need timing determinism on the short chain between sensing and acting, and nothing more than that. If no, last question: can you tell whether last week's code change made the robot better or worse? If not, you need recorded runs and replay, which is value determinism and takes an afternoon. Most projects stop at the third question and would be better off admitting it than buying scheduling machinery they will not use. Very few need all three at once, and the ones that do usually know already, because somebody has handed them a document.

A short version, by situation:

• If somebody outside your team will audit the robot -> decide the schedule in advance, because an auditor asks why the robot was late and a shrug is not an answer.
• If your machine has mass or a sharp tool -> buy timing determinism on the sensing-to-acting chain, because being late there has a physical consequence.
• If you cannot tell whether last week's change helped -> record runs and replay them, because that is the cheapest form of the property you are asking for.
• If a learned component sits in the loop -> test it statistically and keep it off the critical chain, because repeatability was never on offer there.
• If your robot is small, slow and indoors -> skip the machinery entirely, because nothing on it is heavy enough to make a missed deadline matter.

When the question turns into a middleware choice rather than a scheduling one, the HORUS Fit Framework compares options on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence.

HORUS is open source under Apache-2.0 and the repository is linked below. Star it so it is in your list when you start building.