ROS Navigation多机器人导航的环境设置

---

前言

多机导航控制通过引入namespace来区别不同机器人所需要的导航目标，以及每个机器人自身所需要的消息和服务，比如amcl_pose、odom等等。多机环境下namespace另一个重要作用是对各个机器人自身TF链路中frame_id的前缀修饰，通过namespace前缀的引入避免TF链路的冲突

---

map的层级结构

多机navigation控制的环境需要一个主机作为命令的中枢，同时能够实时反馈各个机器人的状态，比如odometry、planned path等等。主机的形式可以是中央模式，也可以是分布模式。主机不同的运行模式也决定了导航地图（map）的层级结构

中央模式

所有navigation运算都在主机完成，各个机器人只负责运动命令的执行：

分布模式

各个机器人负责自身的navigation运算以及运动命令的执行，主机只负责发布地图map，以及对应机器人的导航目标点（推荐）：

分布模式还有另一种形式，各个机器人独立运行map_server，主机订阅其中一个机器人发布的map：

三种模式对比：

模式	特点	适用场景
中央模式	共享地图，中央电脑需要比较强的算力，机器人数量不能过多否则导致运算能力不足	中央电脑算力强大，机器人数量较少
分布模式	共享地图，中央电脑没有算力要求，只需要发布地图和导航目标，导航运算由各个机器人自身负责，机器人舰队数量理论上无限制	机器人舰队规模较大
分布模式变化	地图由各个机器人自己维护，由于中央电脑订阅其中任意一个机器人所发布的地图，所以需要保证各个机器人的地图相同	机器人舰队规模较大

namespace的绝对/相对路径规定

在开始引入namespace之前，需要理解namespace的绝对/相对路径的定义。和Linux文件系统类似，符号“/”表示为绝对路径，相对路径则不需要前置该该符号，参考官网连接

理解namespace绝对/相对路径规定后，需要确认自行开发的代码，以及相关launch文件中，关于消息参数params、消息topic、服务service的名称都为相对的表达，通过相对表达的方式才能在引入namespace后，形成基于namespace的绝对名称

苇航智能的硬件驱动接口，在未引入namespace之前，加载参数使用的是绝对路径形式，下图中左边为未引入namespace时绝对路径的参数，右边为引入namespace后相对路径的参数：

以上图为例：当引入namespace作为机器人个体的区分时，比如机器人命名为“Jack”，参数“pin_enable”将会自动加入Jack作为前缀形成绝对路径参数：
“/Jack/NaviBOT/hardware_interface/pin_enable”

苇航智能相关的launch文件，在未引入namespace之前，也有部分使用了绝对路径形式，下图为differential机器人硬件接口的launch文件，左图为未引入namespace前，remap命令cmd_vel都使用了绝对路径形式，右图为引入namespace后相对路径的形式：

以上图为例：未引入namespace前，单机运行，remap重映射命令cmd_vel到绝对名称“/cmd_vel”，且controller参数joint_state和base_controller都为绝对路径形式。引入namespace后，处于多机运行环境，为了区别面向各个机器人的命令和参数，则需要使用相对路径形式。如机器人命名为“Jack”，命令cmd_vel将被自动组合为：“/Jack/cmd_vel”

加入namespace

机器人本机

对机器人本机，namespace的加入只需要在整个navigation启动的launch文件加入

对比中央电脑架构形式，苇航智能选择分布模式的布局，该模式能够实现各个机器人共享同一个map，同时能实现更多的机器人的控制以获得更大的机器人舰队规模

下图为加入namespace之前和之后，文件“NaviBOT_navigation.launch”的内容对比，左图为未加入namespace前，右图为加入namespace后：

namespace覆盖了：LiDAR激光、运动硬件接口、amcl蒙特卡洛定位、move_base这四个navigation所需要的基础模块。其中“NaviBOT_ux”为苇航智能的导航交互拓展模块、“battery_monitor”为苇航智能电量监控模块，它们都不是navigation运行的必要模块。同时注意到，右图中依然存在map_server模块，但使用了< group unless >的标签，该标签以条件变量的形式实现了其内包含的逻辑是否需要引入。为了兼顾单机控制，苇航智能使用了变量“remote”控制map_server模块的引入，当其值为false时，则表示为单机运行模式，需要引入map_server；否则为多机运行模式，则不引入map_server而是订阅使用中央电脑所发布的地图

远程中央电脑

基于分布模式，远程中央电脑只需发布地图（map）信息，所以其launch文件需要引入map_server：

加入namespace后，机器人的TF链路和下图类似，每一个节点的“Broadcaster”都有namespace作为前缀：

frame_id

frame_id用于TF链路，要注意明确其定义，不要与主题（topic）混淆。namespace加入后会自动在相应的主题名称前加入namespace前缀，但对于frame_id则没有自动添加前缀的过程。对于有变量“tf_prefix”的模块或者程序，可以通过设置tf_prefix与namespace一致，模块会自动把前缀加入到frame_id之前，如果模块没有该变量，则需要为模块所提供的frame_id变量显示的加入目标namespace，比如amcl模块中的odom和base的frame_id：

需要加入namespace前缀的frame_id及其对应模块：

模块	frame_id名称	修改为
amcl	odom_frame_id	< ns >/odom
amcl	base_frame_id	< ns >/base_link
costmap_2d	obstacles/laser_scan_sensor/sensor_frame	< ns >/laser
costmap_2d	global_costmap/robot_base_frame	< ns >/base_link
costmap_2d	local_costmap/global_frame	< ns >/odom
costmap_2d	local_costmap/robot_base_frame	< ns >/base_link
robot_state_publisher	tf_prefix	< ns >
LiDAR(rplidar_ros)	frame_id	< ns >/laser

NOTE: 这里只罗列了导航基本框架中的模块，如果读者系统有其他模块存在frame_id，则可以参照做对应修改

为frame_id加入对应namespace后的TF链路为下图（两个机器人whi_01和whi_02），注意观察与上个章节加入namespace后TF链路对比：frame_id的每一个节点都有namespace的前缀，这样就能保证多机运行时TF链路无干涉：

RViz topic加入namespace

以namespace命名为“test_ns”为例，为了使中央电脑运行的RViz navigation环境中能够可视化导航信息，也需要对应修改的主题，为其加入namespace，限于篇幅，这里只举例RobotModel，其余读者可依次类推进行修改：

RobotModel使用了tf_prefix形式，因此Robot Description和TF Prefix都需要加入对应namespace

Tool Properties添加namespace

加入namespace后，RViz navigation导航界面中两个最常用的工具“2D Pose Estimate”和“2D Nav Goal”也需要对应的namespace，以形成基于namespace的初始位置设置和导航目标设置的命令主题

navigation运行后，选择菜单“Panels->Tool Properties”，在弹出的对话框中为工具“2D Pose Estimate”以及“2D Nav Goal”分别添加对应的namespace。依然以namespace命名为“test_ns”为例，分别在主题“/initialpose”和“/move_base_simple/goal”前加入namespace：

多机导航运行

基于前述采用了分布模式，中央电脑负责地图的发布，机器人各自负责导航运算，在这个结构下，则自然将中央电脑设置为master，机器人设置为client。关于ROS中多机运行机制，读者可参考官网连接

设置master

在终端输入命令：

nano ~/.bashrc

在打开的文件最后加入内容：
export ROS_MASTER_URI=http://< ip of master >:11311
export ROS_HOSTNAME=< ip of master >
保存退出，在终端继续输入命令：

source ~/.bashrc

设置client

在终端输入命令：

nano ~/.bashrc

在打开的文件最后加入内容：
export ROS_MASTER_URI=http://< ip of master >:11311
export ROS_HOSTNAME=< ip of robot >
保存退出，在终端继续输入命令：

source ~/.bashrc

时间同步

多机运行环境下，各个机器间的时间戳需要统一。否则可能出现执行导航命令失败的情况，以下图为例：左图为master的时间戳，右图为client的时间戳，master时间要快于client时间大概2分钟：

当在master中首先给定机器人执行多点路径导航操作后，机器人actionlib中记录的当前目标时间戳即为master当前的时间，随后如果再通过client自身发送导航目标操作，会出现不能执行导航的现象。这是因为2D Navi Goal使用的是move_base_simple/goal为主题的消息方式发送导航目标，该方式下move_base收到目标消息（类型geometry_msgs::PoseStamped）后，将该目标转换为move_base的目标消息move_base_msgs::MoveBaseActionGoal，同时为其赋值了client自身的时间，再转发消息给actionlib，因此，会出现新导航目标时间戳早于actionlib所记录的当前目标时间戳的情况，在该情况下，actionlib将认为这是一个无效目标，从而放弃目标的执行

为了解决这个问题，需要同步master和各个client之间的时间，苇航智能推荐使用NTP（Network Time Protocol），关于其使用配置不在本文讨论范围，读者可网络搜索

运行

在中央电脑打开一个终端，运行能够发布map的launch文件，读者可参考GitHub上苇航智能发布的 master package

对各个机器人的终端，都输入导航运行的launch，由于实现路径不尽相同，这里不做举例说明

当中央和各个机器人都运行后，即可通过Tool Properties，改变“2D Nav Goal”的前缀，分别实现对各个机器人的导航控制，也可以通过苇航智能的插件 Navi_namespace 通过GUI的方式实现对各个机器人的导航控制：

---

总结

使用namespace为topic、params、TF加入前缀以实现对应机器人的导航控制。如果文中出现了描述错误以及不清晰的地方，欢迎指正，共同交流：xinjue.zou.whi@gmail.com