ROS1 C++代码配置Master

金三亲

已于 2022-06-28 16:43:06 修改

阅读量1.2k

点赞数 1

分类专栏： ROS 文章标签： ROS

于 2021-11-04 10:31:58 首次发布

本文链接：https://blog.csdn.net/qq_43419705/article/details/121137180

版权

ROS 专栏收录该内容

8 篇文章 3 订阅

订阅专栏

本篇博客目的是在代码中实现配置ROS_MASTER_URI和ROS_IP。

项目背景

本博客的灵感来源于一个现实的开发场景：开发者A与开发者B需要同时对同一个嵌入设设备各自进行ROS1框架的驱动开发。我们暂且搁置吐槽“为何要同时对同一设备进行开发”，来换个探讨的方式，尝试寻求解决问题的方法。

通过分析需求，可以得知：

开发者A与开发者B各自开发，那么一共需要同时运行两个节点（下称A节点与B节点）。
开发者A在开发的过程当中，只需要获悉A节点的数据内容，不需要B节点内容；开发者B同理。

节点图1

假设方案

众所周知的是，ROS1中存在Master节点，同一个“域”中，有且只能存在一个Master节点。通俗来讲就是，要实现节点间的通讯，就必须先启动主节点，而主节点只能存在一个。那Master应该放在哪里就成为了这个问题的关键。

假设方案一在嵌入设设备上运行Master节点。

节点图2

通过图形，可以看出这个方案的优点显著：
1、操作简单
只需要在嵌入式设备上打开一个独立的终端运行Master节点；
然后在开发者A与开发者B的电脑上执行两条export语句即可。
2、一般的嵌入式设备IP不会频繁更改。

但是缺点也十分明显：
1、嵌入式设备性能开销大。
在开发的过程，频繁的开关程序加重了Master注册、注销节点信息的负担，降低了算力有限的嵌入式设备的系统稳定性；也因此降低多人合作开发的可能性。
2、强网络耦合性。
所有运行的节点都处于同一网络域中，加重了耦合性。且不满足需求分析第二项内容。

方案一小结

适用于小型项目开发、强算力嵌入式设备开发、强节点耦合性开发。
满足分析需求一，不满足分析需求二。

假设方案二在开发者PC上运行Master节点。

在这里插入图片描述

针对方案一的缺陷，提出这个方案。而该方案的特点刚好与方案一完全相反。优点如下：
1、系统开销小。
不需要担忧Master节点崩溃，或者是嵌入式设备因Master超负荷崩溃的问题；
2、弱化网络耦合性。
每个节点只与各自的PC进行注册并通讯。节点之间不存在网络关联性。

缺点亦同方案一相反：
1、操作复杂繁琐。
需要在嵌入式设备的每个Node运行的终端都配置两条export语句。
2、各个Master的IP必然是不同的。

方案二小结

配置繁琐，不适合快速的项目开发。其低网络耦合度适合多人同时开发。
既满足分析需求一，也满足分析需求二。

方案二对比方案一：
方案二比方案一有性能上的提升，更具备项目开发的潜力。但增加了十分繁琐的配置手续。
因此，只要在方案二的基础上进行优化，就可以满足项目的需求。

优化方案

那么方案二的痛点在哪里呢？
自然就是需要反复地配置ROS_MASTER_URI和ROS_IP这两个环境变量了。

我们思考一下，“export+变量”这样的语句属于什么类型的操作？无论是在终端中执行，还是写入bashrc之中，是不是都属于Linux配置系统环境变量的操作？
既然是属于Linux系统功能的范畴，那就肯定是能够通过编程的方法来实现的。因此，这里优化的方向就是通过编程来植入环境变量。

此时，你是否想到了使用system函数来实现执行export语句？
如果是的话，那么很抱歉地说，这是行不通的。

不过，Linux本身就提供了更有效的API函数——setenv。
函数的解释（来源）

属性	属性内容
头文件	stdlib.h
函数声明	int setenv(const char name,const char value,int overwrite)；
函数说明	setenv()用来改变或增加环境变量的内容。
	参数name为环境变量名称字符串。
	参数value则为变量内容。
	参数overwrite用来决定是否要改变已存在的环境变量。如果没有此环境变量则无论overwrite为何值均添加此环境变量。若环境变量存在，当overwrite不为0时，原内容会被改为参数value所指的变量内容；当overwrite为0时，则参数value会被忽略。
	返回值执行成功则返回0，有错误发生时返回-1。

代码实现

方向有了，方法有了，尝试实现一下代码（源码链接）。

#include <ros/ros.h> 
#include <stdlib.h>

int main(int argc, char** argv)
{
    setenv("ROS_MASTER_URI", "http://192.168.1.104:11311", 1);
    setenv("ROS_IP", "192.168.1.157", 1);
    sleep(2);
    printf("ROS_IP\t\t- %s\n", getenv("ROS_IP"));
    printf("ROS_MASTER_URI\t- %s\n", getenv("ROS_MASTER_URI"));
    printf("\n");

    // 注册ROS节点
    ros::init(argc, argv, "client_test");
    ros::NodeHandle nh;
    ROS_INFO("Hello world!");
    while(ros::ok());
}

验证效果

代码中初始化的测试节点名为“client_test”，假如代码能够生效，那么运行测试程序的终端满足两个条件即代表测试成功：
1、终端未初始化ROS环境
2、测试程序注册的节点名能被ROS其他节点所发现

测试结果如图所示：
效果图一分为二，左边是本地的PC，右边是远程的嵌入式设备。

左边三个终端从上到下分别为：
左边终端1：运行roscore（Master节点）
左边终端2：查询本地PC的IP地址
左边终端3：通过ROS1指令查询到的节点列表。

右边三个终端从上到下分别是：
右边终端1：运行的测试程序
右边终端2：查询嵌入式设备的IP地址
右边终端3：未执行export环境下查询的节点列表结果。

右边终端1满足条件1；与终端3的对比，说明通过代码确实能够配置ROS的环境变量且生效，使得注册的“client_test”节点能够被检索找到，满足条件2。说明程序的验证结果是成功的。

解释代码

ros::init函数执行的时候，会根据系统的ROS_MASTER_URI指向去寻找Master所在的IP。然后向Master报告自己（节点）的IP，即ROS_IP。

如果ROS_MASTER_URI所指向的IP内没有Master启动，那么就会出现“Failed to contact master”的报错。因此，需要在ros::init执行前，先执行setenv设置环境变量。

如上面的函数解释所说，setenv第一个参数是环境变量，第二个参数是变量值，关键点在于第三个变量，不为零使得变量生效。

如果环境变量存在，getenv能够返回环境变量的值。

在执行setenv后需要sleep(2)休眠，等待环境变量生效。否则可能查询为空，或者查询到设置的变量未生效。

小结

在ros::init节点初始化之前，使用setenv函数，使得节点的ROS_MASTER_URI与ROS_IP变量发生变化，且只对当前节点生效。从而达到代替终端设置环境变量的效果。

至此，分析需求已经满足，且减少了方案二中反复在终端窗口配置环境的过程。

知识补充

ROS_MASTER_URI和ROS_IP的作用是什么？

我们基本上知道，ROS设计的初衷在于跨平台、跨设备、且分布式，它允许应用程序以节点的方式在不同的设备上进行通讯。它是如何做到的呢？
ROS1给出了它独特的配置方法，那就是指定ROS_MASTER_URI和ROS_IP。

如果把这两条指令理解为指针的话，那么ROS_MASTER_URI就是在ROS环境下，指向master所在的IP位置；而ROS_IP则是指向自身所在的IP。

节点图4

PC1的ROS1节点能够与PC2的ROS1节点进行通讯

如图，有PC1，PC2，PC3三台已经搭建ROS1环境的计算机。Master构建在IP为192.168.0.2的PC2之中。
如果PC1的ROS1节点希望与PC2的ROS1节点进行通讯，就需要在节点启动前，在终端中运行
export ROS_MASTER_URI=http://192.168.0.2:11311
export ROS_IP=192.168.0.1
ROS_MASTER_URI使得指明Master为PC2的IP地址；
ROS_IP使得指明PC1的终端启动的节点使用PC1的IP地址。