asked 2011-06-27 23:46:25 -0500Fei Liu
I want to make use of the strength of Openrave to get the analytic solutions for our 5dof manipulator. I know in orrosplanning package, ik_openrave.py provide a service /GetPositionIK. But I want a IK plugin to be loaded by ompl_ros_interface for motion planning. I just wonder how could I configure the Openrave IK module into a plugin? I heard that openrave could generate a C++ file as the inverse kinematics for the given manipulator, is it possible to use it to build a plugin. What would be the best way to do it and how to do it? Thanks.
answered 2011-06-30 04:58:39 -0500Henning Deeken
i just wanted to tell you that we (Martin and I) just pushed the latest version of our katana_driver stack, which now supports constraint aware motion planning for our arm.
The set up is the following:
with this set up we are now able to use OMPL within our for our arm navigation. I hope looking through our files will help you setting up your arm. We also included some code for testing within the katana_openrave_test package.
Please feel free to e-mail me if you could need more detailed support or in cases you find some bugs or other ideas for improvement.
Greetings from Osnabrück, Henning
answered 2011-06-30 10:26:29 -0500egiljones
Calling the ik solver through a service call should work for converting pose goals into joint goals, which only needs to happen once or a few times (if sampling in goal regions) during planning. For planning in task space - for instance, when it is desired that the end effector of the robot maintain a particular pitch and roll during the movement such that a glass is not upended - the ik solver will need to be called thousands of times, and the time required for calling even a persistent service will likely be orders of magnitude more than the cost of computation ik using ik fast, which should be microseconds. Using pure C++ for the plugin is definitely the way to go in terms of efficiency.
My hope is in the near future we at willow can make it very easy to use ikfast as a generic ik solver, and again if you pursue this path we'd love some pointers.
answered 2011-06-28 17:05:41 -0500egiljones
I've also been wanting to do this on our end but haven't gotten around to it yet. If indeed you can get a C++ function for the ik then it should be pretty straightforward to implement the necessary functions for a kinematics plugin. There's some info on making a kinematics plugin the wiki that may not be totally complete: http://www.ros.org/wiki/kinematics_base - you basically just need to implement a bunch of virtual function and make the plugin. You can use the generic arm navigation package in arm_kinematics_constraint_aware/src/kdl_arm_kinematics_plugin.cpp as a starting point.
I will probably get around to getting some more materials on this in the coming months, but if you have any luck a tutorial on the wiki would be a great help! Especially helpful would be information on the OpenRave side, as I don't have much experience with that.
that sounds great! currently there's two ways to do this:
This question is a year old but a comprehensive tutorial for setting up IKFast using your URDF is finally available here, thanks to David Butterworth: http://ros.org/wiki/Industrial/Tutorials/Create_a_Fast_IK_Solution
That said, while I have gotten the IKFast plugin to generate and compile, I have not had any luck getting it to actually find solutions while running. Still working on that.
if you are interested in the planning part of openrave, we would be glad to help set up all the necessary ROS service calls to get it working with the katana arm. currently the orrosplanning/armplanning_openrave.py script only supports the CollisionMap message, but we can add any messages you feel are important for discovering the collision world.
Although you might have many plans for OMPL and OMPL may support many cool features, we can help you reduce the time to setup planning for your system.
any model files you can send would be helpful.
Asked: 2011-06-27 23:46:25 -0500
Seen: 781 times
Last updated: Dec 03 '12