Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

irb2400 IKFast plugin doesn't match URDF #80

Open
JeremyZoss opened this issue May 21, 2015 · 8 comments
Open

irb2400 IKFast plugin doesn't match URDF #80

JeremyZoss opened this issue May 21, 2015 · 8 comments
Assignees
Labels

Comments

@JeremyZoss
Copy link
Member

URDF tool0 definition was updated in 24f5530, but ikFast analytic solver was not updated. IKFast solver now produces results inconsistent with URDF/KDL.

Test case
Compute IK for robot at nominal (all-zeros) position:

rosservice call /compute_ik "{ik_request: {group_name: 'manipulator', robot_state: {joint_state: {name: ['joint_1', 'joint_2', 'joint_3', 'joint_4', 'joint_5', 'joint_6'], position: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]}}, ik_link_name: 'tool0', pose_stamped: {pose: {position: {x: 0.94, y: 0.0, z: 1.455}, orientation: {x: 0.0, y: 0.707106781185, z: 0.0, w: 0.707106781188}}}}}"
  • KDL: [0, 0, 0, 0, 0, 0]
  • IKFast: [0, 0.15, -0.28, 0.0, 1.70, 0.0]

Other ABB models are not affected, because no IKFast plugin has been created.

@shaun-edwards
Copy link
Member

@Levi-Armstrong, this needs to be addressed ASAP, as it is in a released package.

@gavanderhoorn
Copy link
Member

Wasn't this fixed with the merge of #81?

@JeremyZoss
Copy link
Member Author

I see that fixes were applied to devel + release packages:

But when I try to run my test-code above (with the latest indigo packages), I get different answers from KDL and IKFast plugins. This is just a quick test, so I could be doing something wrong. Dragging the robot in RVIZ (e.g. Tool-Z) causes the robot to flip to a different elbow configuration near the all-zeros position, when using the IKFast plugin, but not when using the KDL plugin.

It seems to me that the above PRs fix this particular bug. There may be another bug where the IKFast plugin does not return the closest solution?? Or, perhaps there's a rounding error that causes IKFast to miss the solutions to the particular cartesian position in my test case.

I'm probably okay to close this bug. If someone identifies the KDL/IKFast configuration-discrepancy as a "real" issue later, then we can open a new bug for that topic.

@Levi-Armstrong : do you concur?

@Levi-Armstrong
Copy link
Member

I believe we have been using this on our 2400 in the lab but I will make sure it is this version and not a custom one before closing the Issue.

@gavanderhoorn
Copy link
Member

@Levi-Armstrong: have you had an opportunity to test this?

@Levi-Armstrong
Copy link
Member

Not yet, I should have an update tomorrow. @Jmeyer1292

@Levi-Armstrong
Copy link
Member

@Jmeyer1292, Have you gotten a chance to check this?

@Jmeyer1292
Copy link
Contributor

Jmeyer1292 commented Feb 6, 2017

It's not the same. On Godel we're using a version that was generated with a "newer" IK-Fast. It's difficult to say anything about the IK code beyond that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants