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 : > 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 : >> 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@willowgarage.com) >> Research Engineer >> Willow Garage, Inc. >> 68 Willow Road >> Menlo Park, CA 94025 >> 650.475.9772 >> >> >> >> >> 2011/1/8 Martin Günther >>> >>> 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@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >> >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> >> >