Ask Your Question
1

ros2 launch packages path

asked 2018-10-05 11:13:23 -0500

severin gravatar image

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)

edit retag flag offensive close merge delete

Comments

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.

William gravatar imageWilliam ( 2018-10-08 11:34:50 -0500 )edit

@William in that particular case, the launch file was indeed in the current directory, but yes, in general you are right :-)

severin gravatar imageseverin ( 2018-10-09 09:17:38 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-10-05 19:20:52 -0500

jacobperron gravatar image

updated 2018-10-05 19:21:55 -0500

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.

edit flag offensive delete link more

Comments

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).

William gravatar imageWilliam ( 2018-10-08 11:33:20 -0500 )edit

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...)

severin gravatar imageseverin ( 2018-10-09 09:19:21 -0500 )edit

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.

severin gravatar imageseverin ( 2018-10-09 09:27:04 -0500 )edit

@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.

Zhoulai Fu gravatar imageZhoulai Fu ( 2018-12-22 06:16:40 -0500 )edit

@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.

Dirk Thomas gravatar imageDirk Thomas ( 2018-12-26 13:26:57 -0500 )edit

@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) ?

Zhoulai Fu gravatar imageZhoulai Fu ( 2019-03-25 03:18:14 -0500 )edit

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.

Dirk Thomas gravatar imageDirk Thomas ( 2019-03-25 11:11:29 -0500 )edit

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.

Zhoulai Fu gravatar imageZhoulai Fu ( 2019-03-29 04:25:49 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-10-05 11:13:23 -0500

Seen: 632 times

Last updated: Oct 05 '18