[ros-users] manipulation stack problems

Ugo Cupcic ugo at shadowrobot.com
Mon Feb 7 18:20:01 UTC 2011


Dear Matei,

Thanks once more for your very complete answer. I now sorted my lifting
problem (some stupid bug in my code).

I'm still having issues with the planning environment. I'm using a Kinect as
a source of 3D data. I have to convert the pcl2 to a pcl using
point_cloud_converter to be able to build the collision map (Radu told me I
was mad to use that as it's not efficient at all, but I'm waiting for the
collision map to use a pcl2 :) ). For the time being I'm just returning true
in isStateValid. I haven't had time to debug that yet (I'll try to work on
it tomorrow), but I'm sending this just in case you have any miraculous
hindsight.

I'm not sure on which topic I should subscribe to visualize the
attached_object in rviz as well. (I looked at the tf but couldn't see any tf
moving with the model, once the hand has grasped the can).

Cheers,

Ugo



On Mon, Feb 7, 2011 at 4:53 PM, Matei Ciocarlie <matei at willowgarage.com>wrote:

> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110207/a232cf50/attachment-0003.html>


More information about the ros-users mailing list