Closed form IK with Calibration

[captain-yoshi]

Summary

There are currently no closed-form kinematic solvers that takes into account the calibration file. Thus this makes these solvers unusable in real life application for precision tasks. Without the calibration, I have seen differences up to 5mm on the UR3 and others up to 15 mm.

Closed Form IK Solvers

Using ur_kinematic the average time is about 4.33714 us. But I think there are problems with this IK solver and there is PR316 and PR358 that has yet to be merged... @kphawkins, @hartmanndennis, @mxgrey Would it be easy to add DH parameters from the Calibration file with the ur_kinematic plugin ?

I have tried to generate an IK solver with IKFast with my calibration but it failed. I suspect that it is related to this: a 6 DOF robot needs the first 3 joints or the last 3 joints axes intersecting at a common point (Diankov, Rosen: 4.1.5 Solving 6D Transformation IK). I didin't find any benchmark for the UR but the average time for a robot used in Djankov thesis is 6 us.

Numerical IK Solvers

Our current options is to use a numerical kinematic solver. Track-IK has an average solving time of 450 us for the UR3. I don't think there is a faster one? Maybe Bio-IK?

Solutions

If we were able to use a closed form IK either ur_kinematic or IK-Fast we would gain at least a hundred fold speed for each query. @rhaschke and @v4hn When using MTC with a complex task, is the IK solver called a lot? For example 10 000 IK queries would take approximately 4.5 seconds with Track-IK and 60 ms with IK-Fast. As I'm writing this, the difference in time doesn't seem like a bottle neck unless 10 000 queries is a small number for generating a long task...

I would have time to tackle this by the end of the month. For me starting with the IK-Fast alternative would be easier. I would have to modify the joints so that 3 of them intersect while retaining the calibration. Would you suggest to start with ur_kinematic? Speed wise I think both are almost equal.

@gavanderhoorn We discussed this a little bit in this PR, were you able to generate an IK-Fast plugin including the calibration? What is the current best way to use the IK-Fast generator? Is following the moveit tutorials still a good way? I think you added a docker somewhere in the world wide web, can you send me a link if it's still up to date?

[rhaschke]

Closed-form solvers always rely on the fact that some axis intersect in a single point or are exactly parallel. If that's not the case anymore, you cannot find a closed-form solution anymore. IKFast is actually a closed-form solver - the closed form is just found automatically. Hence, I'm afraid that you are stuck to numerical solvers if you want to consider calibration.
Regarding MTC: Whether you employ IK solvers or not depends on your task: All Cartesian motion tasks as well as - of course - ComputeIK involve the IK solver. However, I agree with you, that the IK solver isn't the bottleneck for planning.

[fmauch]

Just a quick question: Why did this end up here? I think, this should go to https://github.com/ros-industrial/universal_robot, right?

[captain-yoshi]

@fmauch There was another PR226 that was opened here that is related to this issue.

Your probably right, should go to universal_robot. Should I open another issue there and close here?

[fmauch]

I think, that would be beneficial.

[captain-yoshi]

I am closing this issue and have created another one here ros-industrial/universal_robot#564.

@rhaschke I apologize but can you repost your answer in the thread above? Thx.