fcl 0.5 release with octomap 1.8 support #137

v4hn · 2016-06-27T08:59:54Z

Hey everyone,

over at MoveIt! we just realized we need a version of fcl that supports octomap 1.8,
because ROS' kinetic distribution features the new octomap. See here
What's your plan for the next release? Is there anything we can do to facilitate a release?

davetcoleman · 2016-07-19T14:16:36Z

ping - we are moving towards releasing MoveIt! for the latest version of ROS and this is blocking. thanks!

mamoll · 2016-07-19T14:57:18Z

👍 I don't know who the release manager is for fcl. Based on number of commits in the recent past, I'd say @jslee02 might be the best person to do this.

jslee02 · 2016-07-19T20:23:20Z

We're referring to release the debian packages (maybe for xenial and later distros), right? We might need help from @j-rivero to update the debian packages then.

v4hn · 2016-07-19T20:36:09Z

I'm pretty sure releasing the new version into xenial is out of question.
octomap 1.8 is also not part of xenial, but only yakkety.
For ubuntu 16.04 we will probably have to provide the library via ROS just as octomap 1.8.

Thanks for looking into this!

davetcoleman · 2016-07-19T22:33:50Z

@v4hn so you're saying we'll have to wrap a custom ROS-centric fcl release? would @j-rivero be in charge of this?

j-rivero · 2016-07-19T23:14:37Z

We're referring to release the debian packages (maybe for xenial and later distros), right? We might need help from @j-rivero to update the debian packages then.

Answering the same than in pull #139: for the different Ubuntu distributions to come, I will take care of it from my maintenance in Debian (hopefully Yaketty will sync from it on time). For the already released Ubuntu distributions we will need to use a PPA or the OSRF build farm (I can help with this). The decision of updating ROS repositories with the new version is not mine (we probably need to check with Tully) but I think that unless we have a good reason we try not to introduce custom versions of system libraries inside ROS repositories.

davetcoleman · 2016-07-19T23:18:37Z

A custom PPA outside of ROS sounds like a bad idea - MoveIt! would get more complicated to install. I think we should stick with the ROS PPA that everyone is already using.

@tfoote do we have a good reason to introduce a custom version of a system library? I think we do if we want MoveIt! in Kinetic LTS

j-rivero · 2016-07-20T00:50:31Z

I think we do if we want MoveIt! in Kinetic LTS

Eh .. that sounds like what I meant by a good reason, yes. @tfoote I'm going to start working on the packages for debian, let me know if we finally need them for the ROS repo.

davetcoleman · 2016-07-20T18:47:22Z

Thanks @j-rivero !

jslee02 · 2016-07-24T20:41:09Z

As a note, FCL 0.5.0 is released.

davetcoleman · 2016-07-25T15:34:32Z

Thanks!

j-rivero · 2016-07-26T19:47:25Z

Experimental 0.5 packages (use with caution) have been generated:

If someone can confirm that they work, that would be nice before going further.

davetcoleman · 2016-07-26T19:59:15Z

@j-rivero not sure how to test those packages, how do we install them? we currently have a travis/Docker setup dedicated to testing the kinetic build with the latest fcl and octomap, perhaps we can add your packages there? note its currently not fully fixed :-)

j-rivero · 2016-07-27T21:31:07Z

For the records: here is the logic that we have used to chose how to build and introduce the FCL 0.5 version inside the ROS repositories limiting the side effects on other software.

jonbinney · 2016-07-28T22:30:03Z

@j-rivero I tried installing those fcl packages on Xenial alongside ROS kinetic, and got some errors:

jbinney@swift-> sudo dpkg -i /home/jbinney/Downloads/libfcl*
Selecting previously unselected package libfcl0.5.
(Reading database ... 366844 files and directories currently installed.)
Preparing to unpack .../libfcl0.5_0.5.0-1osrf1-xenial1_amd64.deb ...
Unpacking libfcl0.5 (0.5.0-1osrf1~xenial1) ...
Selecting previously unselected package libfcl0.5-dbg.
Preparing to unpack .../libfcl0.5-dbg_0.5.0-1osrf1-xenial1_amd64.deb ...
Unpacking libfcl0.5-dbg (0.5.0-1osrf1~xenial1) ...
Selecting previously unselected package libfcl-dev.
Preparing to unpack .../libfcl-dev_0.5.0-1osrf1-xenial1_amd64.deb ...
Unpacking libfcl-dev (0.5.0-1osrf1~xenial1) ...
Setting up libfcl0.5 (0.5.0-1osrf1~xenial1) ...
Setting up libfcl0.5-dbg (0.5.0-1osrf1~xenial1) ...
dpkg: dependency problems prevent configuration of libfcl-dev:
 libfcl-dev depends on liboctomap-dev; however:
  Package liboctomap-dev is not installed.

dpkg: error processing package libfcl-dev (--install):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Errors were encountered while processing:
 libfcl-dev

jbinney@swift-> sudo apt-get install liboctomap-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
 liboctomap-dev : Depends: liboctomap1.6v5 (= 1.6.8+dfsg-2.1) but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

jonbinney · 2016-07-28T22:37:18Z

Am I misunderstanding things, or do the FCL packages depend on liboctomap-dev? On xenial I see version 1.6.8 of that package:

jbinney@swift-> apt-cache policy liboctomap-dev
liboctomap-dev:
  Installed: 1.6.8+dfsg-2.1
  Candidate: 1.6.8+dfsg-2.1
  Version table:
 *** 1.6.8+dfsg-2.1 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
        100 /var/lib/dpkg/status

And this looks like the same headers (but different version) that is provided by ros-kinetic-octomap. So FCL 0.5 depends on the system version, which is version 1.6.8, but compiles against version 1.8?

jonbinney · 2016-07-28T22:54:21Z

And now I'm further confused. I forced the removal of the system packages using sudo dpkg -r --force-depends liboctomap-dev liboctomap1.6v5. That leaves me with the new fcl0.5 packages installed, and ros-kinetic-octomap. But it looks like these headers in libfcl-dev are hardcoded to expect version 1.6.8 of octmap. In /usr/include/fcl/config.h I see:

#define FCL_VERSION "0.5.0"                                                                                                                                                                                                           
#define FCL_MAJOR_VERSION 0                                                                                                                                                                                                           
#define FCL_MINOR_VERSION 5                                                                                                                                                                                                           
#define FCL_PATCH_VERSION 0                                                                                                                                                                                                           

#define FCL_HAVE_SSE 0                                                                                                                                                                                                                
#define FCL_HAVE_OCTOMAP 1                                                                                                                                                                                                            
#define FCL_HAVE_TINYXML 0                                                                                                                                                                                                            

#define FCL_BUILD_TYPE_DEBUG 0                                                                                                                                                                                                        
#define FCL_BUILD_TYPE_RELEASE 0                                                                                                                                                                                                      

#if FCL_HAVE_OCTOMAP                                                                                                                                                                                                                  
  #define OCTOMAP_MAJOR_VERSION 1                                                                                                                                                                                                     
  #define OCTOMAP_MINOR_VERSION 6                                                                                                                                                                                                     
  #define OCTOMAP_PATCH_VERSION 8                                                                                                                                                                                                     

  #define OCTOMAP_VERSION_AT_LEAST(x,y,z) \                                                                                                                                                                                           
    (OCTOMAP_MAJOR_VERSION > x || (OCTOMAP_MAJOR_VERSION >= x && \                                                                                                                                                                    
    (OCTOMAP_MINOR_VERSION > y || (OCTOMAP_MINOR_VERSION >= y && \                                                                                                                                                                    
    OCTOMAP_PATCH_VERSION >= z))))                                                                                                                                                                                                    

  #define OCTOMAP_VERSION_AT_MOST(x,y,z) \                                                                                                                                                                                            
    (OCTOMAP_MAJOR_VERSION < x || (OCTOMAP_MAJOR_VERSION <= x && \                                                                                                                                                                    
    (OCTOMAP_MINOR_VERSION < y || (OCTOMAP_MINOR_VERSION <= y && \                                                                                                                                                                    
    OCTOMAP_PATCH_VERSION <= z))))                                                                                                                                                                                                    
#endif // FCL_HAVE_OCTOMAP

davetcoleman · 2016-07-28T23:51:24Z

I'm getting the same thing as @jonbinney:

libfcl-dev : Depends: libfcl0.5 (= 0.5.0-1osrf1~xenial1) but it is not installable

j-rivero · 2016-07-29T00:18:29Z

That is right, I built fcl0.5 packages depending on liboctomap-dev from Ubuntu repositories, which in Xenial is 1.6.8. I assume that you want it to depend on ros-kinetic-octomap package, right? I'm back to generate them.

jonbinney · 2016-07-29T00:19:55Z

Thanks @j-rivero !

j-rivero · 2016-07-29T12:26:09Z

I've released a new set of libfcl-5.0 packages for Xenial using the ROS octomap package. I was able to install them in my kinetic setup, inspecting the files I can not detect any problem.

davetcoleman · 2016-07-29T17:22:10Z

Your new packages build with MoveIt! I've updated the test setup to automate using these debs

@j-rivero Am I correct in making this PR? Can you +1 it?

Is libfcl-0.5-dev suppose to be able to be installed alongside libfcl-dev? In my testing it requires me to uninstall libfcl-dev

Also rosdep is saying:

ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies:
moveit_core: Cannot locate rosdep definition for [libfcl-0.5-dev]

Will you be adding that rule?

j-rivero · 2016-07-29T18:09:24Z

ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies:
moveit_core: Cannot locate rosdep definition for [libfcl-0.5-dev]

Will you be adding that rule?

I'm not sure how do we want to refer to the 0.5 FCL package inside the whole ROS ecosystem, there are several options. Note that if we include a <run_dependency>libfcl-dev</run_dependency> it will make the MoveIt installation to conflict with an installation of the libfcl-dev package from Ubuntu.

We overwrite the current libfcl-dev rosdep rule to resolve to libfcl-0.5-dev so all the ROS packages uses the same version of FCL (0.5 in this case).
We create a different libfcl-0.5-dev rosdep key for the new package, that allows ROS packages to use 0.3 version of libfcl or the new 0.5 (remember that the libraries have different filenames which should avoid weird errors with the ABI).
We create different rosdep keys, one for build_time libfcl-0.5-dev and other for runtime libfcl0.5 which uses the corresponding packages (plus the use of build_export_depend). That could help avoiding conflicts with libfcl-dev.

Probably @tfoote has a better global vision to decide which way to choose.

@j-rivero Am I correct in making this PR? Can you +1 it?

Depending on how we clarify the previous point, we could make to implement the solution in a different manner.

Is libfcl-0.5-dev suppose to be able to be installed alongside libfcl-dev? In my testing it requires me to uninstall libfcl-dev

That was intentional yes since both provide the same headers (same filesystem path) and .so library link.

jonbinney · 2016-07-29T18:17:44Z

I can also confirm that the new debs install cleanly and that moveit builds against it. Thanks @j-rivero !

j-rivero · 2016-07-29T20:42:23Z

I can also confirm that the new debs install cleanly and that moveit builds against it. Thanks @j-rivero !

No problem, thanks for the testing! I'm finishing with the generation of all packages (combinations of Ubuntu distributions and different architectures) so what would be missing is to choose how to solve the rosdep resolution and uploading packages to ROS repositories. I will comment here as soon as all the packages are ready (hopefully during today).

tfoote · 2016-07-29T20:53:07Z

Since these packages are going to be mutually exclusive I would recommend that we update the rosdep rule for xenial and later to point to our custom generated ones instead of creating an additional new rule that would cause conflicts. And hope that the new version can get into yakkety.

@j-rivero could you also spin debian jessie versions? And we'll want i386, armhf and arm64 versions as well.

And people wanting this on other platforms (rpm based, osx etc) will need to package the new version as well.

j-rivero · 2016-07-29T22:03:02Z

@j-rivero could you also spin debian jessie versions? And we'll want i386, armhf and arm64 versions as well.

Thanks Tully. I think that I have ready packages for all the platforms (all platforms with ros-kinetic-octomap released):

Note that there are some platforms missing (Debian armhf) since I think that there is no octomap ROS package for them.

poine · 2016-07-30T11:57:05Z

Hello World
I have downloaded and installed j-rivero libfcl0.5 packages on a Mint18 (Xenial package base). I am still failing to build moveit! from git kinetic-devel branch due to std::shared_ptr vs boost::shared_ptr conflict:

/home/poine/catkin_ws/src/moveit_core/collision_detection/src/collision_octomap_filter.cpp: In function ‘int collision_detection::refineContactNormals(const ObjectConstPtr&, collision_detection::CollisionResult&, double, double, bool, double, double)’:
/home/poine/catkin_ws/src/moveit_core/collision_detection/src/collision_octomap_filter.cpp:118:71: error: conversion from ‘const boost::shared_ptr<const octomap::OcTree>’ to non-scalar type ‘std::shared_ptr<const octomap::OcTree>’ requested
         std::shared_ptr<const octomap::OcTree> octree = shape_octree->octree;

jonbinney · 2016-07-30T17:45:12Z

@poine I believe that compile error is due to a problem with the released version of geometric shapes. Can you add the newest kinetic-devel version of geometric_shapes to your workspace and try again? https://github.com/ros-planning/geometric_shapes

poine · 2016-07-30T18:43:37Z

@jonbinney Thanks a lot, it did the trick.

davetcoleman · 2016-07-31T18:42:50Z

I would recommend that we update the rosdep rule for xenial and later to point to our custom generated ones instead of creating an additional new rule that would cause conflicts. And hope that the new version can get into yakkety.

So libfcl-dev rosdep rule will point to libfcl-0.5-dev debian? @j-rivero can you make that change?

tfoote · 2016-07-31T20:33:58Z

@davetcoleman we can't do that until it's been validated and imported into packages.ros.org for all platforms.

davetcoleman · 2016-08-04T18:23:19Z

until it's been validated and imported into packages.ros.org for all platforms

How long do you think until we can get it into shadow-fixed? I'm working on the MoveIt! Kinetic source build instructions at the moment

davetcoleman · 2016-08-26T17:20:36Z

MoveIt for ROS-Kinetic is now using FCL 0.5 using the rosbuild farm debians. This issue can be closed @jslee02, thanks!

This was referenced Jul 14, 2016

kinetic-devel does not link due to boost::variant c++11/c++03 incompatibilities moveit/moveit_visual_tools#9

Closed

C++11 Support for all moveit_* repos moveit/moveit_core#310

Closed

davetcoleman mentioned this issue Jul 19, 2016

Kinetic release moveit/moveit_ros#695

Closed

9 tasks

davetcoleman mentioned this issue Jul 19, 2016

Dependencies on fcl->octomap moveit/moveit_core#299

Closed

jslee02 mentioned this issue Jul 19, 2016

Releasing 0.5.0 #139

Merged

This was referenced Jul 27, 2016

Use std::shared_ptr for compatibility with FCL 0.5. moveit/geometric_shapes#47

Merged

Switch to std::shared_ptr for FCL and octomap types. moveit/moveit_ros#726

Merged

Enable C++11 support. moveit/moveit_plugins#22

Merged

davetcoleman mentioned this issue Jul 29, 2016

FCL is being re-released into ROS as 0.5 moveit/moveit_core#321

Closed

dbolkensteyn mentioned this issue Jul 30, 2016

Build from source instructions do not work moveit/moveit#8

Closed

davetcoleman mentioned this issue Aug 4, 2016

Kinetic Release moveit/moveit#18

Closed

19 tasks

tfoote mentioned this issue Aug 5, 2016

switch to use custom packaged fcl-0.5-dev ros/rosdistro#12287

Merged

jslee02 mentioned this issue Aug 23, 2016

Should FCL depend on ros packages #169

Open

jslee02 closed this as completed Aug 26, 2016

davetcoleman mentioned this issue Nov 10, 2016

libfcl.so binary crashes when processor does not support avx flag #187

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fcl 0.5 release with octomap 1.8 support #137

fcl 0.5 release with octomap 1.8 support #137

v4hn commented Jun 27, 2016

davetcoleman commented Jul 19, 2016

mamoll commented Jul 19, 2016

jslee02 commented Jul 19, 2016

v4hn commented Jul 19, 2016

davetcoleman commented Jul 19, 2016

j-rivero commented Jul 19, 2016

davetcoleman commented Jul 19, 2016

j-rivero commented Jul 20, 2016

davetcoleman commented Jul 20, 2016

jslee02 commented Jul 24, 2016 •

edited

Loading

davetcoleman commented Jul 25, 2016

j-rivero commented Jul 26, 2016

davetcoleman commented Jul 26, 2016

j-rivero commented Jul 27, 2016

jonbinney commented Jul 28, 2016 •

edited

Loading

jonbinney commented Jul 28, 2016

jonbinney commented Jul 28, 2016

davetcoleman commented Jul 28, 2016

j-rivero commented Jul 29, 2016 •

edited

Loading

jonbinney commented Jul 29, 2016

j-rivero commented Jul 29, 2016

davetcoleman commented Jul 29, 2016 •

edited

Loading

j-rivero commented Jul 29, 2016

jonbinney commented Jul 29, 2016

j-rivero commented Jul 29, 2016

tfoote commented Jul 29, 2016

j-rivero commented Jul 29, 2016

poine commented Jul 30, 2016

jonbinney commented Jul 30, 2016

poine commented Jul 30, 2016

davetcoleman commented Jul 31, 2016

tfoote commented Jul 31, 2016

davetcoleman commented Aug 4, 2016

davetcoleman commented Aug 26, 2016

fcl 0.5 release with octomap 1.8 support #137

fcl 0.5 release with octomap 1.8 support #137

Comments

v4hn commented Jun 27, 2016

davetcoleman commented Jul 19, 2016

mamoll commented Jul 19, 2016

jslee02 commented Jul 19, 2016

v4hn commented Jul 19, 2016

davetcoleman commented Jul 19, 2016

j-rivero commented Jul 19, 2016

davetcoleman commented Jul 19, 2016

j-rivero commented Jul 20, 2016

davetcoleman commented Jul 20, 2016

jslee02 commented Jul 24, 2016 • edited Loading

davetcoleman commented Jul 25, 2016

j-rivero commented Jul 26, 2016

davetcoleman commented Jul 26, 2016

j-rivero commented Jul 27, 2016

jonbinney commented Jul 28, 2016 • edited Loading

jonbinney commented Jul 28, 2016

jonbinney commented Jul 28, 2016

davetcoleman commented Jul 28, 2016

j-rivero commented Jul 29, 2016 • edited Loading

jonbinney commented Jul 29, 2016

j-rivero commented Jul 29, 2016

davetcoleman commented Jul 29, 2016 • edited Loading

j-rivero commented Jul 29, 2016

jonbinney commented Jul 29, 2016

j-rivero commented Jul 29, 2016

tfoote commented Jul 29, 2016

j-rivero commented Jul 29, 2016

poine commented Jul 30, 2016

jonbinney commented Jul 30, 2016

poine commented Jul 30, 2016

davetcoleman commented Jul 31, 2016

tfoote commented Jul 31, 2016

davetcoleman commented Aug 4, 2016

davetcoleman commented Aug 26, 2016

jslee02 commented Jul 24, 2016 •

edited

Loading

jonbinney commented Jul 28, 2016 •

edited

Loading

j-rivero commented Jul 29, 2016 •

edited

Loading

davetcoleman commented Jul 29, 2016 •

edited

Loading