Hinge2 functionality

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

Hinge2 functionality

icoderaven
Hi!

I'm working on a 5 DoF robot arm with a gripper. It's a SCORBOT ER-4U.

Now, I am trying to implement a two DoF joint at the wrist.

When I just add a hinge about one axis, the wrist loads correctly, and can even be rotated in the environment.

However, when I try to add another axis (I assume that it should be of the type hinge2), the link is rendered with an offset, and although the rotation placeholders come up correctly, the moment I try rotating the wrist, the GUI crashes with the following error:

terminate called after throwing an instance of 'OpenRAVE::openrave_exception'
  what():  openrave (InvalidArguments): [virtual void OpenRAVE::KinBody::Joint::GetVelocities(std::vector<double, std::allocator<double> >&, bool) const:1230] unknown joint type 0x80000002
Aborted

I've attached a screenshotScreenshot

From one of the archived posts I read that hinge2 joints weren't supported then. Is it still the case now?

Also, from the same post it was recommended that it would be better to use two hinges with intersecting axes. How can I implement that for the same body?

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Hinge2 functionality

icoderaven
To replicate the issue, I've attached the WRL files and the XML file.
Thanks!
er4u.xml
er4u.tar.gz
Reply | Threaded
Open this post in threaded view
|

Re: Hinge2 functionality

Rosen Diankov
Administrator
some functions in hinge2 joints are not implemented yet, sorry about that ;0)

Attached is an XML file with two hinge joints. Note how we created a
dummy wrist2 link.

Some notes you should keep in mind when using openrave:

- don't develop on /usr/share/openrave-0.6, instead manage all your
files in a local directory in your home and set OPENRAVE_DATA to it

- before setting every link to modifiable="false", please read the
documentation on modifiable:

http://openrave.programmingvision.com/wiki/index.php/Format:XML#Modifiable_Geometry

hope this helps,
rosen,

2012/4/7 icoderaven <[hidden email]>:

> To replicate the issue, I've attached the WRL files and the XML file.
> Thanks!
> http://openrave-users-list.185357.n3.nabble.com/file/n3892480/er4u.xml
> er4u.xml
> http://openrave-users-list.185357.n3.nabble.com/file/n3892480/er4u.tar.gz
> er4u.tar.gz
>
> --
> View this message in context: http://openrave-users-list.185357.n3.nabble.com/Hinge2-functionality-tp3888429p3892480.html
> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users

er4u.xml (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hinge2 functionality

icoderaven
Thanks for this Rosen!

It makes sense to implement this dummy link, just that I wasn't too comfortable not being able to manipulate it using the GUI :)

I'm sorry, but I didn't get why I should consider setting the robot link geometry to be modifiable. (Or perhaps I understand incorrectly)
a. It will make the collision detection faster, because the arm will be well padded
b. I really don't want the links to be deformed.

Does modifiable geometry mean that the WRLs themselves could be affected, like getting deformed on collisions?

Or does it imply that it allows a padding on top, which would mean that I should set the geometries of all the links except the gripper to be modifiable.


Also, since my robot axes are Y upwards, do I have to change the Body Coordinate System as mentioned on the same page?

Thanks for your patience!
Reply | Threaded
Open this post in threaded view
|

Re: Hinge2 functionality

icoderaven
Okay, so I've progressed further, thanks to your help, but now am stuck at the IK generation step.

If I choose the default (transform6D) I get an error stating that the DoFs (5) are < 6, so it can't find solutions.

Looking at the various IK solvers available, I felt that TranslationDirection5D suits my robot the best, because my gripper actuates linearly (It's driven by a leadscrew running through the center of the gripper attachment). However, when I try setting that as a param, I get this error:

NameError: global name 'jointvars' is not defined

I've attached a log of the error (error5D.log)5Derror.log

I then tried using the Rotation3D IK solver, and it seemed to work, but after ~25 minutes or so, I manually stopped its execution (It was working on an incorrect model, anyway) (Rot3Derror.log)Rot3Derror.log

Also, I'm also not sure if I've specified the gripper manipulator tag correctly. I feel that one of my gripper jaws should mimic the other, but in the opposite direction. Additionally, I can't seem to make their movement finer. No combination of resolution or maxvel seems to help, and nor can I find a limit tag for sliding joints.

I've attached the updated WRLs and XML file as well.

er4u.xml
er4u.tar.bz2

Thanks for helping me out!
Reply | Threaded
Open this post in threaded view
|

Re: Hinge2 functionality

Rosen Diankov
Administrator
You had a manipulator direction of [0, 0, 1], which was aligning with
one of your axes. After setting that to [0,1,0], the ik works.

For the slider joint limits, you can use

<limits>0 0.01</limits>

As for modifiable geometry, please only set it to true for the
grippers. The padding is optional and can be loaded with the
convexdecomposition database.

rosen,

2012/4/8 icoderaven <[hidden email]>:

> Okay, so I've progressed further, thanks to your help, but now am stuck at
> the IK generation step.
>
> If I choose the default (transform6D) I get an error stating that the DoFs
> (5) are < 6, so it can't find solutions.
>
> Looking at the various IK solvers available, I felt that
> TranslationDirection5D suits my robot the best, because my gripper actuates
> linearly (It's driven by a leadscrew running through the center of the
> gripper attachment). However, when I try setting that as a param, I get this
> error:
>
> NameError: global name 'jointvars' is not defined
>
> I've attached a log of the error (error5D.log)
> http://openrave-users-list.185357.n3.nabble.com/file/n3894168/5Derror.log
> 5Derror.log
>
> I then tried using the Rotation3D IK solver, and it seemed to work, but
> after ~25 minutes or so, I manually stopped its execution (It was working on
> an incorrect model, anyway) (Rot3Derror.log)
> http://openrave-users-list.185357.n3.nabble.com/file/n3894168/Rot3Derror.log
> Rot3Derror.log
>
> Also, I'm also not sure if I've specified the gripper manipulator tag
> correctly. I feel that one of my gripper jaws should mimic the other, but in
> the opposite direction. Additionally, I can't seem to make their movement
> finer. No combination of resolution or maxvel seems to help, and nor can I
> find a limit tag for sliding joints.
>
> I've attached the updated WRLs and XML file as well.
>
> http://openrave-users-list.185357.n3.nabble.com/file/n3894168/er4u.xml
> er4u.xml
> http://openrave-users-list.185357.n3.nabble.com/file/n3894168/er4u.tar.bz2
> er4u.tar.bz2
>
> Thanks for helping me out!
>
> --
> View this message in context: http://openrave-users-list.185357.n3.nabble.com/Hinge2-functionality-tp3888429p3894168.html
> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users

er4u.xml (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Grasping issues

icoderaven
Hi Rosen

Thanks for your previous reply! It did help me to move forward. Now I've been able to get the arm to move to specific 3D points, and use the TranslationDirection5D IK solver to get the arm to move to the target on -very few- configurations. Is that normal? I see that someone had similar issues http://openrave-users-list.185357.n3.nabble.com/IK-Performance-amp-IK-vs-Grasp-Manipulator-Directions-td3440764.html earlier.

I used to get collision errors with my previous CAD model (when I turned to verbose mode), and so I changed it to eliminate the self collisions. I also changed the gripper joints from being slider joints to revolute since I felt that revolute joints are better supported.

I then moved towards trying to set up a grasp database, but although it evaluates the 112 grasps, it doesn't find a single good grasp. Is it because there are just two grippers? Also, in the Openrave window, at no point of time are the grippers over the box, whereas other robot manipulators completely enclose it.

I tried playing around with the grasp goal distance and the grasping direction (to [0 0 1]) in the manipulator XML section, but to no avail. I also noticed that changing the latter severely reduced IK results (I think that's because of the axis aligning with that of one of the joints, like you mentioned earlier)

So now I have two main queries
a. How do I get the IK solutions over more than a few (hard to find) locations
b. How do I get the grasps to work, i.e. get 'good' grasps?

As always, thanks a lot for helping me out!

I've attached files for your reference
er4u.tar.bz2
Or you could check out a copy from my repo https://github.com/icoderaven/aar-arm
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

Rosen Diankov
Administrator
Sorry for the late reply,

There were three things wrong with the grasps you were generating:

1. you were using the default approach direction, which is not correct
(image attached). unfortunately because of the 5d ik, you do need to
have that as the default direction, fortunately grasping allows you to
specify custom manipulator directions.

2. given how small your target object is, you should be sampling it finer

3. your finger closing direction was wrong, it should be all negative
values. modify to:

            <closingdirection>-1 -1</closingdirection>

Once you fix your

Then use this generate command:
    gmodel.generate(approachrays=gmodel.computeBoxApproachRays(delta=0.004,normalanglerange=0),manipulatordirections=array([[0,0,1]]))

You should get *a lot* of successful grasps now.

Furthermore, you can parallelize the computation by putting  this
before the generate call:

gmodel.numthreads = 3 # use three threads for computation


hope this helps!
rosen,

2012/5/14 icoderaven <[hidden email]>:

> Hi Rosen
>
> Thanks for your previous reply! It did help me to move forward. Now I've
> been able to get the arm to move to specific 3D points, and use the
> TranslationDirection5D IK solver to get the arm to move to the target on
> -very few- configurations. Is that normal? I see that someone had similar
> issues
> http://openrave-users-list.185357.n3.nabble.com/IK-Performance-amp-IK-vs-Grasp-Manipulator-Directions-td3440764.html
> earlier.
>
> I used to get collision errors with my previous CAD model (when I turned to
> verbose mode), and so I changed it to eliminate the self collisions. I also
> changed the gripper joints from being slider joints to revolute since I felt
> that revolute joints are better supported.
>
> I then moved towards trying to set up a grasp database, but although it
> evaluates the 112 grasps, it doesn't find a single good grasp. Is it because
> there are just two grippers? Also, in the Openrave window, at no point of
> time are the grippers over the box, whereas other robot manipulators
> completely enclose it.
>
> I tried playing around with the grasp goal distance and the grasping
> direction (to [0 0 1]) in the manipulator XML section, but to no avail. I
> also noticed that changing the latter severely reduced IK results (I think
> that's because of the axis aligning with that of one of the joints, like you
> mentioned earlier)
>
> So now I have two main queries
> a. How do I get the IK solutions over more than a few (hard to find)
> locations
> b. How do I get the grasps to work, i.e. get 'good' grasps?
>
> As always, thanks a lot for helping me out!
>
> I've attached files for your reference
> http://openrave-users-list.185357.n3.nabble.com/file/n3984508/er4u.tar.bz2
> er4u.tar.bz2
> Or you could check out a copy from my repo
> https://github.com/icoderaven/aar-arm
>
>
> --
> View this message in context: http://openrave-users-list.185357.n3.nabble.com/Hinge2-functionality-tp3888429p3984508.html
> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

Rosen Diankov
Administrator
forgot to attach the image

2012/5/21 Rosen Diankov <[hidden email]>:

> Sorry for the late reply,
>
> There were three things wrong with the grasps you were generating:
>
> 1. you were using the default approach direction, which is not correct
> (image attached). unfortunately because of the 5d ik, you do need to
> have that as the default direction, fortunately grasping allows you to
> specify custom manipulator directions.
>
> 2. given how small your target object is, you should be sampling it finer
>
> 3. your finger closing direction was wrong, it should be all negative
> values. modify to:
>
>            <closingdirection>-1 -1</closingdirection>
>
> Once you fix your
>
> Then use this generate command:
>    gmodel.generate(approachrays=gmodel.computeBoxApproachRays(delta=0.004,normalanglerange=0),manipulatordirections=array([[0,0,1]]))
>
> You should get *a lot* of successful grasps now.
>
> Furthermore, you can parallelize the computation by putting  this
> before the generate call:
>
> gmodel.numthreads = 3 # use three threads for computation
>
>
> hope this helps!
> rosen,
>
> 2012/5/14 icoderaven <[hidden email]>:
>> Hi Rosen
>>
>> Thanks for your previous reply! It did help me to move forward. Now I've
>> been able to get the arm to move to specific 3D points, and use the
>> TranslationDirection5D IK solver to get the arm to move to the target on
>> -very few- configurations. Is that normal? I see that someone had similar
>> issues
>> http://openrave-users-list.185357.n3.nabble.com/IK-Performance-amp-IK-vs-Grasp-Manipulator-Directions-td3440764.html
>> earlier.
>>
>> I used to get collision errors with my previous CAD model (when I turned to
>> verbose mode), and so I changed it to eliminate the self collisions. I also
>> changed the gripper joints from being slider joints to revolute since I felt
>> that revolute joints are better supported.
>>
>> I then moved towards trying to set up a grasp database, but although it
>> evaluates the 112 grasps, it doesn't find a single good grasp. Is it because
>> there are just two grippers? Also, in the Openrave window, at no point of
>> time are the grippers over the box, whereas other robot manipulators
>> completely enclose it.
>>
>> I tried playing around with the grasp goal distance and the grasping
>> direction (to [0 0 1]) in the manipulator XML section, but to no avail. I
>> also noticed that changing the latter severely reduced IK results (I think
>> that's because of the axis aligning with that of one of the joints, like you
>> mentioned earlier)
>>
>> So now I have two main queries
>> a. How do I get the IK solutions over more than a few (hard to find)
>> locations
>> b. How do I get the grasps to work, i.e. get 'good' grasps?
>>
>> As always, thanks a lot for helping me out!
>>
>> I've attached files for your reference
>> http://openrave-users-list.185357.n3.nabble.com/file/n3984508/er4u.tar.bz2
>> er4u.tar.bz2
>> Or you could check out a copy from my repo
>> https://github.com/icoderaven/aar-arm
>>
>>
>> --
>> View this message in context: http://openrave-users-list.185357.n3.nabble.com/Hinge2-functionality-tp3888429p3984508.html
>> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Openrave-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/openrave-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users

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

Re: Grasping issues

icoderaven
In reply to this post by Rosen Diankov
Thanks for your reply!

So, it is definitely computing successful grasps now! What I probably forgot to comprehend was that my approach direction just for grasping could be specified as being different from that mentioned in the XML

Unfortunately, when I call gmodel.computeValidGrasps() with checkIk=True, I get the following error:

computing first 5 valid grasps
Traceback (most recent call last):
  File "/home/kshaurya/aar-arm/scripts/src/try.py", line 63, in <module>
    validgrasps,validindices = gmodel.computeValidGrasps(returnnum=returnnum, checkik=True)
  File "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_/databases/grasping.py", line 778, in computeValidGrasps
    ikparam = IkParameterization(Ray(Tglobalgrasp[0:3,3],dot(Tglobalgrasp[0:3,0:3],self.manip.GetDirection())),IkParameterization.Type.TranslationDirection5D)
NameError: global name 'Ray' is not defined

Probably it needs to be referenced from another class / it requires an import.
Instead, could it just be
ikparam = IkParameterization( [Tglobalgrasp[0:3,3],dot(Tglobalgrasp[0:3,0:3],self.manip.GetDirection())], IkParameterization.Type.TranslationDirection5D)
You seem to have used something like this in this example as well.

(I'm sorry, I'm a bit green at Python)

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

Rosen Diankov
Administrator
computeValidGrasps expects an Transform6D ik solver. Your robot only
supports TranslationDirection5D, therefore you cannot use it.

You'll have to call the TaskManipulation.GraspPlanning function
directly to choose the grasps. The GraspPlanning function supports
both Transform6D and TranslationDirection5D.

if you need to debug, here's a working demo of 5D IK grasp planning:

http://openrave.org/en/main/openravepy/examples.graspplanning.html#neuronics-katana

rosen,

2012/5/21 icoderaven <[hidden email]>:

> Thanks for your reply!
>
> So, it is definitely computing successful grasps now! What I probably forgot
> to comprehend was that my approach direction just for grasping could be
> specified as being different from that mentioned in the XML
>
> Unfortunately, when I call gmodel.computeValidGrasps() with checkIk=True, I
> get the following error:
>
> computing first 5 valid grasps
> Traceback (most recent call last):
>  File "/home/kshaurya/aar-arm/scripts/src/try.py", line 63, in <module>
>    validgrasps,validindices =
> gmodel.computeValidGrasps(returnnum=returnnum, checkik=True)
>  File
> "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_/databases/grasping.py",
> line 778, in computeValidGrasps
>    ikparam =
> IkParameterization(Ray(Tglobalgrasp[0:3,3],dot(Tglobalgrasp[0:3,0:3],self.manip.GetDirection())),IkParameterization.Type.TranslationDirection5D)
> NameError: global name 'Ray' is not defined
>
> Probably it needs to be referenced from another class / it requires an
> import.
> Instead, could it just be
> ikparam = IkParameterization(
> [Tglobalgrasp[0:3,3],dot(Tglobalgrasp[0:3,0:3],self.manip.GetDirection())],
> IkParameterization.Type.TranslationDirection5D)
> You seem to have used something like this in
> http://openrave.org/en/main/_modules/openravepy/examples/tutorial_iktranslation.html
> this  example as well.
>
> (I'm sorry, I'm a bit green at Python)
>
> Thanks!
>
> --
> View this message in context: http://openrave-users-list.185357.n3.nabble.com/Hinge2-functionality-tp3888429p4004841.html
> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

icoderaven
Oh, okay. Thanks for the quick reply!

I guess I got confused by the
elif self.manip.GetIkSolver().Supports(IkParameterization.Type.TranslationDirection5D):
block in the method definition and thought that it was supported.

Cheers!
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

Rosen Diankov
Administrator
you are right, 5D IK gets called... i'm not sure why it doesn't work.
Nevertheless, TaskManipulationGraspPlanning is much more robust.

2012/5/21 icoderaven <[hidden email]>:

> Oh, okay. Thanks for the quick reply!
>
> I guess I got confused by the
> elif
> self.manip.GetIkSolver().Supports(IkParameterization.Type.TranslationDirection5D):
> block in the method definition and thought that it was supported.
>
> Cheers!
>
> --
> View this message in context: http://openrave-users-list.185357.n3.nabble.com/Hinge2-functionality-tp3888429p4004877.html
> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

icoderaven
kshaurya@kshaurya-laptop:~/aar-arm/robots$ openrave.py --database linkstatistics --robot=er4u.robot.xml --samplingdelta=0.004 --numthreads=8
[xmlreaders.cpp:1260] link root has no geometry attached!
openravepy.databases.linkstatistics: generate, Generating link volume points, sampling delta = 0.004000
openravepy.databases.linkstatistics: generate, link 0/9
openravepy.databases.linkstatistics: generate, link 1/9
openravepy.databases.linkstatistics: generate, link 2/9
openravepy.databases.linkstatistics: generate, link 3/9
openravepy.databases.linkstatistics: generate, link 4/9
openravepy.databases.linkstatistics: generate, link 5/9
openravepy.databases.linkstatistics: generate, link 6/9
openravepy.databases.linkstatistics: generate, link 7/9
openravepy.databases.linkstatistics: generate, link 8/9
openravepy.databases.linkstatistics: generate, Generating swept volumes...
openravepy.databases.linkstatistics: generate, joint 6
openravepy.databases.linkstatistics: generate, joint 5
openravepy.databases.linkstatistics: generate, joint 4
openravepy.databases.linkstatistics: generate, joint 3
openravepy.databases.linkstatistics: generate, joint 2
openravepy.databases.linkstatistics: generate, joint 1
openravepy.databases.linkstatistics: generate, joint 7
Traceback (most recent call last):
  File "/usr/bin/openrave.py", line 126, in <module>
    database.run(args=args)
  File "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_0_6/databases/linkstatistics.py", line 464, in run
    LinkStatisticsModel.RunFromParser(*args,**kwargs)
  File "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_0_6/databases/linkstatistics.py", line 456, in RunFromParser
    DatabaseGenerator.RunFromParser(env=env,Model=Model,parser=parser,**kwargs)
  File "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_0_6/databases/__init__.py", line 224, in RunFromParser
    model.autogenerate(options=options)
  File "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_0_6/databases/linkstatistics.py", line 180, in autogenerate
    self.generate(samplingdelta=samplingdelta)
  File "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_0_6/databases/linkstatistics.py", line 237, in generate
    jointvolume = r_[jointvolume, self.transformJointPoints(childjoint,jointvolumes_points[childjoint.GetJointIndex()],translation=-joint.GetAnchor())]
  File "/usr/lib/python2.6/dist-packages/openravepy/_openravepy_0_6/databases/linkstatistics.py", line 358, in transformJointPoints
    if len(points) > 0:
TypeError: object of type 'NoneType' has no len()


So, I think the issue is cropping up because of that dummy base link I use to fix the coordinate axes. I went ahead and filed a ticket for that. I'm not sure whether that was the right thing to do though. :S
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

icoderaven
Okay, I managed to fix it by editing the base link to be rotated instead, eliminating the need for a separate link/joint.

Which leads me to believe that in the guide at

http://openrave.programmingvision.com/wiki/index.php/Format:XML#Changing_the_Body_Coordinate_System

why can't it suffice to add a

<rotationaxis>1 0 0 90</rotationaxis>

in the kinbody XML file?
Reply | Threaded
Open this post in threaded view
|

Re: Grasping issues

Rosen Diankov
Administrator
check response at

https://sourceforge.net/apps/trac/openrave/ticket/284

next time please just file the ticket (and cc rdiankov), or copy the
ticket url on this thread.

thanks!

2012/5/28 icoderaven <[hidden email]>:

> Okay, I managed to fix it by editing the base link to be rotated instead,
> eliminating the need for a separate link/joint.
>
> Which leads me to believe that in the guide at
>
> http://openrave.programmingvision.com/wiki/index.php/Format:XML#Changing_the_Body_Coordinate_System
>
> why can't it suffice to add a
>
> <rotationaxis>1 0 0 90</rotationaxis>
>
> in the kinbody XML file?
>
> --
> View this message in context: http://openrave-users-list.185357.n3.nabble.com/Hinge2-functionality-tp3888429p4018344.html
> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users