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@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/