On Tue, 8 Mar 2011, Marcus Liebhardt wrote:
> Hi everybody!
>
> First I would like to introduce me as well to this group of developers
> around inverse kinematics solvers. I'm the colleague Adolfo was talking
> about, who is working on and with the (tree) IK solvers.
Welcome! :-)
> During the next
> four months, I will try to help developing and implementing parts of the
> functionalities you were talking about before (see -> "[Orocos-Dev] KDL as
> backend for underconstrained motion specification"). Most probably I will be
> more the guy, who comes up with more practical questions and suggestions -
> and hopefully solutions as well. :-)
>
> Recently my colleagues and I talked about conceptual questions related to
> the tree IK solver. Currently the TreeIkPosSolver_NR_JL is oriented for
> offline solving. For our purpose of using the currently existing position
> solver for online (real-time) control, there are certain parameters (and
> with them certain functions) that are not relevant to us in this context.
> Those are namely the maximum number of iterations and the required
> precision.
Why would these not be relevant for on-line solving...? They are an
(indirect) means of determining the maximum amount of computational effort
to put in the solver, and hence I would think they make a lot of sense.
> On the other side, we need new functionalities like velocity
> saturation/clamping in task and joint space. As a result new parameters are
> required.
I repeat my "evergreen" in this context: keeping parameters within certain
bounds is very relevant but not only the responsibility of the IK, rather
of the _whole_ control system.
> Thus, we removed the iterations and added velocity clamping in task space
> and joint space. Additionally, the dependency of the tree has been removed,
> since it only needs its number of joints. We named this new class
> TreeIkPosSolver_Online, which reflects its intended usage.
I am a bit confused about what "the dependency on the tree has been
removed"? And if you removed the "tree"-dependency, why is the function
still carrying "Tree" in the function...?
> The code of that solver has just been sent as an enhancement bug (#837).
For easier reference:
<http://bugs.orocos.org/show_bug.cgi?id=837>
> Our questions to the community are now:
> - What do you think about making different solvers for different purposes,
> i.e. for online and offline solving?
Absolutely useful. The key desing challenge is to achieve this high
flexibility with a maximum of reuse. In other words, I prefer to have small
reusable computational components that can be flexibly composed into a new
variation, instead of a large set of monolithic solvers.
> Do you agree with that or would you
> like to have all functionalities living in one solver (or do you have other
> ideas)?-
I would like to have all functionalities available via one _service_, but
not as one _algorithm_. The "server" things means that different clients
can put computational requests to that server, with a large variety in
the "performance" constraints that each specific client requires in each of
its service requests: accuracy, stop anytime, miminal cost, one
input-several redundant alternatives,...
> We are also interested in better suggestions about naming and/or
> classification of the presented solver.
> - Also, please have a look at the license and copyright in the header of the
> files. We hope this is a proper way for marking the copyright and giving
> credit. If not, please comment on that!
It looks fine to me! Nice to see contributors doing sincere efforts to give
credit to predecessors :-)
I do think that the "All rights reserved" clause in the first line
is in contradiction with the LPGP license a couple of lines
> - And finally, please let us know, if you find this contribution worth
> adding it to the KDL package and/or which changes you would like to have
> applied.
>
> Of course, if you have any questions about the code and would like me to
> provide more insight or explain our intentions, just tell me!
Some questions/remarks:
- "An inverse position kinematics solver for tree structures, optimized for
online calculation": it is worthwhile to explain what this optimization
mean exactly. I think you do that in the following statement:
- "Thus, the calculation is only done once, meaning that no iteration is
done, because this solver is intended to run at a high frequency."
But, as mentioned before, doing one iteration is not exactly the same
thing as "optimized for on-line use".
- the aim for online optimization is, in my opinion, in contradiction to
all the asserts and checks you are doing in the first part of the solver.
I mean the following: _my_ view of "optimized for online use" is the
following: the solver's checks are done only once, at deployment or
connection time; after that, all data is "streamed" unchecked;
- my suggestion would be to identify (with the help of this mailing list)
to identiy the different "codels" (= most primitive computational
elements, in the context of the GenOM project in LAAS) that make up the IK
algorithm, and then to see how these can be combined/composed to create the
variation in solvers that we want.
> Best wishes from Barcelona,
>
> Marcus Liebhardt
Herman
Questions and suggestions about tree inverse kinematic solvers
> Absolutely useful. The key desing challenge is to achieve this high
>>> flexibility with a maximum of reuse. In other words, I prefer to have
>>> small
>>> reusable computational components that can be flexibly composed into a
>>> new
>>> variation, instead of a large set of monolithic solvers.
>>>
>>
I'd like to add some specifics to this point. The current position solvers
(KDL's, what Marcus is proposing) do some/all of these things (list is
unordered):
1. Call a velocity IK solver.
2. Integrate.
3. Saturate (individually) joint positions.
4. Saturate (uniform scaling) joint position increments (joint velocities).
5. Saturate (uniform scaling) task position increments (task velocities).
6. Loop with certain termination criteria.
Most of these individual aspects should have a standalone implementation
that is solver-agnostic, but can be easily included in a specific solver. I
believe this is more or less what Herman refers to. Point 1. already
achieves this pretty successfully, since no implementation code from the
velocity IK pollutes the position IK. As a counterexample, integration and
saturation are not nicely factored out. If you already have a component for
enforcing constraints like joint limits or collision avoidance, the pos IK
should not impose a fat interface with a suboptimal solution that you're not
going to use anyway. At any rate, there should be a clearer separation of
concerns between constraint enforcement and velocity integration (IMO).
Cheers,
Adolfo.
Questions and suggestions about tree inverse kinematic solvers
On Wed, 9 Mar 2011, Adolfo Rodríguez Tsouroukdissian wrote:
>
> Absolutely useful. The key desing challenge
> is to achieve this high
> flexibility with a maximum of reuse. In
> other words, I prefer to have small
> reusable computational components that can
> be flexibly composed into a new
> variation, instead of a large set of
> monolithic solvers.
>
>
> I'd like to add some specifics to this point. The current position solvers
> (KDL's, what Marcus is proposing) do some/all of these things (list is
> unordered):
> 1. Call a velocity IK solver.
> 2. Integrate.
> 3. Saturate (individually) joint positions.
> 4. Saturate (uniform scaling) joint position increments (joint velocities).
> 5. Saturate (uniform scaling) task position increments (task velocities).
> 6. Loop with certain termination criteria.
>
> Most of these individual aspects should have a standalone implementation that is
> solver-agnostic, but can be easily included in a specific solver. I believe this
> is more or less what Herman refers to. Point 1. already achieves this pretty
> successfully, since no implementation code from the velocity IK pollutes the
> position IK. As a counterexample, integration and saturation are not nicely
> factored out. If you already have a component for enforcing constraints like
> joint limits or collision avoidance, the pos IK should not impose a fat
> interface with a suboptimal solution that you're not going to use anyway. At any
> rate, there should be a clearer separation of concerns between constraint
> enforcement and velocity integration (IMO).
I think I understand what you mean with this message, and I agree with it.
> Cheers,
>
> Adolfo.
Herman
Questions and suggestions about tree inverse kinematic solvers
On Wed, 9 Mar 2011, Marcus Liebhardt wrote:
> 2011/3/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Tue, 8 Mar 2011, Marcus Liebhardt wrote:
>
> Hi everybody!
>
> First I would like to introduce me as well to this group
> of developers
> around inverse kinematics solvers. I'm the colleague
> Adolfo was talking
> about, who is working on and with the (tree) IK solvers.
>
>
> Welcome! :-)
>
> During the next
> four months, I will try to help developing and implementing
> parts of the
> functionalities you were talking about before (see ->
> "[Orocos-Dev] KDL as
> backend for underconstrained motion specification"). Most
> probably I will be
> more the guy, who comes up with more practical questions and
> suggestions -
> and hopefully solutions as well. :-)
>
> Recently my colleagues and I talked about conceptual questions
> related to
> the tree IK solver. Currently the TreeIkPosSolver_NR_JL is
> oriented for
> offline solving. For our purpose of using the currently
> existing position
> solver for online (real-time) control, there are certain
> parameters (and
> with them certain functions) that are not relevant to us in
> this context.
> Those are namely the maximum number of iterations and the
> required
> precision.
>
>
> Why would these not be relevant for on-line solving...? They are an
> (indirect) means of determining the maximum amount of computational effort
> to put in the solver, and hence I would think they make a lot of sense.
>
>
> Let me put that into perspective, since we limit the "workspace" of the solver
> by task and joint space velocity clamping, we are not interested in letting the
> solver iterate more than once.
This is not a rational motivation.
> On the other side, we need new functionalities like
> velocity
> saturation/clamping in task and joint space. As a result
> new parameters are
> required.
>
>
> I repeat my "evergreen" in this context: keeping parameters within certain
> bounds is very relevant but not only the responsibility of the IK, rather
> of the _whole_ control system.
>
> Thus, we removed the iterations and added velocity clamping in
> task space
> and joint space. Additionally, the dependency of the tree has
> been removed,
> since it only needs its number of joints. We named this new
> class
> TreeIkPosSolver_Online, which reflects its intended usage.
>
>
> I am a bit confused about what "the dependency on the tree has been
> removed"? And if you removed the "tree"-dependency, why is the function
> still carrying "Tree" in the function...?
>
>
> Well, on the one hand the used inverse velocity and forward position kinematics
> solvers both work with trees and on the other hand one can specify multiple
> endpoints, what is not possible with a chain.
Why not? An "endpoint" can be attached anywhere on the mechanical
structure.
> Hence, I think it would be good to keep the "Tree" in the class name to put this
> solver in the right context.
I am not really convinced...
> The code of that solver has just been sent as an
> enhancement bug (#837).
>
>
> For easier reference:
> <http://bugs.orocos.org/show_bug.cgi?id=837>
>
>
> That "#837" should have been a clickable link, didn't that work or was is not
> readable/read-friendly enough?
Your default setting of your mail client is HTML email; that's not the
policy of this (and most other professional) mailing lists.
> Our questions to the community are now:
> - What do you think about making different solvers for
> different purposes,
> i.e. for online and offline solving?
>
>
> Absolutely useful. The key desing challenge is to achieve this high
> flexibility with a maximum of reuse. In other words, I prefer to have
> small
> reusable computational components that can be flexibly composed into a new
> variation, instead of a large set of monolithic solvers.
>
> Do you agree with that or would you
> like to have all functionalities living in one solver (or do
> you have other
> ideas)?-
>
> I would like to have all functionalities available via one _service_, but
> not as one _algorithm_. The "server" things means that different clients
> can put computational requests to that server, with a large variety in
> the "performance" constraints that each specific client requires in each
> of
> its service requests: accuracy, stop anytime, miminal cost, one
> input-several redundant alternatives,...
>
> We are also interested in better suggestions about naming
> and/or
> classification of the presented solver.
>
>
> - Also, please have a look at the license and copyright in the
> header of the
> files. We hope this is a proper way for marking the copyright
> and giving
> credit. If not, please comment on that!
>
>
> It looks fine to me! Nice to see contributors doing sincere efforts to
> give
> credit to predecessors :-)
> I do think that the "All rights reserved" clause in the first line
> is in contradiction with the LPGP license a couple of lines
>
>
> A quick research on wikipedia showed that it is an obsolescent addition to the
> normal copyright with no legal significance.
> Since there was the wish in our group of developers to keep this antiquated
> phrase, we kept it. :-)
> But I can remove it, if it turns out, that this addition is problematic in any
> way.
>
>
> - And finally, please let us know, if you find this
> contribution worth
> adding it to the KDL package and/or which changes you
> would like to have
> applied.
>
> Of course, if you have any questions about the code and
> would like me to
> provide more insight or explain our intentions, just
> tell me!
>
>
> Some questions/remarks:
> - "An inverse position kinematics solver for tree structures, optimized
> for
> online calculation": it is worthwhile to explain what this optimization
> mean exactly. I think you do that in the following statement:
> - "Thus, the calculation is only done once, meaning that no iteration is
> done, because this solver is intended to run at a high frequency."
> But, as mentioned before, doing one iteration is not exactly the same
> thing as "optimized for on-line use".
> - the aim for online optimization is, in my opinion, in contradiction to
> all the asserts and checks you are doing in the first part of the solver.
> I mean the following: _my_ view of "optimized for online use" is the
> following: the solver's checks are done only once, at deployment or
> connection time; after that, all data is "streamed" unchecked;
>
>
> I think, that "online" in the naming has to be set into perspective as well. It
> was more the best idea I could come up till that moment, since putting all
> functionalities of the solver in its name (like the one it is derived from)
> would have led to a (too) long name.
My "best practices":
- never give a function a name that reflects what you want to do with it,
but always what it does (= its functionalities)
- if there are too many functionalities to name, this is a very strong
indication that the function does too many things. (As was already clear
from other messages in this thread.)
> "Optimized for online calculation" can also
> be a quite subjective term, since different people might have different
> requirements for that. So further discussions might are needed to clarify it.
> That is also the reason, why I asked the community for suggestions for better
> naming. :-)
Good! :-)
>
> - my suggestion would be to identify (with the help of this mailing
> list)
> to identiy the different "codels" (= most primitive computational
> elements, in the context of the GenOM project in LAAS) that make
> up the IK
> algorithm, and then to see how these can be combined/composed to
> create the
> variation in solvers that we want.
>
>
> I think, I miss the big picture / concept for that to be a big help. That most
> probably also comes from the fact, that I do not have much experience with big
> software projects.
> But I want to emphasize, that I am willing to contribute to that effort as far
> as my project/diploma thesis permits it.
> At least I could restructure my code, once a concept is available. The joint and
> task space velocity clamping as well as the joint position clamping might be
> among these "codels" you talked about?
No, not really. "codels" are the smallest, "atomic", parts of computations;
the "clamping" is a functionality. Each functionality need a set of codels,
but it in itself (almost by definition) a "codel".
> Since we are planning to add more features to our solver, I could restructure my
> code based on the community suggestions step by step.
> Best wishes from Barcelona,
>
> Marcus Liebhardt
>
>
> Herman
>
>
> Thanks for these interesting and helpful comments!
You're welcome.
> :-) Marcus
Herman
Questions and suggestions about tree inverse kinematic solvers
On Tuesday 08 March 2011 16:03:38 Marcus Liebhardt wrote:
> Hi everybody!
>
> First I would like to introduce me as well to this group of developers
> around inverse kinematics solvers. I'm the colleague Adolfo was talking
> about, who is working on and with the (tree) IK solvers. During the next
> four months, I will try to help developing and implementing parts of the
> functionalities you were talking about before (see -> "[Orocos-Dev] KDL as
> backend for underconstrained motion
> specification<http://www.orocos.org/forum/rtt/rtt-dev/kdl-backend-undercons
> trained-motion-specification>"). Most probably I will be more the guy, who
> comes up with more practical questions and suggestions - and hopefully
> solutions as well. :-)
>
> Recently my colleagues and I talked about conceptual questions related to
> the tree IK solver. Currently the TreeIkPosSolver_NR_JL is oriented for
> offline solving. For our purpose of using the currently existing position
> solver for online (real-time) control, there are certain parameters (and
> with them certain functions) that are not relevant to us in this context.
> Those are namely the maximum number of iterations and the required
> precision. On the other side, we need new functionalities like velocity
> saturation/clamping in task and joint space. As a result new parameters are
> required.
If you are talking about control an inverse position solver does not make a
lot of sense to me. I would try to implement an inverse velocity solver
instead. New parameters can easily be added in the specific solver you want to
implement. Check the ChainIkSolverPos_NR_JL for instance on how this can be
done.
> Thus, we removed the iterations and added velocity clamping in task space
> and joint space. Additionally, the dependency of the tree has been removed,
> since it only needs its number of joints. We named this new class
> TreeIkPosSolver_Online, which reflects its intended usage. The code of that
> solver has just been sent as an enhancement bug
> (#837<http://bugs.orocos.org/show_bug.cgi?id=837>).
I'll take a look at it and propose changes if needed ;)
> Our questions to the community are now:
> - What do you think about making different solvers for different purposes,
> i.e. for online and offline solving?
That's the main idea with KDL, provide a common interface for all solvers and
a specific interface for specific properties of a specifici implementation.
> Do you agree with that or would you
> like to have all functionalities living in one solver (or do you have other
> ideas)?
I don't see how this would work. Can you give a more elaborate example?
> - We are also interested in better suggestions about naming and/or
> classification of the presented solver.
>
> - Also, please have a look at the
> license and copyright in the header of the files. We hope this is a proper
> way for marking the copyright and giving credit. If not, please comment on
> that!
> - And finally, please let us know, if you find this contribution
> worth adding it to the KDL package and/or which changes you would like to
> have applied.
>
> Of course, if you have any questions about the code and would like me to
> provide more insight or explain our intentions, just tell me!
>
Current development of kdl is happening in the
git.mech.kuleuven.be/robotics/orocos_kinematics_dynamics.git git repository,
where we already started to split out the python bindings and rtt typekit in a
separate packages.
>
> Best wishes from Barcelona,
>
> Marcus Liebhardt
-- Ruben
Questions and suggestions about tree inverse kinematic solvers
On Mon, 23 May 2011, Ruben Smits wrote:
> On Tuesday 08 March 2011 16:03:38 Marcus Liebhardt wrote:
>> Hi everybody!
>>
>> First I would like to introduce me as well to this group of developers
>> around inverse kinematics solvers. I'm the colleague Adolfo was talking
>> about, who is working on and with the (tree) IK solvers. During the next
>> four months, I will try to help developing and implementing parts of the
>> functionalities you were talking about before (see -> "[Orocos-Dev] KDL as
>> backend for underconstrained motion
>> specification<http://www.orocos.org/forum/rtt/rtt-dev/kdl-backend-undercons
>> trained-motion-specification>"). Most probably I will be more the guy, who
>> comes up with more practical questions and suggestions - and hopefully
>> solutions as well. :-)
>>
>> Recently my colleagues and I talked about conceptual questions related to
>> the tree IK solver. Currently the TreeIkPosSolver_NR_JL is oriented for
>> offline solving. For our purpose of using the currently existing position
>> solver for online (real-time) control, there are certain parameters (and
>> with them certain functions) that are not relevant to us in this context.
>> Those are namely the maximum number of iterations and the required
>> precision.
These _are_ relevant for online use too!
> On the other side, we need new functionalities like velocity
>> saturation/clamping in task and joint space. As a result new parameters are
>> required.
>
> If you are talking about control an inverse position solver does not make a
> lot of sense to me. I would try to implement an inverse velocity solver
> instead.
Fully agreed. Or even a dynamics solver.
> New parameters can easily be added in the specific solver you want to
> implement. Check the ChainIkSolverPos_NR_JL for instance on how this can be
> done.
>
>> Thus, we removed the iterations and added velocity clamping in task space
>> and joint space. Additionally, the dependency of the tree has been removed,
>> since it only needs its number of joints. We named this new class
>> TreeIkPosSolver_Online, which reflects its intended usage.
Please _don't_ fall in the trap of calling something after its "intended
use"! First, it is _your_ intended use, and not necessarily other people's
intended use. Second, names should reflect what the thing _does_, since
that is much more reusable.
> The code of that
>> solver has just been sent as an enhancement bug
>> (#837<http://bugs.orocos.org/show_bug.cgi?id=837>).
>
> I'll take a look at it and propose changes if needed ;)
>
>> Our questions to the community are now:
>> - What do you think about making different solvers for different purposes,
>> i.e. for online and offline solving?
>
> That's the main idea with KDL, provide a common interface for all solvers and
> a specific interface for specific properties of a specifici implementation.
Online and offline are the wrong concepts to use! As mentioned before, a
specific solver should get a name that reflects its _algorithm_, not its
"intended use".
>> Do you agree with that or would you
>> like to have all functionalities living in one solver (or do you have other
>> ideas)?
>
> I don't see how this would work. Can you give a more elaborate example?
>
>> - We are also interested in better suggestions about naming and/or
>> classification of the presented solver.
>>
>> - Also, please have a look at the
>> license and copyright in the header of the files. We hope this is a proper
>> way for marking the copyright and giving credit. If not, please comment on
>> that!
It would work a lot easier if you could copy the relevant parts that you
want to be discussed in a separate email, for discussion in the
mailinglist... Otherwise, we just have to guess what parts of the text you
refer to you have in mind for discussion.
>> - And finally, please let us know, if you find this contribution
>> worth adding it to the KDL package and/or which changes you would like to
>> have applied.
>>
>> Of course, if you have any questions about the code and would like me to
>> provide more insight or explain our intentions, just tell me!
>>
>
> Current development of kdl is happening in the
> git.mech.kuleuven.be/robotics/orocos_kinematics_dynamics.git git repository,
> where we already started to split out the python bindings and rtt typekit in a
> separate packages.
>
>>
>> Best wishes from Barcelona,
>>
>> Marcus Liebhardt
>
> -- Ruben
Herman