Re: Error with ikfast when running Hanoi example

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

matt.cong
Hi Rosen,

Thanks for the advice. I was able to use ikfast to generate fk and ik for the Kuka robot after changing the anchor tags to translation tags. I verified that these gave correct solutions (such as the position of the end-effector with respect to the base in the world frame) by having it print out the positions returned by fk and ik.

I defined a gripper (using the basic geometry types) and attached it to the robot in a similar way to how I attached the Puma gripper to the body of the Puma robot. However, when I regenerate the kinematics using ikfast and test them, I obtain the same results for the position of my end-effector as the configuration without the gripper (essentially without the additional length in the last link due to the gripper). Do you have some ideas as to how to resolve this? I noticed that the Puma has an explicitly specified iksolver: Is this needed when a manipulator is attached?

Thanks,
Matthew

----- Original Message -----
From: "Rosen Diankov" <[hidden email]>
To: "matt cong" <[hidden email]>
Cc: [hidden email]
Sent: Monday, September 27, 2010 4:43:57 AM
Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example

Hi Matt,

The reason you are not seeing any change is because link6 of kuka-r850
is at the origin of the robot. In fact, all links are at the origin,
which can be confirmed by calling Link.GetTransform(). You were
probably expecting link6 to be where the manipulator frame was
defined.

In any case, you have to change the translation of Puma6 to "0.56 0 0.79"

rosen,

2010/9/27  <[hidden email]>:

> Hi Rosen,
>
> Thank you once again for the prompt reply. It was very helpful.
>
> I looked at the XML again and it appears that the <offsetfrom> is set
> correctly. However, when I do transformations, they are still relative to
> the base which makes me think that an offsetfrom is spacified incorrectly.
> Here's the file:
>
> <Robot name="Kuka">
>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>   </KinBody>
>   <KinBody file="robots/pumagripper.kinbody.xml">
>     <body name="Puma6">
>       <offsetfrom>link6</offsetfrom>
>       <translation>0.10 0 0</translation>
>       <rotationaxis>0 1 0 90</rotationaxis>
>     </body>
>     <joint name="j6" type="hinge" enable="false">
>       <body>link6</body>
>       <body>Puma6</body>
>       <offsetfrom>Puma6</offsetfrom>
>       <limits>0 0</limits>
>     </joint>
>   </KinBody>
>   <Manipulator name="arm">
>     <effector>link6</effector>
>     <base>base</base>
>     <joints>m1</joints>
>     <!-- joint values of the closed and opened positions -->
>     <closingdirection>1</closingdirection>
>     <direction>0 0 1</direction>
>     <!-- grasp goal with respect to the effector -->
>     <Translation>0 0 0.175</Translation>
>   </Manipulator>
> </Robot>
>
> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE) and the
> last joint is indeed named "link6". I also tried setting the joint anchor
> but that had no effect. Do you have any suggestions?
>
> Thanks,
> Matthew
>
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Cc: [hidden email]
> Sent: Sunday, September 26, 2010 11:52:21 PM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> Hi Matthew,
>
> The <translation> tag sets the link transformations. The <anchor> tag
> sets the offset of the joint anchor axis. By default, the joint anchor
> is at the origin of the "offset link" specified. If you do not care
> about link transformations, then either <anchor> and <translation> can
> be interchanged.
>
> To debug your problem, first make sure the gripper is attached to the
> correct link. Make sure the "offset from" is correct.
>
> The ikfast program accepts transformations with respect to the base
> link of the manipulator specified. In order to debug your code, you'll
> notice that the cpp file also defines a forward kinematics function
> 'fk' that you can use to input joint angles to get the end effector
> transformation. Inserting this transformation back into the ik should
> give you a correct solution.
>
> good luck!
> rosen,
>
> 2010/9/27  <[hidden email]>:
>> Hi Rosen,
>>
>> Thanks for the fix before -- It worked out great.
>>
>> I'm now trying to do the same thing with the Kuka r850 robot: I modified
>> the
>> fixed XML file that you sent me by changing the first kinbody file to be
>> the
>> r850 kinbody as opposed to the r650 kinbody. However, when I visualize
>> this
>> in the environment, the Puma gripper appears at the base of the robot. In
>> addition, when running the example, I obtain the following: openrave
>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as to how
>> I
>> could proceed?
>>
>> Upon looking through the kuka850 kinbody and comparing it to that of 650,
>> I
>> noticed that the only differences were <anchor> being specified as opposed
>> to <translation> Could you explain the difference between these two
>> different ways of specifying the robot? I tried converting them to
>> equivalent translations but the r850 visualization had links floating at
>> unconnected positions in space.
>>
>> I have also used ikfast to compile a standalone C++ executable for the
>> r650
>> arm: Once compiled, I tried running it and got "Failed to get IK
>> solution."
>> Is this because the coordinates I've specified are not within range of the
>> robot? Is there a similar way of getting a standalone FK program as well
>> or
>> is it just implicitly included in the model?
>>
>> Thanks,
>> Matthew
>>
>> ----- Original Message -----
>> From: "Rosen Diankov" <[hidden email]>
>> To: "matt cong" <[hidden email]>
>> Cc: [hidden email]"
>> Sent: Sunday, September 12, 2010 7:56:53 PM
>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>>
>> Hi Matt,
>>
>> For your first example, you need to add a dummy joint  between one
>> link in the robot and one in the hand, otherwise they will not be
>> attached. You also need to add 'robots/' to the robot filenames
>> otherwise openrave will not be able to find the robots unless they are
>> inside the default robots directory. You also need to move the puma
>> gripper
>>
>> Here's the fix:
>>
>> <Robot name="Puma">
>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>   </KinBody>
>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>     <body name="Puma6">
>>       <offsetfrom>link6</offsetfrom>
>>       <translation>-0.03 0 0</translation>
>>       <rotationaxis>0 1 0 90</rotationaxis>
>>     </body>
>>     <!-- add a dummy joint -->
>>     <joint type="hinge" enable="false">
>>       <body>link6</body>
>>       <body>Puma6</body>
>>       <limits>0 0</limits>
>>     </joint>
>>   </KinBody>
>>   <Manipulator name="arm">
>>     <effector>link6</effector>
>>     <base>base</base>
>>     <joints>m1</joints>
>>     <!-- joint values of the closed and opened positions -->
>>     <closingdirection>1</closingdirection>
>>     <direction>0 0 1</direction>
>>     <!-- grasp goal with respect to the effector -->
>>     <Translation>0 0 0.175</Translation>
>>   </Manipulator>
>> </Robot>
>>
>>
>> As for the example on the wiki, you need to add a <Manipulator>
>> definition before using it.
>>
>> rosen,
>>
>>
>> 2010/9/13  <[hidden email]>:
>>> Hi Rosen,
>>>
>>> Thanks for the guidance on the ikfast and planner errors.
>>>
>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot. Since
>>> this arm does not have a gripper attached, I also attached the Puma
>>> gripper
>>> to the end of the robot as follows:
>>>
>>> <Robot name="Puma">
>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>     <KinBody file="pumagripper.kinbody.xml">
>>>     </KinBody>
>>>   </KinBody>
>>>   <Manipulator name="arm">
>>>     <effector>link6</effector>
>>>         <base>base</base>
>>>     <joints>m1</joints>
>>>     <!-- joint values of the closed and opened positions -->
>>>     <closingdirection>1</closingdirection>
>>>     <direction>0 0 1</direction>
>>>     <!-- grasp goal with respect to the effector -->
>>>     <Translation>0 0 0.175</Translation>
>>>   </Manipulator>
>>> </Robot>
>>>
>>> I tried to visualize this new environment using "openrave.py -p
>>> "env.Load('data/hanoi_complex.env.xml')" where hanoi_complex.env.xml has
>>> been modified to use the newly defined Kuka robot. However, I received
>>> the
>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy for
>>> number of joints 7! Part of robot might not be moveable"
>>>
>>> Did I make an error while defining the robot and linking up the different
>>> components such as not specifying an additional joint between the gripper
>>> and arm?
>>>
>>> In addition, I also tried working with the Kuka Collada example here:
>>> http://openrave.programmingvision.com/index.php/Started:Formats. I was
>>> able
>>> to visualize and generate the inverse kinematics successfully but when
>>> running the Hanoi example, it failed due to an assertion error from the
>>> following line: assert(len(jointinds)==len(jointvalues) and
>>> len(jointinds)>0). Is this related to the previous error?
>>>
>>> Thanks,
>>> Matthew
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Rosen Diankov" <[hidden email]>
>>> To: "matt cong" <[hidden email]>
>>> Cc: [hidden email]
>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>> example
>>>
>>> hi Matthew,
>>>
>>> Thanks for the patch, I updated openrave.rosinstall
>>>
>>> You can ignore the ikfast errors should not be printed since the puma
>>> arm has a pre-generated ik file. You can ignore them.
>>>
>>> The planner is randomized, so it can fail at times. This is why
>>> openrave calls it multiple times to guarantee a path is found if one
>>> exists.
>>>
>>> rosen,
>>>
>>> 2010/9/6  <[hidden email]>:
>>>> Hi,
>>>>
>>>> I installed OpenRAVE and ROS via the instructions listed here on Ubuntu
>>>> 10.04 x86_64:
>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>
>>>> One change that I made was adding the pr2_calibration stack to the
>>>> install
>>>> file since calibration_experimental complained that it wasn't present as
>>>> a
>>>> dependency when running "rosdep install orrosplanning rviz" The added
>>>> lines
>>>> are listed below.
>>>>
>>>> - svn:
>>>>     uri:
>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>     local-name: stacks/pr2_calibration
>>>>
>>>> I had a previous SVN-based ROS installation (boxturtle) -- However, I
>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>
>>>> When I go to run the Hanoi example using "openrave.py --example hanoi",
>>>> I
>>>> receive the following error:
>>>>
>>>> [ikfastproblem.h:206]
>>>>
>>>>
>>>>
>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>> cannot open shared object file: No such file or directory
>>>> [ikfastproblem.h:131] failed to load library
>>>>
>>>>
>>>>
>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>
>>>> Should I be concerned with this error? The example runs successfully and
>>>> terminates after the Towers of Hanoi problem is solved. There are also a
>>>> couple of errors during the program such as
>>>>
>>>> [rrt.h:283] plan failed, 3.478000s
>>>> [basemanipulation.h:867] PlanPath failed
>>>>
>>>> but I expect these are due to the arm using RRT for planning and a
>>>> solution
>>>> not being found within a certain number of iterations.
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net Dev2Dev email is sponsored by:
>>>>
>>>> Show off your parallel programming skills.
>>>> Enter the Intel(R) Threading Challenge 2010.
>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>> _______________________________________________
>>>> Openrave-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>
>>> _______________________________________________
>>> Openrave-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Openrave-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>
>>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>
>

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
hi Matthew,

Please remove the explicit iksolver tag, this forces a pre-compiled
ikfast solver to be used, which is why you are getting wrong results.
I'll see if we can add a warning message if this condition is ever
detected.

rosen,

2010/10/22  <[hidden email]>:

> Hi Rosen,
>
> Thanks for the advice. I was able to use ikfast to generate fk and ik for
> the Kuka robot after changing the anchor tags to translation tags. I
> verified that these gave correct solutions (such as the position of the
> end-effector with respect to the base in the world frame) by having it print
> out the positions returned by fk and ik.
>
> I defined a gripper (using the basic geometry types) and attached it to the
> robot in a similar way to how I attached the Puma gripper to the body of the
> Puma robot. However, when I regenerate the kinematics using ikfast and test
> them, I obtain the same results for the position of my end-effector as the
> configuration without the gripper (essentially without the additional length
> in the last link due to the gripper). Do you have some ideas as to how to
> resolve this? I noticed that the Puma has an explicitly specified iksolver:
> Is this needed when a manipulator is attached?
>
> Thanks,
> Matthew
>
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Cc: [hidden email]
> Sent: Monday, September 27, 2010 4:43:57 AM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> Hi Matt,
>
> The reason you are not seeing any change is because link6 of kuka-r850
> is at the origin of the robot. In fact, all links are at the origin,
> which can be confirmed by calling Link.GetTransform(). You were
> probably expecting link6 to be where the manipulator frame was
> defined.
>
> In any case, you have to change the translation of Puma6 to "0.56 0 0.79"
>
> rosen,
>
> 2010/9/27  <[hidden email]>:
>> Hi Rosen,
>>
>> Thank you once again for the prompt reply. It was very helpful.
>>
>> I looked at the XML again and it appears that the <offsetfrom> is set
>> correctly. However, when I do transformations, they are still relative to
>> the base which makes me think that an offsetfrom is spacified incorrectly.
>> Here's the file:
>>
>> <Robot name="Kuka">
>>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>>   </KinBody>
>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>     <body name="Puma6">
>>       <offsetfrom>link6</offsetfrom>
>>       <translation>0.10 0 0</translation>
>>       <rotationaxis>0 1 0 90</rotationaxis>
>>     </body>
>>     <joint name="j6" type="hinge" enable="false">
>>       <body>link6</body>
>>       <body>Puma6</body>
>>       <offsetfrom>Puma6</offsetfrom>
>>       <limits>0 0</limits>
>>     </joint>
>>   </KinBody>
>>   <Manipulator name="arm">
>>     <effector>link6</effector>
>>     <base>base</base>
>>     <joints>m1</joints>
>>     <!-- joint values of the closed and opened positions -->
>>     <closingdirection>1</closingdirection>
>>     <direction>0 0 1</direction>
>>     <!-- grasp goal with respect to the effector -->
>>     <Translation>0 0 0.175</Translation>
>>   </Manipulator>
>> </Robot>
>>
>> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE) and
>> the
>> last joint is indeed named "link6". I also tried setting the joint anchor
>> but that had no effect. Do you have any suggestions?
>>
>> Thanks,
>> Matthew
>>
>> ----- Original Message -----
>> From: "Rosen Diankov" <[hidden email]>
>> To: "matt cong" <[hidden email]>
>> Cc: [hidden email]
>> Sent: Sunday, September 26, 2010 11:52:21 PM
>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>>
>> Hi Matthew,
>>
>> The <translation> tag sets the link transformations. The <anchor> tag
>> sets the offset of the joint anchor axis. By default, the joint anchor
>> is at the origin of the "offset link" specified. If you do not care
>> about link transformations, then either <anchor> and <translation> can
>> be interchanged.
>>
>> To debug your problem, first make sure the gripper is attached to the
>> correct link. Make sure the "offset from" is correct.
>>
>> The ikfast program accepts transformations with respect to the base
>> link of the manipulator specified. In order to debug your code, you'll
>> notice that the cpp file also defines a forward kinematics function
>> 'fk' that you can use to input joint angles to get the end effector
>> transformation. Inserting this transformation back into the ik should
>> give you a correct solution.
>>
>> good luck!
>> rosen,
>>
>> 2010/9/27  <[hidden email]>:
>>> Hi Rosen,
>>>
>>> Thanks for the fix before -- It worked out great.
>>>
>>> I'm now trying to do the same thing with the Kuka r850 robot: I modified
>>> the
>>> fixed XML file that you sent me by changing the first kinbody file to be
>>> the
>>> r850 kinbody as opposed to the r650 kinbody. However, when I visualize
>>> this
>>> in the environment, the Puma gripper appears at the base of the robot. In
>>> addition, when running the example, I obtain the following: openrave
>>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as to how
>>> I
>>> could proceed?
>>>
>>> Upon looking through the kuka850 kinbody and comparing it to that of 650,
>>> I
>>> noticed that the only differences were <anchor> being specified as
>>> opposed
>>> to <translation> Could you explain the difference between these two
>>> different ways of specifying the robot? I tried converting them to
>>> equivalent translations but the r850 visualization had links floating at
>>> unconnected positions in space.
>>>
>>> I have also used ikfast to compile a standalone C++ executable for the
>>> r650
>>> arm: Once compiled, I tried running it and got "Failed to get IK
>>> solution."
>>> Is this because the coordinates I've specified are not within range of
>>> the
>>> robot? Is there a similar way of getting a standalone FK program as well
>>> or
>>> is it just implicitly included in the model?
>>>
>>> Thanks,
>>> Matthew
>>>
>>> ----- Original Message -----
>>> From: "Rosen Diankov" <[hidden email]>
>>> To: "matt cong" <[hidden email]>
>>> Cc: [hidden email]"
>>> Sent: Sunday, September 12, 2010 7:56:53 PM
>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>> example
>>>
>>> Hi Matt,
>>>
>>> For your first example, you need to add a dummy joint  between one
>>> link in the robot and one in the hand, otherwise they will not be
>>> attached. You also need to add 'robots/' to the robot filenames
>>> otherwise openrave will not be able to find the robots unless they are
>>> inside the default robots directory. You also need to move the puma
>>> gripper
>>>
>>> Here's the fix:
>>>
>>> <Robot name="Puma">
>>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>>   </KinBody>
>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>     <body name="Puma6">
>>>       <offsetfrom>link6</offsetfrom>
>>>       <translation>-0.03 0 0</translation>
>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>     </body>
>>>     <!-- add a dummy joint -->
>>>     <joint type="hinge" enable="false">
>>>       <body>link6</body>
>>>       <body>Puma6</body>
>>>       <limits>0 0</limits>
>>>     </joint>
>>>   </KinBody>
>>>   <Manipulator name="arm">
>>>     <effector>link6</effector>
>>>     <base>base</base>
>>>     <joints>m1</joints>
>>>     <!-- joint values of the closed and opened positions -->
>>>     <closingdirection>1</closingdirection>
>>>     <direction>0 0 1</direction>
>>>     <!-- grasp goal with respect to the effector -->
>>>     <Translation>0 0 0.175</Translation>
>>>   </Manipulator>
>>> </Robot>
>>>
>>>
>>> As for the example on the wiki, you need to add a <Manipulator>
>>> definition before using it.
>>>
>>> rosen,
>>>
>>>
>>> 2010/9/13  <[hidden email]>:
>>>> Hi Rosen,
>>>>
>>>> Thanks for the guidance on the ikfast and planner errors.
>>>>
>>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot. Since
>>>> this arm does not have a gripper attached, I also attached the Puma
>>>> gripper
>>>> to the end of the robot as follows:
>>>>
>>>> <Robot name="Puma">
>>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>>     <KinBody file="pumagripper.kinbody.xml">
>>>>     </KinBody>
>>>>   </KinBody>
>>>>   <Manipulator name="arm">
>>>>     <effector>link6</effector>
>>>>         <base>base</base>
>>>>     <joints>m1</joints>
>>>>     <!-- joint values of the closed and opened positions -->
>>>>     <closingdirection>1</closingdirection>
>>>>     <direction>0 0 1</direction>
>>>>     <!-- grasp goal with respect to the effector -->
>>>>     <Translation>0 0 0.175</Translation>
>>>>   </Manipulator>
>>>> </Robot>
>>>>
>>>> I tried to visualize this new environment using "openrave.py -p
>>>> "env.Load('data/hanoi_complex.env.xml')" where hanoi_complex.env.xml has
>>>> been modified to use the newly defined Kuka robot. However, I received
>>>> the
>>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy for
>>>> number of joints 7! Part of robot might not be moveable"
>>>>
>>>> Did I make an error while defining the robot and linking up the
>>>> different
>>>> components such as not specifying an additional joint between the
>>>> gripper
>>>> and arm?
>>>>
>>>> In addition, I also tried working with the Kuka Collada example here:
>>>> http://openrave.programmingvision.com/index.php/Started:Formats. I was
>>>> able
>>>> to visualize and generate the inverse kinematics successfully but when
>>>> running the Hanoi example, it failed due to an assertion error from the
>>>> following line: assert(len(jointinds)==len(jointvalues) and
>>>> len(jointinds)>0). Is this related to the previous error?
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Rosen Diankov" <[hidden email]>
>>>> To: "matt cong" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>> example
>>>>
>>>> hi Matthew,
>>>>
>>>> Thanks for the patch, I updated openrave.rosinstall
>>>>
>>>> You can ignore the ikfast errors should not be printed since the puma
>>>> arm has a pre-generated ik file. You can ignore them.
>>>>
>>>> The planner is randomized, so it can fail at times. This is why
>>>> openrave calls it multiple times to guarantee a path is found if one
>>>> exists.
>>>>
>>>> rosen,
>>>>
>>>> 2010/9/6  <[hidden email]>:
>>>>> Hi,
>>>>>
>>>>> I installed OpenRAVE and ROS via the instructions listed here on Ubuntu
>>>>> 10.04 x86_64:
>>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>>
>>>>> One change that I made was adding the pr2_calibration stack to the
>>>>> install
>>>>> file since calibration_experimental complained that it wasn't present
>>>>> as
>>>>> a
>>>>> dependency when running "rosdep install orrosplanning rviz" The added
>>>>> lines
>>>>> are listed below.
>>>>>
>>>>> - svn:
>>>>>     uri:
>>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>>     local-name: stacks/pr2_calibration
>>>>>
>>>>> I had a previous SVN-based ROS installation (boxturtle) -- However, I
>>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>>
>>>>> When I go to run the Hanoi example using "openrave.py --example hanoi",
>>>>> I
>>>>> receive the following error:
>>>>>
>>>>> [ikfastproblem.h:206]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>>> cannot open shared object file: No such file or directory
>>>>> [ikfastproblem.h:131] failed to load library
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>>
>>>>> Should I be concerned with this error? The example runs successfully
>>>>> and
>>>>> terminates after the Towers of Hanoi problem is solved. There are also
>>>>> a
>>>>> couple of errors during the program such as
>>>>>
>>>>> [rrt.h:283] plan failed, 3.478000s
>>>>> [basemanipulation.h:867] PlanPath failed
>>>>>
>>>>> but I expect these are due to the arm using RRT for planning and a
>>>>> solution
>>>>> not being found within a certain number of iterations.
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net Dev2Dev email is sponsored by:
>>>>>
>>>>> Show off your parallel programming skills.
>>>>> Enter the Intel(R) Threading Challenge 2010.
>>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>>> _______________________________________________
>>>>> Openrave-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Start uncovering the many advantages of virtual appliances
>>>> and start using them to simplify application deployment and
>>>> accelerate your shift to cloud computing
>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>
>>>> _______________________________________________
>>>> Openrave-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> _______________________________________________
>>> Openrave-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Openrave-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>
>>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>
>

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

matt.cong
In reply to this post by matt.cong
Hi Rosen,

Thanks for the suggestion. However, I did not include the explicit iksolver tag when defining a new robot (which is very similar to the Kuka) from the gripper and robot body kinbody files. Sorry for being unclear.

I checked the <offsetfrom> tags for each link in the kinbody files as well as the robot file. In addition, when I visualized the stationary model in an environment, the gripper was in the correct position. I also noticed the <effector> tag in the manipulator was set to the end effector of the main robot body but when I changed it to the new end effector body on the gripper (one of the two claws on the gripper), ikfast said that it could not divide rotation and translation after trying to take the inverse of the mechanism.

Thanks,
Matthew

----- Original Message -----
From: "Rosen Diankov" <[hidden email]>
To: "matt cong" <[hidden email]>
Cc: [hidden email]
Sent: Thursday, October 21, 2010 9:54:56 PM
Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example

hi Matthew,

Please remove the explicit iksolver tag, this forces a pre-compiled
ikfast solver to be used, which is why you are getting wrong results.
I'll see if we can add a warning message if this condition is ever
detected.

rosen,

2010/10/22  <[hidden email]>:

> Hi Rosen,
>
> Thanks for the advice. I was able to use ikfast to generate fk and ik for
> the Kuka robot after changing the anchor tags to translation tags. I
> verified that these gave correct solutions (such as the position of the
> end-effector with respect to the base in the world frame) by having it print
> out the positions returned by fk and ik.
>
> I defined a gripper (using the basic geometry types) and attached it to the
> robot in a similar way to how I attached the Puma gripper to the body of the
> Puma robot. However, when I regenerate the kinematics using ikfast and test
> them, I obtain the same results for the position of my end-effector as the
> configuration without the gripper (essentially without the additional length
> in the last link due to the gripper). Do you have some ideas as to how to
> resolve this? I noticed that the Puma has an explicitly specified iksolver:
> Is this needed when a manipulator is attached?
>
> Thanks,
> Matthew
>
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Cc: [hidden email]
> Sent: Monday, September 27, 2010 4:43:57 AM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> Hi Matt,
>
> The reason you are not seeing any change is because link6 of kuka-r850
> is at the origin of the robot. In fact, all links are at the origin,
> which can be confirmed by calling Link.GetTransform(). You were
> probably expecting link6 to be where the manipulator frame was
> defined.
>
> In any case, you have to change the translation of Puma6 to "0.56 0 0.79"
>
> rosen,
>
> 2010/9/27  <[hidden email]>:
>> Hi Rosen,
>>
>> Thank you once again for the prompt reply. It was very helpful.
>>
>> I looked at the XML again and it appears that the <offsetfrom> is set
>> correctly. However, when I do transformations, they are still relative to
>> the base which makes me think that an offsetfrom is spacified incorrectly.
>> Here's the file:
>>
>> <Robot name="Kuka">
>>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>>   </KinBody>
>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>     <body name="Puma6">
>>       <offsetfrom>link6</offsetfrom>
>>       <translation>0.10 0 0</translation>
>>       <rotationaxis>0 1 0 90</rotationaxis>
>>     </body>
>>     <joint name="j6" type="hinge" enable="false">
>>       <body>link6</body>
>>       <body>Puma6</body>
>>       <offsetfrom>Puma6</offsetfrom>
>>       <limits>0 0</limits>
>>     </joint>
>>   </KinBody>
>>   <Manipulator name="arm">
>>     <effector>link6</effector>
>>     <base>base</base>
>>     <joints>m1</joints>
>>     <!-- joint values of the closed and opened positions -->
>>     <closingdirection>1</closingdirection>
>>     <direction>0 0 1</direction>
>>     <!-- grasp goal with respect to the effector -->
>>     <Translation>0 0 0.175</Translation>
>>   </Manipulator>
>> </Robot>
>>
>> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE) and
>> the
>> last joint is indeed named "link6". I also tried setting the joint anchor
>> but that had no effect. Do you have any suggestions?
>>
>> Thanks,
>> Matthew
>>
>> ----- Original Message -----
>> From: "Rosen Diankov" <[hidden email]>
>> To: "matt cong" <[hidden email]>
>> Cc: [hidden email]
>> Sent: Sunday, September 26, 2010 11:52:21 PM
>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>>
>> Hi Matthew,
>>
>> The <translation> tag sets the link transformations. The <anchor> tag
>> sets the offset of the joint anchor axis. By default, the joint anchor
>> is at the origin of the "offset link" specified. If you do not care
>> about link transformations, then either <anchor> and <translation> can
>> be interchanged.
>>
>> To debug your problem, first make sure the gripper is attached to the
>> correct link. Make sure the "offset from" is correct.
>>
>> The ikfast program accepts transformations with respect to the base
>> link of the manipulator specified. In order to debug your code, you'll
>> notice that the cpp file also defines a forward kinematics function
>> 'fk' that you can use to input joint angles to get the end effector
>> transformation. Inserting this transformation back into the ik should
>> give you a correct solution.
>>
>> good luck!
>> rosen,
>>
>> 2010/9/27  <[hidden email]>:
>>> Hi Rosen,
>>>
>>> Thanks for the fix before -- It worked out great.
>>>
>>> I'm now trying to do the same thing with the Kuka r850 robot: I modified
>>> the
>>> fixed XML file that you sent me by changing the first kinbody file to be
>>> the
>>> r850 kinbody as opposed to the r650 kinbody. However, when I visualize
>>> this
>>> in the environment, the Puma gripper appears at the base of the robot. In
>>> addition, when running the example, I obtain the following: openrave
>>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as to how
>>> I
>>> could proceed?
>>>
>>> Upon looking through the kuka850 kinbody and comparing it to that of 650,
>>> I
>>> noticed that the only differences were <anchor> being specified as
>>> opposed
>>> to <translation> Could you explain the difference between these two
>>> different ways of specifying the robot? I tried converting them to
>>> equivalent translations but the r850 visualization had links floating at
>>> unconnected positions in space.
>>>
>>> I have also used ikfast to compile a standalone C++ executable for the
>>> r650
>>> arm: Once compiled, I tried running it and got "Failed to get IK
>>> solution."
>>> Is this because the coordinates I've specified are not within range of
>>> the
>>> robot? Is there a similar way of getting a standalone FK program as well
>>> or
>>> is it just implicitly included in the model?
>>>
>>> Thanks,
>>> Matthew
>>>
>>> ----- Original Message -----
>>> From: "Rosen Diankov" <[hidden email]>
>>> To: "matt cong" <[hidden email]>
>>> Cc: [hidden email]"
>>> Sent: Sunday, September 12, 2010 7:56:53 PM
>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>> example
>>>
>>> Hi Matt,
>>>
>>> For your first example, you need to add a dummy joint  between one
>>> link in the robot and one in the hand, otherwise they will not be
>>> attached. You also need to add 'robots/' to the robot filenames
>>> otherwise openrave will not be able to find the robots unless they are
>>> inside the default robots directory. You also need to move the puma
>>> gripper
>>>
>>> Here's the fix:
>>>
>>> <Robot name="Puma">
>>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>>   </KinBody>
>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>     <body name="Puma6">
>>>       <offsetfrom>link6</offsetfrom>
>>>       <translation>-0.03 0 0</translation>
>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>     </body>
>>>     <!-- add a dummy joint -->
>>>     <joint type="hinge" enable="false">
>>>       <body>link6</body>
>>>       <body>Puma6</body>
>>>       <limits>0 0</limits>
>>>     </joint>
>>>   </KinBody>
>>>   <Manipulator name="arm">
>>>     <effector>link6</effector>
>>>     <base>base</base>
>>>     <joints>m1</joints>
>>>     <!-- joint values of the closed and opened positions -->
>>>     <closingdirection>1</closingdirection>
>>>     <direction>0 0 1</direction>
>>>     <!-- grasp goal with respect to the effector -->
>>>     <Translation>0 0 0.175</Translation>
>>>   </Manipulator>
>>> </Robot>
>>>
>>>
>>> As for the example on the wiki, you need to add a <Manipulator>
>>> definition before using it.
>>>
>>> rosen,
>>>
>>>
>>> 2010/9/13  <[hidden email]>:
>>>> Hi Rosen,
>>>>
>>>> Thanks for the guidance on the ikfast and planner errors.
>>>>
>>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot. Since
>>>> this arm does not have a gripper attached, I also attached the Puma
>>>> gripper
>>>> to the end of the robot as follows:
>>>>
>>>> <Robot name="Puma">
>>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>>     <KinBody file="pumagripper.kinbody.xml">
>>>>     </KinBody>
>>>>   </KinBody>
>>>>   <Manipulator name="arm">
>>>>     <effector>link6</effector>
>>>>         <base>base</base>
>>>>     <joints>m1</joints>
>>>>     <!-- joint values of the closed and opened positions -->
>>>>     <closingdirection>1</closingdirection>
>>>>     <direction>0 0 1</direction>
>>>>     <!-- grasp goal with respect to the effector -->
>>>>     <Translation>0 0 0.175</Translation>
>>>>   </Manipulator>
>>>> </Robot>
>>>>
>>>> I tried to visualize this new environment using "openrave.py -p
>>>> "env.Load('data/hanoi_complex.env.xml')" where hanoi_complex.env.xml has
>>>> been modified to use the newly defined Kuka robot. However, I received
>>>> the
>>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy for
>>>> number of joints 7! Part of robot might not be moveable"
>>>>
>>>> Did I make an error while defining the robot and linking up the
>>>> different
>>>> components such as not specifying an additional joint between the
>>>> gripper
>>>> and arm?
>>>>
>>>> In addition, I also tried working with the Kuka Collada example here:
>>>> http://openrave.programmingvision.com/index.php/Started:Formats. I was
>>>> able
>>>> to visualize and generate the inverse kinematics successfully but when
>>>> running the Hanoi example, it failed due to an assertion error from the
>>>> following line: assert(len(jointinds)==len(jointvalues) and
>>>> len(jointinds)>0). Is this related to the previous error?
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Rosen Diankov" <[hidden email]>
>>>> To: "matt cong" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>> example
>>>>
>>>> hi Matthew,
>>>>
>>>> Thanks for the patch, I updated openrave.rosinstall
>>>>
>>>> You can ignore the ikfast errors should not be printed since the puma
>>>> arm has a pre-generated ik file. You can ignore them.
>>>>
>>>> The planner is randomized, so it can fail at times. This is why
>>>> openrave calls it multiple times to guarantee a path is found if one
>>>> exists.
>>>>
>>>> rosen,
>>>>
>>>> 2010/9/6  <[hidden email]>:
>>>>> Hi,
>>>>>
>>>>> I installed OpenRAVE and ROS via the instructions listed here on Ubuntu
>>>>> 10.04 x86_64:
>>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>>
>>>>> One change that I made was adding the pr2_calibration stack to the
>>>>> install
>>>>> file since calibration_experimental complained that it wasn't present
>>>>> as
>>>>> a
>>>>> dependency when running "rosdep install orrosplanning rviz" The added
>>>>> lines
>>>>> are listed below.
>>>>>
>>>>> - svn:
>>>>>     uri:
>>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>>     local-name: stacks/pr2_calibration
>>>>>
>>>>> I had a previous SVN-based ROS installation (boxturtle) -- However, I
>>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>>
>>>>> When I go to run the Hanoi example using "openrave.py --example hanoi",
>>>>> I
>>>>> receive the following error:
>>>>>
>>>>> [ikfastproblem.h:206]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>>> cannot open shared object file: No such file or directory
>>>>> [ikfastproblem.h:131] failed to load library
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>>
>>>>> Should I be concerned with this error? The example runs successfully
>>>>> and
>>>>> terminates after the Towers of Hanoi problem is solved. There are also
>>>>> a
>>>>> couple of errors during the program such as
>>>>>
>>>>> [rrt.h:283] plan failed, 3.478000s
>>>>> [basemanipulation.h:867] PlanPath failed
>>>>>
>>>>> but I expect these are due to the arm using RRT for planning and a
>>>>> solution
>>>>> not being found within a certain number of iterations.
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net Dev2Dev email is sponsored by:
>>>>>
>>>>> Show off your parallel programming skills.
>>>>> Enter the Intel(R) Threading Challenge 2010.
>>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>>> _______________________________________________
>>>>> Openrave-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Start uncovering the many advantages of virtual appliances
>>>> and start using them to simplify application deployment and
>>>> accelerate your shift to cloud computing
>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>
>>>> _______________________________________________
>>>> Openrave-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> _______________________________________________
>>> Openrave-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Openrave-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>
>>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>
>

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
hi matthew,

Setting the <effector> to one of the claws includes the claw joint as
part of the arm, which makes things a little more difficult (you can
still compute the ik if you set the claw as the free parameter).
However, it is ok to set the <effector> to the main body.

In any case, you shouldn't be experiencing these problems, please send
your robot file.
rosen,

2010/10/22  <[hidden email]>:

> Hi Rosen,
>
> Thanks for the suggestion. However, I did not include the explicit iksolver
> tag when defining a new robot (which is very similar to the Kuka) from the
> gripper and robot body kinbody files. Sorry for being unclear.
>
> I checked the <offsetfrom> tags for each link in the kinbody files as well
> as the robot file. In addition, when I visualized the stationary model in an
> environment, the gripper was in the correct position. I also noticed the
> <effector> tag in the manipulator was set to the end effector of the main
> robot body but when I changed it to the new end effector body on the gripper
> (one of the two claws on the gripper), ikfast said that it could not divide
> rotation and translation after trying to take the inverse of the mechanism.
>
> Thanks,
> Matthew
>
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Cc: [hidden email]
> Sent: Thursday, October 21, 2010 9:54:56 PM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> hi Matthew,
>
> Please remove the explicit iksolver tag, this forces a pre-compiled
> ikfast solver to be used, which is why you are getting wrong results.
> I'll see if we can add a warning message if this condition is ever
> detected.
>
> rosen,
>
> 2010/10/22  <[hidden email]>:
>> Hi Rosen,
>>
>> Thanks for the advice. I was able to use ikfast to generate fk and ik for
>> the Kuka robot after changing the anchor tags to translation tags. I
>> verified that these gave correct solutions (such as the position of the
>> end-effector with respect to the base in the world frame) by having it
>> print
>> out the positions returned by fk and ik.
>>
>> I defined a gripper (using the basic geometry types) and attached it to
>> the
>> robot in a similar way to how I attached the Puma gripper to the body of
>> the
>> Puma robot. However, when I regenerate the kinematics using ikfast and
>> test
>> them, I obtain the same results for the position of my end-effector as the
>> configuration without the gripper (essentially without the additional
>> length
>> in the last link due to the gripper). Do you have some ideas as to how to
>> resolve this? I noticed that the Puma has an explicitly specified
>> iksolver:
>> Is this needed when a manipulator is attached?
>>
>> Thanks,
>> Matthew
>>
>> ----- Original Message -----
>> From: "Rosen Diankov" <[hidden email]>
>> To: "matt cong" <[hidden email]>
>> Cc: [hidden email]
>> Sent: Monday, September 27, 2010 4:43:57 AM
>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>>
>> Hi Matt,
>>
>> The reason you are not seeing any change is because link6 of kuka-r850
>> is at the origin of the robot. In fact, all links are at the origin,
>> which can be confirmed by calling Link.GetTransform(). You were
>> probably expecting link6 to be where the manipulator frame was
>> defined.
>>
>> In any case, you have to change the translation of Puma6 to "0.56 0 0.79"
>>
>> rosen,
>>
>> 2010/9/27  <[hidden email]>:
>>> Hi Rosen,
>>>
>>> Thank you once again for the prompt reply. It was very helpful.
>>>
>>> I looked at the XML again and it appears that the <offsetfrom> is set
>>> correctly. However, when I do transformations, they are still relative to
>>> the base which makes me think that an offsetfrom is spacified
>>> incorrectly.
>>> Here's the file:
>>>
>>> <Robot name="Kuka">
>>>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>>>   </KinBody>
>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>     <body name="Puma6">
>>>       <offsetfrom>link6</offsetfrom>
>>>       <translation>0.10 0 0</translation>
>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>     </body>
>>>     <joint name="j6" type="hinge" enable="false">
>>>       <body>link6</body>
>>>       <body>Puma6</body>
>>>       <offsetfrom>Puma6</offsetfrom>
>>>       <limits>0 0</limits>
>>>     </joint>
>>>   </KinBody>
>>>   <Manipulator name="arm">
>>>     <effector>link6</effector>
>>>     <base>base</base>
>>>     <joints>m1</joints>
>>>     <!-- joint values of the closed and opened positions -->
>>>     <closingdirection>1</closingdirection>
>>>     <direction>0 0 1</direction>
>>>     <!-- grasp goal with respect to the effector -->
>>>     <Translation>0 0 0.175</Translation>
>>>   </Manipulator>
>>> </Robot>
>>>
>>> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE) and
>>> the
>>> last joint is indeed named "link6". I also tried setting the joint anchor
>>> but that had no effect. Do you have any suggestions?
>>>
>>> Thanks,
>>> Matthew
>>>
>>> ----- Original Message -----
>>> From: "Rosen Diankov" <[hidden email]>
>>> To: "matt cong" <[hidden email]>
>>> Cc: [hidden email]
>>> Sent: Sunday, September 26, 2010 11:52:21 PM
>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>> example
>>>
>>> Hi Matthew,
>>>
>>> The <translation> tag sets the link transformations. The <anchor> tag
>>> sets the offset of the joint anchor axis. By default, the joint anchor
>>> is at the origin of the "offset link" specified. If you do not care
>>> about link transformations, then either <anchor> and <translation> can
>>> be interchanged.
>>>
>>> To debug your problem, first make sure the gripper is attached to the
>>> correct link. Make sure the "offset from" is correct.
>>>
>>> The ikfast program accepts transformations with respect to the base
>>> link of the manipulator specified. In order to debug your code, you'll
>>> notice that the cpp file also defines a forward kinematics function
>>> 'fk' that you can use to input joint angles to get the end effector
>>> transformation. Inserting this transformation back into the ik should
>>> give you a correct solution.
>>>
>>> good luck!
>>> rosen,
>>>
>>> 2010/9/27  <[hidden email]>:
>>>> Hi Rosen,
>>>>
>>>> Thanks for the fix before -- It worked out great.
>>>>
>>>> I'm now trying to do the same thing with the Kuka r850 robot: I modified
>>>> the
>>>> fixed XML file that you sent me by changing the first kinbody file to be
>>>> the
>>>> r850 kinbody as opposed to the r650 kinbody. However, when I visualize
>>>> this
>>>> in the environment, the Puma gripper appears at the base of the robot.
>>>> In
>>>> addition, when running the example, I obtain the following: openrave
>>>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as to
>>>> how
>>>> I
>>>> could proceed?
>>>>
>>>> Upon looking through the kuka850 kinbody and comparing it to that of
>>>> 650,
>>>> I
>>>> noticed that the only differences were <anchor> being specified as
>>>> opposed
>>>> to <translation> Could you explain the difference between these two
>>>> different ways of specifying the robot? I tried converting them to
>>>> equivalent translations but the r850 visualization had links floating at
>>>> unconnected positions in space.
>>>>
>>>> I have also used ikfast to compile a standalone C++ executable for the
>>>> r650
>>>> arm: Once compiled, I tried running it and got "Failed to get IK
>>>> solution."
>>>> Is this because the coordinates I've specified are not within range of
>>>> the
>>>> robot? Is there a similar way of getting a standalone FK program as well
>>>> or
>>>> is it just implicitly included in the model?
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>> ----- Original Message -----
>>>> From: "Rosen Diankov" <[hidden email]>
>>>> To: "matt cong" <[hidden email]>
>>>> Cc: [hidden email]"
>>>> Sent: Sunday, September 12, 2010 7:56:53 PM
>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>> example
>>>>
>>>> Hi Matt,
>>>>
>>>> For your first example, you need to add a dummy joint  between one
>>>> link in the robot and one in the hand, otherwise they will not be
>>>> attached. You also need to add 'robots/' to the robot filenames
>>>> otherwise openrave will not be able to find the robots unless they are
>>>> inside the default robots directory. You also need to move the puma
>>>> gripper
>>>>
>>>> Here's the fix:
>>>>
>>>> <Robot name="Puma">
>>>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>>>   </KinBody>
>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>     <body name="Puma6">
>>>>       <offsetfrom>link6</offsetfrom>
>>>>       <translation>-0.03 0 0</translation>
>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>     </body>
>>>>     <!-- add a dummy joint -->
>>>>     <joint type="hinge" enable="false">
>>>>       <body>link6</body>
>>>>       <body>Puma6</body>
>>>>       <limits>0 0</limits>
>>>>     </joint>
>>>>   </KinBody>
>>>>   <Manipulator name="arm">
>>>>     <effector>link6</effector>
>>>>     <base>base</base>
>>>>     <joints>m1</joints>
>>>>     <!-- joint values of the closed and opened positions -->
>>>>     <closingdirection>1</closingdirection>
>>>>     <direction>0 0 1</direction>
>>>>     <!-- grasp goal with respect to the effector -->
>>>>     <Translation>0 0 0.175</Translation>
>>>>   </Manipulator>
>>>> </Robot>
>>>>
>>>>
>>>> As for the example on the wiki, you need to add a <Manipulator>
>>>> definition before using it.
>>>>
>>>> rosen,
>>>>
>>>>
>>>> 2010/9/13  <[hidden email]>:
>>>>> Hi Rosen,
>>>>>
>>>>> Thanks for the guidance on the ikfast and planner errors.
>>>>>
>>>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot.
>>>>> Since
>>>>> this arm does not have a gripper attached, I also attached the Puma
>>>>> gripper
>>>>> to the end of the robot as follows:
>>>>>
>>>>> <Robot name="Puma">
>>>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>>>     <KinBody file="pumagripper.kinbody.xml">
>>>>>     </KinBody>
>>>>>   </KinBody>
>>>>>   <Manipulator name="arm">
>>>>>     <effector>link6</effector>
>>>>>         <base>base</base>
>>>>>     <joints>m1</joints>
>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>     <closingdirection>1</closingdirection>
>>>>>     <direction>0 0 1</direction>
>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>     <Translation>0 0 0.175</Translation>
>>>>>   </Manipulator>
>>>>> </Robot>
>>>>>
>>>>> I tried to visualize this new environment using "openrave.py -p
>>>>> "env.Load('data/hanoi_complex.env.xml')" where hanoi_complex.env.xml
>>>>> has
>>>>> been modified to use the newly defined Kuka robot. However, I received
>>>>> the
>>>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy for
>>>>> number of joints 7! Part of robot might not be moveable"
>>>>>
>>>>> Did I make an error while defining the robot and linking up the
>>>>> different
>>>>> components such as not specifying an additional joint between the
>>>>> gripper
>>>>> and arm?
>>>>>
>>>>> In addition, I also tried working with the Kuka Collada example here:
>>>>> http://openrave.programmingvision.com/index.php/Started:Formats. I was
>>>>> able
>>>>> to visualize and generate the inverse kinematics successfully but when
>>>>> running the Hanoi example, it failed due to an assertion error from the
>>>>> following line: assert(len(jointinds)==len(jointvalues) and
>>>>> len(jointinds)>0). Is this related to the previous error?
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>> To: "matt cong" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>> example
>>>>>
>>>>> hi Matthew,
>>>>>
>>>>> Thanks for the patch, I updated openrave.rosinstall
>>>>>
>>>>> You can ignore the ikfast errors should not be printed since the puma
>>>>> arm has a pre-generated ik file. You can ignore them.
>>>>>
>>>>> The planner is randomized, so it can fail at times. This is why
>>>>> openrave calls it multiple times to guarantee a path is found if one
>>>>> exists.
>>>>>
>>>>> rosen,
>>>>>
>>>>> 2010/9/6  <[hidden email]>:
>>>>>> Hi,
>>>>>>
>>>>>> I installed OpenRAVE and ROS via the instructions listed here on
>>>>>> Ubuntu
>>>>>> 10.04 x86_64:
>>>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>>>
>>>>>> One change that I made was adding the pr2_calibration stack to the
>>>>>> install
>>>>>> file since calibration_experimental complained that it wasn't present
>>>>>> as
>>>>>> a
>>>>>> dependency when running "rosdep install orrosplanning rviz" The added
>>>>>> lines
>>>>>> are listed below.
>>>>>>
>>>>>> - svn:
>>>>>>     uri:
>>>>>>
>>>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>>>     local-name: stacks/pr2_calibration
>>>>>>
>>>>>> I had a previous SVN-based ROS installation (boxturtle) -- However, I
>>>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>>>
>>>>>> When I go to run the Hanoi example using "openrave.py --example
>>>>>> hanoi",
>>>>>> I
>>>>>> receive the following error:
>>>>>>
>>>>>> [ikfastproblem.h:206]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>>>> cannot open shared object file: No such file or directory
>>>>>> [ikfastproblem.h:131] failed to load library
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>>>
>>>>>> Should I be concerned with this error? The example runs successfully
>>>>>> and
>>>>>> terminates after the Towers of Hanoi problem is solved. There are also
>>>>>> a
>>>>>> couple of errors during the program such as
>>>>>>
>>>>>> [rrt.h:283] plan failed, 3.478000s
>>>>>> [basemanipulation.h:867] PlanPath failed
>>>>>>
>>>>>> but I expect these are due to the arm using RRT for planning and a
>>>>>> solution
>>>>>> not being found within a certain number of iterations.
>>>>>>
>>>>>> Thanks,
>>>>>> Matthew
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> This SF.net Dev2Dev email is sponsored by:
>>>>>>
>>>>>> Show off your parallel programming skills.
>>>>>> Enter the Intel(R) Threading Challenge 2010.
>>>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>>>> _______________________________________________
>>>>>> Openrave-users mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Start uncovering the many advantages of virtual appliances
>>>>> and start using them to simplify application deployment and
>>>>> accelerate your shift to cloud computing
>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>
>>>>> _______________________________________________
>>>>> Openrave-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Start uncovering the many advantages of virtual appliances
>>>> and start using them to simplify application deployment and
>>>> accelerate your shift to cloud computing.
>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>> _______________________________________________
>>>> Openrave-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> _______________________________________________
>>> Openrave-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>> contest
>> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>> marketing
>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>> http://p.sf.net/sfu/nokia-dev2dev
>> _______________________________________________
>> Openrave-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>
>>
>

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
In reply to this post by matt.cong
hi matthew,

i see, you are using the generated C++ files as is without the
openrave wrappers. Up the one week ago, the C++ files did not encode
the grasp frame, it was premultiplied on the openrave side. However,
this week I updated ikfast to incorporate grasp frame also. Can you
try updating to the newest openrave and regenerate the ik?

Also, kinematics are independent of geometry. the 'fk' function gives
coordinates of the gripper frame with respect to the base link, 'ik'
function takes coordinates of the gripper frame with respect to the
baselink.

rosen,

2010/10/22  <[hidden email]>:

> Hi Rosen,
>
> Thank you for your help. I have attached the test scripts. They mostly do
> conversions to ypr and degrees along with some adjustments for differing
> conventions on the starting point of the robot, but these are all minor.
>
> Is it possible that the geometry is connected with the IK problems? I was
> operating under the assumption that the meshes were only related to the
> visual display, but I may have been wrong. Also, does the IK/FK give
> coordinates with respect to the base of the robot or the starting position
> of the end effector?
>
> Thanks,
> Matthew
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Sent: Friday, October 22, 2010 1:11:12 AM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> either way, executing the following command to test the ik:
>
>  openrave.py --database inversekinematics
> --robot=adeptComplete.robot.xml  --iktest=100
>
>
> gives 100% success rate, so everything is working fine... perhaps
> there is some misunderstanding on how the ik functions work... can you
> send the test scripts you are using?
>
> rosen,
>
> 2010/10/22 Rosen Diankov <[hidden email]>:
>> robot geometry looks broken...
>> rosen,
>>
>> 2010/10/22  <[hidden email]>:
>>> Hi Rosen,
>>>
>>> I have attached the robot and kinbody files.
>>>
>>> Thanks,
>>> Matthew
>>> ----- Original Message -----
>>> From: "Rosen Diankov" <[hidden email]>
>>> To: "matt cong" <[hidden email]>
>>> Cc: [hidden email]
>>> Sent: Thursday, October 21, 2010 11:02:23 PM
>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>> example
>>>
>>> hi matthew,
>>>
>>> Setting the <effector> to one of the claws includes the claw joint as
>>> part of the arm, which makes things a little more difficult (you can
>>> still compute the ik if you set the claw as the free parameter).
>>> However, it is ok to set the <effector> to the main body.
>>>
>>> In any case, you shouldn't be experiencing these problems, please send
>>> your robot file.
>>> rosen,
>>>
>>> 2010/10/22  <[hidden email]>:
>>>> Hi Rosen,
>>>>
>>>> Thanks for the suggestion. However, I did not include the explicit
>>>> iksolver
>>>> tag when defining a new robot (which is very similar to the Kuka) from
>>>> the
>>>> gripper and robot body kinbody files. Sorry for being unclear.
>>>>
>>>> I checked the <offsetfrom> tags for each link in the kinbody files as
>>>> well
>>>> as the robot file. In addition, when I visualized the stationary model
>>>> in
>>>> an
>>>> environment, the gripper was in the correct position. I also noticed the
>>>> <effector> tag in the manipulator was set to the end effector of the
>>>> main
>>>> robot body but when I changed it to the new end effector body on the
>>>> gripper
>>>> (one of the two claws on the gripper), ikfast said that it could not
>>>> divide
>>>> rotation and translation after trying to take the inverse of the
>>>> mechanism.
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>> ----- Original Message -----
>>>> From: "Rosen Diankov" <[hidden email]>
>>>> To: "matt cong" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Sent: Thursday, October 21, 2010 9:54:56 PM
>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>> example
>>>>
>>>> hi Matthew,
>>>>
>>>> Please remove the explicit iksolver tag, this forces a pre-compiled
>>>> ikfast solver to be used, which is why you are getting wrong results.
>>>> I'll see if we can add a warning message if this condition is ever
>>>> detected.
>>>>
>>>> rosen,
>>>>
>>>> 2010/10/22  <[hidden email]>:
>>>>> Hi Rosen,
>>>>>
>>>>> Thanks for the advice. I was able to use ikfast to generate fk and ik
>>>>> for
>>>>> the Kuka robot after changing the anchor tags to translation tags. I
>>>>> verified that these gave correct solutions (such as the position of the
>>>>> end-effector with respect to the base in the world frame) by having it
>>>>> print
>>>>> out the positions returned by fk and ik.
>>>>>
>>>>> I defined a gripper (using the basic geometry types) and attached it to
>>>>> the
>>>>> robot in a similar way to how I attached the Puma gripper to the body
>>>>> of
>>>>> the
>>>>> Puma robot. However, when I regenerate the kinematics using ikfast and
>>>>> test
>>>>> them, I obtain the same results for the position of my end-effector as
>>>>> the
>>>>> configuration without the gripper (essentially without the additional
>>>>> length
>>>>> in the last link due to the gripper). Do you have some ideas as to how
>>>>> to
>>>>> resolve this? I noticed that the Puma has an explicitly specified
>>>>> iksolver:
>>>>> Is this needed when a manipulator is attached?
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>> To: "matt cong" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> Sent: Monday, September 27, 2010 4:43:57 AM
>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>> example
>>>>>
>>>>> Hi Matt,
>>>>>
>>>>> The reason you are not seeing any change is because link6 of kuka-r850
>>>>> is at the origin of the robot. In fact, all links are at the origin,
>>>>> which can be confirmed by calling Link.GetTransform(). You were
>>>>> probably expecting link6 to be where the manipulator frame was
>>>>> defined.
>>>>>
>>>>> In any case, you have to change the translation of Puma6 to "0.56 0
>>>>> 0.79"
>>>>>
>>>>> rosen,
>>>>>
>>>>> 2010/9/27  <[hidden email]>:
>>>>>> Hi Rosen,
>>>>>>
>>>>>> Thank you once again for the prompt reply. It was very helpful.
>>>>>>
>>>>>> I looked at the XML again and it appears that the <offsetfrom> is set
>>>>>> correctly. However, when I do transformations, they are still relative
>>>>>> to
>>>>>> the base which makes me think that an offsetfrom is spacified
>>>>>> incorrectly.
>>>>>> Here's the file:
>>>>>>
>>>>>> <Robot name="Kuka">
>>>>>>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>>>>>>   </KinBody>
>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>     <body name="Puma6">
>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>       <translation>0.10 0 0</translation>
>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>     </body>
>>>>>>     <joint name="j6" type="hinge" enable="false">
>>>>>>       <body>link6</body>
>>>>>>       <body>Puma6</body>
>>>>>>       <offsetfrom>Puma6</offsetfrom>
>>>>>>       <limits>0 0</limits>
>>>>>>     </joint>
>>>>>>   </KinBody>
>>>>>>   <Manipulator name="arm">
>>>>>>     <effector>link6</effector>
>>>>>>     <base>base</base>
>>>>>>     <joints>m1</joints>
>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>     <closingdirection>1</closingdirection>
>>>>>>     <direction>0 0 1</direction>
>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>   </Manipulator>
>>>>>> </Robot>
>>>>>>
>>>>>> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE)
>>>>>> and
>>>>>> the
>>>>>> last joint is indeed named "link6". I also tried setting the joint
>>>>>> anchor
>>>>>> but that had no effect. Do you have any suggestions?
>>>>>>
>>>>>> Thanks,
>>>>>> Matthew
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>> To: "matt cong" <[hidden email]>
>>>>>> Cc: [hidden email]
>>>>>> Sent: Sunday, September 26, 2010 11:52:21 PM
>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>> example
>>>>>>
>>>>>> Hi Matthew,
>>>>>>
>>>>>> The <translation> tag sets the link transformations. The <anchor> tag
>>>>>> sets the offset of the joint anchor axis. By default, the joint anchor
>>>>>> is at the origin of the "offset link" specified. If you do not care
>>>>>> about link transformations, then either <anchor> and <translation> can
>>>>>> be interchanged.
>>>>>>
>>>>>> To debug your problem, first make sure the gripper is attached to the
>>>>>> correct link. Make sure the "offset from" is correct.
>>>>>>
>>>>>> The ikfast program accepts transformations with respect to the base
>>>>>> link of the manipulator specified. In order to debug your code, you'll
>>>>>> notice that the cpp file also defines a forward kinematics function
>>>>>> 'fk' that you can use to input joint angles to get the end effector
>>>>>> transformation. Inserting this transformation back into the ik should
>>>>>> give you a correct solution.
>>>>>>
>>>>>> good luck!
>>>>>> rosen,
>>>>>>
>>>>>> 2010/9/27  <[hidden email]>:
>>>>>>> Hi Rosen,
>>>>>>>
>>>>>>> Thanks for the fix before -- It worked out great.
>>>>>>>
>>>>>>> I'm now trying to do the same thing with the Kuka r850 robot: I
>>>>>>> modified
>>>>>>> the
>>>>>>> fixed XML file that you sent me by changing the first kinbody file to
>>>>>>> be
>>>>>>> the
>>>>>>> r850 kinbody as opposed to the r650 kinbody. However, when I
>>>>>>> visualize
>>>>>>> this
>>>>>>> in the environment, the Puma gripper appears at the base of the
>>>>>>> robot.
>>>>>>> In
>>>>>>> addition, when running the example, I obtain the following: openrave
>>>>>>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as to
>>>>>>> how
>>>>>>> I
>>>>>>> could proceed?
>>>>>>>
>>>>>>> Upon looking through the kuka850 kinbody and comparing it to that of
>>>>>>> 650,
>>>>>>> I
>>>>>>> noticed that the only differences were <anchor> being specified as
>>>>>>> opposed
>>>>>>> to <translation> Could you explain the difference between these two
>>>>>>> different ways of specifying the robot? I tried converting them to
>>>>>>> equivalent translations but the r850 visualization had links floating
>>>>>>> at
>>>>>>> unconnected positions in space.
>>>>>>>
>>>>>>> I have also used ikfast to compile a standalone C++ executable for
>>>>>>> the
>>>>>>> r650
>>>>>>> arm: Once compiled, I tried running it and got "Failed to get IK
>>>>>>> solution."
>>>>>>> Is this because the coordinates I've specified are not within range
>>>>>>> of
>>>>>>> the
>>>>>>> robot? Is there a similar way of getting a standalone FK program as
>>>>>>> well
>>>>>>> or
>>>>>>> is it just implicitly included in the model?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matthew
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>> Cc: [hidden email]"
>>>>>>> Sent: Sunday, September 12, 2010 7:56:53 PM
>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>> example
>>>>>>>
>>>>>>> Hi Matt,
>>>>>>>
>>>>>>> For your first example, you need to add a dummy joint  between one
>>>>>>> link in the robot and one in the hand, otherwise they will not be
>>>>>>> attached. You also need to add 'robots/' to the robot filenames
>>>>>>> otherwise openrave will not be able to find the robots unless they
>>>>>>> are
>>>>>>> inside the default robots directory. You also need to move the puma
>>>>>>> gripper
>>>>>>>
>>>>>>> Here's the fix:
>>>>>>>
>>>>>>> <Robot name="Puma">
>>>>>>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>>>>>>   </KinBody>
>>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>>     <body name="Puma6">
>>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>>       <translation>-0.03 0 0</translation>
>>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>>     </body>
>>>>>>>     <!-- add a dummy joint -->
>>>>>>>     <joint type="hinge" enable="false">
>>>>>>>       <body>link6</body>
>>>>>>>       <body>Puma6</body>
>>>>>>>       <limits>0 0</limits>
>>>>>>>     </joint>
>>>>>>>   </KinBody>
>>>>>>>   <Manipulator name="arm">
>>>>>>>     <effector>link6</effector>
>>>>>>>     <base>base</base>
>>>>>>>     <joints>m1</joints>
>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>     <direction>0 0 1</direction>
>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>   </Manipulator>
>>>>>>> </Robot>
>>>>>>>
>>>>>>>
>>>>>>> As for the example on the wiki, you need to add a <Manipulator>
>>>>>>> definition before using it.
>>>>>>>
>>>>>>> rosen,
>>>>>>>
>>>>>>>
>>>>>>> 2010/9/13  <[hidden email]>:
>>>>>>>> Hi Rosen,
>>>>>>>>
>>>>>>>> Thanks for the guidance on the ikfast and planner errors.
>>>>>>>>
>>>>>>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot.
>>>>>>>> Since
>>>>>>>> this arm does not have a gripper attached, I also attached the Puma
>>>>>>>> gripper
>>>>>>>> to the end of the robot as follows:
>>>>>>>>
>>>>>>>> <Robot name="Puma">
>>>>>>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>>>>>>     <KinBody file="pumagripper.kinbody.xml">
>>>>>>>>     </KinBody>
>>>>>>>>   </KinBody>
>>>>>>>>   <Manipulator name="arm">
>>>>>>>>     <effector>link6</effector>
>>>>>>>>         <base>base</base>
>>>>>>>>     <joints>m1</joints>
>>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>>     <direction>0 0 1</direction>
>>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>>   </Manipulator>
>>>>>>>> </Robot>
>>>>>>>>
>>>>>>>> I tried to visualize this new environment using "openrave.py -p
>>>>>>>> "env.Load('data/hanoi_complex.env.xml')" where hanoi_complex.env.xml
>>>>>>>> has
>>>>>>>> been modified to use the newly defined Kuka robot. However, I
>>>>>>>> received
>>>>>>>> the
>>>>>>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy
>>>>>>>> for
>>>>>>>> number of joints 7! Part of robot might not be moveable"
>>>>>>>>
>>>>>>>> Did I make an error while defining the robot and linking up the
>>>>>>>> different
>>>>>>>> components such as not specifying an additional joint between the
>>>>>>>> gripper
>>>>>>>> and arm?
>>>>>>>>
>>>>>>>> In addition, I also tried working with the Kuka Collada example
>>>>>>>> here:
>>>>>>>> http://openrave.programmingvision.com/index.php/Started:Formats. I
>>>>>>>> was
>>>>>>>> able
>>>>>>>> to visualize and generate the inverse kinematics successfully but
>>>>>>>> when
>>>>>>>> running the Hanoi example, it failed due to an assertion error from
>>>>>>>> the
>>>>>>>> following line: assert(len(jointinds)==len(jointvalues) and
>>>>>>>> len(jointinds)>0). Is this related to the previous error?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Matthew
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>>> Cc: [hidden email]
>>>>>>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>>> example
>>>>>>>>
>>>>>>>> hi Matthew,
>>>>>>>>
>>>>>>>> Thanks for the patch, I updated openrave.rosinstall
>>>>>>>>
>>>>>>>> You can ignore the ikfast errors should not be printed since the
>>>>>>>> puma
>>>>>>>> arm has a pre-generated ik file. You can ignore them.
>>>>>>>>
>>>>>>>> The planner is randomized, so it can fail at times. This is why
>>>>>>>> openrave calls it multiple times to guarantee a path is found if one
>>>>>>>> exists.
>>>>>>>>
>>>>>>>> rosen,
>>>>>>>>
>>>>>>>> 2010/9/6  <[hidden email]>:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I installed OpenRAVE and ROS via the instructions listed here on
>>>>>>>>> Ubuntu
>>>>>>>>> 10.04 x86_64:
>>>>>>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>>>>>>
>>>>>>>>> One change that I made was adding the pr2_calibration stack to the
>>>>>>>>> install
>>>>>>>>> file since calibration_experimental complained that it wasn't
>>>>>>>>> present
>>>>>>>>> as
>>>>>>>>> a
>>>>>>>>> dependency when running "rosdep install orrosplanning rviz" The
>>>>>>>>> added
>>>>>>>>> lines
>>>>>>>>> are listed below.
>>>>>>>>>
>>>>>>>>> - svn:
>>>>>>>>>     uri:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>>>>>>     local-name: stacks/pr2_calibration
>>>>>>>>>
>>>>>>>>> I had a previous SVN-based ROS installation (boxturtle) -- However,
>>>>>>>>> I
>>>>>>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>>>>>>
>>>>>>>>> When I go to run the Hanoi example using "openrave.py --example
>>>>>>>>> hanoi",
>>>>>>>>> I
>>>>>>>>> receive the following error:
>>>>>>>>>
>>>>>>>>> [ikfastproblem.h:206]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>>>>>>> cannot open shared object file: No such file or directory
>>>>>>>>> [ikfastproblem.h:131] failed to load library
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>>>>>>
>>>>>>>>> Should I be concerned with this error? The example runs
>>>>>>>>> successfully
>>>>>>>>> and
>>>>>>>>> terminates after the Towers of Hanoi problem is solved. There are
>>>>>>>>> also
>>>>>>>>> a
>>>>>>>>> couple of errors during the program such as
>>>>>>>>>
>>>>>>>>> [rrt.h:283] plan failed, 3.478000s
>>>>>>>>> [basemanipulation.h:867] PlanPath failed
>>>>>>>>>
>>>>>>>>> but I expect these are due to the arm using RRT for planning and a
>>>>>>>>> solution
>>>>>>>>> not being found within a certain number of iterations.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matthew
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> This SF.net Dev2Dev email is sponsored by:
>>>>>>>>>
>>>>>>>>> Show off your parallel programming skills.
>>>>>>>>> Enter the Intel(R) Threading Challenge 2010.
>>>>>>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>>>>>>> _______________________________________________
>>>>>>>>> Openrave-users mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>> and start using them to simplify application deployment and
>>>>>>>> accelerate your shift to cloud computing
>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Openrave-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>> and start using them to simplify application deployment and
>>>>>>> accelerate your shift to cloud computing.
>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>> _______________________________________________
>>>>>>> Openrave-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>> and start using them to simplify application deployment and
>>>>>> accelerate your shift to cloud computing.
>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>> _______________________________________________
>>>>>> Openrave-users mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>>>>> contest
>>>>> Create new apps & games for the Nokia N8 for consumers in  U.S. and
>>>>> Canada
>>>>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>>>>> marketing
>>>>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi
>>>>> Store
>>>>> http://p.sf.net/sfu/nokia-dev2dev
>>>>> _______________________________________________
>>>>> Openrave-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>
>>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

matt.cong
Hi Rosen,

Thanks for all of your help! I updated OpenRAVE and regenerated the IK, which is now giving back the correct coordinates including the gripper.

Thanks again,
Matthew
----- Original Message -----
From: "Rosen Diankov" <[hidden email]>
To: "matt cong" <[hidden email]>
Cc: [hidden email]
Sent: Friday, October 22, 2010 1:38:36 AM
Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example

hi matthew,

i see, you are using the generated C++ files as is without the
openrave wrappers. Up the one week ago, the C++ files did not encode
the grasp frame, it was premultiplied on the openrave side. However,
this week I updated ikfast to incorporate grasp frame also. Can you
try updating to the newest openrave and regenerate the ik?

Also, kinematics are independent of geometry. the 'fk' function gives
coordinates of the gripper frame with respect to the base link, 'ik'
function takes coordinates of the gripper frame with respect to the
baselink.

rosen,

2010/10/22  <[hidden email]>:

> Hi Rosen,
>
> Thank you for your help. I have attached the test scripts. They mostly do
> conversions to ypr and degrees along with some adjustments for differing
> conventions on the starting point of the robot, but these are all minor.
>
> Is it possible that the geometry is connected with the IK problems? I was
> operating under the assumption that the meshes were only related to the
> visual display, but I may have been wrong. Also, does the IK/FK give
> coordinates with respect to the base of the robot or the starting position
> of the end effector?
>
> Thanks,
> Matthew
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Sent: Friday, October 22, 2010 1:11:12 AM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> either way, executing the following command to test the ik:
>
>  openrave.py --database inversekinematics
> --robot=adeptComplete.robot.xml  --iktest=100
>
>
> gives 100% success rate, so everything is working fine... perhaps
> there is some misunderstanding on how the ik functions work... can you
> send the test scripts you are using?
>
> rosen,
>
> 2010/10/22 Rosen Diankov <[hidden email]>:
>> robot geometry looks broken...
>> rosen,
>>
>> 2010/10/22  <[hidden email]>:
>>> Hi Rosen,
>>>
>>> I have attached the robot and kinbody files.
>>>
>>> Thanks,
>>> Matthew
>>> ----- Original Message -----
>>> From: "Rosen Diankov" <[hidden email]>
>>> To: "matt cong" <[hidden email]>
>>> Cc: [hidden email]
>>> Sent: Thursday, October 21, 2010 11:02:23 PM
>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>> example
>>>
>>> hi matthew,
>>>
>>> Setting the <effector> to one of the claws includes the claw joint as
>>> part of the arm, which makes things a little more difficult (you can
>>> still compute the ik if you set the claw as the free parameter).
>>> However, it is ok to set the <effector> to the main body.
>>>
>>> In any case, you shouldn't be experiencing these problems, please send
>>> your robot file.
>>> rosen,
>>>
>>> 2010/10/22  <[hidden email]>:
>>>> Hi Rosen,
>>>>
>>>> Thanks for the suggestion. However, I did not include the explicit
>>>> iksolver
>>>> tag when defining a new robot (which is very similar to the Kuka) from
>>>> the
>>>> gripper and robot body kinbody files. Sorry for being unclear.
>>>>
>>>> I checked the <offsetfrom> tags for each link in the kinbody files as
>>>> well
>>>> as the robot file. In addition, when I visualized the stationary model
>>>> in
>>>> an
>>>> environment, the gripper was in the correct position. I also noticed the
>>>> <effector> tag in the manipulator was set to the end effector of the
>>>> main
>>>> robot body but when I changed it to the new end effector body on the
>>>> gripper
>>>> (one of the two claws on the gripper), ikfast said that it could not
>>>> divide
>>>> rotation and translation after trying to take the inverse of the
>>>> mechanism.
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>> ----- Original Message -----
>>>> From: "Rosen Diankov" <[hidden email]>
>>>> To: "matt cong" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Sent: Thursday, October 21, 2010 9:54:56 PM
>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>> example
>>>>
>>>> hi Matthew,
>>>>
>>>> Please remove the explicit iksolver tag, this forces a pre-compiled
>>>> ikfast solver to be used, which is why you are getting wrong results.
>>>> I'll see if we can add a warning message if this condition is ever
>>>> detected.
>>>>
>>>> rosen,
>>>>
>>>> 2010/10/22  <[hidden email]>:
>>>>> Hi Rosen,
>>>>>
>>>>> Thanks for the advice. I was able to use ikfast to generate fk and ik
>>>>> for
>>>>> the Kuka robot after changing the anchor tags to translation tags. I
>>>>> verified that these gave correct solutions (such as the position of the
>>>>> end-effector with respect to the base in the world frame) by having it
>>>>> print
>>>>> out the positions returned by fk and ik.
>>>>>
>>>>> I defined a gripper (using the basic geometry types) and attached it to
>>>>> the
>>>>> robot in a similar way to how I attached the Puma gripper to the body
>>>>> of
>>>>> the
>>>>> Puma robot. However, when I regenerate the kinematics using ikfast and
>>>>> test
>>>>> them, I obtain the same results for the position of my end-effector as
>>>>> the
>>>>> configuration without the gripper (essentially without the additional
>>>>> length
>>>>> in the last link due to the gripper). Do you have some ideas as to how
>>>>> to
>>>>> resolve this? I noticed that the Puma has an explicitly specified
>>>>> iksolver:
>>>>> Is this needed when a manipulator is attached?
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>> To: "matt cong" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> Sent: Monday, September 27, 2010 4:43:57 AM
>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>> example
>>>>>
>>>>> Hi Matt,
>>>>>
>>>>> The reason you are not seeing any change is because link6 of kuka-r850
>>>>> is at the origin of the robot. In fact, all links are at the origin,
>>>>> which can be confirmed by calling Link.GetTransform(). You were
>>>>> probably expecting link6 to be where the manipulator frame was
>>>>> defined.
>>>>>
>>>>> In any case, you have to change the translation of Puma6 to "0.56 0
>>>>> 0.79"
>>>>>
>>>>> rosen,
>>>>>
>>>>> 2010/9/27  <[hidden email]>:
>>>>>> Hi Rosen,
>>>>>>
>>>>>> Thank you once again for the prompt reply. It was very helpful.
>>>>>>
>>>>>> I looked at the XML again and it appears that the <offsetfrom> is set
>>>>>> correctly. However, when I do transformations, they are still relative
>>>>>> to
>>>>>> the base which makes me think that an offsetfrom is spacified
>>>>>> incorrectly.
>>>>>> Here's the file:
>>>>>>
>>>>>> <Robot name="Kuka">
>>>>>>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>>>>>>   </KinBody>
>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>     <body name="Puma6">
>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>       <translation>0.10 0 0</translation>
>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>     </body>
>>>>>>     <joint name="j6" type="hinge" enable="false">
>>>>>>       <body>link6</body>
>>>>>>       <body>Puma6</body>
>>>>>>       <offsetfrom>Puma6</offsetfrom>
>>>>>>       <limits>0 0</limits>
>>>>>>     </joint>
>>>>>>   </KinBody>
>>>>>>   <Manipulator name="arm">
>>>>>>     <effector>link6</effector>
>>>>>>     <base>base</base>
>>>>>>     <joints>m1</joints>
>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>     <closingdirection>1</closingdirection>
>>>>>>     <direction>0 0 1</direction>
>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>   </Manipulator>
>>>>>> </Robot>
>>>>>>
>>>>>> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE)
>>>>>> and
>>>>>> the
>>>>>> last joint is indeed named "link6". I also tried setting the joint
>>>>>> anchor
>>>>>> but that had no effect. Do you have any suggestions?
>>>>>>
>>>>>> Thanks,
>>>>>> Matthew
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>> To: "matt cong" <[hidden email]>
>>>>>> Cc: [hidden email]
>>>>>> Sent: Sunday, September 26, 2010 11:52:21 PM
>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>> example
>>>>>>
>>>>>> Hi Matthew,
>>>>>>
>>>>>> The <translation> tag sets the link transformations. The <anchor> tag
>>>>>> sets the offset of the joint anchor axis. By default, the joint anchor
>>>>>> is at the origin of the "offset link" specified. If you do not care
>>>>>> about link transformations, then either <anchor> and <translation> can
>>>>>> be interchanged.
>>>>>>
>>>>>> To debug your problem, first make sure the gripper is attached to the
>>>>>> correct link. Make sure the "offset from" is correct.
>>>>>>
>>>>>> The ikfast program accepts transformations with respect to the base
>>>>>> link of the manipulator specified. In order to debug your code, you'll
>>>>>> notice that the cpp file also defines a forward kinematics function
>>>>>> 'fk' that you can use to input joint angles to get the end effector
>>>>>> transformation. Inserting this transformation back into the ik should
>>>>>> give you a correct solution.
>>>>>>
>>>>>> good luck!
>>>>>> rosen,
>>>>>>
>>>>>> 2010/9/27  <[hidden email]>:
>>>>>>> Hi Rosen,
>>>>>>>
>>>>>>> Thanks for the fix before -- It worked out great.
>>>>>>>
>>>>>>> I'm now trying to do the same thing with the Kuka r850 robot: I
>>>>>>> modified
>>>>>>> the
>>>>>>> fixed XML file that you sent me by changing the first kinbody file to
>>>>>>> be
>>>>>>> the
>>>>>>> r850 kinbody as opposed to the r650 kinbody. However, when I
>>>>>>> visualize
>>>>>>> this
>>>>>>> in the environment, the Puma gripper appears at the base of the
>>>>>>> robot.
>>>>>>> In
>>>>>>> addition, when running the example, I obtain the following: openrave
>>>>>>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as to
>>>>>>> how
>>>>>>> I
>>>>>>> could proceed?
>>>>>>>
>>>>>>> Upon looking through the kuka850 kinbody and comparing it to that of
>>>>>>> 650,
>>>>>>> I
>>>>>>> noticed that the only differences were <anchor> being specified as
>>>>>>> opposed
>>>>>>> to <translation> Could you explain the difference between these two
>>>>>>> different ways of specifying the robot? I tried converting them to
>>>>>>> equivalent translations but the r850 visualization had links floating
>>>>>>> at
>>>>>>> unconnected positions in space.
>>>>>>>
>>>>>>> I have also used ikfast to compile a standalone C++ executable for
>>>>>>> the
>>>>>>> r650
>>>>>>> arm: Once compiled, I tried running it and got "Failed to get IK
>>>>>>> solution."
>>>>>>> Is this because the coordinates I've specified are not within range
>>>>>>> of
>>>>>>> the
>>>>>>> robot? Is there a similar way of getting a standalone FK program as
>>>>>>> well
>>>>>>> or
>>>>>>> is it just implicitly included in the model?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matthew
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>> Cc: [hidden email]"
>>>>>>> Sent: Sunday, September 12, 2010 7:56:53 PM
>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>> example
>>>>>>>
>>>>>>> Hi Matt,
>>>>>>>
>>>>>>> For your first example, you need to add a dummy joint  between one
>>>>>>> link in the robot and one in the hand, otherwise they will not be
>>>>>>> attached. You also need to add 'robots/' to the robot filenames
>>>>>>> otherwise openrave will not be able to find the robots unless they
>>>>>>> are
>>>>>>> inside the default robots directory. You also need to move the puma
>>>>>>> gripper
>>>>>>>
>>>>>>> Here's the fix:
>>>>>>>
>>>>>>> <Robot name="Puma">
>>>>>>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>>>>>>   </KinBody>
>>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>>     <body name="Puma6">
>>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>>       <translation>-0.03 0 0</translation>
>>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>>     </body>
>>>>>>>     <!-- add a dummy joint -->
>>>>>>>     <joint type="hinge" enable="false">
>>>>>>>       <body>link6</body>
>>>>>>>       <body>Puma6</body>
>>>>>>>       <limits>0 0</limits>
>>>>>>>     </joint>
>>>>>>>   </KinBody>
>>>>>>>   <Manipulator name="arm">
>>>>>>>     <effector>link6</effector>
>>>>>>>     <base>base</base>
>>>>>>>     <joints>m1</joints>
>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>     <direction>0 0 1</direction>
>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>   </Manipulator>
>>>>>>> </Robot>
>>>>>>>
>>>>>>>
>>>>>>> As for the example on the wiki, you need to add a <Manipulator>
>>>>>>> definition before using it.
>>>>>>>
>>>>>>> rosen,
>>>>>>>
>>>>>>>
>>>>>>> 2010/9/13  <[hidden email]>:
>>>>>>>> Hi Rosen,
>>>>>>>>
>>>>>>>> Thanks for the guidance on the ikfast and planner errors.
>>>>>>>>
>>>>>>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot.
>>>>>>>> Since
>>>>>>>> this arm does not have a gripper attached, I also attached the Puma
>>>>>>>> gripper
>>>>>>>> to the end of the robot as follows:
>>>>>>>>
>>>>>>>> <Robot name="Puma">
>>>>>>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>>>>>>     <KinBody file="pumagripper.kinbody.xml">
>>>>>>>>     </KinBody>
>>>>>>>>   </KinBody>
>>>>>>>>   <Manipulator name="arm">
>>>>>>>>     <effector>link6</effector>
>>>>>>>>         <base>base</base>
>>>>>>>>     <joints>m1</joints>
>>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>>     <direction>0 0 1</direction>
>>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>>   </Manipulator>
>>>>>>>> </Robot>
>>>>>>>>
>>>>>>>> I tried to visualize this new environment using "openrave.py -p
>>>>>>>> "env.Load('data/hanoi_complex.env.xml')" where hanoi_complex.env.xml
>>>>>>>> has
>>>>>>>> been modified to use the newly defined Kuka robot. However, I
>>>>>>>> received
>>>>>>>> the
>>>>>>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy
>>>>>>>> for
>>>>>>>> number of joints 7! Part of robot might not be moveable"
>>>>>>>>
>>>>>>>> Did I make an error while defining the robot and linking up the
>>>>>>>> different
>>>>>>>> components such as not specifying an additional joint between the
>>>>>>>> gripper
>>>>>>>> and arm?
>>>>>>>>
>>>>>>>> In addition, I also tried working with the Kuka Collada example
>>>>>>>> here:
>>>>>>>> http://openrave.programmingvision.com/index.php/Started:Formats. I
>>>>>>>> was
>>>>>>>> able
>>>>>>>> to visualize and generate the inverse kinematics successfully but
>>>>>>>> when
>>>>>>>> running the Hanoi example, it failed due to an assertion error from
>>>>>>>> the
>>>>>>>> following line: assert(len(jointinds)==len(jointvalues) and
>>>>>>>> len(jointinds)>0). Is this related to the previous error?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Matthew
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>>> Cc: [hidden email]
>>>>>>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>>> example
>>>>>>>>
>>>>>>>> hi Matthew,
>>>>>>>>
>>>>>>>> Thanks for the patch, I updated openrave.rosinstall
>>>>>>>>
>>>>>>>> You can ignore the ikfast errors should not be printed since the
>>>>>>>> puma
>>>>>>>> arm has a pre-generated ik file. You can ignore them.
>>>>>>>>
>>>>>>>> The planner is randomized, so it can fail at times. This is why
>>>>>>>> openrave calls it multiple times to guarantee a path is found if one
>>>>>>>> exists.
>>>>>>>>
>>>>>>>> rosen,
>>>>>>>>
>>>>>>>> 2010/9/6  <[hidden email]>:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I installed OpenRAVE and ROS via the instructions listed here on
>>>>>>>>> Ubuntu
>>>>>>>>> 10.04 x86_64:
>>>>>>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>>>>>>
>>>>>>>>> One change that I made was adding the pr2_calibration stack to the
>>>>>>>>> install
>>>>>>>>> file since calibration_experimental complained that it wasn't
>>>>>>>>> present
>>>>>>>>> as
>>>>>>>>> a
>>>>>>>>> dependency when running "rosdep install orrosplanning rviz" The
>>>>>>>>> added
>>>>>>>>> lines
>>>>>>>>> are listed below.
>>>>>>>>>
>>>>>>>>> - svn:
>>>>>>>>>     uri:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>>>>>>     local-name: stacks/pr2_calibration
>>>>>>>>>
>>>>>>>>> I had a previous SVN-based ROS installation (boxturtle) -- However,
>>>>>>>>> I
>>>>>>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>>>>>>
>>>>>>>>> When I go to run the Hanoi example using "openrave.py --example
>>>>>>>>> hanoi",
>>>>>>>>> I
>>>>>>>>> receive the following error:
>>>>>>>>>
>>>>>>>>> [ikfastproblem.h:206]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>>>>>>> cannot open shared object file: No such file or directory
>>>>>>>>> [ikfastproblem.h:131] failed to load library
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>>>>>>
>>>>>>>>> Should I be concerned with this error? The example runs
>>>>>>>>> successfully
>>>>>>>>> and
>>>>>>>>> terminates after the Towers of Hanoi problem is solved. There are
>>>>>>>>> also
>>>>>>>>> a
>>>>>>>>> couple of errors during the program such as
>>>>>>>>>
>>>>>>>>> [rrt.h:283] plan failed, 3.478000s
>>>>>>>>> [basemanipulation.h:867] PlanPath failed
>>>>>>>>>
>>>>>>>>> but I expect these are due to the arm using RRT for planning and a
>>>>>>>>> solution
>>>>>>>>> not being found within a certain number of iterations.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matthew
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> This SF.net Dev2Dev email is sponsored by:
>>>>>>>>>
>>>>>>>>> Show off your parallel programming skills.
>>>>>>>>> Enter the Intel(R) Threading Challenge 2010.
>>>>>>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>>>>>>> _______________________________________________
>>>>>>>>> Openrave-users mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>> and start using them to simplify application deployment and
>>>>>>>> accelerate your shift to cloud computing
>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Openrave-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>> and start using them to simplify application deployment and
>>>>>>> accelerate your shift to cloud computing.
>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>> _______________________________________________
>>>>>>> Openrave-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>> and start using them to simplify application deployment and
>>>>>> accelerate your shift to cloud computing.
>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>> _______________________________________________
>>>>>> Openrave-users mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>>>>> contest
>>>>> Create new apps & games for the Nokia N8 for consumers in  U.S. and
>>>>> Canada
>>>>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>>>>> marketing
>>>>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi
>>>>> Store
>>>>> http://p.sf.net/sfu/nokia-dev2dev
>>>>> _______________________________________________
>>>>> Openrave-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>
>>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

matt.cong
In reply to this post by Rosen Diankov
Hi Rosen,

Thanks again for all of your help. I've been using the ikfast generated ik and noticed that it returns solutions that are outside the joint limits specified in the robot.xml file. Is this to be expected? Are the joint limits handled on the OpenRAVE side?

Thanks,
Matthew
----- Original Message -----
From: "Rosen Diankov" <[hidden email]>
To: "matt cong" <[hidden email]>
Cc: [hidden email]
Sent: Friday, October 22, 2010 1:38:36 AM
Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example

hi matthew,

i see, you are using the generated C++ files as is without the
openrave wrappers. Up the one week ago, the C++ files did not encode
the grasp frame, it was premultiplied on the openrave side. However,
this week I updated ikfast to incorporate grasp frame also. Can you
try updating to the newest openrave and regenerate the ik?

Also, kinematics are independent of geometry. the 'fk' function gives
coordinates of the gripper frame with respect to the base link, 'ik'
function takes coordinates of the gripper frame with respect to the
baselink.

rosen,

2010/10/22  <[hidden email]>:

> Hi Rosen,
>
> Thank you for your help. I have attached the test scripts. They mostly do
> conversions to ypr and degrees along with some adjustments for differing
> conventions on the starting point of the robot, but these are all minor.
>
> Is it possible that the geometry is connected with the IK problems? I was
> operating under the assumption that the meshes were only related to the
> visual display, but I may have been wrong. Also, does the IK/FK give
> coordinates with respect to the base of the robot or the starting position
> of the end effector?
>
> Thanks,
> Matthew
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Sent: Friday, October 22, 2010 1:11:12 AM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> either way, executing the following command to test the ik:
>
>  openrave.py --database inversekinematics
> --robot=adeptComplete.robot.xml  --iktest=100
>
>
> gives 100% success rate, so everything is working fine... perhaps
> there is some misunderstanding on how the ik functions work... can you
> send the test scripts you are using?
>
> rosen,
>
> 2010/10/22 Rosen Diankov <[hidden email]>:
>> robot geometry looks broken...
>> rosen,
>>
>> 2010/10/22  <[hidden email]>:
>>> Hi Rosen,
>>>
>>> I have attached the robot and kinbody files.
>>>
>>> Thanks,
>>> Matthew
>>> ----- Original Message -----
>>> From: "Rosen Diankov" <[hidden email]>
>>> To: "matt cong" <[hidden email]>
>>> Cc: [hidden email]
>>> Sent: Thursday, October 21, 2010 11:02:23 PM
>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>> example
>>>
>>> hi matthew,
>>>
>>> Setting the <effector> to one of the claws includes the claw joint as
>>> part of the arm, which makes things a little more difficult (you can
>>> still compute the ik if you set the claw as the free parameter).
>>> However, it is ok to set the <effector> to the main body.
>>>
>>> In any case, you shouldn't be experiencing these problems, please send
>>> your robot file.
>>> rosen,
>>>
>>> 2010/10/22  <[hidden email]>:
>>>> Hi Rosen,
>>>>
>>>> Thanks for the suggestion. However, I did not include the explicit
>>>> iksolver
>>>> tag when defining a new robot (which is very similar to the Kuka) from
>>>> the
>>>> gripper and robot body kinbody files. Sorry for being unclear.
>>>>
>>>> I checked the <offsetfrom> tags for each link in the kinbody files as
>>>> well
>>>> as the robot file. In addition, when I visualized the stationary model
>>>> in
>>>> an
>>>> environment, the gripper was in the correct position. I also noticed the
>>>> <effector> tag in the manipulator was set to the end effector of the
>>>> main
>>>> robot body but when I changed it to the new end effector body on the
>>>> gripper
>>>> (one of the two claws on the gripper), ikfast said that it could not
>>>> divide
>>>> rotation and translation after trying to take the inverse of the
>>>> mechanism.
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>> ----- Original Message -----
>>>> From: "Rosen Diankov" <[hidden email]>
>>>> To: "matt cong" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Sent: Thursday, October 21, 2010 9:54:56 PM
>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>> example
>>>>
>>>> hi Matthew,
>>>>
>>>> Please remove the explicit iksolver tag, this forces a pre-compiled
>>>> ikfast solver to be used, which is why you are getting wrong results.
>>>> I'll see if we can add a warning message if this condition is ever
>>>> detected.
>>>>
>>>> rosen,
>>>>
>>>> 2010/10/22  <[hidden email]>:
>>>>> Hi Rosen,
>>>>>
>>>>> Thanks for the advice. I was able to use ikfast to generate fk and ik
>>>>> for
>>>>> the Kuka robot after changing the anchor tags to translation tags. I
>>>>> verified that these gave correct solutions (such as the position of the
>>>>> end-effector with respect to the base in the world frame) by having it
>>>>> print
>>>>> out the positions returned by fk and ik.
>>>>>
>>>>> I defined a gripper (using the basic geometry types) and attached it to
>>>>> the
>>>>> robot in a similar way to how I attached the Puma gripper to the body
>>>>> of
>>>>> the
>>>>> Puma robot. However, when I regenerate the kinematics using ikfast and
>>>>> test
>>>>> them, I obtain the same results for the position of my end-effector as
>>>>> the
>>>>> configuration without the gripper (essentially without the additional
>>>>> length
>>>>> in the last link due to the gripper). Do you have some ideas as to how
>>>>> to
>>>>> resolve this? I noticed that the Puma has an explicitly specified
>>>>> iksolver:
>>>>> Is this needed when a manipulator is attached?
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>> To: "matt cong" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> Sent: Monday, September 27, 2010 4:43:57 AM
>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>> example
>>>>>
>>>>> Hi Matt,
>>>>>
>>>>> The reason you are not seeing any change is because link6 of kuka-r850
>>>>> is at the origin of the robot. In fact, all links are at the origin,
>>>>> which can be confirmed by calling Link.GetTransform(). You were
>>>>> probably expecting link6 to be where the manipulator frame was
>>>>> defined.
>>>>>
>>>>> In any case, you have to change the translation of Puma6 to "0.56 0
>>>>> 0.79"
>>>>>
>>>>> rosen,
>>>>>
>>>>> 2010/9/27  <[hidden email]>:
>>>>>> Hi Rosen,
>>>>>>
>>>>>> Thank you once again for the prompt reply. It was very helpful.
>>>>>>
>>>>>> I looked at the XML again and it appears that the <offsetfrom> is set
>>>>>> correctly. However, when I do transformations, they are still relative
>>>>>> to
>>>>>> the base which makes me think that an offsetfrom is spacified
>>>>>> incorrectly.
>>>>>> Here's the file:
>>>>>>
>>>>>> <Robot name="Kuka">
>>>>>>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>>>>>>   </KinBody>
>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>     <body name="Puma6">
>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>       <translation>0.10 0 0</translation>
>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>     </body>
>>>>>>     <joint name="j6" type="hinge" enable="false">
>>>>>>       <body>link6</body>
>>>>>>       <body>Puma6</body>
>>>>>>       <offsetfrom>Puma6</offsetfrom>
>>>>>>       <limits>0 0</limits>
>>>>>>     </joint>
>>>>>>   </KinBody>
>>>>>>   <Manipulator name="arm">
>>>>>>     <effector>link6</effector>
>>>>>>     <base>base</base>
>>>>>>     <joints>m1</joints>
>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>     <closingdirection>1</closingdirection>
>>>>>>     <direction>0 0 1</direction>
>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>   </Manipulator>
>>>>>> </Robot>
>>>>>>
>>>>>> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE)
>>>>>> and
>>>>>> the
>>>>>> last joint is indeed named "link6". I also tried setting the joint
>>>>>> anchor
>>>>>> but that had no effect. Do you have any suggestions?
>>>>>>
>>>>>> Thanks,
>>>>>> Matthew
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>> To: "matt cong" <[hidden email]>
>>>>>> Cc: [hidden email]
>>>>>> Sent: Sunday, September 26, 2010 11:52:21 PM
>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>> example
>>>>>>
>>>>>> Hi Matthew,
>>>>>>
>>>>>> The <translation> tag sets the link transformations. The <anchor> tag
>>>>>> sets the offset of the joint anchor axis. By default, the joint anchor
>>>>>> is at the origin of the "offset link" specified. If you do not care
>>>>>> about link transformations, then either <anchor> and <translation> can
>>>>>> be interchanged.
>>>>>>
>>>>>> To debug your problem, first make sure the gripper is attached to the
>>>>>> correct link. Make sure the "offset from" is correct.
>>>>>>
>>>>>> The ikfast program accepts transformations with respect to the base
>>>>>> link of the manipulator specified. In order to debug your code, you'll
>>>>>> notice that the cpp file also defines a forward kinematics function
>>>>>> 'fk' that you can use to input joint angles to get the end effector
>>>>>> transformation. Inserting this transformation back into the ik should
>>>>>> give you a correct solution.
>>>>>>
>>>>>> good luck!
>>>>>> rosen,
>>>>>>
>>>>>> 2010/9/27  <[hidden email]>:
>>>>>>> Hi Rosen,
>>>>>>>
>>>>>>> Thanks for the fix before -- It worked out great.
>>>>>>>
>>>>>>> I'm now trying to do the same thing with the Kuka r850 robot: I
>>>>>>> modified
>>>>>>> the
>>>>>>> fixed XML file that you sent me by changing the first kinbody file to
>>>>>>> be
>>>>>>> the
>>>>>>> r850 kinbody as opposed to the r650 kinbody. However, when I
>>>>>>> visualize
>>>>>>> this
>>>>>>> in the environment, the Puma gripper appears at the base of the
>>>>>>> robot.
>>>>>>> In
>>>>>>> addition, when running the example, I obtain the following: openrave
>>>>>>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as to
>>>>>>> how
>>>>>>> I
>>>>>>> could proceed?
>>>>>>>
>>>>>>> Upon looking through the kuka850 kinbody and comparing it to that of
>>>>>>> 650,
>>>>>>> I
>>>>>>> noticed that the only differences were <anchor> being specified as
>>>>>>> opposed
>>>>>>> to <translation> Could you explain the difference between these two
>>>>>>> different ways of specifying the robot? I tried converting them to
>>>>>>> equivalent translations but the r850 visualization had links floating
>>>>>>> at
>>>>>>> unconnected positions in space.
>>>>>>>
>>>>>>> I have also used ikfast to compile a standalone C++ executable for
>>>>>>> the
>>>>>>> r650
>>>>>>> arm: Once compiled, I tried running it and got "Failed to get IK
>>>>>>> solution."
>>>>>>> Is this because the coordinates I've specified are not within range
>>>>>>> of
>>>>>>> the
>>>>>>> robot? Is there a similar way of getting a standalone FK program as
>>>>>>> well
>>>>>>> or
>>>>>>> is it just implicitly included in the model?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matthew
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>> Cc: [hidden email]"
>>>>>>> Sent: Sunday, September 12, 2010 7:56:53 PM
>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>> example
>>>>>>>
>>>>>>> Hi Matt,
>>>>>>>
>>>>>>> For your first example, you need to add a dummy joint  between one
>>>>>>> link in the robot and one in the hand, otherwise they will not be
>>>>>>> attached. You also need to add 'robots/' to the robot filenames
>>>>>>> otherwise openrave will not be able to find the robots unless they
>>>>>>> are
>>>>>>> inside the default robots directory. You also need to move the puma
>>>>>>> gripper
>>>>>>>
>>>>>>> Here's the fix:
>>>>>>>
>>>>>>> <Robot name="Puma">
>>>>>>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>>>>>>   </KinBody>
>>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>>     <body name="Puma6">
>>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>>       <translation>-0.03 0 0</translation>
>>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>>     </body>
>>>>>>>     <!-- add a dummy joint -->
>>>>>>>     <joint type="hinge" enable="false">
>>>>>>>       <body>link6</body>
>>>>>>>       <body>Puma6</body>
>>>>>>>       <limits>0 0</limits>
>>>>>>>     </joint>
>>>>>>>   </KinBody>
>>>>>>>   <Manipulator name="arm">
>>>>>>>     <effector>link6</effector>
>>>>>>>     <base>base</base>
>>>>>>>     <joints>m1</joints>
>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>     <direction>0 0 1</direction>
>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>   </Manipulator>
>>>>>>> </Robot>
>>>>>>>
>>>>>>>
>>>>>>> As for the example on the wiki, you need to add a <Manipulator>
>>>>>>> definition before using it.
>>>>>>>
>>>>>>> rosen,
>>>>>>>
>>>>>>>
>>>>>>> 2010/9/13  <[hidden email]>:
>>>>>>>> Hi Rosen,
>>>>>>>>
>>>>>>>> Thanks for the guidance on the ikfast and planner errors.
>>>>>>>>
>>>>>>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot.
>>>>>>>> Since
>>>>>>>> this arm does not have a gripper attached, I also attached the Puma
>>>>>>>> gripper
>>>>>>>> to the end of the robot as follows:
>>>>>>>>
>>>>>>>> <Robot name="Puma">
>>>>>>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>>>>>>     <KinBody file="pumagripper.kinbody.xml">
>>>>>>>>     </KinBody>
>>>>>>>>   </KinBody>
>>>>>>>>   <Manipulator name="arm">
>>>>>>>>     <effector>link6</effector>
>>>>>>>>         <base>base</base>
>>>>>>>>     <joints>m1</joints>
>>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>>     <direction>0 0 1</direction>
>>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>>   </Manipulator>
>>>>>>>> </Robot>
>>>>>>>>
>>>>>>>> I tried to visualize this new environment using "openrave.py -p
>>>>>>>> "env.Load('data/hanoi_complex.env.xml')" where hanoi_complex.env.xml
>>>>>>>> has
>>>>>>>> been modified to use the newly defined Kuka robot. However, I
>>>>>>>> received
>>>>>>>> the
>>>>>>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy
>>>>>>>> for
>>>>>>>> number of joints 7! Part of robot might not be moveable"
>>>>>>>>
>>>>>>>> Did I make an error while defining the robot and linking up the
>>>>>>>> different
>>>>>>>> components such as not specifying an additional joint between the
>>>>>>>> gripper
>>>>>>>> and arm?
>>>>>>>>
>>>>>>>> In addition, I also tried working with the Kuka Collada example
>>>>>>>> here:
>>>>>>>> http://openrave.programmingvision.com/index.php/Started:Formats. I
>>>>>>>> was
>>>>>>>> able
>>>>>>>> to visualize and generate the inverse kinematics successfully but
>>>>>>>> when
>>>>>>>> running the Hanoi example, it failed due to an assertion error from
>>>>>>>> the
>>>>>>>> following line: assert(len(jointinds)==len(jointvalues) and
>>>>>>>> len(jointinds)>0). Is this related to the previous error?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Matthew
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>>> Cc: [hidden email]
>>>>>>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>>> example
>>>>>>>>
>>>>>>>> hi Matthew,
>>>>>>>>
>>>>>>>> Thanks for the patch, I updated openrave.rosinstall
>>>>>>>>
>>>>>>>> You can ignore the ikfast errors should not be printed since the
>>>>>>>> puma
>>>>>>>> arm has a pre-generated ik file. You can ignore them.
>>>>>>>>
>>>>>>>> The planner is randomized, so it can fail at times. This is why
>>>>>>>> openrave calls it multiple times to guarantee a path is found if one
>>>>>>>> exists.
>>>>>>>>
>>>>>>>> rosen,
>>>>>>>>
>>>>>>>> 2010/9/6  <[hidden email]>:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I installed OpenRAVE and ROS via the instructions listed here on
>>>>>>>>> Ubuntu
>>>>>>>>> 10.04 x86_64:
>>>>>>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>>>>>>
>>>>>>>>> One change that I made was adding the pr2_calibration stack to the
>>>>>>>>> install
>>>>>>>>> file since calibration_experimental complained that it wasn't
>>>>>>>>> present
>>>>>>>>> as
>>>>>>>>> a
>>>>>>>>> dependency when running "rosdep install orrosplanning rviz" The
>>>>>>>>> added
>>>>>>>>> lines
>>>>>>>>> are listed below.
>>>>>>>>>
>>>>>>>>> - svn:
>>>>>>>>>     uri:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>>>>>>     local-name: stacks/pr2_calibration
>>>>>>>>>
>>>>>>>>> I had a previous SVN-based ROS installation (boxturtle) -- However,
>>>>>>>>> I
>>>>>>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>>>>>>
>>>>>>>>> When I go to run the Hanoi example using "openrave.py --example
>>>>>>>>> hanoi",
>>>>>>>>> I
>>>>>>>>> receive the following error:
>>>>>>>>>
>>>>>>>>> [ikfastproblem.h:206]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>>>>>>> cannot open shared object file: No such file or directory
>>>>>>>>> [ikfastproblem.h:131] failed to load library
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>>>>>>
>>>>>>>>> Should I be concerned with this error? The example runs
>>>>>>>>> successfully
>>>>>>>>> and
>>>>>>>>> terminates after the Towers of Hanoi problem is solved. There are
>>>>>>>>> also
>>>>>>>>> a
>>>>>>>>> couple of errors during the program such as
>>>>>>>>>
>>>>>>>>> [rrt.h:283] plan failed, 3.478000s
>>>>>>>>> [basemanipulation.h:867] PlanPath failed
>>>>>>>>>
>>>>>>>>> but I expect these are due to the arm using RRT for planning and a
>>>>>>>>> solution
>>>>>>>>> not being found within a certain number of iterations.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matthew
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> This SF.net Dev2Dev email is sponsored by:
>>>>>>>>>
>>>>>>>>> Show off your parallel programming skills.
>>>>>>>>> Enter the Intel(R) Threading Challenge 2010.
>>>>>>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>>>>>>> _______________________________________________
>>>>>>>>> Openrave-users mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>> and start using them to simplify application deployment and
>>>>>>>> accelerate your shift to cloud computing
>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Openrave-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>> and start using them to simplify application deployment and
>>>>>>> accelerate your shift to cloud computing.
>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>> _______________________________________________
>>>>>>> Openrave-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>> and start using them to simplify application deployment and
>>>>>> accelerate your shift to cloud computing.
>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>> _______________________________________________
>>>>>> Openrave-users mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>>>>> contest
>>>>> Create new apps & games for the Nokia N8 for consumers in  U.S. and
>>>>> Canada
>>>>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>>>>> marketing
>>>>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi
>>>>> Store
>>>>> http://p.sf.net/sfu/nokia-dev2dev
>>>>> _______________________________________________
>>>>> Openrave-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>
>>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
hi Matthew,

You are correct, ikfast does not check joint limits. If you think it
is necessary to check limits in the generated file, can you list
several reasons?

rosen,

2010/11/10  <[hidden email]>:

> Hi Rosen,
>
> Thanks again for all of your help. I've been using the ikfast generated ik
> and noticed that it returns solutions that are outside the joint limits
> specified in the robot.xml file. Is this to be expected? Are the joint
> limits handled on the OpenRAVE side?
>
> Thanks,
> Matthew
> ----- Original Message -----
> From: "Rosen Diankov" <[hidden email]>
> To: "matt cong" <[hidden email]>
> Cc: [hidden email]
> Sent: Friday, October 22, 2010 1:38:36 AM
> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>
> hi matthew,
>
> i see, you are using the generated C++ files as is without the
> openrave wrappers. Up the one week ago, the C++ files did not encode
> the grasp frame, it was premultiplied on the openrave side. However,
> this week I updated ikfast to incorporate grasp frame also. Can you
> try updating to the newest openrave and regenerate the ik?
>
> Also, kinematics are independent of geometry. the 'fk' function gives
> coordinates of the gripper frame with respect to the base link, 'ik'
> function takes coordinates of the gripper frame with respect to the
> baselink.
>
> rosen,
>
> 2010/10/22  <[hidden email]>:
>> Hi Rosen,
>>
>> Thank you for your help. I have attached the test scripts. They mostly do
>> conversions to ypr and degrees along with some adjustments for differing
>> conventions on the starting point of the robot, but these are all minor.
>>
>> Is it possible that the geometry is connected with the IK problems? I was
>> operating under the assumption that the meshes were only related to the
>> visual display, but I may have been wrong. Also, does the IK/FK give
>> coordinates with respect to the base of the robot or the starting position
>> of the end effector?
>>
>> Thanks,
>> Matthew
>> ----- Original Message -----
>> From: "Rosen Diankov" <[hidden email]>
>> To: "matt cong" <[hidden email]>
>> Sent: Friday, October 22, 2010 1:11:12 AM
>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi example
>>
>> either way, executing the following command to test the ik:
>>
>>  openrave.py --database inversekinematics
>> --robot=adeptComplete.robot.xml  --iktest=100
>>
>>
>> gives 100% success rate, so everything is working fine... perhaps
>> there is some misunderstanding on how the ik functions work... can you
>> send the test scripts you are using?
>>
>> rosen,
>>
>> 2010/10/22 Rosen Diankov <[hidden email]>:
>>> robot geometry looks broken...
>>> rosen,
>>>
>>> 2010/10/22  <[hidden email]>:
>>>> Hi Rosen,
>>>>
>>>> I have attached the robot and kinbody files.
>>>>
>>>> Thanks,
>>>> Matthew
>>>> ----- Original Message -----
>>>> From: "Rosen Diankov" <[hidden email]>
>>>> To: "matt cong" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Sent: Thursday, October 21, 2010 11:02:23 PM
>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>> example
>>>>
>>>> hi matthew,
>>>>
>>>> Setting the <effector> to one of the claws includes the claw joint as
>>>> part of the arm, which makes things a little more difficult (you can
>>>> still compute the ik if you set the claw as the free parameter).
>>>> However, it is ok to set the <effector> to the main body.
>>>>
>>>> In any case, you shouldn't be experiencing these problems, please send
>>>> your robot file.
>>>> rosen,
>>>>
>>>> 2010/10/22  <[hidden email]>:
>>>>> Hi Rosen,
>>>>>
>>>>> Thanks for the suggestion. However, I did not include the explicit
>>>>> iksolver
>>>>> tag when defining a new robot (which is very similar to the Kuka) from
>>>>> the
>>>>> gripper and robot body kinbody files. Sorry for being unclear.
>>>>>
>>>>> I checked the <offsetfrom> tags for each link in the kinbody files as
>>>>> well
>>>>> as the robot file. In addition, when I visualized the stationary model
>>>>> in
>>>>> an
>>>>> environment, the gripper was in the correct position. I also noticed
>>>>> the
>>>>> <effector> tag in the manipulator was set to the end effector of the
>>>>> main
>>>>> robot body but when I changed it to the new end effector body on the
>>>>> gripper
>>>>> (one of the two claws on the gripper), ikfast said that it could not
>>>>> divide
>>>>> rotation and translation after trying to take the inverse of the
>>>>> mechanism.
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>> To: "matt cong" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> Sent: Thursday, October 21, 2010 9:54:56 PM
>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>> example
>>>>>
>>>>> hi Matthew,
>>>>>
>>>>> Please remove the explicit iksolver tag, this forces a pre-compiled
>>>>> ikfast solver to be used, which is why you are getting wrong results.
>>>>> I'll see if we can add a warning message if this condition is ever
>>>>> detected.
>>>>>
>>>>> rosen,
>>>>>
>>>>> 2010/10/22  <[hidden email]>:
>>>>>> Hi Rosen,
>>>>>>
>>>>>> Thanks for the advice. I was able to use ikfast to generate fk and ik
>>>>>> for
>>>>>> the Kuka robot after changing the anchor tags to translation tags. I
>>>>>> verified that these gave correct solutions (such as the position of
>>>>>> the
>>>>>> end-effector with respect to the base in the world frame) by having it
>>>>>> print
>>>>>> out the positions returned by fk and ik.
>>>>>>
>>>>>> I defined a gripper (using the basic geometry types) and attached it
>>>>>> to
>>>>>> the
>>>>>> robot in a similar way to how I attached the Puma gripper to the body
>>>>>> of
>>>>>> the
>>>>>> Puma robot. However, when I regenerate the kinematics using ikfast and
>>>>>> test
>>>>>> them, I obtain the same results for the position of my end-effector as
>>>>>> the
>>>>>> configuration without the gripper (essentially without the additional
>>>>>> length
>>>>>> in the last link due to the gripper). Do you have some ideas as to how
>>>>>> to
>>>>>> resolve this? I noticed that the Puma has an explicitly specified
>>>>>> iksolver:
>>>>>> Is this needed when a manipulator is attached?
>>>>>>
>>>>>> Thanks,
>>>>>> Matthew
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>> To: "matt cong" <[hidden email]>
>>>>>> Cc: [hidden email]
>>>>>> Sent: Monday, September 27, 2010 4:43:57 AM
>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>> example
>>>>>>
>>>>>> Hi Matt,
>>>>>>
>>>>>> The reason you are not seeing any change is because link6 of kuka-r850
>>>>>> is at the origin of the robot. In fact, all links are at the origin,
>>>>>> which can be confirmed by calling Link.GetTransform(). You were
>>>>>> probably expecting link6 to be where the manipulator frame was
>>>>>> defined.
>>>>>>
>>>>>> In any case, you have to change the translation of Puma6 to "0.56 0
>>>>>> 0.79"
>>>>>>
>>>>>> rosen,
>>>>>>
>>>>>> 2010/9/27  <[hidden email]>:
>>>>>>> Hi Rosen,
>>>>>>>
>>>>>>> Thank you once again for the prompt reply. It was very helpful.
>>>>>>>
>>>>>>> I looked at the XML again and it appears that the <offsetfrom> is set
>>>>>>> correctly. However, when I do transformations, they are still
>>>>>>> relative
>>>>>>> to
>>>>>>> the base which makes me think that an offsetfrom is spacified
>>>>>>> incorrectly.
>>>>>>> Here's the file:
>>>>>>>
>>>>>>> <Robot name="Kuka">
>>>>>>>   <KinBody file="robots/kuka-kr5-r850.kinbody.xml">
>>>>>>>   </KinBody>
>>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>>     <body name="Puma6">
>>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>>       <translation>0.10 0 0</translation>
>>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>>     </body>
>>>>>>>     <joint name="j6" type="hinge" enable="false">
>>>>>>>       <body>link6</body>
>>>>>>>       <body>Puma6</body>
>>>>>>>       <offsetfrom>Puma6</offsetfrom>
>>>>>>>       <limits>0 0</limits>
>>>>>>>     </joint>
>>>>>>>   </KinBody>
>>>>>>>   <Manipulator name="arm">
>>>>>>>     <effector>link6</effector>
>>>>>>>     <base>base</base>
>>>>>>>     <joints>m1</joints>
>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>     <direction>0 0 1</direction>
>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>   </Manipulator>
>>>>>>> </Robot>
>>>>>>>
>>>>>>> I looked through the Kuka-kr5-r850 (the one that came with OpenRAVE)
>>>>>>> and
>>>>>>> the
>>>>>>> last joint is indeed named "link6". I also tried setting the joint
>>>>>>> anchor
>>>>>>> but that had no effect. Do you have any suggestions?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matthew
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>> Cc: [hidden email]
>>>>>>> Sent: Sunday, September 26, 2010 11:52:21 PM
>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>> example
>>>>>>>
>>>>>>> Hi Matthew,
>>>>>>>
>>>>>>> The <translation> tag sets the link transformations. The <anchor> tag
>>>>>>> sets the offset of the joint anchor axis. By default, the joint
>>>>>>> anchor
>>>>>>> is at the origin of the "offset link" specified. If you do not care
>>>>>>> about link transformations, then either <anchor> and <translation>
>>>>>>> can
>>>>>>> be interchanged.
>>>>>>>
>>>>>>> To debug your problem, first make sure the gripper is attached to the
>>>>>>> correct link. Make sure the "offset from" is correct.
>>>>>>>
>>>>>>> The ikfast program accepts transformations with respect to the base
>>>>>>> link of the manipulator specified. In order to debug your code,
>>>>>>> you'll
>>>>>>> notice that the cpp file also defines a forward kinematics function
>>>>>>> 'fk' that you can use to input joint angles to get the end effector
>>>>>>> transformation. Inserting this transformation back into the ik should
>>>>>>> give you a correct solution.
>>>>>>>
>>>>>>> good luck!
>>>>>>> rosen,
>>>>>>>
>>>>>>> 2010/9/27  <[hidden email]>:
>>>>>>>> Hi Rosen,
>>>>>>>>
>>>>>>>> Thanks for the fix before -- It worked out great.
>>>>>>>>
>>>>>>>> I'm now trying to do the same thing with the Kuka r850 robot: I
>>>>>>>> modified
>>>>>>>> the
>>>>>>>> fixed XML file that you sent me by changing the first kinbody file
>>>>>>>> to
>>>>>>>> be
>>>>>>>> the
>>>>>>>> r850 kinbody as opposed to the r650 kinbody. However, when I
>>>>>>>> visualize
>>>>>>>> this
>>>>>>>> in the environment, the Puma gripper appears at the base of the
>>>>>>>> robot.
>>>>>>>> In
>>>>>>>> addition, when running the example, I obtain the following: openrave
>>>>>>>> planning_error: 'MoveUnsyncJoints'. Do you have any suggestions as
>>>>>>>> to
>>>>>>>> how
>>>>>>>> I
>>>>>>>> could proceed?
>>>>>>>>
>>>>>>>> Upon looking through the kuka850 kinbody and comparing it to that of
>>>>>>>> 650,
>>>>>>>> I
>>>>>>>> noticed that the only differences were <anchor> being specified as
>>>>>>>> opposed
>>>>>>>> to <translation> Could you explain the difference between these two
>>>>>>>> different ways of specifying the robot? I tried converting them to
>>>>>>>> equivalent translations but the r850 visualization had links
>>>>>>>> floating
>>>>>>>> at
>>>>>>>> unconnected positions in space.
>>>>>>>>
>>>>>>>> I have also used ikfast to compile a standalone C++ executable for
>>>>>>>> the
>>>>>>>> r650
>>>>>>>> arm: Once compiled, I tried running it and got "Failed to get IK
>>>>>>>> solution."
>>>>>>>> Is this because the coordinates I've specified are not within range
>>>>>>>> of
>>>>>>>> the
>>>>>>>> robot? Is there a similar way of getting a standalone FK program as
>>>>>>>> well
>>>>>>>> or
>>>>>>>> is it just implicitly included in the model?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Matthew
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>>> Cc: [hidden email]"
>>>>>>>> Sent: Sunday, September 12, 2010 7:56:53 PM
>>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>>> example
>>>>>>>>
>>>>>>>> Hi Matt,
>>>>>>>>
>>>>>>>> For your first example, you need to add a dummy joint  between one
>>>>>>>> link in the robot and one in the hand, otherwise they will not be
>>>>>>>> attached. You also need to add 'robots/' to the robot filenames
>>>>>>>> otherwise openrave will not be able to find the robots unless they
>>>>>>>> are
>>>>>>>> inside the default robots directory. You also need to move the puma
>>>>>>>> gripper
>>>>>>>>
>>>>>>>> Here's the fix:
>>>>>>>>
>>>>>>>> <Robot name="Puma">
>>>>>>>>   <KinBody file="robots/kuka-kr5-r650.kinbody.xml">
>>>>>>>>   </KinBody>
>>>>>>>>   <KinBody file="robots/pumagripper.kinbody.xml">
>>>>>>>>     <body name="Puma6">
>>>>>>>>       <offsetfrom>link6</offsetfrom>
>>>>>>>>       <translation>-0.03 0 0</translation>
>>>>>>>>       <rotationaxis>0 1 0 90</rotationaxis>
>>>>>>>>     </body>
>>>>>>>>     <!-- add a dummy joint -->
>>>>>>>>     <joint type="hinge" enable="false">
>>>>>>>>       <body>link6</body>
>>>>>>>>       <body>Puma6</body>
>>>>>>>>       <limits>0 0</limits>
>>>>>>>>     </joint>
>>>>>>>>   </KinBody>
>>>>>>>>   <Manipulator name="arm">
>>>>>>>>     <effector>link6</effector>
>>>>>>>>     <base>base</base>
>>>>>>>>     <joints>m1</joints>
>>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>>     <direction>0 0 1</direction>
>>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>>   </Manipulator>
>>>>>>>> </Robot>
>>>>>>>>
>>>>>>>>
>>>>>>>> As for the example on the wiki, you need to add a <Manipulator>
>>>>>>>> definition before using it.
>>>>>>>>
>>>>>>>> rosen,
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/9/13  <[hidden email]>:
>>>>>>>>> Hi Rosen,
>>>>>>>>>
>>>>>>>>> Thanks for the guidance on the ikfast and planner errors.
>>>>>>>>>
>>>>>>>>> I'm looking to run the Hanoi example with the kuka-kr5-r650 robot.
>>>>>>>>> Since
>>>>>>>>> this arm does not have a gripper attached, I also attached the Puma
>>>>>>>>> gripper
>>>>>>>>> to the end of the robot as follows:
>>>>>>>>>
>>>>>>>>> <Robot name="Puma">
>>>>>>>>>   <KinBody file="kuka-kr5-r650.kinbody.xml">
>>>>>>>>>     <KinBody file="pumagripper.kinbody.xml">
>>>>>>>>>     </KinBody>
>>>>>>>>>   </KinBody>
>>>>>>>>>   <Manipulator name="arm">
>>>>>>>>>     <effector>link6</effector>
>>>>>>>>>         <base>base</base>
>>>>>>>>>     <joints>m1</joints>
>>>>>>>>>     <!-- joint values of the closed and opened positions -->
>>>>>>>>>     <closingdirection>1</closingdirection>
>>>>>>>>>     <direction>0 0 1</direction>
>>>>>>>>>     <!-- grasp goal with respect to the effector -->
>>>>>>>>>     <Translation>0 0 0.175</Translation>
>>>>>>>>>   </Manipulator>
>>>>>>>>> </Robot>
>>>>>>>>>
>>>>>>>>> I tried to visualize this new environment using "openrave.py -p
>>>>>>>>> "env.Load('data/hanoi_complex.env.xml')" where
>>>>>>>>> hanoi_complex.env.xml
>>>>>>>>> has
>>>>>>>>> been modified to use the newly defined Kuka robot. However, I
>>>>>>>>> received
>>>>>>>>> the
>>>>>>>>> following error: "[KinBody.cpp:2387] Cannot compute joint hierarchy
>>>>>>>>> for
>>>>>>>>> number of joints 7! Part of robot might not be moveable"
>>>>>>>>>
>>>>>>>>> Did I make an error while defining the robot and linking up the
>>>>>>>>> different
>>>>>>>>> components such as not specifying an additional joint between the
>>>>>>>>> gripper
>>>>>>>>> and arm?
>>>>>>>>>
>>>>>>>>> In addition, I also tried working with the Kuka Collada example
>>>>>>>>> here:
>>>>>>>>> http://openrave.programmingvision.com/index.php/Started:Formats. I
>>>>>>>>> was
>>>>>>>>> able
>>>>>>>>> to visualize and generate the inverse kinematics successfully but
>>>>>>>>> when
>>>>>>>>> running the Hanoi example, it failed due to an assertion error from
>>>>>>>>> the
>>>>>>>>> following line: assert(len(jointinds)==len(jointvalues) and
>>>>>>>>> len(jointinds)>0). Is this related to the previous error?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matthew
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Rosen Diankov" <[hidden email]>
>>>>>>>>> To: "matt cong" <[hidden email]>
>>>>>>>>> Cc: [hidden email]
>>>>>>>>> Sent: Tuesday, September 7, 2010 4:36:39 AM
>>>>>>>>> Subject: Re: [OpenRAVE-users] Error with ikfast when running Hanoi
>>>>>>>>> example
>>>>>>>>>
>>>>>>>>> hi Matthew,
>>>>>>>>>
>>>>>>>>> Thanks for the patch, I updated openrave.rosinstall
>>>>>>>>>
>>>>>>>>> You can ignore the ikfast errors should not be printed since the
>>>>>>>>> puma
>>>>>>>>> arm has a pre-generated ik file. You can ignore them.
>>>>>>>>>
>>>>>>>>> The planner is randomized, so it can fail at times. This is why
>>>>>>>>> openrave calls it multiple times to guarantee a path is found if
>>>>>>>>> one
>>>>>>>>> exists.
>>>>>>>>>
>>>>>>>>> rosen,
>>>>>>>>>
>>>>>>>>> 2010/9/6  <[hidden email]>:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I installed OpenRAVE and ROS via the instructions listed here on
>>>>>>>>>> Ubuntu
>>>>>>>>>> 10.04 x86_64:
>>>>>>>>>> http://openrave.programmingvision.com/index.php/Installation
>>>>>>>>>>
>>>>>>>>>> One change that I made was adding the pr2_calibration stack to the
>>>>>>>>>> install
>>>>>>>>>> file since calibration_experimental complained that it wasn't
>>>>>>>>>> present
>>>>>>>>>> as
>>>>>>>>>> a
>>>>>>>>>> dependency when running "rosdep install orrosplanning rviz" The
>>>>>>>>>> added
>>>>>>>>>> lines
>>>>>>>>>> are listed below.
>>>>>>>>>>
>>>>>>>>>> - svn:
>>>>>>>>>>     uri:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_calibration/tags/cturtle
>>>>>>>>>>     local-name: stacks/pr2_calibration
>>>>>>>>>>
>>>>>>>>>> I had a previous SVN-based ROS installation (boxturtle) --
>>>>>>>>>> However,
>>>>>>>>>> I
>>>>>>>>>> removed the ROS directory and all references in my ~/.bashrc.
>>>>>>>>>>
>>>>>>>>>> When I go to run the Hanoi example using "openrave.py --example
>>>>>>>>>> hanoi",
>>>>>>>>>> I
>>>>>>>>>> receive the following error:
>>>>>>>>>>
>>>>>>>>>> [ikfastproblem.h:206]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so:
>>>>>>>>>> cannot open shared object file: No such file or directory
>>>>>>>>>> [ikfastproblem.h:131] failed to load library
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /home/mdc238/.openrave/kinematics.1212e32be9160d1dd10dda70c49c46d3/ikfast10.Transform6D.x86_64.so
>>>>>>>>>>
>>>>>>>>>> Should I be concerned with this error? The example runs
>>>>>>>>>> successfully
>>>>>>>>>> and
>>>>>>>>>> terminates after the Towers of Hanoi problem is solved. There are
>>>>>>>>>> also
>>>>>>>>>> a
>>>>>>>>>> couple of errors during the program such as
>>>>>>>>>>
>>>>>>>>>> [rrt.h:283] plan failed, 3.478000s
>>>>>>>>>> [basemanipulation.h:867] PlanPath failed
>>>>>>>>>>
>>>>>>>>>> but I expect these are due to the arm using RRT for planning and a
>>>>>>>>>> solution
>>>>>>>>>> not being found within a certain number of iterations.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Matthew
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> This SF.net Dev2Dev email is sponsored by:
>>>>>>>>>>
>>>>>>>>>> Show off your parallel programming skills.
>>>>>>>>>> Enter the Intel(R) Threading Challenge 2010.
>>>>>>>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Openrave-users mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>>> and start using them to simplify application deployment and
>>>>>>>>> accelerate your shift to cloud computing
>>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Openrave-users mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>> and start using them to simplify application deployment and
>>>>>>>> accelerate your shift to cloud computing.
>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>> _______________________________________________
>>>>>>>> Openrave-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>> and start using them to simplify application deployment and
>>>>>>> accelerate your shift to cloud computing.
>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>> _______________________________________________
>>>>>>> Openrave-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>>>>>> contest
>>>>>> Create new apps & games for the Nokia N8 for consumers in  U.S. and
>>>>>> Canada
>>>>>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>>>>>> marketing
>>>>>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi
>>>>>> Store
>>>>>> http://p.sf.net/sfu/nokia-dev2dev
>>>>>> _______________________________________________
>>>>>> Openrave-users mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users