Affine trajectories: a few questions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Affine trajectories: a few questions

Brennan Peter Sellner
We're making use of affine trajectories, and I have a few clarification
questions:

1. If specifying rotations in DOF_Rotation3D (theta * axis) format, how
does one specify a rotation of 0?  Given this format, the resulting vector
is of magnitude 0, which understandably gives Coin fits.  Since affine
moves are specified in an absolute frame, this means that there's no way
to *exactly* return to the starting position.

2. All Trajectory instances are specified in an absolute frame.  This is
an understandable design decision, but it is often useful (especially with
affine trajectories) to specify moves relative to the robot's current
position.  I haven't been able to find a way to do this -- am I missing
something?  I could certainly do the math in my plugin's code (although it
would be somewhat tedious), but I can't find an accessor for the robot's
current joint values -- I'm sure it must be there, but I can't find it for
the life of me.  This is more a matter of convenience than necessity.

3. Finally, when setting a trajectory (at least via
RobotBase::SetActiveMotion()), the first point is always moved to
instantaneously, regardless of the time field of the first TPOINT, for
both affine and joint moves.  I would expect the robot to move smoothly
from the current position to the first TPOINT if the first point's time is
> 0, rather than jumping.  Am I misinterpreting the semantics of
TPOINT::time, or is this a bug?

Thanks!

-Brennan




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Affine trajectories: a few questions

Rosen Diankov-2
Hi Brennan,

> 1. If specifying rotations in DOF_Rotation3D (theta * axis) format, how
> does one specify a rotation of 0?  Given this format, the resulting vector
> is of magnitude 0, which understandably gives Coin fits.  Since affine
> moves are specified in an absolute frame, this means that there's no way
> to *exactly* return to the starting position.
You would give [0 0 0], there was a bug with this that I just fixed,
thanks for pointing it out! (check out rev 246). I recommend using the
quaternion specification for rotations through.

> 2. All Trajectory instances are specified in an absolute frame.  This is
> an understandable design decision, but it is often useful (especially with
> affine trajectories) to specify moves relative to the robot's current
> position.  I haven't been able to find a way to do this -- am I missing
> something?  I could certainly do the math in my plugin's code (although it
> would be somewhat tedious), but I can't find an accessor for the robot's
> current joint values -- I'm sure it must be there, but I can't find it for
> the life of me.  This is more a matter of convenience than necessity.


The fact that trajectories are specified in absolute frame doesn't
mean you can't work with trajectories that are relative to the robot.
Just have write some code that given a full joint trajectory,
multiplies each point's transformation matrix with the current robot's
transformation. Then set it with RobotBase::SetMotion. For example,
here's what a function would look like that sets a relative active
motion

SetRelativeActiveMotion(RobotBase* probot, Trajectory* pTrajActive)
{
Trajectory* ptrajfull = g_pEnviron->CreateTrajectory(probot->GetDOF());
probot->GetFullTrajectoryFromActive(ptrajfull, pTrajActive);
FOREACH(itpoint, ptrajfull->GetPoints()) {
    itpoint->trans = probot->GetTransform() * itpoint->trans;
}
probot->SetMotion(ptrajfull)
}

As for joint values, check out KinBody::GetJointValues, or
RobotBase::GetActiveDOFValues

> 3. Finally, when setting a trajectory (at least via
> RobotBase::SetActiveMotion()), the first point is always moved to
> instantaneously, regardless of the time field of the first TPOINT, for
> both affine and joint moves.  I would expect the robot to move smoothly
> from the current position to the first TPOINT if the first point's time is
>> 0, rather than jumping.  Am I misinterpreting the semantics of
> TPOINT::time, or is this a bug?

This is all dependent on how the Controller executes the trajectory.
The default robot controller is IdealController and specified in
basecontrollers. IdealController is meant to just playback the
trajectory as is, it makes it easier to test stuff when it doesn't add
its own motions to guarantee a smooth robot trajectory. For a
controller meant to control a real robot, I would be very worried if
the controller did this jumping. You are more than welcome to copy
IdealController and make your own implementation.

Hope this helps!
Rosen,


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Affine trajectories: a few questions

Brennan Peter Sellner
On Sat, 12 Jul 2008, Rosen Diankov wrote:

> The fact that trajectories are specified in absolute frame doesn't
> mean you can't work with trajectories that are relative to the robot.
> Just have write some code that given a full joint trajectory,
> multiplies each point's transformation matrix with the current robot's
> transformation. Then set it with RobotBase::SetMotion. For example,
> here's what a function would look like that sets a relative active
> motion
>
> SetRelativeActiveMotion(RobotBase* probot, Trajectory* pTrajActive)
> {
> Trajectory* ptrajfull = g_pEnviron->CreateTrajectory(probot->GetDOF());
> probot->GetFullTrajectoryFromActive(ptrajfull, pTrajActive);
> FOREACH(itpoint, ptrajfull->GetPoints()) {
>    itpoint->trans = probot->GetTransform() * itpoint->trans;
> }
> probot->SetMotion(ptrajfull)
> }

Ah, okay.  From the comments in Trajectory.h, I was interpreting
TPOINT::trans to be the transform to the "first link" (Trajectory.h:76),
which I assumed meant the first link of the robot, and equal to
probot->GetTransform().

> This is all dependent on how the Controller executes the trajectory.
> The default robot controller is IdealController and specified in
> basecontrollers. IdealController is meant to just playback the
> trajectory as is, it makes it easier to test stuff when it doesn't add
> its own motions to guarantee a smooth robot trajectory. For a
> controller meant to control a real robot, I would be very worried if
> the controller did this jumping. You are more than welcome to copy
> IdealController and make your own implementation.

Fair enough: now that we can add a 0-move point at the beginning for
affine rotations, it's not an issues.

Thanks!

-Brennan


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Affine trajectories: a few questions

Rosen Diankov-2
You are right in your interpretation, the transform of the first link
is the transform of the robot:

probot->GetTransform() == probot->GetLinks()[0]->GetTransform()

and probot->SetTransform() moves the first link. Since every other
link is with respect to the first link, the entire robot moves
accordingly.

rosen,

2008/7/13 Brennan Peter Sellner <[hidden email]>:

> On Sat, 12 Jul 2008, Rosen Diankov wrote:
>> The fact that trajectories are specified in absolute frame doesn't
>> mean you can't work with trajectories that are relative to the robot.
>> Just have write some code that given a full joint trajectory,
>> multiplies each point's transformation matrix with the current robot's
>> transformation. Then set it with RobotBase::SetMotion. For example,
>> here's what a function would look like that sets a relative active
>> motion
>>
>> SetRelativeActiveMotion(RobotBase* probot, Trajectory* pTrajActive)
>> {
>> Trajectory* ptrajfull = g_pEnviron->CreateTrajectory(probot->GetDOF());
>> probot->GetFullTrajectoryFromActive(ptrajfull, pTrajActive);
>> FOREACH(itpoint, ptrajfull->GetPoints()) {
>>    itpoint->trans = probot->GetTransform() * itpoint->trans;
>> }
>> probot->SetMotion(ptrajfull)
>> }
>
> Ah, okay.  From the comments in Trajectory.h, I was interpreting
> TPOINT::trans to be the transform to the "first link" (Trajectory.h:76),
> which I assumed meant the first link of the robot, and equal to
> probot->GetTransform().
>
>> This is all dependent on how the Controller executes the trajectory.
>> The default robot controller is IdealController and specified in
>> basecontrollers. IdealController is meant to just playback the
>> trajectory as is, it makes it easier to test stuff when it doesn't add
>> its own motions to guarantee a smooth robot trajectory. For a
>> controller meant to control a real robot, I would be very worried if
>> the controller did this jumping. You are more than welcome to copy
>> IdealController and make your own implementation.
>
> Fair enough: now that we can add a 0-move point at the beginning for
> affine rotations, it's not an issues.
>
> Thanks!
>
> -Brennan
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>


Loading...