【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帮助开发者高效构建分布式、可扩展的机器人体系，减少了低层次的通信和管理工作，使开发者能够专注于机器人自己的核心功能。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。