UR10 with continous joints (2pi)
Issue #3
wontfix
Using the normal UR10 urdf causes the planner to either fail or create crazy plans very often. The solution we found is to use the limited version of the arm joints. However this solution is not ideal when planning for the real arm.
I was hoping that trac IK would solve the issue, but I tested and it seems to be the same.
Do you think there would be a solution to solve that problem
Comments (3)
-
Account Deactivated
-
Account Deactivated
- changed status to wontfix
This seems to be more of an issue with how MoveIt! is planning (plans fast in joint space then tries to smooth the plan in post-processing), rather than an IK issue.
Future enhancements of trac_ik include the ability for IK to run for a requested set of time to find multiple IK solutions and return the one that minimizes a user-defined metric. This might help reduce problems in planning by finding a better goal joint configuration.
-
reporter
Thanks for the answer. ok, I understand.
- Log in to comment
It sounds to me like this is a long standing issue with MoveIt!? And this happens even with KDL? If so, I'd say that this is probably more of an issue with the way that MoveIt! is planning than a trac_ik issue.
My understanding of how MoveIt! works from digging in the code is this (though I am NOT a MoveIt! developer): For normal operations, MoveIt! only really calls an IK solver once -- to get a joint configuration for the goal. It already knows the current joint configuration from encoder info. All planning at that point is done in JOINT SPACE. Collision detection and constraint checking may use Forward Kinematics to determine the pose of any subgoal joint configuration, but the planning IS NOT being done in Cartesian space. After a joint trajectory is found, MoveIt! tries to smooth the trajectory to make it less "crazy", but this isn't always the case. Thus, TRAC-IK really isn't going to help you much for normal MoveIt! operations.
If you don't have obstacles in your space, you may want to try the Cartesian planning API in MoveIt! to get "straight-line" motion. If you are calling MoveIt's Cartesian planner, that IS "planning" in Cartesian space (doing lots of IK calls). Though really it is just performing linear interpolation in x,y,z,roll,pitch,yaw between the current and desired poses -- it isn't really "Searching" for a solution. That is, MoveIt Cartesian capability is not doing collision avoidance or replanning -- if a collision is detected, the "planning" immediately stops, but still returns True that a trajectory was found. This is not ideal, and needs to be fixed -- I may write a new Cartesian capability plugin for MoveIt! that addresses this.