Thanks Ruben
I already saw the ocl/motion_control/naxes/nAxesGeneratorPos and ocl/motion_control/cartesian/CartesianGeneratorPos generators.
What I was looking for is either how I could use the Paths/Trajectories together with those controllers (especially the CartesianGeneratorPos) or a controller having built in support for Paths/Trajectories.
I assume I will have to create my own CartesianGeneratorPos which supports Paths/Trajectories, but I cannot really see yet how this was planned to fit together.
How are Paths/Trajectories usually used in Orocos Motion Control?
Marc
-----Ursprüngliche Nachricht-----
Von: orocos-users-bounces [..] ... [mailto:orocos-users-bounces [..] ...] Im Auftrag von Ruben Smits
Gesendet: Mittwoch, 11. Februar 2009 10:57
An: orocos-users [..] ...
Betreff: Re: [Orocos-users] Trajectory/Path
On Wednesday 11 February 2009 10:00:34 Bodmer Marc wrote:
> Hi List
>
> Are there any examples for how to cleanly use the Trajectory and Path
> Classes from KDL?
> I assume these would be used on the naxes/Cartesian Generator Level,
> but in OCL i couldn't find any use of these classes.
In OCL we use the velocity-profiles in the naxes/generator and cartesian/generator classes.
We do not use the paths in these generators because they cannot be adapted/created at runtime without memory-allocation, which is needed for in these implementations. If the path is known at compile/configuration time, you can use the trajectories (which binds paths and velocity-profiles together).
> Does someone have such a Generator and is willing to share it's code.
> It is really a good starting point to have something like the OCL
> Components, if there are.
look at ocl/motion_control/naxes/nAxesGeneratorPos and ocl/motion_control/cartesian/CartesianGeneratorPos
> (sidekick to the ongoing
> RTT 2.0 dicussion, examples is really a GOOD thing. But thank you for
> this great framework. I really like what I saw so far, I still have to
> find my way through the jungle though...).
All we need is time :)
Ruben
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Trajectory/Path
Thanks Herman
> That would mean that you have fixed geometry, but want to adapt some
cutting parameters along this geometry?
exactly
> In our own research, we are working towards a motion specification
framework that is fully "constraint based"; i.e., all inputs are not in
the form of hard setpoints, but in the form of soft constraints, which a
realtime constraint solver transforms into concrete motion setpoints at
each sample instant.
> In your use case, the NC geometry could be such a "soft" constraint
(although it will be a very hard kind of softness, I guess:-)). > How to
express your process parameter specifications in this framework, I do
not know immediately, but I am certainly interested in brainstorming
about it with you.
Thanks for your offer, since I don't know this framework I think I
cannot really discuss. But what you proposed sounds reasonable (the not
so soft softness). Can you tell me more about this framework? I am
certainly interested in it.
> There is, from an application point of view, no "big picture" in
> Orocos, except for the fact that we want to provide a _framework_ with
> a lot of good tools and components to make the development of _your_
> big picture as strong as possible :-)
I "know" about this and actually that's one of the great things of
OROCOS. But right now I am trying to hack together a fast prototype
which shows the power of Orocos and Opensource for our Application. So I
am trying to use as much knowledge and code already available,
furthermore it would probably be beneficial to use "tested" and
supported "standard" components when they fit in. Even when we have to
help testing and improving, we are still not alone.
Trajectory/Path
On Wed, 11 Feb 2009, Bodmer Marc wrote:
>> That would mean that you have fixed geometry, but want to adapt some
> cutting parameters along this geometry?
>
> exactly
>
>> In our own research, we are working towards a motion specification
> framework that is fully "constraint based"; i.e., all inputs are not in
> the form of hard setpoints, but in the form of soft constraints, which a
> realtime constraint solver transforms into concrete motion setpoints at
> each sample instant.
>> In your use case, the NC geometry could be such a "soft" constraint
> (although it will be a very hard kind of softness, I guess:-)). > How to
> express your process parameter specifications in this framework, I do
> not know immediately, but I am certainly interested in brainstorming
> about it with you.
>
> Thanks for your offer, since I don't know this framework I think I
> cannot really discuss. But what you proposed sounds reasonable (the not
> so soft softness). Can you tell me more about this framework? I am
> certainly interested in it.
It's part of Ruben's PhD work, and he is currently working on an
implementation in Orocos. I can send you a paper (off line) that we
published about it two years ago, but that's paper, and the link with code
is not always so obvious :-)
>> There is, from an application point of view, no "big picture" in
>> Orocos, except for the fact that we want to provide a _framework_ with
>
>> a lot of good tools and components to make the development of _your_
>> big picture as strong as possible :-)
>
> I "know" about this and actually that's one of the great things of
> OROCOS. But right now I am trying to hack together a fast prototype
> which shows the power of Orocos and Opensource for our Application. So I
> am trying to use as much knowledge and code already available,
I understand :-)
> furthermore it would probably be beneficial to use "tested" and
> supported "standard" components when they fit in. Even when we have to
> help testing and improving, we are still not alone.
Indeed! Currently, only the RTT things have received a testing which is
worth that name; the KDL and BFL parts of Orocos have not yet been so
lucky.
Herman
Trajectory/Path
On Wednesday 11 February 2009 11:30:29 you wrote:
> Thanks Ruben
>
> I already saw the ocl/motion_control/naxes/nAxesGeneratorPos and
> ocl/motion_control/cartesian/CartesianGeneratorPos generators.
>
> What I was looking for is either how I could use the Paths/Trajectories
> together with those controllers (especially the CartesianGeneratorPos)
> or a controller having built in support for Paths/Trajectories.
>
> I assume I will have to create my own CartesianGeneratorPos which supports
> Paths/Trajectories, but I cannot really see yet how this was planned to fit
> together.
A path is just a 3D (with rotations) path in space, it returns a Frame/Twist
with respect to a running parameter s.
A velocity profile defines how position/velocity/acceleration changes over time
for a running parameter s.
A trajectory puts the velocity profile on top of the path, and returns a
Frame/Twist with respect to time.
> How are Paths/Trajectories usually used in Orocos Motion Control?
When you are doing off-line path planning, the paths/trajectories are very
handy. But I never did this myself, since off-line path planning is so old-
school ;). I hope the doxygen information about the classes are informative
enough. The idea is that we have some primitive paths, line, arc, etc. and
that these can be put together in a composite path. The same holds for
trajectories.
The major problem I have for using paths in real-time components is the fact
that creating path's on-line needs memory allocation, which is dangerous in
real-time components. If your planner is not real-time, I highly recommend you
to use the paths/trajectories.
> Marc
>
> -----Ursprüngliche Nachricht-----
> Von: orocos-users-bounces [..] ...
> [mailto:orocos-users-bounces [..] ...] Im Auftrag von Ruben
> Smits Gesendet: Mittwoch, 11. Februar 2009 10:57
> An: orocos-users [..] ...
> Betreff: Re: [Orocos-users] Trajectory/Path
>
> On Wednesday 11 February 2009 10:00:34 Bodmer Marc wrote:
> > Hi List
> >
> > Are there any examples for how to cleanly use the Trajectory and Path
> > Classes from KDL?
> > I assume these would be used on the naxes/Cartesian Generator Level,
> > but in OCL i couldn't find any use of these classes.
>
> In OCL we use the velocity-profiles in the naxes/generator and
> cartesian/generator classes.
>
> We do not use the paths in these generators because they cannot be
> adapted/created at runtime without memory-allocation, which is needed for
> in these implementations. If the path is known at compile/configuration
> time, you can use the trajectories (which binds paths and velocity-profiles
> together).
>
> > Does someone have such a Generator and is willing to share it's code.
> > It is really a good starting point to have something like the OCL
> > Components, if there are.
>
> look at ocl/motion_control/naxes/nAxesGeneratorPos and
> ocl/motion_control/cartesian/CartesianGeneratorPos
>
> > (sidekick to the ongoing
> > RTT 2.0 dicussion, examples is really a GOOD thing. But thank you for
> > this great framework. I really like what I saw so far, I still have to
> > find my way through the jungle though...).
>
> All we need is time :)
>
> Ruben
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Trajectory/Path
> A path is just a 3D (with rotations) path in space, it returns a
Frame/Twist with respect to a running parameter s.
> A velocity profile defines how position/velocity/acceleration changes
over time for a running parameter s.
> A trajectory puts the velocity profile on top of the path, and returns
a Frame/Twist with respect to time.
> When you are doing off-line path planning, the paths/trajectories are
very handy. But I never did this myself, since off-line path planning
is so old- school ;). I hope the doxygen information about the classes
are informative enough. The idea is that we have some primitive paths,
line, arc, etc. and that these can be put together in a composite path.
The same holds for trajectories.
> The major problem I have for using paths in real-time components is
the fact that creating path's on-line needs memory allocation, > which
is dangerous in real-time components. If your planner is not real-time,
I highly recommend you to use the paths/trajectories.
Thank you Ruben for this summary, this however raises another question:
Since offline planning is so old school :-) , and since you seem to be
experienced with dynamic
realtime trajectory planning.
How does the structure of a dynamic planning application in orocos look
like?
I don't have any complex autonomous vehicles in mind, just a simple nc
machine
with dynamic changing cutting parameters.
Did you expand the _moveTo() Command Interface of the
CartesianGeneratorPos to fit your
needs and create a planning component which acesses this IF? How do you
specify which
motions the machine should conduct?
Well, probably these are all a little unspecific questions, that's
because I am still trying to
get the big picture...
Trajectory/Path
On Wednesday 11 February 2009 14:04:51 Bodmer Marc wrote:
> > A path is just a 3D (with rotations) path in space, it returns a
>
> Frame/Twist with respect to a running parameter s.
>
> > A velocity profile defines how position/velocity/acceleration changes
>
> over time for a running parameter s.
>
> > A trajectory puts the velocity profile on top of the path, and returns
>
> a Frame/Twist with respect to time.
>
> > When you are doing off-line path planning, the paths/trajectories are
>
> very handy. But I never did this myself, since off-line path planning
> is so old- school ;). I hope the doxygen information about the classes
> are informative enough. The idea is that we have some primitive paths,
> line, arc, etc. and that these can be put together in a composite path.
> The same holds for trajectories.
>
> > The major problem I have for using paths in real-time components is
>
> the fact that creating path's on-line needs memory allocation, > which
> is dangerous in real-time components. If your planner is not real-time,
> I highly recommend you to use the paths/trajectories.
>
> Thank you Ruben for this summary, this however raises another question:
> Since offline planning is so old school :-) , and since you seem to be
> experienced with dynamic
> realtime trajectory planning.
> How does the structure of a dynamic planning application in orocos look
> like?
Look at http://people.mech.kuleuven.be/~dversche/realtimeopt/realtimeopt.html,
this is the most recent thing we (one of my colleagues) has done in this area.
I think the main idea is to have a non-real-time overall path planner which
fills a buffer and a real-time set-point generator reads this buffer and sends
its result to a controller.
> I don't have any complex autonomous vehicles in mind, just a simple nc
> machine
> with dynamic changing cutting parameters.
>
> Did you expand the _moveTo() Command Interface of the
> CartesianGeneratorPos to fit your
> needs and create a planning component which acesses this IF? How do you
> specify which
> motions the machine should conduct?
The CartesianGeneratorPos is only able to create straight-line trajectories,
because it does not use Path structures. I personally never used anything else
wrt to path planning.
Ruben
Trajectory/Path
On Wed, 11 Feb 2009, Bodmer Marc wrote:
>> A path is just a 3D (with rotations) path in space, it returns a
> Frame/Twist with respect to a running parameter s.
>> A velocity profile defines how position/velocity/acceleration changes
> over time for a running parameter s.
>> A trajectory puts the velocity profile on top of the path, and returns
> a Frame/Twist with respect to time.
>> When you are doing off-line path planning, the paths/trajectories are
> very handy. But I never did this myself, since off-line path planning
> is so old- school ;). I hope the doxygen information about the classes
> are informative enough. The idea is that we have some primitive paths,
> line, arc, etc. and that these can be put together in a composite path.
> The same holds for trajectories.
>> The major problem I have for using paths in real-time components is
> the fact that creating path's on-line needs memory allocation, > which
> is dangerous in real-time components. If your planner is not real-time,
> I highly recommend you to use the paths/trajectories.
>
> Thank you Ruben for this summary, this however raises another question:
> Since offline planning is so old school :-) , and since you seem to be
> experienced with dynamic
> realtime trajectory planning.
> How does the structure of a dynamic planning application in orocos look
> like?
It's at the moment not much more than a somewhat advanced sensor feedback
loop :-) The "somewhat more advanced" part means that we use a set of
possible feedback laws and estimator modules together in a finite state
machine, so that adaptability and robustness can be higher than with one
single feedback law.
> I don't have any complex autonomous vehicles in mind, just a simple nc
> machine with dynamic changing cutting parameters.
That would mean that you have fixed geometry, but want to adapt some
cutting parameters along this geometry?
> Did you expand the _moveTo() Command Interface of the
> CartesianGeneratorPos to fit your needs and create a planning component
> which acesses this IF? How do you specify which motions the machine
> should conduct?
In our own research, we are working towards a motion specification
framework that is fully "constraint based"; i.e., all inputs are not in the
form of hard setpoints, but in the form of soft constraints, which a
realtime constraint solver transforms into concrete motion setpoints at
each sample instant.
In your use case, the NC geometry could be such a "soft" constraint
(although it will be a very hard kind of softness, I guess:-)). How to
express your process parameter specifications in this framework, I do not
know immediately, but I am certainly interested in brainstorming about it
with you.
> Well, probably these are all a little unspecific questions, that's
> because I am still trying to get the big picture...
There is, from an application point of view, no "big picture" in Orocos,
except for the fact that we want to provide a _framework_ with a lot of
good tools and components to make the development of _your_ big picture as
strong as possible :-)
Herman