Hi Sachin, The ik_seed_state comments totally threw me off ;0) If this is a valid way of extracting the joints used in the ik, perhaps it would make sense to say that the ik_seed_state is valid with no positions filled in. Group name would be awesome, but knowing the set of joints also works since we can do the inverse search. rosen, 2011/1/14 Sachin Chitta : > Rosen, > > You can specify the set of joints used for IK in the ik_seed_state. Do > you want to be able to specify this instead using a group name in the > request for the set of joints that will be used for IK? We can add > that in. It definitely would make the IK service more convenient. > > Sachin > > On Thu, Jan 13, 2011 at 7:46 PM, Rosen Diankov wrote: >> 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 >>> >>> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > > > > -- > Sachin Chitta > Research Scientist > Willow Garage > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >