Revision history [back]

I try to install package from source into ROS, what's the proper way of doing it?

See #q252478 for an example workflow that I consider to be "the proper way". The steps you list in your question are almost correct, but if you don't take care of installing all dependencies, CMake will start complaining when it evaluates the CMakeLists.txt of whatever package(s) you're trying to build and they need a dependency that isn't present.

That works fine, my example node works and I can adjust the source to my liking, but the package is installed to my catkin workspace and not the global ROS path. How do I add the package into the ROS environment so that something like rospack list can identify it?

The way ROS Catkin workspaces work is that they overlay each other (more docs). Like an onion, each workspace layers on top of the previous one. The ROS installation in /opt/ros is essentially an install space, and your own personal workspace (ie: the first one you typically create) will overlay that one, and have its own source, build and devel space. In some cases, you'll want your workspace to have an install space as well, but that is not required for regular development work.

The process of overlaying makes all the packages in the underlying workspace available to the one that builds on top of it.

So in a situation with two workspaces -- say $HOME/ws_a and $HOME/ws_b -- in which the second overlays (or extends) the first, every pkg in ws_a can be rosrunned, roslaunched and found by rospack found. Provided you set things up correctly.

So back to your question: there is no "global ROS path". It is always built up from the paths to any workspaces that are currently active, and if you have multiple overlaying workspaces it will include the union of the pkgs of all those workspaces.

Lastly, how come after catkin_make I can't find my package using rosrun my_package serial_example_node?

If you've created your workspace correctly, have executed source /path/to/your/catkin_ws/devel/setup.bash after running catkin_make and the package is created properly, rosrun should be able to find it. If it doesn't, check that it was actually built. If it was, you may try and run rospack profile, which forces the rebuilding of a cache that some ROS command line tools will use to find your package.

A good way to test things are working is by running rospack find $pkg (where you replace $pkg with the name of your package). If that returns a sane path, things should be ok.

First of all, I don't quite get how a package like this one works when installed (or any ROS package). I checked its CMakeLists.txt file, it only installs headers and an example binary file. Going into cd /opt/ros/kinetic/share/serial there is only package.xml file and a cmake folder with serialConfig.cmake and serialConfig-version.cmake files.

Every Catkin workspace is structured according to the FHS layout (REP-122). As you can see, different directories are intended to host different files for different purposes. The files that you found (in /opt/ros/kinetic/share) are only part of the set of files that make up a package. Libraries and binaries (the node executables) in particular end up in lib/ for instance.

I compiled a basic ROS node using this library and it works fine, so how does ROS know where to find the src files if it only has headers and cmake configs installed?

All tools that interact with Catkin workspaces make use of several base libraries (rospkg, catkin_pkg and rosdep being three of those). Those libraries present a unified view of package resources and consumers of that information know how to use that to perform their tasks. So rosrun uses the libraries to find the binaries it needs to run, and roslaunch uses the libraries to find launch files.

All of this is not very different from how it works for 'regular' Linux programs: libraries and binaries also don't need to be stored in the same directories as the text, configuration and resource files that they need and use. By exploiting convention (and through the use of shared libraries with suitable functionality) everything still works.

I try to install package from source into ROS, what's the proper way of doing it?

See #q252478 for an example workflow that I consider to be "the proper way". The steps you list in your question are almost correct, but if you don't take care of installing all dependencies, CMake will start complaining when it evaluates the CMakeLists.txt of whatever package(s) you're trying to build and they need a dependency that isn't present.

That works fine, my example node works and I can adjust the source to my liking, but the package is installed to my catkin workspace and not the global ROS path. How do I add the package into the ROS environment so that something like rospack list can identify it?

The way ROS Catkin workspaces work is that they overlay each other (more docs). Like an onion, each workspace layers on top of the previous one. The ROS installation in /opt/ros is essentially an install space, and your own personal workspace (ie: the first one you typically create) will overlay that one, and have its own source, build and devel space. In some cases, you'll want your workspace to have an install space as well, but that is not required for regular development work.

The process of overlaying makes all the packages in the underlying workspace available to the one that builds on top of it.

So in a situation with two workspaces -- say $HOME/ws_a and $HOME/ws_b -- in which the second overlays (or extends) the first, every pkg in ws_a can be rosrunned, roslaunched and found by rospack found. Provided you set things up correctly.find after you've activated (ie: sourced) ws_b.

So back to your question: there is no "global ROS path". It is always built up from the paths to any workspaces that are currently active, and if you have multiple overlaying workspaces it will include the union of the pkgs of all those workspaces.

Lastly, how come after catkin_make I can't find my package using rosrun my_package serial_example_node?

If you've created your workspace correctly, have executed source /path/to/your/catkin_ws/devel/setup.bash after running catkin_make and the package is created properly, rosrun should be able to find it. If it doesn't, check that it was actually built. If it was, you may try and run rospack profile, which forces the rebuilding of a cache that some ROS command line tools will use to find your package.

A good way to test things are working is by running rospack find $pkg (where you replace $pkg with the name of your package). If that returns a sane path, things should be ok.

First of all, I don't quite get how a package like this one works when installed (or any ROS package). I checked its CMakeLists.txt file, it only installs headers and an example binary file. Going into cd /opt/ros/kinetic/share/serial there is only package.xml file and a cmake folder with serialConfig.cmake and serialConfig-version.cmake files.

Every Catkin workspace is structured according to the FHS layout (REP-122). As you can see, different directories are intended to host different files for different purposes. The files that you found (in /opt/ros/kinetic/share) are only part of the set of files that make up a package. Libraries and binaries (the node executables) in particular end up in lib/ for instance.

I compiled a basic ROS node using this library and it works fine, so how does ROS know where to find the src files if it only has headers and cmake configs installed?

All tools that interact with Catkin workspaces make use of several base libraries (rospkg, catkin_pkg and rosdep being three of those). Those libraries present a unified view of package resources and consumers of that information know how to use that to perform their tasks. So rosrun uses the libraries to find the binaries it needs to run, and roslaunch uses the libraries to find launch files.

All of this is not very different from how it works for 'regular' Linux programs: libraries and binaries also don't need to be stored in the same directories as the text, configuration and resource files that they need and use. By exploiting convention (and through the use of shared libraries with suitable functionality) everything still works.

I try to install package from source into ROS, what's the proper way of doing it?

See #q252478 for an example workflow that I consider to be "the proper way". The steps you list in your question are almost correct, but if you don't take care of installing all dependencies, CMake will start complaining when it evaluates the CMakeLists.txt of whatever package(s) you're trying to build and they need a dependency that isn't present.

That works fine, my example node works and I can adjust the source to my liking, but the package is installed to my catkin workspace and not the global ROS path. How do I add the package into the ROS environment so that something like rospack list can identify it?

The way ROS Catkin workspaces work is that they overlay each other (more docs). Like an onion, each workspace layers on top of the previous one. The ROS installation in /opt/ros is essentially an install space, and your own personal workspace (ie: the first one you typically create) will overlay that one, and have its own source, build and devel space. In some cases, you'll want your workspace to have an install space as well, but that is not required for regular development work.

The process of overlaying makes all the packages in the underlying workspace available to the one that builds on top of it.

So in a situation with two workspaces -- say $HOME/ws_a and $HOME/ws_b -- in which the second overlays (or extends) the first, every pkg in ws_a can be rosrunned, roslaunched and found by rospack find after you've activated (ie: sourced) ws_b.

So back to your question: there is no special "global ROS path". It is always built up from the paths to any workspaces that are currently active, and if you have multiple overlaying workspaces it will include the union of the pkgs of all those workspaces.

Lastly, how come after catkin_make I can't find my package using rosrun my_package serial_example_node?

If you've created your workspace correctly, have executed source /path/to/your/catkin_ws/devel/setup.bash after running catkin_make and the package is created properly, rosrun should be able to find it. If it doesn't, check that it was actually built. If it was, you may try and run rospack profile, which forces the rebuilding of a cache that some ROS command line tools will use to find your package.

A good way to test things are working is by running rospack find $pkg (where you replace $pkg with the name of your package). If that returns a sane path, things should be ok.

First of all, I don't quite get how a package like this one works when installed (or any ROS package). I checked its CMakeLists.txt file, it only installs headers and an example binary file. Going into cd /opt/ros/kinetic/share/serial there is only package.xml file and a cmake folder with serialConfig.cmake and serialConfig-version.cmake files.

Every Catkin workspace is structured according to the FHS layout (REP-122). As you can see, different directories are intended to host different files for different purposes. The files that you found (in /opt/ros/kinetic/share) are only part of the set of files that make up a package. Libraries and binaries (the node executables) in particular end up in lib/ for instance.

I compiled a basic ROS node using this library and it works fine, so how does ROS know where to find the src files if it only has headers and cmake configs installed?

All tools that interact with Catkin workspaces make use of several base libraries (rospkg, catkin_pkg and rosdep being three of those). Those libraries present a unified view of package resources and consumers of that information know how to use that to perform their tasks. So rosrun uses the libraries to find the binaries it needs to run, and roslaunch uses the libraries to find launch files.

All of this is not very different from how it works for 'regular' Linux programs: libraries and binaries also don't need to be stored in the same directories as the text, configuration and resource files that they need and use. By exploiting convention (and through the use of shared libraries with suitable functionality) everything still works.