ur3 library is linked by default when using ur_kin.h and ur_kin.cpp from the ur_kinematics package

[BlueNoise]

Hi,

I've been trying to use the inverse() method from the ur_kinematics package and had some issues figuring out why the IK wasn't working properly for the UR5. I followed recommendations made by people to get it to work. Unfortunately, it still wasn't working after adding those lines at the top of my cpp node:

#define UR5_PARAMS
#include "ur_kinematics/ur_kin.h"

This doesn't solve the issue because it stills links against the UR3 library, instead of the UR5 library. This happened because of this in the CMakeLists.txt

target_link_libraries(ur5_ik_node
  ${catkin_LIBRARIES}
)

By replacing the code above by this:

target_link_libraries(ur5_ik_node
  ${catkin_LIBRARIES}
  ur5_kin
)

It now forces to link against libur5_kin.so instead of the default libur3_kin.so by "overwriting" the previous link.

A call to ldd on my node shows that it worked correctly.

libur5_kin.so =>~/camera_calibration_ws/devel/lib/libur5_kin.so (0x00007fecc8526000)

I am wondering how to avoid this kind of problem in the future, since I believe using the catkin_LIBRARIES variable is the standard way to proceed when linking against ROS libraries, and not specifying each one of them manually.

On a side note, I am aware that this issue is somehow related to #220 and #247.

[miguelprada]

I think the short answer is that directly linking against the liburX_kin is not a well supported use case. The structure of the ur_kinematics package is directed towards using these classes trough the MoveIt kinematics plugin interface, and is somewhat broken if you try to directly link against them.

I'm a bit surprised to see that explicitly adding the version you want to target_link_libraries, but that's good to know. I've gone through more elaborate hacks at some point before.

This is still far from a perfect solution since:

1. as you said, it breaks the assumption that things should just work by linking against all exported ${catkin_LIBRARIES}
2. does not support use cases where you need to compute FK/IK for more than one different UR model

I'm honestly not sure what the best solution is. I'd say it necessarily goes through exporting differently named classes/functions for each UR model, so you can link against all of them and still select the one you want in user code. There's probably some way to do this with minor modifications, and possibly without breaking users depending on hacks such as the one you used. Unless you want to work on a PR really fixing the issue, I'd say your solution is a good compromise.

[gavanderhoorn]

I've always thought the "best" way to deal with this would be to split out the kinematics plugins into packages.

They could still depend on a shared package which provides all the base functionality, but each package could be specific to each plugin.

Linking would be against those specific packages, not against the base package.

[gavanderhoorn]

On a side note, I am aware that this issue is somehow related to #220 and #247.

It sounds like your post is actually almost a duplicate.

[miguelprada]

I've always thought the "best" way to deal with this would be to split out the kinematics plugins into packages.

Not sure I get your point. AFAIK, the plugins are not the issue here, since you can still dynamically load the one you want.

The issue as I understand it is if you want to directly link your code against the different liburX_kin.so libraries, since all of them contain symbols with equal names. Splitting them into packages is certainly an option, although it should also be possible to fix this problem by exporting the kinematics functions for each model using different names.

[gavanderhoorn]

The issue as I understand it is if you want to directly link your code against the different liburX_kin.so libraries, since all of them contain symbols with equal names. Splitting them into packages is certainly an option, although it should also be possible to fix this problem by exporting the kinematics functions for each model using different names.

We could certainly rename the functions, but in the end the robot model is exactly the same, it's just the translations which differ. That makes it ideal for reuse, which I guess is what the rationale is behind the current setup (identical names of functions, change just the constants used).

My idea behind using separate packages is that it conveniently allows for keeping the same code and fixes the deployment problem for consumers: by stating the correct dependency in the manifest and build script, it's clear which IK plugin is being linked.

It would be similar to how IKFast plugins are used fi.

[BlueNoise]

This pull request(#355) from 2018 is closely related with our current topic. That might give us some ideas.

@gavanderhoorn I am not sure that creating separate packages solves all the issues. It might be a compromise, but one problem that comes to mind with this approach is the inability to select multiple UR models from another package because of linking against ${catkin_LIBRARIES}. The ideal solution to me would let the user call any of the functions inside ur_kinematics for any robot model inside one executable. e.g., being able to call IK on UR3, UR5 and UR10 in the same executable.

[miguelprada]

My idea behind using separate packages is that it conveniently allows for keeping the same code and fixes the deployment problem for consumers: by stating the correct dependency in the manifest and build script, it's clear which IK plugin is being linked.

I may be missing something here, but I don't quite see how splitting into packages helps reuse the same code. It does improve the deployment, but issues will still be there for use cases where more than one model of UR is used. I cannot think of other way to solve this other than renaming/namespacing the functions for each model, irrespective of whether they stay in the same package or not.

It would be similar to how IKFast plugins are used fi.

That's a good point.

This pull request(#355) from 2018 is closely related with our current topic. That might give us some ideas.

I think something along this line would be my preferred choice. It allows to maintain the same code for the kinematics while allowing the user to pick and choose which model they want to work with.