Error with ikfast when running Hanoi example

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

Error with ikfast when running Hanoi example

matt.cong
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
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
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
>
>

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

coord-crosses everywhere

Daniel Leidner-2
In reply to this post by matt.cong
Hi Rosen,

as i refreshed our robot model, i noticed that there are now a lot of
coord-crosses appearing when i select one of its manipulators.
i think this is pretty annoying. i think it would be much better if i
would just see the tcp of the manipulator...
i am not sure whats your intention with that amount of coords ;-) maybe
we can discuss it, or just leave it as it is.

ciao daniel

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

coords.png (324K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: coord-crosses everywhere

Peter Brook-2

I actually thought that it was a useful feature for tracking down geometry bugs and unexpected behavior. However, it does seem like something that should be user disableable.

Peter

On Sep 7, 2010 2:29 AM, "Daniel Leidner" <[hidden email]> wrote:
> Hi Rosen,
>
> as i refreshed our robot model, i noticed that there are now a lot of
> coord-crosses appearing when i select one of its manipulators.
> i think this is pretty annoying. i think it would be much better if i
> would just see the tcp of the manipulator...
> i am not sure whats your intention with that amount of coords ;-) maybe
> we can discuss it, or just leave it as it is.
>
> ciao daniel


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

patch for ikfast

Daniel Leidner-2
In reply to this post by matt.cong
Hi Rosen,

i had a problem with the ikfast generation. it is not guaranteed that
SoDB::readlock() in xmlreaders.h works correctly,
especially our huge robot model created a segmentation fault due to a
race conditions or something like that.
i attached the patch we applied in openravepy_init.cpp.

i am not sure if this is a good place for the patch, but it will help
you to find the issue.

ciao Daniel

--- python/bindings/openravepy_int.cpp.org 2010-09-07 13:47:58.472890493 +0200
+++ python/bindings/openravepy_int.cpp 2010-09-07 13:47:51.215843125 +0200
@@ -48,6 +48,10 @@
 #include "bindings.h"
 #include "docstrings.h"
 
+#ifdef OPENRAVE_COIN3D
+#include <Inventor/SoDB.h>
+#endif
+
 #define CHECK_POINTER(p) { \
         if( !(p) ) throw openrave_exception(boost::str(boost::format("[%s:%d]: invalid pointer")%__PRETTY_FUNCTION__%__LINE__)); \
 }
@@ -3369,6 +3373,10 @@
     T_from_number<float>();
     T_from_number<double>();
     init_python_bindings();
+#ifdef OPENRAVE_COIN3D
+    if(!SoDB::isInitialized())
+      SoDB::init();
+#endif
 
     typedef return_value_policy< copy_const_reference > return_copy_const_ref;
     class_< openrave_exception >( "_openrave_exception_", DOXY_CLASS(openrave_exception) )

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: patch for ikfast

Rosen Diankov
Administrator
hi daniel,

thanks, the appropriate change was made  xmlreaders in r1719.

rosen,

2010/9/7 Daniel Leidner <[hidden email]>:

> Hi Rosen,
>
> i had a problem with the ikfast generation. it is not guaranteed that
> SoDB::readlock() in xmlreaders.h works correctly,
> especially our huge robot model created a segmentation fault due to a
> race conditions or something like that.
> i attached the patch we applied in openravepy_init.cpp.
>
> i am not sure if this is a good place for the patch, but it will help
> you to find the issue.
>
> ciao Daniel
>
> ------------------------------------------------------------------------------
> 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
>
>

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: coord-crosses everywhere

Rosen Diankov
Administrator
In reply to this post by Peter Brook-2
Hi guys,

What do you think about the link axes being draw smaller and darker?
i'm attaching a snapshot, it is also updated at r1720

rosen,

2010/9/7 Peter Brook <[hidden email]>:

> I actually thought that it was a useful feature for tracking down geometry
> bugs and unexpected behavior. However, it does seem like something that
> should be user disableable.
>
> Peter
>
> On Sep 7, 2010 2:29 AM, "Daniel Leidner" <[hidden email]> wrote:
>> Hi Rosen,
>>
>> as i refreshed our robot model, i noticed that there are now a lot of
>> coord-crosses appearing when i select one of its manipulators.
>> i think this is pretty annoying. i think it would be much better if i
>> would just see the tcp of the manipulator...
>> i am not sure whats your intention with that amount of coords ;-) maybe
>> we can discuss it, or just leave it as it is.
>>
>> ciao daniel
>
> ------------------------------------------------------------------------------
> 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
>
>

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

small_axes.png (200K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: coord-crosses everywhere

Daniel Leidner-2
hi all

i like it, now you can see the difference between the links and the tcp.
also you can "tracking down geometry bugs and unexpected behavior"

daniel

Rosen Diankov wrote:

> Hi guys,
>
> What do you think about the link axes being draw smaller and darker?
> i'm attaching a snapshot, it is also updated at r1720
>
> rosen,
>
> 2010/9/7 Peter Brook <[hidden email]>:
>  
>> I actually thought that it was a useful feature for tracking down geometry
>> bugs and unexpected behavior. However, it does seem like something that
>> should be user disableable.
>>
>> Peter
>>
>> On Sep 7, 2010 2:29 AM, "Daniel Leidner" <[hidden email]> wrote:
>>    
>>> Hi Rosen,
>>>
>>> as i refreshed our robot model, i noticed that there are now a lot of
>>> coord-crosses appearing when i select one of its manipulators.
>>> i think this is pretty annoying. i think it would be much better if i
>>> would just see the tcp of the manipulator...
>>> i am not sure whats your intention with that amount of coords ;-) maybe
>>> we can discuss it, or just leave it as it is.
>>>
>>> ciao daniel
>>>      
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>>    
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> 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
>>    


------------------------------------------------------------------------------
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
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 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
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
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

kuka_puma.jpg (40K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

matt.cong
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
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

matt.cong
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
Reply | Threaded
Open this post in threaded view
|

Re: Error with ikfast when running Hanoi example

Rosen Diankov
Administrator
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
>
>

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