Ask Your Question
1

How do you upgrade pcl to the current release?

asked 2018-04-21 04:31:21 -0500

Hakaishin gravatar image

I saw this question: https://answers.ros.org/question/1162... But it is 7 years old and I assume some progress happened on this issue. I am asking because all the approaches suggested by tfoote sound like they take a good amount of work. And I don't want to waste my time, to find out afterwards, that the upgrading process has been made easier. So is there a canonical way to do this by now? Is one of the solutions of tfoote the best for kinetic and pcl 1.8?

I saw some project like this one: https://github.com/NicolaCovallero/ir... that simply add pcl 1.8 in the cmake file and not as a package dependency. Will this work in kinetic? And if yes, does it prevent me from using any packages that do depend on ros_pcl, ros_conversions etc, because I will get namespace collisions?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2018-04-21 06:25:27 -0500

gvdhoorn gravatar image

updated 2018-04-21 08:38:08 -0500

PCL is a 'system dependency' (ie: something used by ROS packages, but not a ROS package itself).

To use a newer version of a system dependency there is a relatively simple procedure:

  1. identify all packages that you use that depend on the system dependency (read: all ROS packages that you use that (indirectly) depend on the dependency)
  2. clone their source repositories into your workspace
  3. install the newer version of the system dependency (this will most likely install it in /usr/local if building from source, or if you're using your system's pkg manager, in the appropriate system location)
  4. in case you have parallel installations of the same dependency on your system: update the CMakeLists.txt of all affected packages to add version requirements to the find_package(..) lines
  5. build the workspace

At this point all the packages in your workspace should be using the new version of the dependency (provided you did step 4 correctly).

Step 1 is really important: it's allright to use pkg A with dependency X version Q, and pkg B with dependency X version W, as long as A does not link anything from B, nor B from A. Linking two different versions of dependency X into the same binary is generally not very stable, and can lead to SEGFAULTs (in the case of C/C++) and/or other strange, unexpected and hard to diagnose problems.

If the two packages do not directly share any binary artefacts, but are standalone and communicate only through messages, it can work.

Step 4 is equally important: pkgs typically look for PCL with something like find_package(PCL REQUIRED). If you have both 1.7 and 1.8 on your system, CMake may end up finding 1.7 before 1.8, resulting in 1.7 being used.


So summarising: follow the above procedure, and make sure to update any find_package(PCL ..) lines to read find_package(PCL 1.8 ..). If depending on any of the perception_ros packages, you would have to update the line in (at least) pcl_ros.

edit flag offensive delete link more

Comments

Two notes:

  1. this is not specific to PCL: the same works (more or less) for any system dependency. Some will require a bit more work to get CMake to find the new versions, but in general it'll be the same
  2. this is not ROS specific: Catkin ~= CMake, and this is a CMake workflow
gvdhoorn gravatar imagegvdhoorn ( 2018-04-21 06:27:00 -0500 )edit

Thank you very much, I will try to follow these instructions. In the same question that I linked, why did your procedure not apply there? Did tfoote not know about this answer, or where there other reasons, that at that time this did not work or did I misunderstand the linked question?

Hakaishin gravatar imageHakaishin ( 2018-04-21 07:23:57 -0500 )edit

At that point in time PCL was actually a ROS package, so upgrading it was a litle bit more involved. Note also the comment:

we're working on making it so that PCL and ROS integrate in a more standard way in future versions

I believe he is referring to making PCL a system dependency.

gvdhoorn gravatar imagegvdhoorn ( 2018-04-21 08:15:44 -0500 )edit

But of course there are more sides to this than just installing a newer version on your system: newer versions of libraries typicaly introduce new functionality, but could also introduce breaking changes and changes to existing APIs. If that happens, no workflow will save you, and you'll have to do some work to make the ROS packages that you want to link against the new version compatible again.

That is probably what @tfoote means with:

however that will not solve the fundamental problem.

gvdhoorn gravatar imagegvdhoorn ( 2018-04-21 08:16:47 -0500 )edit

I see, thank you very much. Your approach worked :)

Hakaishin gravatar imageHakaishin ( 2018-04-21 08:17:17 -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-04-21 04:31:21 -0500

Seen: 887 times

Last updated: Apr 21 '18