trajectory generation in KDL

Submitted by bruyninc on Thu, 2010-11-18 13:36

RTT-dev

On Thu, 18 Nov 2010, Konrad Banachowicz wrote:

> I am going to add cubic spline and quintic spline trajectory generation
> to KDL.

Great idea :-)

> I need those for integration with ROS, especially for my JointSplineTrajectoryGenerator package.
> I looked in KDL code and KDL::VelocityProfile looks good as the base for
> may code but i have problem how to handle SetProfile and
> SetProfileDuration in my spline generator because those methods take only
> two positions witch is not enough for generation of spline.

> Maybe i should make my VelocityProfile smart and depending on arguments
> of SetProfileDuration do linear, cubic spline, quintic spline
> interpolation ?
> But there is SetProfile which don't specify the duration which is required.

The (very welcome) addition that you have in mind will require most
probably a thorough redesign of what is there already in KDL. I am very
interested and motivated to start this discussion :-)

Thanks a lot for your appreciated efforts!

Herman

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Thu, 2010-11-18 14:48.

Because KDL classes are all related to cartesian space trajectories, I think
there should b? added JointTrajectory class to be base for all joint space
trajectory generators.
The main question is which methods should be defined by the base class.
My proposal is that pos, vel, acc and duration methods should be defined by
the base class and SetProfile should be left for concrete implementation.
An other question is should JointTrajectory handle mulitiple DOF internally
or user should create multiple JointTrajectory objects each handling single
DOF ?

Pozdrawiam
Konrad Banachowicz

»

Login or register to post comments

trajectory generation in KDL

Submitted by snrkiwi on Thu, 2010-11-18 15:20.

On Nov 18, 2010, at 09:45 , Konrad Banachowicz wrote:

> Because KDL classes are all related to cartesian space trajectories, I think there should b? added JointTrajectory class to be base for all joint space trajectory generators.
> The main question is which methods should be defined by the base class.
> My proposal is that pos, vel, acc and duration methods should be defined by the base class and SetProfile should be left for concrete implementation.
> An other question is should JointTrajectory handle mulitiple DOF internally or user should create multiple JointTrajectory objects each handling single DOF ?

Do you have a UML diagram of how this all goes together? And any use case documentation of how an application user would bring all this together?
S
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Thu, 2010-11-18 15:52.

2010/11/18 S Roderick <kiwi [dot] net [..] ...>

> On Nov 18, 2010, at 09:45 , Konrad Banachowicz wrote:
>
> > Because KDL classes are all related to cartesian space trajectories, I
> think there should b? added JointTrajectory class to be base for all joint
> space trajectory generators.
> > The main question is which methods should be defined by the base class.
> > My proposal is that pos, vel, acc and duration methods should be defined
> by the base class and SetProfile should be left for concrete implementation.
> > An other question is should JointTrajectory handle mulitiple DOF
> internally or user should create multiple JointTrajectory objects each
> handling single DOF ?
>
> Do you have a UML diagram of how this all goes together? And any use case
> documentation of how an application user would bring all this together?
>
I don't think that UML is necessary here because there is only single
inheritance form JontTrajectory interface class.
My current implementation have JointSplineTrajectory which take number of
joints as constructor parameter.
After reception of new trajectory point one of versions of
generateCofficients is called depending on available trajectory point
informations.
Every control loop sampleSpline method is called and newly calculated
setpoint is send to servo component.

»

Login or register to post comments

trajectory generation in KDL

Submitted by snrkiwi on Thu, 2010-11-18 16:00.

On Nov 18, 2010, at 10:48 , Konrad Banachowicz wrote:

> 2010/11/18 S Roderick <kiwi [dot] net [..] ...>
> On Nov 18, 2010, at 09:45 , Konrad Banachowicz wrote:
>
> > Because KDL classes are all related to cartesian space trajectories, I think there should b? added JointTrajectory class to be base for all joint space trajectory generators.
> > The main question is which methods should be defined by the base class.
> > My proposal is that pos, vel, acc and duration methods should be defined by the base class and SetProfile should be left for concrete implementation.
> > An other question is should JointTrajectory handle mulitiple DOF internally or user should create multiple JointTrajectory objects each handling single DOF ?
>
> Do you have a UML diagram of how this all goes together? And any use case documentation of how an application user would bring all this together?
> I don't think that UML is necessary here because there is only single inheritance form JontTrajectory interface class.
> My current implementation have JointSplineTrajectory which take number of joints as constructor parameter.
> After reception of new trajectory point one of versions of generateCofficients is called depending on available trajectory point informations.
> Every control loop sampleSpline method is called and newly calculated setpoint is send to servo component.

Show me how I use this as a user. You haven't answered that.

Show me how your JointTrajectory class is called. What is "after reception of new trajectory point"? What is a "trajectory point"? Reception of what? And from whom?

A diagram (UML or otherwise) might help others understand the design you have in your head. And hence, how we might use this feature and/or contribute to it.

S

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Thu, 2010-11-18 16:16.

2010/11/18 Stephen Roderick <kiwi [dot] net [..] ...>

> On Nov 18, 2010, at 10:48 , Konrad Banachowicz wrote:
>
> 2010/11/18 S Roderick <kiwi [dot] net [..] ...>
>
>> On Nov 18, 2010, at 09:45 , Konrad Banachowicz wrote:
>>
>> > Because KDL classes are all related to cartesian space trajectories, I
>> think there should b? added JointTrajectory class to be base for all joint
>> space trajectory generators.
>> > The main question is which methods should be defined by the base class.
>> > My proposal is that pos, vel, acc and duration methods should be defined
>> by the base class and SetProfile should be left for concrete implementation.
>> > An other question is should JointTrajectory handle mulitiple DOF
>> internally or user should create multiple JointTrajectory objects each
>> handling single DOF ?
>>
>> Do you have a UML diagram of how this all goes together? And any use case
>> documentation of how an application user would bring all this together?
>>
> I don't think that UML is necessary here because there is only single
> inheritance form JontTrajectory interface class.
> My current implementation have JointSplineTrajectory which take number of
> joints as constructor parameter.
> After reception of new trajectory point one of versions of
> generateCofficients is called depending on available trajectory point
> informations.
> Every control loop sampleSpline method is called and newly calculated
> setpoint is send to servo component.
>
>
> Show me how I use this as a user. You haven't answered that.
>
> Show me how your JointTrajectory class is called. What is "after reception
> of new trajectory point"? What is a "trajectory point"? Reception of what?
> And from whom
>

Maybe some example code would be helpful :

class TrajectoryPoint {
public:
  std::vector<double> positions;
  std::vector<double> velocities;
  std::vector<double> accelerations;
  double duration;
}
 
.......
 
TrajectoryPoint pointNew;
 
JointSplineTrajectory trj(6); // create trajectory for 6DOF
 
trajectory_port.read(point);
 
if(point.accelerations)
{
  trj.generateCofficients(pointOld.positions, pointNew.positions,
pointOld.velocities, pointNew.velocities, pointOld.accelerations,
pointNew.accelerations, pointNew.duration);
} else if(point.velocites)
{
  trj.generateCofficients(pointOld.positions, pointNew.positions,
pointOld.velocities, pointNew.velocities, pointNew.duration);
} else
{
  trj.generateCofficients(pointOld.positions, pointNew.positions,
pointNew.duration);
}
 
......
 
time += dt;
Setpoints set;
trj.sampleSpline(set.positions, set.velocities, set.accelerations, time);
 
setpoint_port.write(set);

»

Login or register to post comments

Ruben Smits's picture

trajectory generation in KDL

Submitted by Ruben Smits on Thu, 2010-11-18 14:56.

On Thursday 18 November 2010 15:45:48 Konrad Banachowicz wrote:
> Because KDL classes are all related to cartesian space trajectories, I
> think there should b? added JointTrajectory class to be base for all joint
> space trajectory generators. The main question is which methods should be
> defined by the base class. My proposal is that pos, vel, acc and duration
> methods should be defined by the base class and SetProfile should be left
> for concrete implementation. An other question is should JointTrajectory
> handle mulitiple DOF internally or user should create multiple
> JointTrajectory objects each handling single DOF ?

The velocity profiles themselves are not related in any way to cartesian space
trajectories.

We have
Paths: these are paths in cartesian space without any timing
Velocity Profiles: these only take care of timing
Trajectories: these are the combination of a velocity profile and a path: it
adds the timing on top of the path.

Ruben

> Pozdrawiam
> Konrad Banachowicz
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Thu, 2010-11-18 15:48.

2010/11/18 Ruben Smits <ruben [dot] smits [..] ...>

> On Thursday 18 November 2010 15:45:48 Konrad Banachowicz wrote:
> > Because KDL classes are all related to cartesian space trajectories, I
> > think there should b? added JointTrajectory class to be base for all
> joint
> > space trajectory generators. The main question is which methods should be
> > defined by the base class. My proposal is that pos, vel, acc and duration
> > methods should be defined by the base class and SetProfile should be left
> > for concrete implementation. An other question is should JointTrajectory
> > handle mulitiple DOF internally or user should create multiple
> > JointTrajectory objects each handling single DOF ?
>
> The velocity profiles themselves are not related in any way to cartesian
> space
> trajectories.
>
> We have
> Paths: these are paths in cartesian space without any timing
> Velocity Profiles: these only take care of timing
> Trajectories: these are the combination of a velocity profile and a path:
> it
> adds the timing on top of the path.
>
But documentation say "Velocity Profiles ... expresses position, velocity
and acceleration of a point on a curve in function of time. It defines the
how a point s moves on a path S.". I can't imagine how to define path i
arbitrary joint space. I know that it can be used independently from
KDL::Trajectory but documentation suggests that it is intended for cartesian
trajectory. And there stile is problem with SetProfile which don't supply
enough data for every possible Trajectory.

»

Login or register to post comments

Ruben Smits's picture

trajectory generation in KDL

Submitted by Ruben Smits on Thu, 2010-11-18 19:04.

On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> 2010/11/18 Ruben Smits
> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>
> On Thursday 18 November 2010 15:45:48 Konrad Banachowicz wrote:
> > Because KDL classes are all related to cartesian space trajectories, I
> > think there should b? added JointTrajectory class to be base for all
> > joint space trajectory generators. The main question is which methods
> > should be defined by the base class. My proposal is that pos, vel, acc
> > and duration methods should be defined by the base class and SetProfile
> > should be left for concrete implementation. An other question is should
> > JointTrajectory handle mulitiple DOF internally or user should create
> > multiple
> > JointTrajectory objects each handling single DOF ?
>
> The velocity profiles themselves are not related in any way to cartesian
> space trajectories.
>
> We have
> Paths: these are paths in cartesian space without any timing
> Velocity Profiles: these only take care of timing
> Trajectories: these are the combination of a velocity profile and a path:
> it adds the timing on top of the path.

> But documentation say "Velocity Profiles ... expresses position, velocity
> and acceleration of a point on a curve in function of time. It defines the
> how a point s moves on a path S.". I can't imagine how to define path i
> arbitrary joint space.

You're right, the documentation is clearly not describing the functionality
well. But the API clearly shows that a velocity profile works on a single
value. So it can be easily used for joint trajectories. An example on how it
is currently used as a joint trajectory generator can be found on
http://svn.mech.kuleuven.be/websvn/orocos/trunk/ocl/motion_control/naxes...

> I know that it can be used independently from
> KDL::Trajectory but documentation suggests that it is intended for
> cartesian trajectory. And there stile is problem with SetProfile which
> don't supply enough data for every possible Trajectory.

As you can see in the API of the inherited classes, they add extra algorithm
specific configuration functions, for instance the setMax function of the
velocityprofile_trap:
http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cla...

I'm not saying that this is the best way to do it. But this is how it is done
in the current code. Any suggestions are welcome.

Ruben
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Thu, 2010-11-18 19:28.

2010/11/18 Ruben Smits <ruben [dot] smits [..] ...>

> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > I know that it can be used independently from
> > KDL::Trajectory but documentation suggests that it is intended for
> > cartesian trajectory. And there stile is problem with SetProfile which
> > don't supply enough data for every possible Trajectory.
>
> As you can see in the API of the inherited classes, they add extra
> algorithm
> specific configuration functions, for instance the setMax function of the
> velocityprofile_trap:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cla...
>
Yes but i would like to avoid calling multiple methods for a single
trajectory point.
The problem with additional methods is when coefficients should be
calculated ? If it would be done in SetProfile all other parameters need to
be set before it.
Making that strict calling sequence could be very error-prone.

»

Login or register to post comments

Ruben Smits's picture

trajectory generation in KDL

Submitted by Ruben Smits on Thu, 2010-11-18 19:44.

On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> 2010/11/18 Ruben Smits
> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>
> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > I know that it can be used independently from
> > KDL::Trajectory but documentation suggests that it is intended for
> > cartesian trajectory. And there stile is problem with SetProfile which
> > don't supply enough data for every possible Trajectory.
>
> As you can see in the API of the inherited classes, they add extra
> algorithm specific configuration functions, for instance the setMax
> function of the velocityprofile_trap:
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classK
> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eorocos/p
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><http: /> /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i would like
> to avoid calling multiple methods for a single trajectory point. The
> problem with additional methods is when coefficients should be calculated
> ? If it would be done in SetProfile all other parameters need to be set
> before it. Making that strict calling sequence could be very error-prone.

Can you come up with a minimal set of parameters that can fit for every
possible Trajectory, without having it blowing up?

Ruben

»

Login or register to post comments

trajectory generation in KDL

Submitted by peter on Mon, 2010-11-22 10:12.

On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > 2010/11/18 Ruben Smits
> > <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> >
> > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > I know that it can be used independently from
> > > KDL::Trajectory but documentation suggests that it is intended for
> > > cartesian trajectory. And there stile is problem with SetProfile which
> > > don't supply enough data for every possible Trajectory.
> >
> > As you can see in the API of the inherited classes, they add extra
> > algorithm specific configuration functions, for instance the setMax
> > function of the velocityprofile_trap:
> > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/clas
> > sK
> > DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroco
> > s/p
> > ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><htt
> > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i would
> > like to avoid calling multiple methods for a single trajectory point.
> > The problem with additional methods is when coefficients should be
> > calculated ? If it would be done in SetProfile all other parameters need
> > to be set before it. Making that strict calling sequence could be very
> > error-prone.
>
> Can you come up with a minimal set of parameters that can fit for every
> possible Trajectory, without having it blowing up?

The only solution I see in this issue is to provide the trajectory-specific
parameters (that might be all parameters) in the implementation class. A user
of your trajectory object will then need to know which specific kind of
interpolator is used, in order to parametrize it properly.

As Herman suggests, there are so many kinds of trajectory generators that you
will never agree on a common set of parameters. Fortunately, the ins and outs
are general (joint space or cartesian space pos/vel/acc/...) such that the
most important part of abstraction still holds.

In practice, I see component/node implementations for just *one* specific
trajectory generator, and sharing this input/output data flow (topic) interface
generically among all generators.

Peter

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Mon, 2010-11-22 22:00.

2010/11/22 Peter Soetens <peter [..] ...>

> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > > 2010/11/18 Ruben Smits
> > > <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> > >
> > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > > I know that it can be used independently from
> > > > KDL::Trajectory but documentation suggests that it is intended for
> > > > cartesian trajectory. And there stile is problem with SetProfile
> which
> > > > don't supply enough data for every possible Trajectory.
> > >
> > > As you can see in the API of the inherited classes, they add extra
> > > algorithm specific configuration functions, for instance the setMax
> > > function of the velocityprofile_trap:
> > >
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cla...
> > > sK
> > > DL_1_1VelocityProfile__Trap.html<
> http://people.mech.kuleuven.be/%7Eoroco
> > > s/p
> > >
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><htt
> > > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
> would
> > > like to avoid calling multiple methods for a single trajectory point.
> > > The problem with additional methods is when coefficients should be
> > > calculated ? If it would be done in SetProfile all other parameters
> need
> > > to be set before it. Making that strict calling sequence could be very
> > > error-prone.
> >
> > Can you come up with a minimal set of parameters that can fit for every
> > possible Trajectory, without having it blowing up?
>
> The only solution I see in this issue is to provide the trajectory-specific
> parameters (that might be all parameters) in the implementation class. A
> user
> of your trajectory object will then need to know which specific kind of
> interpolator is used, in order to parametrize it properly.
>
> As Herman suggests, there are so many kinds of trajectory generators that
> you
> will never agree on a common set of parameters. Fortunately, the ins and
> outs
> are general (joint space or cartesian space pos/vel/acc/...) such that the
> most important part of abstraction still holds.
>
So what do you think about extending SetProfile to take pos/vel/acc ?
That would be sufficient representation of trajectory point and all other
things (mexVel, maxAcc ...) would be set by parameters.

>
> In practice, I see component/node implementations for just *one* specific
> trajectory generator, and sharing this input/output data flow (topic)
> interface
> generically among all generators.

Should there be a base class for all generators inherits from TaskContext ?
Or compatibility should be ensured by the creator of the component ?

>
> Peter
>

»

Login or register to post comments

trajectory generation in KDL

Submitted by peter on Wed, 2010-11-24 08:40.

On Monday 22 November 2010 22:56:51 Konrad Banachowicz wrote:
> 2010/11/22 Peter Soetens <peter [..] ...>
>
> > On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > > > 2010/11/18 Ruben Smits
> > > > <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> > > >
> > > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > > > I know that it can be used independently from
> > > > > KDL::Trajectory but documentation suggests that it is intended for
> > > > > cartesian trajectory. And there stile is problem with SetProfile
> >
> > which
> >
> > > > > don't supply enough data for every possible Trajectory.
> > > >
> > > > As you can see in the API of the inherited classes, they add extra
> > > > algorithm specific configuration functions, for instance the setMax
> >
> > > > function of the velocityprofile_trap:
> > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/clas
> > <http://people.mech.kuleuven.be/%7Eorocos/pub/devel/kdl/latest/api/html/c
> > las>
> >
> > > > sK
> > > > DL_1_1VelocityProfile__Trap.html<
> >
> > http://people.mech.kuleuven.be/%7Eoroco
> >
> > > > s/p
> >
> > ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><htt
> >
> > > > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
> >
> > would
> >
> > > > like to avoid calling multiple methods for a single trajectory point.
> > > > The problem with additional methods is when coefficients should be
> > > > calculated ? If it would be done in SetProfile all other parameters
> >
> > need
> >
> > > > to be set before it. Making that strict calling sequence could be
> > > > very error-prone.
> > >
> > > Can you come up with a minimal set of parameters that can fit for every
> > > possible Trajectory, without having it blowing up?
> >
> > The only solution I see in this issue is to provide the
> > trajectory-specific parameters (that might be all parameters) in the
> > implementation class. A user
> > of your trajectory object will then need to know which specific kind of
> > interpolator is used, in order to parametrize it properly.
> >
> > As Herman suggests, there are so many kinds of trajectory generators that
> > you
> > will never agree on a common set of parameters. Fortunately, the ins and
> > outs
> > are general (joint space or cartesian space pos/vel/acc/...) such that
> > the most important part of abstraction still holds.
>
> So what do you think about extending SetProfile to take pos/vel/acc ?

I'll let the kdl maintainer decide on that, but I would agree with this
extension. Judging from Herman's replies to this post, he's also going in that
direction, although with an 'addProfile(pos/vel/acc)' interface for waypoints.
Probably both are required, one for the start point/segment and one for each
additional waypoint.

> That would be sufficient representation of trajectory point and all other
> things (mexVel, maxAcc ...) would be set by parameters.

I agree here.

>
> > In practice, I see component/node implementations for just *one* specific
> > trajectory generator, and sharing this input/output data flow (topic)
> > interface
> > generically among all generators.
>
> Should there be a base class for all generators inherits from TaskContext ?

Once you're done on the KDL API and want to provide these algorithms into
components, yes.

> Or compatibility should be ensured by the creator of the component ?

Both options aren't exclusive. You're not force to inherit from someone else's
base component, but it should be the easiest thing to do.

I think you're moving in the right direction[1], so don't hesitate to try what
you mean and post a patch.

Peter

[1] Err, Ruben has the final word here of course :-)

»

Login or register to post comments

Ruben Smits's picture

trajectory generation in KDL

Submitted by Ruben Smits on Wed, 2010-11-24 09:12.

On Wednesday 24 November 2010 09:36:44 Peter Soetens wrote:
> On Monday 22 November 2010 22:56:51 Konrad Banachowicz wrote:
> > 2010/11/22 Peter Soetens <peter [..] ...>
> >
> > > On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > > > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > > > > 2010/11/18 Ruben Smits
> > > > > <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> > > > >
> > > > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > > > > I know that it can be used independently from
> > > > > > KDL::Trajectory but documentation suggests that it is intended
> > > > > > for cartesian trajectory. And there stile is problem with
> > > > > > SetProfile
> > >
> > > which
> > >
> > > > > > don't supply enough data for every possible Trajectory.
> > > > >
> > > > > As you can see in the API of the inherited classes, they add extra
> > > > > algorithm specific configuration functions, for instance the setMax
> > >
> > > > > function of the velocityprofile_trap:
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
> > > as
> > > <http://people.mech.kuleuven.be/%7Eorocos/pub/devel/kdl/latest/api/htm
> > > l/c las>
> > >
> > > > > sK
> > > > > DL_1_1VelocityProfile__Trap.html<
> > >
> > > http://people.mech.kuleuven.be/%7Eoroco
> > >
> > > > > s/p
> > >
> > > ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
> > > t
> > >
> > > > > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
> > >
> > > would
> > >
> > > > > like to avoid calling multiple methods for a single trajectory
> > > > > point. The problem with additional methods is when coefficients
> > > > > should be calculated ? If it would be done in SetProfile all other
> > > > > parameters
> > >
> > > need
> > >
> > > > > to be set before it. Making that strict calling sequence could be
> > > > > very error-prone.
> > > >
> > > > Can you come up with a minimal set of parameters that can fit for
> > > > every possible Trajectory, without having it blowing up?
> > >
> > > The only solution I see in this issue is to provide the
> > > trajectory-specific parameters (that might be all parameters) in the
> > > implementation class. A user
> > > of your trajectory object will then need to know which specific kind of
> > > interpolator is used, in order to parametrize it properly.
> > >
> > > As Herman suggests, there are so many kinds of trajectory generators
> > > that you
> > > will never agree on a common set of parameters. Fortunately, the ins
> > > and outs
> > > are general (joint space or cartesian space pos/vel/acc/...) such that
> > > the most important part of abstraction still holds.
> >
> > So what do you think about extending SetProfile to take pos/vel/acc ?
>
> I'll let the kdl maintainer decide on that, but I would agree with this
> extension. Judging from Herman's replies to this post, he's also going in
> that direction, although with an 'addProfile(pos/vel/acc)' interface for
> waypoints. Probably both are required, one for the start point/segment and
> one for each additional waypoint.

Hmm, I do not think adding vel and acc in the SetProfile of the base class is
the right way to go, since some generators will not be able to take vel and
acc into account which will result in unexpected behaviour from the users POV.

I propose the following:

create a new Profile class that inherits from the current one and adds a new
SetProfile that takes pos/vel arguments, and again the same for a Profile class
that can take pos/vel/acc arguments.

If one uses the SetProfile with only pos arguments on this new set of profiles
the velocity constraints are set to zero and the expected behaviour of the
SetProfile without velocity arguments is preserved.

You're spline profile can than inherit from this new base class.

> > That would be sufficient representation of trajectory point and all other
> > things (mexVel, maxAcc ...) would be set by parameters.
>
> I agree here.

+1

> > > In practice, I see component/node implementations for just *one*
> > > specific trajectory generator, and sharing this input/output data flow
> > > (topic) interface
> > > generically among all generators.
> >
> > Should there be a base class for all generators inherits from TaskContext
> > ?

We could, currently every Generator component inherits directly from a
TaskContext without going through an intermediate base component.

>
> Once you're done on the KDL API and want to provide these algorithms into
> components, yes.
>
> > Or compatibility should be ensured by the creator of the component ?
>
> Both options aren't exclusive. You're not force to inherit from someone
> else's base component, but it should be the easiest thing to do.
>
> I think you're moving in the right direction[1], so don't hesitate to try
> what you mean and post a patch.
>
> Peter
>
> [1] Err, Ruben has the final word here of course :-)

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Mon, 2010-11-29 15:48.

2010/11/24 Ruben Smits <ruben [dot] smits [..] ...>

> On Wednesday 24 November 2010 09:36:44 Peter Soetens wrote:
> > On Monday 22 November 2010 22:56:51 Konrad Banachowicz wrote:
> > > 2010/11/22 Peter Soetens <peter [..] ...>
> > >
> > > > On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > > > > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > > > > > 2010/11/18 Ruben Smits
> > > > > > <ruben [dot] smits [..] ... > ruben [dot] smits [..] ...>>
> > > > > >
> > > > > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > > > > > I know that it can be used independently from
> > > > > > > KDL::Trajectory but documentation suggests that it is intended
> > > > > > > for cartesian trajectory. And there stile is problem with
> > > > > > > SetProfile
> > > >
> > > > which
> > > >
> > > > > > > don't supply enough data for every possible Trajectory.
> > > > > >
> > > > > > As you can see in the API of the inherited classes, they add
> extra
> > > > > > algorithm specific configuration functions, for instance the
> setMax
> > > >
> > > > > > function of the velocityprofile_trap:
> > > >
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl<...
> > > > as
> > > > <
> http://people.mech.kuleuven.be/%7Eorocos/pub/devel/kdl/latest/api/htm
> > > > l/c las>
> > > >
> > > > > > sK
> > > > > > DL_1_1VelocityProfile__Trap.html<
> > > >
> > > > http://people.mech.kuleuven.be/%7Eoroco
> > > >
> > > > > > s/p
> > > >
> > > >
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
> > > > t
> > > >
> > > > > > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but
> i
> > > >
> > > > would
> > > >
> > > > > > like to avoid calling multiple methods for a single trajectory
> > > > > > point. The problem with additional methods is when coefficients
> > > > > > should be calculated ? If it would be done in SetProfile all
> other
> > > > > > parameters
> > > >
> > > > need
> > > >
> > > > > > to be set before it. Making that strict calling sequence could be
> > > > > > very error-prone.
> > > > >
> > > > > Can you come up with a minimal set of parameters that can fit for
> > > > > every possible Trajectory, without having it blowing up?
> > > >
> > > > The only solution I see in this issue is to provide the
> > > > trajectory-specific parameters (that might be all parameters) in the
> > > > implementation class. A user
> > > > of your trajectory object will then need to know which specific kind
> of
> > > > interpolator is used, in order to parametrize it properly.
> > > >
> > > > As Herman suggests, there are so many kinds of trajectory generators
> > > > that you
> > > > will never agree on a common set of parameters. Fortunately, the ins
> > > > and outs
> > > > are general (joint space or cartesian space pos/vel/acc/...) such
> that
> > > > the most important part of abstraction still holds.
> > >
> > > So what do you think about extending SetProfile to take pos/vel/acc ?
> >
> > I'll let the kdl maintainer decide on that, but I would agree with this
> > extension. Judging from Herman's replies to this post, he's also going in
> > that direction, although with an 'addProfile(pos/vel/acc)' interface for
> > waypoints. Probably both are required, one for the start point/segment
> and
> > one for each additional waypoint.
>
> Hmm, I do not think adding vel and acc in the SetProfile of the base class
> is
> the right way to go, since some generators will not be able to take vel and
> acc into account which will result in unexpected behaviour from the users
> POV.
>
> I propose the following:
>
> create a new Profile class that inherits from the current one and adds a
> new
> SetProfile that takes pos/vel arguments, and again the same for a Profile
> class
> that can take pos/vel/acc arguments.
>
> If one uses the SetProfile with only pos arguments on this new set of
> profiles
> the velocity constraints are set to zero and the expected behaviour of the
> SetProfile without velocity arguments is preserved.
>

> You're spline profile can than inherit from this new base class.
>
It made implementation of my trajectory component difficult and
overcomplicated, because I need to accept trajectory point of any type ( PT,
PVT, PVAT).
I made simplest possible implementation which satisfy my needs (patch in
appendix).

>
> > > That would be sufficient representation of trajectory point and all
> other
> > > things (mexVel, maxAcc ...) would be set by parameters.
> >
> > I agree here.
>
> +1
>
> > > > In practice, I see component/node implementations for just *one*
> > > > specific trajectory generator, and sharing this input/output data
> flow
> > > > (topic) interface
> > > > generically among all generators.
> > >
> > > Should there be a base class for all generators inherits from
> TaskContext
> > > ?
>
> We could, currently every Generator component inherits directly from a
> TaskContext without going through an intermediate base component.
>
> >
> > Once you're done on the KDL API and want to provide these algorithms into
> > components, yes.
> >
> > > Or compatibility should be ensured by the creator of the component ?
> >
> > Both options aren't exclusive. You're not force to inherit from someone
> > else's base component, but it should be the easiest thing to do.
> >
> > I think you're moving in the right direction[1], so don't hesitate to try
> > what you mean and post a patch.
> >
> > Peter
> >
> > [1] Err, Ruben has the final word here of course :-)
>

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Wed, 2010-11-24 20:52.

2010/11/24 Ruben Smits <ruben [dot] smits [..] ...>

> On Wednesday 24 November 2010 09:36:44 Peter Soetens wrote:
> > On Monday 22 November 2010 22:56:51 Konrad Banachowicz wrote:
> > > 2010/11/22 Peter Soetens <peter [..] ...>
> > >
> > > > On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > > > > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > > > > > 2010/11/18 Ruben Smits
> > > > > > <ruben [dot] smits [..] ... > ruben [dot] smits [..] ...>>
> > > > > >
> > > > > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > > > > > I know that it can be used independently from
> > > > > > > KDL::Trajectory but documentation suggests that it is intended
> > > > > > > for cartesian trajectory. And there stile is problem with
> > > > > > > SetProfile
> > > >
> > > > which
> > > >
> > > > > > > don't supply enough data for every possible Trajectory.
> > > > > >
> > > > > > As you can see in the API of the inherited classes, they add
> extra
> > > > > > algorithm specific configuration functions, for instance the
> setMax
> > > >
> > > > > > function of the velocityprofile_trap:
> > > >
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl<...
> > > > as
> > > > <
> http://people.mech.kuleuven.be/%7Eorocos/pub/devel/kdl/latest/api/htm
> > > > l/c las>
> > > >
> > > > > > sK
> > > > > > DL_1_1VelocityProfile__Trap.html<
> > > >
> > > > http://people.mech.kuleuven.be/%7Eoroco
> > > >
> > > > > > s/p
> > > >
> > > >
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
> > > > t
> > > >
> > > > > > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but
> i
> > > >
> > > > would
> > > >
> > > > > > like to avoid calling multiple methods for a single trajectory
> > > > > > point. The problem with additional methods is when coefficients
> > > > > > should be calculated ? If it would be done in SetProfile all
> other
> > > > > > parameters
> > > >
> > > > need
> > > >
> > > > > > to be set before it. Making that strict calling sequence could be
> > > > > > very error-prone.
> > > > >
> > > > > Can you come up with a minimal set of parameters that can fit for
> > > > > every possible Trajectory, without having it blowing up?
> > > >
> > > > The only solution I see in this issue is to provide the
> > > > trajectory-specific parameters (that might be all parameters) in the
> > > > implementation class. A user
> > > > of your trajectory object will then need to know which specific kind
> of
> > > > interpolator is used, in order to parametrize it properly.
> > > >
> > > > As Herman suggests, there are so many kinds of trajectory generators
> > > > that you
> > > > will never agree on a common set of parameters. Fortunately, the ins
> > > > and outs
> > > > are general (joint space or cartesian space pos/vel/acc/...) such
> that
> > > > the most important part of abstraction still holds.
> > >
> > > So what do you think about extending SetProfile to take pos/vel/acc ?
> >
> > I'll let the kdl maintainer decide on that, but I would agree with this
> > extension. Judging from Herman's replies to this post, he's also going in
> > that direction, although with an 'addProfile(pos/vel/acc)' interface for
> > waypoints. Probably both are required, one for the start point/segment
> and
> > one for each additional waypoint.
>
> Hmm, I do not think adding vel and acc in the SetProfile of the base class
> is
> the right way to go, since some generators will not be able to take vel and
> acc into account which will result in unexpected behaviour from the users
> POV.
>
> I propose the following:
>
> create a new Profile class that inherits from the current one and adds a
> new
> SetProfile that takes pos/vel arguments, and again the same for a Profile
> class
> that can take pos/vel/acc arguments.
>
> Looks good for me.
Do you have any sugestions about these class names ?

> If one uses the SetProfile with only pos arguments on this new set of
> profiles
> the velocity constraints are set to zero and the expected behaviour of the
> SetProfile without velocity arguments is preserved.
>
>
> You're spline profile can than inherit from this new base class.

There is one another problem my generator cannot work without specifying
duration, so SetProfile could not be used.

> > > That would be sufficient representation of trajectory point and all
> other
> > > things (mexVel, maxAcc ...) would be set by parameters.
> >
> > I agree here.
>
> +1
>
> > > > In practice, I see component/node implementations for just *one*
> > > > specific trajectory generator, and sharing this input/output data
> flow
> > > > (topic) interface
> > > > generically among all generators.
> > >
> > > Should there be a base class for all generators inherits from
> TaskContext
> > > ?
>
> We could, currently every Generator component inherits directly from a
> TaskContext without going through an intermediate base component.
>
> >
> > Once you're done on the KDL API and want to provide these algorithms into
> > components, yes.
> >
> > > Or compatibility should be ensured by the creator of the component ?
> >
> > Both options aren't exclusive. You're not force to inherit from someone
> > else's base component, but it should be the easiest thing to do.
> >
> > I think you're moving in the right direction[1], so don't hesitate to try
> > what you mean and post a patch.
> >
> > Peter
> >
> > [1] Err, Ruben has the final word here of course :-)
>

»

Login or register to post comments

trajectory generation in KDL

Submitted by bruyninc on Mon, 2010-11-22 22:04.

On Mon, 22 Nov 2010, Konrad Banachowicz wrote:

> 2010/11/22 Peter Soetens <peter [..] ...>
> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz
> wrote:
> > > 2010/11/18 Ruben Smits
> > >
> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> > >
> > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz
> wrote:
> > > > I know that it can be used independently from
> > > > KDL::Trajectory but documentation suggests that it is
> intended for
> > > > cartesian trajectory. And there stile is problem with
> SetProfile which
> > > > don't supply enough data for every possible Trajectory.
> > >
> > > As you can see in the API of the inherited classes, they add
> extra
> > > algorithm specific configuration functions, for instance the
> setMax
> > > function of the velocityprofile_trap:
> > >
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/clas
> > > sK
> > >
> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroco
> > > s/p
> > >
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><htt
> > > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
> would
> > > like to avoid calling multiple methods for a single trajectory
> point.
> > > The problem with additional methods is when coefficients should be
> > > calculated ? If it would be done in SetProfile all other
> parameters need
> > > to be set before it. Making that strict calling sequence could be
> very
> > > error-prone.
> >
> > Can you come up with a minimal set of parameters that can fit for
> every
> > possible Trajectory, without having it blowing up?
>
> The only solution I see in this issue is to provide the
> trajectory-specific
> parameters (that might be all parameters) in the implementation class.
> A user
> of your trajectory object will then need to know which specific kind
> of
> interpolator is used, in order to parametrize it properly.
>
> As Herman suggests, there are so many kinds of trajectory generators
> that you
> will never agree on a common set of parameters. Fortunately, the ins
> and outs
> are general (joint space or cartesian space pos/vel/acc/...) such that
> the
> most important part of abstraction still holds.
>
> So what do you think about extending SetProfile to take pos/vel/acc ?

What exactly do you have in mind with this extension?

> That would be sufficient representation of trajectory point and all other
> things (mexVel, maxAcc ...) would be set by parameters.
>
> In practice, I see component/node implementations for just *one*
> specific
> trajectory generator, and sharing this input/output data flow
> (topic) interface
> generically among all generators.
>
> Should there be a base class for all generators inherits from TaskContext ?

No. All generators should first and foremost be just algorithms. The
TaskContext is the "component primitive" in which such algorithms can be
deployed, but they should not know anything about that themselves.

> Or compatibility should be ensured by the creator of the component ?

What compatibility do you have in mind exactly?

> Peter

Herman

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Mon, 2010-11-22 22:32.

2010/11/22 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>

> On Mon, 22 Nov 2010, Konrad Banachowicz wrote:
>
> 2010/11/22 Peter Soetens <peter [..] ...>
>> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
>> > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz
>> wrote:
>> > > 2010/11/18 Ruben Smits
>> > >
>> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>> > >
>> > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz
>> wrote:
>> > > > I know that it can be used independently from
>> > > > KDL::Trajectory but documentation suggests that it is
>> intended for
>> > > > cartesian trajectory. And there stile is problem with
>> SetProfile which
>> > > > don't supply enough data for every possible Trajectory.
>> > >
>> > > As you can see in the API of the inherited classes, they add
>> extra
>> > > algorithm specific configuration functions, for instance the
>> setMax
>> > > function of the velocityprofile_trap:
>> > >
>>
>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cla...
>> > > sK
>> > >
>> DL_1_1VelocityProfile__Trap.html<
>> http://people.mech.kuleuven.be/%7Eoroco
>> > > s/p
>> > >
>>
>> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><htt
>> > > p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
>> would
>> > > like to avoid calling multiple methods for a single trajectory
>> point.
>> > > The problem with additional methods is when coefficients should be
>> > > calculated ? If it would be done in SetProfile all other
>> parameters need
>> > > to be set before it. Making that strict calling sequence could be
>> very
>> > > error-prone.
>> >
>> > Can you come up with a minimal set of parameters that can fit for
>> every
>> > possible Trajectory, without having it blowing up?
>>
>> The only solution I see in this issue is to provide the
>> trajectory-specific
>> parameters (that might be all parameters) in the implementation class.
>> A user
>> of your trajectory object will then need to know which specific kind
>> of
>> interpolator is used, in order to parametrize it properly.
>>
>> As Herman suggests, there are so many kinds of trajectory generators
>> that you
>> will never agree on a common set of parameters. Fortunately, the ins
>> and outs
>> are general (joint space or cartesian space pos/vel/acc/...) such that
>> the
>> most important part of abstraction still holds.
>>
>> So what do you think about extending SetProfile to take pos/vel/acc ?
>>
>
> What exactly do you have in mind with this extension?

SetProfile currently take only position argument i would like to extend it
to pos/vel/acc.

>
>
> That would be sufficient representation of trajectory point and all other
>> things (mexVel, maxAcc ...) would be set by parameters.
>>
>> In practice, I see component/node implementations for just *one*
>> specific
>> trajectory generator, and sharing this input/output data flow
>> (topic) interface
>> generically among all generators.
>>
>> Should there be a base class for all generators inherits from TaskContext
>> ?
>>
>
> No. All generators should first and foremost be just algorithms. The
> TaskContext is the "component primitive" in which such algorithms can be
> deployed, but they should not know anything about that themselves.

Writing a "generator" I thought about component which generate trajectory.

>
>
> Or compatibility should be ensured by the creator of the component ?
>>
>
> What compatibility do you have in mind exactly?
>
Compatible DataPorts for example.
So generators components would be interchangeable.

>
> Peter
>>
>
> Herman
>

»

Login or register to post comments

trajectory generation in KDL

Submitted by bruyninc on Tue, 2010-11-23 06:40.

On Mon, 22 Nov 2010, Konrad Banachowicz wrote:

> 2010/11/22 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...Herman [dot] Bruyninckx [..] ...>>
> On Mon, 22 Nov 2010, Konrad Banachowicz wrote:
>
> 2010/11/22 Peter Soetens <peter [..] ...peter [..] ...>>
> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz
> wrote:
> > > 2010/11/18 Ruben Smits
> > >
> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...><mailto:ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>>
> > >
> > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz
> wrote:
> > > > I know that it can be used independently from
> > > > KDL::Trajectory but documentation suggests that it is
> intended for
> > > > cartesian trajectory. And there stile is problem with
> SetProfile which
> > > > don't supply enough data for every possible Trajectory.
> > >
> > > As you can see in the API of the inherited classes, they add
> extra
> > > algorithm specific configuration functions, for instance the
> setMax
> > > function of the velocityprofile_trap:
> > >
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cla...
> > > sK
> > >
> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroco
> > > s/p
> > >
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><htt
>>> p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev<http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev>> Yes but i
> would
>>> like to avoid calling multiple methods for a single trajectory
> point.
>>> The problem with additional methods is when coefficients should be
>>> calculated ? If it would be done in SetProfile all other
> parameters need
>>> to be set before it. Making that strict calling sequence could be
> very
>>> error-prone.
>>
>> Can you come up with a minimal set of parameters that can fit for
> every
>> possible Trajectory, without having it blowing up?
>
> The only solution I see in this issue is to provide the
> trajectory-specific
> parameters (that might be all parameters) in the implementation class.
> A user
> of your trajectory object will then need to know which specific kind
> of
> interpolator is used, in order to parametrize it properly.
>
> As Herman suggests, there are so many kinds of trajectory generators
> that you
> will never agree on a common set of parameters. Fortunately, the ins
> and outs
> are general (joint space or cartesian space pos/vel/acc/...) such that
> the
> most important part of abstraction still holds.
>
> So what do you think about extending SetProfile to take pos/vel/acc ?
>
> What exactly do you have in mind with this extension?
> SetProfile currently take only position argument i would like to extend it to pos/vel/acc.
>
In principle that makes sense. Just out of curiosity, what is/are the use
cases that you want this feature for?

> That would be sufficient representation of trajectory point and all other
> things (mexVel, maxAcc ...) would be set by parameters.
>
> In practice, I see component/node implementations for just *one*
> specific
> trajectory generator, and sharing this input/output data flow
> (topic) interface
> generically among all generators.
>
> Should there be a base class for all generators inherits from TaskContext ?
>
> No. All generators should first and foremost be just algorithms. The
> TaskContext is the "component primitive" in which such algorithms can be
> deployed, but they should not know anything about that themselves.
> Writing a "generator" I thought about component which generate trajectory.
>
>
> Or compatibility should be ensured by the creator of the component ?
>
> What compatibility do you have in mind exactly?
> Compatible DataPorts for example.
> So generators components would be interchangeable.

That's indeed a goal to aim for. But at a different level than the creation
of new interpolator _algorithms_. This interoperability is something that
should be done, by definition, on an inter-project basis. I am very
interested in helping to realise this, but I have experienced that it is
very difficult to agree on a common format for representing trajectories.
What seems to be possible is to generate a set of "via points" (= frames to
move through, up to a given uncertainty, e.g., represented by a Gaussian
distribution).

Herman

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Tue, 2010-11-23 08:28.

>
>> So what do you think about extending SetProfile to take pos/vel/acc ?
>>
>> What exactly do you have in mind with this extension?
>> SetProfile currently take only position argument i would like to extend it
>> to pos/vel/acc.
>>
>> In principle that makes sense. Just out of curiosity, what is/are the use
> cases that you want this feature for?

For spline trajectory generator.
I think this point specification would fit most trajectory generation
algorithms.

That would be sufficient representation of trajectory point and all other
> things (mexVel, maxAcc ...) would be set by parameters.
>
> In practice, I see component/node implementations for just *one*
> specific
> trajectory generator, and sharing this input/output data flow
> (topic) interface
> generically among all generators.
>
> Should there be a base class for all generators inherits from TaskContext ?
>
> No. All generators should first and foremost be just algorithms. The
> TaskContext is the "component primitive" in which such algorithms can be
> deployed, but they should not know anything about that themselves.
> Writing a "generator" I thought about component which generate trajectory.
>
>
> Or compatibility should be ensured by the creator of the component ?
>
> What compatibility do you have in mind exactly?
> Compatible DataPorts for example.
> So generators components would be interchangeable.
>

That's indeed a goal to aim for. But at a different level than the creation
> of new interpolator _algorithms_. This interoperability is something that
> should be done, by definition, on an inter-project basis. I am very
> interested in helping to realise this, but I have experienced that it is
> very difficult to agree on a common format for representing trajectories.
> What seems to be possible is to generate a set of "via points" (= frames to
> move through, up to a given uncertainty, e.g., represented by a Gaussian
> distribution)

My main goal is integration with ROS so i am using
trajectory_msgs/JointTrajectoryPoint for input of my components.
And my own oro_servo_msgs for communicating with servo.

»

Login or register to post comments

trajectory generation in KDL

Submitted by bruyninc on Tue, 2010-11-23 20:20.

On Tue, 23 Nov 2010, Konrad Banachowicz wrote:

>
>
> So what do you think about extending SetProfile to take
> pos/vel/acc ?
>
> What exactly do you have in mind with this extension?
> SetProfile currently take only position argument i would
> like to extend it to pos/vel/acc.
>
> In principle that makes sense. Just out of curiosity, what is/are the use
> cases that you want this feature for?
>
> For spline trajectory generator.

Hmmm... If the positions of the (control) points of a spline are given,
there is no more freedom for the velocity and acceleration. So, I do not
see what the extension of SetProfile would really mean in this case.

> I think this point specification would fit most trajectory generation
> algorithms.

I interpret this as follows: if all you specify is a set of "via points"
you want to move through (with a given tolerance), than this is sufficient
information to use any kind of trajectory representation and corresponding
interpolation generation to solve the motion interpolation problem; each
chosen algorithm will lead to different position, velocity and acceleration
profiles, but that's fine.

> That would be sufficient representation of trajectory point and all
> other
> things (mexVel, maxAcc ...) would be set by parameters.
>
> In practice, I see component/node implementations for just *one*
> specific
> trajectory generator, and sharing this input/output data flow
> (topic) interface
> generically among all generators.
>
> Should there be a base class for all generators inherits from
> TaskContext ?
>
> No. All generators should first and foremost be just algorithms. The
> TaskContext is the "component primitive" in which such algorithms
> can be
> deployed, but they should not know anything about that themselves.
> Writing a "generator" I thought about component which generate
> trajectory.
>
>
> Or compatibility should be ensured by the creator of the component ?
>
> What compatibility do you have in mind exactly?
> Compatible DataPorts for example.
> So generators components would be interchangeable.
>
>
> That's indeed a goal to aim for. But at a different level than the
> creation
> of new interpolator _algorithms_. This interoperability is something
> that
> should be done, by definition, on an inter-project basis. I am very
> interested in helping to realise this, but I have experienced that
> it is
> very difficult to agree on a common format for representing
> trajectories.
> What seems to be possible is to generate a set of "via points" (=
> frames to
> move through, up to a given uncertainty, e.g., represented by a
> Gaussian
> distribution)
>
> My main goal is integration with ROS so i am using
> trajectory_msgs/JointTrajectoryPoint for input of my components.
> And my own oro_servo_msgs for communicating with servo.

I do not understand the "so" in the paragraph above...

Herman

»

Login or register to post comments

Ruben Smits's picture

trajectory generation in KDL

Submitted by Ruben Smits on Mon, 2010-11-22 10:16.

On Monday 22 November 2010 11:05:52 Peter Soetens wrote:
> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
> > On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > > 2010/11/18 Ruben Smits
> > > <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> > >
> > > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > > I know that it can be used independently from
> > > > KDL::Trajectory but documentation suggests that it is intended for
> > > > cartesian trajectory. And there stile is problem with SetProfile
> > > > which don't supply enough data for every possible Trajectory.
> > >
> > > As you can see in the API of the inherited classes, they add extra
> > > algorithm specific configuration functions, for instance the setMax
> > > function of the velocityprofile_trap:
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
> > > as sK
> > > DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroc
> > > o s/p
> > > ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
> > > t p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
> > > would like to avoid calling multiple methods for a single trajectory
> > > point. The problem with additional methods is when coefficients should
> > > be calculated ? If it would be done in SetProfile all other parameters
> > > need to be set before it. Making that strict calling sequence could be
> > > very error-prone.
> >
> > Can you come up with a minimal set of parameters that can fit for every
> > possible Trajectory, without having it blowing up?
>
> The only solution I see in this issue is to provide the trajectory-specific
> parameters (that might be all parameters) in the implementation class. A
> user of your trajectory object will then need to know which specific kind
> of interpolator is used, in order to parametrize it properly.
>
> As Herman suggests, there are so many kinds of trajectory generators that
> you will never agree on a common set of parameters. Fortunately, the ins
> and outs are general (joint space or cartesian space pos/vel/acc/...) such
> that the most important part of abstraction still holds.
>
> In practice, I see component/node implementations for just *one* specific
> trajectory generator, and sharing this input/output data flow (topic)
> interface generically among all generators.

+1, this is how we (in Orocos/OCL) did it before and it proved to be working
very well.

Ruben

»

Login or register to post comments

trajectory generation in KDL

Submitted by snrkiwi on Mon, 2010-11-22 13:44.

On Nov 22, 2010, at 05:12 , Ruben Smits wrote:

> On Monday 22 November 2010 11:05:52 Peter Soetens wrote:
>> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
>>> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
>>>> 2010/11/18 Ruben Smits
>>>> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>>>>
>>>> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
>>>>> I know that it can be used independently from
>>>>> KDL::Trajectory but documentation suggests that it is intended for
>>>>> cartesian trajectory. And there stile is problem with SetProfile
>>>>> which don't supply enough data for every possible Trajectory.
>>>>
>>>> As you can see in the API of the inherited classes, they add extra
>>>> algorithm specific configuration functions, for instance the setMax
>>>> function of the velocityprofile_trap:
>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>> as sK
>>>> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroc
>>>> o s/p
>>>> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
>>>> t p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
>>>> would like to avoid calling multiple methods for a single trajectory
>>>> point. The problem with additional methods is when coefficients should
>>>> be calculated ? If it would be done in SetProfile all other parameters
>>>> need to be set before it. Making that strict calling sequence could be
>>>> very error-prone.
>>>
>>> Can you come up with a minimal set of parameters that can fit for every
>>> possible Trajectory, without having it blowing up?
>>
>> The only solution I see in this issue is to provide the trajectory-specific
>> parameters (that might be all parameters) in the implementation class. A
>> user of your trajectory object will then need to know which specific kind
>> of interpolator is used, in order to parametrize it properly.
>>
>> As Herman suggests, there are so many kinds of trajectory generators that
>> you will never agree on a common set of parameters. Fortunately, the ins
>> and outs are general (joint space or cartesian space pos/vel/acc/...) such
>> that the most important part of abstraction still holds.
>>
>> In practice, I see component/node implementations for just *one* specific
>> trajectory generator, and sharing this input/output data flow (topic)
>> interface generically among all generators.
>
> +1, this is how we (in Orocos/OCL) did it before and it proved to be working
> very well.

+1, and it's very similar to the way that most GUI toolkits do it for heterogeneous sets of widgets (look at Qt) - same problem.
S

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Tue, 2010-11-23 21:16.

Sorry my mistake.

On Tue, 23 Nov 2010, Konrad Banachowicz wrote:

2010/11/23 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Tue, 23 Nov 2010, Konrad Banachowicz wrote:
>
>
>
> So what do you think about extending
> SetProfile to take
> pos/vel/acc ?
>
> What exactly do you have in mind with this
> extension?
> SetProfile currently take only position
> argument i would
> like to extend it to pos/vel/acc.
>
> In principle that makes sense. Just out of curiosity,
> what is/are the use
> cases that you want this feature for?
>
> For spline trajectory generator.
>
>
> Hmmm... If the positions of the (control) points of a spline are given,
> there is no more freedom for the velocity and acceleration. So, I do not
> see what the extension of SetProfile would really mean in this case.
>
> I think this point specification would fit most trajectory
> generation
> algorithms.
>
>
> I interpret this as follows: if all you specify is a set of "via points"
> you want to move through (with a given tolerance), than this is sufficient
> information to use any kind of trajectory representation and corresponding
> interpolation generation to solve the motion interpolation problem; each
> chosen algorithm will lead to different position, velocity and
> acceleration
> profiles, but that's fine.
>
> No I can't agree with you. For cubic spline you need control value
> (position)
> and its first derivative (velocity).
> For quintic spline second derivative (acceleration) is also necessary for
> every
> control point.
>

OK, I understand. The confusion came from your not-so-clear distinction
between "point" (as part of a trajectory) and "control point" (as a
specification feature relevant only for splines).

Herman

PS It would have been okay to keep this discussion on the mailinglist.

»

Login or register to post comments

trajectory generation in KDL

Submitted by bruyninc on Mon, 2010-11-22 14:32.

On Mon, 22 Nov 2010, S Roderick wrote:

> On Nov 22, 2010, at 05:12 , Ruben Smits wrote:
>
>> On Monday 22 November 2010 11:05:52 Peter Soetens wrote:
>>> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
>>>> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
>>>>> 2010/11/18 Ruben Smits
>>>>> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>>>>>
>>>>> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
>>>>>> I know that it can be used independently from
>>>>>> KDL::Trajectory but documentation suggests that it is intended for
>>>>>> cartesian trajectory. And there stile is problem with SetProfile
>>>>>> which don't supply enough data for every possible Trajectory.
>>>>>
>>>>> As you can see in the API of the inherited classes, they add extra
>>>>> algorithm specific configuration functions, for instance the setMax
>>>>> function of the velocityprofile_trap:
>>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>>> as sK
>>>>> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroc
>>>>> o s/p
>>>>> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
>>>>> t p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
>>>>> would like to avoid calling multiple methods for a single trajectory
>>>>> point. The problem with additional methods is when coefficients should
>>>>> be calculated ? If it would be done in SetProfile all other parameters
>>>>> need to be set before it. Making that strict calling sequence could be
>>>>> very error-prone.
>>>>
>>>> Can you come up with a minimal set of parameters that can fit for every
>>>> possible Trajectory, without having it blowing up?
>>>
>>> The only solution I see in this issue is to provide the trajectory-specific
>>> parameters (that might be all parameters) in the implementation class. A
>>> user of your trajectory object will then need to know which specific kind
>>> of interpolator is used, in order to parametrize it properly.
>>>
>>> As Herman suggests, there are so many kinds of trajectory generators that
>>> you will never agree on a common set of parameters. Fortunately, the ins
>>> and outs are general (joint space or cartesian space pos/vel/acc/...) such
>>> that the most important part of abstraction still holds.
>>>
>>> In practice, I see component/node implementations for just *one* specific
>>> trajectory generator, and sharing this input/output data flow (topic)
>>> interface generically among all generators.
>>
>> +1, this is how we (in Orocos/OCL) did it before and it proved to be working
>> very well.
>
> +1, and it's very similar to the way that most GUI toolkits do it for heterogeneous sets of widgets (look at Qt) - same problem.
> S

I'm always interested in getting to know better such "best practice" from
other domains :-) So, do you have some idea or link to where I can find
this similar Qt solution?

Thanks! Don't bother to answer if you do not have this link readily
available, I don't wont't to distract you from your work :-)

Herman

»

Login or register to post comments

trajectory generation in KDL

Submitted by snrkiwi on Mon, 2010-11-22 15:28.

On Nov 22, 2010, at 09:29 , Herman Bruyninckx wrote:

> On Mon, 22 Nov 2010, S Roderick wrote:
>
>> On Nov 22, 2010, at 05:12 , Ruben Smits wrote:
>>
>>> On Monday 22 November 2010 11:05:52 Peter Soetens wrote:
>>>> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
>>>>> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
>>>>>> 2010/11/18 Ruben Smits
>>>>>> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>>>>>>
>>>>>> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
>>>>>>> I know that it can be used independently from
>>>>>>> KDL::Trajectory but documentation suggests that it is intended for
>>>>>>> cartesian trajectory. And there stile is problem with SetProfile
>>>>>>> which don't supply enough data for every possible Trajectory.
>>>>>>
>>>>>> As you can see in the API of the inherited classes, they add extra
>>>>>> algorithm specific configuration functions, for instance the setMax
>>>>>> function of the velocityprofile_trap:
>>>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>>>> as sK
>>>>>> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroc
>>>>>> o s/p
>>>>>> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
>>>>>> t p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
>>>>>> would like to avoid calling multiple methods for a single trajectory
>>>>>> point. The problem with additional methods is when coefficients should
>>>>>> be calculated ? If it would be done in SetProfile all other parameters
>>>>>> need to be set before it. Making that strict calling sequence could be
>>>>>> very error-prone.
>>>>>
>>>>> Can you come up with a minimal set of parameters that can fit for every
>>>>> possible Trajectory, without having it blowing up?
>>>>
>>>> The only solution I see in this issue is to provide the trajectory-specific
>>>> parameters (that might be all parameters) in the implementation class. A
>>>> user of your trajectory object will then need to know which specific kind
>>>> of interpolator is used, in order to parametrize it properly.
>>>>
>>>> As Herman suggests, there are so many kinds of trajectory generators that
>>>> you will never agree on a common set of parameters. Fortunately, the ins
>>>> and outs are general (joint space or cartesian space pos/vel/acc/...) such
>>>> that the most important part of abstraction still holds.
>>>>
>>>> In practice, I see component/node implementations for just *one* specific
>>>> trajectory generator, and sharing this input/output data flow (topic)
>>>> interface generically among all generators.
>>>
>>> +1, this is how we (in Orocos/OCL) did it before and it proved to be working
>>> very well.
>>
>> +1, and it's very similar to the way that most GUI toolkits do it for heterogeneous sets of widgets (look at Qt) - same problem.
>> S
>
> I'm always interested in getting to know better such "best practice" from
> other domains :-) So, do you have some idea or link to where I can find
> this similar Qt solution?
>
> Thanks! Don't bother to answer if you do not have this link readily
> available, I don't wont't to distract you from your work :-)

The base widget class (to choose one) is

http://doc.trolltech.com/4.6/qwidget.html

There are a suite of properties here you can set/get. Look at any derived class from there, and it adds additional properties as necessary. I think that this is the outline of what everyone is saying - put the abstract items in the base class and add additonal properties in derived classes as necessary.

There are several other instances in Qt also -

http://doc.trolltech.com/4.6/qabstractslider.html
http://doc.trolltech.com/4.6/qabstractspinbox.html

or a slightly different approach

http://doc.trolltech.com/4.6/qabstractitemmodel.html

Within our own application components we also do something similar to what Ruben suggested. Make a base component with your common data flow and operations, and derive from there with additional parameters as necessary. We use this frequently for hardware devices, where the derived classes might be a simulator or hardware, or some kind of playback capability. The basic data and operations are the same, the implementation details differ.

HTH
S

»

Login or register to post comments

trajectory generation in KDL

Submitted by bruyninc on Mon, 2010-11-22 18:28.

On Mon, 22 Nov 2010, Stephen Roderick wrote:

> On Nov 22, 2010, at 09:29 , Herman Bruyninckx wrote:
>
>> On Mon, 22 Nov 2010, S Roderick wrote:
>>
>>> On Nov 22, 2010, at 05:12 , Ruben Smits wrote:
>>>
>>>> On Monday 22 November 2010 11:05:52 Peter Soetens wrote:
>>>>> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
>>>>>> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
>>>>>>> 2010/11/18 Ruben Smits
>>>>>>> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>>>>>>>
>>>>>>> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
>>>>>>>> I know that it can be used independently from
>>>>>>>> KDL::Trajectory but documentation suggests that it is intended for
>>>>>>>> cartesian trajectory. And there stile is problem with SetProfile
>>>>>>>> which don't supply enough data for every possible Trajectory.
>>>>>>>
>>>>>>> As you can see in the API of the inherited classes, they add extra
>>>>>>> algorithm specific configuration functions, for instance the setMax
>>>>>>> function of the velocityprofile_trap:
>>>>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>>>>> as sK
>>>>>>> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroc
>>>>>>> o s/p
>>>>>>> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
>>>>>>> t p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
>>>>>>> would like to avoid calling multiple methods for a single trajectory
>>>>>>> point. The problem with additional methods is when coefficients should
>>>>>>> be calculated ? If it would be done in SetProfile all other parameters
>>>>>>> need to be set before it. Making that strict calling sequence could be
>>>>>>> very error-prone.
>>>>>>
>>>>>> Can you come up with a minimal set of parameters that can fit for every
>>>>>> possible Trajectory, without having it blowing up?
>>>>>
>>>>> The only solution I see in this issue is to provide the trajectory-specific
>>>>> parameters (that might be all parameters) in the implementation class. A
>>>>> user of your trajectory object will then need to know which specific kind
>>>>> of interpolator is used, in order to parametrize it properly.
>>>>>
>>>>> As Herman suggests, there are so many kinds of trajectory generators that
>>>>> you will never agree on a common set of parameters. Fortunately, the ins
>>>>> and outs are general (joint space or cartesian space pos/vel/acc/...) such
>>>>> that the most important part of abstraction still holds.
>>>>>
>>>>> In practice, I see component/node implementations for just *one* specific
>>>>> trajectory generator, and sharing this input/output data flow (topic)
>>>>> interface generically among all generators.
>>>>
>>>> +1, this is how we (in Orocos/OCL) did it before and it proved to be working
>>>> very well.
>>>
>>> +1, and it's very similar to the way that most GUI toolkits do it for heterogeneous sets of widgets (look at Qt) - same problem.
>>> S
>>
>> I'm always interested in getting to know better such "best practice" from
>> other domains :-) So, do you have some idea or link to where I can find
>> this similar Qt solution?
>>
>> Thanks! Don't bother to answer if you do not have this link readily
>> available, I don't wont't to distract you from your work :-)
>
>
> The base widget class (to choose one) is
>
> http://doc.trolltech.com/4.6/qwidget.html
>
> There are a suite of properties here you can set/get. Look at any derived class from there, and it adds additional properties as necessary. I think that this is the outline of what everyone is saying - put the abstract items in the base class and add additonal properties in derived classes as necessary.
>
Thanks for the information!

> There are several other instances in Qt also -
>
> http://doc.trolltech.com/4.6/qabstractslider.html
> http://doc.trolltech.com/4.6/qabstractspinbox.html
>
> or a slightly different approach
>
> http://doc.trolltech.com/4.6/qabstractitemmodel.html
>
> Within our own application components we also do something similar to
> what Ruben suggested. Make a base component with your common data flow
> and operations, and derive from there with additional parameters as
> necessary. We use this frequently for hardware devices, where the derived
> classes might be a simulator or hardware, or some kind of playback
> capability. The basic data and operations are the same, the
> implementation details differ.
>
Coincidently, I received an email from someone reacting to my "FOSS vision"
post on euron-dist and robotics-worldwide, saying that the most important
FOSS project he misses is one that helps people to interface new hardware
faster and better and more methodologically. That's exactly what your post
descibes, isn't it? And it's also the core of the "best practice" robot
hardware interface library that the BRICS project is preparing... We still
need to do quite some work before it is really best practice, but I think
we will be able "to deliver"...

> HTH
> S

Herman

»

Login or register to post comments

trajectory generation in KDL

Submitted by snrkiwi on Mon, 2010-11-22 18:48.

On Nov 22, 2010, at 13:24 , Herman Bruyninckx wrote:

> On Mon, 22 Nov 2010, Stephen Roderick wrote:
>
>> On Nov 22, 2010, at 09:29 , Herman Bruyninckx wrote:
>>
>>> On Mon, 22 Nov 2010, S Roderick wrote:
>>>
>>>> On Nov 22, 2010, at 05:12 , Ruben Smits wrote:
>>>>
>>>>> On Monday 22 November 2010 11:05:52 Peter Soetens wrote:
>>>>>> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
>>>>>>> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
>>>>>>>> 2010/11/18 Ruben Smits
>>>>>>>> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>>>>>>>>
>>>>>>>> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
>>>>>>>>> I know that it can be used independently from
>>>>>>>>> KDL::Trajectory but documentation suggests that it is intended for
>>>>>>>>> cartesian trajectory. And there stile is problem with SetProfile
>>>>>>>>> which don't supply enough data for every possible Trajectory.
>>>>>>>>
>>>>>>>> As you can see in the API of the inherited classes, they add extra
>>>>>>>> algorithm specific configuration functions, for instance the setMax
>>>>>>>> function of the velocityprofile_trap:
>>>>>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>>>>>> as sK
>>>>>>>> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroc
>>>>>>>> o s/p
>>>>>>>> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
>>>>>>>> t p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
>>>>>>>> would like to avoid calling multiple methods for a single trajectory
>>>>>>>> point. The problem with additional methods is when coefficients should
>>>>>>>> be calculated ? If it would be done in SetProfile all other parameters
>>>>>>>> need to be set before it. Making that strict calling sequence could be
>>>>>>>> very error-prone.
>>>>>>>
>>>>>>> Can you come up with a minimal set of parameters that can fit for every
>>>>>>> possible Trajectory, without having it blowing up?
>>>>>>
>>>>>> The only solution I see in this issue is to provide the trajectory-specific
>>>>>> parameters (that might be all parameters) in the implementation class. A
>>>>>> user of your trajectory object will then need to know which specific kind
>>>>>> of interpolator is used, in order to parametrize it properly.
>>>>>>
>>>>>> As Herman suggests, there are so many kinds of trajectory generators that
>>>>>> you will never agree on a common set of parameters. Fortunately, the ins
>>>>>> and outs are general (joint space or cartesian space pos/vel/acc/...) such
>>>>>> that the most important part of abstraction still holds.
>>>>>>
>>>>>> In practice, I see component/node implementations for just *one* specific
>>>>>> trajectory generator, and sharing this input/output data flow (topic)
>>>>>> interface generically among all generators.
>>>>>
>>>>> +1, this is how we (in Orocos/OCL) did it before and it proved to be working
>>>>> very well.
>>>>
>>>> +1, and it's very similar to the way that most GUI toolkits do it for heterogeneous sets of widgets (look at Qt) - same problem.
>>>> S
>>>
>>> I'm always interested in getting to know better such "best practice" from
>>> other domains :-) So, do you have some idea or link to where I can find
>>> this similar Qt solution?
>>>
>>> Thanks! Don't bother to answer if you do not have this link readily
>>> available, I don't wont't to distract you from your work :-)
>>
>>
>> The base widget class (to choose one) is
>>
>> http://doc.trolltech.com/4.6/qwidget.html
>>
>> There are a suite of properties here you can set/get. Look at any derived class from there, and it adds additional properties as necessary. I think that this is the outline of what everyone is saying - put the abstract items in the base class and add additonal properties in derived classes as necessary.
>>
> Thanks for the information!
>
>> There are several other instances in Qt also -
>>
>> http://doc.trolltech.com/4.6/qabstractslider.html
>> http://doc.trolltech.com/4.6/qabstractspinbox.html
>>
>> or a slightly different approach
>>
>> http://doc.trolltech.com/4.6/qabstractitemmodel.html
>>
>> Within our own application components we also do something similar to
>> what Ruben suggested. Make a base component with your common data flow
>> and operations, and derive from there with additional parameters as
>> necessary. We use this frequently for hardware devices, where the derived
>> classes might be a simulator or hardware, or some kind of playback
>> capability. The basic data and operations are the same, the
>> implementation details differ.
>>
> Coincidently, I received an email from someone reacting to my "FOSS vision"
> post on euron-dist and robotics-worldwide, saying that the most important
> FOSS project he misses is one that helps people to interface new hardware
> faster and better and more methodologically. That's exactly what your post
> descibes, isn't it? And it's also the core of the "best practice" robot
> hardware interface library that the BRICS project is preparing... We still
> need to do quite some work before it is really best practice, but I think
> we will be able "to deliver"...

Interesting coincidence ...

We have found it incredibly useful to have drop-in component replacements for hardware vs simulated vs playback devices. It does, however, provide extra configuration options to your deployment, which brings us back around to the deployment tool thread on the ML. So it's not all completely rosy ... yet ...

This approach also rings well with management, when you explain that you can change from a simulated system, to a hardware system, by changing one bit of XML and have only one component be different. That 99.9% similarity between those system configurations makes them much more comfortable with testing systems in simulation, etc.
S

»

Login or register to post comments

trajectory generation in KDL

Submitted by bruyninc on Mon, 2010-11-22 18:56.

On Mon, 22 Nov 2010, Stephen Roderick wrote:

> On Nov 22, 2010, at 13:24 , Herman Bruyninckx wrote:
>
>> On Mon, 22 Nov 2010, Stephen Roderick wrote:
>>
>>> On Nov 22, 2010, at 09:29 , Herman Bruyninckx wrote:
>>>
>>>> On Mon, 22 Nov 2010, S Roderick wrote:
>>>>
>>>>> On Nov 22, 2010, at 05:12 , Ruben Smits wrote:
>>>>>
>>>>>> On Monday 22 November 2010 11:05:52 Peter Soetens wrote:
>>>>>>> On Thursday 18 November 2010 20:43:32 Ruben Smits wrote:
>>>>>>>> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
>>>>>>>>> 2010/11/18 Ruben Smits
>>>>>>>>> <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
>>>>>>>>>
>>>>>>>>> On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
>>>>>>>>>> I know that it can be used independently from
>>>>>>>>>> KDL::Trajectory but documentation suggests that it is intended for
>>>>>>>>>> cartesian trajectory. And there stile is problem with SetProfile
>>>>>>>>>> which don't supply enough data for every possible Trajectory.
>>>>>>>>>
>>>>>>>>> As you can see in the API of the inherited classes, they add extra
>>>>>>>>> algorithm specific configuration functions, for instance the setMax
>>>>>>>>> function of the velocityprofile_trap:
>>>>>>>>> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cl
>>>>>>>>> as sK
>>>>>>>>> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eoroc
>>>>>>>>> o s/p
>>>>>>>>> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><ht
>>>>>>>>> t p:/ /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i
>>>>>>>>> would like to avoid calling multiple methods for a single trajectory
>>>>>>>>> point. The problem with additional methods is when coefficients should
>>>>>>>>> be calculated ? If it would be done in SetProfile all other parameters
>>>>>>>>> need to be set before it. Making that strict calling sequence could be
>>>>>>>>> very error-prone.
>>>>>>>>
>>>>>>>> Can you come up with a minimal set of parameters that can fit for every
>>>>>>>> possible Trajectory, without having it blowing up?
>>>>>>>
>>>>>>> The only solution I see in this issue is to provide the trajectory-specific
>>>>>>> parameters (that might be all parameters) in the implementation class. A
>>>>>>> user of your trajectory object will then need to know which specific kind
>>>>>>> of interpolator is used, in order to parametrize it properly.
>>>>>>>
>>>>>>> As Herman suggests, there are so many kinds of trajectory generators that
>>>>>>> you will never agree on a common set of parameters. Fortunately, the ins
>>>>>>> and outs are general (joint space or cartesian space pos/vel/acc/...) such
>>>>>>> that the most important part of abstraction still holds.
>>>>>>>
>>>>>>> In practice, I see component/node implementations for just *one* specific
>>>>>>> trajectory generator, and sharing this input/output data flow (topic)
>>>>>>> interface generically among all generators.
>>>>>>
>>>>>> +1, this is how we (in Orocos/OCL) did it before and it proved to be working
>>>>>> very well.
>>>>>
>>>>> +1, and it's very similar to the way that most GUI toolkits do it for heterogeneous sets of widgets (look at Qt) - same problem.
>>>>> S
>>>>
>>>> I'm always interested in getting to know better such "best practice" from
>>>> other domains :-) So, do you have some idea or link to where I can find
>>>> this similar Qt solution?
>>>>
>>>> Thanks! Don't bother to answer if you do not have this link readily
>>>> available, I don't wont't to distract you from your work :-)
>>>
>>>
>>> The base widget class (to choose one) is
>>>
>>> http://doc.trolltech.com/4.6/qwidget.html
>>>
>>> There are a suite of properties here you can set/get. Look at any derived class from there, and it adds additional properties as necessary. I think that this is the outline of what everyone is saying - put the abstract items in the base class and add additonal properties in derived classes as necessary.
>>>
>> Thanks for the information!
>>
>>> There are several other instances in Qt also -
>>>
>>> http://doc.trolltech.com/4.6/qabstractslider.html
>>> http://doc.trolltech.com/4.6/qabstractspinbox.html
>>>
>>> or a slightly different approach
>>>
>>> http://doc.trolltech.com/4.6/qabstractitemmodel.html
>>>
>>> Within our own application components we also do something similar to
>>> what Ruben suggested. Make a base component with your common data flow
>>> and operations, and derive from there with additional parameters as
>>> necessary. We use this frequently for hardware devices, where the derived
>>> classes might be a simulator or hardware, or some kind of playback
>>> capability. The basic data and operations are the same, the
>>> implementation details differ.
>>>
>> Coincidently, I received an email from someone reacting to my "FOSS vision"
>> post on euron-dist and robotics-worldwide, saying that the most important
>> FOSS project he misses is one that helps people to interface new hardware
>> faster and better and more methodologically. That's exactly what your post
>> descibes, isn't it? And it's also the core of the "best practice" robot
>> hardware interface library that the BRICS project is preparing... We still
>> need to do quite some work before it is really best practice, but I think
>> we will be able "to deliver"...
>
> Interesting coincidence ...
>
> We have found it incredibly useful to have drop-in component replacements for hardware vs simulated vs playback devices. It does, however, provide extra configuration options to your deployment, which brings us back around to the deployment tool thread on the ML. So it's not all completely rosy ... yet ...
>
> This approach also rings well with management, when you explain that you can change from a simulated system, to a hardware system, by changing one bit of XML and have only one component be different. That 99.9% similarity between those system configurations makes them much more comfortable with testing systems in simulation, etc.
> S

Indeed. These are all steps that we _have_ to make in order to gain a
decent, professional reputation...

Herman

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Thu, 2010-11-18 20:16.

2010/11/18 Ruben Smits <ruben [dot] smits [..] ...>

> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > 2010/11/18 Ruben Smits
> > <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> >
> > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > I know that it can be used independently from
> > > KDL::Trajectory but documentation suggests that it is intended for
> > > cartesian trajectory. And there stile is problem with SetProfile which
> > > don't supply enough data for every possible Trajectory.
> >
> > As you can see in the API of the inherited classes, they add extra
> > algorithm specific configuration functions, for instance the setMax
> > function of the velocityprofile_trap:
> >
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/cla...
> > DL_1_1VelocityProfile__Trap.html<
> http://people.mech.kuleuven.be/%7Eorocos/p
> >
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><http: /> > /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i would
> like
> > to avoid calling multiple methods for a single trajectory point. The
> > problem with additional methods is when coefficients should be calculated
> > ? If it would be done in SetProfile all other parameters need to be set
> > before it. Making that strict calling sequence could be very error-prone.
>
> Can you come up with a minimal set of parameters that can fit for every
> possible Trajectory, without having it blowing up?
>
For quintic spline i need : start_pos, start_vel, start_acc, end_pos,
end_vel, end_acc, duration

»

Login or register to post comments

trajectory generation in KDL

Submitted by bruyninc on Sun, 2010-11-21 14:48.

On Thu, 18 Nov 2010, Konrad Banachowicz wrote:

> 2010/11/18 Ruben Smits <ruben [dot] smits [..] ...>
> On Thursday 18 November 2010 20:24:33 Konrad Banachowicz wrote:
> > 2010/11/18 Ruben Smits
> > <ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
> >
> > On Thursday 18 November 2010 16:16:19 Konrad Banachowicz wrote:
> > > I know that it can be used independently from
> > > KDL::Trajectory but documentation suggests that it is intended for
> > > cartesian trajectory. And there stile is problem with SetProfile which
> > > don't supply enough data for every possible Trajectory.
> >
> > As you can see in the API of the inherited classes, they add extra
> > algorithm specific configuration functions, for instance the setMax
> > function of the velocityprofile_trap:
> >
> http://people.mech.kuleuven.be/~orocos/pub/devel/kdl/latest/api/html/classK
> >
> DL_1_1VelocityProfile__Trap.html<http://people.mech.kuleuven.be/%7Eorocos/p
> >
> ub/devel/kdl/latest/api/html/classKDL_1_1VelocityProfile__Trap.html><http: /> > /lists.mech.kuleuven.be/mailman/listinfo/orocos-dev> Yes but i would
> like
> > to avoid calling multiple methods for a single trajectory point. The
> > problem with additional methods is when coefficients should be
> calculated
> > ? If it would be done in SetProfile all other parameters need to be set
> > before it. Making that strict calling sequence could be very
> error-prone.
>
> Can you come up with a minimal set of parameters that can fit for every
> possible Trajectory, without having it blowing up?
>
> For quintic spline i need : start_pos, start_vel, start_acc, end_pos, end_vel,
> end_acc, duration

That's just for _one_ particular kind of quintic spline... (There are
dozens of spline basis functions, you know.) Each specific choice
of interpolation function requires a number of extra parameters to specify,
and I think that's what Ruben pointed out to be the problem of "blowing up"
APIs.

Personally, I think trajectory generation is one of those fields where it
will be very difficult to avoid a "state full" interface: first one or more
calls to configure which trajectory generator to use, and with which
configuration; than call(s) to configure _this_ trajectory; and only then
the calls to get/set the next interpolation point.

One single class hierarchy will probably also not be the right thing to do,
since it will be very difficult to define the top level, virtual API.

Having a state-full API is not necessarily a problem for user-friendliness
or for keeping your code consistent: in a component-based design, one could
keep the state-full things _inside_ the component (and (re)configure them
there, and only there), and you could provide one component for each (family
of similar) trajectory generation functions.

Herman

PS Can you please not rely on HTML email formatting alone? Your replies
come out very confusing in text-based mail clients...

»

Login or register to post comments

trajectory generation in KDL

Submitted by Konrad Banachowicz on Thu, 2010-11-18 13:48.

Hi ,
I am going to add cubic spline and quintic spline trajectory generation to
KDL.
I need those for integration with ROS, especially for my
JointSplineTrajectoryGenerator package.
I looked in KDL code and KDL::VelocityProfile looks good as the base for may
code but i have problem how to handle SetProfile and SetProfileDuration in
my spline generator because those methods take only two positions witch is
not enough for generation of spline.
Maybe i should make my VelocityProfile smart and depending on arguments of
SetProfileDuration do linear, cubic spline, quintic spline interpolation ?
But there is SetProfile which don't specify the duration which is required.

Pozdrawiam
Konrad Banachowicz

»

Login or register to post comments