ROS 2 Has a Nondeterminism Problem. Two New Papers Want to Fix It.

They tested it on the Autoware reference system, which is about as close to a real autonomous vehicle stack as you get in open source. The results are what you'd expect: vanilla ROS 2 showed callbacks executing in different orders across runs, with end-to-end latencies that varied significantly. Under their LF-controlled system, execution order was consistent and latencies were predictable.

Now, I've seen determinism claims before. I covered real-time operating systems back when QNX was the hot thing and everyone was promising microsecond-level guarantees. The question is always the same: what do you give up? In this case, the paper is honest that not every ROS 2 feature can be executed deterministically under logical time. There are constraints. But the fact that they can do automatic conversion without modifying the ROS 2 code is, I have to admit, pretty clever.

The harness argument

The second paper takes a different angle. Instead of trying to make ROS 2 deterministic after the fact, it argues that robot middleware needs to evolve into what the AI agent community calls a "harness", the external system that mediates tools, manages state, bounds resources, and records execution.

This framing comes from the language model agent world, where researchers have been grappling with how to safely let AI models interact with external tools. The robotics community, according to these authors, hasn't adopted this framing yet, and it should.

Their argument is that a Physical AI harness has to mediate at three levels simultaneously: control (what commands get sent to actuators), computing (how much inference time the model gets), and communication (how much bandwidth it consumes). A learned policy's output crosses all three dimensions. Robot middleware, they claim, is the only layer in the stack with abstractions over all three, so it's the natural place to build enforcement.

What enforcement? They propose three functions: Projection (gate each output at emission), Isolation (bound the model's execution and transmission slot), and Transfer (fall back to a verified baseline when checks fail). If this sounds like safety engineering 101, well, it is. The point is that these functions exist today as hand-built application code scattered across deployed systems. The paper argues they should be standardized as a "ROS 2 Harness Profile."

So what

Here's the thing that strikes me about both papers: they're describing problems that the autonomous vehicle industry has been wrestling with for a decade. Deterministic execution? Waymo and Cruise built custom middleware stacks precisely because ROS wasn't cutting it for safety-critical applications. Resource bounding for AI inference? Every AV company has horror stories about a perception model taking too long and the planning stack running on stale data.

I've seen this movie before. Academic robotics builds on ROS because it's convenient and well-documented. Industry builds custom systems because ROS doesn't meet their requirements. Then, years later, the academic community rediscovers the problems industry already solved (often in proprietary, unpublished ways) and proposes solutions that look suspiciously similar.

That's not a criticism, exactly. It's just how the field works. And to be fair, both papers are doing something valuable: they're making these solutions available to the broader community, not locked up inside some company's internal codebase.

The timing question is whether any of this matters for the current wave of humanoid and general-purpose robot startups. Most of them are building on ROS 2 because, well, what else are you going to use? But they're also moving fast and shipping robots into warehouses and factories where "nondeterministic behavior" is not exactly a selling point.

My guess (and it's just a guess, call me old-fashioned but I prefer to wait for actual deployment data) is that we'll see a bifurcation. Research labs and early-stage startups will keep using vanilla ROS 2 because it's good enough for prototyping. Companies shipping safety-critical systems will either adopt frameworks like Lingua Franca, build their own harness layers, or abandon ROS entirely.

The Harness Profile idea is interesting because it's trying to prevent that abandonment. If ROS 2 can evolve to meet the requirements of Physical AI deployment, maybe the ecosystem stays unified. If it can't, we'll end up with the same fragmentation we saw in the autonomous vehicle space, where everyone built their own thing and interoperability went out the window.

It's too early to say which way this goes. But if you're building robots with AI in the loop and you haven't thought about determinism and resource bounding, these papers are worth your time. The problems they describe are real, and they're only going to get worse as models get bigger and deployment stakes get higher.

If you want to argue about any of this, my email's on the about page.

James Chen · 10 hours ago · 5 min