ROS workspace coverage

The so-called workspace coverage , Refers to... In different workspaces , There are function packages with duplicate names .

ROS In development , The user-defined workspace can be customized, and multiple user-defined workspaces can exist at the same time , There may be a situation : Although function packages in a specific workspace cannot have the same name , However, the function package of the customized workspace and the built-in function package can have the same name, or the function package with the same name can also appear in different customized workspaces , Then when calling the function package with this name , Which one will be called ？ such as ： Custom workspace A There are function packs turtlesim, Custom workspace B There are also feature packs turtlesim, Of course, the built-in space of the system also exists turtlesim, If the turtlesim package , Which workspace will be called ？

Realization

0. New workspace A And the workspace B, Create function packs in both workspaces : turtlesim.

1. stay ~/.bashrc Under the document Additional Of the current workspace bash The format is as follows :

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

2. New command line :source .bashrc Load environment variables

3. see ROS Environmental variables echo $ROS_PACKAGE_PATH

result : Custom workspace B: Custom space A: System built-in space

4. Call the command :roscd turtlesim Will enter the custom workspace B

reason

ROS Can parse .bashrc file , And generate ROS_PACKAGE_PATH ROS Package path , In this variable, according to .bashrc Set workspace priority in configuration , Certain principles should be followed when setting :ROS_PACKAGE_PATH The value in , and .bashrc The order of configuration is reversed ---> The priority of post configuration is higher , If you change the custom space A And custom space B Of source The order , So when calling , Will enter the workspace A.

Conclusion

When the function package has the same name , According to ROS_PACKAGE_PATH lookup , Priority will be given to those before configuration .

hidden danger

There are safety risks , For example, the current workspace B Higher priority , Means when the program calls turtlesim when , The workspace will not be called A It will not call the built-in turtlesim, If the workspace A There are other function packages that depend on their own turtlesim, And in accordance with ROS Principles involved in workspace coverage , Then the actual execution will call the workspace B Of turtlesim, This leads to execution exceptions , There are potential safety hazards .

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 .