use trac_ik_plugin with 3DOF robot
Issue #30
resolved
I have a 3DOF robot arm and all of them are rotating on the same axis (say z axis in urdf model). Inside RViz with MoveIt's motion planning, I am able to drag the end-effector around and perform the motion planning with your trac_ik_plugin as the kinematic solver.
However, when I write my own ROS package to call the API or use MoveGroup class from MoveIt, it never returns a solution to exactly the same target end-effector pose. I have no such problem when working with a 7DOF arm with exactly the same setup procedure (except of course the arm is designed differently).
So my question is whether trac_ik is designed to work with small number of DOF (e.g. 3DOF in my case)? Or there is any tested examples or tricks to get it working?
Comments (6)
-
-
reporter
Hi ironmanames, The tolerance is definitely the key. I finally managed to get some reasonable output from trac_ik. Also using FK to setup test is a good trick. Thanks! However, interestingly the moveit api solver still doesn't give me a pass. I think this maybe because the motion planning part that is failing to give me a valid trajectory. This is probably not related to trac_ik anymore. At least I can confirm that trac_ik is returning me a good valid joint state to my target point after adding some debug print in trac_ik library.
-
reporter
I am running into a deadlock situation. I have to set tolerance to all zero in order to get solutions from trac_ik. But it looks like the motion planner (RRT etc) will fail to give an output. Do you know if it's possible to set two different tolerance in MoveIt or anyway to bypass this dead lock situation?
-
reporter
Good news is that I finally managed to use trac_ik with my 3DOF design. The trick is to set the tolerance differently and not too strict in the corresponding (x,y,z) and (roll, pitch, yaw).
-
Glad to hear it's worked out.
-
Account Deactivated
- changed status to resolved
I'm going to resolve this issue for now. Please re-open if you have any further issues.
- Log in to comment
Hey John,
For low DOF situations you might consider something like IKFast which can create an analytical solution, it should be faster, but I know that there are some limitations that are based on the actual configuration of the arm. trac_ik can handle low-DOF situations, although it's best comparative advantage is in the 5-8DOF range.
Are you certain that the pose being requested is reachable? With 3 DOFs the returned pose may not be the same because the requested pose is not in the configuration space of the arm. The best way to test this would be to set the angles on the joints, use FK to find the pose and request trac_ik to find that pose. In fact, this is how we test trac_ik. We uniformly sample from joint angles and perform FK, and then use trac_ik to find a solution to that pose, we do this 10,000 times and that's how we're able to calculate the percent of coverage.
Another possible source of error is the setting of the tolerances. If the pose is off by an amount less than the tolerances then you'll need to tighten the tolerances to get a better pose.