【ROS实战】02-ROS架构介绍
1. 简介
你是否曾有过这样的疑问：我按照文档安装了ROS，依照要求写了一些示例节点（node）、消息（msg）和话题（topic），但觉得过程既麻烦又繁琐。也许你开始怀疑：为什么需要ROS？它到底帮我解决了什么问题？
本文将通过一个简单的例子，介绍ROS的架构，阐明它解决了哪些问题，以及它如何帮助我们简化开发流程。
2. 移动案例
假设我们要编写一个能够控制机器人移动的程序。
- 随着程序的增多，我们需要进行模块化，方便分工合作和代码复用；
- 还需要开放移动接口，使得其他模块能够调用移动控制功能；
- 对应，需要选型一个通信机制来传递移动指令；
- 移动指令的格式，返回消息的格式需要规范化管理；
- 指令可能需要同时传给多个模块，如果下游模块没有及时收到可能需要缓存；
- 此外，我们还需要确保各个模块服务的持续运行，能够有效管理；
- 模块多了后，多对多的消息传递，日志，可能需要一种有效的监控和调试手段。
你会发现，一个简单的移动控制功能，背后可能涉及了大量的框架设计、标准化工作和大量代码量，如果全部手工实现，不同的人实现方案可能五花八门，也使得开发者很难专注于机器人的核心功能（如更好地移动、刹车、转弯等）。
在这种情况下，ROS的出现就解决了这些问题。下面是ROS中的一些关键概念：
- 节点(node)：每个节点对应一个功能模块，ROS会帮助你管理节点的生命周期，确保它们稳定运行并完成各自的任务，免去你手动管理进程或线程的麻烦。
- 消息(message)：消息定义了节点之间传递的数据结构，如运动指令、雷达数据、坐标数据等。ROS提供了许多常用的消息类型，你可以直接使用这些标准的消息类型，无需重复设计数据格式。如果你的团队其他成员或外部开源项目遵循相同的消息标准，那么这些模块可以无缝对接。
- 话题(topic)：话题是消息传递的方式之一。比如，假设你和其他模块约定使用
cmd_vel话题来传递运动指令。所有需要发送或接收运动指令的节点都可以订阅或发布到cmd_vel话题。当遥控器节点发布指令时，移动控制节点只需订阅cmd_vel话题，接收到指令后即可控制机器人移动。和消息队列的概念很相似，这个机制有效的解决了分层解耦和模块化的问题。
3. ROS框架
3.1 整体架构
根据上述案例，ROS的架构可以简要概括为：编写节点（node），节点程序中通过话题（topic）或服务（service）与其他节点进行通信，完成机器人相关的逻辑控制。整体架构图如下，左侧是ROS1，右侧是ROS2，两者的架构类似。
ROS的框架大致分为三层：
- 应用层：即我们编写的各个节点。
- 中间层：ROS提供API以及内部通信机制，帮助开发者与ROS系统交互。
- 操作系统层：ROS并不是独立的操作系统，而是依赖于现有操作系统运行。ROS1仅支持Linux，ROS2支持更多操作系统。
图中其他名词解释：
- Master（主节点）：负责管理系统中的节点，提供节点注册、发现和信息转发等服务。
- Client Library（客户端库）：提供开发者API，供节点编程、消息传递等操作。
- TCPROS/UDPROS（TCP/UDP协议）：ROS1中的通信协议，负责节点间数据传输。
- Nodelet API（节点内API）：允许多个节点在同一进程内运行，避免进程间通信的开销。
- Abstract DDS Layer（抽象DDS层）：ROS2的核心通信机制，基于DDS标准提供分布式通信能力。
- Intra-process API（进程内通信API）：用于高效的内部通信，避免跨进程通信的开销。
- DDS（数据分发服务）：ROS2的底层通信协议，负责实现节点间高效可靠的数据交换。
ROS1和2主要区别：
- ROS1依赖Master节点来协调节点间的通信，而ROS2使用DDS协议实现去中心化的分布式通信。
- ROS2引入了进程内通信（Intra-process API），减少了进程间通信的开销，提高了效率。
- ROS2的DDS通信层使得它更加灵活，可以支持不同的操作系统和硬件平台。
3.2 通信机制
通信机制是ROS的核心，开发节点的主要目的是数据的流转和处理。充分利用ROS的通信框架是标准化、简化以及提升开发灵活性和健壮性的关键。
3.2.1 话题
话题通信是ROS中最常用的通信方式，类似于常见的消息队列。
如下图，假设有两个节点，node2订阅了/topic话题，它会监听这个话题是否有新消息。当node1发布消息到/topic话题时，node2会立即触发回调函数进行处理。
需要注意：
- 消息的格式由
.msg文件定义，消息可以是简单或嵌套的复合结构。 - 发布和订阅节点是多对多的，多个节点可以同时发布到同一话题，也可以有多个节点同时订阅一个话题的数据。
例如，在机器人移动的场景中，node1负责发送移动指令（例如通过遥控器接收指令），而node2负责根据指令控制机器人的硬件（如电机）。
这种基于话题的开发方式将功能分层解耦，灵活且可靠，ROS会确保每个节点稳定运行，消息可靠传递。
3.2.2 服务
虽然话题的发布/订阅模型非常灵活，但在需要双向同步传输的场景下，服务（Service）更加合适。服务采用客户端/服务器模型，包含两个数据类型：一个用于请求，另一个用于应答，类似于HTTP请求。
如下图，node2作为服务方提供一个服务，调用地址为/service。当node1作为客户端调用该服务时，会向/service发送请求数据，node2收到请求后进行处理，并将结果返回给node1，完成一次服务调用。
总结：
- 话题适用于异步通信，解耦信息的生产者和消费者，常用于实时更新的数据交换。
- 服务适用于同步通信，采用客户端/服务器模式，常用于需要强逻辑处理的数据交换。
4. 开发文件结构
在ROS框架下，可以看到我们的主要任务是编写节点代码，并通过ROS命令启动节点，形成完整的系统。ROS支持多种编程语言（C、Python、Java），但代码必须遵循ROS的组织结构。
ROS文件结构：
- 工作空间（Workspace）：顶级目录（图中的catkin workspace）为一个工作空间。
- 构建文件：二级目目录中的
build、devel、install为构建过程生成的文件。 - 功能包（Package）：在
工作空间.src目录下，是一系列的功能包，每个功能包可包含多个节点，具体取决于项目需求。
功能包是我们主要面向开发的内容，功能包内部目录结构：
- config：存放配置文件。
- include：存放头文件。
- scripts：存放可直接运行的Python脚本。
- src：存放C++源代码。
- launch：存放启动文件。
- msg：存放自定义消息类型。
- srv：存放自定义服务类型。
- CMakeLists.txt：编译规则。
- package.xml：功能包清单。
5. 小结
ROS为机器人开发提供了一个强大的框架，简化了功能模块化设计、数据交换和服务通信。通过标准化的消息、话题和服务，ROS帮助开发者高效构建分布式、可扩展的机器人系统，减少了低层次的通信和管理工作，使开发者能够专注于机器人本身的核心功能。