# Different Axes of rotation arrangement for UR5

Since the new version of UR driver available for CB3 UR's, the urdf from the ur_description from fmauch fork can extract the factory calibration of the manipulator. Hence I want to use that version of the urdf to generate the IkFast plugin. However, no matter how I tried the result is still unsuccessful with no solutions: 1.0! While I used the melodic-devel branch of the ur_description the IkFast plugin finished with:

openravepy.databases.inversekinematics: testik,
success rate: 0.932000,
wrong solutions: 0.000000,
no solutions: 0.068000,
missing solution: 0.867000


Then I used view_ur5.launch to examine the differences between the two different urdf and it shows: the fmauch fork uses the z axis as the axis of rotation for all the joints, whereas the molodic-devel uses the y axis as the axis of rotation for the joints.

The above is the ur5 view for the fmauch fork.

The above is the ur5 view for the melodic-devel.

Is there anyway to put the calibration data into the melodic-devel urdf or how to change the fmauch urdf to use the y axis as the axis of rotation for the joints? Because I suspect the different axis of rotation for the joints is the reason causing one can generate the IkFast plugin and the other cannot.

Thank you very much for your help.

Victor Wu.

edit retag close merge delete

Sort by » oldest newest most voted

I went with using the z-axis as this is closer to DH notation which the whole calibration is heavily based on. I was not aware, that this would be a problem with IkFast, though.

Personally, I have never used IkFast directly, as I use trac_ik in most cases, so I cannot say for sure, which requirements it has in regards to the URDF.

Is there anyway to put the calibration data into the melodic-devel urdf or how to change the fmauch urdf to use the y axis as the axis of rotation for the joints?

I guess the second option would be easier to implement. For this, you'll "simply" have to rearrange everything correctly. However, I would suggest to do it on the melodic-devel-staging branch instead of on my fork, as there is only one xacro file left and my fork will die as soon as we have a working MoveIt! configuration inside melodic-devel-staging.

Because I suspect the different axis of rotation for the joints is the reason causing one can generate the IkFast plugin and the other cannot.

I would try to confirm that guess before diving into that work.

more

@fexner thank you very much for your reply. So, you are using trac_ik for UR. I may try that instead. The whole point is that I want to find an Ik Solver that can work with Descartes for trajectory planning. If track_ik works then I can change to that. However, will the whole thing work with all joint limits of +/- 2pi except the elbow limits to +/- 1pi? And I still have the question of how to insert the calibration into the melodic-devel-staging?

( 2020-08-14 03:43:30 -0600 )edit

I am not suggesting to use trac_ik instead of IkFast, I was just reasoning why I don't know too much about it. I think, the URDF should be usable with IkFast, that should be our goal.

( 2020-08-14 03:46:10 -0600 )edit

The elbow joint limits are only a problem for OMPL @Victor Wu. It doesn't affect (traditional) IK solvers. Or at least not the issue you are referring to.

Trac IK will not work too well with Descartes, for two reasons:

1. it doesn't return all solutions (which Descartes needs to be able to pick the 'best' one)
2. it's rather slow, at least when compared to IKFast (milliseconds vs microseconds)
( 2020-08-14 03:47:34 -0600 )edit

@fexner: I haven't checked, but how is the calibration data "added" to the base kinematics in the URDF?

Would the different orientation of the link frames affect the correctness?

( 2020-08-14 03:48:25 -0600 )edit

@gvdhoorn Thank you for your comment. I am really confused for how do the three things, Descartes, MoveIt and OMPL related? Does your comment imply that if I do not use OMPL, what else can I use, then the problem of limited joints will not affect me? And does this scheme work with Descartes? I know these are again different questions or should I split them into different questions to ask?

( 2020-08-14 03:57:02 -0600 )edit

Everything comes from this yaml file (or the calibrated version of a specific robot). The calibration will be already added to these parameters. There will just be less zeros in case of a calibrated model.

Those values have to be rearranged into the URDF if one wants to try to change the links' orientation. Meaning x would not go to x bot somewhere else, and so on. Which is why I chose to use the z-axis notation in the first place ;-)

@Victor Wu how exactly did you try to generate the IkFast solution? Is there a step-by-step guide I could try to follow in order to reproduce this?

( 2020-08-14 04:00:47 -0600 )edit

@fexner I simply follow the instructions from the moveit_tutorialsikfast_tutorial. There, I will generate a .urdf file from the composit .urdf.xacro files first. Then generate the .dae file. Lastly, the most important step is to use the rosrun moveit_kinematics auto_create_ikfast_moveit_plugin.sh --iktype Transform6D \$MYROBOT_NAME.urdf <planning_group_name> <base_link> <eef_link> command.

( 2020-08-14 04:06:16 -0600 )edit

Those values have to be rearranged into the URDF if one wants to try to change the links' orientation. Meaning x would not go to x bot somewhere else, and so on. Which is why I chose to use the z-axis notation in the first place ;-)

So melodic-devel-staging currently still uses the link orientations as they have always been.

This may mean we need to fix/change something.

( 2020-08-14 04:08:08 -0600 )edit