机器人是一群小程序组成的团队
打开一台运转中的机器人内部的软件，你不会看到一个庞大的程序，而会看到几十个小程序，每个只做一件事：一个读取摄像头，一个运行激光扫描仪，一个决定往哪开，一个驱动车轮电机，一个监视电池。它们同时运行，分布在一台或多台计算机上，并且不断需要彼此的结果。摄像头程序拍下的画面若没人看得到就毫无用处；挑选路径的程序若无法把方案交给电机也同样无用。
因此机器人软件的核心问题不是某一个算法，而是“管道”：所有这些程序如何快速、可靠、互不干扰地共享数据？为每个项目、每一次都手写这套管道，既痛苦又容易出错。一次性地为所有人解决这个问题的软件层，叫做机器人中间件：一个位于众多程序之间的共享通信系统，让它们能互传消息，而无需各自知道对方的网络地址。
ROS：人人都在用的共享管道
在研究界与工业界，迄今最常用的中间件是 机器人操作系统（ROS）。尽管名字如此，ROS 并不是像 Windows 或 Linux 那样的操作系统——它运行在操作系统之上。更恰当的理解是：它是一套工具加上一组约定，用来构建机器人软件栈：一种打包每个程序的方式、一种标准消息格式（让某家厂商的摄像头与另一家的规划器彼此听懂），以及把它们连接起来的通信机制。
在 ROS 的术语里，每个运行中的程序叫一个节点。摄像头驱动是一个节点；障碍检测器是一个节点；电机控制器是一个节点。整台机器人就是一张节点图——这些小程序由它们之间流动的数据连成一张网。由于每个节点都说同样的标准消息，你可以替换其中一个、新增一个，或把某个节点搬到另一台计算机上，而不必重写其余部分。正是这种模块化，让业余爱好者和汽车公司能共用同一批积木。
ROS 还自带可复用的部件，让你不必从零开始：常见传感器的驱动、一棵坐标变换树（tf）（持续记录机器人每个部件相对于其他部件的位置）、可视化工具，以及为导航等任务准备好的现成软件栈。上手 ROS，意味着继承了一整个庞大社区经过检验的积木。
发布—订阅：简报订阅模型
节点究竟如何交换数据？其核心是发布—订阅模式。想象一份简报：发布者写好一期，发到一个有名字的频道上——比如“每周园艺贴士”。任何感兴趣的人订阅该频道，就会自动收到每一期。发布者无需知道读者是谁、有多少、住在哪里；读者也无需四处去找发布者。双方唯一需要约定的，只有频道的名字。
在 ROS 里，这些有名字的频道称为话题（topic）。产出数据的节点是发布者（publisher）；想要这份数据的节点是订阅者（subscriber）。摄像头节点向一个名为 `/camera/image` 的话题发布数据；障碍检测节点订阅 `/camera/image`，每一帧到达就立刻收到。同一批摄像头帧可以同时喂给好几个订阅者——录制器、显示器、检测器——而发布者无需任何额外工作。正是这种“解耦”，让你能自由地增删节点。
[camera node] --publishes--> /camera/image --+--> [obstacle detector]
|
+--> [video recorder]
|
+--> [live display]
one publisher, one topic, three subscribers — none know the others exist每块拼图插在哪里：感知、规划、控制
话题和节点只是布线——在线缆里流动的内容则遵循一种反复出现的结构，叫感知—规划—控制架构。感知把原始传感器数据变成对世界的理解（“前方两米处有一堵墙”）。规划决定如何应对（“左转绕过去”）。控制把这个决定变成电机能精确执行的指令。数据从感知流经思考、流入行动——随后新的传感器读数又开启下一轮循环。
- 感知节点订阅原始传感器话题（摄像头、激光雷达），发布处理后的结果——障碍地图、检测到的物体列表、对机器人位姿的估计。此处常通过传感器融合把多路数据流合并起来。
- 规划节点订阅这些感知输出，再加上一个目标，然后发布一条路径或轨迹。此处常驻一棵行为树，决定下一步该执行哪种行为。
- 控制节点订阅规划好的轨迹，并把底层指令——轮速、关节力矩——发布到电机驱动所监听的话题上。这个回路通常是所有回路中跑得最快的。
这样看来，架构与中间件就严丝合缝地对上了：感知、规划、控制是一组组节点，它们之间的箭头就是话题。在这一切接触真实硬件之前，团队会先用机器人仿真器测试整张节点图——同样的消息、同样的话题，只是机器人是虚拟的。由于节点只关心话题，它们分辨不出数据来自真摄像头还是仿真摄像头，这让从仿真迁移到实体机器人变得格外顺畅。
为何这种设计能胜出（以及要当心什么）
这种“在中间件之上跑发布/订阅”的设计在三个大方面带来回报。它模块化：各团队可以独立构建和测试节点。它可复用：一个写得好的感知节点能原封不动地用到下一台机器人上。它还能跨越单机扩展——同样的模式让不同计算机、甚至不同机器人上的节点通过网络共享话题，这正是多台机器协同的多机器人系统的基础。
它的权衡也值得了解。默认情况下，发布/订阅是“发完即不管”——发布者并不知道是否有人收到消息，因此丢失或迟到的数据可能在不知不觉中溜过去，必须在设计上加以防范。时序很重要：控制回路若得不到新鲜的传感器消息，可能变得不稳定。松耦合的节点也更难调试，因为没有任何单一位置能展示整条数据流——这正是 ROS 内置工具来记录每一条消息并稍后回放的原因，它把转瞬即逝的故障变成可以从容研究的对象。