[advanced ROS] Lecture 3 ROS file system and distributed communication

【ROS Advanced 】 The third is ROS File system and distributed communication

Preface

We have already known ,ROS The system is a typical Multi process distributed framework , A complete system can be divided into the following levels ：

1. host ;
2. working space workspace;
3. Function pack package;
4. node node;
5. topic of conversation topic;

• The hierarchical framework under the host can be shown in the following figure ：
  
  The main problems of this paper are as follows ：
• How to use the meta function pack （ Associated feature packs ）
• ROS Workspace coverage and hidden dangers
• ROS Distributed communication （ Communication between different hosts ）

One 、 Meta function pack

1. Concept

• Application scenarios ： In practice ROS Development process , Robots often need to design multiple functions , You need to call different function packages , But if you install them one by one, it will lead to inefficiency , A waste of time , At this point, you need to package the function package ;

• Concept ： Meta function pack （metapackage）,ROS A virtual package in , There is no substantive content , But it relies on other software packages , In this way, other packages can be combined

• example ：sudo apt install ros-noetic-desktop-full
  It's going on ROS When installing , We run the above instructions , Similar to a directory index , Tell the host a Feature Pack Collection , Download and install one by one ;

2. Realization

• New function pack
• modify package.xml：

 <exec_depend> Integrated function package </exec_depend>
 .....
 <export>
   <metapackage />
 </export>

• Modify Compilation Rules CMakeLists.txt：

cmake_minimum_required(VERSION 3.0.2)
project(demo)
find_package(catkin REQUIRED)
catkin_metapackage()

Reference address ：ROS Wiki Metapackage

Two 、 Workspace coverage

1. Problem analysis

• To achieve ：

1. Create two new workspaces , Create a feature pack with the same name in two spaces wssim
2. Add environment variables , modify ~/.bashrc:

source /home/ user / route / working space A/devel/setup.bash
source /home/ user / route / working space B/devel/setup.bash

3. Load environment variables ：source.bashrc
4. View environment variables ：echo $ROS_PACKAGE_PATH
5. Enter the workspace ：roscd wssim

• There's a problem ： That is, it will directly enter the workspace B, The actual space nesting is ：

working space B -> working space A -> System built-in space

• reason ： The relationship between configuration order and priority

In the actual parsing process ,ROS First of all, according to bashrc file , Set the workspace priority according to its configuration , Generate the corresponding function package ROS_PACKAGE_PATH ROS route , But I will follow a principle ：

ROS_PACKAGE_PATH The value in , and .bashrc The order of configuration is reversed -> The priority of first configuration is low

2. Conclusions and hidden dangers

• Concept ： There are function packages with the same name in different workspaces ;
• The essence ： When the function package has the same name , According to ROS_PACKAGE_PATH lookup , Priority will be given to those before configuration ;
• hidden danger ： Because of this situation, call wssim The workspace will be called first B Feature pack in , It may not meet our needs for actual operation , There will be call problems

BUG explain ：
When in .bashrc In file source After multiple workspaces , Possible situations , stay ROS PACKAGE PATH Contains only two workspaces , You can delete a custom workspace build And devel Catalog , again catkin_make, And then reload .bashrc file , Problem solving .

3、 ... and 、 Distributed communication

1. Demand scenarios

In actual development ,ROS The system is often used to complete the communication and cooperation among multiple computers , Will be distributed on different computers , In the process of running, it often communicates with other nodes , There are many network configuration requirements ：

• There must be a complete two-way connection between all machines on all ports
• Each computer must advertise itself by a name that all other computers can resolve

2. Realization

• Basic preparation ： Make different hosts in The same network , Setting up IP

virtual machine ： Change the network adapter to bridge mode

• Modify the configuration file ： Mainly refers to the modification of the computer /etc/hosts The file of , Add the other party's... To the file IP Address and computer name

Network instructions ：

1. IP Address check ：ifconfig
2. Computer name ：hostname
3. Test network communication ：ping

• To configure IP Address ：

host ： modify ~/.bashrc file

export ROS_MASTER_URI=http:// host IP:11311
export ROS_HOSTNAME= host IP

Slave ： modify ~/.bashrc file

export ROS_MASTER_URI=http:// host IP:11311
export ROS_HOSTNAME= Slave IP

• test ：

1. The host starts roscore
2. Host start subscription node , Start the publishing node from the server , Test communication
3. The host starts the publishing node , Start the subscription node from the machine , Reverse phase test

summary

• Statement ： The blog section of this section refers to CSDN User zhaoxuzuo ROS course , The next blog will focus on node names 、 Topic name 、 On the problem of duplicate names of parameter names , Introduce the abnormal conditions caused by repetition .