Best Robotics Middleware for Teams Coming From Web Development

For a team coming from web development the default is ROS 2, with HORUS worth a look when the robot lives on one computer. Most web instincts transfer: services, queues, deploys. The two that do not are that a late message is a wrong one, and that a crash moves something physical. The verdict flips when everything runs on one board and the ROS catalogue has nothing you need. The rest of this is for engineers who can ship a service in a week and have never had software break something in the room.

You have shipped systems for years and the first robot week still feels like starting over. The tutorial assumes a Linux setup nobody on the team uses. The build tool is not the one you know and it has opinions about directory layout. There is no hot reload, so every change is a rebuild and a restart, and the loop that used to take four seconds now takes two minutes. You add a retry around a call that sometimes fails, the way you always have, and the arm performs the same motion twice. You add logging to find out why, and the problem changes shape, because printing took long enough to matter. Nothing crashes with a stack trace pointing at your mistake; instead the robot behaves slightly differently each run, and the difference is not in your code. Meanwhile the parts of the job you are good at — deploying, monitoring, splitting work across services, keeping schemas compatible — barely come up in any tutorial, and when they do come up they are treated as advanced. The gap is not intelligence and it is not effort. It is that the environment has different physics, and nobody names which of your instincts still apply.

What is the best robotics middleware for a team coming from web development?

ROS 2 is the best default, because the hard part of your first robot is everything except message passing and ROS 2 is where those parts already exist. You are not going to write a lidar driver, a mapping stack, an arm planner or a simulator, and a team with a web background is especially unlikely to enjoy discovering how long each of those takes. The counter-case is narrow and real: if the robot is one computer running sensing, control and actuation, and the parts you need are two vendor libraries you install like any dependency, then a full framework contributes packaging and charges upkeep. That shape is common in desk arms, camera-to-motor pipelines, test rigs and most robots built around a model running on the same board. The way to tell which you have takes ten minutes. Write down the components you refuse to write yourself. A long, specific list means take the ecosystem. A short, vague list means take the smallest thing that moves messages and spend the saved weeks on the robot.

What is robotics middleware, and what is the web equivalent?

Robotics middleware is the layer that carries messages between the separate programs on a robot and decides what happens when one of them is slow, missing or dead. The closest thing in web work is a message bus plus a service mesh plus a deployment system, sold as one package. The publish-and-subscribe part will feel familiar within an hour. What differs is the default answer to failure. A web bus assumes delivery matters, so it buffers, retries and holds messages until a consumer catches up. A robot bus assumes freshness matters, so it drops the old reading and hands over the newest one, because a camera frame from three moments ago is worse than no frame at all. That single inversion explains most of what looks wrong about robot messaging to a web engineer: no durable queues, no dead letter handling, no exactly-once semantics, and topics that silently discard what nobody read in time. None of that is an oversight. It is what you want when the consumer is a wheel.

What do teams from a web background try first, and why does it stop working?

Most web teams start by building the robot as a set of services with HTTP or WebSocket between them, and it works impressively well for about a month. It stops working at four predictable points. First, the control loop starts missing its moment, not because the network is slow but because the runtime paused to tidy memory at the wrong instant. Second, a retry moves a motor twice, and the safe fix turns out to be redesigning every command to be repeatable rather than adding a retry policy. Third, a component crashes and the robot keeps moving, because nothing in a web stack expects a dead service to mean stop the machine. Fourth, someone asks why the arm hesitated on Tuesday and there is no recording of what every component saw, only logs with timestamps that do not line up. Each fix is affordable alone. Together they are a middleware you are building by accident, without any of the tools a real one brings. The wider switch from web to robotics hits the same four walls in the same order.

What are the actual options for a team with a web background?

There are six honest options, and only two of them are middleware in the sense a robotics person means. ROS 2 is the full framework: message layer, build system, launch layer, tooling and a catalogue of components other people wrote, adopted as one decision. HORUS is a single-machine real-time middleware for Rust, Python and C++ that share the same shared-memory ring buffers, so messages are not serialised between processes on that computer; it is open source under Apache-2.0, validated in simulation, and it is not a ROS replacement for projects that need the catalogue. Beyond those two: a broker such as MQTT or NATS, which is a good fit for telemetry off the robot and a bad fit for anything the robot waits on; a general message library of the ZeroMQ sort, where you define every message shape and supervision rule yourself; the web stack you already know, kept for dashboards and fleet services; and no middleware at all, meaning one program with threads, which is the right first move more often than it sounds.

How do the options compare for engineers who have shipped web services?

The column that matters most for a web team is the middle one, because the ramp is where the weeks go.

Two rows together is the normal answer: a robot-side message layer, plus the web stack you already know carrying status to people.

What should a small product team with no hardware experience pick?

Pick ROS 2, and pick it because of hiring and help rather than because of the technology. A team new to hardware will hit problems that are not software problems — a motor that ignores the datasheet, a camera mount that flexes, a controller that oscillates on carpet and not on tile — and the value of the standard stack is that the searchable archive of solved problems is enormous and the people you might contract are already fluent in it. The exception worth taking seriously is the team whose product is a model running on one board with a couple of actuators, which describes a lot of what gets built now. In that shape the ecosystem's value is close to zero, the upkeep is not, and a smaller stack means the whole system stays inside two people's heads. One warning either way: whatever you pick, budget the ramp explicitly rather than hoping it disappears. Teams that plan for weeks of unproductive setup stay calm. Teams that planned for days start making foundation changes under deadline, which is the pattern that actually sinks projects.

What should we pick if the whole robot runs on one small computer?

If everything runs on one board, most of what a networked framework does for you is being paid for and never used. Discovery, network transports and the rules for what happens when a remote peer vanishes are machinery for a problem you do not have, and the upkeep is real whether or not the features are. This describes more robots than people expect: desk arms, camera-to-motor pipelines, balancing machines, test rigs, competition robots, and nearly every project where a model and the motors it commands share a single computer. The question that decides it is not what runs there today but what runs there in a year. If a second computer is planned — a workstation doing perception, a base station collecting runs — adopt something built for that now, because retrofitting a network boundary is a genuine rewrite. If nothing is planned, a single-machine stack removes an entire category of problems, and the category it removes is the one web engineers find least surprising and most tedious: things that work on the desk and fail on the robot's own network.

What should we pick if there is a demo in eight weeks?

Whatever is running today, frozen. Eight weeks is not enough to change foundations and still have a robot, and the decision that ruins demos is always the mid-project switch made because someone read a comparison in week four. If nothing is running yet, choose by what you refuse to write: a demo that needs mapping and navigation takes the ecosystem that has them, rough edges included; a demo where one arm picks one object takes the smallest thing that moves messages, and you write the rest. Then stop evaluating, because every hour spent comparing options after the choice is an hour the robot does not get. What actually decides a demo is unglamorous and familiar from web work: does the thing stop safely when something goes wrong, can you restart it in ten seconds in front of an audience, and can a person watching tell what it is doing. Web teams are good at all three. Spend the eight weeks there rather than on the stack.

What if the team knows TypeScript and Python but no C++ or Rust?

Stay in the languages you know until one of them is what stops you, which happens later than people assume and in exactly one place. Reading sensors, coordinating components, planning at human speeds, dashboards, logging, fleet services: Python and TypeScript handle all of it, and a fluent team moves faster in a familiar language than in one they are learning under deadline. The wall is the loop that holds a wheel speed or stops an arm before the table, which misses its moment when the runtime pauses to tidy memory — a problem garbage collection creates in robot control and cannot be configured away. The answer is to move that one component into a compiled language, not to rewrite the robot. Which makes one property worth checking before you choose a stack: whether a compiled component can sit beside the Python and read the same data without a translation layer between them. If crossing languages means writing and maintaining a bridge, that bridge becomes permanent, and permanent bridges are where robot projects quietly lose their afternoons.

What do you give up by choosing the smaller option?

You give up the catalogue, and the catalogue is the real product being sold. No lidar driver waiting for you, no navigation stack, no arm planner, no simulator that already speaks your message types, no visualiser that discovers your topics without configuration, no recording tool with a decade of use behind it. You also give up the strangers who already had your problem, which web engineers rely on more than they realise: searching a ROS 2 error lands you on a thread from someone who solved it years ago, while searching an error from a smaller project lands you on the source code. And you give up easy handover — a robot on the standard stack can be picked up by a contractor or a new hire, while a robot on your own arrangement of parts can be maintained by the people who arranged it. What comes back is a surface small enough for two people to hold, no upkeep bill for tools you never open, and a much shorter path from a change to seeing the change on the robot.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the robot's value comes from parts other people already built. A mobile base with a lidar that must map a building and navigate it: ROS 2, without further discussion, because that stack exists and writing it is a multi-year project. An arm using an established motion planner. Anything you intend to test in a simulator that already speaks the same message types. Anything a contractor, a student or a new hire will touch, since the standard stack is what they already know and hiring for it is a solved problem. Anything spanning two computers by design, where HORUS is not the answer at all, because shared memory stops at the edge of a machine. And anything whose loops run slowly enough that how messages move is irrelevant, which covers a great many working robots. For a web team specifically there is one more case: when nobody on the team has shipped hardware before, the ecosystem's archive of other people's mistakes is worth more than any property of a smaller stack.

Is a robot just a distributed system we already know how to build?

No, and here is why: a distributed system's failure is a bad response, and a robot's failure is a bad motion. Everything follows from that. Retries become dangerous, because the request you are retrying may already have moved something. Buffering becomes dangerous, because a queue that catches up delivers a stale command to a machine that has since moved on. Eventual consistency has no meaning when the disagreement is between where the arm is and where the software believes it is. Graceful degradation is not a reduced feature set; it is deciding, in advance, what a component does when the message it needs did not arrive — and the right answer is usually to stop, which no web system ever does on purpose. The scheduling instinct differs too: a web service optimises the common case and tolerates a slow one, while a control loop treats a late answer as a failed one, every time. The architecture skills transfer completely. The defaults are inverted, and the honest comparison of the two fields is that robotics is not harder, it is less forgiving.

Could we just put an HTTP API or a message broker between the parts?

Partly, but not the way you think. For the parts that talk to people, that is exactly right: a broker or a plain web API carrying status to a dashboard, mission commands from an operator, or fleet telemetry to a service is a good design that plays to your strengths, and swapping it for a robotics-native tool buys nothing. The place it fails is any path the robot waits on. A broker sits between the sender and the receiver by design, which is a virtue when a phone might be offline and a defect when a control loop needs the newest reading and nothing else. Add a hub in the middle of a sense-decide-act path and you have added a component that can stall, buffer or reorder the one message stream that must not be stalled, buffered or reordered. The rule that holds up: a broker belongs on the boundary between the robot and everything else, never inside the loop that moves the machine.

How do we decide this in an afternoon?

Write three lists and let them decide. First, the components you refuse to write yourself: drivers, mapping, navigation, planning, simulation. Second, how many computers will run your code when the robot is finished, not today. Third, which language holds the loop that must not miss its moment. Read them together. A long first list means take the ecosystem regardless of the rest, because rebuilding that list is a project of its own. A short first list plus one computer means take the smallest thing that moves messages. Several computers means you want a networked message layer, catalogue or not. A compiled loop sitting beside Python on one board is the case where sharing memory across languages earns its keep. Weight the first list hardest — the catalogue is the only item here that takes years to replace, and it is the part a middleware decision quietly commits you to long after the transport underneath stops mattering.

A short version, by situation:

• If you are building anything mobile that must map or navigate -> ROS 2, because the stack you need already exists and writing it is a year you do not have.
• If your robot is a model and some motors on one board -> a single-machine message layer, because none of the network machinery applies and all of its upkeep would.
• If a compiled control loop sits beside Python glue on that board -> a stack where both read the same data without a bridge, because bridges become permanent.
• If you are building the dashboard, the operator view or the fleet service -> the web stack you already know, because that is the one part where your existing instincts are correct.
• If nobody on the team has shipped hardware before -> ROS 2, because the archive of other people's mistakes is worth more than any technical property.
• If there is a demo in eight weeks -> whatever runs today, because a foundation change under deadline is how demos get missed.

To compare options rather than symptoms, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. For a team arriving from web development, setup effort and ecosystem size dominate the first year, deployment target decides the second, and licence quietly removes candidates before anyone opens a comparison page.

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.