[ros-users] Generic constraint aware IK?

[Sachin Chitta]

We are, at some point, going to revisit the move_arm API. There is a
potential for ROS APIs to get bloated easily since some people might often
want only a subset of the functionality but the service call or action must
provide the full functionality. That's the idea with the
get_constraint_aware_ik service - it provides a larger set of functionality
but you can choose to ignore stuff you don't need across the whole stack. We
would like to retain the ability to specify constraints to an ik solver so
the solution might be to provide both services and advertise only the one
that will end up getting used using a configuration parameter.

Thanks for the feedback. Any feedback helps, so keep it coming.

Regards,
Sachin

2011/1/9 Martin Günther <mguenthe at uos.de>

> Hi Gil,
>
> thanks, that was very helpful. I went with the second solution you
> proposed (just strip away the constraint-aware stuff and call a normal
> get_ik service instead). Since the Katana arm only has 5 DoF, I don't
> have any redundancy that I could use to avoid collisions anyway.
> Perhaps move_arm should have an option to provide a get_ik instead of
> a get_constraint_aware_ik service instead? Just a thought, providing a
> simple wrapper is not really difficult of course, and maybe the
> move_arm API shouldn't be too bloated.
>
> Best wishes,
> Martin
>
>
> On Sat, 8 Jan 2011 11:00:07 -0800
> Gil Jones <gjones at willowgarage.com> wrote:
>
> > Hi Martin,
> >
> > I'm glad you are making progress - we're definitely trying to make it
> > easier for others to use arm navigation but we still have a ways to
> > go.
> >
> > To answer your question,  you don't have to supply move_arm with an ik
> > service - that's only if you want to pass in end-effector goals and
> > have it call the IK service.  You can call ik yourself and just pass
> > in joint positions and everything should work.
> >
> > If you want move_arm to invoke IK, then it boils down to whether or
> > not you actually want to make ik aware of constraints, such as not
> > providing solutions that are in self- or environmental collision.  If
> > you don't care about that you can simply provide a service that take
> > the constraint aware ik messages and then calls your non-constraint
> > aware ik.  If you return a solution that violates constraints - for
> > instance, that is in self-collision
> > - then move arm will abort with an error code.  But if the solution
> > is valid everything should work.
> >
> > But if you are really interested in getting constraint aware ik then
> > there's no easy way that I know about, though conceptually
> > constraint-aware ik isn't too difficult.  What our constraint aware IK
> > (pr2_arm_kinematics_constraint_aware) consists of is a way to check
> > that space of potential IK solutions for a solution that obeys all
> > constraints. On the PR2 we only have one redundancy so we just set
> > the redundancy according to the supplied seed, discretize the
> > redundancy space, and then check each state for constraint
> > satisfaction using our planning_environment.  We also do an initial
> > check to make sure that the end effector itself isn't in collision at
> > the desired pose - if it is there's no reason to search the space of
> > redundancies.  We return the first valid solution we find, though
> > we've also experimented with other versions that try to find the
> > 'best' solution - the one furthest away from collisions, for instance.
> >
> > I very much hope we can make things like this more generic in the
> > future - maybe there's an openrave module that will do this for you.
> > But if you are interested in writing your own let us know if there's
> > anything we can do to help.
> >
> > Best,
> > Gil
>
> --
> Dipl.-Inf. Martin Günther
> Universität Osnabrück
> Institut für Informatik
> Albrechtstr. 28  (Raum 31/503)
> D-49076 Osnabrück
>
> Fon: 0541 969 2434
> http://www.inf.uos.de/mguenthe/
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
Sachin Chitta
Research Scientist
Willow Garage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110109/3b0488f7/attachment-0003.html>