ros2 launch packages path

Question

I'm quite confused by how ROS2 manages packages and package locations.

In ROS1, I would compile my nodes with a CMAKE_INSTALL_PREFIX like $HOME/ros-dev and install them there, then source $HOME/ros-dev/setup.bash (or manually set ROS_PACKAGE_PATH=$HOME/ros-dev/share), and everyone was happy: ros run & roslaunch would find my packages, and I could compile other packages with cmake finding the dependencies on the installed one without trouble.

Now, ROS2/ament got rid of setup.bash. Fine, I can certainly live with that. But if I create a launch file with the new python framework (btw, this framework is awfully verbose -- I certainly liked the XML launch files better, even though it was XML), how is ros2 launch my_launch_file.py supposed to know where my packages are located?

By default, it looks for packages in /opt/ros/bouncy. I can set AMENT_PREFIX_PATH to my install prefix, but it doesn't seem to be able to find the packages/nodes (I've tried as well $PREFIX/lib and $PREFIX/share without much success).

And beyond that specific issue, what is the correct way of telling ROS2 where the packages are installed? Setting AMENT_PREFIX_PATH in my .bashrc with a list of possible install prefixes? (in that case, it would have been nice to reuse ROS_PACKAGE_PATH whose name is clearer)

---

Originally posted by severin on ROS Answers with karma: 240 on 2018-10-05

Post score: 2

---

Original comments

Comment by William on 2018-10-08:
Perhaps it is a typo, but ros2 launch my_launch_file.py would not work unless my_launch_file.py is in the current directory. Something like ros2 launch my_package my_launch_file.py would work by finding where my_package is installed and locating the launch file from there.

Comment by severin on 2018-10-09:
@William in that particular case, the launch file was indeed in the current directory, but yes, in general you are right :-)

Answer 1

Following the Colcon Tutorial, after building a custom package we can still find a setup.bash (and a local_setup.bash) in the install directory of the workspace. Sourcing one of these will populate AMENT_PREFIX_PATH and commands like ros2 launch should be able to locate your packages.

If my workspace is located at ~/ros2_ws, then I should be able to do source ~/ros2_ws/install/local_setup.bash after building.

---

Originally posted by jacobperron with karma: 1870 on 2018-10-05

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by William on 2018-10-08:
I'll add that it is a specific choice to not have something like the ROS_PACKAGE_PATH (which would find packages even if they have not been built yet by searching) and instead require all packages to be installed before our tools can find them (allowing us to avoid all expensive searching).

Comment by severin on 2018-10-09:
But then the question surely is: why does ROS_PACKAGE_PATH find non-build packages? I've only ever pointed my ROS_PACKAGE_PATH to my install directories (and I thought it was the way it was supposed to be done...)

Comment by severin on 2018-10-09:
Thanks @jacobperron. In ROS1, the traditional, non-ROS-specific, cd build && cmake .. && make && make install sequence works great and install a setup.sh in $CMAKE_INSTALL_PREFIX. I'd rather do the same with ROS2 instead of using 'magic' tools like colcon.

Comment by Zhoulai Fu on 2018-12-22:
@severin Totally Agreed! Inventing a new name "colcon", "ament", or what ever machin or truc, just makes ROS2 harder to use, wasting many people's time. I wish that ROS3 would come with a more standard build-system that would be welcoming to new contributors.

Comment by Dirk Thomas on 2018-12-26:
@Zhoulai Fu if you know an existing build system which satisfies all the requirements of ROS (processing federally dev. pkgs in a single invocation, support for CMake/Python pkgs etc., working across all target platforms, supporting cross compilation) please feel free to suggest it.

Comment by Zhoulai Fu on 2019-03-25:
@Dirk Thomas I do not know, but what were the challenges for using only a traditional CMake-based build system (that works well on the Clang project, for example) ?

Comment by Dirk Thomas on 2019-03-25:
ament_cmake is plain CMake plus helper functions you can either use or decide to implement yourself. There is nothing non-CMake in ament_cmake. You can absolutely write a package in vanilla CMake (if you prefer to do everything by hand). Also CMake does not address the question of Python packages where you want to use something native to Python development (which is setup.py / setuptools). And CMake doesn't scale well to building numerous CMake packages efficiently - therefore we use a build tool which invoked cmake for each package in the right order.

Comment by Zhoulai Fu on 2019-03-29:
Now I see that "ament_cmake" is a CMake wrapper that helps overcome CMake efficiency issues and issues related to python setuptools. Thank you very much for your detailed explanation, @Dirk Thomas.

Comment by felixf4xu on 2022-10-06:
No, it's not cmake wrappers/helper funstions. If it is, we should be able to run something line "cmake .." just like any other cmake projects to config and build, but we cann't! The ament_cmake things must be run by colcon and the additional source .. cmd, which are absolutely aliens to native cmake!!