Re: Relative positioning of kinbodies

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

Re: Relative positioning of kinbodies

Rosen Diankov
Administrator
hi moslem,

the offsetfrom tag is only valid with the <body> tag. in your case,
you are putting it inside the <kinbody> tag. This actually sets the
translation of the actual body, not the link.

if you want to move link1, perhaps this will work:


<KinBody file="link1.xml">
<body name="link1">
<offsetfrom>base</offsetfrom>
<Translation>0.0 0.0 0.2255</Translation>
</body>
</KinBody>

if you look at the examples in the robots folder of how hands are
merged with arms, you'll see that the link definition of the hand
usually holds the <offsetfrom> tag of the arm end effector link.

rosen,

2010/6/4 Moslem Kazemi <[hidden email]>:

> Hi Rosen,
> I noticed that when I define the kinbody of the robot as follows:
> <KinBody name="ramparm">
> <KinBody file="base.xml"></KinBody>
>
> <KinBody file="link1.xml">
> <offsetfrom>base</offsetfrom>
> <Translation>0.0 0.0 0.2255</Translation>
> </KinBody>
> <Joint name="J1" type="hinge">
> <Body>base</Body>
> <Body>link1</Body>
> <offsetfrom>base</offsetfrom>
> <weight>0.2</weight>
> <lostop>-100</lostop>
> <histop>100</histop>
> <axis>0 0 1</axis>
> <maxvel>1.5</maxvel>
> <resolution>0.5</resolution>
> </Joint>
> <KinBody
> The translation <Translation>0.0 0.0 0.2255</Translation> is always w.r.t.
> the absolute world coordinate frame! and it does not take
> <offsetfrom>base</offsetfrom> into account!
> It does not even return an error if I change "base"
> in <offsetfrom>base</offsetfrom> with some kinbody which have not even been
> defined, like "blabla"!
> Thanks,
> --Moslem.
> and here is for example the base.xml file. link1 is similar ....
> <?xml version="1.0" encoding="utf-8"?>
> <KinBody>
> <Body name="base" type="dynamic">
> <Translation>0.0  0.0  0.0</Translation>
> <Geom type="trimesh">
> <Data>../../vrml/PAM102.wrl 0.001</Data>
> <Render>../../vrml/PAM102.wrl 0.001</Render>
> <Translation>0.0  0.0  0.045</Translation>
> <rotationaxis>1 0 0 -90</rotationaxis>
> <diffuseColor>0.01 0.01 0.5</diffuseColor>
> </Geom>
> <Geom type="trimesh">
> <Translation>0.0 0.0 0.135</Translation>
> <rotationaxis>1 0 0 0</rotationaxis>
> <Data>../../vrml/PR90_half.wrl 0.001</Data>
> <Render>../../vrml/PR90_half.wrl  0.001</Render>
> <diffuseColor>0.05 1 .05</diffuseColor>
> </Geom>
> </Body>
> </KinBody>
>
>
>
>
> --
> Moslem Kazemi, Ph.D. candidate
> Robotics: Motion Planning, Hardware, and Control
> Smart Systems: Design and Integration
> Simon Fraser University
> http://sites.google.com/site/moslemk/
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Relative positioning of kinbodies

Rosen Diankov
Administrator
hi moslem,

For plotting lines, triangles, etc, look at the testplotting.py
example file. it will show you all the possibilities. each of these
calls returns a handle, that once deleted, will delete the graph

for running trajectories from file, currently openrave has a very
simple text trajectory format outline in rave/trajectory.h

You can get a robot to follow this a trajectory in file traj.txt by:

manip=interfaces.BaseManipulation(robot)
manip.TrajFromData(open('traj.txt','r').read())

# will wait until robot stops followings its trajectory
robot.WaitForController(0)

hope this answers your questions
rosen,

2010/6/4 Moslem Kazemi <[hidden email]>:

> I am programming in python ...
> --Moslem.
>
> On Fri, Jun 4, 2010 at 5:57 PM, Rosen Diankov <[hidden email]>
> wrote:
>>
>> hi moslem,
>> all that is possible, please tell me what language you'd prefer to do
>> this in and i can point you to the correct example code
>> rosen,
>>
>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> > Thanks! But I enjoy the viewer and actually I really need it for
>> > visualization! It is nice to have it ....
>> > By the way, I have a time parameterized joint trajectory which is stored
>> > in
>> > a text file .... I like to move the robot and visualize the motion of
>> > the
>> > robot along this path. Is there any controller for this purpose or I
>> > should
>> > read the path and then displace the robot be setting joint angles with a
>> > proper timing? What would you suggest?
>> > Meanwhile, I like also to draw some lines/paths in the environment! Is
>> > there
>> > a plugin or interface for that?
>> > Hope I am not asking too much! I am just excited to implement my stuff
>> > and
>> > create some demos ....
>> > Thanks,
>> > --Moslem.
>> >
>> > On Fri, Jun 4, 2010 at 4:48 PM, Rosen Diankov <[hidden email]>
>> > wrote:
>> >>
>> >> disabling the GUI (ie not attaching a viewer) will give you 100%
>> >> stability within openrave
>> >> rosen,
>> >>
>> >> 2010/6/4 Rosen Diankov <[hidden email]>:
>> >> > hi moslem,
>> >> > i wouldn't be surprised, soqt, qt4, and coin3d are very unstable
>> >> > libraries. The testsensorcamera.py combines them with the Tkinter
>> >> > python library, which I think calls gtk as the backend. In the end,
>> >> > it's a big mess of threads fighting for the GUI ;0)
>> >> >
>> >> > i'm at least hoping to replace qt4 and coin3d with openscenegraph+gtk
>> >> >
>> >> > rosen,
>> >> >
>> >> > 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >> Hi Rosen,
>> >> >> I am testing the robot model that I just created for our robotic arm
>> >> >> with a
>> >> >> camera sensor. I adapted the code testsensorcamera.py from openrave
>> >> >> examples
>> >> >> and just load my own environment/robot model with no other changes!
>> >> >> It
>> >> >> works
>> >> >> almost fine .... However, sometimes when I run the code (without any
>> >> >> changes) it gives me this error and the camera/sensor view halts and
>> >> >> I
>> >> >> have
>> >> >> to close the viewer and camera view and run again! This happens from
>> >> >> time to
>> >> >> time .....
>> >> >> Here is the error:
>> >> >> Enter command (q-quit,c-capture image): error in background error
>> >> >> handler:
>> >> >> out of stack space (infinite loop?)
>> >> >>     while executing
>> >> >> "::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1
>> >> >> -level 0
>> >> >> -errorco
>> >> >> de NONE -errorinfo {out of stack space (infinite loop?)
>> >> >>     while execu..."
>> >> >> Any suggestion?
>> >> >> Thanks,
>> >> >> --Moslem.
>> >> >>
>> >> >> On Fri, Jun 4, 2010 at 2:29 PM, Rosen Diankov
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> no, it doesn't.
>> >> >>> i usually open the robot with python and print the coord frames out
>> >> >>> explicitly...
>> >> >>> rosen,
>> >> >>>
>> >> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> > Does the viewer has the capability of showing the link coord
>> >> >>> > frames
>> >> >>> > (or
>> >> >>> > kinbody coord frames)?
>> >> >>> > --Moslem.
>> >> >>> >
>> >> >>> > On Fri, Jun 4, 2010 at 2:11 PM, Moslem Kazemi <[hidden email]>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> No, it was my bad! :) just got it ....Thanks!
>> >> >>> >>
>> >> >>> >> On Fri, Jun 4, 2010 at 2:11 PM, Rosen Diankov
>> >> >>> >> <[hidden email]>
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> sorry, i assumed that link1 was the name of your second link.
>> >> >>> >>> please
>> >> >>> >>> replace the name="XXX" correspondingly.
>> >> >>> >>> rosen,
>> >> >>> >>>
>> >> >>> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> >>> > Thanks! It complains that the link has no geometry attached
>> >> >>> >>> > to
>> >> >>> >>> > it!
>> >> >>> >>> > Should I
>> >> >>> >>> > care about this?
>> >> >>> >>> >
>> >> >>> >>> > On Fri, Jun 4, 2010 at 2:04 PM, Rosen Diankov
>> >> >>> >>> > <[hidden email]>
>> >> >>> >>> > wrote:
>> >> >>> >>> >>
>> >> >>> >>> >> hi moslem,
>> >> >>> >>> >>
>> >> >>> >>> >> the offsetfrom tag is only valid with the <body> tag. in
>> >> >>> >>> >> your
>> >> >>> >>> >> case,
>> >> >>> >>> >> you are putting it inside the <kinbody> tag. This actually
>> >> >>> >>> >> sets
>> >> >>> >>> >> the
>> >> >>> >>> >> translation of the actual body, not the link.
>> >> >>> >>> >>
>> >> >>> >>> >> if you want to move link1, perhaps this will work:
>> >> >>> >>> >>
>> >> >>> >>> >>
>> >> >>> >>> >> <KinBody file="link1.xml">
>> >> >>> >>> >> <body name="link1">
>> >> >>> >>> >> <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> </body>
>> >> >>> >>> >> </KinBody>
>> >> >>> >>> >>
>> >> >>> >>> >> if you look at the examples in the robots folder of how
>> >> >>> >>> >> hands
>> >> >>> >>> >> are
>> >> >>> >>> >> merged with arms, you'll see that the link definition of the
>> >> >>> >>> >> hand
>> >> >>> >>> >> usually holds the <offsetfrom> tag of the arm end effector
>> >> >>> >>> >> link.
>> >> >>> >>> >>
>> >> >>> >>> >> rosen,
>> >> >>> >>> >>
>> >> >>> >>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> >>> >> > Hi Rosen,
>> >> >>> >>> >> > I noticed that when I define the kinbody of the robot as
>> >> >>> >>> >> > follows:
>> >> >>> >>> >> > <KinBody name="ramparm">
>> >> >>> >>> >> > <KinBody file="base.xml"></KinBody>
>> >> >>> >>> >> >
>> >> >>> >>> >> > <KinBody file="link1.xml">
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> > <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> > </KinBody>
>> >> >>> >>> >> > <Joint name="J1" type="hinge">
>> >> >>> >>> >> > <Body>base</Body>
>> >> >>> >>> >> > <Body>link1</Body>
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> > <weight>0.2</weight>
>> >> >>> >>> >> > <lostop>-100</lostop>
>> >> >>> >>> >> > <histop>100</histop>
>> >> >>> >>> >> > <axis>0 0 1</axis>
>> >> >>> >>> >> > <maxvel>1.5</maxvel>
>> >> >>> >>> >> > <resolution>0.5</resolution>
>> >> >>> >>> >> > </Joint>
>> >> >>> >>> >> > <KinBody
>> >> >>> >>> >> > The translation <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> > is
>> >> >>> >>> >> > always
>> >> >>> >>> >> > w.r.t.
>> >> >>> >>> >> > the absolute world coordinate frame! and it does not take
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom> into account!
>> >> >>> >>> >> > It does not even return an error if I change "base"
>> >> >>> >>> >> > in <offsetfrom>base</offsetfrom> with some kinbody which
>> >> >>> >>> >> > have
>> >> >>> >>> >> > not
>> >> >>> >>> >> > even
>> >> >>> >>> >> > been
>> >> >>> >>> >> > defined, like "blabla"!
>> >> >>> >>> >> > Thanks,
>> >> >>> >>> >> > --Moslem.
>> >> >>> >>> >> > and here is for example the base.xml file. link1 is
>> >> >>> >>> >> > similar
>> >> >>> >>> >> > ....
>> >> >>> >>> >> > <?xml version="1.0" encoding="utf-8"?>
>> >> >>> >>> >> > <KinBody>
>> >> >>> >>> >> > <Body name="base" type="dynamic">
>> >> >>> >>> >> > <Translation>0.0  0.0  0.0</Translation>
>> >> >>> >>> >> > <Geom type="trimesh">
>> >> >>> >>> >> > <Data>../../vrml/PAM102.wrl 0.001</Data>
>> >> >>> >>> >> > <Render>../../vrml/PAM102.wrl 0.001</Render>
>> >> >>> >>> >> > <Translation>0.0  0.0  0.045</Translation>
>> >> >>> >>> >> > <rotationaxis>1 0 0 -90</rotationaxis>
>> >> >>> >>> >> > <diffuseColor>0.01 0.01 0.5</diffuseColor>
>> >> >>> >>> >> > </Geom>
>> >> >>> >>> >> > <Geom type="trimesh">
>> >> >>> >>> >> > <Translation>0.0 0.0 0.135</Translation>
>> >> >>> >>> >> > <rotationaxis>1 0 0 0</rotationaxis>
>> >> >>> >>> >> > <Data>../../vrml/PR90_half.wrl 0.001</Data>
>> >> >>> >>> >> > <Render>../../vrml/PR90_half.wrl  0.001</Render>
>> >> >>> >>> >> > <diffuseColor>0.05 1 .05</diffuseColor>
>> >> >>> >>> >> > </Geom>
>> >> >>> >>> >> > </Body>
>> >> >>> >>> >> > </KinBody>
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > --
>> >> >>> >>> >> > Moslem Kazemi, Ph.D. candidate
>> >> >>> >>> >> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> >>> >> > Smart Systems: Design and Integration
>> >> >>> >>> >> > Simon Fraser University
>> >> >>> >>> >> > http://sites.google.com/site/moslemk/
>> >> >>> >>> >> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > --
>> >> >>> >>> > Moslem Kazemi, Ph.D. candidate
>> >> >>> >>> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> >>> > Smart Systems: Design and Integration
>> >> >>> >>> > Simon Fraser University
>> >> >>> >>> > http://sites.google.com/site/moslemk/
>> >> >>> >>> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Moslem Kazemi, Ph.D. candidate
>> >> >>> >> Robotics: Motion Planning, Hardware, and Control
>> >> >>> >> Smart Systems: Design and Integration
>> >> >>> >> Simon Fraser University
>> >> >>> >> http://sites.google.com/site/moslemk/
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Moslem Kazemi, Ph.D. candidate
>> >> >>> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> > Smart Systems: Design and Integration
>> >> >>> > Simon Fraser University
>> >> >>> > http://sites.google.com/site/moslemk/
>> >> >>> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Moslem Kazemi, Ph.D. candidate
>> >> >> Robotics: Motion Planning, Hardware, and Control
>> >> >> Smart Systems: Design and Integration
>> >> >> Simon Fraser University
>> >> >> http://sites.google.com/site/moslemk/
>> >> >>
>> >> >
>> >
>> >
>> >
>> > --
>> > Moslem Kazemi, Ph.D. candidate
>> > Robotics: Motion Planning, Hardware, and Control
>> > Smart Systems: Design and Integration
>> > Simon Fraser University
>> > http://sites.google.com/site/moslemk/
>> >
>
>
>
> --
> Moslem Kazemi, Ph.D. candidate
> Robotics: Motion Planning, Hardware, and Control
> Smart Systems: Design and Integration
> Simon Fraser University
> http://sites.google.com/site/moslemk/
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Relative positioning of kinbodies

Moslem Kazemi
Yes, that worked like a charm! 
Thanks!
--Moslem.

On Fri, Jun 4, 2010 at 5:36 PM, Rosen Diankov <[hidden email]> wrote:
hi moslem,

For plotting lines, triangles, etc, look at the testplotting.py
example file. it will show you all the possibilities. each of these
calls returns a handle, that once deleted, will delete the graph

for running trajectories from file, currently openrave has a very
simple text trajectory format outline in rave/trajectory.h

You can get a robot to follow this a trajectory in file traj.txt by:

manip=interfaces.BaseManipulation(robot)
manip.TrajFromData(open('traj.txt','r').read())

# will wait until robot stops followings its trajectory
robot.WaitForController(0)

hope this answers your questions
rosen,

2010/6/4 Moslem Kazemi <[hidden email]>:
> I am programming in python ...
> --Moslem.
>
> On Fri, Jun 4, 2010 at 5:57 PM, Rosen Diankov <[hidden email]>
> wrote:
>>
>> hi moslem,
>> all that is possible, please tell me what language you'd prefer to do
>> this in and i can point you to the correct example code
>> rosen,
>>
>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> > Thanks! But I enjoy the viewer and actually I really need it for
>> > visualization! It is nice to have it ....
>> > By the way, I have a time parameterized joint trajectory which is stored
>> > in
>> > a text file .... I like to move the robot and visualize the motion of
>> > the
>> > robot along this path. Is there any controller for this purpose or I
>> > should
>> > read the path and then displace the robot be setting joint angles with a
>> > proper timing? What would you suggest?
>> > Meanwhile, I like also to draw some lines/paths in the environment! Is
>> > there
>> > a plugin or interface for that?
>> > Hope I am not asking too much! I am just excited to implement my stuff
>> > and
>> > create some demos ....
>> > Thanks,
>> > --Moslem.
>> >
>> > On Fri, Jun 4, 2010 at 4:48 PM, Rosen Diankov <[hidden email]>
>> > wrote:
>> >>
>> >> disabling the GUI (ie not attaching a viewer) will give you 100%
>> >> stability within openrave
>> >> rosen,
>> >>
>> >> 2010/6/4 Rosen Diankov <[hidden email]>:
>> >> > hi moslem,
>> >> > i wouldn't be surprised, soqt, qt4, and coin3d are very unstable
>> >> > libraries. The testsensorcamera.py combines them with the Tkinter
>> >> > python library, which I think calls gtk as the backend. In the end,
>> >> > it's a big mess of threads fighting for the GUI ;0)
>> >> >
>> >> > i'm at least hoping to replace qt4 and coin3d with openscenegraph+gtk
>> >> >
>> >> > rosen,
>> >> >
>> >> > 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >> Hi Rosen,
>> >> >> I am testing the robot model that I just created for our robotic arm
>> >> >> with a
>> >> >> camera sensor. I adapted the code testsensorcamera.py from openrave
>> >> >> examples
>> >> >> and just load my own environment/robot model with no other changes!
>> >> >> It
>> >> >> works
>> >> >> almost fine .... However, sometimes when I run the code (without any
>> >> >> changes) it gives me this error and the camera/sensor view halts and
>> >> >> I
>> >> >> have
>> >> >> to close the viewer and camera view and run again! This happens from
>> >> >> time to
>> >> >> time .....
>> >> >> Here is the error:
>> >> >> Enter command (q-quit,c-capture image): error in background error
>> >> >> handler:
>> >> >> out of stack space (infinite loop?)
>> >> >>     while executing
>> >> >> "::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1
>> >> >> -level 0
>> >> >> -errorco
>> >> >> de NONE -errorinfo {out of stack space (infinite loop?)
>> >> >>     while execu..."
>> >> >> Any suggestion?
>> >> >> Thanks,
>> >> >> --Moslem.
>> >> >>
>> >> >> On Fri, Jun 4, 2010 at 2:29 PM, Rosen Diankov
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> no, it doesn't.
>> >> >>> i usually open the robot with python and print the coord frames out
>> >> >>> explicitly...
>> >> >>> rosen,
>> >> >>>
>> >> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> > Does the viewer has the capability of showing the link coord
>> >> >>> > frames
>> >> >>> > (or
>> >> >>> > kinbody coord frames)?
>> >> >>> > --Moslem.
>> >> >>> >
>> >> >>> > On Fri, Jun 4, 2010 at 2:11 PM, Moslem Kazemi <[hidden email]>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> No, it was my bad! :) just got it ....Thanks!
>> >> >>> >>
>> >> >>> >> On Fri, Jun 4, 2010 at 2:11 PM, Rosen Diankov
>> >> >>> >> <[hidden email]>
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> sorry, i assumed that link1 was the name of your second link.
>> >> >>> >>> please
>> >> >>> >>> replace the name="XXX" correspondingly.
>> >> >>> >>> rosen,
>> >> >>> >>>
>> >> >>> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> >>> > Thanks! It complains that the link has no geometry attached
>> >> >>> >>> > to
>> >> >>> >>> > it!
>> >> >>> >>> > Should I
>> >> >>> >>> > care about this?
>> >> >>> >>> >
>> >> >>> >>> > On Fri, Jun 4, 2010 at 2:04 PM, Rosen Diankov
>> >> >>> >>> > <[hidden email]>
>> >> >>> >>> > wrote:
>> >> >>> >>> >>
>> >> >>> >>> >> hi moslem,
>> >> >>> >>> >>
>> >> >>> >>> >> the offsetfrom tag is only valid with the <body> tag. in
>> >> >>> >>> >> your
>> >> >>> >>> >> case,
>> >> >>> >>> >> you are putting it inside the <kinbody> tag. This actually
>> >> >>> >>> >> sets
>> >> >>> >>> >> the
>> >> >>> >>> >> translation of the actual body, not the link.
>> >> >>> >>> >>
>> >> >>> >>> >> if you want to move link1, perhaps this will work:
>> >> >>> >>> >>
>> >> >>> >>> >>
>> >> >>> >>> >> <KinBody file="link1.xml">
>> >> >>> >>> >> <body name="link1">
>> >> >>> >>> >> <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> </body>
>> >> >>> >>> >> </KinBody>
>> >> >>> >>> >>
>> >> >>> >>> >> if you look at the examples in the robots folder of how
>> >> >>> >>> >> hands
>> >> >>> >>> >> are
>> >> >>> >>> >> merged with arms, you'll see that the link definition of the
>> >> >>> >>> >> hand
>> >> >>> >>> >> usually holds the <offsetfrom> tag of the arm end effector
>> >> >>> >>> >> link.
>> >> >>> >>> >>
>> >> >>> >>> >> rosen,
>> >> >>> >>> >>
>> >> >>> >>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> >>> >> > Hi Rosen,
>> >> >>> >>> >> > I noticed that when I define the kinbody of the robot as
>> >> >>> >>> >> > follows:
>> >> >>> >>> >> > <KinBody name="ramparm">
>> >> >>> >>> >> > <KinBody file="base.xml"></KinBody>
>> >> >>> >>> >> >
>> >> >>> >>> >> > <KinBody file="link1.xml">
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> > <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> > </KinBody>
>> >> >>> >>> >> > <Joint name="J1" type="hinge">
>> >> >>> >>> >> > <Body>base</Body>
>> >> >>> >>> >> > <Body>link1</Body>
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> > <weight>0.2</weight>
>> >> >>> >>> >> > <lostop>-100</lostop>
>> >> >>> >>> >> > <histop>100</histop>
>> >> >>> >>> >> > <axis>0 0 1</axis>
>> >> >>> >>> >> > <maxvel>1.5</maxvel>
>> >> >>> >>> >> > <resolution>0.5</resolution>
>> >> >>> >>> >> > </Joint>
>> >> >>> >>> >> > <KinBody
>> >> >>> >>> >> > The translation <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> > is
>> >> >>> >>> >> > always
>> >> >>> >>> >> > w.r.t.
>> >> >>> >>> >> > the absolute world coordinate frame! and it does not take
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom> into account!
>> >> >>> >>> >> > It does not even return an error if I change "base"
>> >> >>> >>> >> > in <offsetfrom>base</offsetfrom> with some kinbody which
>> >> >>> >>> >> > have
>> >> >>> >>> >> > not
>> >> >>> >>> >> > even
>> >> >>> >>> >> > been
>> >> >>> >>> >> > defined, like "blabla"!
>> >> >>> >>> >> > Thanks,
>> >> >>> >>> >> > --Moslem.
>> >> >>> >>> >> > and here is for example the base.xml file. link1 is
>> >> >>> >>> >> > similar
>> >> >>> >>> >> > ....
>> >> >>> >>> >> > <?xml version="1.0" encoding="utf-8"?>
>> >> >>> >>> >> > <KinBody>
>> >> >>> >>> >> > <Body name="base" type="dynamic">
>> >> >>> >>> >> > <Translation>0.0  0.0  0.0</Translation>
>> >> >>> >>> >> > <Geom type="trimesh">
>> >> >>> >>> >> > <Data>../../vrml/PAM102.wrl 0.001</Data>
>> >> >>> >>> >> > <Render>../../vrml/PAM102.wrl 0.001</Render>
>> >> >>> >>> >> > <Translation>0.0  0.0  0.045</Translation>
>> >> >>> >>> >> > <rotationaxis>1 0 0 -90</rotationaxis>
>> >> >>> >>> >> > <diffuseColor>0.01 0.01 0.5</diffuseColor>
>> >> >>> >>> >> > </Geom>
>> >> >>> >>> >> > <Geom type="trimesh">
>> >> >>> >>> >> > <Translation>0.0 0.0 0.135</Translation>
>> >> >>> >>> >> > <rotationaxis>1 0 0 0</rotationaxis>
>> >> >>> >>> >> > <Data>../../vrml/PR90_half.wrl 0.001</Data>
>> >> >>> >>> >> > <Render>../../vrml/PR90_half.wrl  0.001</Render>
>> >> >>> >>> >> > <diffuseColor>0.05 1 .05</diffuseColor>
>> >> >>> >>> >> > </Geom>
>> >> >>> >>> >> > </Body>
>> >> >>> >>> >> > </KinBody>
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > --
>> >> >>> >>> >> > Moslem Kazemi, Ph.D. candidate
>> >> >>> >>> >> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> >>> >> > Smart Systems: Design and Integration
>> >> >>> >>> >> > Simon Fraser University
>> >> >>> >>> >> > http://sites.google.com/site/moslemk/
>> >> >>> >>> >> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > --
>> >> >>> >>> > Moslem Kazemi, Ph.D. candidate
>> >> >>> >>> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> >>> > Smart Systems: Design and Integration
>> >> >>> >>> > Simon Fraser University
>> >> >>> >>> > http://sites.google.com/site/moslemk/
>> >> >>> >>> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Moslem Kazemi, Ph.D. candidate
>> >> >>> >> Robotics: Motion Planning, Hardware, and Control
>> >> >>> >> Smart Systems: Design and Integration
>> >> >>> >> Simon Fraser University
>> >> >>> >> http://sites.google.com/site/moslemk/
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Moslem Kazemi, Ph.D. candidate
>> >> >>> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> > Smart Systems: Design and Integration
>> >> >>> > Simon Fraser University
>> >> >>> > http://sites.google.com/site/moslemk/
>> >> >>> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Moslem Kazemi, Ph.D. candidate
>> >> >> Robotics: Motion Planning, Hardware, and Control
>> >> >> Smart Systems: Design and Integration
>> >> >> Simon Fraser University
>> >> >> http://sites.google.com/site/moslemk/
>> >> >>
>> >> >
>> >
>> >
>> >
>> > --
>> > Moslem Kazemi, Ph.D. candidate
>> > Robotics: Motion Planning, Hardware, and Control
>> > Smart Systems: Design and Integration
>> > Simon Fraser University
>> > http://sites.google.com/site/moslemk/
>> >
>
>
>
> --
> Moslem Kazemi, Ph.D. candidate
> Robotics: Motion Planning, Hardware, and Control
> Smart Systems: Design and Integration
> Simon Fraser University
> http://sites.google.com/site/moslemk/
>



--
Moslem Kazemi, Ph.D. candidate
Robotics: Motion Planning, Hardware, and Control
Smart Systems: Design and Integration
Simon Fraser University
http://sites.google.com/site/moslemk/

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Relative positioning of kinbodies

Moslem Kazemi
Hi Rosen,
Is there an interface to read/store tree structures from/into text files, similar to the trajectory.h for trajectories? I couldn't find any ....
Thanks,
--Moslem.

On Sat, Jun 5, 2010 at 9:34 AM, Moslem Kazemi <[hidden email]> wrote:
Yes, that worked like a charm! 
Thanks!
--Moslem.

On Fri, Jun 4, 2010 at 5:36 PM, Rosen Diankov <[hidden email]> wrote:
hi moslem,

For plotting lines, triangles, etc, look at the testplotting.py
example file. it will show you all the possibilities. each of these
calls returns a handle, that once deleted, will delete the graph

for running trajectories from file, currently openrave has a very
simple text trajectory format outline in rave/trajectory.h

You can get a robot to follow this a trajectory in file traj.txt by:

manip=interfaces.BaseManipulation(robot)
manip.TrajFromData(open('traj.txt','r').read())

# will wait until robot stops followings its trajectory
robot.WaitForController(0)

hope this answers your questions
rosen,

2010/6/4 Moslem Kazemi <[hidden email]>:
> I am programming in python ...
> --Moslem.
>
> On Fri, Jun 4, 2010 at 5:57 PM, Rosen Diankov <[hidden email]>
> wrote:
>>
>> hi moslem,
>> all that is possible, please tell me what language you'd prefer to do
>> this in and i can point you to the correct example code
>> rosen,
>>
>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> > Thanks! But I enjoy the viewer and actually I really need it for
>> > visualization! It is nice to have it ....
>> > By the way, I have a time parameterized joint trajectory which is stored
>> > in
>> > a text file .... I like to move the robot and visualize the motion of
>> > the
>> > robot along this path. Is there any controller for this purpose or I
>> > should
>> > read the path and then displace the robot be setting joint angles with a
>> > proper timing? What would you suggest?
>> > Meanwhile, I like also to draw some lines/paths in the environment! Is
>> > there
>> > a plugin or interface for that?
>> > Hope I am not asking too much! I am just excited to implement my stuff
>> > and
>> > create some demos ....
>> > Thanks,
>> > --Moslem.
>> >
>> > On Fri, Jun 4, 2010 at 4:48 PM, Rosen Diankov <[hidden email]>
>> > wrote:
>> >>
>> >> disabling the GUI (ie not attaching a viewer) will give you 100%
>> >> stability within openrave
>> >> rosen,
>> >>
>> >> 2010/6/4 Rosen Diankov <[hidden email]>:
>> >> > hi moslem,
>> >> > i wouldn't be surprised, soqt, qt4, and coin3d are very unstable
>> >> > libraries. The testsensorcamera.py combines them with the Tkinter
>> >> > python library, which I think calls gtk as the backend. In the end,
>> >> > it's a big mess of threads fighting for the GUI ;0)
>> >> >
>> >> > i'm at least hoping to replace qt4 and coin3d with openscenegraph+gtk
>> >> >
>> >> > rosen,
>> >> >
>> >> > 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >> Hi Rosen,
>> >> >> I am testing the robot model that I just created for our robotic arm
>> >> >> with a
>> >> >> camera sensor. I adapted the code testsensorcamera.py from openrave
>> >> >> examples
>> >> >> and just load my own environment/robot model with no other changes!
>> >> >> It
>> >> >> works
>> >> >> almost fine .... However, sometimes when I run the code (without any
>> >> >> changes) it gives me this error and the camera/sensor view halts and
>> >> >> I
>> >> >> have
>> >> >> to close the viewer and camera view and run again! This happens from
>> >> >> time to
>> >> >> time .....
>> >> >> Here is the error:
>> >> >> Enter command (q-quit,c-capture image): error in background error
>> >> >> handler:
>> >> >> out of stack space (infinite loop?)
>> >> >>     while executing
>> >> >> "::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1
>> >> >> -level 0
>> >> >> -errorco
>> >> >> de NONE -errorinfo {out of stack space (infinite loop?)
>> >> >>     while execu..."
>> >> >> Any suggestion?
>> >> >> Thanks,
>> >> >> --Moslem.
>> >> >>
>> >> >> On Fri, Jun 4, 2010 at 2:29 PM, Rosen Diankov
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> no, it doesn't.
>> >> >>> i usually open the robot with python and print the coord frames out
>> >> >>> explicitly...
>> >> >>> rosen,
>> >> >>>
>> >> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> > Does the viewer has the capability of showing the link coord
>> >> >>> > frames
>> >> >>> > (or
>> >> >>> > kinbody coord frames)?
>> >> >>> > --Moslem.
>> >> >>> >
>> >> >>> > On Fri, Jun 4, 2010 at 2:11 PM, Moslem Kazemi <[hidden email]>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> No, it was my bad! :) just got it ....Thanks!
>> >> >>> >>
>> >> >>> >> On Fri, Jun 4, 2010 at 2:11 PM, Rosen Diankov
>> >> >>> >> <[hidden email]>
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> sorry, i assumed that link1 was the name of your second link.
>> >> >>> >>> please
>> >> >>> >>> replace the name="XXX" correspondingly.
>> >> >>> >>> rosen,
>> >> >>> >>>
>> >> >>> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> >>> > Thanks! It complains that the link has no geometry attached
>> >> >>> >>> > to
>> >> >>> >>> > it!
>> >> >>> >>> > Should I
>> >> >>> >>> > care about this?
>> >> >>> >>> >
>> >> >>> >>> > On Fri, Jun 4, 2010 at 2:04 PM, Rosen Diankov
>> >> >>> >>> > <[hidden email]>
>> >> >>> >>> > wrote:
>> >> >>> >>> >>
>> >> >>> >>> >> hi moslem,
>> >> >>> >>> >>
>> >> >>> >>> >> the offsetfrom tag is only valid with the <body> tag. in
>> >> >>> >>> >> your
>> >> >>> >>> >> case,
>> >> >>> >>> >> you are putting it inside the <kinbody> tag. This actually
>> >> >>> >>> >> sets
>> >> >>> >>> >> the
>> >> >>> >>> >> translation of the actual body, not the link.
>> >> >>> >>> >>
>> >> >>> >>> >> if you want to move link1, perhaps this will work:
>> >> >>> >>> >>
>> >> >>> >>> >>
>> >> >>> >>> >> <KinBody file="link1.xml">
>> >> >>> >>> >> <body name="link1">
>> >> >>> >>> >> <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> </body>
>> >> >>> >>> >> </KinBody>
>> >> >>> >>> >>
>> >> >>> >>> >> if you look at the examples in the robots folder of how
>> >> >>> >>> >> hands
>> >> >>> >>> >> are
>> >> >>> >>> >> merged with arms, you'll see that the link definition of the
>> >> >>> >>> >> hand
>> >> >>> >>> >> usually holds the <offsetfrom> tag of the arm end effector
>> >> >>> >>> >> link.
>> >> >>> >>> >>
>> >> >>> >>> >> rosen,
>> >> >>> >>> >>
>> >> >>> >>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >> >>> >>> >> > Hi Rosen,
>> >> >>> >>> >> > I noticed that when I define the kinbody of the robot as
>> >> >>> >>> >> > follows:
>> >> >>> >>> >> > <KinBody name="ramparm">
>> >> >>> >>> >> > <KinBody file="base.xml"></KinBody>
>> >> >>> >>> >> >
>> >> >>> >>> >> > <KinBody file="link1.xml">
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> > <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> > </KinBody>
>> >> >>> >>> >> > <Joint name="J1" type="hinge">
>> >> >>> >>> >> > <Body>base</Body>
>> >> >>> >>> >> > <Body>link1</Body>
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >> >>> >>> >> > <weight>0.2</weight>
>> >> >>> >>> >> > <lostop>-100</lostop>
>> >> >>> >>> >> > <histop>100</histop>
>> >> >>> >>> >> > <axis>0 0 1</axis>
>> >> >>> >>> >> > <maxvel>1.5</maxvel>
>> >> >>> >>> >> > <resolution>0.5</resolution>
>> >> >>> >>> >> > </Joint>
>> >> >>> >>> >> > <KinBody
>> >> >>> >>> >> > The translation <Translation>0.0 0.0 0.2255</Translation>
>> >> >>> >>> >> > is
>> >> >>> >>> >> > always
>> >> >>> >>> >> > w.r.t.
>> >> >>> >>> >> > the absolute world coordinate frame! and it does not take
>> >> >>> >>> >> > <offsetfrom>base</offsetfrom> into account!
>> >> >>> >>> >> > It does not even return an error if I change "base"
>> >> >>> >>> >> > in <offsetfrom>base</offsetfrom> with some kinbody which
>> >> >>> >>> >> > have
>> >> >>> >>> >> > not
>> >> >>> >>> >> > even
>> >> >>> >>> >> > been
>> >> >>> >>> >> > defined, like "blabla"!
>> >> >>> >>> >> > Thanks,
>> >> >>> >>> >> > --Moslem.
>> >> >>> >>> >> > and here is for example the base.xml file. link1 is
>> >> >>> >>> >> > similar
>> >> >>> >>> >> > ....
>> >> >>> >>> >> > <?xml version="1.0" encoding="utf-8"?>
>> >> >>> >>> >> > <KinBody>
>> >> >>> >>> >> > <Body name="base" type="dynamic">
>> >> >>> >>> >> > <Translation>0.0  0.0  0.0</Translation>
>> >> >>> >>> >> > <Geom type="trimesh">
>> >> >>> >>> >> > <Data>../../vrml/PAM102.wrl 0.001</Data>
>> >> >>> >>> >> > <Render>../../vrml/PAM102.wrl 0.001</Render>
>> >> >>> >>> >> > <Translation>0.0  0.0  0.045</Translation>
>> >> >>> >>> >> > <rotationaxis>1 0 0 -90</rotationaxis>
>> >> >>> >>> >> > <diffuseColor>0.01 0.01 0.5</diffuseColor>
>> >> >>> >>> >> > </Geom>
>> >> >>> >>> >> > <Geom type="trimesh">
>> >> >>> >>> >> > <Translation>0.0 0.0 0.135</Translation>
>> >> >>> >>> >> > <rotationaxis>1 0 0 0</rotationaxis>
>> >> >>> >>> >> > <Data>../../vrml/PR90_half.wrl 0.001</Data>
>> >> >>> >>> >> > <Render>../../vrml/PR90_half.wrl  0.001</Render>
>> >> >>> >>> >> > <diffuseColor>0.05 1 .05</diffuseColor>
>> >> >>> >>> >> > </Geom>
>> >> >>> >>> >> > </Body>
>> >> >>> >>> >> > </KinBody>
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > --
>> >> >>> >>> >> > Moslem Kazemi, Ph.D. candidate
>> >> >>> >>> >> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> >>> >> > Smart Systems: Design and Integration
>> >> >>> >>> >> > Simon Fraser University
>> >> >>> >>> >> > http://sites.google.com/site/moslemk/
>> >> >>> >>> >> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > --
>> >> >>> >>> > Moslem Kazemi, Ph.D. candidate
>> >> >>> >>> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> >>> > Smart Systems: Design and Integration
>> >> >>> >>> > Simon Fraser University
>> >> >>> >>> > http://sites.google.com/site/moslemk/
>> >> >>> >>> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Moslem Kazemi, Ph.D. candidate
>> >> >>> >> Robotics: Motion Planning, Hardware, and Control
>> >> >>> >> Smart Systems: Design and Integration
>> >> >>> >> Simon Fraser University
>> >> >>> >> http://sites.google.com/site/moslemk/
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Moslem Kazemi, Ph.D. candidate
>> >> >>> > Robotics: Motion Planning, Hardware, and Control
>> >> >>> > Smart Systems: Design and Integration
>> >> >>> > Simon Fraser University
>> >> >>> > http://sites.google.com/site/moslemk/
>> >> >>> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Moslem Kazemi, Ph.D. candidate
>> >> >> Robotics: Motion Planning, Hardware, and Control
>> >> >> Smart Systems: Design and Integration
>> >> >> Simon Fraser University
>> >> >> http://sites.google.com/site/moslemk/
>> >> >>
>> >> >
>> >
>> >
>> >
>> > --
>> > Moslem Kazemi, Ph.D. candidate
>> > Robotics: Motion Planning, Hardware, and Control
>> > Smart Systems: Design and Integration
>> > Simon Fraser University
>> > http://sites.google.com/site/moslemk/
>> >
>
>
>
> --
> Moslem Kazemi, Ph.D. candidate
> Robotics: Motion Planning, Hardware, and Control
> Smart Systems: Design and Integration
> Simon Fraser University
> http://sites.google.com/site/moslemk/
>



--
Moslem Kazemi, Ph.D. candidate
Robotics: Motion Planning, Hardware, and Control
Smart Systems: Design and Integration
Simon Fraser University
http://sites.google.com/site/moslemk/



--
Moslem Kazemi, Ph.D. candidate
Robotics: Motion Planning, Hardware, and Control
Smart Systems: Design and Integration
Simon Fraser University
http://sites.google.com/site/moslemk/

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Relative positioning of kinbodies

Rosen Diankov
Administrator
hi moslem,

i'm not sure what you mean by 'similar to trajectory.h' since that
file format is just an array of values..
are you asking if there's a way to export openrave kinematics into a file?
rosen,


2010/6/5 Moslem Kazemi <[hidden email]>:

> Hi Rosen,
> Is there an interface to read/store tree structures from/into text files,
> similar to the trajectory.h for trajectories? I couldn't find any ....
> Thanks,
> --Moslem.
>
> On Sat, Jun 5, 2010 at 9:34 AM, Moslem Kazemi <[hidden email]> wrote:
>>
>> Yes, that worked like a charm!
>> Thanks!
>> --Moslem.
>>
>> On Fri, Jun 4, 2010 at 5:36 PM, Rosen Diankov <[hidden email]>
>> wrote:
>>>
>>> hi moslem,
>>>
>>> For plotting lines, triangles, etc, look at the testplotting.py
>>> example file. it will show you all the possibilities. each of these
>>> calls returns a handle, that once deleted, will delete the graph
>>>
>>> for running trajectories from file, currently openrave has a very
>>> simple text trajectory format outline in rave/trajectory.h
>>>
>>> You can get a robot to follow this a trajectory in file traj.txt by:
>>>
>>> manip=interfaces.BaseManipulation(robot)
>>> manip.TrajFromData(open('traj.txt','r').read())
>>>
>>> # will wait until robot stops followings its trajectory
>>> robot.WaitForController(0)
>>>
>>> hope this answers your questions
>>> rosen,
>>>
>>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> > I am programming in python ...
>>> > --Moslem.
>>> >
>>> > On Fri, Jun 4, 2010 at 5:57 PM, Rosen Diankov <[hidden email]>
>>> > wrote:
>>> >>
>>> >> hi moslem,
>>> >> all that is possible, please tell me what language you'd prefer to do
>>> >> this in and i can point you to the correct example code
>>> >> rosen,
>>> >>
>>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> > Thanks! But I enjoy the viewer and actually I really need it for
>>> >> > visualization! It is nice to have it ....
>>> >> > By the way, I have a time parameterized joint trajectory which is
>>> >> > stored
>>> >> > in
>>> >> > a text file .... I like to move the robot and visualize the motion
>>> >> > of
>>> >> > the
>>> >> > robot along this path. Is there any controller for this purpose or I
>>> >> > should
>>> >> > read the path and then displace the robot be setting joint angles
>>> >> > with a
>>> >> > proper timing? What would you suggest?
>>> >> > Meanwhile, I like also to draw some lines/paths in the environment!
>>> >> > Is
>>> >> > there
>>> >> > a plugin or interface for that?
>>> >> > Hope I am not asking too much! I am just excited to implement my
>>> >> > stuff
>>> >> > and
>>> >> > create some demos ....
>>> >> > Thanks,
>>> >> > --Moslem.
>>> >> >
>>> >> > On Fri, Jun 4, 2010 at 4:48 PM, Rosen Diankov
>>> >> > <[hidden email]>
>>> >> > wrote:
>>> >> >>
>>> >> >> disabling the GUI (ie not attaching a viewer) will give you 100%
>>> >> >> stability within openrave
>>> >> >> rosen,
>>> >> >>
>>> >> >> 2010/6/4 Rosen Diankov <[hidden email]>:
>>> >> >> > hi moslem,
>>> >> >> > i wouldn't be surprised, soqt, qt4, and coin3d are very unstable
>>> >> >> > libraries. The testsensorcamera.py combines them with the Tkinter
>>> >> >> > python library, which I think calls gtk as the backend. In the
>>> >> >> > end,
>>> >> >> > it's a big mess of threads fighting for the GUI ;0)
>>> >> >> >
>>> >> >> > i'm at least hoping to replace qt4 and coin3d with
>>> >> >> > openscenegraph+gtk
>>> >> >> >
>>> >> >> > rosen,
>>> >> >> >
>>> >> >> > 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >> Hi Rosen,
>>> >> >> >> I am testing the robot model that I just created for our robotic
>>> >> >> >> arm
>>> >> >> >> with a
>>> >> >> >> camera sensor. I adapted the code testsensorcamera.py from
>>> >> >> >> openrave
>>> >> >> >> examples
>>> >> >> >> and just load my own environment/robot model with no other
>>> >> >> >> changes!
>>> >> >> >> It
>>> >> >> >> works
>>> >> >> >> almost fine .... However, sometimes when I run the code (without
>>> >> >> >> any
>>> >> >> >> changes) it gives me this error and the camera/sensor view halts
>>> >> >> >> and
>>> >> >> >> I
>>> >> >> >> have
>>> >> >> >> to close the viewer and camera view and run again! This happens
>>> >> >> >> from
>>> >> >> >> time to
>>> >> >> >> time .....
>>> >> >> >> Here is the error:
>>> >> >> >> Enter command (q-quit,c-capture image): error in background
>>> >> >> >> error
>>> >> >> >> handler:
>>> >> >> >> out of stack space (infinite loop?)
>>> >> >> >>     while executing
>>> >> >> >> "::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1
>>> >> >> >> -level 0
>>> >> >> >> -errorco
>>> >> >> >> de NONE -errorinfo {out of stack space (infinite loop?)
>>> >> >> >>     while execu..."
>>> >> >> >> Any suggestion?
>>> >> >> >> Thanks,
>>> >> >> >> --Moslem.
>>> >> >> >>
>>> >> >> >> On Fri, Jun 4, 2010 at 2:29 PM, Rosen Diankov
>>> >> >> >> <[hidden email]>
>>> >> >> >> wrote:
>>> >> >> >>>
>>> >> >> >>> no, it doesn't.
>>> >> >> >>> i usually open the robot with python and print the coord frames
>>> >> >> >>> out
>>> >> >> >>> explicitly...
>>> >> >> >>> rosen,
>>> >> >> >>>
>>> >> >> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >>> > Does the viewer has the capability of showing the link coord
>>> >> >> >>> > frames
>>> >> >> >>> > (or
>>> >> >> >>> > kinbody coord frames)?
>>> >> >> >>> > --Moslem.
>>> >> >> >>> >
>>> >> >> >>> > On Fri, Jun 4, 2010 at 2:11 PM, Moslem Kazemi
>>> >> >> >>> > <[hidden email]>
>>> >> >> >>> > wrote:
>>> >> >> >>> >>
>>> >> >> >>> >> No, it was my bad! :) just got it ....Thanks!
>>> >> >> >>> >>
>>> >> >> >>> >> On Fri, Jun 4, 2010 at 2:11 PM, Rosen Diankov
>>> >> >> >>> >> <[hidden email]>
>>> >> >> >>> >> wrote:
>>> >> >> >>> >>>
>>> >> >> >>> >>> sorry, i assumed that link1 was the name of your second
>>> >> >> >>> >>> link.
>>> >> >> >>> >>> please
>>> >> >> >>> >>> replace the name="XXX" correspondingly.
>>> >> >> >>> >>> rosen,
>>> >> >> >>> >>>
>>> >> >> >>> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >>> >>> > Thanks! It complains that the link has no geometry
>>> >> >> >>> >>> > attached
>>> >> >> >>> >>> > to
>>> >> >> >>> >>> > it!
>>> >> >> >>> >>> > Should I
>>> >> >> >>> >>> > care about this?
>>> >> >> >>> >>> >
>>> >> >> >>> >>> > On Fri, Jun 4, 2010 at 2:04 PM, Rosen Diankov
>>> >> >> >>> >>> > <[hidden email]>
>>> >> >> >>> >>> > wrote:
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> hi moslem,
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> the offsetfrom tag is only valid with the <body> tag. in
>>> >> >> >>> >>> >> your
>>> >> >> >>> >>> >> case,
>>> >> >> >>> >>> >> you are putting it inside the <kinbody> tag. This
>>> >> >> >>> >>> >> actually
>>> >> >> >>> >>> >> sets
>>> >> >> >>> >>> >> the
>>> >> >> >>> >>> >> translation of the actual body, not the link.
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> if you want to move link1, perhaps this will work:
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> <KinBody file="link1.xml">
>>> >> >> >>> >>> >> <body name="link1">
>>> >> >> >>> >>> >> <offsetfrom>base</offsetfrom>
>>> >> >> >>> >>> >> <Translation>0.0 0.0 0.2255</Translation>
>>> >> >> >>> >>> >> </body>
>>> >> >> >>> >>> >> </KinBody>
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> if you look at the examples in the robots folder of how
>>> >> >> >>> >>> >> hands
>>> >> >> >>> >>> >> are
>>> >> >> >>> >>> >> merged with arms, you'll see that the link definition of
>>> >> >> >>> >>> >> the
>>> >> >> >>> >>> >> hand
>>> >> >> >>> >>> >> usually holds the <offsetfrom> tag of the arm end
>>> >> >> >>> >>> >> effector
>>> >> >> >>> >>> >> link.
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> rosen,
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >>> >>> >> > Hi Rosen,
>>> >> >> >>> >>> >> > I noticed that when I define the kinbody of the robot
>>> >> >> >>> >>> >> > as
>>> >> >> >>> >>> >> > follows:
>>> >> >> >>> >>> >> > <KinBody name="ramparm">
>>> >> >> >>> >>> >> > <KinBody file="base.xml"></KinBody>
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> > <KinBody file="link1.xml">
>>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>>> >> >> >>> >>> >> > <Translation>0.0 0.0 0.2255</Translation>
>>> >> >> >>> >>> >> > </KinBody>
>>> >> >> >>> >>> >> > <Joint name="J1" type="hinge">
>>> >> >> >>> >>> >> > <Body>base</Body>
>>> >> >> >>> >>> >> > <Body>link1</Body>
>>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>>> >> >> >>> >>> >> > <weight>0.2</weight>
>>> >> >> >>> >>> >> > <lostop>-100</lostop>
>>> >> >> >>> >>> >> > <histop>100</histop>
>>> >> >> >>> >>> >> > <axis>0 0 1</axis>
>>> >> >> >>> >>> >> > <maxvel>1.5</maxvel>
>>> >> >> >>> >>> >> > <resolution>0.5</resolution>
>>> >> >> >>> >>> >> > </Joint>
>>> >> >> >>> >>> >> > <KinBody
>>> >> >> >>> >>> >> > The translation <Translation>0.0 0.0
>>> >> >> >>> >>> >> > 0.2255</Translation>
>>> >> >> >>> >>> >> > is
>>> >> >> >>> >>> >> > always
>>> >> >> >>> >>> >> > w.r.t.
>>> >> >> >>> >>> >> > the absolute world coordinate frame! and it does not
>>> >> >> >>> >>> >> > take
>>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom> into account!
>>> >> >> >>> >>> >> > It does not even return an error if I change "base"
>>> >> >> >>> >>> >> > in <offsetfrom>base</offsetfrom> with some kinbody
>>> >> >> >>> >>> >> > which
>>> >> >> >>> >>> >> > have
>>> >> >> >>> >>> >> > not
>>> >> >> >>> >>> >> > even
>>> >> >> >>> >>> >> > been
>>> >> >> >>> >>> >> > defined, like "blabla"!
>>> >> >> >>> >>> >> > Thanks,
>>> >> >> >>> >>> >> > --Moslem.
>>> >> >> >>> >>> >> > and here is for example the base.xml file. link1 is
>>> >> >> >>> >>> >> > similar
>>> >> >> >>> >>> >> > ....
>>> >> >> >>> >>> >> > <?xml version="1.0" encoding="utf-8"?>
>>> >> >> >>> >>> >> > <KinBody>
>>> >> >> >>> >>> >> > <Body name="base" type="dynamic">
>>> >> >> >>> >>> >> > <Translation>0.0  0.0  0.0</Translation>
>>> >> >> >>> >>> >> > <Geom type="trimesh">
>>> >> >> >>> >>> >> > <Data>../../vrml/PAM102.wrl 0.001</Data>
>>> >> >> >>> >>> >> > <Render>../../vrml/PAM102.wrl 0.001</Render>
>>> >> >> >>> >>> >> > <Translation>0.0  0.0  0.045</Translation>
>>> >> >> >>> >>> >> > <rotationaxis>1 0 0 -90</rotationaxis>
>>> >> >> >>> >>> >> > <diffuseColor>0.01 0.01 0.5</diffuseColor>
>>> >> >> >>> >>> >> > </Geom>
>>> >> >> >>> >>> >> > <Geom type="trimesh">
>>> >> >> >>> >>> >> > <Translation>0.0 0.0 0.135</Translation>
>>> >> >> >>> >>> >> > <rotationaxis>1 0 0 0</rotationaxis>
>>> >> >> >>> >>> >> > <Data>../../vrml/PR90_half.wrl 0.001</Data>
>>> >> >> >>> >>> >> > <Render>../../vrml/PR90_half.wrl  0.001</Render>
>>> >> >> >>> >>> >> > <diffuseColor>0.05 1 .05</diffuseColor>
>>> >> >> >>> >>> >> > </Geom>
>>> >> >> >>> >>> >> > </Body>
>>> >> >> >>> >>> >> > </KinBody>
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> > --
>>> >> >> >>> >>> >> > Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> >>> >> > Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> >>> >> > Smart Systems: Design and Integration
>>> >> >> >>> >>> >> > Simon Fraser University
>>> >> >> >>> >>> >> > http://sites.google.com/site/moslemk/
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >
>>> >> >> >>> >>> >
>>> >> >> >>> >>> >
>>> >> >> >>> >>> > --
>>> >> >> >>> >>> > Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> >>> > Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> >>> > Smart Systems: Design and Integration
>>> >> >> >>> >>> > Simon Fraser University
>>> >> >> >>> >>> > http://sites.google.com/site/moslemk/
>>> >> >> >>> >>> >
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> >> >> >>> >> --
>>> >> >> >>> >> Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> >> Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> >> Smart Systems: Design and Integration
>>> >> >> >>> >> Simon Fraser University
>>> >> >> >>> >> http://sites.google.com/site/moslemk/
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > --
>>> >> >> >>> > Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> > Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> > Smart Systems: Design and Integration
>>> >> >> >>> > Simon Fraser University
>>> >> >> >>> > http://sites.google.com/site/moslemk/
>>> >> >> >>> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Moslem Kazemi, Ph.D. candidate
>>> >> >> >> Robotics: Motion Planning, Hardware, and Control
>>> >> >> >> Smart Systems: Design and Integration
>>> >> >> >> Simon Fraser University
>>> >> >> >> http://sites.google.com/site/moslemk/
>>> >> >> >>
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Moslem Kazemi, Ph.D. candidate
>>> >> > Robotics: Motion Planning, Hardware, and Control
>>> >> > Smart Systems: Design and Integration
>>> >> > Simon Fraser University
>>> >> > http://sites.google.com/site/moslemk/
>>> >> >
>>> >
>>> >
>>> >
>>> > --
>>> > Moslem Kazemi, Ph.D. candidate
>>> > Robotics: Motion Planning, Hardware, and Control
>>> > Smart Systems: Design and Integration
>>> > Simon Fraser University
>>> > http://sites.google.com/site/moslemk/
>>> >
>>
>>
>>
>> --
>> Moslem Kazemi, Ph.D. candidate
>> Robotics: Motion Planning, Hardware, and Control
>> Smart Systems: Design and Integration
>> Simon Fraser University
>> http://sites.google.com/site/moslemk/
>
>
>
> --
> Moslem Kazemi, Ph.D. candidate
> Robotics: Motion Planning, Hardware, and Control
> Smart Systems: Design and Integration
> Simon Fraser University
> http://sites.google.com/site/moslemk/
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Relative positioning of kinbodies

Moslem Kazemi
No! What I meant was that for example I have a tree (as in RRT planner) stored in a text file ... Now I like to load it in openrave and I was wondering if there is a class/interface available for this purpose? As you mentioned to load trajectories from text files one could use trajectory.h interface which I am using right now ....do we have such capability to load trees? Hope I am clear!
Thanks.
--Moslem.

On Sat, Jun 5, 2010 at 10:15 AM, Rosen Diankov <[hidden email]> wrote:
hi moslem,

i'm not sure what you mean by 'similar to trajectory.h' since that
file format is just an array of values..
are you asking if there's a way to export openrave kinematics into a file?
rosen,


2010/6/5 Moslem Kazemi <[hidden email]>:
> Hi Rosen,
> Is there an interface to read/store tree structures from/into text files,
> similar to the trajectory.h for trajectories? I couldn't find any ....
> Thanks,
> --Moslem.
>
> On Sat, Jun 5, 2010 at 9:34 AM, Moslem Kazemi <[hidden email]> wrote:
>>
>> Yes, that worked like a charm!
>> Thanks!
>> --Moslem.
>>
>> On Fri, Jun 4, 2010 at 5:36 PM, Rosen Diankov <[hidden email]>
>> wrote:
>>>
>>> hi moslem,
>>>
>>> For plotting lines, triangles, etc, look at the testplotting.py
>>> example file. it will show you all the possibilities. each of these
>>> calls returns a handle, that once deleted, will delete the graph
>>>
>>> for running trajectories from file, currently openrave has a very
>>> simple text trajectory format outline in rave/trajectory.h
>>>
>>> You can get a robot to follow this a trajectory in file traj.txt by:
>>>
>>> manip=interfaces.BaseManipulation(robot)
>>> manip.TrajFromData(open('traj.txt','r').read())
>>>
>>> # will wait until robot stops followings its trajectory
>>> robot.WaitForController(0)
>>>
>>> hope this answers your questions
>>> rosen,
>>>
>>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> > I am programming in python ...
>>> > --Moslem.
>>> >
>>> > On Fri, Jun 4, 2010 at 5:57 PM, Rosen Diankov <[hidden email]>
>>> > wrote:
>>> >>
>>> >> hi moslem,
>>> >> all that is possible, please tell me what language you'd prefer to do
>>> >> this in and i can point you to the correct example code
>>> >> rosen,
>>> >>
>>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> > Thanks! But I enjoy the viewer and actually I really need it for
>>> >> > visualization! It is nice to have it ....
>>> >> > By the way, I have a time parameterized joint trajectory which is
>>> >> > stored
>>> >> > in
>>> >> > a text file .... I like to move the robot and visualize the motion
>>> >> > of
>>> >> > the
>>> >> > robot along this path. Is there any controller for this purpose or I
>>> >> > should
>>> >> > read the path and then displace the robot be setting joint angles
>>> >> > with a
>>> >> > proper timing? What would you suggest?
>>> >> > Meanwhile, I like also to draw some lines/paths in the environment!
>>> >> > Is
>>> >> > there
>>> >> > a plugin or interface for that?
>>> >> > Hope I am not asking too much! I am just excited to implement my
>>> >> > stuff
>>> >> > and
>>> >> > create some demos ....
>>> >> > Thanks,
>>> >> > --Moslem.
>>> >> >
>>> >> > On Fri, Jun 4, 2010 at 4:48 PM, Rosen Diankov
>>> >> > <[hidden email]>
>>> >> > wrote:
>>> >> >>
>>> >> >> disabling the GUI (ie not attaching a viewer) will give you 100%
>>> >> >> stability within openrave
>>> >> >> rosen,
>>> >> >>
>>> >> >> 2010/6/4 Rosen Diankov <[hidden email]>:
>>> >> >> > hi moslem,
>>> >> >> > i wouldn't be surprised, soqt, qt4, and coin3d are very unstable
>>> >> >> > libraries. The testsensorcamera.py combines them with the Tkinter
>>> >> >> > python library, which I think calls gtk as the backend. In the
>>> >> >> > end,
>>> >> >> > it's a big mess of threads fighting for the GUI ;0)
>>> >> >> >
>>> >> >> > i'm at least hoping to replace qt4 and coin3d with
>>> >> >> > openscenegraph+gtk
>>> >> >> >
>>> >> >> > rosen,
>>> >> >> >
>>> >> >> > 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >> Hi Rosen,
>>> >> >> >> I am testing the robot model that I just created for our robotic
>>> >> >> >> arm
>>> >> >> >> with a
>>> >> >> >> camera sensor. I adapted the code testsensorcamera.py from
>>> >> >> >> openrave
>>> >> >> >> examples
>>> >> >> >> and just load my own environment/robot model with no other
>>> >> >> >> changes!
>>> >> >> >> It
>>> >> >> >> works
>>> >> >> >> almost fine .... However, sometimes when I run the code (without
>>> >> >> >> any
>>> >> >> >> changes) it gives me this error and the camera/sensor view halts
>>> >> >> >> and
>>> >> >> >> I
>>> >> >> >> have
>>> >> >> >> to close the viewer and camera view and run again! This happens
>>> >> >> >> from
>>> >> >> >> time to
>>> >> >> >> time .....
>>> >> >> >> Here is the error:
>>> >> >> >> Enter command (q-quit,c-capture image): error in background
>>> >> >> >> error
>>> >> >> >> handler:
>>> >> >> >> out of stack space (infinite loop?)
>>> >> >> >>     while executing
>>> >> >> >> "::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1
>>> >> >> >> -level 0
>>> >> >> >> -errorco
>>> >> >> >> de NONE -errorinfo {out of stack space (infinite loop?)
>>> >> >> >>     while execu..."
>>> >> >> >> Any suggestion?
>>> >> >> >> Thanks,
>>> >> >> >> --Moslem.
>>> >> >> >>
>>> >> >> >> On Fri, Jun 4, 2010 at 2:29 PM, Rosen Diankov
>>> >> >> >> <[hidden email]>
>>> >> >> >> wrote:
>>> >> >> >>>
>>> >> >> >>> no, it doesn't.
>>> >> >> >>> i usually open the robot with python and print the coord frames
>>> >> >> >>> out
>>> >> >> >>> explicitly...
>>> >> >> >>> rosen,
>>> >> >> >>>
>>> >> >> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >>> > Does the viewer has the capability of showing the link coord
>>> >> >> >>> > frames
>>> >> >> >>> > (or
>>> >> >> >>> > kinbody coord frames)?
>>> >> >> >>> > --Moslem.
>>> >> >> >>> >
>>> >> >> >>> > On Fri, Jun 4, 2010 at 2:11 PM, Moslem Kazemi
>>> >> >> >>> > <[hidden email]>
>>> >> >> >>> > wrote:
>>> >> >> >>> >>
>>> >> >> >>> >> No, it was my bad! :) just got it ....Thanks!
>>> >> >> >>> >>
>>> >> >> >>> >> On Fri, Jun 4, 2010 at 2:11 PM, Rosen Diankov
>>> >> >> >>> >> <[hidden email]>
>>> >> >> >>> >> wrote:
>>> >> >> >>> >>>
>>> >> >> >>> >>> sorry, i assumed that link1 was the name of your second
>>> >> >> >>> >>> link.
>>> >> >> >>> >>> please
>>> >> >> >>> >>> replace the name="XXX" correspondingly.
>>> >> >> >>> >>> rosen,
>>> >> >> >>> >>>
>>> >> >> >>> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >>> >>> > Thanks! It complains that the link has no geometry
>>> >> >> >>> >>> > attached
>>> >> >> >>> >>> > to
>>> >> >> >>> >>> > it!
>>> >> >> >>> >>> > Should I
>>> >> >> >>> >>> > care about this?
>>> >> >> >>> >>> >
>>> >> >> >>> >>> > On Fri, Jun 4, 2010 at 2:04 PM, Rosen Diankov
>>> >> >> >>> >>> > <[hidden email]>
>>> >> >> >>> >>> > wrote:
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> hi moslem,
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> the offsetfrom tag is only valid with the <body> tag. in
>>> >> >> >>> >>> >> your
>>> >> >> >>> >>> >> case,
>>> >> >> >>> >>> >> you are putting it inside the <kinbody> tag. This
>>> >> >> >>> >>> >> actually
>>> >> >> >>> >>> >> sets
>>> >> >> >>> >>> >> the
>>> >> >> >>> >>> >> translation of the actual body, not the link.
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> if you want to move link1, perhaps this will work:
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> <KinBody file="link1.xml">
>>> >> >> >>> >>> >> <body name="link1">
>>> >> >> >>> >>> >> <offsetfrom>base</offsetfrom>
>>> >> >> >>> >>> >> <Translation>0.0 0.0 0.2255</Translation>
>>> >> >> >>> >>> >> </body>
>>> >> >> >>> >>> >> </KinBody>
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> if you look at the examples in the robots folder of how
>>> >> >> >>> >>> >> hands
>>> >> >> >>> >>> >> are
>>> >> >> >>> >>> >> merged with arms, you'll see that the link definition of
>>> >> >> >>> >>> >> the
>>> >> >> >>> >>> >> hand
>>> >> >> >>> >>> >> usually holds the <offsetfrom> tag of the arm end
>>> >> >> >>> >>> >> effector
>>> >> >> >>> >>> >> link.
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> rosen,
>>> >> >> >>> >>> >>
>>> >> >> >>> >>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>>> >> >> >>> >>> >> > Hi Rosen,
>>> >> >> >>> >>> >> > I noticed that when I define the kinbody of the robot
>>> >> >> >>> >>> >> > as
>>> >> >> >>> >>> >> > follows:
>>> >> >> >>> >>> >> > <KinBody name="ramparm">
>>> >> >> >>> >>> >> > <KinBody file="base.xml"></KinBody>
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> > <KinBody file="link1.xml">
>>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>>> >> >> >>> >>> >> > <Translation>0.0 0.0 0.2255</Translation>
>>> >> >> >>> >>> >> > </KinBody>
>>> >> >> >>> >>> >> > <Joint name="J1" type="hinge">
>>> >> >> >>> >>> >> > <Body>base</Body>
>>> >> >> >>> >>> >> > <Body>link1</Body>
>>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>>> >> >> >>> >>> >> > <weight>0.2</weight>
>>> >> >> >>> >>> >> > <lostop>-100</lostop>
>>> >> >> >>> >>> >> > <histop>100</histop>
>>> >> >> >>> >>> >> > <axis>0 0 1</axis>
>>> >> >> >>> >>> >> > <maxvel>1.5</maxvel>
>>> >> >> >>> >>> >> > <resolution>0.5</resolution>
>>> >> >> >>> >>> >> > </Joint>
>>> >> >> >>> >>> >> > <KinBody
>>> >> >> >>> >>> >> > The translation <Translation>0.0 0.0
>>> >> >> >>> >>> >> > 0.2255</Translation>
>>> >> >> >>> >>> >> > is
>>> >> >> >>> >>> >> > always
>>> >> >> >>> >>> >> > w.r.t.
>>> >> >> >>> >>> >> > the absolute world coordinate frame! and it does not
>>> >> >> >>> >>> >> > take
>>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom> into account!
>>> >> >> >>> >>> >> > It does not even return an error if I change "base"
>>> >> >> >>> >>> >> > in <offsetfrom>base</offsetfrom> with some kinbody
>>> >> >> >>> >>> >> > which
>>> >> >> >>> >>> >> > have
>>> >> >> >>> >>> >> > not
>>> >> >> >>> >>> >> > even
>>> >> >> >>> >>> >> > been
>>> >> >> >>> >>> >> > defined, like "blabla"!
>>> >> >> >>> >>> >> > Thanks,
>>> >> >> >>> >>> >> > --Moslem.
>>> >> >> >>> >>> >> > and here is for example the base.xml file. link1 is
>>> >> >> >>> >>> >> > similar
>>> >> >> >>> >>> >> > ....
>>> >> >> >>> >>> >> > <?xml version="1.0" encoding="utf-8"?>
>>> >> >> >>> >>> >> > <KinBody>
>>> >> >> >>> >>> >> > <Body name="base" type="dynamic">
>>> >> >> >>> >>> >> > <Translation>0.0  0.0  0.0</Translation>
>>> >> >> >>> >>> >> > <Geom type="trimesh">
>>> >> >> >>> >>> >> > <Data>../../vrml/PAM102.wrl 0.001</Data>
>>> >> >> >>> >>> >> > <Render>../../vrml/PAM102.wrl 0.001</Render>
>>> >> >> >>> >>> >> > <Translation>0.0  0.0  0.045</Translation>
>>> >> >> >>> >>> >> > <rotationaxis>1 0 0 -90</rotationaxis>
>>> >> >> >>> >>> >> > <diffuseColor>0.01 0.01 0.5</diffuseColor>
>>> >> >> >>> >>> >> > </Geom>
>>> >> >> >>> >>> >> > <Geom type="trimesh">
>>> >> >> >>> >>> >> > <Translation>0.0 0.0 0.135</Translation>
>>> >> >> >>> >>> >> > <rotationaxis>1 0 0 0</rotationaxis>
>>> >> >> >>> >>> >> > <Data>../../vrml/PR90_half.wrl 0.001</Data>
>>> >> >> >>> >>> >> > <Render>../../vrml/PR90_half.wrl  0.001</Render>
>>> >> >> >>> >>> >> > <diffuseColor>0.05 1 .05</diffuseColor>
>>> >> >> >>> >>> >> > </Geom>
>>> >> >> >>> >>> >> > </Body>
>>> >> >> >>> >>> >> > </KinBody>
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >> > --
>>> >> >> >>> >>> >> > Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> >>> >> > Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> >>> >> > Smart Systems: Design and Integration
>>> >> >> >>> >>> >> > Simon Fraser University
>>> >> >> >>> >>> >> > http://sites.google.com/site/moslemk/
>>> >> >> >>> >>> >> >
>>> >> >> >>> >>> >
>>> >> >> >>> >>> >
>>> >> >> >>> >>> >
>>> >> >> >>> >>> > --
>>> >> >> >>> >>> > Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> >>> > Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> >>> > Smart Systems: Design and Integration
>>> >> >> >>> >>> > Simon Fraser University
>>> >> >> >>> >>> > http://sites.google.com/site/moslemk/
>>> >> >> >>> >>> >
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> >> >> >>> >> --
>>> >> >> >>> >> Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> >> Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> >> Smart Systems: Design and Integration
>>> >> >> >>> >> Simon Fraser University
>>> >> >> >>> >> http://sites.google.com/site/moslemk/
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > --
>>> >> >> >>> > Moslem Kazemi, Ph.D. candidate
>>> >> >> >>> > Robotics: Motion Planning, Hardware, and Control
>>> >> >> >>> > Smart Systems: Design and Integration
>>> >> >> >>> > Simon Fraser University
>>> >> >> >>> > http://sites.google.com/site/moslemk/
>>> >> >> >>> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Moslem Kazemi, Ph.D. candidate
>>> >> >> >> Robotics: Motion Planning, Hardware, and Control
>>> >> >> >> Smart Systems: Design and Integration
>>> >> >> >> Simon Fraser University
>>> >> >> >> http://sites.google.com/site/moslemk/
>>> >> >> >>
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Moslem Kazemi, Ph.D. candidate
>>> >> > Robotics: Motion Planning, Hardware, and Control
>>> >> > Smart Systems: Design and Integration
>>> >> > Simon Fraser University
>>> >> > http://sites.google.com/site/moslemk/
>>> >> >
>>> >
>>> >
>>> >
>>> > --
>>> > Moslem Kazemi, Ph.D. candidate
>>> > Robotics: Motion Planning, Hardware, and Control
>>> > Smart Systems: Design and Integration
>>> > Simon Fraser University
>>> > http://sites.google.com/site/moslemk/
>>> >
>>
>>
>>
>> --
>> Moslem Kazemi, Ph.D. candidate
>> Robotics: Motion Planning, Hardware, and Control
>> Smart Systems: Design and Integration
>> Simon Fraser University
>> http://sites.google.com/site/moslemk/
>
>
>
> --
> Moslem Kazemi, Ph.D. candidate
> Robotics: Motion Planning, Hardware, and Control
> Smart Systems: Design and Integration
> Simon Fraser University
> http://sites.google.com/site/moslemk/
>



--
Moslem Kazemi, Ph.D. candidate
Robotics: Motion Planning, Hardware, and Control
Smart Systems: Design and Integration
Simon Fraser University
http://sites.google.com/site/moslemk/

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: Relative positioning of kinbodies

Rosen Diankov
Administrator
there is no functionality for this, although it is an interesting
concept to be able to serialize the generated graphs from the planner.
rosen,

2010/6/5 Moslem Kazemi <[hidden email]>:

> No! What I meant was that for example I have a tree (as in RRT planner)
> stored in a text file ... Now I like to load it in openrave and I was
> wondering if there is a class/interface available for this purpose? As you
> mentioned to load trajectories from text files one could use trajectory.h
> interface which I am using right now ....do we have such capability to load
> trees? Hope I am clear!
> Thanks.
> --Moslem.
>
> On Sat, Jun 5, 2010 at 10:15 AM, Rosen Diankov <[hidden email]>
> wrote:
>>
>> hi moslem,
>>
>> i'm not sure what you mean by 'similar to trajectory.h' since that
>> file format is just an array of values..
>> are you asking if there's a way to export openrave kinematics into a file?
>> rosen,
>>
>>
>> 2010/6/5 Moslem Kazemi <[hidden email]>:
>> > Hi Rosen,
>> > Is there an interface to read/store tree structures from/into text
>> > files,
>> > similar to the trajectory.h for trajectories? I couldn't find any ....
>> > Thanks,
>> > --Moslem.
>> >
>> > On Sat, Jun 5, 2010 at 9:34 AM, Moslem Kazemi <[hidden email]> wrote:
>> >>
>> >> Yes, that worked like a charm!
>> >> Thanks!
>> >> --Moslem.
>> >>
>> >> On Fri, Jun 4, 2010 at 5:36 PM, Rosen Diankov <[hidden email]>
>> >> wrote:
>> >>>
>> >>> hi moslem,
>> >>>
>> >>> For plotting lines, triangles, etc, look at the testplotting.py
>> >>> example file. it will show you all the possibilities. each of these
>> >>> calls returns a handle, that once deleted, will delete the graph
>> >>>
>> >>> for running trajectories from file, currently openrave has a very
>> >>> simple text trajectory format outline in rave/trajectory.h
>> >>>
>> >>> You can get a robot to follow this a trajectory in file traj.txt by:
>> >>>
>> >>> manip=interfaces.BaseManipulation(robot)
>> >>> manip.TrajFromData(open('traj.txt','r').read())
>> >>>
>> >>> # will wait until robot stops followings its trajectory
>> >>> robot.WaitForController(0)
>> >>>
>> >>> hope this answers your questions
>> >>> rosen,
>> >>>
>> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >>> > I am programming in python ...
>> >>> > --Moslem.
>> >>> >
>> >>> > On Fri, Jun 4, 2010 at 5:57 PM, Rosen Diankov
>> >>> > <[hidden email]>
>> >>> > wrote:
>> >>> >>
>> >>> >> hi moslem,
>> >>> >> all that is possible, please tell me what language you'd prefer to
>> >>> >> do
>> >>> >> this in and i can point you to the correct example code
>> >>> >> rosen,
>> >>> >>
>> >>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >>> >> > Thanks! But I enjoy the viewer and actually I really need it for
>> >>> >> > visualization! It is nice to have it ....
>> >>> >> > By the way, I have a time parameterized joint trajectory which is
>> >>> >> > stored
>> >>> >> > in
>> >>> >> > a text file .... I like to move the robot and visualize the
>> >>> >> > motion
>> >>> >> > of
>> >>> >> > the
>> >>> >> > robot along this path. Is there any controller for this purpose
>> >>> >> > or I
>> >>> >> > should
>> >>> >> > read the path and then displace the robot be setting joint angles
>> >>> >> > with a
>> >>> >> > proper timing? What would you suggest?
>> >>> >> > Meanwhile, I like also to draw some lines/paths in the
>> >>> >> > environment!
>> >>> >> > Is
>> >>> >> > there
>> >>> >> > a plugin or interface for that?
>> >>> >> > Hope I am not asking too much! I am just excited to implement my
>> >>> >> > stuff
>> >>> >> > and
>> >>> >> > create some demos ....
>> >>> >> > Thanks,
>> >>> >> > --Moslem.
>> >>> >> >
>> >>> >> > On Fri, Jun 4, 2010 at 4:48 PM, Rosen Diankov
>> >>> >> > <[hidden email]>
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> disabling the GUI (ie not attaching a viewer) will give you 100%
>> >>> >> >> stability within openrave
>> >>> >> >> rosen,
>> >>> >> >>
>> >>> >> >> 2010/6/4 Rosen Diankov <[hidden email]>:
>> >>> >> >> > hi moslem,
>> >>> >> >> > i wouldn't be surprised, soqt, qt4, and coin3d are very
>> >>> >> >> > unstable
>> >>> >> >> > libraries. The testsensorcamera.py combines them with the
>> >>> >> >> > Tkinter
>> >>> >> >> > python library, which I think calls gtk as the backend. In the
>> >>> >> >> > end,
>> >>> >> >> > it's a big mess of threads fighting for the GUI ;0)
>> >>> >> >> >
>> >>> >> >> > i'm at least hoping to replace qt4 and coin3d with
>> >>> >> >> > openscenegraph+gtk
>> >>> >> >> >
>> >>> >> >> > rosen,
>> >>> >> >> >
>> >>> >> >> > 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >>> >> >> >> Hi Rosen,
>> >>> >> >> >> I am testing the robot model that I just created for our
>> >>> >> >> >> robotic
>> >>> >> >> >> arm
>> >>> >> >> >> with a
>> >>> >> >> >> camera sensor. I adapted the code testsensorcamera.py from
>> >>> >> >> >> openrave
>> >>> >> >> >> examples
>> >>> >> >> >> and just load my own environment/robot model with no other
>> >>> >> >> >> changes!
>> >>> >> >> >> It
>> >>> >> >> >> works
>> >>> >> >> >> almost fine .... However, sometimes when I run the code
>> >>> >> >> >> (without
>> >>> >> >> >> any
>> >>> >> >> >> changes) it gives me this error and the camera/sensor view
>> >>> >> >> >> halts
>> >>> >> >> >> and
>> >>> >> >> >> I
>> >>> >> >> >> have
>> >>> >> >> >> to close the viewer and camera view and run again! This
>> >>> >> >> >> happens
>> >>> >> >> >> from
>> >>> >> >> >> time to
>> >>> >> >> >> time .....
>> >>> >> >> >> Here is the error:
>> >>> >> >> >> Enter command (q-quit,c-capture image): error in background
>> >>> >> >> >> error
>> >>> >> >> >> handler:
>> >>> >> >> >> out of stack space (infinite loop?)
>> >>> >> >> >>     while executing
>> >>> >> >> >> "::tcl::Bgerror {out of stack space (infinite loop?)} {-code
>> >>> >> >> >> 1
>> >>> >> >> >> -level 0
>> >>> >> >> >> -errorco
>> >>> >> >> >> de NONE -errorinfo {out of stack space (infinite loop?)
>> >>> >> >> >>     while execu..."
>> >>> >> >> >> Any suggestion?
>> >>> >> >> >> Thanks,
>> >>> >> >> >> --Moslem.
>> >>> >> >> >>
>> >>> >> >> >> On Fri, Jun 4, 2010 at 2:29 PM, Rosen Diankov
>> >>> >> >> >> <[hidden email]>
>> >>> >> >> >> wrote:
>> >>> >> >> >>>
>> >>> >> >> >>> no, it doesn't.
>> >>> >> >> >>> i usually open the robot with python and print the coord
>> >>> >> >> >>> frames
>> >>> >> >> >>> out
>> >>> >> >> >>> explicitly...
>> >>> >> >> >>> rosen,
>> >>> >> >> >>>
>> >>> >> >> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >>> >> >> >>> > Does the viewer has the capability of showing the link
>> >>> >> >> >>> > coord
>> >>> >> >> >>> > frames
>> >>> >> >> >>> > (or
>> >>> >> >> >>> > kinbody coord frames)?
>> >>> >> >> >>> > --Moslem.
>> >>> >> >> >>> >
>> >>> >> >> >>> > On Fri, Jun 4, 2010 at 2:11 PM, Moslem Kazemi
>> >>> >> >> >>> > <[hidden email]>
>> >>> >> >> >>> > wrote:
>> >>> >> >> >>> >>
>> >>> >> >> >>> >> No, it was my bad! :) just got it ....Thanks!
>> >>> >> >> >>> >>
>> >>> >> >> >>> >> On Fri, Jun 4, 2010 at 2:11 PM, Rosen Diankov
>> >>> >> >> >>> >> <[hidden email]>
>> >>> >> >> >>> >> wrote:
>> >>> >> >> >>> >>>
>> >>> >> >> >>> >>> sorry, i assumed that link1 was the name of your second
>> >>> >> >> >>> >>> link.
>> >>> >> >> >>> >>> please
>> >>> >> >> >>> >>> replace the name="XXX" correspondingly.
>> >>> >> >> >>> >>> rosen,
>> >>> >> >> >>> >>>
>> >>> >> >> >>> >>> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >>> >> >> >>> >>> > Thanks! It complains that the link has no geometry
>> >>> >> >> >>> >>> > attached
>> >>> >> >> >>> >>> > to
>> >>> >> >> >>> >>> > it!
>> >>> >> >> >>> >>> > Should I
>> >>> >> >> >>> >>> > care about this?
>> >>> >> >> >>> >>> >
>> >>> >> >> >>> >>> > On Fri, Jun 4, 2010 at 2:04 PM, Rosen Diankov
>> >>> >> >> >>> >>> > <[hidden email]>
>> >>> >> >> >>> >>> > wrote:
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >> hi moslem,
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >> the offsetfrom tag is only valid with the <body> tag.
>> >>> >> >> >>> >>> >> in
>> >>> >> >> >>> >>> >> your
>> >>> >> >> >>> >>> >> case,
>> >>> >> >> >>> >>> >> you are putting it inside the <kinbody> tag. This
>> >>> >> >> >>> >>> >> actually
>> >>> >> >> >>> >>> >> sets
>> >>> >> >> >>> >>> >> the
>> >>> >> >> >>> >>> >> translation of the actual body, not the link.
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >> if you want to move link1, perhaps this will work:
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >> <KinBody file="link1.xml">
>> >>> >> >> >>> >>> >> <body name="link1">
>> >>> >> >> >>> >>> >> <offsetfrom>base</offsetfrom>
>> >>> >> >> >>> >>> >> <Translation>0.0 0.0 0.2255</Translation>
>> >>> >> >> >>> >>> >> </body>
>> >>> >> >> >>> >>> >> </KinBody>
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >> if you look at the examples in the robots folder of
>> >>> >> >> >>> >>> >> how
>> >>> >> >> >>> >>> >> hands
>> >>> >> >> >>> >>> >> are
>> >>> >> >> >>> >>> >> merged with arms, you'll see that the link definition
>> >>> >> >> >>> >>> >> of
>> >>> >> >> >>> >>> >> the
>> >>> >> >> >>> >>> >> hand
>> >>> >> >> >>> >>> >> usually holds the <offsetfrom> tag of the arm end
>> >>> >> >> >>> >>> >> effector
>> >>> >> >> >>> >>> >> link.
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >> rosen,
>> >>> >> >> >>> >>> >>
>> >>> >> >> >>> >>> >> 2010/6/4 Moslem Kazemi <[hidden email]>:
>> >>> >> >> >>> >>> >> > Hi Rosen,
>> >>> >> >> >>> >>> >> > I noticed that when I define the kinbody of the
>> >>> >> >> >>> >>> >> > robot
>> >>> >> >> >>> >>> >> > as
>> >>> >> >> >>> >>> >> > follows:
>> >>> >> >> >>> >>> >> > <KinBody name="ramparm">
>> >>> >> >> >>> >>> >> > <KinBody file="base.xml"></KinBody>
>> >>> >> >> >>> >>> >> >
>> >>> >> >> >>> >>> >> > <KinBody file="link1.xml">
>> >>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >>> >> >> >>> >>> >> > <Translation>0.0 0.0 0.2255</Translation>
>> >>> >> >> >>> >>> >> > </KinBody>
>> >>> >> >> >>> >>> >> > <Joint name="J1" type="hinge">
>> >>> >> >> >>> >>> >> > <Body>base</Body>
>> >>> >> >> >>> >>> >> > <Body>link1</Body>
>> >>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom>
>> >>> >> >> >>> >>> >> > <weight>0.2</weight>
>> >>> >> >> >>> >>> >> > <lostop>-100</lostop>
>> >>> >> >> >>> >>> >> > <histop>100</histop>
>> >>> >> >> >>> >>> >> > <axis>0 0 1</axis>
>> >>> >> >> >>> >>> >> > <maxvel>1.5</maxvel>
>> >>> >> >> >>> >>> >> > <resolution>0.5</resolution>
>> >>> >> >> >>> >>> >> > </Joint>
>> >>> >> >> >>> >>> >> > <KinBody
>> >>> >> >> >>> >>> >> > The translation <Translation>0.0 0.0
>> >>> >> >> >>> >>> >> > 0.2255</Translation>
>> >>> >> >> >>> >>> >> > is
>> >>> >> >> >>> >>> >> > always
>> >>> >> >> >>> >>> >> > w.r.t.
>> >>> >> >> >>> >>> >> > the absolute world coordinate frame! and it does
>> >>> >> >> >>> >>> >> > not
>> >>> >> >> >>> >>> >> > take
>> >>> >> >> >>> >>> >> > <offsetfrom>base</offsetfrom> into account!
>> >>> >> >> >>> >>> >> > It does not even return an error if I change "base"
>> >>> >> >> >>> >>> >> > in <offsetfrom>base</offsetfrom> with some kinbody
>> >>> >> >> >>> >>> >> > which
>> >>> >> >> >>> >>> >> > have
>> >>> >> >> >>> >>> >> > not
>> >>> >> >> >>> >>> >> > even
>> >>> >> >> >>> >>> >> > been
>> >>> >> >> >>> >>> >> > defined, like "blabla"!
>> >>> >> >> >>> >>> >> > Thanks,
>> >>> >> >> >>> >>> >> > --Moslem.
>> >>> >> >> >>> >>> >> > and here is for example the base.xml file. link1 is
>> >>> >> >> >>> >>> >> > similar
>> >>> >> >> >>> >>> >> > ....
>> >>> >> >> >>> >>> >> > <?xml version="1.0" encoding="utf-8"?>
>> >>> >> >> >>> >>> >> > <KinBody>
>> >>> >> >> >>> >>> >> > <Body name="base" type="dynamic">
>> >>> >> >> >>> >>> >> > <Translation>0.0  0.0  0.0</Translation>
>> >>> >> >> >>> >>> >> > <Geom type="trimesh">
>> >>> >> >> >>> >>> >> > <Data>../../vrml/PAM102.wrl 0.001</Data>
>> >>> >> >> >>> >>> >> > <Render>../../vrml/PAM102.wrl 0.001</Render>
>> >>> >> >> >>> >>> >> > <Translation>0.0  0.0  0.045</Translation>
>> >>> >> >> >>> >>> >> > <rotationaxis>1 0 0 -90</rotationaxis>
>> >>> >> >> >>> >>> >> > <diffuseColor>0.01 0.01 0.5</diffuseColor>
>> >>> >> >> >>> >>> >> > </Geom>
>> >>> >> >> >>> >>> >> > <Geom type="trimesh">
>> >>> >> >> >>> >>> >> > <Translation>0.0 0.0 0.135</Translation>
>> >>> >> >> >>> >>> >> > <rotationaxis>1 0 0 0</rotationaxis>
>> >>> >> >> >>> >>> >> > <Data>../../vrml/PR90_half.wrl 0.001</Data>
>> >>> >> >> >>> >>> >> > <Render>../../vrml/PR90_half.wrl  0.001</Render>
>> >>> >> >> >>> >>> >> > <diffuseColor>0.05 1 .05</diffuseColor>
>> >>> >> >> >>> >>> >> > </Geom>
>> >>> >> >> >>> >>> >> > </Body>
>> >>> >> >> >>> >>> >> > </KinBody>
>> >>> >> >> >>> >>> >> >
>> >>> >> >> >>> >>> >> >
>> >>> >> >> >>> >>> >> >
>> >>> >> >> >>> >>> >> >
>> >>> >> >> >>> >>> >> > --
>> >>> >> >> >>> >>> >> > Moslem Kazemi, Ph.D. candidate
>> >>> >> >> >>> >>> >> > Robotics: Motion Planning, Hardware, and Control
>> >>> >> >> >>> >>> >> > Smart Systems: Design and Integration
>> >>> >> >> >>> >>> >> > Simon Fraser University
>> >>> >> >> >>> >>> >> > http://sites.google.com/site/moslemk/
>> >>> >> >> >>> >>> >> >
>> >>> >> >> >>> >>> >
>> >>> >> >> >>> >>> >
>> >>> >> >> >>> >>> >
>> >>> >> >> >>> >>> > --
>> >>> >> >> >>> >>> > Moslem Kazemi, Ph.D. candidate
>> >>> >> >> >>> >>> > Robotics: Motion Planning, Hardware, and Control
>> >>> >> >> >>> >>> > Smart Systems: Design and Integration
>> >>> >> >> >>> >>> > Simon Fraser University
>> >>> >> >> >>> >>> > http://sites.google.com/site/moslemk/
>> >>> >> >> >>> >>> >
>> >>> >> >> >>> >>
>> >>> >> >> >>> >>
>> >>> >> >> >>> >>
>> >>> >> >> >>> >> --
>> >>> >> >> >>> >> Moslem Kazemi, Ph.D. candidate
>> >>> >> >> >>> >> Robotics: Motion Planning, Hardware, and Control
>> >>> >> >> >>> >> Smart Systems: Design and Integration
>> >>> >> >> >>> >> Simon Fraser University
>> >>> >> >> >>> >> http://sites.google.com/site/moslemk/
>> >>> >> >> >>> >
>> >>> >> >> >>> >
>> >>> >> >> >>> >
>> >>> >> >> >>> > --
>> >>> >> >> >>> > Moslem Kazemi, Ph.D. candidate
>> >>> >> >> >>> > Robotics: Motion Planning, Hardware, and Control
>> >>> >> >> >>> > Smart Systems: Design and Integration
>> >>> >> >> >>> > Simon Fraser University
>> >>> >> >> >>> > http://sites.google.com/site/moslemk/
>> >>> >> >> >>> >
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >> --
>> >>> >> >> >> Moslem Kazemi, Ph.D. candidate
>> >>> >> >> >> Robotics: Motion Planning, Hardware, and Control
>> >>> >> >> >> Smart Systems: Design and Integration
>> >>> >> >> >> Simon Fraser University
>> >>> >> >> >> http://sites.google.com/site/moslemk/
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > --
>> >>> >> > Moslem Kazemi, Ph.D. candidate
>> >>> >> > Robotics: Motion Planning, Hardware, and Control
>> >>> >> > Smart Systems: Design and Integration
>> >>> >> > Simon Fraser University
>> >>> >> > http://sites.google.com/site/moslemk/
>> >>> >> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Moslem Kazemi, Ph.D. candidate
>> >>> > Robotics: Motion Planning, Hardware, and Control
>> >>> > Smart Systems: Design and Integration
>> >>> > Simon Fraser University
>> >>> > http://sites.google.com/site/moslemk/
>> >>> >
>> >>
>> >>
>> >>
>> >> --
>> >> Moslem Kazemi, Ph.D. candidate
>> >> Robotics: Motion Planning, Hardware, and Control
>> >> Smart Systems: Design and Integration
>> >> Simon Fraser University
>> >> http://sites.google.com/site/moslemk/
>> >
>> >
>> >
>> > --
>> > Moslem Kazemi, Ph.D. candidate
>> > Robotics: Motion Planning, Hardware, and Control
>> > Smart Systems: Design and Integration
>> > Simon Fraser University
>> > http://sites.google.com/site/moslemk/
>> >
>
>
>
> --
> Moslem Kazemi, Ph.D. candidate
> Robotics: Motion Planning, Hardware, and Control
> Smart Systems: Design and Integration
> Simon Fraser University
> http://sites.google.com/site/moslemk/
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users