[Bug 837] A new tree IK position solver for online/real-time calculations

http://bugs.orocos.org/show_bug.cgi?id=837

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |ruben [dot] smits [..] ...en.b
| |e

--- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...> 2011-05-26 14:45:05 CEST ---
I would accept it if you made it a TreeIkSolverVel that adds maximum jointspace
and taskspace velocities and scales.

That extra functionality is indeed useful.

The position solver you propose acts like a proportional feedback controller
with a feedback gain of 1. It belongs in a controller component/block.

-- Ruben

Ruben Smits's picture

[Bug 837] A new tree IK position solver for online/real-time cal

http://bugs.orocos.org/show_bug.cgi?id=837

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED

Ruben Smits's picture

[Bug 837] A new tree IK position solver for online/real-time cal

http://bugs.orocos.org/show_bug.cgi?id=837

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED

[Bug 837] A new tree IK position solver for online/real-time cal

Am 17. Februar 2012 17:53 schrieb Ruben Smits <ruben [dot] smits [..] ...>
:

>
> http://bugs.orocos.org/show
>
> g
>
> _bug.cgi?id=837 <http://bugs.orocos.org/show_bug.cgi?id=837>
>
> Ruben Smits <ruben [dot] smits [..] ...> changed:
>
> What |Removed |Added
>
> ----------------------------------------------------------------------------
> Status|NEW |ASSIGNED
>

[Bug 837] A new tree IK position solver for online/real-time cal

On Thu, 23 Feb 2012, Marcus Liebhardt wrote:

> Am 17. Februar 2012 17:53 schrieb Ruben Smits <ruben [dot] smits [..] ...>:
>
> http://bugs.orocos.org/show
> g
>
> _bug.cgi?id=837
>
> Ruben Smits <ruben [dot] smits [..] ...> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|NEW                         |ASSIGNED
>
> --- Comment #2 from Ruben Smits <ruben [dot] smits [..] ...> 2012-02-17
> 09:53:57 CET ---
> I changed my mind on this one,
>
>
> Ha, I can't believe it! I already gave up on this one. But it seems like that
> contribution was more persistent than me. After being sent in a year ago, revived
> after some months, it finally got through! :-)
> This remembers me of something, I wanted to write to the list a long time ago.
>
> An interesting discussion followed the present contribution (see "Questions and
> suggestions about tree inverse kinematic solvers" on this list [1]). The result of
> this discussion was, that some modifications should be applied to the solver in order
> to make it a suitable addition to the library. However, the actual details about what
> should be changed were left in the dark. That was quite unfortunate, since I hadn't
> the skills to implement the required changes myself and was too busy with my thesis to
> dig deep and find out what I need to do. So, in the end this contribution "died" more
> or less for me.
>
> I remember that the topic of how to handle community/user contributions has already
> been addressed in the past at least once. I want to note that I do appreciate the
> strong will in this community to keep the code quality high by making sure potential
> contributions align with the existing requirements/policies. But when doing so, I
> would like to see those requesting changes providing more help for those who should
> apply them. This help shall not be doing the actual work on that contribution, but
> providing enough information for the contributor to be able to apply the requested
> changes himself.
> So, these are my two cents. Let's go back to the actual topic.
>
> The present patch is actually quite outdated. Since the proposal the solver has been
> developed further. Some changes have been applied and more features added, e.g.
> iterations were put back in and exponential smoothing was added. We are using this
> solver now for nearly a year and it serves us quite well. The current code can be
> found on github (see [2] & [3]).
> There are still some things I'm not happy/sure about. Some of these things have been
> addressed in the discussion I mentioned before. For example, the solver housing task
> and joint space limiting and exponential smoothing looks a bit overloaded to me. There
> are probably better ways to implement these features.
> So, I will create a patch of the new against the old version and I'm looking forward
> to your feedback!

My feedback is the following: in this history of kinematic solvers, we see
the same unfortunate evolution as in most other robotics functionality
libraries: planners, point cloud, openCV, ... And that is that people can
only think, design and code in terms of class libraries, providing one or
more new API calls everytime they extend existing functionality.

This approach is NOT SCALABLE:
- every new solver copies 80-90% of code from an already existing solver,
so an update to the shared core requires ever more efforts to be applied
to all derived solvers
- every new solver (including this one) introduces "legacy" that is only
relevant/meaningful for the developer of the new solver, but not
necessarilty for every user of the functionality. For example: the
documentation of inputs and outputs, the use or not-use of "assert"s, the
precise policy to avoid joint limits, the coupling estimators, etc.
- functional extensions are done via "inheritance" instead of by the much
more "composition", which is a lot more scalable and flexible (whenever
it can be applied).
The result is an ever increasing slowdown of patch application and of code
reuse (read: code reuse as complete function blocks, and not as "copy and
post" from one C++ file to another). That's not where I want this project
to go, on the contrary.

More concretely, here is my suggestion for the future: kinematic solvers
should be refactored from a "class library" paradigm into a "data flow"
paradigm. That means that new functionality is added "function block" by
function block, and not "full class by full class". The core of all the
current solvers is the same: do some inward and outward sweeps over the
kinematic structure, and then do operations at every joint and/or link,
with some extra things at the root, the leaves and the junctions of trees.
_The_ more scalable approach would consist of coding this sweepings
separately, providing a "plug in" set of hooks allowing extensions to be
done by composition (e.g., checking or controlling joint position limit
violations every time a joint is traversed in the sweeps). _The API_ of a
solver will not exist anymore, which fits reality a lot better than the
current class libraries: _every_ robotic system has slightly different sets
of inputs and outputs, especially when also taking control and estimation
into account.

>
> Best wishes
> Marcus Liebhardt

Herman

>
> [1]http://www.orocos.org/forum/rtt/rtt-dev/questions-and-suggestions-about-tree-inverse-
> kinematic-solvers
> [2]https://github.com/pal-robotics/reem_teleop/blob/master/tree_kinematics/include/tree_
> kinematics/treeiksolverpos_online.hpp
> [3]https://github.com/pal-robotics/reem_teleop/blob/master/tree_kinematics/src/treeiksol
> verpos_online.cpp
>
>
>
> I already included the solver in master:
> commit 554377c8d0a004be224430a7bb56d39fe5499335
>
> But I'm not so keen on all the asserts in the code. These should be
> replaced by
> error codes.
>
> --
> Configure bugmail: http://bugs.orocos.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
>
> --
> Dipl.-Ing. (M.Sc.) Marcus Liebhardt
> Control Engineer
> Yujin Robot
> Address (Korean): ???? ??? ??? ??? 345-30 ????? #601, 153-023.
> Address (English): #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu, Seoul,
> 153-023, Republic of Korea
> Website: http://www.yujinrobot.com
> Email: marcus [dot] liebhardt [..] ...
> Phone: +82-2-2026-1400
>
>

--
KU Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Ruben Smits's picture

[Bug 837] A new tree IK position solver for online/real-time cal

On Thu, Feb 23, 2012 at 12:34 PM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
>
> On Thu, 23 Feb 2012, Marcus Liebhardt wrote:
>
>> Am 17. Februar 2012 17:53 schrieb Ruben Smits
>> <ruben [dot] smits [..] ...>:
>>
>>      http://bugs.orocos.org/show
>>            g
>>
>>      _bug.cgi?id=837
>>
>>      Ruben Smits <ruben [dot] smits [..] ...> changed:
>>
>>                What    |Removed                     |Added
>>
>>  ----------------------------------------------------------------------------
>>                  Status|NEW                         |ASSIGNED
>>
>>      --- Comment #2 from Ruben Smits <ruben [dot] smits [..] ...>
>> 2012-02-17
>>      09:53:57 CET ---
>>      I changed my mind on this one,
>>
>>
>> Ha, I can't believe it! I already gave up on this one. But it seems like
>> that
>> contribution was more persistent than me. After being sent in a year ago,
>> revived
>> after some months, it finally got through! :-)
>> This remembers me of something, I wanted to write to the list a long time
>> ago.
>>
>> An interesting discussion followed the present contribution (see
>> "Questions and
>> suggestions about tree inverse kinematic solvers" on this list [1]). The
>> result of
>> this discussion was, that some modifications should be applied to the
>> solver in order
>> to make it a suitable addition to the library. However, the actual
>> details about what
>> should be changed were left in the dark. That was quite unfortunate,
>> since I hadn't
>> the skills to implement the required changes myself and was too busy with
>> my thesis to
>> dig deep and find out what I need to do. So, in the end this contribution
>> "died" more
>> or less for me.
>>
>> I remember that the topic of how to handle community/user contributions
>> has already
>> been addressed in the past at least once. I want to note that I do
>> appreciate the
>> strong will in this community to keep the code quality high by making
>> sure potential
>> contributions align with the existing requirements/policies. But when
>> doing so, I
>> would like to see those requesting changes providing more help for those
>> who should
>> apply them. This help shall not be doing the actual work on that
>> contribution, but
>> providing enough information for the contributor to be able to apply the
>> requested
>> changes himself.
>> So, these are my two cents. Let's go back to the actual topic.
>>
>> The present patch is actually quite outdated. Since the proposal the
>> solver has been
>> developed further. Some changes have been applied and more features
>> added, e.g.
>> iterations were put back in and exponential smoothing was added. We are
>> using this
>> solver now for nearly a year and it serves us quite well. The current
>> code can be
>> found on github (see [2] & [3]).
>> There are still some things I'm not happy/sure about. Some of these
>> things have been
>> addressed in the discussion I mentioned before. For example, the solver
>> housing task
>> and joint space limiting and exponential smoothing looks a bit overloaded
>> to me. There
>> are probably better ways to implement these features.
>> So, I will create a patch of the new against the old version and I'm
>> looking forward
>> to your feedback!
>
>
> My feedback is the following: in this history of kinematic solvers, we see
> the same unfortunate evolution as in most other robotics functionality
> libraries: planners, point cloud, openCV, ... And that is that people can
> only think, design and code in terms of class libraries, providing one or
> more new API calls everytime they extend existing functionality.
>
> This approach is NOT SCALABLE:
> - every new solver copies 80-90% of code from an already existing solver,
>  so an update to the shared core requires ever more efforts to be applied
>  to all derived solvers

Hmm, in this case no code was copied over from other solvers, it uses
an existing solver inside and adds extra functionality.

> - every new solver (including this one) introduces "legacy" that is only
>  relevant/meaningful for the developer of the new solver, but not
>  necessarilty for every user of the functionality. For example: the
>  documentation of inputs and outputs, the use or not-use of "assert"s, the
>  precise policy to avoid joint limits, the coupling estimators, etc.
> - functional extensions are done via "inheritance" instead of by the much
>  more "composition", which is a lot more scalable and flexible (whenever
>  it can be applied).
> The result is an ever increasing slowdown of patch application and of code
> reuse (read: code reuse as complete function blocks, and not as "copy and
> post" from one C++ file to another). That's not where I want this project
> to go, on the contrary.
>
> More concretely, here is my suggestion for the future: kinematic solvers
> should be refactored from a "class library" paradigm into a "data flow"
> paradigm. That means that new functionality is added "function block" by
> function block, and not "full class by full class". The core  of all the
> current solvers is the same: do some inward and outward sweeps over the
> kinematic structure, and then do operations at every joint and/or link,
> with some extra things at the root, the leaves and the junctions of trees.
> _The_ more scalable approach would consist of coding this sweepings
> separately, providing a "plug in" set of hooks allowing extensions to be
> done by composition (e.g., checking or controlling joint position limit
> violations every time a joint is traversed in the sweeps). _The API_ of a
> solver will not exist anymore, which fits reality a lot better than the
> current class libraries: _every_ robotic system has slightly different
> sets
> of inputs and outputs, especially when also taking control and estimation
> into account.
>

I like the idea but in this case we need a structure that stores all
the data needed by the different "visitors" (solvers) which is not the
kinematic structure itself?

I would be happy to see a proof of concept of this for this particular
use case, an inverse velocity kinematics solver that can handle joint
space position and velocity limits and cartesian space velocity
limits, that would fit in the scope of Orocos KDL.

>>
>> Best wishes
>> Marcus Liebhardt
>
>
> Herman
>

Ruben

>>
>>
>> [1]http://www.orocos.org/forum/rtt/rtt-dev/questions-and-suggestions-about-tree-inverse-
>> kinematic-solvers
>>
>> [2]https://github.com/pal-robotics/reem_teleop/blob/master/tree_kinematics/include/tree_
>> kinematics/treeiksolverpos_online.hpp
>>
>> [3]https://github.com/pal-robotics/reem_teleop/blob/master/tree_kinematics/src/treeiksol
>>
>> verpos_online.cpp
>>
>>
>>
>>      I already included the solver in master:
>>      commit 554377c8d0a004be224430a7bb56d39fe5499335
>>
>>      But I'm not so keen on all the asserts in the code. These should be
>>      replaced by
>>      error codes.
>>
>>      --
>>      Configure bugmail: http://bugs.orocos.org/userprefs.cgi?tab=email
>>      ------- You are receiving this mail because: -------
>>      You are the assignee for the bug.
>>      --
>>      Orocos-Dev mailing list
>>      Orocos-Dev [..] ...
>>      http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>>
>> --
>> Dipl.-Ing. (M.Sc.) Marcus Liebhardt
>> Control Engineer
>> Yujin Robot
>> Address (Korean): ???? ??? ??? ??? 345-30 ????? #601, 153-023.
>> Address (English): #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu,
>> Seoul,
>> 153-023, Republic of Korea
>> Website: http://www.yujinrobot.com
>> Email: marcus [dot] liebhardt [..] ...
>> Phone: +82-2-2026-1400
>>
>>
>
> --
>  KU Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
>    <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>  EURON Coordinator (European Robotics Research Network)
> <http://www.euron.org>
>  Open Realtime Control Services <http://www.orocos.org>
>  Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

[Bug 837] A new tree IK position solver for online/real-time cal

On Fri, 24 Feb 2012, Ruben Smits wrote:

> On Thu, Feb 23, 2012 at 12:34 PM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> On Thu, 23 Feb 2012, Marcus Liebhardt wrote:
>>
>>> Am 17. Februar 2012 17:53 schrieb Ruben Smits
>>> <ruben [dot] smits [..] ...>:
>>>
>>>      http://bugs.orocos.org/show
>>>            g
>>>
>>>      _bug.cgi?id=837
>>>
>>>      Ruben Smits <ruben [dot] smits [..] ...> changed:
>>>
>>>                What    |Removed                     |Added
>>>
>>>  ----------------------------------------------------------------------------
>>>                  Status|NEW                         |ASSIGNED
>>>
>>>      --- Comment #2 from Ruben Smits <ruben [dot] smits [..] ...>
>>> 2012-02-17
>>>      09:53:57 CET ---
>>>      I changed my mind on this one,
>>>
>>>
>>> Ha, I can't believe it! I already gave up on this one. But it seems like
>>> that
>>> contribution was more persistent than me. After being sent in a year ago,
>>> revived
>>> after some months, it finally got through! :-)
>>> This remembers me of something, I wanted to write to the list a long time
>>> ago.
>>>
>>> An interesting discussion followed the present contribution (see
>>> "Questions and
>>> suggestions about tree inverse kinematic solvers" on this list [1]). The
>>> result of
>>> this discussion was, that some modifications should be applied to the
>>> solver in order
>>> to make it a suitable addition to the library. However, the actual
>>> details about what
>>> should be changed were left in the dark. That was quite unfortunate,
>>> since I hadn't
>>> the skills to implement the required changes myself and was too busy with
>>> my thesis to
>>> dig deep and find out what I need to do. So, in the end this contribution
>>> "died" more
>>> or less for me.
>>>
>>> I remember that the topic of how to handle community/user contributions
>>> has already
>>> been addressed in the past at least once. I want to note that I do
>>> appreciate the
>>> strong will in this community to keep the code quality high by making
>>> sure potential
>>> contributions align with the existing requirements/policies. But when
>>> doing so, I
>>> would like to see those requesting changes providing more help for those
>>> who should
>>> apply them. This help shall not be doing the actual work on that
>>> contribution, but
>>> providing enough information for the contributor to be able to apply the
>>> requested
>>> changes himself.
>>> So, these are my two cents. Let's go back to the actual topic.
>>>
>>> The present patch is actually quite outdated. Since the proposal the
>>> solver has been
>>> developed further. Some changes have been applied and more features
>>> added, e.g.
>>> iterations were put back in and exponential smoothing was added. We are
>>> using this
>>> solver now for nearly a year and it serves us quite well. The current
>>> code can be
>>> found on github (see [2] & [3]).
>>> There are still some things I'm not happy/sure about. Some of these
>>> things have been
>>> addressed in the discussion I mentioned before. For example, the solver
>>> housing task
>>> and joint space limiting and exponential smoothing looks a bit overloaded
>>> to me. There
>>> are probably better ways to implement these features.
>>> So, I will create a patch of the new against the old version and I'm
>>> looking forward
>>> to your feedback!
>>
>>
>> My feedback is the following: in this history of kinematic solvers, we see
>> the same unfortunate evolution as in most other robotics functionality
>> libraries: planners, point cloud, openCV, ... And that is that people can
>> only think, design and code in terms of class libraries, providing one or
>> more new API calls everytime they extend existing functionality.
>>
>> This approach is NOT SCALABLE:
>> - every new solver copies 80-90% of code from an already existing solver,
>>  so an update to the shared core requires ever more efforts to be applied
>>  to all derived solvers
>
> Hmm, in this case no code was copied over from other solvers, it uses
> an existing solver inside and adds extra functionality.

This is the best way to copy, indeed :-) But the scalability remains
compromised, by the "extend via adding functionality in existing classes".

>> - every new solver (including this one) introduces "legacy" that is only
>>  relevant/meaningful for the developer of the new solver, but not
>>  necessarilty for every user of the functionality. For example: the
>>  documentation of inputs and outputs, the use or not-use of "assert"s, the
>>  precise policy to avoid joint limits, the coupling estimators, etc.
>> - functional extensions are done via "inheritance" instead of by the much
>>  more "composition", which is a lot more scalable and flexible (whenever
>>  it can be applied).
>> The result is an ever increasing slowdown of patch application and of code
>> reuse (read: code reuse as complete function blocks, and not as "copy and
>> post" from one C++ file to another). That's not where I want this project
>> to go, on the contrary.
>>
>> More concretely, here is my suggestion for the future: kinematic solvers
>> should be refactored from a "class library" paradigm into a "data flow"
>> paradigm. That means that new functionality is added "function block" by
>> function block, and not "full class by full class". The core  of all the
>> current solvers is the same: do some inward and outward sweeps over the
>> kinematic structure, and then do operations at every joint and/or link,
>> with some extra things at the root, the leaves and the junctions of trees.
>> _The_ more scalable approach would consist of coding this sweepings
>> separately, providing a "plug in" set of hooks allowing extensions to be
>> done by composition (e.g., checking or controlling joint position limit
>> violations every time a joint is traversed in the sweeps). _The API_ of a
>> solver will not exist anymore, which fits reality a lot better than the
>> current class libraries: _every_ robotic system has slightly different
>> sets
>> of inputs and outputs, especially when also taking control and estimation
>> into account.
>>
>
> I like the idea but in this case we need a structure that stores all
> the data needed by the different "visitors" (solvers) which is not the
> kinematic structure itself?

Yes, this is not a simple design issue! I am preparing some thoughts in
this direction, but don't hold your breath.

> I would be happy to see a proof of concept of this for this particular
> use case, an inverse velocity kinematics solver that can handle joint
> space position and velocity limits and cartesian space velocity
> limits, that would fit in the scope of Orocos KDL.

I think this is a very valid remark to make: a "show me the code" proof of
concept. Any takers to help me out with this, i.e., someone with a full
week of effort available somewhere in the coming months?

>>> Best wishes
>>> Marcus Liebhardt

> Ruben

Herman

Ruben Smits's picture

[Bug 837] A new tree IK position solver for online/real-time cal

Hi Herman,

On Fri, Feb 24, 2012 at 9:21 AM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Fri, 24 Feb 2012, Ruben Smits wrote:
>
>> On Thu, Feb 23, 2012 at 12:34 PM, Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...> wrote:
>>>
>>>
>>> On Thu, 23 Feb 2012, Marcus Liebhardt wrote:
>>>
>>>> Am 17. Februar 2012 17:53 schrieb Ruben Smits
>>>> <ruben [dot] smits [..] ...>:
>>>>
>>>>      http://bugs.orocos.org/show
>>>>            g
>>>>
>>>>      _bug.cgi?id=837
>>>>
>>>>      Ruben Smits <ruben [dot] smits [..] ...> changed:
>>>>
>>>>                What    |Removed                     |Added
>>>>
>>>>
>>>>  ----------------------------------------------------------------------------
>>>>                  Status|NEW                         |ASSIGNED
>>>>
>>>>      --- Comment #2 from Ruben Smits <ruben [dot] smits [..] ...>
>>>> 2012-02-17
>>>>      09:53:57 CET ---
>>>>      I changed my mind on this one,
>>>>
>>>>
>>>> Ha, I can't believe it! I already gave up on this one. But it seems like
>>>> that
>>>> contribution was more persistent than me. After being sent in a year
>>>> ago,
>>>> revived
>>>> after some months, it finally got through! :-)
>>>> This remembers me of something, I wanted to write to the list a long
>>>> time
>>>> ago.
>>>>
>>>> An interesting discussion followed the present contribution (see
>>>> "Questions and
>>>> suggestions about tree inverse kinematic solvers" on this list [1]). The
>>>> result of
>>>> this discussion was, that some modifications should be applied to the
>>>> solver in order
>>>> to make it a suitable addition to the library. However, the actual
>>>> details about what
>>>> should be changed were left in the dark. That was quite unfortunate,
>>>> since I hadn't
>>>> the skills to implement the required changes myself and was too busy
>>>> with
>>>> my thesis to
>>>> dig deep and find out what I need to do. So, in the end this
>>>> contribution
>>>> "died" more
>>>> or less for me.
>>>>
>>>> I remember that the topic of how to handle community/user contributions
>>>> has already
>>>> been addressed in the past at least once. I want to note that I do
>>>> appreciate the
>>>> strong will in this community to keep the code quality high by making
>>>> sure potential
>>>> contributions align with the existing requirements/policies. But when
>>>> doing so, I
>>>> would like to see those requesting changes providing more help for those
>>>> who should
>>>> apply them. This help shall not be doing the actual work on that
>>>> contribution, but
>>>> providing enough information for the contributor to be able to apply the
>>>> requested
>>>> changes himself.
>>>> So, these are my two cents. Let's go back to the actual topic.
>>>>
>>>> The present patch is actually quite outdated. Since the proposal the
>>>> solver has been
>>>> developed further. Some changes have been applied and more features
>>>> added, e.g.
>>>> iterations were put back in and exponential smoothing was added. We are
>>>> using this
>>>> solver now for nearly a year and it serves us quite well. The current
>>>> code can be
>>>> found on github (see [2] & [3]).
>>>> There are still some things I'm not happy/sure about. Some of these
>>>> things have been
>>>> addressed in the discussion I mentioned before. For example, the solver
>>>> housing task
>>>> and joint space limiting and exponential smoothing looks a bit
>>>> overloaded
>>>> to me. There
>>>> are probably better ways to implement these features.
>>>> So, I will create a patch of the new against the old version and I'm
>>>> looking forward
>>>> to your feedback!
>>>
>>>
>>>
>>> My feedback is the following: in this history of kinematic solvers, we
>>> see
>>> the same unfortunate evolution as in most other robotics functionality
>>> libraries: planners, point cloud, openCV, ... And that is that people can
>>> only think, design and code in terms of class libraries, providing one or
>>> more new API calls everytime they extend existing functionality.
>>>
>>> This approach is NOT SCALABLE:
>>> - every new solver copies 80-90% of code from an already existing solver,
>>>  so an update to the shared core requires ever more efforts to be applied
>>>  to all derived solvers
>>
>>
>> Hmm, in this case no code was copied over from other solvers, it uses
>> an existing solver inside and adds extra functionality.
>
>
> This is the best way to copy, indeed :-) But the scalability remains
> compromised, by the "extend via adding functionality in existing classes".
>

I fully agree.

>
>>> - every new solver (including this one) introduces "legacy" that is only
>>>  relevant/meaningful for the developer of the new solver, but not
>>>  necessarilty for every user of the functionality. For example: the
>>>  documentation of inputs and outputs, the use or not-use of "assert"s,
>>> the
>>>  precise policy to avoid joint limits, the coupling estimators, etc.
>>> - functional extensions are done via "inheritance" instead of by the much
>>>  more "composition", which is a lot more scalable and flexible (whenever
>>>  it can be applied).
>>> The result is an ever increasing slowdown of patch application and of
>>> code
>>> reuse (read: code reuse as complete function blocks, and not as "copy and
>>> post" from one C++ file to another). That's not where I want this project
>>> to go, on the contrary.
>>>
>>> More concretely, here is my suggestion for the future: kinematic solvers
>>> should be refactored from a "class library" paradigm into a "data flow"
>>> paradigm. That means that new functionality is added "function block" by
>>> function block, and not "full class by full class". The core  of all the
>>> current solvers is the same: do some inward and outward sweeps over the
>>> kinematic structure, and then do operations at every joint and/or link,
>>> with some extra things at the root, the leaves and the junctions of
>>> trees.
>>> _The_ more scalable approach would consist of coding this sweepings
>>> separately, providing a "plug in" set of hooks allowing extensions to be
>>> done by composition (e.g., checking or controlling joint position limit
>>> violations every time a joint is traversed in the sweeps). _The API_ of a
>>> solver will not exist anymore, which fits reality a lot better than the
>>> current class libraries: _every_ robotic system has slightly different
>>> sets
>>> of inputs and outputs, especially when also taking control and estimation
>>> into account.
>>>
>>
>> I like the idea but in this case we need a structure that stores all
>> the data needed by the different "visitors" (solvers) which is not the
>> kinematic structure itself?
>
>
> Yes, this is not a simple design issue! I am preparing some thoughts in
> this direction, but don't hold your breath.
>

Ok, maybe we should mark that as our goal for KDL 2.0 ;)

>
>> I would be happy to see a proof of concept of this for this particular
>> use case, an inverse velocity kinematics solver that can handle joint
>> space position and velocity limits and cartesian space velocity
>> limits, that would fit in the scope of Orocos KDL.
>
>
> I think this is a very valid remark to make: a "show me the code" proof of
> concept. Any takers to help me out with this, i.e., someone with a full
> week of effort available somewhere in the coming months?
>
>>>> Best wishes
>>>> Marcus Liebhardt
>
>
>> Ruben
>
>
> Herman

Ruben

[Bug 837] A new tree IK position solver for online/real-time cal

Am 23. Februar 2012 20:34 schrieb Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...>:

> On Thu, 23 Feb 2012, Marcus Liebhardt wrote:
>
> Am 17. Februar 2012 17:53 schrieb Ruben Smits <
>> ruben [dot] smits [..] ...>**:
>>
>> http://bugs.orocos.org/show
>> g
>>
>> _bug.cgi?id=837
>>
>> Ruben Smits <ruben [dot] smits [..] ...> changed:
>>
>> What |Removed |Added
>> ------------------------------**------------------------------**
>> ----------------
>> Status|NEW |ASSIGNED
>>
>> --- Comment #2 from Ruben Smits <ruben [dot] smits [..] ...>
>> 2012-02-17
>> 09:53:57 CET ---
>> I changed my mind on this one,
>>
>>
>> Ha, I can't believe it! I already gave up on this one. But it seems like
>> that
>> contribution was more persistent than me. After being sent in a year ago,
>> revived
>> after some months, it finally got through! :-)
>> This remembers me of something, I wanted to write to the list a long time
>> ago.
>>
>> An interesting discussion followed the present contribution (see
>> "Questions and
>> suggestions about tree inverse kinematic solvers" on this list [1]). The
>> result of
>> this discussion was, that some modifications should be applied to the
>> solver in order
>> to make it a suitable addition to the library. However, the actual
>> details about what
>> should be changed were left in the dark. That was quite unfortunate,
>> since I hadn't
>> the skills to implement the required changes myself and was too busy with
>> my thesis to
>> dig deep and find out what I need to do. So, in the end this contribution
>> "died" more
>> or less for me.
>>
>> I remember that the topic of how to handle community/user contributions
>> has already
>> been addressed in the past at least once. I want to note that I do
>> appreciate the
>> strong will in this community to keep the code quality high by making
>> sure potential
>> contributions align with the existing requirements/policies. But when
>> doing so, I
>> would like to see those requesting changes providing more help for those
>> who should
>> apply them. This help shall not be doing the actual work on that
>> contribution, but
>> providing enough information for the contributor to be able to apply the
>> requested
>> changes himself.
>> So, these are my two cents. Let's go back to the actual topic.
>>
>> The present patch is actually quite outdated. Since the proposal the
>> solver has been
>> developed further. Some changes have been applied and more features
>> added, e.g.
>> iterations were put back in and exponential smoothing was added. We are
>> using this
>> solver now for nearly a year and it serves us quite well. The current
>> code can be
>> found on github (see [2] & [3]).
>> There are still some things I'm not happy/sure about. Some of these
>> things have been
>> addressed in the discussion I mentioned before. For example, the solver
>> housing task
>> and joint space limiting and exponential smoothing looks a bit overloaded
>> to me. There
>> are probably better ways to implement these features.
>> So, I will create a patch of the new against the old version and I'm
>> looking forward
>> to your feedback!
>>
>
> My feedback is the following: in this history of kinematic solvers, we see
> the same unfortunate evolution as in most other robotics functionality
> libraries: planners, point cloud, openCV, ... And that is that people can
> only think, design and code in terms of class libraries, providing one or
> more new API calls everytime they extend existing functionality.
>
> This approach is NOT SCALABLE:
> - every new solver copies 80-90% of code from an already existing solver,
> so an update to the shared core requires ever more efforts to be applied
> to all derived solvers
> - every new solver (including this one) introduces "legacy" that is only
> relevant/meaningful for the developer of the new solver, but not
> necessarilty for every user of the functionality. For example: the
> documentation of inputs and outputs, the use or not-use of "assert"s, the
> precise policy to avoid joint limits, the coupling estimators, etc.
> - functional extensions are done via "inheritance" instead of by the much
> more "composition", which is a lot more scalable and flexible (whenever
> it can be applied).
> The result is an ever increasing slowdown of patch application and of code
> reuse (read: code reuse as complete function blocks, and not as "copy and
> post" from one C++ file to another). That's not where I want this project
> to go, on the contrary.
>
>
I think, I understand the above and I agree, that doesn't sound like a good
way to go.

> More concretely, here is my suggestion for the future: kinematic solvers
> should be refactored from a "class library" paradigm into a "data flow"
> paradigm. That means that new functionality is added "function block" by
> function block, and not "full class by full class". The core of all the
> current solvers is the same: do some inward and outward sweeps over the
> kinematic structure, and then do operations at every joint and/or link,
> with some extra things at the root, the leaves and the junctions of trees.
> _The_ more scalable approach would consist of coding this sweepings
> separately, providing a "plug in" set of hooks allowing extensions to be
> done by composition (e.g., checking or controlling joint position limit
> violations every time a joint is traversed in the sweeps). _The API_ of a
> solver will not exist anymore, which fits reality a lot better than the
> current class libraries: _every_ robotic system has slightly different sets
> of inputs and outputs, especially when also taking control and estimation
> into account.
>
>
This is a quite abstract explanation, but I think get (most of) the idea
here. I would be happy, if you (or others) could elaborate at bit more on
or point me to literature about the present topic(s).
My specific questions are:
* Are you talking about modular programming?
* How could these plug-ins you are talking about look like?
* What do you mean with that _the API_ (aka _the one_/single API?) of a
solver will not exist any more? How would such a general or generic API
look like?

Let me try to apply what I understood so far. I hope this goes into the
direction you are suggesting.
I move the functions like task and joint space limiting, as well as
exponential smoothing, out of the solver and into - let's say - a KDL tools
library.
"My" new solver will then be composed of the set of tools/functionalities I
need. Since these functionalities will only be called, the solver itself
will consist of much less code.

Are these things you are talking about already used/applied in other parts
of Orocos? I would be very happy about code examples, in which your
suggestions are implemented/applied/used.

>
>> Best wishes
>> Marcus Liebhardt
>>
>
> Herman
>

Thanks for the feedback and help!

Marcus

>
>
>> [1]http://www.orocos.org/**forum/rtt/rtt-dev/questions-**
>> and-suggestions-about-tree-**inverse-<http://www.orocos.org/forum/rtt/rtt-dev/questions-and-suggestions-about-tree-inverse->
>> kinematic-solvers
>> [2]https://github.com/pal-**robotics/reem_teleop/blob/**
>> master/tree_kinematics/**include/tree_<https://github.com/pal-robotics/reem_teleop/blob/master/tree_kinematics/include/tree_>
>> kinematics/treeiksolverpos_**online.hpp
>> [3]https://github.com/pal-**robotics/reem_teleop/blob/**
>> master/tree_kinematics/src/**treeiksol<https://github.com/pal-robotics/reem_teleop/blob/master/tree_kinematics/src/treeiksol>
>>
>> verpos_online.cpp
>>
>>
>>
>> I already included the solver in master:
>> commit 554377c8d0a004be224430a7bb56d3**9fe5499335
>>
>> But I'm not so keen on all the asserts in the code. These should be
>> replaced by
>> error codes.
>>
>> --
>> Configure bugmail: http://bugs.orocos.org/**userprefs.cgi?tab=email<http://bugs.orocos.org/...
>> ------- You are receiving this mail because: -------
>> You are the assignee for the bug.
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ....**kuleuven.be<Orocos-Dev [..] ...>
>> http://lists.mech.kuleuven.be/**mailman/listinfo/orocos-dev<http://lists...
>>
>>
>>
>> --
>> Dipl.-Ing. (M.Sc.) Marcus Liebhardt
>> Control Engineer
>> Yujin Robot
>> Address (Korean): ???? ??? ??? ??? 345-30 ????? #601, 153-023.
>> Address (English): #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu,
>> Seoul,
>> 153-023, Republic of Korea
>> Website: http://www.yujinrobot.com
>> Email: marcus.liebhardt@yujinrobot.**com<marcus [dot] liebhardt [..] ...>
>> Phone: +82-2-2026-1400
>>
>>
>>
> --
> KU Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.**be/~bruyninc<http://people.mech.kuleuven.be/%7Ebruyninc>>
> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network) <
> http://www.euron.org>
> Open Realtime Control Services <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

[Bug 837] A new tree IK position solver for online/real-time cal

On Fri, 24 Feb 2012, Marcus Liebhardt wrote:

> Am 23. Februar 2012 20:34 schrieb Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...>:
> On Thu, 23 Feb 2012, Marcus Liebhardt wrote:
>
> Am 17. Februar 2012 17:53 schrieb Ruben Smits
> <ruben [dot] smits [..] ...>:
>
>      http://bugs.orocos.org/show
>            g
>
>      _bug.cgi?id=837
>
>      Ruben Smits <ruben [dot] smits [..] ...> changed:
>
>                What    |Removed                     |Added
>    
>  ----------------------------------------------------------------------------
>                  Status|NEW                         |ASSIGNED
>
>      --- Comment #2 from Ruben Smits
> <ruben [dot] smits [..] ...> 2012-02-17
>      09:53:57 CET ---
>      I changed my mind on this one,
>
>
> Ha, I can't believe it! I already gave up on this one. But it
> seems like that
> contribution was more persistent than me. After being sent in
> a year ago, revived
> after some months, it finally got through! :-)
> This remembers me of something, I wanted to write to the list
> a long time ago.
>
> An interesting discussion followed the present contribution
> (see "Questions and
> suggestions about tree inverse kinematic solvers" on this list
> [1]). The result of
> this discussion was, that some modifications should be applied
> to the solver in order
> to make it a suitable addition to the library. However, the
> actual details about what
> should be changed were left in the dark. That was quite
> unfortunate, since I hadn't
> the skills to implement the required changes myself and was
> too busy with my thesis to
> dig deep and find out what I need to do. So, in the end this
> contribution "died" more
> or less for me.
>
> I remember that the topic of how to handle community/user
> contributions has already
> been addressed in the past at least once. I want to note that
> I do appreciate the
> strong will in this community to keep the code quality high by
> making sure potential
> contributions align with the existing requirements/policies.
> But when doing so, I
> would like to see those requesting changes providing more help
> for those who should
> apply them. This help shall not be doing the actual work on
> that contribution, but
> providing enough information for the contributor to be able to
> apply the requested
> changes himself.
> So, these are my two cents. Let's go back to the actual topic.
>
> The present patch is actually quite outdated. Since the
> proposal the solver has been
> developed further. Some changes have been applied and more
> features added, e.g.
> iterations were put back in and exponential smoothing was
> added. We are using this
> solver now for nearly a year and it serves us quite well. The
> current code can be
> found on github (see [2] & [3]).
> There are still some things I'm not happy/sure about. Some of
> these things have been
> addressed in the discussion I mentioned before. For example,
> the solver housing task
> and joint space limiting and exponential smoothing looks a bit
> overloaded to me. There
> are probably better ways to implement these features.
> So, I will create a patch of the new against the old version
> and I'm looking forward
> to your feedback!
>
>
> My feedback is the following: in this history of kinematic solvers, we see
> the same unfortunate evolution as in most other robotics functionality
> libraries: planners, point cloud, openCV, ... And that is that people can
> only think, design and code in terms of class libraries, providing one or
> more new API calls everytime they extend existing functionality.
>
> This approach is NOT SCALABLE:
> - every new solver copies 80-90% of code from an already existing solver,
>  so an update to the shared core requires ever more efforts to be applied
>  to all derived solvers
> - every new solver (including this one) introduces "legacy" that is only
>  relevant/meaningful for the developer of the new solver, but not
>  necessarilty for every user of the functionality. For example: the
>  documentation of inputs and outputs, the use or not-use of "assert"s, the
>  precise policy to avoid joint limits, the coupling estimators, etc.
> - functional extensions are done via "inheritance" instead of by the much
>  more "composition", which is a lot more scalable and flexible (whenever
>  it can be applied).
> The result is an ever increasing slowdown of patch application and of code
> reuse (read: code reuse as complete function blocks, and not as "copy and
> post" from one C++ file to another). That's not where I want this project
> to go, on the contrary.
>
>
> I think, I understand the above and I agree, that doesn't sound like a good way to go.
>  
> More concretely, here is my suggestion for the future: kinematic solvers
> should be refactored from a "class library" paradigm into a "data flow"
> paradigm. That means that new functionality is added "function block" by
> function block, and not "full class by full class". The core  of all the
> current solvers is the same: do some inward and outward sweeps over the
> kinematic structure, and then do operations at every joint and/or link,
> with some extra things at the root, the leaves and the junctions of trees.
> _The_ more scalable approach would consist of coding this sweepings
> separately, providing a "plug in" set of hooks allowing extensions to be
> done by composition (e.g., checking or controlling joint position limit
> violations every time a joint is traversed in the sweeps). _The API_ of a
> solver will not exist anymore, which fits reality a lot better than the
> current class libraries: _every_ robotic system has slightly different
> sets
> of inputs and outputs, especially when also taking control and estimation
> into account.
>
>
> This is a quite abstract explanation, but I think get (most of) the idea here. I would
> be happy, if you (or others) could elaborate at bit more on or point me to literature
> about the present topic(s).

I don't know any, except maybe the book on Flow-based Programming
<http://www.jpaulmorrison.com/fbp/>
although my suggestions are a bit different.
<http://en.wikipedia.org/wiki/Flow-based_programming> and
<http://en.wikipedia.org/wiki/Functional_programming> also go in the same
direction.

> My specific questions are:
> * Are you talking about modular programming?

Depends on what you mean by that term :-)

> * How could these plug-ins you are talking about look like?

They will look _very_ much like the code I see being added to the KLD IK
solvers every time a new solver arrives: a "filter" function, a "distance
monitoring" function, etc.

> * What do you mean with that _the API_ (aka _the one_/single API?) of a solver will
> not exist any more? How would such a general or generic API look like?

Forget about class libraries and their APIs; think "functional
programming", but then in a component-based context. Hence, the software
equivalent of the _hardware_ computational components, namely DSP blocks,
FPGA cores, GPU threads, etc.

> Let me try to apply what I understood so far. I hope this goes into the direction you
> are suggesting.
> I move the functions like task and joint space limiting, as well as exponential
> smoothing, out of the solver and into - let's say - a KDL tools library.

No, further away, since the computations themselves are a lot more general
than their application in kinematics :-) These things would go in something
like a "Systems & Control Library".

> "My" new solver will then be composed of the set of tools/functionalities I need.
> Since these functionalities will only be called, the solver itself will consist of
> much less code.

Yes. I do not yet have a good idea how to best "compose" a new
solver....:-(

> Are these things you are talking about already used/applied in other parts of Orocos?

No. But "big players" like Simulink, 20Sim or LabView use that approach for
years already.

> I would be very happy about code examples, in which your suggestions are
> implemented/applied/used.

None yet!

> Best wishes
> Marcus Liebhardt

Herman