Adding compatibility for tx250

[mwamp]

Hi, I'd like to create the model for the tx250 (as in my fork ). However I am having considerable trouble with the generation of an IKFast solution (which I do need very much). Openrave generates a file for me but I does not appear to yield correct results, basically there are no allowed positions for my robot.

My URDF works well in moveit so I can only assume it is correct.

I have tried compiling openrave from source as well as using the version built in ros kinetic. One strange thing is that the file generated by ik fast is very long (~20K lines).

Would anybody happen to know what might be going wrong? Would anybody care to run openrave as it should be quick enough if it's already installed. I am linking a script to run it with my parameters, only the paths inside should be adjusted (github does not like .sh extension). setup_ikFast.txt

Best,

[gavanderhoorn]

I haven't tested anything, but I have the impression that you created the URDF using the SW2URDF plugin for SolidWorks.

That is possible, but you'll have to take extra care when defining the origins for the joints, or the plugin will do a number on the orientations of the axes which leads to very complex math for IKFast (and its generator) to solve.

An example of this can be seen in the xacro snippets for joint_5 (here):

<joint name="${prefix}joint_5"  type="revolute">
  <origin xyz="-0.063781 0 0.10248" rpy="0 -0.7854 0" />

this has both translations in two dimensions as well as a rotation.

I would suggest to simplify this by fixing the origins of your joints (and updating your meshes) and then trying again.

[gavanderhoorn]

As this is not an issue with the packages in this repository I'll go ahead and close this.

Feel free to keep commenting on it though.

[mwamp]

Thanks for the help. Your impression is correct. I didn't really think through the fact that those awkward origins would mess things up. I would still expect the correct answer from ikfast though just not as fast.

Anyway I'll give it a shot, thanks.

[gavanderhoorn]

The math (in the generator) is non-trivial -- take a look at Rosen's PhD thesis. Straightening out the transforms between joints helps in avoiding rounding errors and other causes of numerical instability.

[mwamp]

So I straightened up some of the joints in my URDF. This time I got a clean no go from IK fast. Some things are very strange. One of them is that my first version gave 3 triplets of "unaligned joints" whereas the new one appears to have 4.

About the joint referred to earlier, I made some changes but didn't go 'all the way'. Actually there is a pair of 45° joints (4 and 5) making up the wrist of this arm. So there is bound to be more involved joint transforms since they are not colinear.

I'll see if further transformation of the joints can help but I don't expect it will since it will somehow mess up the rotation axes of the joints. I'll also look for an equivalence transform between this configuration and a more standard rx160 like colinear wrist.

Then I'll ask Rosen Diankov if I may bother him.

[gavanderhoorn]

The TX 250 has a "complex wrist". In my experience IKFast sometimes has difficulties generating solutions for non-spherical wrist setups.

I can only suggest to follow this workflow instead of the one explained in the various MoveIt tutorials. It's worked for me in the past where others failed.

Ignore the "4 dof" aspect of the Q&A and if you already have OpenRAVE installed you obviously don't need to use the Docker image.