IKFast is not easily used as a library

[shaun-edwards]

The current package generated by moveit_ikfast is not easily used as a library. Some ikfast functionality, such as returning multiple IK results, may be useful. Because such functionality is outside the IK plugin definition, it is not generally available. The following is a list of issues that prevent a generated package from being included as a library:

• The generated package does not include any headers. Instead method prototypes are embedded in the source file (*_manipulator_ikfast_moveit_plugin.cpp).
• Namespace name(ikfast_kinematics_plugin) is not globally unique and does not follow the ROS convention of using the package name for namespacing
• Loading a package as both a library and a plugin results in a DEBUG message that indicates this shouldn't be done (more research required).
• CMakeList would need to be modified.

[shaun-edwards]

I'd like to address this, but I wanted to pose the issue for discussion first.

[davetcoleman]

These are all good changes to make - I agree this package needs a lot of cleanup!

[shaun-edwards]

I've done a little more research into this. One big problem I ran into is if a plugin and library are loaded in the same application, then not only do they have to be from different packages, but the namespaces must be different (normally this is ensured by using the package name as a namespace). In our particular application, where we load moveit and the ik as a library, we ran into this problem.

The "best" solution I have been able to come up with is to make ikfast a header only library and use macros to ensure the namespaces are unique. This approach results in 3 ikfast packages, one header only library, one plugin, and one library. I'll be able to show an example of this soon, but if anybody has any comments, please share.

[mikeferguson]

@shaun-edwards I'm sure there is a way around that -- we regularly create ROS-agnostic libraries and load them inside ROS-bound plugins (MoveIt itself does a lot of this). The class names certainly need to be different, but I highly doubt one needs to create different packages.

[shaun-edwards]

@mikeferguson, thanks for the help. If I understand correctly, you are proposing that we have 2 packages; one that creates a library and a second that wraps it in a plugin. This does make more sense.