Update ur_kinematics

[Yuki-cpp]

Summary

ur_kinematics can only support one UR robot type without being recompiled and uses old style C++ code. Moreover the python bindings are not functional. It also doesn't support the e-series robots. In this PR, we aim at modernizing this package, fixing those 3 issues.

Details

Here is what was done:

• Updated the UR robot parameter handling system to support robot selection at run-time instead of compile time. Added parameters for the e-series robots
• Added pybind11 python bindings
• Added a solution exploration function to expand the 8 original solutions into the full set of solutions

Warning

Since robot parameters are handled at run-time instead of compile time, a small over-head occurs reducing the time performances by a few percents. However, with C++20 we could remove said over head with the addition of class types in non-type template parameters

Related issue : #442

[gavanderhoorn]

First: thank you for the PR and the work, this looks like a good improvement.

Three initial comments:

• as mentioned in ur_kinematics issues and future work? #442 (comment), some discussion beforehand would have been good here. As an example, we're targeting Kinetic as well as Melodic with this repository. For Kinetic, the highest C++ standard we can require is 11, not 14. It may work on Kinetic (with GCC fi), but that is not the point. Going to C++20 would not be possible, even for Melodic.
  This is not necessarily a problem, but it would have been nice to avoid even having to discuss this, which was the idea when I wrote ur_kinematics issues and future work? #442 (comment).
• this seems to overlap and/or replace Added function to enumerate all possible joint angles per IK solution #305 and [ur_moveit_plugin] Use full range in IK if joints support it without solution explosion #316 (and by extension IK: combine PRs #239, #305, and #316 #358 and Added #define-based namespaces to prevent linking errors. #355). Can you comment on this?
• we'd like to avoid the use of submodules here. I'm not sure how we'll get pybind11 in, but if possible, submodules would not be the way.

[gavanderhoorn]

Apparently there is a Catkin-wrapped version of pybind11: ipab-slmc/pybind11_catkin. It's also been released into both Kinetic and Melodic.

[gavanderhoorn]

Starting with Bionic we could depend on ros/rosdistro#22261.

[jbeck28]

I'm having issues using the kinematics plugin for a UR5e. Specifically, it seems the included kinematics.yaml is actually using KDL rather than the UR5e Kinematics plugin. When I modified this through setup assistant to use the UR5e kinematics plugin, I found that upon moving the interactive marker in RViz, the end effector becomes strangely oriented, and I can never find non-approximate IK solutions.

Is this something anyone else has encountered?