[ros-users] Generic constraint aware IK?

Fri Jan 14 03:56:59 UTC 2011

In addition to the ik_openrave.py, here are some more notes about the
orrosplanning/IK service:

1. It allows you to set a manipulator name that specify the group
joints. Current possible ones for the pr2 are:

leftarm
leftarm_torso
rightarm
rightarm_torso
head
head_torso
leftarm_camera
rightarm_camera

2. You can choose which type of IK to solve: Transform6D, Rotation3D,
Translation3D, Direction3D, Ray4D, Lookat3D,

For example, check out the lookat3d ik for the pr2 head:

rosrun openrave openrave.py --example tutorial_iklookat

3. It can give you all solutions, not just the first collision-free
one it finds.

rosen,

2011/1/14 Rosen Diankov <rosen.diankov at gmail.com>:
> Hi Martin,
>
> There is a ik_openrave.py script in the orrosplanning package that
> will offer the IK service for you. We just added support for the
> GetPositionIK message (jsk-ros-pkg r1022). Update the
> openrave_planning stack and rosmake orrosplanning.
>
> In order to start it do:
>
> rosrun orrosplanning ik_openrave.py
>
> there is a test script here:
>
> rosrun orrosplanning testarmik.py
>
> Some notes:
>
> 1. The GetPositionIK service does not allow you to set the group of
> joints used in the IK computation only the end effector link name.
> Therefore, openrave adds the torso joint by default. If you want finer
> control of this, there use the orrosplanning/IK service (parameters
> should be the same). In any case the ik_openrave.py script starts both
> services.
>
> 2. You can disable the default viewer by
>
> rosrun orrosplanning ik_openrave.py --viewer=""
>
> 3. ik_openrave.py also subscribes to the CollisionMap message. You can
> change the message it subscribes to with '--collision_map=xxx'
>
> 4. You can load a different robot with the '--scene' command. This
> takes in COLLADA files, which can be automatically generated from URDF
> files.
>
> hope this helps!
> rosen,
>
> 2011/1/9 Gil Jones <gjones at willowgarage.com>:
>> 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
>>
>> --
>> E. Gil Jones (gjones at willowgarage.com)
>> Research Engineer
>> Willow Garage, Inc.
>> 68 Willow Road
>> Menlo Park, CA 94025
>> 650.475.9772
>>
>>
>>
>>
>> 2011/1/8 Martin Günther <mguenthe at uos.de>
>>>
>>> Hi everybody,
>>>
>>> I am currently (still) in the process of porting the arm_navigation
>>> stack to a Katana arm. I already have a replacement for almost
>>> everything in the pr2_3dnav/right_arm_navigation.launch file (mostly a
>>> big copy-and-paste orgy, followed by s/pr2/katana/g).
>>>
>>> At the moment, I use the generic arm_kinematics package from urdf_tools
>>> to provide the get_ik and get_fk services, since this seems to be the
>>> simplest package to set up. Maybe later I'm going to switch to
>>> OpenRave's ikfast module.
>>>
>>> However, move_arm expects a get_constraint_aware_ik service. Is there
>>> an easy way to get that going?
>>>
>>> Cheers,
>>> Martin
>>>
>>> --
>>> 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
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>