本章节主要介绍如何实现 “乌龟护航” 案例。里面的大部分代码会沿用内的相关代码内容。因此建议先尝试实现上一章节的效果，再来进行本章节的实战。

案例需求&分析

需求： 基于上一章节要求编写程序实现，以 turtlesim_node 节点的原生乌龟（turtle1）为几何中心，生成多只新的乌龟（以三只为例，即turtle2、turtle3、turtle4）。要求在 turtle1 无论是静止或是被键盘控制运动时，turtle2 都会以 turtle1 的几何中心为目标并以某种队形对其进行护航。

本章节主要介绍如何实现 “乌龟跟随” 案例。

案例需求&分析

需求： 编写程序实现，程序运行后会启动 turtlesim_node 节点，该节点会生成一个窗口，窗口中有一只原生乌龟（turtle1），紧接着再生成一只新的乌龟（turtle2）。要求在 turtle1 无论是静止或是被键盘控制运动时，turtle2 都会以 turtle1 为目标并向其几何中心运动。

在 TF 框架中，ROS2 除了封装了 坐标广播与监听 功能外，还提供了一些可以帮助我们提高开发、调试效率的工具。本章节主要介绍这些工具的使用。

这些工具主要涉及到两个功能包：tf2_ros 和 tf2_tools。

功能包介绍

tf2_ros 包中提供的常用节点如下：

• static_transform_publisher：该节点用于广播静态坐标变换，在 章节中已有详细说明，不再介绍；

• tf2_monitor：该节点用于打印所有或特定坐标系的发布频率与网络延迟；

• tf2_echo：该节点用于打印特定坐标系的平移旋转关系。

坐标变换监听 可以实现坐标点在不同坐标系之间的变换，或者不同的多个坐标系之间的变换。 针对坐标变换进行监听的前提，是必须已有不同的多个坐标系相对关系的广播，而至于是静态广播或动态广播则无要求。因为监听获取的坐标系相对关系皆为某一时刻或某一时间点。

在中，我们经由案例一实现了多坐标系的场景下实现不同坐标系之间的变换。在这一章节中，我们会实现案例二，即同一坐标点在不同坐标系下的变换。虽然两个案例的需求不同，但是相关算法都被封装好了，我们只需要调用相关 API 即可。

坐标变换监听 可以实现坐标点在不同坐标系之间的变换，或者不同的多个坐标系之间的变换。 针对坐标变换进行监听的前提，是必须已有不同的多个坐标系相对关系的广播，而至于是静态广播或动态广播则无要求。因为监听获取的坐标系相对关系皆为某一时刻或某一时间点。

案例梳理

以下有两个案例：

1. 在中，我们发布了 laser 相对于 base_link，和 camra 相对于 base_link 的坐标系关系，请基于此求解 laser 相对于 camera 的坐标系关系。
2. 在中，我们发布了 laser 相对于 base_link的坐标系关系 和 laser 坐标系下一 点状障碍物 的坐标点数据，请基于此求解在 base_link 坐标系下 该点状障碍物 的坐标。

在 里，我们介绍了静态广播 和 动态广播。本章会主要介绍如何发布坐标点消息。

案例梳理

以下有一案例需求：

有一无人车，在无人车底盘上装有 固定式 的激光雷达。车辆底盘、雷达各对应一坐标系，且各坐标系的原点取其几何中心。现该激光雷达扫描到一 点状障碍物 且可以定位到障碍物的坐标，请在 雷达坐标系下 发布障碍坐标点数据，并在Rviz2 中查看结果。

上述案例是一个简单的 话题发布程序，在了解用于发布坐标点信息的 geometry_msgs/msg/PointStamped 接口消息之后，直接通过 话题发布方 按照一定逻辑发布消息即可。

坐标系相对关系主要有两种：静态坐标系相对关系与动态坐标系相对关系：

• 静态坐标系相对关系 是指两个坐标系之间的相对位置是 固定不变 的，比如：车辆上的雷达、摄像头等组件一般是固定式的，那么雷达坐标系相对于车辆底盘坐标系或摄像头坐标系相对于车辆底盘坐标系就是一种静态关系。

• 动态坐标系相对关系 是指两个坐标系之间的相对位置关系是 动态改变 的，比如：车辆上机械臂的关节或夹爪、多车编队中不同车辆等都是可以运动的，那么机械臂的关节或夹爪坐标系相对车辆底盘坐标系或不同车辆坐标系的相对关系就是一种动态关系。

我们在操作机器人时，通常会使用各种传感器感知机器人周围的物体与机器人的相对位置。不过在未针对传感器进行配置的情况下，传感器只能够返回其自身与物体的相对位置。因此我们需要通过某些特定的转换工程，才可以将该传感器的方位信息，变换物体相对于机器人系统或机器人其它组件的方位信息。在 ROS 中直接封装了相关的模块，其名称为 tf(TransForm Frame)

概念

该模块允许用户随时间跟踪多个坐标系。它在拥有 时间缓冲 的 树状结构 中维护坐标帧之间的关系，并让用户在 任何 所需的时间点在 任意 两个坐标帧之间变换点、向量等。在ROS中已经提供了同名的库实现，并且随着ROS的迭代，该库升级为了tf2，也即第二代坐标变换库。

由来看，我们不难发现对于坐标变换的实现，其本质是基于话题通信的发布订阅模型。发布方可以发布坐标系之间的相对关系，订阅方则可以监听这些消息，并实现不同坐标系之间的变换。根据，在话题通信中，接口消息 作为数据载体在整个通信模型中是比较重要的一部分。

本章将会介绍坐标变换中常用的两种接口消息：geometry_msgs/msg/TransformStamped 和 geometry_msgs/msg/PointStamped。

前者用于描述某一时刻两个坐标系之间相对关系的接口，后者用于描述某一时刻坐标系内某个坐标点的位置的接口。在之后的坐标变换中，我们会经常性的使用到坐标系相对关系以及坐标点相关信息。

这里是我有关ROS2工具 - 坐标变换 的相关笔记，包括的内容有：

• 坐标变换的概念与应用场景
• 坐标变换的两种重要消息载体: TransformStamped & PointStamped 的定义格式（基于 话题通信 ）
• 坐标变换的通信双方（广播方与监听方）
• 坐标变换工具 （相关指令的进一步说明以及调试工具等）

具体软硬件以及技术背景等细节请参考

假设你有一个机器人：

• 它在日常运行时没有问题，但是在某一次运行时突然报错了。你希望即刻对此进行排查，但是这个报错只出现了一次，再次运行又没有报错了。
• 你给他重新设计了一个运动控制节点，但是调不准它的一些特定参数。如果在真实环境中直接运行可能会出现意想不到的情况。
• 你在某一次运动导航实验中意外的获得了一条导航路径，希望有什么工具把它保存下来，以便之后复现该结果。

针对数据的留存及其读取实现，ROS2 提供了专门的工具 —— rosbag2

有关 launch 文件的介绍，可以参考

除非你希望仅使用 C++ 进行编写，否则由于 XML & YAML 语言自身并无事件触发函数能进行适配，我个人并不推荐使用 XML/YAML 语言作为编写 launch 的首要语言（虽然他编写起来确实较为简便 = =）。若有实际需要，请结合官方文档进行代码的书写。

有关 launch 文件的介绍，可以参考

Python 实现语法

以下介绍在 Python 中 launch 文件 的相关语法：

1. 节点设置-Node

在 使用 Python 实现的 launch 文件 中，被执行的节点需要统一封装为 launch_ros.actions.Node 对象，并通过 LaunchDescription() 函数创建特定包装对象以进行返回。以下将会针对统一封装的 Node 对象内的参数进行说明。

在机器人操作系统中，节点是程序的基本构成单元。一个完整的、系统性的功能模块由多个节点构成，在启动某个功能模块时可能需要依次启动这些节点。

以机器人的导航功能为例，其涉及的节点主要有以下几种：

• 底盘驱动；
• 雷达驱动；
• 摄像头驱动；
• imu 驱动；
• 地图服务；
• 路径规划；
• 运动控制；
• 环境感知；
• 定位；
• etc.

且不同的节点启动时，可能还会涉及到各种参数的导入、节点间执行逻辑的处理等。

这里是我有关 ROS2工具 - launch & rosbag2 内容的相关笔记，这里所包括的内容有：

• launch 文件及其实现
• rosbag2 工具的介绍与使用（序列化存储数据，实现话题消息的录制与回放）

具体软硬件以及技术背景等细节请参考

二、图形化工具（RQt）

简述

RQt 是一个基于 Qt 框架 开发的 GUI 框架。它通过应用各种 “以插件形式存在的工具与接口” 实现在单个页面开发、调试与监控机器人系统，其允许用户通过配置插件灵活地与 ROS2 系统进行交互。作为通信机制工具只是其中的一种功能，在这里仅会做一些简要的入门介绍。

上一章内容，我们学习了ROS2中的多种通信机制，了解了不同通信模型的实现流程、相关API以及各自的特点。在实际开发当中，我们可能会遇到一些问题：

1. 一个完整的机器人系统启动之后，其组成是比较复杂的，可能包含十几个、几十个甚至上百个节点，不同的节点可能又包含一个或多个通信对象(话题发布方、话题订阅方、服务端、客户端、动作服务端、动作客户端、参数服务端、参数客户端)，通信时还需要使用到各种各样的msg、srv或action接口消息，那么在开发过程中，如何才能方便的获取这些节点、话题、服务、动作、参数以及接口相关的信息呢？
2. 编写通信实现，通信至少涉及到双方，一方编写完毕后，如何验证程序是否可以正常运行呢？
3. 话题通信过程中，发布方程序中设置了消息的发布频率，如何判断实际运行中的发布频率是否和设置的频率一致呢？
4. ......

假设有一个机器人，在机器人上有一个雷达。该雷达有一相关节点会发布雷达探测到的各种信息，且会被机器人内部一导航模块所属节点订阅并接收。为了减少机器人移动过程中由于通信延迟在路径规划上产生相关误差，当二者进行数据交互时，必然需要保证信息的实时性。

因此我们需要使用 时间类 API，在传输数据时提供相关数据产生时的时间戳使接收方能够进行相关数据时效性的判断。除此之外，雷达坐标变换或多消息融合等也需要该类 API。

类型

时间类 API 一共有以下几种：

• Rate 类
• Time 类
• Duration 类

咱在之前聊到，那么有话题重名吗？

有的，dude，有的☝🤓

与节点重名相同，在 ROS2 中，话题名称也可能重名。在不同的节点之间，通信都依赖于话题，当话题重名时，系统虽然不会抛出异常，但是通过 相同话题名称 关联到一起的节点可能 并不属于 同一通信逻辑，从而导致通信错乱，甚至出现异常。这种情况下可能就需要将相同的话题名称设置为不同。

不过与节点重名不同的是，有些场景下需要避免话题重名的情况，在有些场景下又需要将不同的话题名称修改为相同以实现某些功能。因此话题重名在某些情况下是被 允许 的。

在 ROS2 中，不同的节点可以有相同的节点名称，比如你可以启动多个节点的名称都是 turtlesim 的 turtlesim_node 节点。

虽然节点重名是被 允许 的，但是开发者应该 主动避免 这种情况，因为节点重名可能会导致操作上的混淆。

仍以启动了多个 turtlesim_node 节点为例，当使用 计算图（rqt_graph） 查看节点运行状态时，由于这些节点的名称一致，它们在计算图上会被显示为同一个节点，而实际上是有多个节点。并且节点名称也会和话题名称、服务名称、动作名称、参数等多种变量产生关联，届时也可能会导致通信逻辑上的混乱。

在 ROS2 中编写功能包时，一般会在单个空间内进行编写与编译。但是当程序员需要经由多个工作空间进行不同的功能包的编写式，很可能会出现在不同的工作空间下将不同的功能包命名为同一个名字的情况。例如在 工作空间A 和 工作空间B 中都创建了一个名字叫 “C” 的功能包，假设该功能包里都有一个 “C_node” 节点，那么当我们新建终端并直接执行

ros2 run C C_node

在 ROS2 中编写一个大的模块时，一般需要依照不同的功能分成多个子包。例如对于一个机器人导航模块，该模块可能被分为定位、路径规划、离线地图等多个子包进行分别编写。那么当我们需要安装该模块时，需要一个个安装这些子包才可以应用全部功能吗？

元功能包(MetaPackage)

在 ROS2 中，其提供了一种可以将多个不同的功能子包打包成一个大的功能包的方式，当我们需要安装某个功能模块时，只需要直接调用安装这个大的功能包即可。该包又被称为 元功能包 ，即 MetaPackage。

这里是我有关ROS2通信机制补充内容的相关笔记，这里的内容比起而言知识密度比较松散，包括的内容有：

• 分布式框架的搭建（实现不同的 ROS2 设备间通信）
• 重名问题的处理（自定义功能包、节点、节点内话题重名的处理）
• 常用 API （定时器等时间类 API）
• 通信机制工具 （相关指令的进一步说明以及 rqt 工具箱等）

具体软硬件以及技术背景等细节请参考

在之前的中，我们系统地学习了四种通信机制。这四种通信机制在当时的应用场景都为单个ROS设备内相关节点、话题之间的相互沟通。那么当我们涉及到多台 ROS2 设备之间的相互通信时，我们应该如何实现？

分布式通信

分布式通信就是这样一种 通过网络 在不同主机之间实现 数据交互 的通信策略。

首先我们应该了解， ROS2 本身就是一个分布式通信框架，它可以通过中间件很方便的实现不同设备之间的通信。

ROS2 所基于的中间件为数据分发服务（Data Distribution Service, 简称DDS），当多台 ROS2 设备处于同一网络时，通过 DDS 的 域ID机制(ROS_DOMAIN_ID) 便可以实现分布式通信。其大致流程为：

这里是有关ROS2通信机制核心内容的相关笔记,其包括了ROS2内常用的四种通信方式：

• Topics (话题通信)
• Services (服务通信)
• Actions (动作通信)
• Parameters (参数服务)

具体软硬件以及技术背景等细节请参考

现在，我们通过针对以下案例需求进行 Python 的实现，以更加深入了解参数服务。

案例需求&案例分析

需求：有两个节点，请编写参数服务，在参数服务端（节点A）中设置一些参数，使参数客户端（节点B）可以通过访问参数服务端（节点A）对这些参数实现查看与修改，并且参数服务端（节点A）自身可以对此进行增删改查。

分析：在上述需求中，我们需要关注以下三个要素：

1. 参数服务端；
2. 参数客户端；
3. 参数本身。

流程简介

现在，我们通过针对以下案例需求进行 C++ 的实现，以更加深入了解参数服务。

案例需求&案例分析

需求：有两个节点，请编写参数服务，在参数服务端（节点A）中设置一些参数，使参数客户端（节点B）可以通过访问参数服务端（节点A）对这些参数实现查看与修改，并且参数服务端（节点A）自身可以对此进行增删改查。

分析：在上述需求中，我们需要关注以下三个要素：

1. 参数服务端；
2. 参数客户端；
3. 参数本身。

流程简介

案例实现前需要先了解ROS2中参数的相关API，无论是客户端还是服务端都会使用到参数，而参数服务案例实现主要步骤如下：

参数（Parameters） 是 ROS2 中用于节点运行时动态配置的键值对（Key-Value）存储机制。参数并不需要中心化的仓库用于存储信息，其直接被归属于节点本身。参数允许通过服务接口在该节点运行期间读写其内部相关配置，而无需修改代码或重启该节点。与话题通信（Topics）和服务通信（Services）不同，参数的交互本质是 对节点内部状态的访问与控制，而非单纯的节点间数据流通。

具体而言：

• 参数直接存储在节点内部，每个节点维护独立的参数列表，通过命名空间（例如 /control_node/max_speed）进行隔离。
• 参数通过 ROS2 内置的参数服务接口（如 /get_parameters 和 /set_parameters 等）访问，其访问逻辑底层依赖于 ROS2 服务通信（Services）机制。
• 同一节点内的参数可被多个外部对象（如 CLI 工具、其他节点、RQT 界面等）同时访问，形成 单服务端（节点）对 多客户端 的交互模式。

现在，我们通过针对以下案例需求进行Python的实现，以更加深入了解动作通信。

案例需求&案例分析

需求：编写动作服务端，动作客户端提交一个整型数据N，动作服务端接收请求数据并累加1-N之间的所有整数，将最终结果返回给动作客户端，且每累加一次都需要计算当前运算进度并反馈给动作客户端。

分析：在上述需求中，我们需要关注以下三个要素：

1. 动作客户端；
2. 动作服务端；
3. 消息载体。

流程简介

案例实现前需要自定义动作接口。

现在，我们通过针对以下案例需求进行C++的实现，以更加深入了解动作通信。

案例需求&案例分析

需求：编写动作通信，动作客户端提交一个整型数据N，动作服务端接收请求数据并累加1-N之间的所有整数，将最终结果返回给动作客户端，且每累加一次都需要计算当前运算进度并反馈给动作客户端。

分析：在上述需求中，我们需要关注以下三个要素：

1. 动作客户端；
2. 动作服务端；
3. 消息载体。

流程简介

案例实现前需要自定义动作接口。

动作通信(Actions) 同样是一种基于 请求响应 的方式，以实现不同节点之间数据传输的通信模式。其中发送请求数据的对象称为 客户端，接受请求并发送数据相应的对象称之为 服务端。为了与前文的 相区分，将这里的客户端称为动作客户端，服务端称为动作服务端。

在结构上，动作通信由目标、反馈和结果三个部分组成,因此和 服务通信 不同的是，动作通信 可以在请求响应过程中获取连续反馈，并且也可以向动作服务端发送任务取消请求。

实现自定义动作接口消息的流程与的流程类似，其主要步骤如下：

1. 创建并编写 .action 文件；
2. 编辑配置文件；
3. 编译；
4. 测试。

因此，我们现在会在创建的接口功能包 base_interfaces_demo 里，尝试编写一个 .action 文件。该文件中包含请求数据(两个整型字段)与响应数据(一个整型字段)。

创建并编辑 .action 文件

在功能包 base_interfaces_demo 下新建 action 文件夹，action 文件夹下新建 Progress.action 文件，文件中输入如下内容：

版权声明：本文为博主转载文章，遵循 CC 4.0 BY 版权协议。因为自测有用转载至此，以下为原文链接👇

原文链接：https://blog.csdn.net/weixin_44023934/article/details/121242176

rosdep update命令使用

该方法是可以跳过 sudo rosdep init 初始化命令设置的，前提是安装ros，rosdep update 是安装一些依赖库，比如在 Cartographer、ORB-SLAM 等算法需要使用到一些依赖库，是必须安装的，如果不是有需要的，只是使用 ros 一般依赖，是不需要 rosdep update 的

现在，我们通过针对以下案例需求进行Python的实现，以更加深入了解服务通信。

案例需求&案例分析

需求：编写服务通信，客户端可以提交两个整数到服务端，服务端接收请求并解析两个整数求和，然后将结果响应回客户端。

分析：在上述需求中，我们需要关注以下三个要素：

1. 客户端；
2. 服务端；
3. 消息载体。

流程简介

案例实现前需要自定义服务接口。

在接口准备完毕后，服务通信实现的主要步骤如下：

现在，我们通过针对以下案例需求进行C++的实现，以更加深入了解服务通信。

案例需求&案例分析

需求：编写服务通信，客户端可以提交两个整数到服务端，服务端接收请求并解析两个整数求和，然后将结果响应回客户端。

分析：在上述需求中，我们需要关注以下三个要素：

1. 客户端；
2. 服务端；
3. 消息载体。

流程简介

案例实现前需要自定义服务接口。

在接口准备完毕后，服务通信实现的主要步骤如下：

1. 编写服务端实现；
2. 编写客户端实现；
3. 编辑配置文件；
4. 编译；
5. 执行。

服务通信(Services)是一种基于 请求响应 的方式实现不同节点之间数据传输的通信模模式。发送请求数据的对象称为客户端，接受请求并发送数据相应的对象称之为服务端，与话题通信一样，客户端和服务端也通过话题(Topic)相关联，但是客户端和服务端可以互相进行数据传输交互。因此在服务通信中，消息的流向是双向的。

在服务通信中，服务端与客户端是一种一对多的关系。也就是说，在同一服务话题下，可以存在多个客户端，但只能存在一个服务端。每个客户端都可以向服务端发送请求，也即与该单个服务端之间建立独立的相互通信。

实现自定义服务接口消息的流程与的流程类似，其主要步骤如下：

1. 创建并编写 .srv 文件；
2. 编辑配置文件；
3. 编译；
4. 测试。

因此，我们现在会在创建的接口功能包 base_interfaces_demo 里，尝试编写一个 .srv 文件。该文件中包含请求数据(两个整型字段)与响应数据(一个整型字段)。

创建并编辑 .srv 文件

在功能包 base_interfaces_demo 下新建 srv 文件夹，srv 文件夹下新建 AddInts.srv 文件，文件中输入如下内容：

实现自定义话题接口消息的流程与在功能包中编写可执行程序的流程相似，其主要步骤如下：

1. 创建并编写 .msg 文件；
2. 编辑配置文件；
3. 编译；
4. 测试。

因此，我们现在会在创建的接口功能包 base_interfaces_demo 里，尝试编写一个 .msg 文件。该文件中包含学生的姓名、年龄、身高等字段。

创建并编辑 .msg 文件

在功能包 base_interfaces_demo 下新建 msg 文件夹，msg 文件夹下新建 Student.msg 文件，文件中输入如下内容：

在案例1中，案例1所发布的消息是一个字符串文本，其消息类型是ROS2的内置消息类型。与使用原生消息接口相比，使用自定义消息接口发布的信息所对应的信息载体并没有被预定义，因此需要我们自己进行配置。

接下来我们将使用 自定义消息接口 实现话题通信。如果还没有在Ubuntu中执行准备工作的，可以参考。

自定义消息接口文件

具体实现请参考

C++

1. 发布方实现

功能包 cpp01_topic 的 src 目录下，新建 C++ 文件 demo03_talker_self.cpp，并编辑文件，输入如下内容：

在日常编写代码中，由于多个并行文件的创建，会出现许多代码重复编写的情况。例如创建 .vue 文件时需要分别创建 script 标签、 template 标签，或者在 ROS2 中创建节点文件时无论 C++ 文件之间还是 Python 文件之间的代码结构，都出现基本相同的情况等等。

为了减少重复代码的编写，提升代码编写效率，我们可以在 VSCode 中设置自定义代码片段来自动为我们生成相应自定义片段。

接下来我们将使用 原生消息接口 实现话题通信。如果还没有在Ubuntu中执行准备工作的，可以参考。

C++

1. 发布方实现

功能包 cpp01_topic 的 src 目录下，新建 C++ 文件 demo01_talker_str.cpp，并编辑文件，输入如下内容：

/*
    需求：以某个固定频率发送文本“Hello World!”，且文本后缀编号，每次发送一条信息，编号递增1.
    步骤：
        1. 包含头文件；
        2. 初始化 ROS2 客户端
        3. 自定义节点类：
            3-1. 创建发布方；
            3-2. 创建定时器；
            3-3. 组织消息并发布。
        4. 调用spin函数，并传入节点对象指针
        5. 释放资源。
 */

// 1. 包含头文件；
#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"

using namespace std::chrono_literals;

// 3. 自定义节点类：
class MinimalPublisher : public rclcpp::Node
{
    public: 
    // count_(0) 的作用是将 count_ 初始化为 0
        MinimalPublisher() : Node("minimalpublisher"), count_(0)
        {
        // 3-1. 创建发布方；

        /*
            模板： 被发布的消息类型
            参数：
                1. 话题名称；
                2. QOS(消息队列长度)；
            返回值：发布对象指针。
         */

        publisher_ = this->create_publisher<std_msgs::msg::String>("topic", 10); 
        // 3-2. 创建定时器；
        /*
            参数：
                1. 时间间隔；
                2. 回调函数；
            返回值：定时器对象指针。
         */
        timer_ = this->create_wall_timer(500ms, stc::bind(&MinimalPublisher::timer_callback, this)) 
        } 
    private: 
        void timer_callback() 
        {
            // 3-3. 组织消息并发布。
            auto message = std_msgs::msg::string();
            message.data = "Hello, world!" + std::to_string(count_++); RCLCPP_INFO(this->get_logger(), "发布的消息： '%s'", message.data.c_str());
            publisher_->publish(message); 

        }
        rclcpp::Publisher<stdmsgs::msg::String>::SharedPtr publisher_;
        rclcpp::TimerBase::SharedPtr timer_;
        size_t count_;
};

int main(int argc, char *argv[])
{
    // 2. 初始化 ROS2 客户端
    rclcpp::init(argc, argv);
    // 4. 调用spin函数，并传入节点对象指针。
    rclcpp::spin(std::make_shared<MinimalPublisher>());
    // 5.释放资源;
    rclcpp::shutdown();
    return 0; 
}

在通信过程中，当节点间需要传输数据时，就必然需要以特定格式传输数据，也就是我们常用的数据载体。在ROS2中，数据载体被称之为接口(interfaces)。

常用的接口文件

通信时使用的数据载体一般需要使用接口文件定义。常用的接口文件有三种：msg 文件、srv 文件与 action 文件，分别用于对应所述的话题通信、服务通信和动作通信，并且每种文件都需要按照一定格式定义 特定数据类型的 “变量”。

话题通信(Topics)是一种以发布 订阅 的方式实现不同节点之间数据传输的通信模式。数据发布对象称为发布方，数据订阅对象称之为订阅方，发布方和订阅方通过话题(Topic)相关联，发布方将消息(Message)发布在话题上，订阅方则从该话题订阅消息(Message)。因此在话题通信中，消息的流向总是单向的。

但是在话题通信中发布方与订阅方是一种多对多的关系，也就是说，话题通信的同一话题下可以存在多个发布方，也可以存在多个订阅方，这意味着数据会出现交叉传输的情况。

作为一种高度复杂的系统性实现，在机器人中，一个完整的机器人应用程序一般会由若干功能模块组成，其中每个功能模块可能又包含若干功能点，而不同功能模块、不同功能点之间通常需要频繁的进行数据交互。 比如以导航中的路径规划模块为例：

• 路径规划模块需要其他功能模块将各种数据输入，并输出相应处理后的数据以便被其他模块调用；
• 输入的数据有地图服务提供的地图数据、定位模块提供的机器人位姿数据、人机交互模块提供的目标点数据等；
• 而输出的处理后的数据，即路径信息等则会被运动控制订阅或是回显在人机交互界面上。

这里是我有关ROS2的相关笔记，这些笔记内所使用的相关软硬件配置为：

• ROS2 Jazzy Jalisco LTS
• Ubuntu 24.04.3 LTS
• Raspberry Pi 5B (4GB)

这些笔记大部分参考以下网站和视频教程写成：

• ROS2-Jazzy官方支持文档: ROS 2 Documentation — ROS 2 Documentation: Jazzy documentation
• 清华大学出版社出版的《ROS机器人理论与实践》教材的主要作者赵虚左的ROS2网课: 猛狮集训营视频合集·ROS2理论与实践核心篇

在C++中：

#include "rclcpp/rclcpp.hpp"

class MyNode: public rclcpp::Node{
public:
        MyNode():Node("hello_node_cpp"){
            RCLCPP_INFO(this->get_logger(), "helloworld");
        }

};

int main(int argc, char const *argv[])
{
    //初始化
    rclcpp::init(argc, argv);
    // 实例化自定义类
    auto node = std::make_shared<MyNode>();
    // ......

    // 资源释放
    rclcpp::shutdown();

    return 0;
}

从传输层开始

传输层的主要功能是提供端到端的数据传输服务，例如 TCP 协议提供了可靠的、面向连接的数据传输服务。TCP使用序列号、确认应答、重传等机制来确保数据的可靠传输。因此，从抽象角度来看，我们可以将传输层之间的特定通讯视为提供了一种相对可靠的通信机制。

checksum 的构造方法比较简单，但是计算比较麻烦：将需要发送的 16-bit 二进制源数据两两相加，取从右往左数共十六位数，如果有多的位数就把该位数移到最低位再相加。如此反复将所有需要发送的数据相加完毕后对它作反码，即将这十六位数的1置0，0置1。

具体需要的数据以下列的表格作为例子：

UDP 是一种简洁、轻量级的传输协议，只提供最基本的通讯服务。UDP 定义于 [RFC 768]，其功能与传输协议差不多。除了多路复用/解复用功能和一些轻微的错误检查功能外，它没有为 IP 增加任何功能。也就是说，如果一个应用程序开发人员选择 UDP 而不是 TCP 作为传输协议的话，那么该应用程序几乎可以被认为是在直接与 IP 对话而没有任何其他的包装。

UDP 是无连接的，因此在两个进程开始通信之前不需要提前握手。因此，当应用程序通过 UDP 而不是 TCP 运行时，专用于这些特定应用程序的服务器通常可以支持更多的在线客户端。

UDP 提供的是一种不可靠的数据传输服务，也就是说：

翻译一下就是：

假设你打开浏览器，并在地址栏中输入 http://yourbusiness.com/about.html, 请问从你按下回车开始到在显示网页的过程间会发生什么？请提供所使用协议的详细信息以及所交换信息的高级描述。