# 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:

>
> ruben [dot] smits [..] ...>>

> 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.

>