Use fclConfig.cmake once FCL 0.5 becomes minimum requirement

[jslee02]

The current FCL provides fclConfig.cmake by #116, and it will probably be included in version 0.5. We could use it instead of our FindFCL.cmake to find fcl in CMake. The only required change would be replacing find_package(FCL REQUIRED) to find_package(fcl REQUIRED).

[joao-borrego]

Will DART support FCL 0.5 in the near future?
I am currently working with MoveIt!, which uses FCL 0.5, thus preventing me from having it installed alongside DART.

(The ultimate objective is using ROS + Gazebo 9.0 + Dart 6 + MoveIt!)

[jslee02]

DART already supports FCL 0.5 since 6.0.1 and FCL 6.0 (current master branch) since 6.4.0. This issue is just about how to find the library. Also, Gazebo 9.0 supports DART 6.

What is exactly preventing you from using DART and MoveIt now?

[joao-borrego]

Thank you! I wrongly assumed DART required libfcl-dev debian package, which conflicts with libfcl-0.5-dev
I already managed to get the required setup by building FCL from source as well and tweaking the default installation directories. Thank you once more!

[mxgrey]

I've been having this issue as well, and it's rather irritating. The problem seems to be that libdart6-dev depends on libfcl-dev, which conflicts with libfcl-0.5-dev. This means if you want to have both DART6 and MoveIt! installed such that they can be used simultaneously for development, you probably have to build and install DART from source, and completely avoid installing it using apt. This seems like it's ultimately an issue with the upstream maintenance of libfcl and/or the package management. It looks like libfcl-0.5-dev is maintained at OSRF, so I'll ask around and see what we might be able to do about this. It might be the case that since libfcl is still in version 0, no one will be willing (yet) to commit to a maintenance approach that avoids this kind of issue. It can't hurt to make some noise about it, though.

…

--Grey

On Wed, Mar 7, 2018 at 8:41 AM, Borrego ***@***.***> wrote: Thank you! I wrongly assumed DART required libfcl-dev debian package, which conflicts with libfcl-0.5-dev I already managed to get the required setup by building FCL from source as well and tweaking the default installation directories. Thank you once more! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#736 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPyUWMHS4OXjYOQ8O_YRlawn8gwe7imks5tcA2vgaJpZM4I-Uzm> .

[mxgrey]

After poking around, one straightforward solution for us to consider would be to add DART to the ROS distribution ecosystem. That way, people who want to use DART in ROS can easily do so without any conflicts. The ROS-distributed package would be named according to the distribution that it belongs to, e.g. ros-kinetic-dart, so it wouldn't conflict with the libdart packages in our own PPA.

We already provide a catkin package.xml for DART, so it should be pretty straightforward to make this happen. The full instructions can be found here.

I'll begin work on making this happen, if no one has any objections. I'll start from version 6.3.0, since that appears to be our latest tagged release. I don't imagine there's much point in backporting to older versions of DART.

[jslee02]

That sounds exciting! I have some questions though.

The ROS-distributed package would be named according to the distribution that it belongs to, e.g. ros-kinetic-dart, so it wouldn't conflict with the libdart packages in our own PPA.

Just to clarify, ros-kinetic-dart (or ros-kinetic-dartsim as we're planning to change the package name to dartsim) and libdart* couldn't be installed alongside, right?

I'm not sure if it is a good practice to have two packages of ROS package and non-ROS package. I thought libfcl-0.5-dev is a stopgap solution for that libfcl-dev in Trusty is too old. Wouldn't this possibly cause other version conflicts? I mean in the future ROS + Gazebo 9.0 + DART 6 + MoveIt! wouldn't be possible anyway unless we have ros-kinetic-gazebo, which is the reverse direction of Gazebo had gone through. Am I missing something here?

[mxgrey]

They can be installed alongside each other because ros-kinetic-dartsim will be installed to /opt/ros/kinetic/ instead of /usr/. For an end user to even "see" ros-kinetic-dartsim during their build configuration, they would need to run the /opt/ros/kinetic/setup.bash file, and then build using catkin, which I think will set CMAKE_MODULE_PATH to the CMAKE_MODULE_PATH environment variable that gets set by /opt/ros/kinetic/setup.bash.

I thought libfcl-0.5-dev is a stopgap solution for that libfcl-dev in Trusty is too old

I don't know the original motivation behind libfcl-0.5-dev. It's not clear to me whether it was intended for general consumption or whether it was only intended for ROS-related packages. If it were only intended for ROS-related packages, we could have avoided this conflict by making a ros-kinetic-fcl package instead of libfcl-0.5-dev, because the ros-kinetic version would go into /opt/ros/kinetic.

Since that isn't the case, I can only assume that libfcl-0.5-dev was intended for broader use, and thus it gets installed to the system. This is unfortunate since it seems to belong to an Open Robotics PPA, which makes it difficult for other packages in other PPAs to depend on. At the same time, it conflicts with the debian libfcl-dev package, so... it's a bit of a mess :/

I mean in the future ROS + Gazebo 9.0 + DART 6 + MoveIt! wouldn't be possible anyway unless we have ros-kinetic-gazebo

A user can have gazebo-9 installed to their system, and this combination would work just fine. This combo also works fine if someone installs DART strictly by building it from source. The only issue is that the deb package for MoveIt! depends on libfcl-0.5-dev while the deb package for libdart6-dev depends on libfcl-dev, but there is an explicit conflict between libfcl-0.5-dev's deb and libfcl-dev's deb, so we cannot simultaneously install the MoveIt! deb and the libdart6-dev deb.

However, since DART has no issue with building against libfcl-0.5-dev, we can build DART from source without any trouble. It's just that the DART deb doesn't give us the flexibility to choose between libfcl-dev or libfcl-0.5-dev; we have to pick one or the other, as far as I can tell, but we can't pick libfcl-0.5-dev without requiring users to expose themselves to the ROS PPA (... not that the ROS PPA would be bad for users, but it's an extra step that shouldn't be necessary in a perfect world).

Also, gazebo-9 doesn't depend on FCL at all (at least from what I can tell), so gazebo-9 is completely independent of this whole issue.

Truthfully, the only thing we're really "accomplishing" by putting DART into the ROS ecosystem is:

1. We create an alternative deb package for DART which is able to depend on libfcl-0.5-dev instead of libfcl-dev.
2. ROS users have an easier time accessing DART because they can get it through the Open Robotics PPA instead of our dartsim PPA.

(or ros-kinetic-dartsim as we're planning to change the package name to dartsim)

I wasn't totally clear on whether that decision was final, so thanks for mentioning it. I'm on board with using dartsim, so I'll be sure to use that when referring to the package name from now on.

[jslee02]

Thanks for the clear explanation! Let me know if there is anything I can help for having DART in the ROS ecosystem.

I wasn't totally clear on whether that decision was final, so thanks for mentioning it.

Yeah, maybe I didn't mention that I'm also on board with that. 😛

[mxgrey]

I thought I'd mention here that I recently noticed dartsim is now available in ros-kinetic under the package ros-kinetic-dartsim. This should make it much much easier for ROS users to take advantage of DART inside ROS projects, alongside MoveIt!.

The one catch is that it's still not possible to install both debian packages libdart6-dev and ros-kinetic-dartsim from their apt repos simultaneously, because of the conflict between the libfcl-dev and libfcl-0.5-dev packages.

That being said, we could avoid this specific conflict if we were more strict about separating interface and implementation. We have a complete abstraction layer around fcl, so in principle we shouldn't need libfcl-dev. The problem right now is we're exposing some implementation headers for the FCL collision detector. I don't exactly know if it's worth the effort, but it's something to consider.