default DH vs calibrated DH

[tlpss]

Not an issue per se, but writing it down as we might want to think about it in the future.

We use the default DH params for the UR robots, but each robot has a calibrated set of parameters that are used by the controlbox. ROS drivers use this as well, for example.

From a few measuremens, the difference in poses when running FK on the same joint configs is about 1-2mm. Not too bad, but for very precise manipulation, not insignifcant either.

Easy fix could be to allow users to set the dh params from their robot by adding an additional function to the bindings API.

[Victorlouisdg]

It's worth noting that we already have a C++ ur_inverse_kinematics(EEF_pose, d1, d4, d5, d6, a2, a3) that works for any UR-shaped robot by taking the 6 relevant DH parameters as input. It wouldn't be much work to create a Python binding for this function, so that users can call it with calibrated DH parameters instead. The ur*e.inverse_kinematics() functions can then be seen as "convenience functions" where the generic DH parameters are already filled in.

A small benefit of using the functions with generic DH parameters hardcoded, is that by being compile-time constant, the compiler potentially makes these functions faster.