grasping: same scene - different outcomes

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

grasping: same scene - different outcomes

richard
Hi,

I could solve most of my previous problems, but now I noticed a
"strange" GraspPlanning bahaviour (I'm using the GraspPlanning class
from graspplanning.py): I have the puma (or sometimes the pa10schunk)
robot arm and 2 objects. The robot can easily reach the objects and the
destinations, they are all somewhere in the middle of the robots
action-range. Most often, grasping and placing to the destination works
fine, but the strange thing is: when calling
self.taskmanip.GraspPlanning with randomgrasps=True, then without
changing any file, sometimes the grasping and placing is successful, and
sometimes it ends after the successful grasping and vertical lifting
with following error:

planning to destination
[basemanipulation.h:651] Starting MoveToHandPosition...
[basemanipulation.h:775] only found 0/4 ik solutions
[basemanipulation.h:793] No IK Solution found
failed to reach a goal openrave planning_error: 'MoveToHandPosition'

Increasing parameters of MoveToHandPosition doesn't help. How can this
happen, if GraspPlanning plans the grasp in respect to the destination?

Very often, the same thing happens, after changing the position (or
destination) of an object, which could be successfully grasped and
placed before, by only 1-2 centimeters. Now, if I'm trying to pick and
place objects in simple scenes from one table on another, there's nearly
always one object which grasping/placing ends as mentioned. Any help?

best regards

Richard

--
Richard Cubek, Dipl.-Ing.(FH)
University of Applied Sciences Ravensburg-Weingarten
Intelligent Mobile Robotics Laboratory
Phone: (0049) (0)751 501 9838
Mobile: (0049) (0)163 88 39 529


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: grasping: same scene - different outcomes

Okal Billy
Hi Richard,

I am not sure but isn't that attributed to the randomness in sampling. Whenever I fire my planners in openrave, they always generate diff number of nodes, collisions ...


billy

On 8 October 2010 21:24, Richard Cubek <[hidden email]> wrote:
Hi,

I could solve most of my previous problems, but now I noticed a
"strange" GraspPlanning bahaviour (I'm using the GraspPlanning class
from graspplanning.py): I have the puma (or sometimes the pa10schunk)
robot arm and 2 objects. The robot can easily reach the objects and the
destinations, they are all somewhere in the middle of the robots
action-range. Most often, grasping and placing to the destination works
fine, but the strange thing is: when calling
self.taskmanip.GraspPlanning with randomgrasps=True, then without
changing any file, sometimes the grasping and placing is successful, and
sometimes it ends after the successful grasping and vertical lifting
with following error:

planning to destination
[basemanipulation.h:651] Starting MoveToHandPosition...
[basemanipulation.h:775] only found 0/4 ik solutions
[basemanipulation.h:793] No IK Solution found
failed to reach a goal openrave planning_error: 'MoveToHandPosition'

Increasing parameters of MoveToHandPosition doesn't help. How can this
happen, if GraspPlanning plans the grasp in respect to the destination?

Very often, the same thing happens, after changing the position (or
destination) of an object, which could be successfully grasped and
placed before, by only 1-2 centimeters. Now, if I'm trying to pick and
place objects in simple scenes from one table on another, there's nearly
always one object which grasping/placing ends as mentioned. Any help?

best regards

Richard

--
Richard Cubek, Dipl.-Ing.(FH)
University of Applied Sciences Ravensburg-Weingarten
Intelligent Mobile Robotics Laboratory
Phone: (0049) (0)751 501 9838
Mobile: (0049) (0)163 88 39 529


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users



--
Viele Gruss/Best Regards,
Billy Okal
Jacobs University Bremen
#5383, MA 333
-------------------------------------------------------------------------------------------------------
"sure vi is user friendly, its just particular about who to be friends with"

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: grasping: same scene - different outcomes

richard
Billy Okal schrieb:
> Hi Richard,
>
> I am not sure but isn't that attributed to the randomness in sampling.
> Whenever I fire my planners in openrave, they always generate diff
> number of nodes, collisions ...

If I have the same script running on the same scene with different
outcomes, then of course, there is somewhere randomness. My problem is:
I run the script with randomgrasps=True, and sometimes, the grasping and
placing worked. But, if having randomgrasps=False, it always failed.
It's difficult to work with it, if there obviously are possible
solutions, but GraspPlanning doesn't find them (or finds them sometimes,
if using randomgrasps=True).

An even stranger outcome when trying following: As the destination of
the object to grasp, I'm defining the same position where it already
stands, only +0.005 in z (so not to hit the table directly when
placing). The robot grasps the object, lifts it vertically about 0.07
meters (that means it already passed the destination), and the same
error occurs again! Why is the destination not reachable, even if the
robot just passed that joint configuration?

>
>
> billy
>
> On 8 October 2010 21:24, Richard Cubek <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I could solve most of my previous problems, but now I noticed a
>     "strange" GraspPlanning bahaviour (I'm using the GraspPlanning class
>     from graspplanning.py): I have the puma (or sometimes the pa10schunk)
>     robot arm and 2 objects. The robot can easily reach the objects
>     and the
>     destinations, they are all somewhere in the middle of the robots
>     action-range. Most often, grasping and placing to the destination
>     works
>     fine, but the strange thing is: when calling
>     self.taskmanip.GraspPlanning with randomgrasps=True, then without
>     changing any file, sometimes the grasping and placing is
>     successful, and
>     sometimes it ends after the successful grasping and vertical lifting
>     with following error:
>
>     planning to destination
>     [basemanipulation.h:651] Starting MoveToHandPosition...
>     [basemanipulation.h:775] only found 0/4 ik solutions
>     [basemanipulation.h:793] No IK Solution found
>     failed to reach a goal openrave planning_error: 'MoveToHandPosition'
>
>     Increasing parameters of MoveToHandPosition doesn't help. How can this
>     happen, if GraspPlanning plans the grasp in respect to the
>     destination?
>
>     Very often, the same thing happens, after changing the position (or
>     destination) of an object, which could be successfully grasped and
>     placed before, by only 1-2 centimeters. Now, if I'm trying to pick and
>     place objects in simple scenes from one table on another, there's
>     nearly
>     always one object which grasping/placing ends as mentioned. Any help?
>
>     best regards
>
>     Richard
>
>     --
>     Richard Cubek, Dipl.-Ing.(FH)
>     University of Applied Sciences Ravensburg-Weingarten
>     Intelligent Mobile Robotics Laboratory
>     Phone: (0049) (0)751 501 9838
>     Mobile: (0049) (0)163 88 39 529
>
>
>     ------------------------------------------------------------------------------
>     Beautiful is writing same markup. Internet Explorer 9 supports
>     standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>     Spend less time writing and  rewriting code and more time creating
>     great
>     experiences on the web. Be a part of the beta today.
>     http://p.sf.net/sfu/beautyoftheweb
>     _______________________________________________
>     Openrave-users mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/openrave-users
>
>
>
>
> --
> Viele Gruss/Best Regards,
> Billy Okal
> Jacobs University Bremen
> #5383, MA 333
> -------------------------------------------------------------------------------------------------------
> "sure vi is user friendly, its just particular about who to be friends
> with"


--
Richard Cubek, Dipl.-Ing.(FH)
University of Applied Sciences Ravensburg-Weingarten
Intelligent Mobile Robotics Laboratory
Phone: (0049) (0)751 501 9838
Mobile: (0049) (0)163 88 39 529



------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

KinBody message

virgil
Hi,

I have a quite complicated KinBody model that is reading very big .iv files (stemming from Parasolid to Open Inventor conversion). When I load the model in openrave I get this message:

[KinBody.cpp:2417] Cannot compute joint hierarchy for number of joints 4! Part of robot might not be moveable

Could anyone be kind enough to briefly mention what could cause it and what are the possible remedies?

Thanks,

Virgil





     

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: KinBody message

Rosen Diankov
Administrator
hi virgil,

The message means that not all links are connected by a joint. You
should look at all your joint definitions and make sure they are
connected to right links.  If you cannot figure out the problem, then
please send your robot file and we can have a look at it.

rosen,

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

> Hi,
>
> I have a quite complicated KinBody model that is reading very big .iv files (stemming from Parasolid to Open Inventor conversion). When I load the model in openrave I get this message:
>
> [KinBody.cpp:2417] Cannot compute joint hierarchy for number of joints 4! Part of robot might not be moveable
>
> Could anyone be kind enough to briefly mention what could cause it and what are the possible remedies?
>
> Thanks,
>
> Virgil
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: grasping: same scene - different outcomes

Rosen Diankov
Administrator
In reply to this post by richard
hi richard,

This is indeed a very interesting problem. First, regardless of
randomgrasps, it should always succeed. The taskmanipulation plugin
searches through all grasps, regardless if they are randomly ordered.

Are you experiencing this problem with the default graspplanning
scene? If you are using a different scene, can you send all files
necessary to reproduce this problem?

thanks,
rosen,

2010/10/9 Richard Cubek <[hidden email]>:

> Billy Okal schrieb:
>> Hi Richard,
>>
>> I am not sure but isn't that attributed to the randomness in sampling.
>> Whenever I fire my planners in openrave, they always generate diff
>> number of nodes, collisions ...
>
> If I have the same script running on the same scene with different
> outcomes, then of course, there is somewhere randomness. My problem is:
> I run the script with randomgrasps=True, and sometimes, the grasping and
> placing worked. But, if having randomgrasps=False, it always failed.
> It's difficult to work with it, if there obviously are possible
> solutions, but GraspPlanning doesn't find them (or finds them sometimes,
> if using randomgrasps=True).
>
> An even stranger outcome when trying following: As the destination of
> the object to grasp, I'm defining the same position where it already
> stands, only +0.005 in z (so not to hit the table directly when
> placing). The robot grasps the object, lifts it vertically about 0.07
> meters (that means it already passed the destination), and the same
> error occurs again! Why is the destination not reachable, even if the
> robot just passed that joint configuration?
>
>>
>>
>> billy
>>
>> On 8 October 2010 21:24, Richard Cubek <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Hi,
>>
>>     I could solve most of my previous problems, but now I noticed a
>>     "strange" GraspPlanning bahaviour (I'm using the GraspPlanning class
>>     from graspplanning.py): I have the puma (or sometimes the pa10schunk)
>>     robot arm and 2 objects. The robot can easily reach the objects
>>     and the
>>     destinations, they are all somewhere in the middle of the robots
>>     action-range. Most often, grasping and placing to the destination
>>     works
>>     fine, but the strange thing is: when calling
>>     self.taskmanip.GraspPlanning with randomgrasps=True, then without
>>     changing any file, sometimes the grasping and placing is
>>     successful, and
>>     sometimes it ends after the successful grasping and vertical lifting
>>     with following error:
>>
>>     planning to destination
>>     [basemanipulation.h:651] Starting MoveToHandPosition...
>>     [basemanipulation.h:775] only found 0/4 ik solutions
>>     [basemanipulation.h:793] No IK Solution found
>>     failed to reach a goal openrave planning_error: 'MoveToHandPosition'
>>
>>     Increasing parameters of MoveToHandPosition doesn't help. How can this
>>     happen, if GraspPlanning plans the grasp in respect to the
>>     destination?
>>
>>     Very often, the same thing happens, after changing the position (or
>>     destination) of an object, which could be successfully grasped and
>>     placed before, by only 1-2 centimeters. Now, if I'm trying to pick and
>>     place objects in simple scenes from one table on another, there's
>>     nearly
>>     always one object which grasping/placing ends as mentioned. Any help?
>>
>>     best regards
>>
>>     Richard
>>
>>     --
>>     Richard Cubek, Dipl.-Ing.(FH)
>>     University of Applied Sciences Ravensburg-Weingarten
>>     Intelligent Mobile Robotics Laboratory
>>     Phone: (0049) (0)751 501 9838
>>     Mobile: (0049) (0)163 88 39 529
>>
>>
>>     ------------------------------------------------------------------------------
>>     Beautiful is writing same markup. Internet Explorer 9 supports
>>     standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>>     Spend less time writing and  rewriting code and more time creating
>>     great
>>     experiences on the web. Be a part of the beta today.
>>     http://p.sf.net/sfu/beautyoftheweb
>>     _______________________________________________
>>     Openrave-users mailing list
>>     [hidden email]
>>     <mailto:[hidden email]>
>>     https://lists.sourceforge.net/lists/listinfo/openrave-users
>>
>>
>>
>>
>> --
>> Viele Gruss/Best Regards,
>> Billy Okal
>> Jacobs University Bremen
>> #5383, MA 333
>> -------------------------------------------------------------------------------------------------------
>> "sure vi is user friendly, its just particular about who to be friends
>> with"
>
>
> --
> Richard Cubek, Dipl.-Ing.(FH)
> University of Applied Sciences Ravensburg-Weingarten
> Intelligent Mobile Robotics Laboratory
> Phone: (0049) (0)751 501 9838
> Mobile: (0049) (0)163 88 39 529
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users