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 issue, 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?
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_kinematicthe 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_kinematicorIK-Fastwe 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 issue, 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?