-
Notifications
You must be signed in to change notification settings - Fork 1k
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 for UR donation #300
Comments
You should create a pull request for such things because this can be beneficial to other users. What does your forward function look like? |
+1 to a pull request.
|
The IK solver in UR_kin.cpp works fine. |
@atenpas: could you elaborate your comment a bit? Are you saying that you don't encounter the problems that @TheURMaxer describes / described in #299? |
@gavanderhoorn: As I've stated in #299: "I've been using the ur_kin module without any problems on our UR5 robot (I use this directly without moveit though)". I also emailed with the developer of that module, and there does not seem to be a real issue here. |
Ok. Tnx. |
I believe the kinematics core functionality is fine; the problem happens in the MoveIt wrapper, and seems to be the root of the joint_limited work-around as well. Take a look at ur_moveit_plugin.cpp, L658 and following: there's a block of code that tries to account for the fact that the joint angles cover more than one rotation. The issue is that, if each joint has two periodic solutions (q[i][j] and q[i][j]+2pi), then each kinematic solution has 2^6=64 joint-space solutions. So, for a typical IK request with 8 kinematically distinct configurations (elbow up and down, wrist up and down, shoulder forward and back, so 2^3) there are 512 total solutions. Since the current function only considers one permutation of the 64, the likelihood of the IK returning the true nearest solution is pretty small, leading to the jumping behavior seen in the MoveIt RViz window. To test this, I wrote a function that recursively enumerates all 64 possible joint configurations for a given solution, which has solved the erratic behavior in RViz on my machine. Right now it uses the std::vector + std::sort technique that's currently implemented, but it seems like it might be more efficient to return a priority queue, or maybe just the best result. I'll open a pull request for further discussion. |
Marking this as an issue for wrid19 as it'd be nice to get a final answer to this in addition to @atenpas' answer. Note: this issue is also part of the |
About 2 weeks ago, I posted a problem regarding the IK of UR robots. The issue related to recovering rotation information and the IK solution in UR_kin.cpp. I mentioned that the original paper, Analytic Inverse Kinematics for the Universal Robots UR-5/UR-10 Arms by Kelsey P. Hawkins, December 7, 2013, provided the "correct" forward kinematics fomulae, but only a sketch of the inverse kinematics. Keeping the story short, I made modifications to the UR_kin.cpp to provide the matching IK to the paper by Hawkins. I hereby post my modifications in the hope they are useful to anyone else.
Regards,
Max van Rooij
`UR5_inverse_kin_new(const double T[16], double q_sols[8*6], double q6_des)
{
double const d1 = 0.08920f; //Denavit-Hartenberg parameters for the UR5 in [m]
double const d4 = 0.10900f;
double const d5 = 0.09300f;
double const d6 = 0.08200f;
double const a2 = -0.42500f;
double const a3 = -0.39243f;
}`
The text was updated successfully, but these errors were encountered: