I made a small change to moveit_ikfast's template plugin that I think would be very useful to people with low-DOF arms. The change enables OpenRAVE's Translation3D-type inverse kinematics, which previously wasn't supported.
We have some arms in our lab that have just 3 DOF, so they can't reach arbitrary poses. They can, however, reach arbitrary translations if we don't care about orientation. The default IK that moveit uses (namely, KDL) doesn't work very well for these low-DOF arms. It usually fails to find a (pose) solution. If approximate solutions are enabled, it usually finds a solution, but one that isn't particularly useful.
I've found that IKFast's Translation3D-type IK works quite well, however. This merge request makes a simple change to the ikfast moveit template, that treats Translation3D IK requests as basically the same as Transform6D requests. It works because I believe the IK solver computed by IKFast just ignores the orientation anyways.
I've tested this change with our 3 DOF arm in simulation, with moveit's auto-generated demo.launch. It works great when the interactive markers are dragged around - our arm follows the translation nicely. Again, a big improvement over KDL (which failed to find solutions unless approximate ones were allowed) for low-DOF arms.
Thanks, and do let me know if you'd like me to make any more changes / think it should be made another way, have any questions, etc.
Cheers,
Steve
(P.S. Thanks for all your help in working on and helping to mature MoveIt! - it's a great platform!)
Hi all,
I made a small change to moveit_ikfast's template plugin that I think would be very useful to people with low-DOF arms. The change enables OpenRAVE's Translation3D-type inverse kinematics, which previously wasn't supported.
We have some arms in our lab that have just 3 DOF, so they can't reach arbitrary poses. They can, however, reach arbitrary translations if we don't care about orientation. The default IK that moveit uses (namely, KDL) doesn't work very well for these low-DOF arms. It usually fails to find a (pose) solution. If approximate solutions are enabled, it usually finds a solution, but one that isn't particularly useful.
I've found that IKFast's Translation3D-type IK works quite well, however. This merge request makes a simple change to the ikfast moveit template, that treats Translation3D IK requests as basically the same as Transform6D requests. It works because I believe the IK solver computed by IKFast just ignores the orientation anyways.
I've tested this change with our 3 DOF arm in simulation, with moveit's auto-generated demo.launch. It works great when the interactive markers are dragged around - our arm follows the translation nicely. Again, a big improvement over KDL (which failed to find solutions unless approximate ones were allowed) for low-DOF arms.
Thanks, and do let me know if you'd like me to make any more changes / think it should be made another way, have any questions, etc.
Cheers, Steve (P.S. Thanks for all your help in working on and helping to mature MoveIt! - it's a great platform!)