KDL as backend for underconstrained motion specification
| Submitted by fosini on Wed, 2011-02-16 12:36 |
Hello devs, especially the KDL-inclined ones :)
We have a colleague in our group that is currently using KDL's IK tree
solvers, and the results so far have been very satisfactory. In the coming
weeks, we will have the need for solvers that build on top of these tree
solvers, the immediate use case being task priorization by null-space
projection. Other use cases may follow. Before starting a KDL-based
implementation from scratch, I'd like to ask whether someone else is (or has
been) working on this, in order not to duplicate efforts. In particular, I
would like to ask about the status of the iTaSC implementation, which was
referred to in this list on April 2010 [1]. It would be preferable to build
on, and contribute to efforts that already have some momentum.
TIA,
Adolfo.
[1]
http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
KDL as backend for underconstrained motion specification
On Wednesday 16 February 2011 13:32:23 Adolfo Rodríguez Tsouroukdissian wrote:
> Hello devs, especially the KDL-inclined ones :)
>
> We have a colleague in our group that is currently using KDL's IK tree
> solvers, and the results so far have been very satisfactory. In the coming
> weeks, we will have the need for solvers that build on top of these tree
> solvers, the immediate use case being task priorization by null-space
> projection. Other use cases may follow. Before starting a KDL-based
> implementation from scratch, I'd like to ask whether someone else is (or
> has been) working on this, in order not to duplicate efforts. In
> particular, I would like to ask about the status of the iTaSC
> implementation, which was referred to in this list on April 2010 [1]. It
> would be preferable to build on, and contribute to efforts that already
> have some momentum.
Our current iTaSC implementation is still highly coupled with Orocos/RTT as
the basic building blocks are full-fledged components, not classes. They use
KDL classes internally though.
A colleague of mine is working on two things at the moment:
* adding priorization to the current implementation
* adding acceleration resolved solvers (currently we only have velocity
resolved solvers)
This is still WIP, far from usable in production systems, but if you feel
adventurous, we can share the development load. The drawback is that we are
still bound to the Orocos components and are not working on a KDL only
solution yet.
> TIA,
>
> Adolfo.
-- Ruben
> [1]
> http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
>
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited. If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
KDL as backend for underconstrained motion specification
2011/2/16 Ruben Smits <ruben [dot] smits [..] ...>
> On Wednesday 16 February 2011 13:32:23 Adolfo Rodríguez Tsouroukdissian
> wrote:
> > Hello devs, especially the KDL-inclined ones :)
> >
> > We have a colleague in our group that is currently using KDL's IK tree
> > solvers, and the results so far have been very satisfactory. In the
> coming
> > weeks, we will have the need for solvers that build on top of these tree
> > solvers, the immediate use case being task priorization by null-space
> > projection. Other use cases may follow. Before starting a KDL-based
> > implementation from scratch, I'd like to ask whether someone else is (or
> > has been) working on this, in order not to duplicate efforts. In
> > particular, I would like to ask about the status of the iTaSC
> > implementation, which was referred to in this list on April 2010 [1]. It
> > would be preferable to build on, and contribute to efforts that already
> > have some momentum.
>
> Our current iTaSC implementation is still highly coupled with Orocos/RTT as
> the basic building blocks are full-fledged components, not classes. They
> use
> KDL classes internally though.
>
> A colleague of mine is working on two things at the moment:
> * adding priorization to the current implementation
>
We share an interest and we have someone willing to work on it. Sounds like
we could make some progress here. Note: weight-based priorization is also
interesting, but not on our plate at the moment.
* adding acceleration resolved solvers (currently we only have velocity
> resolved solvers)
>
We also share an interest here, but unfortunately we won't have anyone
working on that in the foreseeable future :(
>
> This is still WIP, far from usable in production systems, but if you feel
> adventurous, we can share the development load. The drawback is that we are
> still bound to the Orocos components and are not working on a KDL only
> solution yet.
>
Orocos integration is a plus, but we would prefer to have a standalone KDL
solver for our particular use case. At any rate, it wouldn't hurt to lurk
into the existing implementation, if it is publicly available. Otherwise,
we'll probably bring design discussions over to the list. We are about to
plan a work package on this, and we are scouting for prior art
(implementation-wise).
Thanks for the infos so far. We appreciate greatly the community's interest
on the topic.
Best,
Adolfo.
>
> > TIA,
> >
> > Adolfo.
>
> -- Ruben
>
> > [1]
> >
> http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
> >
> > --
> > Adolfo Rodríguez Tsouroukdissian, Ph. D.
> >
> > Robotics engineer
> > PAL ROBOTICS S.L
> > http://www.pal-robotics.com
> > Tel. +34.93.414.53.47
> > Fax.+34.93.209.11.09
> >
> > CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> > contain confidential information which is privileged and intended only
> for
> > the individual or entity to whom they are addressed. If you are not the
> > intended recipient, you are hereby notified that any disclosure, copying,
> > distribution or use of this e-mail and/or accompanying document(s) is
> > strictly prohibited. If you have received this e-mail in error, please
> > immediately notify the sender at the above e-mail address.
>
KDL as backend for underconstrained motion specification
Hi,
On 02/16/2011 03:12 PM, Adolfo Rodríguez Tsouroukdissian wrote:
2011/2/16 Ruben Smits<ruben [dot] smits [..] ...ruben [dot] smits [..] ...>>
On Wednesday 16 February 2011 13:32:23 Adolfo Rodríguez Tsouroukdissian wrote:
> Hello devs, especially the KDL-inclined ones :)
>
> We have a colleague in our group that is currently using KDL's IK tree
> solvers, and the results so far have been very satisfactory. In the coming
> weeks, we will have the need for solvers that build on top of these tree
> solvers, the immediate use case being task priorization by null-space
> projection. Other use cases may follow. Before starting a KDL-based
> implementation from scratch, I'd like to ask whether someone else is (or
> has been) working on this, in order not to duplicate efforts. In
> particular, I would like to ask about the status of the iTaSC
> implementation, which was referred to in this list on April 2010 [1]. It
> would be preferable to build on, and contribute to efforts that already
> have some momentum.
Our current iTaSC implementation is still highly coupled with Orocos/RTT as
the basic building blocks are full-fledged components, not classes. They use
KDL classes internally though.
A colleague of mine is working on two things at the moment:
I'm working on this at the moment
* adding priorization to the current implementation
We share an interest and we have someone willing to work on it. Sounds like we could make some progress here. Note: weight-based priorization is also interesting, but not on our plate at the moment.
I would like to use both, weights (on constraints in task space and
joint space) and priorization (primary constraints, secondary
constraints...)
I'm implementing an algorithm based on the proposed algorithm by
P. Baerlocher, R. Boulic: “Task-priority formulations for the kinematic
control of highly redundant articulated structures,” Proc. IEEE IROS
98, pp 323329 (1998)
(without weights)
which is an improvement of :
B. Siciliano, J.-J.E. Slotine: “A general framework for managing
multiple tasks in highly redundant robotic systems,” Proc. IEEE ICRA
pp. 12111216 (1991)
An interesting paper is of:
Oussama Kanoun, Prioritizing linear equality and inequality systems:
application to local
motion planning for redundant robots, IEEE ICRA 2009
They have some code available in the
equality constraints:
http://softs.laas.fr/openrobots/robotpkg/path/hpp-gik/index.html =>LGPL
equality + inequality constraints?!
http://softs.laas.fr/openrobots/robotpkg/path/hpp-hik/index.html =>
closed source
The implementation of last paper, for equality and inequality
constraints is certainly of interest!
But out of the scope of my project right now
Maybe interesting for someone else to implement?
* adding acceleration resolved solvers (currently we only have velocity
resolved solvers)
We also share an interest here, but unfortunately we won't have anyone working on that in the foreseeable future :(
This is still WIP, far from usable in production systems, but if you feel
adventurous, we can share the development load. The drawback is that we are
still bound to the Orocos components and are not working on a KDL only
solution yet.
Orocos integration is a plus, but we would prefer to have a standalone KDL solver for our particular use case. At any rate, it wouldn't hurt to lurk into the existing implementation, if it is publicly available. Otherwise, we'll probably bring design discussions over to the list. We are about to plan a work package on this, and we are scouting for prior art (implementation-wise).
It can be interesting to make a KDL implementation of it, in the end it
is a function you can call
The current solver that we use (without priorities) is actually about
the same as ChainIkSolverVel_wdls, except that we give the "solver"
already the jacobians, in stead that he has to calculate them himself
(It could be rewritten to let this function:1) calculate the jacobians
2) call a function that does what abovementionned function does, but
with jacobians as parameters
solver = ChainIkSolverVel_wdls(chain)
solver.CartToJnt(const JntArray& q_in, const Twist& v_in, JntArray&
qdot_out)
which calls on his turn
solver2 = ChainIkSolverVel_wdls_with_jacobians()
solver2.CartToJnt(const Jacobian& J_in, const Twist& v_in, JntArray&
qdot_out)
=> this second solver can be used in iTaSC
)
So I think a solver with priorities belongs somewhere here:
*With a name like: ChainIkSolverVel_wdls_priorities() ?
*and then call:
solver3.ChainIkSolverVel_wdls_priorities()
solver3.CartToJnt(const std::vector<Jacobian>& J_in, const Twist& v_in,
JntArray& qdot_out)
(this is the most usefull for my case, you can do then something similar
to explained above)
Thanks for the infos so far. We appreciate greatly the community's interest on the topic.
Best,
Adolfo.
> TIA,
>
> Adolfo.
-- Ruben
Nick
> [1]
> http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
>
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited. If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
--
Adolfo Rodríguez Tsouroukdissian, Ph. D.
Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s)
may contain confidential information which is privileged and
intended only for the individual or entity to whom they are
addressed. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution or use of this
e-mail and/or accompanying document(s) is strictly prohibited. If
you have received this e-mail in error, please immediately notify
the sender at the above e-mail address.
KDL as backend for underconstrained motion specification
Hi,
I have coded the ChainIkSolverVel_wdls in KDL and as a matter of fact
have followed this thread with much interest.
As for the distinction between tasks hierarchy (strict priorities) and
weighting (soft priorities), it has to be noticed that when there is no
solutions to the Inverse Velocity Kinematics problem, this solver
provides a mean to favour some of the tasks dimensions (ie the task
error will be minimized more efficiently in some direction than in
others) and as a matter of fact, tasks weighting is already provided by
this solver at the lowest level.
As for which algorithm to use, the work of Baerlocher and Boulic is a
very strong base to start from but I would suggest to have a look at
these works that were recently published and that provide an effective
way of extending Baerlocher and Boulic work and are also related to
iTasc regarding constraints compatibility matters :
Rubrecht, S. and Padois, V. and Bidaud, P. and de Broissia, M. (2010).
Constraint Compliant Control for a Redundant Manipulator in a Cluttered
Environment. In Proceedings of the 12th International Symposium on
Advances in Robot Kinematics. Pages 367--376. Slovenia.
http://www.isir.upmc.fr/files/2010ACTI1523.pdf
Rubrecht, S. and Padois, V. and Bidaud, P. and De Broissia, M. (2010).
Constraints Compliant Control: constraints compatibility and the
displaced configuration approach. In Proceedings of the 2010 IEEE/RSJ
International Conference on Intelligent Robots and Systems 2010 IEEE/RSJ
International Conference on Intelligent Robots and Systems . Taipei,
Taiwan. http://www.isir.upmc.fr/files/2010ACTI1590.pdf
We also have done some preliminary work on the comparison between strict
and soft priorities in the dynamic control of humanoids using LQP
solvers (related to the work of Kanoun) and I am available to discuss
this topic if some of you are interested.
Thanks for reading and sorry if this message looks like cheap
advertising of our work to some of you.
Best,
Vincent
> Hi,ruben [dot] smits [..] ...>>
>
>
>
> On 02/16/2011 03:12 PM, Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> 2011/2/16 Ruben Smits<ruben [dot] smits [..] ...
> On Wednesday 16 February 2011 13:32:23 Adolfo Rodríguez Tsouroukdissian wrote:
>
>> Hello devs, especially the KDL-inclined ones :)
>>
>> We have a colleague in our group that is currently using KDL's IK tree
>> solvers, and the results so far have been very satisfactory. In the coming
>> weeks, we will have the need for solvers that build on top of these tree
>> solvers, the immediate use case being task priorization by null-space
>> projection. Other use cases may follow. Before starting a KDL-based
>> implementation from scratch, I'd like to ask whether someone else is (or
>> has been) working on this, in order not to duplicate efforts. In
>> particular, I would like to ask about the status of the iTaSC
>> implementation, which was referred to in this list on April 2010 [1]. It
>> would be preferable to build on, and contribute to efforts that already
>> have some momentum.
> Our current iTaSC implementation is still highly coupled with Orocos/RTT as
> the basic building blocks are full-fledged components, not classes. They use
> KDL classes internally though.
>
> A colleague of mine is working on two things at the moment:
>
> I'm working on this at the moment
>
> * adding priorization to the current implementation
>
> We share an interest and we have someone willing to work on it. Sounds like we could make some progress here. Note: weight-based priorization is also interesting, but not on our plate at the moment.
>
> I would like to use both, weights (on constraints in task space and
> joint space) and priorization (primary constraints, secondary
> constraints...)
> I'm implementing an algorithm based on the proposed algorithm by
> P. Baerlocher, R. Boulic: “Task-priority formulations for the kinematic
> control of highly redundant articulated structures,” Proc. IEEE IROS
> 98, pp 323329 (1998)
>
> (without weights)
> which is an improvement of :
>
> B. Siciliano, J.-J.E. Slotine: “A general framework for managing
> multiple tasks in highly redundant robotic systems,” Proc. IEEE ICRA
> pp. 12111216 (1991)
>
> An interesting paper is of:
> Oussama Kanoun, Prioritizing linear equality and inequality systems:
> application to local
> motion planning for redundant robots, IEEE ICRA 2009
> They have some code available in the
> equality constraints:
> http://softs.laas.fr/openrobots/robotpkg/path/hpp-gik/index.html =>LGPL
> equality + inequality constraints?!
> http://softs.laas.fr/openrobots/robotpkg/path/hpp-hik/index.html =>
> closed source
>
> The implementation of last paper, for equality and inequality
> constraints is certainly of interest!
> But out of the scope of my project right now
> Maybe interesting for someone else to implement?
>
> * adding acceleration resolved solvers (currently we only have velocity
> resolved solvers)
>
> We also share an interest here, but unfortunately we won't have anyone working on that in the foreseeable future :(
>
>
> This is still WIP, far from usable in production systems, but if you feel
> adventurous, we can share the development load. The drawback is that we are
> still bound to the Orocos components and are not working on a KDL only
> solution yet.
>
> Orocos integration is a plus, but we would prefer to have a standalone KDL solver for our particular use case. At any rate, it wouldn't hurt to lurk into the existing implementation, if it is publicly available. Otherwise, we'll probably bring design discussions over to the list. We are about to plan a work package on this, and we are scouting for prior art (implementation-wise).
>
> It can be interesting to make a KDL implementation of it, in the end it
> is a function you can call
> The current solver that we use (without priorities) is actually about
> the same as ChainIkSolverVel_wdls, except that we give the "solver"
> already the jacobians, in stead that he has to calculate them himself
> (It could be rewritten to let this function:1) calculate the jacobians
> 2) call a function that does what abovementionned function does, but
> with jacobians as parameters
> solver = ChainIkSolverVel_wdls(chain)
> solver.CartToJnt(const JntArray& q_in, const Twist& v_in, JntArray&
> qdot_out)
> which calls on his turn
> solver2 = ChainIkSolverVel_wdls_with_jacobians()
> solver2.CartToJnt(const Jacobian& J_in, const Twist& v_in, JntArray&
> qdot_out)
> => this second solver can be used in iTaSC
> )
> So I think a solver with priorities belongs somewhere here:
> *With a name like: ChainIkSolverVel_wdls_priorities() ?
> *and then call:
> solver3.ChainIkSolverVel_wdls_priorities()
> solver3.CartToJnt(const std::vector<Jacobian>& J_in, const Twist& v_in,
> JntArray& qdot_out)
> (this is the most usefull for my case, you can do then something similar
> to explained above)
>
>
> Thanks for the infos so far. We appreciate greatly the community's interest on the topic.
>
> Best,
>
> Adolfo.
>
>
>
>
>> TIA,
>>
>> Adolfo.
> -- Ruben
>
> Nick
>
>> [1]
>> http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
>>
>> --
>> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>>
>> Robotics engineer
>> PAL ROBOTICS S.L
>> http://www.pal-robotics.com
>> Tel. +34.93.414.53.47
>> Fax.+34.93.209.11.09
>>
>> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
>> contain confidential information which is privileged and intended only for
>> the individual or entity to whom they are addressed. If you are not the
>> intended recipient, you are hereby notified that any disclosure, copying,
>> distribution or use of this e-mail and/or accompanying document(s) is
>> strictly prohibited. If you have received this e-mail in error, please
>> immediately notify the sender at the above e-mail address.
>
>
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s)
> may contain confidential information which is privileged and
> intended only for the individual or entity to whom they are
> addressed. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution or use of this
> e-mail and/or accompanying document(s) is strictly prohibited. If
> you have received this e-mail in error, please immediately notify
> the sender at the above e-mail address.
>
KDL as backend for underconstrained motion specification
2011/2/17 Vincent Padois <vincent [dot] padois [..] ...>
> Hi,
>
> I have coded the ChainIkSolverVel_wdls in KDL and as a matter of fact have
> followed this thread with much interest.
>
We know, and are very grateful for that :)
>
> As for the distinction between tasks hierarchy (strict priorities) and
> weighting (soft priorities), it has to be noticed that when there is no
> solutions to the Inverse Velocity Kinematics problem, this solver provides a
> mean to favour some of the tasks dimensions (ie the task error will be
> minimized more efficiently in some direction than in others) and as a matter
> of fact, tasks weighting is already provided by this solver at the lowest
> level.
>
That's what we're currently using to set task priorities (weight != 0), as
well as for ignoring endpoint directions (weight == 0). We want to address
strict priorization of equality constraints by means of null-space
projections. We would also like to have solvers that accept custom
Jacobians, which among other things are a better alternative to setting
weight==0 for a task space direction (you invert a smaller Jacobian, only
what you need).
> As for which algorithm to use, the work of Baerlocher and Boulic is a very
> strong base to start from but I would suggest to have a look at these works
> that were recently published and that provide an effective way of extending
> Baerlocher and Boulic work and are also related to iTasc regarding
> constraints compatibility matters :
>
> Rubrecht, S. and Padois, V. and Bidaud, P. and de Broissia, M. (2010).
> Constraint Compliant Control for a Redundant Manipulator in a Cluttered
> Environment. In Proceedings of the 12th International Symposium on Advances
> in Robot Kinematics. Pages 367--376. Slovenia.
> http://www.isir.upmc.fr/files/2010ACTI1523.pdf
>
> Rubrecht, S. and Padois, V. and Bidaud, P. and De Broissia, M. (2010).
> Constraints Compliant Control: constraints compatibility and the displaced
> configuration approach. In Proceedings of the 2010 IEEE/RSJ International
> Conference on Intelligent Robots and Systems 2010 IEEE/RSJ International
> Conference on Intelligent Robots and Systems . Taipei, Taiwan.
> http://www.isir.upmc.fr/files/2010ACTI1590.pdf
>
I'm halfway done reading the above papers. Very hot and relevant topic (at
least for me). I would have loved to see your presentation at IROS 2010, I
don't know how I missed it. I was hunting for works in these lines. Anyway,
as I see it, a solver that can enforce strict priorities for a stack of
tasks subject to equality constraints is missing in KDL and by itself would
add value to the library. Further, it could serve as a building block that
broader-scoped efforts, such as your above mentioned work, or iTaSC, could
build on top of.
> We also have done some preliminary work on the comparison between strict
> and soft priorities in the dynamic control of humanoids using LQP solvers
> (related to the work of Kanoun) and I am available to discuss this topic if
> some of you are interested.
>
We're all ears. Maybe an executive summary to bring us up to speed on the
more relevant take-home points?.
>
> Thanks for reading and sorry if this message looks like cheap advertising
> of our work to some of you.
>
>
and thanks for bringing ideas to the discussion :)
Cheers,
Adolfo.
KDL as backend for underconstrained motion specification
On 18/02/2011 13:15, Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> 2011/2/17 Vincent Padois <vincent [dot] padois [..] ...
> <mailto:vincent [dot] padois [..] ...>>
>
> Hi,
>
> I have coded the ChainIkSolverVel_wdls in KDL and as a matter of
> fact have followed this thread with much interest.
>
>
> We know, and are very grateful for that :)
>
>
> As for the distinction between tasks hierarchy (strict priorities)
> and weighting (soft priorities), it has to be noticed that when
> there is no solutions to the Inverse Velocity Kinematics problem,
> this solver provides a mean to favour some of the tasks dimensions
> (ie the task error will be minimized more efficiently in some
> direction than in others) and as a matter of fact, tasks weighting
> is already provided by this solver at the lowest level.
>
>
> That's what we're currently using to set task priorities (weight !=
> 0), as well as for ignoring endpoint directions (weight == 0). We want
> to address strict priorization of equality constraints by means of
> null-space projections. We would also like to have solvers that accept
> custom Jacobians, which among other things are a better alternative to
> setting weight==0 for a task space direction (you invert a smaller
> Jacobian, only what you need).
I agree on the fact that strict prioritization is not strictly covered
by this solver even though in some specific cases the configuration
space weighting matrix can play the role of a projector on the Null
Space of the Jacobian. But this is probably not what is needed and the
implementation of a of higher level solver enforcing prescribed
priorities between tasks is what you must be looking for (reading your
next comment, it is indeed what you are looking for).
>
>
> As for which algorithm to use, the work of Baerlocher and Boulic
> is a very strong base to start from but I would suggest to have a
> look at these works that were recently published and that provide
> an effective way of extending Baerlocher and Boulic work and are
> also related to iTasc regarding constraints compatibility matters :
>
> Rubrecht, S. and Padois, V. and Bidaud, P. and de Broissia, M.
> (2010). Constraint Compliant Control for a Redundant Manipulator
> in a Cluttered Environment. In Proceedings of the 12th
> International Symposium on Advances in Robot Kinematics. Pages
> 367--376. Slovenia. http://www.isir.upmc.fr/files/2010ACTI1523.pdf
>
> Rubrecht, S. and Padois, V. and Bidaud, P. and De Broissia, M.
> (2010). Constraints Compliant Control: constraints compatibility
> and the displaced configuration approach. In Proceedings of the
> 2010 IEEE/RSJ International Conference on Intelligent Robots and
> Systems 2010 IEEE/RSJ International Conference on Intelligent
> Robots and Systems . Taipei, Taiwan.
> http://www.isir.upmc.fr/files/2010ACTI1590.pdf
>
>
> I'm halfway done reading the above papers. Very hot and relevant topic
> (at least for me). I would have loved to see your presentation at IROS
> 2010, I don't know how I missed it. I was hunting for works in these
> lines. Anyway, as I see it, a solver that can enforce strict
> priorities for a stack of tasks subject to equality constraints is
> missing in KDL and by itself would add value to the library. Further,
> it could serve as a building block that broader-scoped efforts, such
> as your above mentioned work, or iTaSC, could build on top of.
There is still some work to be done regarding inequality constraints and
we are working on this with one of my PhD student (Sébastien Rubrecht,
fisrt author of the papers I cited).
>
>
> We also have done some preliminary work on the comparison between
> strict and soft priorities in the dynamic control of humanoids
> using LQP solvers (related to the work of Kanoun) and I am
> available to discuss this topic if some of you are interested.
>
>
> We're all ears. Maybe an executive summary to bring us up to speed on
> the more relevant take-home points?.
Well I can point out one paper that we recently passed to ICRA 2011. I
still need to upload it somewhere so that you can access a preview
version of it. Will do soon.
> Thanks for reading and sorry if this message looks like cheap
> advertising of our work to some of you.
>
>
> and thanks for bringing ideas to the discussion :)
My pleasure.
Cheers,
Vincent
>
> Cheers,
>
> Adolfo.
>
>
KDL as backend for underconstrained motion specification
On 02/18/2011 01:15 PM, Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> 2011/2/17 Vincent Padois <vincent [dot] padois [..] ...
> <mailto:vincent [dot] padois [..] ...>>
>
> Hi,
>
> I have coded the ChainIkSolverVel_wdls in KDL and as a matter of
> fact have followed this thread with much interest.
>
>
> We know, and are very grateful for that :)
>
>
> As for the distinction between tasks hierarchy (strict priorities)
> and weighting (soft priorities), it has to be noticed that when
> there is no solutions to the Inverse Velocity Kinematics problem,
> this solver provides a mean to favour some of the tasks dimensions
> (ie the task error will be minimized more efficiently in some
> direction than in others) and as a matter of fact, tasks weighting
> is already provided by this solver at the lowest level.
>
>
> That's what we're currently using to set task priorities (weight != 0),
> as well as for ignoring endpoint directions (weight == 0). We want to
> address strict priorization of equality constraints by means of
> null-space projections. We would also like to have solvers that accept
> custom Jacobians, which among other things are a better alternative to
> setting weight==0 for a task space direction (you invert a smaller
> Jacobian, only what you need).
>
>
> As for which algorithm to use, the work of Baerlocher and Boulic is
> a very strong base to start from but I would suggest to have a look
> at these works that were recently published and that provide an
> effective way of extending Baerlocher and Boulic work and are also
> related to iTasc regarding constraints compatibility matters :
>
> Rubrecht, S. and Padois, V. and Bidaud, P. and de Broissia, M.
> (2010). Constraint Compliant Control for a Redundant Manipulator in
> a Cluttered Environment. In Proceedings of the 12th International
> Symposium on Advances in Robot Kinematics. Pages 367--376. Slovenia.
> http://www.isir.upmc.fr/files/2010ACTI1523.pdf
>
> Rubrecht, S. and Padois, V. and Bidaud, P. and De Broissia, M.
> (2010). Constraints Compliant Control: constraints compatibility and
> the displaced configuration approach. In Proceedings of the 2010
> IEEE/RSJ International Conference on Intelligent Robots and Systems
> 2010 IEEE/RSJ International Conference on Intelligent Robots and
> Systems . Taipei, Taiwan. http://www.isir.upmc.fr/files/2010ACTI1590.pdf
>
>
> I'm halfway done reading the above papers. Very hot and relevant topic
> (at least for me). I would have loved to see your presentation at IROS
> 2010, I don't know how I missed it. I was hunting for works in these
> lines. Anyway, as I see it, a solver that can enforce strict priorities
> for a stack of tasks subject to equality constraints is missing in KDL
> and by itself would add value to the library. Further, it could serve
> as a building block that broader-scoped efforts, such as your above
> mentioned work, or iTaSC, could build on top of.
Is there any code available? Eg. that you used for the examples in the
paper?
>
>
> We also have done some preliminary work on the comparison between
> strict and soft priorities in the dynamic control of humanoids using
> LQP solvers (related to the work of Kanoun) and I am available to
> discuss this topic if some of you are interested.
>
>
> We're all ears. Maybe an executive summary to bring us up to speed on
> the more relevant take-home points?.
>
>
> Thanks for reading and sorry if this message looks like cheap
> advertising of our work to some of you.
>
>
> and thanks for bringing ideas to the discussion :)
>
> Cheers,
>
> Adolfo.
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only
> for the individual or entity to whom they are addressed. If you are not
> the intended recipient, you are hereby notified that any disclosure,
> copying, distribution or use of this e-mail and/or accompanying
> document(s) is strictly prohibited. If you have received this e-mail in
> error, please immediately notify the sender at the above e-mail address.
KDL as backend for underconstrained motion specification
On 18/02/2011 17:35, Dominick Vanthienen wrote:
>
>
>
> On 02/18/2011 01:15 PM, Adolfo Rodríguez Tsouroukdissian wrote:
>>
>> 2011/2/17 Vincent Padois<vincent [dot] padois [..] ...
>> <mailto:vincent [dot] padois [..] ...>>
>>
>> Hi,
>>
>> I have coded the ChainIkSolverVel_wdls in KDL and as a matter of
>> fact have followed this thread with much interest.
>>
>>
>> We know, and are very grateful for that :)
>>
>>
>> As for the distinction between tasks hierarchy (strict priorities)
>> and weighting (soft priorities), it has to be noticed that when
>> there is no solutions to the Inverse Velocity Kinematics problem,
>> this solver provides a mean to favour some of the tasks dimensions
>> (ie the task error will be minimized more efficiently in some
>> direction than in others) and as a matter of fact, tasks weighting
>> is already provided by this solver at the lowest level.
>>
>>
>> That's what we're currently using to set task priorities (weight != 0),
>> as well as for ignoring endpoint directions (weight == 0). We want to
>> address strict priorization of equality constraints by means of
>> null-space projections. We would also like to have solvers that accept
>> custom Jacobians, which among other things are a better alternative to
>> setting weight==0 for a task space direction (you invert a smaller
>> Jacobian, only what you need).
>>
>>
>> As for which algorithm to use, the work of Baerlocher and Boulic is
>> a very strong base to start from but I would suggest to have a look
>> at these works that were recently published and that provide an
>> effective way of extending Baerlocher and Boulic work and are also
>> related to iTasc regarding constraints compatibility matters :
>>
>> Rubrecht, S. and Padois, V. and Bidaud, P. and de Broissia, M.
>> (2010). Constraint Compliant Control for a Redundant Manipulator in
>> a Cluttered Environment. In Proceedings of the 12th International
>> Symposium on Advances in Robot Kinematics. Pages 367--376. Slovenia.
>> http://www.isir.upmc.fr/files/2010ACTI1523.pdf
>>
>> Rubrecht, S. and Padois, V. and Bidaud, P. and De Broissia, M.
>> (2010). Constraints Compliant Control: constraints compatibility and
>> the displaced configuration approach. In Proceedings of the 2010
>> IEEE/RSJ International Conference on Intelligent Robots and Systems
>> 2010 IEEE/RSJ International Conference on Intelligent Robots and
>> Systems . Taipei, Taiwan. http://www.isir.upmc.fr/files/2010ACTI1590.pdf
>>
>>
>> I'm halfway done reading the above papers. Very hot and relevant topic
>> (at least for me). I would have loved to see your presentation at IROS
>> 2010, I don't know how I missed it. I was hunting for works in these
>> lines. Anyway, as I see it, a solver that can enforce strict priorities
>> for a stack of tasks subject to equality constraints is missing in KDL
>> and by itself would add value to the library. Further, it could serve
>> as a building block that broader-scoped efforts, such as your above
>> mentioned work, or iTaSC, could build on top of.
> Is there any code available? Eg. that you used for the examples in the
> paper?
We have some KDL based code which we use in most of our work but I need
to check whether it can be posted as is (it may be too application
specific in some places). Will do and let you know.
>>
>> We also have done some preliminary work on the comparison between
>> strict and soft priorities in the dynamic control of humanoids using
>> LQP solvers (related to the work of Kanoun) and I am available to
>> discuss this topic if some of you are interested.
>>
>>
>> We're all ears. Maybe an executive summary to bring us up to speed on
>> the more relevant take-home points?.
>>
>>
>> Thanks for reading and sorry if this message looks like cheap
>> advertising of our work to some of you.
>>
>>
>> and thanks for bringing ideas to the discussion :)
>>
>> Cheers,
>>
>> Adolfo.
>>
>>
>> --
>> Adolfo Rodríguez Tsouroukdissian
>>
>> Robotics engineer
>> PAL ROBOTICS S.L
>> http://www.pal-robotics.com
>> Tel. +34.93.414.53.47
>> Fax.+34.93.209.11.09
>>
>> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
>> contain confidential information which is privileged and intended only
>> for the individual or entity to whom they are addressed. If you are not
>> the intended recipient, you are hereby notified that any disclosure,
>> copying, distribution or use of this e-mail and/or accompanying
>> document(s) is strictly prohibited. If you have received this e-mail in
>> error, please immediately notify the sender at the above e-mail address.
KDL as backend for underconstrained motion specification
On Wed, Feb 16, 2011 at 6:55 PM, Dominick Vanthienen <
dominick [dot] vanthienen [..] ...> wrote:
>
> Hi,
>
>
>
> On 02/16/2011 03:12 PM, Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> 2011/2/16 Ruben Smits<ruben [dot] smits [..] ...
> On Wednesday 16 February 2011 13:32:23 Adolfo Rodríguez Tsouroukdissian
> wrote:
>
> > Hello devs, especially the KDL-inclined ones :)
> >
> > We have a colleague in our group that is currently using KDL's IK
> tree
> > solvers, and the results so far have been very satisfactory. In the
> coming
> > weeks, we will have the need for solvers that build on top of these
> tree
> > solvers, the immediate use case being task priorization by null-space
> > projection. Other use cases may follow. Before starting a KDL-based
> > implementation from scratch, I'd like to ask whether someone else is
> (or
> > has been) working on this, in order not to duplicate efforts. In
> > particular, I would like to ask about the status of the iTaSC
> > implementation, which was referred to in this list on April 2010 [1].
> It
> > would be preferable to build on, and contribute to efforts that
> already
> > have some momentum.
> Our current iTaSC implementation is still highly coupled with Orocos/RTT
> as
> the basic building blocks are full-fledged components, not classes. They
> use
> KDL classes internally though.
>
> A colleague of mine is working on two things at the moment:
>
> I'm working on this at the moment
>
Hello Nick. Great to know you're also working on this!
>
> * adding priorization to the current implementation
>
> We share an interest and we have someone willing to work on it. Sounds
> like we could make some progress here. Note: weight-based priorization is
> also interesting, but not on our plate at the moment.
>
> I would like to use both, weights (on constraints in task space and
> joint space) and priorization (primary constraints, secondary
> constraints...)
> I'm implementing an algorithm based on the proposed algorithm by
> P. Baerlocher, R. Boulic: “Task-priority formulations for the kinematic
> control of highly redundant articulated structures,” Proc. IEEE IROS
> 98, pp 323329 (1998)
>
This is pretty much what we're aiming at.
>
> (without weights)
> which is an improvement of :
>
> B. Siciliano, J.-J.E. Slotine: “A general framework for managing
> multiple tasks in highly redundant robotic systems,” Proc. IEEE ICRA
> pp. 12111216 (1991)
>
> An interesting paper is of:
> Oussama Kanoun, Prioritizing linear equality and inequality systems:
> application to local
> motion planning for redundant robots, IEEE ICRA 2009
> They have some code available in the
> equality constraints:
> http://softs.laas.fr/openrobots/robotpkg/path/hpp-gik/index.html =>LGPL
> equality + inequality constraints?!
> http://softs.laas.fr/openrobots/robotpkg/path/hpp-hik/index.html =>
> closed source
>
> The implementation of last paper, for equality and inequality
> constraints is certainly of interest!
> But out of the scope of my project right now
> Maybe interesting for someone else to implement?
>
General (or linear) inequality constraints are out of our current scope as
well.
> * adding acceleration resolved solvers (currently we only have velocity
> resolved solvers)
>
> We also share an interest here, but unfortunately we won't have anyone
> working on that in the foreseeable future :(
>
>
> This is still WIP, far from usable in production systems, but if you
> feel
> adventurous, we can share the development load. The drawback is that we
> are
> still bound to the Orocos components and are not working on a KDL only
> solution yet.
>
> Orocos integration is a plus, but we would prefer to have a standalone
> KDL solver for our particular use case. At any rate, it wouldn't hurt to
> lurk into the existing implementation, if it is publicly available.
> Otherwise, we'll probably bring design discussions over to the list. We are
> about to plan a work package on this, and we are scouting for prior art
> (implementation-wise).
>
> It can be interesting to make a KDL implementation of it, in the end it
> is a function you can call
> The current solver that we use (without priorities) is actually about
> the same as ChainIkSolverVel_wdls, except that we give the "solver"
> already the jacobians, in stead that he has to calculate them himself
>
Why do you provide the Jacobians to the solver?, so you can have a single
Jacobian solver instance that serves all solvers, and save computations?.
We've noticed that the current tree velocity IK solver hardcodes the joint
to Jacobian solver. We might be interested in changing this, food for
thought.
> (It could be rewritten to let this function:1) calculate the jacobians
> 2) call a function that does what abovementionned function does, but
> with jacobians as parameters
> solver = ChainIkSolverVel_wdls(chain)
> solver.CartToJnt(const JntArray& q_in, const Twist& v_in, JntArray&
> qdot_out)
> which calls on his turn
> solver2 = ChainIkSolverVel_wdls_with_jacobians()
> solver2.CartToJnt(const Jacobian& J_in, const Twist& v_in, JntArray&
> qdot_out)
>
This signature of CartToJoint is not compatible with KDL's velocity IK
interface, or is it?
> => this second solver can be used in iTaSC
> )
>
What does that mean? what does a solver need to be iTaSC-friendly, are
existing KDL solvers iTaSC-friendly?.
> So I think a solver with priorities belongs somewhere here:
> *With a name like: ChainIkSolverVel_wdls_priorities() ?
> *and then call:
> solver3.ChainIkSolverVel_wdls_priorities()
> solver3.CartToJnt(const std::vector<Jacobian>& J_in, const Twist& v_in,
> JntArray& qdot_out)
> (this is the most usefull for my case, you can do then something similar
> to explained above)
>
Solver naming is always a compromise between brevity and explicitness. Do
you think that *_priorities is descriptive enough, or should the
priorization scheme be more explicit (in the name)?.
Also, since we're mostly interested in tree solvers, we'll not work on the
chain variants, which are anyway a particular case of trees. Wrt the API, I
started yesterday evening to draft an API for the solvers. I'll post it here
or in the wiki soon. It wil probably consist of two solvers:
- One higher-level solver where the user specifies the priority
levels/endpoints.
- One iso-priority solver that is very close to the existing
TreeIkSolverVel_wdls, but takes into account higher-priority tasks.
That's all for now. Chers,
Adolfo
>
> Thanks for the infos so far. We appreciate greatly the community's
> interest on the topic.
>
> Best,
>
> Adolfo.
>
>
>
>
> > TIA,
> >
> > Adolfo.
> -- Ruben
>
> Nick
>
> > [1]
> >
> http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
> >
> > --
> > Adolfo Rodríguez Tsouroukdissian, Ph. D.
> >
> > Robotics engineer
> > PAL ROBOTICS S.L
> > http://www.pal-robotics.com
> > Tel. +34.93.414.53.47
> > Fax.+34.93.209.11.09
> >
> > CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s)
> may
> > contain confidential information which is privileged and intended
> only for
> > the individual or entity to whom they are addressed. If you are not
> the
> > intended recipient, you are hereby notified that any disclosure,
> copying,
> > distribution or use of this e-mail and/or accompanying document(s) is
> > strictly prohibited. If you have received this e-mail in error,
> please
> > immediately notify the sender at the above e-mail address.<http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev>
>
KDL as backend for underconstrained motion specification
On 02/17/2011 11:11 AM, Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> On Wed, Feb 16, 2011 at 6:55 PM, Dominick Vanthienen
> <dominick [dot] vanthienen [..] ...
> <mailto:dominick [dot] vanthienen [..] ...>> wrote:
>
>
> Hi,
>
>
>
> On 02/16/2011 03:12 PM, Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> 2011/2/16 Ruben Smits<ruben [dot] smits [..] ...
> <mailto:ruben [dot] smits [..] ...><mailto:ruben [dot] smits [..] ...
> <mailto:ruben [dot] smits [..] ...>>>
> On Wednesday 16 February 2011 13:32:23 Adolfo Rodríguez
> Tsouroukdissian wrote:
>
> > Hello devs, especially the KDL-inclined ones :)
> >
> > We have a colleague in our group that is currently using
> KDL's IK tree
> > solvers, and the results so far have been very satisfactory.
> In the coming
> > weeks, we will have the need for solvers that build on top
> of these tree
> > solvers, the immediate use case being task priorization by
> null-space
> > projection. Other use cases may follow. Before starting a
> KDL-based
> > implementation from scratch, I'd like to ask whether someone
> else is (or
> > has been) working on this, in order not to duplicate efforts. In
> > particular, I would like to ask about the status of the iTaSC
> > implementation, which was referred to in this list on April
> 2010 [1]. It
> > would be preferable to build on, and contribute to efforts
> that already
> > have some momentum.
> Our current iTaSC implementation is still highly coupled with
> Orocos/RTT as
> the basic building blocks are full-fledged components, not
> classes. They use
> KDL classes internally though.
>
> A colleague of mine is working on two things at the moment:
>
> I'm working on this at the moment
>
>
> Hello Nick. Great to know you're also working on this!
>
>
> * adding priorization to the current implementation
>
> We share an interest and we have someone willing to work on it.
> Sounds like we could make some progress here. Note: weight-based
> priorization is also interesting, but not on our plate at the moment.
>
> I would like to use both, weights (on constraints in task space and
> joint space) and priorization (primary constraints, secondary
> constraints...)
> I'm implementing an algorithm based on the proposed algorithm by
> P. Baerlocher, R. Boulic: “Task-priority formulations for the
> kinematic
> control of highly redundant articulated structures,” Proc. IEEE IROS
> 98, pp 323329 (1998)
>
>
> This is pretty much what we're aiming at.
>
>
> (without weights)
> which is an improvement of :
>
> B. Siciliano, J.-J.E. Slotine: “A general framework for managing
> multiple tasks in highly redundant robotic systems,” Proc. IEEE ICRA
> pp. 12111216 (1991)
>
> An interesting paper is of:
> Oussama Kanoun, Prioritizing linear equality and inequality systems:
> application to local
> motion planning for redundant robots, IEEE ICRA 2009
> They have some code available in the
> equality constraints:
> http://softs.laas.fr/openrobots/robotpkg/path/hpp-gik/index.html
> =>LGPL
> equality + inequality constraints?!
> http://softs.laas.fr/openrobots/robotpkg/path/hpp-hik/index.html =>
> closed source
>
> The implementation of last paper, for equality and inequality
> constraints is certainly of interest!
> But out of the scope of my project right now
> Maybe interesting for someone else to implement?
>
>
> General (or linear) inequality constraints are out of our current
> scope as well.
>
>
> * adding acceleration resolved solvers (currently we only have
> velocity
> resolved solvers)
>
> We also share an interest here, but unfortunately we won't have
> anyone working on that in the foreseeable future :(
>
>
> This is still WIP, far from usable in production systems, but
> if you feel
> adventurous, we can share the development load. The drawback is
> that we are
> still bound to the Orocos components and are not working on a
> KDL only
> solution yet.
>
> Orocos integration is a plus, but we would prefer to have a
> standalone KDL solver for our particular use case. At any rate, it
> wouldn't hurt to lurk into the existing implementation, if it is
> publicly available. Otherwise, we'll probably bring design
> discussions over to the list. We are about to plan a work package
> on this, and we are scouting for prior art (implementation-wise).
>
> It can be interesting to make a KDL implementation of it, in the
> end it
> is a function you can call
> The current solver that we use (without priorities) is actually about
> the same as ChainIkSolverVel_wdls, except that we give the "solver"
> already the jacobians, in stead that he has to calculate them himself
>
>
> Why do you provide the Jacobians to the solver?, so you can have a
> single Jacobian solver instance that serves all solvers, and save
> computations?. We've noticed that the current tree velocity IK solver
> hardcodes the joint to Jacobian solver. We might be interested in
> changing this, food for thought.
Because I've got the jacobians already (calculated in another component)
>
> (It could be rewritten to let this function:1) calculate the jacobians
> 2) call a function that does what abovementionned function does, but
> with jacobians as parameters
> solver = ChainIkSolverVel_wdls(chain)
> solver.CartToJnt(const JntArray& q_in, const Twist& v_in, JntArray&
> qdot_out)
> which calls on his turn
> solver2 = ChainIkSolverVel_wdls_with_jacobians()
> solver2.CartToJnt(const Jacobian& J_in, const Twist& v_in, JntArray&
> qdot_out)
>
>
> This signature of CartToJoint is not compatible with KDL's velocity IK
> interface, or is it?
>
> => this second solver can be used in iTaSC
> )
>
>
> What does that mean? what does a solver need to be iTaSC-friendly, are
> existing KDL solvers iTaSC-friendly?.
>
> So I think a solver with priorities belongs somewhere here:
> *With a name like: ChainIkSolverVel_wdls_priorities() ?
> *and then call:
> solver3.ChainIkSolverVel_wdls_priorities()
> solver3.CartToJnt(const std::vector<Jacobian>& J_in, const Twist&
> v_in,
> JntArray& qdot_out)
> (this is the most usefull for my case, you can do then something
> similar
> to explained above)
>
>
> Solver naming is always a compromise between brevity and explicitness.
> Do you think that *_priorities is descriptive enough, or should the
> priorization scheme be more explicit (in the name)?.
> Also, since we're mostly interested in tree solvers, we'll not work on
> the chain variants, which are anyway a particular case of trees. Wrt
> the API, I started yesterday evening to draft an API for the solvers.
> I'll post it here or in the wiki soon. It wil probably consist of two
> solvers:
> - One higher-level solver where the user specifies the priority
> levels/endpoints.
> - One iso-priority solver that is very close to the existing
> TreeIkSolverVel_wdls, but takes into account higher-priority tasks.
Actually,
the solver with matrices and vectors as input (per priority), and a
vector as output, (as described in the papers)
is a "general" matrix operation that actually should resort under a
matrix library...
(At the moment, I will implement it in a component (so I can continue)
and when we find the right place and name for it (through this
discussion), someone can put it in a solver
or solvers (probably something like a general solver (the one that
belongs in a matrix library) and then specific solvers that call this
one for chains, trees, ...))
Nick
>
> That's all for now. Chers,
>
> Adolfo
>
>
>
>
>
> Thanks for the infos so far. We appreciate greatly the
> community's interest on the topic.
>
> Best,
>
> Adolfo.
>
>
>
>
> > TIA,
> >
> > Adolfo.
> -- Ruben
>
> Nick
>
> > [1]
> >
> http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
> >
> > --
> > Adolfo Rodríguez Tsouroukdissian, Ph. D.
> >
> > Robotics engineer
> > PAL ROBOTICS S.L
> > http://www.pal-robotics.com
> > Tel. +34.93.414.53.47
> > Fax.+34.93.209.11.09
> >
> > CONFIDENTIALITY NOTICE: This e-mail and the accompanying
> document(s) may
> > contain confidential information which is privileged and
> intended only for
> > the individual or entity to whom they are addressed. If you
> are not the
> > intended recipient, you are hereby notified that any
> disclosure, copying,
> > distribution or use of this e-mail and/or accompanying
> document(s) is
> > strictly prohibited. If you have received this e-mail in
> error, please
> > immediately notify the sender at the above e-mail address.
>
>
KDL as backend for underconstrained motion specification
> > Why do you provide the Jacobians to the solver?, so you can have a
> > single Jacobian solver instance that serves all solvers, and save
> > computations?. We've noticed that the current tree velocity IK solver
> > hardcodes the joint to Jacobian solver. We might be interested in
> > changing this, food for thought.
> Because I've got the jacobians already (calculated in another component)
>
This would enable us to better specify endpoints. The current velocity IK
tree solver only deals with 6-dimensional endpoints. If you provide
Jacobians from the outside, you could add endpoints with custom Jacobians (<
6dof, single joints, etc.). This is actually what we have in our in-house
velocity IK solver that a colleague developed, so reaching feature-parity in
this respect would be nice.
@Nick, does the iTaSC implementation allow for adding/removing new tasks
dynamically?
KDL as backend for underconstrained motion specification
On 02/18/2011 12:46 PM, Adolfo Rodríguez Tsouroukdissian wrote:
>
> > Why do you provide the Jacobians to the solver?, so you can have a
> > single Jacobian solver instance that serves all solvers, and save
> > computations?. We've noticed that the current tree velocity IK
> solver
> > hardcodes the joint to Jacobian solver. We might be interested in
> > changing this, food for thought.
> Because I've got the jacobians already (calculated in another
> component)
>
>
> This would enable us to better specify endpoints. The current velocity
> IK tree solver only deals with 6-dimensional endpoints. If you provide
> Jacobians from the outside, you could add endpoints with custom
> Jacobians (< 6dof, single joints, etc.). This is actually what we
> have in our in-house velocity IK solver that a colleague developed, so
> reaching feature-parity in this respect would be nice.
>
> @Nick, does the iTaSC implementation allow for adding/removing new
> tasks dynamically?
in it's current state: no (you'll have to call the configure hook of the
Scene component again)
in the future: possible yes (after migrating all program configuration
from the Scene to a supervisor/configurator)
>
KDL as backend for underconstrained motion specification
On Wed, 16 Feb 2011, Adolfo Rodríguez Tsouroukdissian wrote:
> Hello devs, especially the KDL-inclined ones :)
>
> We have a colleague in our group that is currently using KDL's IK tree
> solvers, and the results so far have been very satisfactory. In the
> coming weeks, we will have the need for solvers that build on top of
> these tree solvers, the immediate use case being task priorization by
> null-space projection. Other use cases may follow. Before starting a
> KDL-based implementation from scratch, I'd like to ask whether someone
> else is (or has been) working on this, in order not to duplicate efforts.
One of the KUL phds is currently working on such stuff :-) (He is listening
on this mailing list.)
> In particular, I would like to ask about the status of the iTaSC
> implementation, which was referred to in this list on April 2010 [1]. It
> would be preferable to build on, and contribute to efforts that already
> have some momentum.
Herman
> TIA,
>
> Adolfo.
>
> [1] http://www.orocos.org/forum/orocos/orocos-users/kdl-decoupling-ik-problem
>
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.
>