【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，两者的架构类似。
https://i-blog.csdnimg.cn/img_convert/feb82d2f4929115dd9f4699f4b3b60e3.jpeg
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会立即触发回调函数举行处理处罚。
https://i-blog.csdnimg.cn/img_convert/f690e949f4155c800a68a59bcde03b48.png
须要留意：
[*]消息的格式由.msg文件定义，消息可以是简单或嵌套的复合结构。
[*]发布和订阅节点是多对多的，多个节点可以同时发布到同一话题，也可以有多个节点同时订阅一个话题的数据。
例如，在机器人移动的场景中，node1负责发送移动指令（例如通过遥控器接收指令），而node2负责根据指令控制机器人的硬件（如电机）。
这种基于话题的开发方式将功能分层解耦，灵活且可靠，ROS会确保每个节点稳定运行，消息可靠传递。
3.2.2 服务
固然话题的发布/订阅模子非常灵活，但在须要双向同步传输的场景下，服务（Service）更加符合。服务采用客户端/服务器模子，包含两个数据范例：一个用于哀求，另一个用于应答，类似于HTTP哀求。
如下图，node2作为服务方提供一个服务，调用地址为/service。当node1作为客户端调用该服务时，会向/service发送哀求数据，node2收到哀求后举行处理处罚，并将结果返回给node1，完成一次服务调用。
https://i-blog.csdnimg.cn/img_convert/ffa6803f6876658fb4477cad8886ca3d.png
总结：
[*]话题适用于异步通信，解耦信息的生产者和消费者，常用于实时更新的数据互换。
[*]服务适用于同步通信，采用客户端/服务器模式，常用于须要强逻辑处理处罚的数据互换。
4. 开发文件结构
在ROS框架下，可以看到我们的紧张任务是编写节点代码，并通过ROS命令启动节点，形成完整的体系。ROS支持多种编程语言（C、Python、Java），但代码必须遵循ROS的构造结构。
https://i-blog.csdnimg.cn/img_convert/785d1c051d27be0d76b1c80053219868.png
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企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]