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

ikFast class checks joint limits incorrectly #1449

Closed
sniyaz opened this issue Apr 24, 2020 · 6 comments · Fixed by #1452
Closed

ikFast class checks joint limits incorrectly #1449

sniyaz opened this issue Apr 24, 2020 · 6 comments · Fixed by #1452
Labels
type: bug Indicates an unexpected problem or unintended behavior

Comments

@sniyaz
Copy link

sniyaz commented Apr 24, 2020

Environment

Irrelevant, but on Dart 6.9 with GCC 7.5 on Bionic.

Expected Behavior

All valid solutions being returned through ikFast.

Current Behavior

if (solutionValues[i] < skel->getDof(dofIndex)->getPositionLowerLimit())

It doesn't look like ikFast gives any promises for the range of returned ik solutions. For example, with a joint with limits at [pi/8, 2pi], the ikFast binary may return a solution at -pi.

Checking this raw value against the skeleton limits (as is done now) appears to lead to valid solutions being thrown away (in the example above, we can just wrap the joint value to pi, which is actually in-limits).

It looks like some wrapping is needed in the joint limit checking here, since ikFast doesn't provide a guarantee on the range as mentioned earlier.

Steps to Reproduce

I have a Jaco ikFast binary I'd be happy to share where this happens.

Code to Reproduce

Simply run the provided binary: almost all solutions are thrown away.

@sniyaz sniyaz added the type: bug Indicates an unexpected problem or unintended behavior label Apr 24, 2020
@jslee02
Copy link
Member

jslee02 commented Apr 25, 2020

Thank you for the report. The workaround makes sense to me. I wonder why IKFast wraps the solution in the first place though. 🤔

Maybe we can wrap the joint values only for SO(2) joint. I'm not sure what the representation is used for SO(3) joint in IKFast.

I have a Jaco ikFast binary I'd be happy to share where this happens.

Could you share the binary and the URDF as well? It would be very helpful to ensure if the issue is solved by having it as a regression test with the models.

@jslee02
Copy link
Member

jslee02 commented Apr 26, 2020

A possible solution for this issue: #1452

@jslee02 jslee02 reopened this Apr 27, 2020
@jslee02
Copy link
Member

jslee02 commented Apr 27, 2020

@sniyaz Please let me know when you confirm that #1452 fixes the issue.

@sniyaz
Copy link
Author

sniyaz commented Apr 28, 2020

Thank you @jslee02! I won't have access to my lab machine for a bit, but I'll let you know ASAP whether this resolves things.

Would you still like the URDF and the binary?

@jslee02
Copy link
Member

jslee02 commented May 1, 2020

I won't have access to my lab machine for a bit, but I'll let you know ASAP whether this resolves things.

Thanks!

Would you still like the URDF and the binary?

Optional, but it'd be great if you can share!

@jslee02
Copy link
Member

jslee02 commented Aug 28, 2020

Closing this issue as the fix was verified by the unit test. @sniyaz Please let me know if the issue is persistent even with the fix. :)

@jslee02 jslee02 closed this as completed Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants