Hi,

I've written a IK position solver in the course of my work and I'm hoping

that it might be useful to others.

The solver basically combines uses WDLS (Weighted pseudo inverse with

Damped Least-Square) velocity solver to do gradient descent while using the

joint space weights to respect joint limits. It's worked beautifully to in

our IK setup where the NR_JL (Newton-Raphson Joint Limit) had been failing

for us.

I'd love to submit it if new solvers are welcome, however as I'm somewhat

new to this sub-discipline, I'm not certain it would meet the requirements

be considered for inclusion.

A few questions:

* Are new solvers welcome?

* What are the requirements (needs unit test? coding standard?

mathematical proof? etc)?

I've received the necessary permission from my company to submit, but I'm

not sure how much time I can spend on building unit tests, polishing etc.

Thoughts?

Andy

## New solvers welcome?

Hi Andy,

On Wed, Mar 21, 2012 at 5:16 PM, Andy Somerville

<andy [dot] somerville [..] ...> wrote:

> Hi,

>

> I've written a IK position solver in the course of my work and I'm hoping

> that it might be useful to others.

>

> The solver basically combines uses WDLS (Weighted pseudo inverse with Damped

> Least-Square) velocity solver to do gradient descent while using the joint

> space weights to respect joint limits. It's worked beautifully to in our IK

> setup where the NR_JL (Newton-Raphson Joint Limit) had been failing for us.

>

> I'd love to submit it if new solvers are welcome, however as I'm somewhat

> new to this sub-discipline, I'm not certain it would meet the requirements

> be considered for inclusion.

>

> A few questions:

>

> * Are new solvers welcome?

New solvers are always welcome, very welcome. And I would love to

include yours as well.

> * What are the requirements (needs unit test? coding standard?

> mathematical proof? etc)?

* It should at least not break the build of KDL ;)

* It should be realtime usable, this means that there shouldn't be any

memory allocation in the functions that are used in the update cycle

(CartToJnt), and deterministic in time wrt loops.

* A unit test is always welcome, but it is not a show-stopper, as long

as it is missing we can mark the solver as experimental. The unit test

should test two things: see if we can successfully create the solver

and call its functions without crashing and secondly prove its

internal functionality, usually we do this with a forward - inverse

recursion, which means you start from a given nominal cartesian space

input, using your solver you calculate the joint space output. Than

you use the joint space output in a forward solver to verify if it

results in the desired cartesian space motion. You can check the

existing unit tests to see how it works.

> I've received the necessary permission from my company to submit, but I'm

> not sure how much time I can spend on building unit tests, polishing etc.

The easiest to proceed is that you open a bug report and attach a

patch against the master branch. Make sure you include your name and

company in the copyright statement and a license header. Than we can

start from there to see how much polishing is necessary.

> Thoughts?

>

> Andy

Ruben

>

>

> --

> Orocos-Dev mailing list

> Orocos-Dev [..] ...

> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

>

## New solvers welcome?

Ruben

On Thu, Mar 22, 2012 at 5:27 AM, Ruben Smits

<ruben [dot] smits [..] ...> wrote:

>

> > A few questions:

> >

> > * Are new solvers welcome?

>

> New solvers are always welcome, very welcome. And I would love to

> include yours as well.

Great!

>

> > * What are the requirements (needs unit test? coding standard?

> > mathematical proof? etc)?

>

> * It should at least not break the build of KDL ;)

That's a reasonable requirement : )

> * It should be realtime usable, this means that there shouldn't be any

> memory allocation in the functions that are used in the update cycle

> (CartToJnt), and deterministic in time wrt loops.

I tried to do this, but it's possible I may have missed something

since I've not had much experience worrying about what does and does

not do dynamic allocation internally.

>

> * A unit test is always welcome, but it is not a show-stopper, as long

> as it is missing we can mark the solver as experimental. The unit test

> should test two things: see if we can successfully create the solver

> and call its functions without crashing and secondly prove its

> internal functionality, usually we do this with a forward - inverse

> recursion, which means you start from a given nominal cartesian space

> input, using your solver you calculate the joint space output. Than

> you use the joint space output in a forward solver to verify if it

> results in the desired cartesian space motion. You can check the

> existing unit tests to see how it works.

I'll take a look at the unit tests, I might be able to easily create a

new one with little modification from a copy paste. Otherwise It'll

probably have to wait until we have some down time.

>

>

> > I've received the necessary permission from my company to submit, but

> > I'm

> > not sure how much time I can spend on building unit tests, polishing

> > etc.

>

> The easiest to proceed is that you open a bug report and attach a

> patch against the master branch. Make sure you include your name and

> company in the copyright statement and a license header. Than we can

> start from there to see how much polishing is necessary.

I replied to Herman's comment with code, but I'll put subsequent code

in a bug report.

## New solvers welcome?

On 03/22/2012 10:27 AM, Ruben Smits wrote:

> Hi Andy,

>

> On Wed, Mar 21, 2012 at 5:16 PM, Andy Somerville

> <andy [dot] somerville [..] ...> wrote:

>> Hi,

>>

>> I've written a IK position solver in the course of my work and I'm hoping

>> that it might be useful to others.

>>

>> The solver basically combines uses WDLS (Weighted pseudo inverse with Damped

>> Least-Square) velocity solver to do gradient descent while using the joint

>> space weights to respect joint limits. It's worked beautifully to in our IK

>> setup where the NR_JL (Newton-Raphson Joint Limit) had been failing for us.

>>

iTaSC contains also a component doing a similar thing, including priorities next to the WDLS

it isn't integrated in KDL anyway, but it should (?) at some point

nick

>> I'd love to submit it if new solvers are welcome, however as I'm somewhat

>> new to this sub-discipline, I'm not certain it would meet the requirements

>> be considered for inclusion.

>>

>> A few questions:

>>

>> * Are new solvers welcome?

>

> New solvers are always welcome, very welcome. And I would love to

> include yours as well.

>

>> * What are the requirements (needs unit test? coding standard?

>> mathematical proof? etc)?

>

> * It should at least not break the build of KDL ;)

> * It should be realtime usable, this means that there shouldn't be any

> memory allocation in the functions that are used in the update cycle

> (CartToJnt), and deterministic in time wrt loops.

>

> * A unit test is always welcome, but it is not a show-stopper, as long

> as it is missing we can mark the solver as experimental. The unit test

> should test two things: see if we can successfully create the solver

> and call its functions without crashing and secondly prove its

> internal functionality, usually we do this with a forward - inverse

> recursion, which means you start from a given nominal cartesian space

> input, using your solver you calculate the joint space output. Than

> you use the joint space output in a forward solver to verify if it

> results in the desired cartesian space motion. You can check the

> existing unit tests to see how it works.

>

>

>> I've received the necessary permission from my company to submit, but I'm

>> not sure how much time I can spend on building unit tests, polishing etc.

>

> The easiest to proceed is that you open a bug report and attach a

> patch against the master branch. Make sure you include your name and

> company in the copyright statement and a license header. Than we can

> start from there to see how much polishing is necessary.

>

>> Thoughts?

>>

>> Andy

>

> Ruben

>

>>

>>

>> --

>> Orocos-Dev mailing list

>> Orocos-Dev [..] ...

>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

>>

>

>

>

## New solvers welcome?

On Thu, 22 Mar 2012, Dominick Vanthienen wrote:

>

>

> On 03/22/2012 10:27 AM, Ruben Smits wrote:

>> Hi Andy,

>>

>> On Wed, Mar 21, 2012 at 5:16 PM, Andy Somerville

>> <andy [dot] somerville [..] ...> wrote:

>>> Hi,

>>>

>>> I've written a IK position solver in the course of my work and I'm hoping

>>> that it might be useful to others.

>>>

>>> The solver basically combines uses WDLS (Weighted pseudo inverse with Damped

>>> Least-Square) velocity solver to do gradient descent while using the joint

>>> space weights to respect joint limits. It's worked beautifully to in our IK

>>> setup where the NR_JL (Newton-Raphson Joint Limit) had been failing for us.

>>>

> iTaSC contains also a component doing a similar thing, including priorities next to the WDLS

> it isn't integrated in KDL anyway, but it should (?) at some point

The other way around makes more sense :-) The "i" in iTaSC stands for

"integration", so the iTaSC component is the right place to integrate

things from KDL and other libraries, and not the other way around.

So, this corroborates the remark I made in my answer: people tend to put

functionalities inside "kinematics solvers" that basically belong somewhere

else. KDL is about kinematics and dynamics, that is, how to transform

mechanical properties from joint space to Cartesian space and back. It

should _not_ start doing control, configuration, planning, task

optimization,... I repeat: they should _not_ start doing configuration,

planning, task optimization,... Keep libraries lean and mean, please; our

maintainers will be grateful :-)

> nick

Herman

>>> I'd love to submit it if new solvers are welcome, however as I'm somewhat

>>> new to this sub-discipline, I'm not certain it would meet the requirements

>>> be considered for inclusion.

>>>

>>> A few questions:

>>>

>>> * Are new solvers welcome?

>>

>> New solvers are always welcome, very welcome. And I would love to

>> include yours as well.

>>

>>> * What are the requirements (needs unit test? coding standard?

>>> mathematical proof? etc)?

>>

>> * It should at least not break the build of KDL ;)

>> * It should be realtime usable, this means that there shouldn't be any

>> memory allocation in the functions that are used in the update cycle

>> (CartToJnt), and deterministic in time wrt loops.

>>

>> * A unit test is always welcome, but it is not a show-stopper, as long

>> as it is missing we can mark the solver as experimental. The unit test

>> should test two things: see if we can successfully create the solver

>> and call its functions without crashing and secondly prove its

>> internal functionality, usually we do this with a forward - inverse

>> recursion, which means you start from a given nominal cartesian space

>> input, using your solver you calculate the joint space output. Than

>> you use the joint space output in a forward solver to verify if it

>> results in the desired cartesian space motion. You can check the

>> existing unit tests to see how it works.

>>

>>

>>> I've received the necessary permission from my company to submit, but I'm

>>> not sure how much time I can spend on building unit tests, polishing etc.

>>

>> The easiest to proceed is that you open a bug report and attach a

>> patch against the master branch. Make sure you include your name and

>> company in the copyright statement and a license header. Than we can

>> start from there to see how much polishing is necessary.

>>

>>> Thoughts?

>>>

>>> Andy

>>

>> Ruben

>>

>>>

>>>

>>> --

>>> Orocos-Dev mailing list

>>> Orocos-Dev [..] ...

>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

>>>

>>

>>

>>

## New solvers welcome?

On Wed, 21 Mar 2012, Andy Somerville wrote:

> Hi,

> I've written a IK position solver in the course of my work and I'm hoping that it might be

> useful to others.

>

> The solver basically combines uses WDLS (Weighted pseudo inverse with Damped Least-Square)

> velocity solver to do gradient descent while using the joint space weights to respect joint

> limits. It's worked beautifully to in our IK setup where the NR_JL (Newton-Raphson Joint Limit)

> had been failing for us.

>

> I'd love to submit it if new solvers are welcome, however as I'm somewhat new to this

> sub-discipline, I'm not certain it would meet the requirements be considered for inclusion.

>

> A few questions:

>

> * Are new solvers welcome?

Of course! But as was mentioned before on the mailinglist already a (very

few) times, we are thinking about redesigning how solvers are made: from an

"OO" design to a "data flow" design. The reason is that each different

solver brings in a slightly new API while cutting and pasting 90% of a

previous solver's code, and this leads to "library rotting: lots of method

call APIs that are most often serving only one use case well (that of the

developer) while compromising maintainability and optimality for other use

cases.

Anyway, I would welcome a discussion about your design on orocos-dev. And

no decisions have already been taken to indeed proceed in the "new

direction" mentioned above.

> * What are the requirements (needs unit test? coding standard? mathematical proof? etc)?

>

> I've received the necessary permission from my company to submit, but I'm not sure how much time

> I can spend on building unit tests, polishing etc.

>

> Thoughts?

>

> Andy

Thanks!!!

Herman

## New solvers welcome?

On Thu, Mar 22, 2012 at 1:12 AM, Herman Bruyninckx <

Herman [dot] Bruyninckx [..] ...> wrote:

>

> On Wed, 21 Mar 2012, Andy Somerville wrote:

>

>> Hi,

>> I've written a IK position solver in the course of my work and I'm hoping

>> that it might be

>> useful to others.

>

> Anyway, I would welcome a discussion about your design on orocos-dev. And

> no decisions have already been taken to indeed proceed in the "new

> direction" mentioned above.

>

The algorithm is probably not particularly novel but I think the two

important

parts are:

* Scale all velocities to be between -1 and 1 by dividing the max Joint

velocity

* Use small steps and cut them in half any time it sees a solution farther

than

the last

* If joint limits are violated, abandon a solution and try again next round

(rather than keeping that solution but pulling in the one joint to be

inside the limits)

rough algorithm:

loop over iterations

check if solution is close enough

if yes

return true

use velocity solver to get joint motion proportions for motion toward goal

find abs-max-joint-velocity and divide velocity solver solution by that

to scale between -1 and 1

multiply by predetermined step size factor (perhaps this is too naive)

add scaled velocity solution to old solution to produce new solution

check to see if new solution is closer than old solution

if not

divide step size factor by 2

set solver weights to 1 for all joints

loop over joints

if joint violates joint limits

set that joint weight to near 0

flag that limits violated

if limts violated throw out new solution and replace with old

(new iteration will attempt to step closer again without moving joint

which violated limits)

return false since all iterations have completed without success

function draft pass at preparing code for KDL (rich text to avoid gmail

line wrapping):

bool ikPosSolve_hillClimb_jointLimit( KDL::ChainIkSolverVel_wdls &

ikVelocitySolver,

KDL::ChainFkSolverPos_recursive &

fkPositionSolver,

const KDL::JntArray &

jointState,

const KDL::Frame &

targetFrame,

KDL::JntArray &

jointSolution,

int

maxIterations,

const KDL::JntArray &

jointMin,

const KDL::JntArray &

jointMax,

float

epsilon )

{

int numJoints = jointState.rows();

jointSolution = jointState;

KDL::JntArray jointPosDiff( numJoints );

KDL::JntArray lastJointSolution( jointSolution );

// magic number for getting initial step size correct FIXME: too naive?

pass in param?

float baseJointMotionFactor = 0.1;

// For weighting joints. Declaring early to move dynamic allocation out

of loop

Eigen::MatrixXd jointSpaceIdenityMatrix = Eigen::MatrixXd::Identity(

numJoints, numJoints );

Eigen::MatrixXd jointSpaceWeightMatrix( jointSpaceIdenityMatrix );

for( int i = 0; i < maxIterations + 1; i++ ) // + 1 time because answers

checks are delayed by a cycle

{

KDL::Twist twistDiff0;

{ // Check for success

KDL::Frame targetAttempt;

fkPositionSolver.JntToCart( jointSolution, targetAttempt );

twistDiff0 = diff( targetAttempt, targetFrame );

if( Equal( twistDiff0, KDL::Twist::Zero(), epsilon ) )

return true; // SUCCESS!

}

{ // do the step toward the solution

int velSolverStatus = ikVelocitySolver.CartToJnt( jointSolution,

twistDiff0, jointPosDiff );

if( velSolverStatus < 0 )

return false;

// Find the biggest joint value so we can scale everything

between -1 and 1

double maxAbsDiffValue = 0.0001;

for( unsigned int jointIndex = 0; jointIndex <

jointSolution.rows(); ++jointIndex )

{

maxAbsDiffValue = std::max( maxAbsDiffValue,

std::abs(jointPosDiff(jointIndex)) );

}

float jointMotionFactor = baseJointMotionFactor;

jointMotionFactor *= 1/maxAbsDiffValue; // scale

everything between -1 and 1 * baseJointMotionFactor

lastJointSolution = jointSolution;

jointSolution.data = jointSolution.data + (jointPosDiff.data *

jointMotionFactor);

// Check out solution and compare to previous

KDL::Frame testAttempt;

fkPositionSolver.JntToCart( jointSolution, testAttempt );

KDL::Twist twistDiff1 = diff( testAttempt, targetFrame );

// If our new solution is further from the target than our new

one, cut our step size in half

if( (twistDiff1.vel.Norm() > twistDiff0.vel.Norm())

|| (twistDiff1.rot.Norm() > twistDiff0.rot.Norm()) )

{

baseJointMotionFactor *= 0.5;

}

}

{ // check for and back off of any joint limit violations

jointSpaceWeightMatrix = jointSpaceIdenityMatrix;

bool jointLimitViolation = false;

for( unsigned int jnt = 0; jnt < jointMin.rows()

&& jnt < jointMax.rows(); ++jnt )

{

if( jointSolution(jnt) < jointMin(jnt)

|| jointSolution(jnt) > jointMax(jnt) )

{

jointSpaceWeightMatrix( jnt, jnt ) = 0.0001; // Not sure

if this needs to be non-zero

jointLimitViolation = true;

}

}

if( jointLimitViolation ) // solution invalidated

by joint limit violation

jointSolution = lastJointSolution; // try step again with

weight of violating joint reduced

ikVelocitySolver.setWeightJS( jointSpaceWeightMatrix );

}

}

// completed max cycles without going below error threshold

return false;

}

## New solvers welcome?

On Thu, 22 Mar 2012, Andy Somerville wrote:

> On Thu, Mar 22, 2012 at 1:12 AM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:

> > On Wed, 21 Mar 2012, Andy Somerville wrote:

> >

> >> I've written a IK position solver in the course of my work and I'm hoping

> >> that it might be useful to others.

> >

> > Anyway, I would welcome a discussion about your design on orocos-dev. And

> > no decisions have already been taken to indeed proceed in the "new

> > direction" mentioned above.

>

> The algorithm is probably not particularly novel but I think the two important parts are:

Thanks for the concrete details! Much appreciated. I have a number of

comments, that I attach at the end of the message, after a selection that I

made from your posting.

> * Scale all velocities to be between -1 and 1 by dividing the max Joint velocity

> * Use small steps and cut them in half any time it sees a solution farther than

> the last

> * If joint limits are violated, abandon a solution and try again next round

> (rather than keeping that solution but pulling in the one joint to be inside the limits)

>

[...]

> find abs-max-joint-velocity and divide velocity solver solution by that to scale between -1

> and 1

[...]

> multiply by predetermined step size factor (perhaps this is too naive)

[...]

> divide step size factor by 2

>[...]

> set solver weights to 1 for all joints

[...]

> loop over joints

[...]

> if limts violated throw out new solution and replace with old

> (new iteration will attempt to step closer again without moving joint which violated limits)

[...]

> return false since all iterations have completed without success

[...]

> bool ikPosSolve_hillClimb_jointLimit( KDL::ChainIkSolverVel_wdls & ikVelocitySolver,

> KDL::ChainFkSolverPos_recursive & fkPositionSolver,

> const KDL::JntArray & jointState,

> const KDL::Frame & targetFrame,

> KDL::JntArray & jointSolution,

> int maxIterations,

> const KDL::JntArray & jointMin,

> const KDL::JntArray & jointMax,

> float epsilon )

Your solver is definitely ok, and is in the line of the solvers we have

already. But, and this becomes a bigger "but" with every new solver we

accept, and it is a problem that is definitely not yours but it is a lot

more general:

- look at the API: it contains generic parts (every solver takes similar

inputs and outputs), constraint-specific parts (jointMin, jointMax),

_and_ solver-specific parts (maxIterations, epsilon).

- this means that in a week or two, someone else comes along, which wants

to keep the generic part, but change the constraint-specific part, and

keeps the solver-specific parts.

- three months from now, yet another good orocos citizen sends in yet

another algorith, now with a different solver-specific part.

- Etcetera.

You see the problem, I guess: how will we keep on calling all these

different "solvers"? How many lines are really different? What do we do

with all those "magic numbers" in the code? (I made a rough selection of

the magic numbers in your solver above.)

My conclusions are simple:

- we can't maintain this in a scalable and reusable way.

- we should forget about an API-based approach, and go towards a data flow

set of functionalities.

The latter remark means, in somewhat more detail:

- for your specific application, you will make a data flow component,

consisting of, at least, the following computational sub-components:

- the generic part, which has "hooks" at every iteration over a joint and

a link;

- a constraint-specific set of plugins for (some of) these hooks;

- a specific solver,

- configuration components for each of these, _separately_.

The more obvious advantages are:

- no API explosion

- much more modular, hence maintainable

- no more magic numbers anywhere

- a lot simpler to quickly change the different parts independently

- a very generically shareable infrastructure: iterations of trees (whether

they represent kinematic chains or Bayesian networks or control

diagrams), so high code reuse over KDL, BFL, and SCL (and other libraries

with "dynamic programming-like" algorithms)

- ability to use solvers that are made by solver experts.

- readiness to be used in a tool, because of the systematic structure.

Please, let me know whether all of the above makes some sense to you. In

the context of our BRICS project, I am working towards a more detailed

explanation of the summary above. The transition towards data flow

programming will not be trivial, but that is mostly because of the

incredible bias towards Object-Oriented software design that computer

science curricula all over the world are imposing on our students, without

really being aware of the limitations wrt to complementary design paradigms

:-) Note that I write "complementary" and not "competing", because there is

no need to replace all API-based functionalities in KDL with data flow

components. I just think we have to refactor the existing API-based

solvers, in a clever way, _and_ add the data flow way too.

Exercise for the reader: try to find _any_ library in robotics that does

not have the same "API hell" problems as described above. No, don't try to

nominate PCL. Or OMPL. Or any of the other popular ones, for that matter.

I have already lost many hours trying to find _exactly_ what parameters in

the API are needed for which of the parts in their solvers; and even more

to find those parameters that are _not_ in the API but that I know must

be configurable somewhere. Sigh...

Herman

## New solvers welcome?

[snip]

Please, let me know whether all of the above makes some sense to you. In

> the context of our BRICS project, I am working towards a more detailed

> explanation of the summary above. The transition towards data flow

> programming will not be trivial, but that is mostly because of the

> incredible bias towards Object-Oriented software design that computer

> science curricula all over the world are imposing on our students, without

> really being aware of the limitations wrt to complementary design paradigms

> :-) Note that I write "complementary" and not "competing", because there is

> no need to replace all API-based functionalities in KDL with data flow

> components. I just think we have to refactor the existing API-based

> solvers, in a clever way, _and_ add the data flow way too.

>

I share this point of view. I've seen a lot of code (ours and not) use KDL,

and the existing IK solver APIs work well for a narrow (but very common!)

set of particular cases. Once things get a bit more complicated or

specific, the usual flow we've ended up using (and seeing elsewhere) is to

use KDL building blocks like FK and Jacobian solvers to create whatever IK

you're interested in. This is not good as most of these IK setups never

make it back to KDL. I like the "complementary" and not "competing"

argument of Herman, as all functionalities should have a good API that

allows them to be combined in an OO- or data flow-based design. I say +1

for discussing how to refactor solver structure, this sounds like a major

feature for the next KDL (2.0 anyone?).

Andy, I hope we've not strayed too much away from the original subject, but

the topic is very important. Some months ago a student of ours also

proposed a solver because there were a couple of features not yet available

in KDL. There is no way right now to cherry-pick features from each solver

in a clean and reusable fashion. So, thanks for the solver, it has some

nice features, and thanks for triggering this discussion.

All, what are your thought about doing a kdl-developers meeting sometime in

the future?. It could serve as a good opportunity to gather requirements

and use cases. If there's interest, we could take this subject on another

thread.

Cheers,

## New solvers welcome?

On Fri, 23 Mar 2012, Adolfo Rodríguez Tsouroukdissian wrote:

>

> [snip]

>

> Please, let me know whether all of the above makes some sense to you. In

> the context of our BRICS project, I am working towards a more detailed

> explanation of the summary above. The transition towards data flow

> programming will not be trivial, but that is mostly because of the

> incredible bias towards Object-Oriented software design that computer

> science curricula all over the world are imposing on our students, without

> really being aware of the limitations wrt to complementary design paradigms

> :-) Note that I write "complementary" and not "competing", because there is

> no need to replace all API-based functionalities in KDL with data flow

> components. I just think we have to refactor the existing API-based

> solvers, in a clever way, _and_ add the data flow way too.

>

>

> I share this point of view. I've seen a lot of code (ours and not) use KDL, and the existing IK

> solver APIs work well for a narrow (but very common!) set of particular cases. Once things get

> a bit more complicated or specific, the usual flow we've ended up using (and seeing elsewhere)

> is to use KDL building blocks like FK and Jacobian solvers to create whatever IK you're

> interested in. This is not good as most of these IK setups never make it back to KDL. I like the

> "complementary" and not "competing" argument of Herman, as all functionalities should have a

> good API that allows them to be combined in an OO- or data flow-based design. I say +1 for

> discussing how to refactor solver structure, this sounds like a major feature for the next KDL

> (2.0 anyone?).

>

> Andy, I hope we've not strayed too much away from the original subject, but the topic is very

> important. Some months ago a student of ours also proposed a solver because there were a couple

> of features not yet available in KDL. There is no way right now to cherry-pick features from

> each solver in a clean and reusable fashion. So, thanks for the solver, it has some nice

> features, and thanks for triggering this discussion.

>

> All, what are your thought about doing a kdl-developers meeting sometime in the future?. It

> could serve as a good opportunity to gather requirements and use cases. If there's interest, we

> could take this subject on another thread.

+1

> Cheers,

>

> Adolfo Rodríguez Tsouroukdissian

Herman

## New solvers welcome?

>

>

> The algorithm is probably not particularly novel but I think the two

> important

> parts are:

> * Scale all velocities to be between -1 and 1 by dividing the max Joint

> velocity

> * Use small steps and cut them in half any time it sees a solution

> farther than

> the last

> * If joint limits are violated, abandon a solution and try again next

> round

> (rather than keeping that solution but pulling in the one joint to be

> inside the limits)

>

...er 3 important parts : )