What Robotics Companies Get Wrong About Their Software Foundations

Robotics companies get their software foundation wrong by choosing between ROS 2, a homegrown stack and a lighter middleware for the demo rather than the product. The mistake is rarely which one they pick, but picking before anybody wrote down what the machine must never do. That changes for a team that already shipped once, where ROS 2, HORUS or a homegrown stack gets chosen from scars rather than a landing page. The rest of this post is for a team with a working prototype and a growing suspicion that the foundation underneath will not survive the product.

The robot works, which is the confusing part. It picked up the object in front of the investor, it drove the loop in the office, and the video is good. Then somebody asks for a second unit and the week disappears into making a second computer behave like the first one, and nobody can say exactly which of the forty things on that machine mattered.

Meanwhile the list of small strange things is growing. The arm occasionally pauses for no reason anybody has reproduced. A camera process has to be started before the controller or nothing works, and the reason is lost. There is a script that began as a workaround and is now what every launch depends on, understood by exactly one person, who is on holiday.

Nobody wants to say the sentence out loud, because saying it commits everyone to acting on it: the foundation chosen in month two is now the thing we spend the week fighting, and no one remembers choosing it.

What do robotics companies actually get wrong about their software foundations?

They choose the foundation to satisfy a demo and then discover it is governing a product. A demo needs one machine to do one thing once with a knowledgeable person nearby. A product needs many machines to do many things repeatedly with nobody nearby, and those two jobs reward opposite decisions almost everywhere they differ.

The specific error is not the technology. It is choosing before writing down the requirements that only a shipped machine has: what happens when a process dies mid-motion, how a failure in a customer's building gets reproduced at a desk, how a new engineer starts the robot on day one, and what the machine must never do regardless of what the rest of the software asks for.

None of those questions has an obvious answer during the prototype, so nobody asks them, and the foundation gets picked on what was familiar, what a tutorial used or what an assistant suggested. That choice then decides how processes are split, how data moves and how failures are found, for the life of the company.

What counts as a software foundation in a robot?

The foundation is the set of decisions every later decision has to live with, and there are about five of them. First, how the software is split into separate running programs, and which of them share a computer. Second, how those programs pass data to each other. Third, what the message shapes are, and who is allowed to change one. Fourth, how the whole machine is started, configured and shut down. Fifth, how a run is recorded so a failure can be watched again later.

Notice that only one of those five is what people mean by choosing a framework. The other four get decided informally, in the first fortnight, by whoever wrote the first program, and they turn out to be much harder to change than the framework itself.

This is why arguments about frameworks so often miss. Two teams can use the same framework and have completely different foundations, because one split the machine into six processes with defined messages and the other has one enormous program with threads. The framework is the visible part; the decisions around it are the part you live in.

What are the real foundation options a company can choose from?

There are six, and most companies only ever consider two. The single-program option: everything in one process, no messages, function calls throughout, which is genuinely correct for a small machine. The ecosystem option, ROS 2, which brings drivers, visualisation, recording, navigation and a hiring pool that already knows the vocabulary. The focused option, such as HORUS, an open-source middleware under Apache-2.0 where Rust, Python and C++ processes on one computer share the same shared-memory ring buffers, so messages between them are not serialised, which suits a machine whose difficulty is several processes sharing a control loop. The vendor option, whatever SDK arrived with the arm or the base. The commercial option, a supported platform with a contract behind it. And the homegrown option, writing transport, discovery and tooling yourself.

The error companies make here is treating the list as exclusive. Shipping machines routinely run two of these at once, with an ecosystem carrying perception and drivers while something narrower carries the handful of processes that must stay in step. Choosing is not marrying.

How do the foundation options compare?

The comparison is decided by the third column, the one everybody skims: what each option assumes you already know. A foundation that assumes knowledge your team lacks is not a fast start, whatever the first tutorial suggests.

The right row is the one whose last column does not describe your company next year.

Does the answer change for a hardware company compared with an AI startup?

Yes, and the two get it wrong in opposite directions. Hardware companies under-invest in the foundation because software feels like the part you can fix later. The software is treated as the layer that sits on top rather than the thing that decides whether unit twelve behaves like unit one. That company usually ends up with a working prototype and no way to produce a second one that behaves the same.

AI-first companies make the opposite error. The model is treated as the whole product, and everything around it as plumbing beneath serious attention. Then the model turns out to produce answers at its own pace while the machine needs a decision on a schedule, and the interesting work becomes what the robot does while waiting, which nobody designed.

Both errors share a root: the foundation gets whatever attention is left after the part the founders find interesting. The correction is the same in both cases. Somebody senior has to own the boring layer explicitly, before the company hires the engineers who will inherit whatever that layer became.

How much does the computer inside the robot decide this?

More than any preference, and companies discover it after committing rather than before. If everything runs on one board, the questions worth asking are about processes sharing that board and the memory it has. If the machine is really several computers on a network, the network is the constraint, and behaviour during a dropout or a reconnection shapes the architecture whether or not anyone planned for it.

The board also decides what you can afford to run. A large ecosystem on a small computer leaves less room for the perception and model work that is the actual product, and teams discover this late, when adding one more process starts making the machine behave differently.

There is a third case worth naming. If the compute is a microcontroller with no real operating system, most of this discussion does not apply and the real foundation questions are about firmware structure and interrupts. Companies that answer the middleware question before answering which computer the robot runs on usually answer it twice.

What if the foundation has to be chosen before the funding round?

Choose the option with the largest ecosystem and the smallest number of decisions you have to invent yourself. Under fundraising pressure the correct move is almost always the boring one, because the round is won by the machine doing something impressive, not by the architecture underneath it, and an ecosystem means fewer weeks spent on problems that are already solved.

The trap is the opposite instinct: building something custom because it demos better on a slide about technical depth. Investors ask about the software once and about the machine constantly. A custom foundation buys a paragraph in a deck and costs quarters of engineering that would otherwise have gone into what the robot does.

There is a caveat that matters after the round closes. Whatever gets chosen under deadline pressure becomes the thing forty engineers inherit, and nobody schedules time to revisit it. So make the fast choice, and write down in the repository what would have to be true for it to be wrong. That paragraph is the difference between a decision and an accident.

What if the team is strong at software but new to robots?

Expect the surprises to come from the physical side, and choose the foundation that has already met them. Experienced software teams arrive with correct instincts about structure and testing, and then lose months to things no web system does: clocks that disagree, a sensor that reports confidently wrong values for the first second, a motor controller that needs a specific initialisation order.

Every one of those has been hit and written up inside a mature ecosystem. On a homegrown foundation, each is a fresh mystery costing a weekend, and the team cannot yet tell a hard problem from a self-inflicted one. Working inside something established gives a baseline: when the standard thing behaves strangely, the strangeness is usually yours.

The other correction for strong software teams is to resist making the architecture elegant before the machine works. Robot software gets ugly in specific places for physical reasons, and generalising too early produces an abstraction that fights the hardware. Get the machine working, then clean up what turned out to matter, in that order, as covered in what teams should standardise early.

What does a foundation problem look like from the outside?

It looks like a team that is busy while the robot stops improving. Standups fill with environment differences, configuration, why the machine behaves differently after a reboot, and why last week's recording will not replay. The demo still works, so nothing is visibly on fire, and the roadmap slips a fortnight at a time without any single week where something went wrong.

The second sign is that failures cannot be reproduced. Something happens on the machine, everybody agrees it happened, and there is no way to make it happen again at a desk. Fixes become guesses, and confidence in the software gets replaced by confidence in a particular engineer, which is not the same thing and does not survive that engineer leaving.

The third sign is a private vocabulary. Your team has words for concepts nobody outside the company shares, onboarding takes weeks rather than days, and every new hire spends a first month learning software that will never appear on a CV. That is the shape described in signs a prototype will not survive production, and it is a foundation symptom rather than a people problem.

What do you give up by committing to one foundation early?

You give up options you did not know you wanted, and the loss is felt as waiting rather than as pain. Once the foundation is chosen, a bug in it becomes something you report, work around or fork, and each of those is survivable while none of them is in the plan.

You also inherit assumptions. Every foundation encodes a view of how a robot should be organised, and that view will eventually disagree with your machine. Fighting the disagreement is expensive, accepting it means changing your design, and neither feels good with a customer waiting.

The third loss is understanding. A team that adopts everything can eventually not explain why the robot behaved as it did, because the interesting behaviour happens inside code nobody read. That becomes acute during certification, a serious field failure, or due diligence when somebody asks how the emergency stop is guaranteed. The remedy is not building your own. It is reading the source of what you adopted, once, before depending on it.

When is ROS 2 the better choice?

ROS 2 is the better foundation for most robots, and specifically whenever the hard part is perception, navigation, integration or staying maintainable while the team changes. If your machine has to map a building it has never seen, plan around a person, recognise objects and report to a fleet manager, ROS 2 is years of work you get to skip.

ROS 2 also wins the arguments that decide companies rather than benchmarks. You can hire people who already know it, contractors can staff your project without inventing anything, vendors ship drivers for it, and a failure in a customer's building can be recorded and replayed at a desk the next morning.

HORUS is not the answer in those cases. A shared-memory middleware carries messages between processes on one computer and brings no mapper, no planner, no fleet interface and no driver for the lidar that arrived last week. If those are the hard problems, choosing something smaller means writing all of it yourself, which is how prototypes turn into infrastructure projects.

Is the foundation really the reason the robot is late?

No, and here is why. Most late robots are late for reasons the foundation cannot cause: the requirements changed twice, the hardware arrived four months after it was promised, the thing the machine has to do is genuinely hard, or nobody wrote down what finished means. Changing the software underneath does not move any of those.

The foundation is a convenient thing to blame because it is the only part of the project that can be replaced by a decision in a meeting. Rewriting is visible, feels decisive, and postpones the harder conversation about scope. Companies that switch under those conditions usually arrive at the same delay six months later on a different stack.

There is a real version of this, and it has a signature. The foundation is the problem when the same kind of week keeps repeating: hours going to configuration, launching, environment differences and failures nobody can reproduce, while the machine's actual job gets the remainder. That is a pattern, not a feeling: look at where last month's hours went before anybody proposes a rewrite.

Can a company just swap the foundation later?

Partly, but not the way you think. The code is the portable part. A controller does not care how the numbers reached it, and a state machine, a calibration routine and a perception pipeline usually move faster than the team fears.

What actually holds you in place is everything around the code: launch configuration, recorded runs in a specific format, dashboards, test rigs, the deployment scripts, the continuous integration, and above all the habits of everyone hired so far. A team fluent in one ecosystem carries that fluency into every design conversation, so changing the substrate means changing how people think, which takes longer than any rewrite.

The practical consequence is not to avoid committing. It is to keep the logic that makes your robot valuable in plain libraries the foundation calls, rather than scattered through framework-specific classes. Do that in the first months and a future move becomes rewiring. Leave it to year three and the entanglement has already happened, which is why these decisions are hard to reverse.

How do you tell which foundation problem you actually have?

Spend one week measuring rather than arguing, because the three problems have different fixes and they feel identical from inside. Write down where every engineering hour went, split into three buckets: the machine's actual job, plumbing and configuration, and reproducing things nobody understands. The proportions answer the question faster than any architecture review.

Then run three tests on the machine you intend to ship. Can a new engineer get the robot running from a clean checkout without asking anyone? Can you replay yesterday's failure at a desk? What does the machine do when one process is killed mid-motion? A foundation that fails the first test costs you every hire. One that fails the second makes every bug a guess. One that fails the third will eventually hurt somebody.

If all three pass, the foundation is fine and the delay is scope, hardware or an unwritten requirement. Fix that instead, because no migration ever tightened a specification. The choice of who builds the software interacts with all of this, which is the subject of consulting against building in-house.

• If your robot must map and navigate a place it has not seen -> ROS 2, because that work already exists and is maintained.
• If several processes on one computer must stay in step -> a focused middleware alongside the ecosystem, because the loop is the product.
• If you are one person with one machine and one language -> one program and no middleware, because the design you can hold in your head ships first.
• If you sell into a regulated or unreachable setting -> a supported commercial platform, because somebody else's paperwork is cheaper than your own.
• If nobody can state what the machine must never do -> stop and write that down, because no foundation survives an unwritten requirement.

The HORUS Fit Framework reduces the whole comparison to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score each option on all five and reject anything weak on the axis your company cannot afford to be weak on, then write the reason in the repository where the next team will find it.

If timing between processes keeps turning out to be that axis, put HORUS on your reading list rather than this quarter's roadmap: star it so it is in your list when you start building.