[ros-users] manipulation stack problems

Mon Feb 7 16:53:43 UTC 2011

Hi Ugo,

Glad to hear things are working out. Writing a /hand_posture_execution
for a new hand is expected behavior, it's what we envisioned people
doing for porting the code to a new robot.

As for the lift, maybe this will help. The reason for the lift is so
that, when the grasp is complete, the robot is in a state that the
environment servers does not consider in collision; otherwise, the
motion planners will refuse to take the arm out of there. The amount
of lift is specified in the PickupGoal as a GripperTranslation. Much
like the approach, there are two values: one is how much you'd like
the object to be lifted, and the other one is the minimum lift
distance that should be deemed feasible before the grasp is even
attempted.

Now, for the direction of the lift, note that the lift component of
the PickupGoal specifies a direction as a Vector3Stamped. In theory,
this one can be used to specify a direction in any coordinate frame
that tf knows about. However, there is a catch: due to the way the
internals of our system work, the grasping pipeline can only use lift
directions specified in either the hand's coordinate system or the
robot's coordinate system. These are the "robot_frame" and
"hand_frame" specified in your .yaml hand configuration file.

In practice, this is enough to cover most use cases. We've found two
main use cases
- when getting something from a table, you want to lift "up" (in the
opposite direction to gravity). For this case, use the "up" direction
in your robot frame.
- when getting something from a shelf, you want to lift in the
opposite of the gripper approach direction. For this case, use the
opposite of the approach direction in your hand frame.

Hope this helps; let us know if you run into more problems.

Best,
Matei

On Mon, Feb 7, 2011 at 7:24 AM, Ugo Cupcic <ugo at shadowrobot.com> wrote:
> Hi,
>
> Thanks a lot for both your answers. It made things a bit clearer.
>
> I'm using the grasping pipeline, but I had to modify some nodes because I'm
> adapting it to our robot hand / arm + using the kinect as a 3d sensor.
> I had to write my own move_arm_simple_action / hand_posture_execution nodes.
>
> Modifying the hand_approach_direction in my hand_description config file
> solved the problem of the "backward" approach.
>
> I still have to get the lift action to behave, but we're getting there :)
>
> Cheers,
>
> Ugo
>
>
> On Fri, Feb 4, 2011 at 1:07 AM, Matei Ciocarlie <matei at willowgarage.com>
> wrote:
>>
>> Hi Ugo,
>>
>> Are you using the grasping pipeline by calling the Pickup action? If so,
>> the grasping pipeline will do for you all of what Kaijen explained. Here are
>> a few notes:
>>
>> - the pre-grasp stored in the database is not used. Initially we though it
>> would be, but then we realized that how far back the pre-grasp should be
>> from the grasp is often application-specific.
>>
>> - the Pickup action goal thus specifies how far back the pre-grasp should
>> be. There are two relevant fields:
>>
>> float32 desired_approach_distance
>> float32 min_approach_distance
>>
>> - the grasping pipeline will attempt to find a pre-grasp that is "behind"
>> the grasp by at least min_approach_distance, and ideally
>> desired_approach_distance. This pre-grasp must be reachable and out of
>> collision. It will do this by starting at the grasp position, then doing
>> interpolated IK "backwards" as far as possible, up to
>> desired_approach_distance. This explains why Interpolated IK markers show up
>> the at the grasp location first, then move back.
>>
>> - what does "backwards" mean? That is specified on the parameter server.
>> The grasping pipeline will look for a set of parameters telling it, among
>> others:
>>  * what is the tf name of reference frame of the hand - this is the frame
>> that the grasp pose refers to
>>  * what is the "approach" direction, relative to the hand frame, when
>> executing a grasp. A pre-grasp will be computed by translating a grasp in
>> the opposite of the approach direction.
>>
>> For the PR2, this is specified in
>> pr2_object_manipulation_launch/config/pr2_hand_descriptions.yaml. You will
>> probably need to adapt this file to your hardware.
>>
>> Let us know if you have more problems, we'd be glad to help. Also, if you
>> could include some rviz screenshots from multiple viewpoints that would
>> help, as it's hard to tell from one image what things look like in 3D.
>>
>> Best,
>> Matei
>>
>> On Thu, Feb 3, 2011 at 1:06 PM, Kaijen Hsiao <kaijenhsiao at gmail.com>
>> wrote:
>>>
>>> Hi Ugo,
>>> I'm not sure exactly which stack/code you are using, but those markers
>>> look like they're coming from the interpolated IK motion planner.  The
>>> interpolated IK motion planner can search for a consistent/feasible
>>> path starting from either end--if the start_from_end parameter is
>>> true, then the planner finds IK solutions for the end pose first, then
>>> works its way backwards towards the start pose, using the last set of
>>> found arm angles as the starting point.
>>>
>>> Typically when you're planning from pregrasp to grasp, you want to
>>> enter pregrasp as start and grasp as end so the trajectory times are
>>> correct, but you want to ask it to start searching from the grasp
>>> (end) pose and work its way backwards.  That's because you typically
>>> can't compromise on the final grasp pose, but you might not mind if
>>> the Cartesian path backwards towards the pregrasp gets almost but not
>>> all the way there.  That's what the error codes tell you--how far it
>>> got.  (You can also set the steps_before_abort param to 0 if you just
>>> want it to abort if it finds any infeasible/inconsistent poses at
>>> all.)
>>> If you get an incomplete path back, you can decide whether you're
>>> willing to just motion plan to a slightly closer pregrasp pose, or if
>>> you want to abort.  If the markers don't make it all the way to the
>>> pregrasp, it means that the path is incomplete--the next step towards
>>> the pregrasp either had no collision-free IK solution, or else had no
>>> solution consistent with the last step (within consistent_angle for
>>> all joint angles from the last step).
>>>
>>> I'm not sure what you're running to get to the pregrasp, but you
>>> probably want to use move_arm or some such to move to the start of the
>>> (completed portion of the) trajectory returned by the interpolated IK
>>> motion planner, then use a normal joint trajectory movement to get
>>> through the rest of the trajectory.  (Or you can just use a Cartesian
>>> controller, assured that there actually is a feasible/consistent path
>>> to actually reach the grasp pose from that set of joint angles.)
>>>
>>> Hope that helps.
>>>
>>> -Kaijen
>>>
>>>
>>> On Thu, Feb 3, 2011 at 8:25 AM, Ugo Cupcic <ugo at shadowrobot.com> wrote:
>>> > Hi all,
>>> >
>>> > I'm still trying to get the manipulation stack to work with our arm and
>>> > hand
>>> > and I ran into some problem:
>>> >
>>> > As you can see here, A path from pregrasp to grasp is found:
>>> > http://img267.imageshack.us/img267/199/rviz013.png
>>> >
>>> > But:
>>> >  > the path seems to be the wrong way around: the first markers are at
>>> > the
>>> > bottom, instead of at the top.
>>> >  > when moving the arm, the arm moves maybe 5cm below the markers (on
>>> > the
>>> > screenshot, it's at position 0 which should be pregrasp).
>>> >
>>> > The values I put in the database are:
>>> > grasp_pregrasp_position =
>>> > "{0,0,0.281533,0.707106781186548,0.707106781186548,0,0}"
>>> > grasp_grasp_position =
>>> > "{0,0,0.213018,0.707106781186548,0.707106781186548,0,0}"
>>> >
>>> > Any help greatly appreciated.
>>> >
>>> > 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
>>> >
>>> >
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> 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