0
$\begingroup$

Rosanswers logo

Thanks to the MoveIt tutorial on IkFast Kinematics Solver, I managed to generate a plugin for UR5 using the urdf files in the ur_description from the generic ros-industrial/universal_robot github. However, I am using the new ur robot driver. That requires the urdf from the specific gitbub of fmauch/universal_robot. When I used the urdf from there, the docker image generates alot of errors. I assume both ur5.urdf.xacro are describing the same manipulator and should produce the same Ik solver but it obviously does not!

Any idea which of them should be used.

Thank you very much for your help.


Originally posted by Victor Wu on ROS Answers with karma: 53 on 2020-08-11

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I assume both ur5.urdf.xacro are describing the same manipulator and should produce the same Ik solver but it obviously does not!

that would not be a(n) (entirely) correct assumption.

The files in ros-industrial/universal_robot model the kinematics of a single robot, which is almost guaranteed not to correspond to the kinematics of your specific robot.

The difference would be in the kinematic calibration data.

The files in fmauch/universal_robot have been extended to allow you to import the calibration from your robot, which will then update link length and joint offsets such that the resulting URDF corresponds 100% with the kinematic structure of your specific robot.

So while from a high-level those files model the same robot type, the URDFs which will be uploaded to robot_description are actually different.


Edit:

does this mean, if I want to use a self generated IkFast plugin for Moveit to use, I should go through the ur robot ros driver to the point where I get the calibration data from the robot first. Then use that data to generate a urdf with the calibration data to use the docker image to generate the IkFast plugin before using the moveit setup assistant to generate the moveit config suit for use?

If you want the IKFast plugin to be generated while taking the calibration data of your robot into account, then: yes.

At the same time, I would like to ask how is the joint_limited situation for ur5? You and others started to discuss this issue back from 2014. Have you come to a conclusion that we do not need to limit the joints to just +-pi except for the elble? And a further question, is the vel_joint_trajectory_controller of the new ur robot driver ready for use yet?

These seem unrelated to the question you ask in your OP.

It would be better to post new questions -- after verifying these have not been asked before.


Originally posted by gvdhoorn with karma: 86574 on 2020-08-11

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by gvdhoorn on 2020-08-11:
The need to use the fmauch fork will be removed, as the files in ros-industrial/universal_robot will be updated to include the necessary changes to support importing kinematic calibration data.

This is already started and part of ros-industrial/universal_robot#448.

The current progress can be seen in ros-industrial/universal_robot@melodic-devel-staging.

Work to make UniversalRobots/Universal_Robots_ROS_Driver compatible with this is in UniversalRobots/Universal_Robots_ROS_Driver#97.

Comment by Victor Wu on 2020-08-11:
@gvdhoorn does this mean, if I want to use a self generated IkFast plugin for Moveit to use, I should go through the ur robot ros driver to the point where I get the calibration data from the robot first. Then use that data to generate a urdf with the calibration data to use the docker image to generate the IkFast plugin before using the moveit setup assistant to generate the moveit config suit for use? At the same time, I would like to ask how is the joint_limited situation for ur5? You and others started to discuss this issue back from 2014. Have you come to a conclusion that we do not need to limit the joints to just +-pi except for the elble? And a further question, is the vel_joint_trajectory_controller of the new ur robot driver ready for use yet?

Comment by Victor Wu on 2020-08-12:
When I use the urdf from the fmauch fork and trying to generate the IkFast plugin, I got the following:

openravepy.databases.inversekinematics: testik, success rate: 0.000000, wrong solutions: 0.000000, no solutions: 1.000000, missing solution: 0.000000
Created /tmp/ikfast.rKmGra/.openrave/kinematics.4bd8292d934c988a06151a7ad63f3388/ikfast0x10000049.Transform6D.0_1_2_3_4_5.cpp

So, I will interpret it as complete failure, with success rate:0; no solutions: 1.0. What could have gone wrong?

Comment by gvdhoorn on 2020-08-12:
I have no idea.

Comment by Victor Wu on 2020-08-12:
Thank you very much for all your help so far. I will then try the melodic-devel-staging and report back.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.