Hi everybody,
I was going through the iTaSC documentation and code, when I found iTaSC's
IK solver WDLSPriorVelSolver.
I'm curious. Is it planned or possible to move/port this solver to KDL to
make it easier to use it in other contexts?
If not, do you think it is difficult to do that, e.g. is it closely link to
other parts in the iTaSC framework?
I'm wondering if it could work with KDL::Chain and KDL::Tree structures.
My idea is to use it to create a kinematics plugin for our robot in ROS.
Again, thanks for the information!
Marcus Liebhardt
About the WDLSPriorVelSolver in itasc_solvers
On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
> Hi everybody,
> I was going through the iTaSC documentation and code, when I found iTaSC's IK
> solver WDLSPriorVelSolver.
> I'm curious. Is it planned or possible to move/port this solver to KDL to make
> it easier to use it in other contexts?
KDL should indeed get a serious refactoring overhaul, by adding some things
and removing other stuff. We have not yet found the time to make a decent
roadmap, unfortunately.
> If not, do you think it is difficult to do that, e.g. is it closely link to
> other parts in the iTaSC framework?
The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is also
a _component_, while KDL only contains _algorithms_. We think that is the
right thing to do: to keep KDL fully independent of any component
framework.
Why would you like to extend KDL with component-based solvers?
> I'm wondering if it could work with KDL::Chain and KDL::Tree structures.
There are extensions on the way in this direction. Azamat is working on
them (see some recent posts of his).
> My idea is to use it to create a kinematics plugin for our robot in ROS.
That's best done with framework-independent KDL algorithms! ROS is another
"component framework" (in addition to Orocos/RTT), so the integration you
have in mind will work with "pure" KDL and not with the iTaSC/RTT
components.
> Again, thanks for the information!
> Marcus Liebhardt
herman
About the WDLSPriorVelSolver in itasc_solvers
On 02/08/2012 08:42 AM, Herman Bruyninckx wrote:
> On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
>
>> Hi everybody,
>> I was going through the iTaSC documentation and code, when I found iTaSC's IK
>> solver WDLSPriorVelSolver.
>> I'm curious. Is it planned or possible to move/port this solver to KDL to make
>> it easier to use it in other contexts?
>
> KDL should indeed get a serious refactoring overhaul, by adding some things
> and removing other stuff. We have not yet found the time to make a decent
> roadmap, unfortunately.
it is of interest to move the actual algorithm (wdlsPrior=weighted damped least squares with priorities) to KDL
same for the choleski factorization algorithm in itasc_core btw
>
>> If not, do you think it is difficult to do that, e.g. is it closely link to
>> other parts in the iTaSC framework?
>
> The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is also
> a _component_, while KDL only contains _algorithms_. We think that is the
> right thing to do: to keep KDL fully independent of any component
> framework.
>
> Why would you like to extend KDL with component-based solvers?
>
>> I'm wondering if it could work with KDL::Chain and KDL::Tree structures.
the 'solver', solves the task/output space coordinates to joint coordinates, taking into account weights and the A matrix per priority
the A matrix is constructed out of the feature and robot jacobians
this chain and/or tree information is in the A matrix!
it is just an optimization problem
so it does work already with chains/trees
eg. the PR2 model is KDL::Tree and the Kuka LWR is a KDL::Chain
>
> There are extensions on the way in this direction. Azamat is working on
> them (see some recent posts of his).
He's working on the resolved acceleration case
>
>> My idea is to use it to create a kinematics plugin for our robot in ROS.
>
> That's best done with framework-independent KDL algorithms! ROS is another
> "component framework" (in addition to Orocos/RTT), so the integration you
> have in mind will work with "pure" KDL and not with the iTaSC/RTT
> components.
>
>> Again, thanks for the information!
>> Marcus Liebhardt
>
> herman
About the WDLSPriorVelSolver in itasc_solvers
2012/2/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
>
> Hi everybody,
>> I was going through the iTaSC documentation and code, when I found
>> iTaSC's IK
>> solver WDLSPriorVelSolver.
>> I'm curious. Is it planned or possible to move/port this solver to KDL to
>> make
>> it easier to use it in other contexts?
>>
>
> KDL should indeed get a serious refactoring overhaul, by adding some things
> and removing other stuff. We have not yet found the time to make a decent
> roadmap, unfortunately.
>
>
> If not, do you think it is difficult to do that, e.g. is it closely link
>> to
>> other parts in the iTaSC framework?
>>
>
> The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is also
> a _component_, while KDL only contains _algorithms_. We think that is the
> right thing to do: to keep KDL fully independent of any component
> framework.
>
> Why would you like to extend KDL with component-based solvers?
I don't exactly like to do that, but I'm interested in using a solver,
which implements priorities. I couldn't find a solver in KDL, which does
that (please correct me, if I'm wrong).
One use case of priorities would be implementing joint limit _avoidance_
(in contrast to only respecting these limits as the current position
solvers (*_JL) do).
I'm not sure how this is done in the human-robot comanipulation demo [1].
Is it implemented using priorities or weights or both?
"task activated close to the limit" made me think it is implemented as a
prioritised task.
Now, if I like to use such a feature with KDL, I probably would end up
writing a new solver.
Instead of writing multiple solvers for different tasks, I was wondering if
there are other ways to achieve this, e.g. by interfacing with iTasc?
Are there other modular ways to add functionalities to the current solvers?
>
>
> I'm wondering if it could work with KDL::Chain and KDL::Tree structures.
>>
>
> There are extensions on the way in this direction. Azamat is working on
> them (see some recent posts of his).
>
>
> My idea is to use it to create a kinematics plugin for our robot in ROS.
>>
>
> That's best done with framework-independent KDL algorithms!
Indeed. That is also how I implemented a kinematics node the first time.
> ROS is another
> "component framework" (in addition to Orocos/RTT), so the integration you
> have in mind will work with "pure" KDL and not with the iTaSC/RTT
> components.
>
>
> Again, thanks for the information!
>> Marcus Liebhardt
>>
>
> herman
>
>
>
Regards,
Marcus
[1] http://www.orocos.org/files/iTaSC_comanipulation_demo.pdf
About the WDLSPriorVelSolver in itasc_solvers
On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
> 2012/2/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
>
> Hi everybody,
> I was going through the iTaSC documentation and code,
> when I found iTaSC's IK
> solver WDLSPriorVelSolver.
> I'm curious. Is it planned or possible to move/port
> this solver to KDL to make
> it easier to use it in other contexts?
>
>
> KDL should indeed get a serious refactoring overhaul, by adding some
> things
> and removing other stuff. We have not yet found the time to make a
> decent
> roadmap, unfortunately.
>
> If not, do you think it is difficult to do that, e.g. is it
> closely link to
> other parts in the iTaSC framework?
>
>
> The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is
> also
> a _component_, while KDL only contains _algorithms_. We think that is
> the
> right thing to do: to keep KDL fully independent of any component
> framework.
>
> Why would you like to extend KDL with component-based solvers?
>
>
> I don't exactly like to do that, but I'm interested in using a solver, which
> implements priorities. I couldn't find a solver in KDL, which does that
> (please correct me, if I'm wrong).
>
> One use case of priorities would be implementing joint limit _avoidance_ (in
> contrast to only respecting these limits as the current position solvers
> (*_JL) do).
> I'm not sure how this is done in the human-robot comanipulation demo [1]. Is
> it implemented using priorities or weights or both?
> "task activated close to the limit" made me think it is implemented as a
> prioritised task.
No, as a 'weighted' task. But you could choose priorities, too.
> Now, if I like to use such a feature with KDL, I probably would end up writing
> a new solver.
> Instead of writing multiple solvers for different tasks, I was wondering if
> there are other ways to achieve this, e.g. by interfacing with iTasc?
> Are there other modular ways to add functionalities to the current solvers?
One solver is designed to solve one particular constrained optimization
problem. Typically (but not exclusively) that means that a new solver will
have to be written (from "scratch") when one changes the kind of
constrained optimization problem that one wants to solve.
> I'm wondering if it could work with KDL::Chain and
> KDL::Tree structures.
>
>
> There are extensions on the way in this direction. Azamat is working on
> them (see some recent posts of his).
>
> My idea is to use it to create a kinematics plugin for our
> robot in ROS.
>
>
> That's best done with framework-independent KDL algorithms!
>
> Indeed. That is also how I implemented a kinematics node the first time.
>
> ROS is another
> "component framework" (in addition to Orocos/RTT), so the
> integration you
> have in mind will work with "pure" KDL and not with the iTaSC/RTT
> components.
>
> Again, thanks for the information!
> Marcus Liebhardt
>
Herman
About the WDLSPriorVelSolver in itasc_solvers
On Wednesday 08 February 2012 17:26:31 Marcus Liebhardt wrote:
> 2012/2/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>
> > On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
> > Hi everybody,
> >
> >> I was going through the iTaSC documentation and code, when I found
> >> iTaSC's IK
> >> solver WDLSPriorVelSolver.
> >> I'm curious. Is it planned or possible to move/port this solver to KDL
> >> to make
> >> it easier to use it in other contexts?
> >
> > KDL should indeed get a serious refactoring overhaul, by adding some
> > things and removing other stuff. We have not yet found the time to make
> > a decent roadmap, unfortunately.
> >
> > If not, do you think it is difficult to do that, e.g. is it closely
> > link
> >
> >> to
> >> other parts in the iTaSC framework?
> >
> > The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is
> > also a _component_, while KDL only contains _algorithms_. We think that
> > is the right thing to do: to keep KDL fully independent of any
> > component framework.
> >
> > Why would you like to extend KDL with component-based solvers?
>
> I don't exactly like to do that, but I'm interested in using a solver,
> which implements priorities. I couldn't find a solver in KDL, which does
> that (please correct me, if I'm wrong).
Why are you not just using the iTaSC software then?
It already contains the solver you need. So you just have to implement your
own task and then, you can use the solver for free :)
>
> One use case of priorities would be implementing joint limit _avoidance_
> (in contrast to only respecting these limits as the current position
> solvers (*_JL) do).
> I'm not sure how this is done in the human-robot comanipulation demo [1].
> Is it implemented using priorities or weights or both?
> "task activated close to the limit" made me think it is implemented as a
> prioritised task.
We use both prioritization and weights. These things are all configurable. So
there is no recoding needed if you want to change priorities or weighting!
Just change some properties and rerun!
Futhermore iTaSC makes use of rFSM (reduced Finite State Machines), which
allow to make a nice state machine for your task in which you can adapt the
priorities and the weights ONLINE depending on the actual outcomes or
performance of your task.
>
> Now, if I like to use such a feature with KDL, I probably would end up
> writing a new solver.
> Instead of writing multiple solvers for different tasks, I was wondering if
> there are other ways to achieve this, e.g. by interfacing with iTasc?
> Are there other modular ways to add functionalities to the current solvers?
>
> > I'm wondering if it could work with KDL::Chain and KDL::Tree
> > structures.
> >
> > There are extensions on the way in this direction. Azamat is working on
> > them (see some recent posts of his).
> >
> > My idea is to use it to create a kinematics plugin for our robot in
> > ROS.
> >
> > That's best done with framework-independent KDL algorithms!
Can you be more specific of the actual tasks you want to implement?
This way we could maybe help you by pointing out what we would do to implement
it.
Kind regards,
Tinne
About the WDLSPriorVelSolver in itasc_solvers
2012/2/8 Tinne De Laet <tinne [dot] delaet [..] ...>
> On Wednesday 08 February 2012 17:26:31 Marcus Liebhardt wrote:
> > 2012/2/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> >
> > > On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
> > > Hi everybody,
> > >
> > >> I was going through the iTaSC documentation and code, when I found
> > >> iTaSC's IK
> > >> solver WDLSPriorVelSolver.
> > >> I'm curious. Is it planned or possible to move/port this solver to KDL
> > >> to make
> > >> it easier to use it in other contexts?
> > >
> > > KDL should indeed get a serious refactoring overhaul, by adding some
> > > things and removing other stuff. We have not yet found the time to make
> > > a decent roadmap, unfortunately.
> > >
> > > If not, do you think it is difficult to do that, e.g. is it closely
> > > link
> > >
> > >> to
> > >> other parts in the iTaSC framework?
> > >
> > > The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is
> > > also a _component_, while KDL only contains _algorithms_. We think that
> > > is the right thing to do: to keep KDL fully independent of any
> > > component framework.
> > >
> > > Why would you like to extend KDL with component-based solvers?
> >
> > I don't exactly like to do that, but I'm interested in using a solver,
> > which implements priorities. I couldn't find a solver in KDL, which does
> > that (please correct me, if I'm wrong).
>
> Why are you not just using the iTaSC software then?
>
Well, I'm new to iTaSC and had no time to try it out yet. It looks
powerful, but also big and complicated. However, our talk made me even more
curious to try it out! :-)
> It already contains the solver you need. So you just have to implement your
> own task and then, you can use the solver for free :)
> >
> > One use case of priorities would be implementing joint limit _avoidance_
> > (in contrast to only respecting these limits as the current position
> > solvers (*_JL) do).
> > I'm not sure how this is done in the human-robot comanipulation demo [1].
> > Is it implemented using priorities or weights or both?
> > "task activated close to the limit" made me think it is implemented as a
> > prioritised task.
> We use both prioritization and weights. These things are all configurable.
> So
> there is no recoding needed if you want to change priorities or weighting!
> Just change some properties and rerun!
> Futhermore iTaSC makes use of rFSM (reduced Finite State Machines), which
> allow to make a nice state machine for your task in which you can adapt the
> priorities and the weights ONLINE depending on the actual outcomes or
> performance of your task.
>
> >
> > Now, if I like to use such a feature with KDL, I probably would end up
> > writing a new solver.
> > Instead of writing multiple solvers for different tasks, I was wondering
> if
> > there are other ways to achieve this, e.g. by interfacing with iTasc?
> > Are there other modular ways to add functionalities to the current
> solvers?
> >
> > > I'm wondering if it could work with KDL::Chain and KDL::Tree
> > > structures.
> > >
> > > There are extensions on the way in this direction. Azamat is working on
> > > them (see some recent posts of his).
> > >
> > > My idea is to use it to create a kinematics plugin for our robot in
> > > ROS.
> > >
> > > That's best done with framework-independent KDL algorithms!
> Can you be more specific of the actual tasks you want to implement?
> This way we could maybe help you by pointing out what we would do to
> implement
> it.
>
My main task at the moment is to improve an old, robot specific and not
parametrisable IK solver, which is based on the pr2_arm_kinematics. My idea
is to replace it with a generic KDL solver, what worked for me before.
This allows me to use the framework/code structure, which is already in
place.
However, I need to find a solution for joint limit avoidance. Also, this
change needs to happen fast.
Hence, in short term I will not be able to implement iTaSC. But in the long
run, I definitely want to try it out.
Marcus
>
> Kind regards,
> Tinne
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
About the WDLSPriorVelSolver in itasc_solvers
On 02/08/2012 09:26 AM, Marcus Liebhardt wrote:Herman [dot] Bruyninckx [..] ...>>
> 2012/2/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
>
> On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
>
> Hi everybody,
> I was going through the iTaSC documentation and code, when I found iTaSC's IK
> solver WDLSPriorVelSolver.
> I'm curious. Is it planned or possible to move/port this solver to KDL to make
> it easier to use it in other contexts?
>
>
> KDL should indeed get a serious refactoring overhaul, by adding some things
> and removing other stuff. We have not yet found the time to make a decent
> roadmap, unfortunately.
>
>
> If not, do you think it is difficult to do that, e.g. is it closely link to
> other parts in the iTaSC framework?
>
>
> The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is also
> a _component_, while KDL only contains _algorithms_. We think that is the
> right thing to do: to keep KDL fully independent of any component
> framework.
>
> Why would you like to extend KDL with component-based solvers?
>
>
> I don't exactly like to do that, but I'm interested in using a solver, which implements priorities. I couldn't find a solver in KDL, which does that (please correct me, if
> I'm wrong).
why don't you use iTaSC?
>
> One use case of priorities would be implementing joint limit _avoidance_ (in contrast to only respecting these limits as the current position solvers (*_JL) do).
> I'm not sure how this is done in the human-robot comanipulation demo [1]. Is it implemented using priorities or weights or both?
> "task activated close to the limit" made me think it is implemented as a prioritised task.
best would be with inequality constraints (joint position>value)
that is work in progress
for now, and in the comanipulation demo: activate the task if close to limit (weight profile for smooth transition) and velocity setpoint (also a profile, to push harder if
closer to limit) on that joint
see graphs for the task on http://www.orocos.org/files/iTaSC_comanipulation_demo.pdf (link can also be found on itasc wiki, under comanipulation demo)
>
> Now, if I like to use such a feature with KDL, I probably would end up writing a new solver.
> Instead of writing multiple solvers for different tasks, I was wondering if there are other ways to achieve this, e.g. by interfacing with iTasc?
> Are there other modular ways to add functionalities to the current solvers?
create a new solver= a modular block of itasc
>
>
>
> I'm wondering if it could work with KDL::Chain and KDL::Tree structures.
>
>
> There are extensions on the way in this direction. Azamat is working on
> them (see some recent posts of his).
>
>
> My idea is to use it to create a kinematics plugin for our robot in ROS.
>
>
> That's best done with framework-independent KDL algorithms!
>
>
> Indeed. That is also how I implemented a kinematics node the first time.
>
> ROS is another
> "component framework" (in addition to Orocos/RTT), so the integration you
> have in mind will work with "pure" KDL and not with the iTaSC/RTT
> components.
>
>
> Again, thanks for the information!
> Marcus Liebhardt
>
>
> herman
>
>
>
> Regards,
> Marcus
>
> [1] http://www.orocos.org/files/iTaSC_comanipulation_demo.pdf
>