ROS1中source xxx.bash失效

如题,你在bashrc中写了source xxx.bash,但是你打开新的终端后,提示报错,并且找不到这个package

即使你在bashrc中写了

不知道原因之前,总是觉得怪怪的,知道原因后,其实很简单。

这里其实就是ROS工作空间source的核心机制 ------每个工作空间的setup.bash不是简单"追加"路径,而是基于该工作空间编译时的依赖关系,重新构建ROS_PACKAGE_PATH。

一、核心机制

每个ROS工作空间编译(catkin_make/catkin build)时,会在devel/setup.bash中记录:

  1. 该工作空间编译时,生效的「父工作空间」(也就是当时ROS_PACKAGE_PATH里的路径);
  2. 当你source这个setup.bash时,ROS会:
    • 把当前工作空间的路径放到最前面(最高优先级);
    • 然后拼接上编译时记录的「父工作空间」路径;
    • 最后只保留系统ROS路径(/opt/ros/noetic/share);
    • 不会保留之前手动source过的、但和当前工作空间无关的路径。

简单说:source一个工作空间的setup.bash,相当于"重置"ROS_PACKAGE_PATH,只保留「当前工作空间 + 它编译时依赖的工作空间 + 系统ROS」。

二、我这边做了测试

1. 初始状态(.bashrc加载后的默认值)
bash 复制代码
echo $ROS_PACKAGE_PATH 
/home/wu/code/ros/neor_mini/mini_sim18_ws/src:/home/wu/grasp_ws/src:/home/wu/catkin_workspace/src:/home/wu/catkin_ws/src:/opt/ros/noetic/share
  • 原因:.bashrc里最后source的是mini_sim18_ws,且mini_sim18_ws编译时依赖了grasp_ws、catkin_workspace、catkin_ws,所以初始路径包含这些。
2. source catkin_ws后
bash 复制代码
echo $ROS_PACKAGE_PATH 
/home/wu/catkin_ws/src:/home/wu/Moveit_test03_ws/src:/opt/ros/noetic/share
  • 原因:catkin_ws编译时只依赖Moveit_test03_ws和系统ROS,所以source它时,ROS会"重置"路径,只保留catkin_ws(当前) + Moveit_test03_ws(父) + 系统ROS,删掉了mini_sim18_ws、grasp_ws等无关路径。
3. source catkin_workspace后
bash 复制代码
echo $ROS_PACKAGE_PATH 
/home/wu/catkin_workspace/src:/home/wu/catkin_ws/src:/opt/ros/noetic/share
  • 原因:catkin_workspace编译时依赖catkin_ws和系统ROS,所以source后路径变成:catkin_workspace(当前) + catkin_ws(父) + 系统ROS,删掉了Moveit_test03_ws。
4. source Moveit_test03_ws后
bash 复制代码
echo $ROS_PACKAGE_PATH 
/home/wu/Moveit_test03_ws/src:/opt/ros/noetic/share
  • 原因:Moveit_test03_ws编译时没有依赖任何自定义工作空间 ,只依赖系统ROS,所以source后路径只有它自己 + 系统ROS,其他自定义工作空间路径全被删掉。
5. source mini_sim18_ws后
bash 复制代码
echo $ROS_PACKAGE_PATH 
/home/wu/code/ros/neor_mini/mini_sim18_ws/src:/home/wu/grasp_ws/src:/home/wu/catkin_workspace/src:/home/wu/catkin_ws/src:/opt/ros/noetic/share
  • 原因:回到初始状态,因为mini_sim18_ws编译时依赖了grasp_ws、catkin_workspace、catkin_ws,所以source后这些路径又被加回来。

每个ROS工作空间的setup.bash就像一个"预设清单":

  • 编译时:你告诉它"我依赖A、B、C工作空间",它就把A、B、C记到清单里;
  • source时:它会清空当前所有路径,只按清单加载"自己 + 依赖的A/B/C + 系统ROS"。
  • 不同工作空间的"清单"不同,所以source后ROS_PACKAGE_PATH就不一样。

总结

  1. 核心原因 :source工作空间的setup.bash会"重置"ROS_PACKAGE_PATH,只保留「当前工作空间 + 它编译时依赖的工作空间 + 系统ROS」,而非简单追加;
  2. 关键现象 :不同工作空间编译时的依赖不同,导致source后路径组成不同;

最后

这就是我最开始存在的困惑:为啥我bashrc中source路径放置的顺序不同,最后有些能直接跑起来,有些就是需要重新source指定bash。

相关推荐
小羊没烦恼!3 天前
初探性能优化——2个月到4小时的性能提升
java·开发语言·windows·算法·c#
伞伞悦读3 天前
【第38期】Python 模块与包详解:import、from、模块搜索路径、包结构和 __init__
开发语言·python
C语言小火车3 天前
C/C++ 为什么需要编译器?
开发语言·c++
霍霍的袁3 天前
【C++】map 和 set 的使用 | 从用法到底层
开发语言·c++·学习·visual studio
孙启超3 天前
【AI开发之Rust】第 11 课:智能指针与内部可变性
开发语言·后端·rust
此生决int3 天前
深入理解C++系列(20)——C++11(下)
开发语言·c++
CoderYanger3 天前
A.每日一题:835. 图像重叠
java·开发语言·程序人生·leetcode·面试·职场和发展·学习方法
伞伞悦读3 天前
【第37期】Python JSON 与配置详解:序列化、反序列化、嵌套结构和配置文件
开发语言·python·json
CCCCCCCCharlie3 天前
Linux进程控制四大核心操作
linux·开发语言
Brilliantwxx3 天前
【STM32】 SPI Flash 驱动开发实战:阻塞模式驱动 W25Q64(含工程代码)
开发语言·stm32·单片机·嵌入式硬件