Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
IkParameterizationType translationyaxisangle4d is not implemented #548
TranslationYaxis4D is not implemented in moveit_kinematics
With the help of @gavanderhoorn his answer on http://answers.ros.org/question/263925/generating-an-ikfast-solution-for-4-dof-arm/ I have made an IkFast plugin for my robot.
I've looked this up and came to the following answer on ros.answers.org http://answers.ros.org/question/191884/ik-for-this-ikparameterizationtype-not-implemented-yet/
I would be greatly helped to know which actions I should take to (similarly as in the answer above) get these kinematics implemented.
regarding a PR, no problem. But figuring out the first 2 points I have a question if you don't mind:
So I should be able to use the same
I would guess the same thing.
Possibly? I guess you tried it by now? :)
Ping @mintar . You fought with these a lot in the past.
I think so too. In the case of
For example, when I implemented the support for
There you can see that it tries to read a 3-dimensional vector (the direction vector) from
So I computed the
So you need to do something similar for the three
FYI, from the openrave documentation:
For testing, I found it easier to generate some test poses that I know are reachable by the arm (for example in RViz, generate a new random goal pose), and then call MoveIt's IK service with those poses. Dragging the handle adds further complexity IMO, so I did that as a second step.
If you fix it and could provide a PR, that would be great! I didn't do it back then because I didn't have a
This is what I did so far:
case IKP_TranslationXAxisAngle4D: case IKP_TranslationYAxisAngle4D: case IKP_TranslationZAxisAngle4D: // For **TranslationXAxisAngle4D**, **TranslationYAxisAngle4D**, and **TranslationZAxisAngle4D**, the first value // represents the angle. mult2 = pose_frame.M; double rot; rot = mult2(0, 1); ComputeIk(trans, rot, vfree.size() > 0 ? &vfree : NULL, solutions); return solutions.GetNumSolutions();
I might be making a mistake in calculating the angle above?
So I will first see that I get the IK to work.
Regarding the IK service I try to do the following:
I did some searching on this but I can't figure out how to set this up. Any pointers?
What it means is that when you ignore the translation, the rotation of the eef can be expressed as a rotation around one of the robot arm base frame axes.
For example, a SCARA robot has 4 degrees of freedom. The endeffector can rotate. The z axis of the robot's base frame and eef always point up, since the eef misses the degrees of freedom to rotate the z axis out of that plane. Since the two z axes are always parallel, the eef pose can always be expressed as translation (x,y,z) and yaw angle wrt. the base frame, and
It would help if you could provide the URDF and the generated ikfast solver of your robot.
You should be able to get the rotation angle like this:
case IKP_TranslationZAxisAngle4D: double roll, pitch, yaw; pose_frame.M.GetRPY(roll, pitch, yaw); ComputeIk(trans, *yaw, vfree.size() > 0 ? &vfree : NULL, solutions); return solutions.GetNumSolutions();
If that doesn't work, try
@mintar I see your point with the example of the SCARA robot. My URDF is in the working branch "cleaned" of my robot support package:
The reason I'm making an IKfast plugin in the first place is that I'd like to use python with moveit_commander to get the robot to a number of positions. The robot is driven by Machinekit, and that has a python API too.
I use ROS/Moveit as the off-line planning alternative to Machinekits G-code interpreter. So for making an application I'll use a python program which will take actions, depending on hardware inputs/outputs, the Machinetalk remote interface and other application specifics (like production automation machinery).
Because my robot is < 4DOF I've not succeeded in using moveit_commander (cartesian) with the "standard" KDL kinematics or trac_ik plugin.
So in the end I'd like to provide x,y and z (and possibly eef angle) and just let Moveit plan and execute the move.
Ok, your robot indeed doesn't have an axis that's parallel with the base frame, so you can't use TranslationZAxisAngle4D. Your approach to use Translation3D and then manually set the eef rotation sounds reasonable. An even better solution would be to hack your generated
referenced this issue
Jul 10, 2018
I have same topic (running moveit on yaw-yaw-z-yaw SCARA robot) and the discussion here was so helpful.
I can confirm this works with moveit_commander sample code