ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

For example, I want to get this module (message_filters), how can I do that?

In general, if possible, you should always prefer to use apt or apt-get on Ubuntu (and Debian).

Installing packages using the binaries provided through the ROS buildfarm is the most efficient way, as it automatically takes care of things like resolving dependencies (ie: it installs everything needed to be able to use a package).

For your specific package, you would run something like this in a command shell:

# this should be run every now and then
sudo apt update

# this actually installs the package
sudo apt install ros-kinetic-message-filters

After following the on-screen prompts, apt should install the package and you can immediately start using it.

If a package is not available, the next option is to try and build the package "from sources". This essentially means that you'll try to compile it on your own machine in a Catkin workspace.

<personal_opinion_based_on_years_of_experience>

Do not do this, unless absolutely necessary.

</personal_opinion_based_on_years_of_experience>

There are only a few reasons to attempt a build from source:

  1. there are no binaries available for your platform (ie: CPU architecture, OS release or a combination of those). This includes the situation where a package has never been released using the ROS buildfarm
  2. you need a feature (or fix) that is not yet part of a binary release (ie: version 1.2 has the feature you need, but the developer has only released 1.1)
  3. you want to work on the package yourself

In those cases, building a package from sources would be OK, but simply cloning the source repository in your workspace and running catkin_make (or catkin build) is in most cases not enough. See #q252478 for an example workflow that should result in a successful build (should, as it depends on whether the author/maintainer of the package(s) provided correct metadata).

For example, I want to get this module (message_filters), how can I do that?

In general, if possible, you should always prefer to use apt or apt-get on Ubuntu (and Debian).

Installing packages using the binaries provided through the ROS buildfarm is the most efficient way, as it automatically takes care of things like resolving dependencies (ie: it installs everything needed to be able to use a package).

For your specific package, you would run something like this in a command shell:

# this should be run every now and then
sudo apt update

# this actually installs the package
sudo apt install ros-kinetic-message-filters

After following the on-screen prompts, apt should install the package and you can immediately start using it.

If a package is not available, the next option is to try and build the package "from sources". This essentially means that you'll try to compile it on your own machine in a Catkin workspace.

<personal_opinion_based_on_years_of_experience>

Do not do this, unless absolutely necessary.

</personal_opinion_based_on_years_of_experience>

There are only a few reasons to attempt a build from source:

  1. there are no binaries available for your platform (ie: CPU architecture, OS release or a combination of those). This includes the situation where a package has never been released using the ROS buildfarm
  2. you need a feature (or fix) that is not yet part of a binary release (ie: version 1.2 has the feature you need, but the developer has only released 1.1)
  3. you require the use of specific optimisations (ie: compiler flags) or versions of libraries to be used (fi: a specific versions of PCL or OpenCV that the ROS buildfarm does not support/use)
  4. you want to work on the package yourselfyourself (ie: develop it)

In those cases, building a package from sources would be OK, but simply cloning the source repository in your workspace and running catkin_make (or catkin build) is in most cases not enough. See the accepted answer to #q252478 for an example workflow that should result in a successful build (should, as it depends on whether the author/maintainer of the package(s) provided correct metadata).


Edit: my rationale for discouraging users to build packages from source are:

  1. it's wasteful (of both time and effort): the ROS buildfarm already compiles and packages everything. Why wait 45 minutes for your workspace to compile if you just want to use a package and apt installs it in 5 minutes?
  2. managing build dependencies is non-trivial: even with tools like rosdep and rosinstall_generator, setting up a sane build environment is non-trivial. This seems to be confirmed by the many, many questions on ROS Answers citing CMake / Catkin errors where packages cannot be found. Why make dependency resolution your problem when apt installs all required run and build dependencies for you?
  3. if care is not taken, it will result in reduced performance: CMake by default will use the None build type. This will invoke the compiler without any specific optimisations enabled. Especially for packages that implement computationally intensive processes (such as pointcloud or lidar processing, heavy matrix & vector math, etc) this can result in poor performance. Users would have to manually select the Release or RelWithDebInfo build types to get proper performance out of packages they built themselves. While doable, this is easily forgotten, leading to the many questions on ROS Answers about code "running slow when compiled with ROS" or the navstack not maintaining its update rate. The ROS buildfarm provides binaries with the default optimisation type enabled that your platform uses, and removes the need for users to take care of this themselves.

For example, I want to get this module (message_filters), how can I do that?

In general, if possible, you should always prefer to use apt or apt-get on Ubuntu (and Debian).

Installing packages using the binaries provided through the ROS buildfarm is the most efficient way, as it automatically takes care of things like resolving dependencies (ie: it installs everything needed to be able to use a package).

For your specific package, you would run something like this in a command shell:

# this should be run every now and then
sudo apt update

# this actually installs the package
sudo apt install ros-kinetic-message-filters

After following the on-screen prompts, apt should install the package and you can immediately start using it.

If a package is not available, the next option is to try and build the package "from sources". This essentially means that you'll try to compile it on your own machine in a Catkin workspace.

<personal_opinion_based_on_years_of_experience>

Do not do this, unless absolutely necessary.

</personal_opinion_based_on_years_of_experience>

There are only a few reasons to attempt a build from source:

  1. there are no binaries available for your platform (ie: CPU architecture, OS release or a combination of those). This includes the situation where a package has never been released using the ROS buildfarm
  2. you need a feature (or fix) that is not yet part of a binary release (ie: version 1.2 has the feature you need, but the developer has only released 1.1)
  3. you require the use of specific optimisations (ie: compiler flags) or versions of libraries to be used (fi: a specific versions of PCL or OpenCV that the ROS buildfarm does not support/use)
  4. you require the use of specific optimisations (ie: compiler flags)
  5. you want to work on the package yourself (ie: develop it)

In those cases, building a package from sources would be OK, but simply cloning the source repository in your workspace and running catkin_make (or catkin build) is in most cases not enough. See the accepted answer to #q252478 for an example workflow that should result in a successful build (should, as it depends on whether the author/maintainer of the package(s) provided correct metadata).


Edit: my rationale for discouraging users to build packages from source are:

  1. it's wasteful (of both time and effort): the ROS buildfarm already compiles and packages everything. Why wait 45 minutes for your workspace to compile if you just want to use a package and apt installs it in 5 minutes?
  2. managing build dependencies is non-trivial: even with tools like rosdep and rosinstall_generator, setting up a sane build environment is non-trivial. This seems to be confirmed by the many, many questions on ROS Answers citing CMake / Catkin errors where packages cannot be found. Why make dependency resolution your problem when apt installs all required run and build dependencies for you?
  3. if care is not taken, it will result in reduced performance: CMake by default will use the None build type. This will invoke the compiler without any specific optimisations enabled. Especially for packages that implement computationally intensive processes (such as pointcloud or lidar processing, heavy matrix & vector math, etc) this can result in poor performance. Users would have to manually select the Release or RelWithDebInfo build types to get proper performance out of packages they built themselves. While doable, this is easily forgotten, leading to the many questions on ROS Answers about code "running slow when compiled with ROS" or the navstack not maintaining its update rate. The ROS buildfarm provides binaries with the default optimisation type enabled that your platform uses, and removes the need for users to take care of this themselves.

For example, I want to get this module (message_filters), how can I do that?

Released packages

In general, if possible, you should always prefer to use apt or apt-get on Ubuntu (and Debian).

Installing packages using the binaries provided through the ROS buildfarm is the most efficient way, as it automatically takes care of things like resolving dependencies (ie: it installs everything needed to be able to use a package).

For your specific package, you would run something like this in a command shell:

# this should be run every now and then
sudo apt update

# this actually installs the package
sudo apt install ros-kinetic-message-filters

After following the on-screen prompts, apt should install the package and you can immediately start using it.

There are a number of ways to see whether a package has been released:

  1. use the ROS wiki: a released package for which a wiki page exists has a number of buttons at the top of the page. For message_filters we see:

    ROS distro buttons at the top of the message_filters wiki page

    Notice the indigo, kinetic, lunar and melodic buttons. Clicking on those will switch the wiki page to the version specific to that particular ROS release. Upon clicking on those buttons, a number of badges will appear/disappear just below the Package Summary heading:

    package badges on the wiki for message_filters in melodic

    Notice the Released, Continuous Integration and Documented badges here again for message_filters.

    The important one here is Released. This badge being shown tells us that message_filters has been released into ROS Melodic and should be available for installation using apt.

  2. use the status pages: these pages can be found here: repositories.ros.org/status_page and are periodically updated by the ROS buildfarm. Even if a package does not have a wiki page (they have to be created by a human), a released package will show up on these pages.

    For ROS Kinetic, we would open the ros_kinetic_default.html page (refer to #q301220 for why there are multiple Kinetic pages) and search for message_filters by typing it in the textfield at the top-left of the page.

    If a package has been released through the ROS buildfarm, the page should show you one or more rows after having filtered everything based on your query. Released packages will show up. If the page is empty, a package is not released. Refer to the legend (coloured squares, top of the page) for an explanation of the meaning of the coloured squares in the rightmost columns.

No release available

If a package is not available, the next option is to try and build the package "from sources". This essentially means that you'll try to compile it on your own machine in a Catkin workspace.

<personal_opinion_based_on_years_of_experience>

Do not do this, unless absolutely necessary.

</personal_opinion_based_on_years_of_experience>

There are only a few reasons to attempt a build from source:

  1. there are no binaries available for your platform (ie: CPU architecture, OS release or a combination of those). This includes the situation where a package has never been released using the ROS buildfarm
  2. you need a feature (or fix) that is not yet part of a binary release (ie: version 1.2 has the feature you need, but the developer has only released 1.1)
  3. you require specific versions of libraries to be used (fi: a specific versions of PCL or OpenCV that the ROS buildfarm does not support/use)
  4. you require the use of specific optimisations (ie: compiler flags)
  5. you want to work on the package yourself (ie: develop it)

In those cases, building a package from sources would be OK, but simply cloning the source repository in your workspace and running catkin_make (or catkin build) is in most cases not enough. See the accepted answer to #q252478 for an example workflow that should result in a successful build (should, as it depends on whether the author/maintainer of the package(s) provided correct metadata).


Avoiding from-source builds

Edit: my rationale for discouraging users to build packages from source are:

  1. it's wasteful (of both time and effort): the ROS buildfarm already compiles and packages everything. Why wait 45 minutes for your workspace to compile if you just want to use a package and apt installs it in 5 minutes?
  2. managing build dependencies is non-trivial: even with tools like rosdep and rosinstall_generator, setting up a sane build environment is non-trivial. This seems to be confirmed by the many, many questions on ROS Answers citing CMake / Catkin errors where packages cannot be found. Why make dependency resolution your problem when apt installs all required run and build dependencies for you?
  3. if care is not taken, it will result in reduced performance: CMake by default will use the None build type. This will invoke the compiler without any specific optimisations enabled. Especially for packages that implement computationally intensive processes (such as pointcloud or lidar processing, heavy matrix & vector math, etc) this can result in poor performance. Users would have to manually select the Release or RelWithDebInfo build types to get proper performance out of packages they built themselves. While doable, this is easily forgotten, leading to the many questions on ROS Answers about code "running slow when compiled with ROS" or the navstack not maintaining its update rate. The ROS buildfarm provides binaries with the default optimisation type enabled that your platform uses, and removes the need for users to take care of this themselves.

For example, I want to get this module (message_filters), how can I do that?

Released packages

In general, if possible, you should always prefer to use apt or apt-get on Ubuntu (and Debian).

Installing packages using the binaries provided through the ROS buildfarm is the most efficient way, as it automatically takes care of things like resolving dependencies (ie: it installs everything needed to be able to use a package).

For your specific package, you would run something like this in a command shell:

# this should be run every now and then
sudo apt update

# this actually installs the package
sudo apt install ros-kinetic-message-filters

After following the on-screen prompts, apt should install the package and you can immediately start using it.

There are a number of ways to see whether a package has been released:

  1. use the ROS wiki: a released package for which a wiki page exists has a number of buttons at the top of the page. For message_filters we see:

    ROS distro buttons at the top of the message_filters wiki page

    Notice the indigo, kinetic, lunar and melodic buttons. Clicking on those will switch the wiki page to the version specific to that particular ROS release. Upon clicking on those buttons, a number of badges will appear/disappear just below the Package Summary heading:

    package badges on the wiki for message_filters in melodic

    Notice the Released, Continuous Integration and Documented badges here again for message_filters.

    The important one here is Released. This badge being shown tells us that message_filters has been released into ROS Melodic and should be available for installation using apt.

  2. use the status pages: these pages can be found here: repositories.ros.org/status_page and are periodically updated by the ROS buildfarm. Even if a package does not have a wiki page (they have to be created by a human), a released package will show up on these pages.

    For ROS Kinetic, we would open the ros_kinetic_default.html page (refer to #q301220 for why there are multiple Kinetic pages) and search for message_filters by typing it in the textfield at the top-left of the page.

    If a package has been released through the ROS buildfarm, the page should show you one or more rows after having filtered everything based on your query. Released packages will show up. If the page is empty, a package is not released. Refer to the legend (coloured squares, top of the page) for an explanation of the meaning of the coloured squares in the rightmost columns.

No release available

If a package is not available, the next option is to try and build the package "from sources". This essentially means that you'll try to compile it on your own machine in a Catkin workspace.

<personal_opinion_based_on_years_of_experience>

Do not do this, unless absolutely absolutely necessary.

</personal_opinion_based_on_years_of_experience>

There are only a few reasons to attempt a build from source:

  1. there are no binaries available for your platform (ie: CPU architecture, OS release version or a combination of those). This includes the situation where a package has never been released using through the ROS buildfarm
  2. you need a feature (or fix) that is not yet part of a binary release (ie: version 1.2 has the feature you need, but the developer has only released 1.1)
  3. you require specific versions of libraries to be used (fi: a specific versions of PCL or OpenCV that the ROS buildfarm does not support/use)
  4. you require the use of specific optimisations (ie: compiler flags)
  5. the package has become unmaintained and is no longer being released (even though their are old releases available)
  6. you want to work on the package yourself (ie: develop it)

In those cases, building a package from sources would be OK, but simply cloning the source repository in your workspace and running catkin_make (or catkin build) is in most cases not enough. See the accepted answer to #q252478 for an example workflow that should result in a successful build (should, as it depends on whether the author/maintainer of the package(s) provided correct metadata).

Avoiding from-source builds

Edit: my rationale for discouraging users to build packages from source are:

  1. it's wasteful (of both time and effort): the ROS buildfarm already compiles and packages everything. Why wait 45 minutes for your workspace to compile if you just want to use a package and apt installs it in 5 minutes?
  2. managing build dependencies is non-trivial: even with tools like rosdep and rosinstall_generator, setting up a sane build environment is non-trivial. This seems to be confirmed by the many, many questions on ROS Answers citing CMake / Catkin errors where packages cannot be found. Why make dependency resolution your problem when apt installs all required run and build dependencies for you?
  3. if care is not taken, it will result in reduced performance: CMake by default will use the None build type. This will invoke the compiler without any specific optimisations enabled. Especially for packages that implement computationally intensive processes (such as pointcloud or lidar processing, heavy matrix & vector math, etc) this can result in poor performance. Users would have to manually select the Release or RelWithDebInfo build types to get proper performance out of packages they built themselves. While doable, this is easily forgotten, leading to the many questions on ROS Answers about code "running slow when compiled with ROS" or the navstack not maintaining its update rate. The ROS buildfarm provides binaries with the default optimisation type enabled that your platform uses, and removes the need for users to take care of this themselves.

For example, I want to get this module (message_filters), how can I do that?

Released packages

In general, if possible, you should always prefer to use apt or apt-get on Ubuntu (and Debian).

Installing packages using the binaries provided through the ROS buildfarm is the most efficient way, as it automatically takes care of things like resolving dependencies (ie: it installs everything needed to be able to use a package).

For your specific package, you would run something like this in a command shell:

# this should be run every now and then
sudo apt update

# this actually installs the package
sudo apt install ros-kinetic-message-filters

After following the on-screen prompts, apt should install the package and you can immediately start using it.

There are a number of ways to see whether a package has been released:

  1. use the ROS wiki: a released package for which a wiki page exists has a number of buttons at the top of the page. For message_filters we see:

    ROS distro buttons at the top of the message_filters wiki page

    Notice the indigo, kinetic, lunar and melodic buttons. Clicking on those will switch the wiki page to the version specific to that particular ROS release. Upon clicking on those buttons, a number of badges will appear/disappear just below the Package Summary heading:

    package badges on the wiki for message_filters in melodic

    Notice the Released, Continuous Integration and Documented badges here again for message_filters.

    The important one here is Released. This badge being shown tells us that message_filters has been released into ROS Melodic and should be available for installation using apt.

  2. use the status pages: these pages can be found here: repositories.ros.org/status_page and are periodically updated by the ROS buildfarm. Even if a package does not have a wiki page (they have to be created by a human), a released package will show up on these pages.

    For ROS Kinetic, we would open the ros_kinetic_default.html page (refer to #q301220 for why there are multiple Kinetic pages) and search for message_filters by typing it in the textfield at the top-left of the page.

    If a package has been released through the ROS buildfarm, the page should show you one or more rows after having filtered everything based on your query. Released packages will show up. If the page is empty, a package is not released. Refer to the legend (coloured squares, top of the page) for an explanation of the meaning of the coloured squares in the rightmost columns.

No release available

If a package is not available, the next option is to try and build the package "from sources". This essentially means that you'll try to compile it on your own machine in a Catkin workspace.

<personal_opinion_based_on_years_of_experience>

Do not do this, unless absolutely necessary.

</personal_opinion_based_on_years_of_experience>

There are only a few reasons to attempt a build from source:

  1. there are no binaries available for your platform (ie: CPU architecture, OS version or a combination of those). This includes the situation where a package has never been released through the ROS buildfarm
  2. you need a feature (or fix) that is not yet part of a binary release (ie: version 1.2 has the feature you need, but the developer has only released 1.1)
  3. you require specific versions of libraries to be used (fi: a specific versions of PCL or OpenCV that the ROS buildfarm does not support/use)
  4. you require the use of specific optimisations (ie: compiler flags)
  5. the package has become unmaintained and is no longer being released (even though their there are old releases available)
  6. you want to work on the package yourself (ie: develop it)

In those cases, building a package from sources would be OK, but simply cloning the source repository in your workspace and running catkin_make (or catkin build) is in most cases not enough. See the accepted answer to #q252478 for an example workflow that should result in a successful build (should, as it depends on whether the author/maintainer of the package(s) provided correct metadata).

Avoiding from-source builds

Edit: my rationale for discouraging users to build packages from source are:

  1. it's wasteful (of both time and effort): the ROS buildfarm already compiles and packages everything. Why wait 45 minutes for your workspace to compile if you just want to use a package and apt installs it in 5 minutes?
  2. managing build dependencies is non-trivial: even with tools like rosdep and rosinstall_generator, setting up a sane build environment is non-trivial. This seems to be confirmed by the many, many questions on ROS Answers citing CMake / Catkin errors where packages cannot be found. Why make dependency resolution your problem when apt installs all required run and build dependencies for you?
  3. if care is not taken, it will result in reduced performance: CMake by default will use the None build type. This will invoke the compiler without any specific optimisations enabled. Especially for packages that implement computationally intensive processes (such as pointcloud or lidar processing, heavy matrix & vector math, etc) this can result in poor performance. Users would have to manually select the Release or RelWithDebInfo build types to get proper performance out of packages they built themselves. While doable, this is easily forgotten, leading to the many questions on ROS Answers about code "running slow when compiled with ROS" or the navstack not maintaining its update rate. The ROS buildfarm provides binaries with the default optimisation type enabled that your platform uses, and removes the need for users to take care of this themselves.

For example, I want to get this module (message_filters), how can I do that?

Released packages

In general, if possible, you should always prefer to use apt or apt-get on Ubuntu (and Debian).

Installing packages using the binaries provided through the ROS buildfarm is the most efficient way, as it automatically takes care of things like resolving dependencies (ie: it installs everything needed to be able to use a package).

For your specific package, you would run something like this in a command shell:

# this should be run every now and then
sudo apt update

# this actually installs the package
sudo apt install ros-kinetic-message-filters

After following the on-screen prompts, apt should install the package and you can immediately start using it.

There are a number of ways to see whether a package has been released:

  1. use the ROS wiki: a released package for which a wiki page exists has a number of buttons at the top of the page. For message_filters we see:

    ROS distro buttons at the top of the message_filters wiki page

    Notice the indigo, kinetic, lunar and melodic buttons. Clicking on those will switch the wiki page to the version specific to that particular ROS release. Upon clicking on those buttons, a number of badges will appear/disappear just below the Package Summary heading:

    package badges on the wiki for message_filters in melodic

    Notice the Released, Continuous Integration and Documented badges here again for message_filters.

    The important one here is Released. This badge being shown tells us that message_filters has been released into ROS Melodic and should be available for installation using apt.

  2. use the ROS Index. Similar to the ROS wiki, this will list packages which have been registered with the ros/rosdistro repository. Search the available packages using the search box in the top right of the page.

  3. use the status pages: these pages can be found here: repositories.ros.org/status_page and are periodically updated by the ROS buildfarm. Even if a package does not have a wiki page (they have to be created by a human), a released package will show up on these pages.

    For ROS Kinetic, we would open the ros_kinetic_default.html page (refer to #q301220 for why there are multiple Kinetic pages) and search for message_filters by typing it in the textfield at the top-left of the page.

    If a package has been released through the ROS buildfarm, the page should show you one or more rows after having filtered everything based on your query. Released packages will show up. If the page is empty, a package is not released. Refer to the legend (coloured squares, top of the page) for an explanation of the meaning of the coloured squares in the rightmost columns.

No release available

If a package is not available, the next option is to try and build the package "from sources". This essentially means that you'll try to compile it on your own machine in a Catkin workspace.

<personal_opinion_based_on_years_of_experience>

Do not do this, unless absolutely necessary.

</personal_opinion_based_on_years_of_experience>

There are only a few reasons to attempt a build from source:

  1. there are no binaries available for your platform (ie: CPU architecture, OS version or a combination of those). This includes the situation where a package has never been released through the ROS buildfarm
  2. you need a feature (or fix) that is not yet part of a binary release (ie: version 1.2 has the feature you need, but the developer has only released 1.1)
  3. you require specific versions of libraries to be used (fi: a specific versions of PCL or OpenCV that the ROS buildfarm does not support/use)
  4. you require the use of specific optimisations (ie: compiler flags)
  5. the package has become unmaintained and is no longer being released (even though there are old releases available)
  6. you want to work on the package yourself (ie: develop it)

In those cases, building a package from sources would be OK, but simply cloning the source repository in your workspace and running catkin_make (or catkin build) is in most cases not enough. See the accepted answer to #q252478 for an example workflow that should result in a successful build (should, as it depends on whether the author/maintainer of the package(s) provided correct metadata).

Avoiding from-source builds

Edit: my rationale for discouraging users to build packages from source are:

  1. it's wasteful (of both time and effort): the ROS buildfarm already compiles and packages everything. Why wait 45 minutes for your workspace to compile if you just want to use a package and apt installs it in 5 minutes?
  2. managing build dependencies is non-trivial: even with tools like rosdep and rosinstall_generator, setting up a sane build environment is non-trivial. This seems to be confirmed by the many, many questions on ROS Answers citing CMake / Catkin errors where packages cannot be found. Why make dependency resolution your problem when apt installs all required run and build dependencies for you?
  3. if care is not taken, it will result in reduced performance: CMake by default will use the None build type. This will invoke the compiler without any specific optimisations enabled. Especially for packages that implement computationally intensive processes (such as pointcloud or lidar processing, heavy matrix & vector math, etc) this can result in poor performance. Users would have to manually select the Release or RelWithDebInfo build types to get proper performance out of packages they built themselves. While doable, this is easily forgotten, leading to the many questions on ROS Answers about code "running slow when compiled with ROS" or the navstack not maintaining its update rate. The ROS buildfarm provides binaries with the default optimisation type enabled that your platform uses, and removes the need for users to take care of this themselves.