[ros-users] reactive_grasp, compliant_close: not using the database

Kaijen Hsiao kaijenhsiao at gmail.com
Thu Mar 3 22:01:11 UTC 2011

Hi Ugo,
Would it be sufficient for your purposes to add
sensor_msgs/JointState pre_grasp_posture
sensor_msgs/JointState grasp_posture
to the ReactiveActionGoal?
(If you want, I can also make a new CompliantCloseAction that contains
these two things, so you can parallel our code--I've meant to use such
a thing for our code for awhile even, but there was never a need for
it until now.  We are likely to want such a thing for future arm/hand
ports, anyway.)
Are you using the trunk or Diamondback or unstable version of our
code, or something else?


On Thu, Mar 3, 2011 at 9:41 AM, Matei Ciocarlie <matei at willowgarage.com> wrote:
> Hi Ugo,
> There are two things that the hand needs to do: move from pre-grasp to
> grasp, and then close the fingers. Our nomenclature is definitely less
> than ideal, they are both referred to as "grasp" in parts of the
> pipeline...
> Reactive grasping as defined by the ReactiveGrasp.action actually
> combines both. It should be called "ReactiveApproachAndGrasp" or
> something in the vicinity... The implementation we have is PR2
> specific for both the approach and the finger closing part. You are
> right, as a module that is (also) responsible for closing the fingers,
> it should take in the grasp posture as well (not just the pose).
> When not using reactive grasping, we actually do split it into two.
> First, open-loop inerpolated IK is done to get the hand from pre-grasp
> to grasp. Then, a call to a GraspHandPostureExecution.action is made.
> This call does contain all the info about the grasp .We have a PR2
> implementation that simply closes the fingers in response to that call
> in the
> pr2_gripper_grasp_controller package.
> You could write a sh_gripper_grasp_controller package that responds to
> GraspHandPostureExecution goals, either in a reactive or non-reactive
> way. This would only refer to the finger closing part (not the
> approach) but you could implement all the behaviors that you mentioned
> in your email.
> Alternatively, if you prefer a "ReactiveApproachAndGrasp" all in one
> shot, we would indeed need to modify the ReactiveGrasp call to contain
> the grasp posture. That also seems like a reasonable thing to do.
> Best,
> Matei
> On Thu, Mar 3, 2011 at 4:16 AM, Ugo Cupcic <ugo at shadowrobot.com> wrote:
>> Hi,
>> In the reactive_grasp, the compliant_close function is not using the grasp
>> posture from the database. I understand that it can work for the gripper,
>> but for a more complex hand such as ours, I believe it would be a good start
>> to have access to this grasp posture here.
>> What I wanted to do in the reactive grasp, was (as a first approach):
>>  - interpolate between current posture of the hand and "closed posture"
>> (read from the database), while checking for contacts.
>>  - when I have a contact on one finger, I stop moving this finger.
>>  - when all fingers are touching lightly the object, close until force > X
>> Is it not the purpose of the reactive_grasp server? Should I do that in my
>> standard static grasp? Do I need to query my databases in my reactive_grasp
>> node to get the list of possible grasps, or would it be possible to extend
>> the content of the ReactiveGraspGoal message, so as to include this
>> information?
>> I hope my questions make sense, otherwise feel free to ask me for more info!
>> Cheers,
>> Ugo
>> --
>> Ugo Cupcic | Shadow Robot Company | ugo at shadowrobot.com
>> Software Engineer | 251 Liverpool Road |
>> need a Hand? | London N1 1LX | +44 20 7700 2487
>> http://www.shadowrobot.com/hand/ @shadowrobot
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> --
> Matei Ciocarlie
> Research Scientist
> Willow Garage Inc.
> 650-475-9780
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

More information about the ros-users mailing list