-
Notifications
You must be signed in to change notification settings - Fork 43
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
IK solutions exceed joint limits #48
Comments
That is quite odd - do you mind sharing code that can replicate this problem? EDIT: actually looking at the code more, the joint limits are currently only used in the initial configuration generation rather than enforced at each step of the optimization. There are several potential solutions:
It's not obvious that solution 1 will be better here because it will introduce more local minima as now there's competing cost functions. You can try solution 2 for now but when you post the code I can also implement those solutions and try them out on it. |
I apologize that our urdf file is confidential, and hence I cannot share the structure of it.
And in ManiSkill, I just apply the joint configuration, and check the corresponding tcp like this:
Could you please explain how to wrap and project the joint configurations into joint limits? |
Hi, thanks for your impressive works!
We are new to the robotics, and we have customized a urdf file to describe our 6-DOF arm.
And we found that given an tool center pose (tcp), the PseudoInverseIK will return converged solutions that exceed joint limits. (The argument of joint limit is properly given.)
The values are around 10^1 to 10^2 (should be radius I think).
Surprisingly, after setting the seemingly wrong joint solutions on robot simulators like ManiSkill, we found the corresponding tcp is the same as expected.
Is it reasonable?
What should be further tested?
Thanks in advance!
The text was updated successfully, but these errors were encountered: