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>

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