A robot is a team of small programs
Open up the software inside a working robot and you will not find one giant program. You will find dozens of small ones, each doing a single job: one reads the camera, one runs the laser scanner, one decides where to drive, one talks to the wheel motors, one watches the battery. They all run at the same time, on one computer or several, and they constantly need each other's results. The camera program's picture is useless unless the program that spots obstacles can see it; the program that picks a path is useless unless it can hand its plan to the motors.
So the central problem of robot software is not any one algorithm — it is plumbing. How do all these programs share data quickly, reliably, and without tripping over each other? Writing that plumbing by hand for every project, every time, would be miserable and bug-prone. The software layer that solves it once, for everyone, is called robotics middleware: a shared communication system that sits between the many programs and lets them pass messages without each one needing to know the others' network addresses.
ROS: the shared plumbing everyone uses
By far the most common middleware in research and industry is the Robot Operating System (ROS). Despite the name, ROS is not an operating system like Windows or Linux — it runs on top of one. It is better thought of as a toolkit plus a set of conventions for building the robotics software stack: a way to package each program, a standard message format so a camera from one vendor and a planner from another can understand each other, and the communication machinery that connects them.
In ROS vocabulary, each running program is a node. A camera driver is a node; an obstacle detector is a node; a motor controller is a node. The whole robot is a node graph — a web of these little programs wired together by the data flowing between them. Because every node speaks the same standard messages, you can swap one out, add a new one, or move a node to a different computer without rewriting the rest. That modularity is the reason a hobbyist and a car company can share the same building blocks.
ROS also ships with reusable parts so you do not start from zero: drivers for common sensors, a transform tree (tf) that keeps track of where every part of the robot is relative to every other, visualization tools, and ready-made stacks for jobs like navigation. Picking up ROS means inheriting a large community's worth of tested building blocks.
Publish–subscribe: the newsletter model
How do nodes actually exchange data? The heart of it is the publish–subscribe pattern. Picture a newsletter. A publisher writes an issue and sends it out on a named channel — say, "Weekly Gardening Tips." Anyone interested subscribes to that channel and receives every issue automatically. The publisher never has to know who the readers are, how many there are, or where they live. The readers never have to chase down the publisher. The channel name is the only thing both sides agree on.
In ROS those named channels are called topics. A node that produces data is a publisher; a node that wants that data is a subscriber. The camera node publishes to a topic named, say, `/camera/image`. The obstacle-detector node subscribes to `/camera/image` and gets every frame as it arrives. The same camera frames can feed several subscribers at once — a recorder, a display, a detector — with no extra work from the publisher. This decoupling is exactly why you can add or remove nodes freely.
[camera node] --publishes--> /camera/image --+--> [obstacle detector]
|
+--> [video recorder]
|
+--> [live display]
one publisher, one topic, three subscribers — none know the others existWhere each piece plugs in: perception, planning, control
Topics and nodes are just wiring — what flows through the wires follows a recurring shape called the perception–planning–control architecture. Perception turns raw sensor data into an understanding of the world ("there is a wall 2 meters ahead"). Planning decides what to do about it ("turn left and go around"). Control turns that decision into precise commands the motors can execute. Data flows from sensing, through thinking, into acting — then the new sensor readings start the loop again.
- Perception nodes subscribe to raw sensor topics (camera, LiDAR) and publish processed results — an obstacle map, a list of detected objects, an estimate of the robot's pose. Several streams are often combined here through sensor fusion.
- Planning nodes subscribe to those perception outputs plus a goal, then publish a path or trajectory. A behavior tree often lives here, deciding which behavior to run next.
- Control nodes subscribe to the planned trajectory and publish low-level commands — wheel speeds, joint torques — onto the topics the motor drivers listen to. This loop usually runs fastest of all.
Seen this way, the architecture and the middleware fit together cleanly: perception, planning, and control are groups of nodes, and the arrows between them are topics. Before any of this touches real hardware, teams test the whole node graph against a robot simulator — the same messages, the same topics, but a virtual robot. Because the nodes only care about topics, they cannot tell whether the data comes from a real camera or a simulated one, which makes moving from simulation to the physical robot remarkably smooth.
Why this design wins (and what to watch for)
The pub/sub-over-middleware design pays off in three big ways. It is modular: teams can build and test nodes independently. It is reusable: a well-written perception node drops into the next robot unchanged. And it scales beyond one machine — the same pattern lets nodes on different computers, or even different robots, share topics over a network, which is the foundation for a multi-robot system where several machines coordinate.
The trade-offs are worth knowing. By default, pub/sub is "fire and forget" — a publisher does not learn whether anyone received a message, so dropped or late data can pass unnoticed and must be designed around. Timing matters: a control loop starved of fresh sensor messages can become unstable. And loosely coupled nodes can be harder to debug, since no single place shows the whole flow — which is why ROS includes tools to record every message and replay it later, turning a fleeting glitch into something you can study at leisure.