add C++ API for grasping

[rdiankov]

[email protected]:

I have a manipulator defined by a pa-10 and a shadow-hand robots, all ok and
working.
I made the grasping database of one object for grasping, and it works on the
examples and so. My next step is to call a function from the code and have
the data inside C (much like manip->FindIKSolution for the arm)

My question is : Is there any way to call grasping database trough C++ api?
the only way I found to get grasps from database is trough openrave.py.

Im actually calling FindIKSolution from the api to get a pa10 ik from the
python database, and I just wonder if  a similar function exists (or will)
for grasp sets.

Rosen Diankov:

The short answer to your question is that there is no directly way of
accessing the grasp sets from C++. However, this doesn't mean it isn't
possible with a little programming.

For example, the TaskManipulation's GraspPlanning command

http://openrave.org/en/main/interface_types/module/taskmanipulation.html#graspplanning

accepts the list of grasps as a string parameter, which is passed from
python. The graspplanning example uses this:

http://openrave.org/en/main/openravepy/examples.graspplanning.html#openravepy.examples.graspplanning.GraspPlanning.graspAndPlaceObject

If you would really like a C++ interface, please describe how you
would ideally like to load and use the grasps.

[email protected]

We are now using python already to call grasp, in fact examples are working,
so no problem at this point.

The thing is that having a c++ function making what python actually do
should be great to simplify code and lessen the number of applications
running. Having a function like that, we could load the plugin over openrave
instead openrave.py.

About the function, should be great to have one similar to:

OpenRAVE::RobotBase::Manipulator::FindIKSolution(const IkParameterization
&param, std::vector< dReal > &solution, int filteroptions)

¿Something like OpenRAVE::RobotBase::Manipulator::FindGraspSolution(const
graspParameterization &param, std::vector< dReal > &solution, int
filteroptions)?
returning joint angles for a valid grasp.
I suppose that parametrization must include the target kinbody, and all
needed.

Maybe even possible to put them together in a
Manipulator::FindSolution(params, solution) so can be possble to get all
Manipulator joint values from one call...

thanks for your response and regards.

[rdiankov]

It doesn't make sense to overload the robot manipulator class with methods that extend beyond the robot definition.

We've been thinking about adding a C++ API to the databases for some time now, and currently we're offering the inversekinematics database through the "ikfast" module. Perhaps in the future, we might develop a more formal API for accessing data. We definitely have to think about how the C++ and python worlds will interact with each other. Any comment in this direction are more welcome.

[rdiankov]

Jorge Munoz

I totally agree about that. It can be a great advance to have access to databases from c++.

About the location of the API call, as I see, a function taking a target in workspace and giving a solution in configuration space is inverse kinematics, so a good place to be for that function maybe the ikfast module?

the ikfast module just creates the IkSolver? instance, so IK can be used without knowing the existence of ikfast. So there are better places to put the grasping module other than in the ikfast module.

Please check out the ManipulationIKGoalSampler class, I think this is the closest type of structure you would want for the grasping:

http://openrave.org/en/coreapihtml/classOpenRAVE_1_1planningutils_1_1ManipulatorIKGoalSampler.html

Please think about sample code that the user has to type in order to:

1. create this c++ grasping db class
2. possible uses of the c++ grasping db class

[rdiankov]

So, I understand that ManipulationIKGoalSampler (correct me if wrong) makes pairs with workspace transforms and c-space coordinates. After that its possible to locate the coordinates by finding its workspace pair at the table.

Are you thinking in a kind of gripper inverse kinematics in the ikfast way or in the actual grasping way?

ikfast is easy for robots with one end effector like arms, but i see difficult(not impossible) if we have more than one end effector like a gripper, and furthermore, in the case of high dof grippers (like a hand). Maybe we can do something by taking every finger as an end effector? (just wondering)
For grasping we have the stability check involved after, but it can be easy if the first problem is solved.

In the other hand there is the aproximation-dir->close-fingers way used actually at grasping database.

About last questions. The plan is to use python or a C++ lib for the database?