http://bugs.orocos.org/show_bug.cgi?id=1044
Summary: Broken error propogation logic within solvers
Product: KDL
Version: kdl-trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component: Kinematic Solvers
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
Estimated Hours: 0.0
[I've discussed this separately with Ruben, and hope that the following
description makes sense]
A number of KDL solvers use underlying solvers or separate computations to do
part of their work (e.g. chainiksolverpos_nr uses an IK velocity solver
provided to it, while chainiksolvervel_wdls uses an SVD computation underneath
it), but fail to correctly propogate failure of any underlying computation.
There is also a question of what should be propogated if an underlying
computation fails. Should it be a) the raw return code from the underlying
computation, or b) a return code specific to this solver that simply indicates
that the underlying computation failed. The first approach means you have to
avoid duplicate error codes between the parent and any underlying
solver/computation (as one will mask the other), while the second approach
loses any information on the actual error that occured in the underlying
solver/computation. Both cases are particularly prevalent if user created (ie
non-KDL) solvers are used instead of KDL solvers.
Example
{{{
KDL::Chain = some chain;
ChainFkSolverPos_recursive fksolver1(chain);
ChainIkSolverVel_pinv iksolvervel(chain);
ChainIkSolverPos_NR iksolverpos(chain,fksolver,iksolvervel);
...
int rc = iksolverpos->CartToJnt(...);
}}}
If the velocity solver iksolvervel, which is used by iksolverpos in the
CartToJnt() call fails, then how do we find out what actually happened in
iksolvervel? Was it a convergence error? Was it a singularity? etc.
Currently iksolverpos in the above case will return -3 and any error code from
iksolvervel is lost. Why would we care? Well with certain solvers, failure to
converge may result in different behaviour from hitting a singularity (e.g. you
may continue moving with a degraded result in one case, but not the other).
If you modify my patch for #1043 to return the "rc" error code from the IK
velocity solver, then you're assuming that any set of error codes from any
given IK velocity solver (as given to the iksolverpos in it's constructor) are
disjoint from the error codes of the IK position solver. This isn't scalable to
larger systems.
Now in the example cod eabove the user has access to both iksolvervel and
iksolverpos, and so if iksolverpos returned an error code indicating that the
given IK velocity solver failed, then the caller could query the iksolvervel
object directly to determine its last error code (presuming it was modified to
store the last error code ala errno). If all solvers had the same error
behaviour then arbitrary hierarchies of solvers could be used, and each solver
need only store its last error code, and be able to inform the user when a
particular underlying solver failed (and so the user would have to query the
underlying solver directly to determine how it actually failed). This decouples
the parent solver from having to know anything about the error codes of the
underlying, child solvers.
Note that cases like chainiksolvervel_wdls, which use an SVD computation
underneath, will have to either store the SVD result separately, provide some
way to map all the SVD error codes into the error codes of the WDLS solver, or
the SVD computation should be wrapped like a solver with it's own last error
code made available.
[Bug 1044] New: Broken error propogation logic within solvers
On Tue, 8 Oct 2013, S Roderick wrote:
> http://bugs.orocos.org/show_bug.cgi?id=1044
>
> Summary: Broken error propogation logic within solvers
> Product: KDL
> Version: kdl-trunk
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: enhancement
> Priority: P3
> Component: Kinematic Solvers
> AssignedTo: orocos-dev [..] ...
> ReportedBy: kiwi [dot] net [..] ...
> Estimated Hours: 0.0
>
> [I've discussed this separately with Ruben, and hope that the following
> description makes sense]
>
Thanks for the nice summary of problems described below! They are exactly
the reason why I started to fight severely against class libraries for
"solvers" of any kind, and the "information hiding behind standardized
APIs" that goes naturally with it. Both are not scalable, and too
restrictive.
Instead, we are now developing a "function blocks on steroids" framework,
based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
positioned somewhere between OO class libraries and RTT components,
introducing "scheduling" and "composable Ports" as the major primitives to
deal with the mentioned problems.
Stay tuned!
> A number of KDL solvers use underlying solvers or separate computations to do
> part of their work (e.g. chainiksolverpos_nr uses an IK velocity solver
> provided to it, while chainiksolvervel_wdls uses an SVD computation underneath
> it), but fail to correctly propogate failure of any underlying computation.
> There is also a question of what should be propogated if an underlying
> computation fails. Should it be a) the raw return code from the underlying
> computation, or b) a return code specific to this solver that simply indicates
> that the underlying computation failed. The first approach means you have to
> avoid duplicate error codes between the parent and any underlying
> solver/computation (as one will mask the other), while the second approach
> loses any information on the actual error that occured in the underlying
> solver/computation. Both cases are particularly prevalent if user created (ie
> non-KDL) solvers are used instead of KDL solvers.
>
> Example
> {{{
> KDL::Chain = some chain;
> ChainFkSolverPos_recursive fksolver1(chain);
> ChainIkSolverVel_pinv iksolvervel(chain);
> ChainIkSolverPos_NR iksolverpos(chain,fksolver,iksolvervel);
> ...
> int rc = iksolverpos->CartToJnt(...);
> }}}
> If the velocity solver iksolvervel, which is used by iksolverpos in the
> CartToJnt() call fails, then how do we find out what actually happened in
> iksolvervel? Was it a convergence error? Was it a singularity? etc.
>
> Currently iksolverpos in the above case will return -3 and any error code from
> iksolvervel is lost. Why would we care? Well with certain solvers, failure to
> converge may result in different behaviour from hitting a singularity (e.g. you
> may continue moving with a degraded result in one case, but not the other).
>
> If you modify my patch for #1043 to return the "rc" error code from the IK
> velocity solver, then you're assuming that any set of error codes from any
> given IK velocity solver (as given to the iksolverpos in it's constructor) are
> disjoint from the error codes of the IK position solver. This isn't scalable to
> larger systems.
>
> Now in the example cod eabove the user has access to both iksolvervel and
> iksolverpos, and so if iksolverpos returned an error code indicating that the
> given IK velocity solver failed, then the caller could query the iksolvervel
> object directly to determine its last error code (presuming it was modified to
> store the last error code ala errno). If all solvers had the same error
> behaviour then arbitrary hierarchies of solvers could be used, and each solver
> need only store its last error code, and be able to inform the user when a
> particular underlying solver failed (and so the user would have to query the
> underlying solver directly to determine how it actually failed). This decouples
> the parent solver from having to know anything about the error codes of the
> underlying, child solvers.
>
> Note that cases like chainiksolvervel_wdls, which use an SVD computation
> underneath, will have to either store the SVD result separately, provide some
> way to map all the SVD error codes into the error codes of the WDLS solver, or
> the SVD computation should be wrapped like a solver with it's own last error
> code made available.
Herman
[Bug 1044] New: Broken error propogation logic within solvers
Hello,
Even though not much active in the Orocos community, here are my two cents
on this topic.
2013/10/8 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Tue, 8 Oct 2013, S Roderick wrote:
>
> > http://bugs.orocos.org/show_bug.cgi?id=1044
> >
> > Summary: Broken error propogation logic within solvers
> > Product: KDL
> > Version: kdl-trunk
> > Platform: All
> > OS/Version: All
> > Status: NEW
> > Severity: enhancement
> > Priority: P3
> > Component: Kinematic Solvers
> > AssignedTo: orocos-dev [..] ...
> > ReportedBy: kiwi [dot] net [..] ...
> > Estimated Hours: 0.0
> >
> > [I've discussed this separately with Ruben, and hope that the following
> > description makes sense]
> >
>
> Thanks for the nice summary of problems described below! They are exactly
> the reason why I started to fight severely against class libraries for
> "solvers" of any kind, and the "information hiding behind standardized
> APIs" that goes naturally with it. Both are not scalable, and too
> restrictive.
>
I clearly agree that solvers should be used as components more than in a
classical API way. That clearly allows for more flexibility and less
undesired entanglement between the specific problem to be solved and the
general solver used to solve it.
> Instead, we are now developing a "function blocks on steroids" framework,
> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
> positioned somewhere between OO class libraries and RTT components,
> introducing "scheduling" and "composable Ports" as the major primitives to
> deal with the mentioned problems.
>
> Stay tuned!
>
> > A number of KDL solvers use underlying solvers or separate computations
> to do
> > part of their work (e.g. chainiksolverpos_nr uses an IK velocity solver
> > provided to it, while chainiksolvervel_wdls uses an SVD computation
> underneath
> > it), but fail to correctly propogate failure of any underlying
> computation.
> > There is also a question of what should be propogated if an underlying
> > computation fails. Should it be a) the raw return code from the
> underlying
> > computation, or b) a return code specific to this solver that simply
> indicates
> > that the underlying computation failed. The first approach means you
> have to
> > avoid duplicate error codes between the parent and any underlying
> > solver/computation (as one will mask the other), while the second
> approach
> > loses any information on the actual error that occured in the underlying
> > solver/computation. Both cases are particularly prevalent if user
> created (ie
> > non-KDL) solvers are used instead of KDL solvers.
> >
> > Example
> > {{{
> > KDL::Chain = some chain;
> > ChainFkSolverPos_recursive fksolver1(chain);
> > ChainIkSolverVel_pinv iksolvervel(chain);
> > ChainIkSolverPos_NR iksolverpos(chain,fksolver,iksolvervel);
> > ...
> > int rc = iksolverpos->CartToJnt(...);
> > }}}
> > If the velocity solver iksolvervel, which is used by iksolverpos in the
> > CartToJnt() call fails, then how do we find out what actually happened in
> > iksolvervel? Was it a convergence error? Was it a singularity? etc.
> >
> > Currently iksolverpos in the above case will return -3 and any error
> code from
> > iksolvervel is lost. Why would we care? Well with certain solvers,
> failure to
> > converge may result in different behaviour from hitting a singularity
> (e.g. you
> > may continue moving with a degraded result in one case, but not the
> other).
> >
> > If you modify my patch for #1043 to return the "rc" error code from the
> IK
> > velocity solver, then you're assuming that any set of error codes from
> any
> > given IK velocity solver (as given to the iksolverpos in it's
> constructor) are
> > disjoint from the error codes of the IK position solver. This isn't
> scalable to
> > larger systems.
> >
> > Now in the example cod eabove the user has access to both iksolvervel and
> > iksolverpos, and so if iksolverpos returned an error code indicating
> that the
> > given IK velocity solver failed, then the caller could query the
> iksolvervel
> > object directly to determine its last error code (presuming it was
> modified to
> > store the last error code ala errno). If all solvers had the same error
> > behaviour then arbitrary hierarchies of solvers could be used, and each
> solver
> > need only store its last error code, and be able to inform the user when
> a
> > particular underlying solver failed (and so the user would have to query
> the
> > underlying solver directly to determine how it actually failed). This
> decouples
> > the parent solver from having to know anything about the error codes of
> the
> > underlying, child solvers.
> >
> > Note that cases like chainiksolvervel_wdls, which use an SVD computation
> > underneath, will have to either store the SVD result separately, provide
> some
> > way to map all the SVD error codes into the error codes of the WDLS
> solver, or
> > the SVD computation should be wrapped like a solver with it's own last
> error
> > code made available.
>
Even though I contributed to the writing of this solver
(chainiksolvervel_wdls), which at that time was probably providing the most
tunable and general way to compute an analytical solution to the inverse
velocity kinematics problem, I am now convinced that this is not the way to
go. People should definitely switch to solvers (at the velocity kinematics
or dynamics level) which allow to formulate the control problem using only
forward models and allowing to express inequality constraints in a
"natural" way.
>
> Herman
>
Vincent
[Bug 1044] New: Broken error propogation logic within solvers
Hi Herman,
On Tue, Oct 8, 2013 at 7:22 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 8 Oct 2013, S Roderick wrote:
>
> > http://bugs.orocos.org/show_bug.cgi?id=1044
> >
> > Summary: Broken error propogation logic within solvers
> > Product: KDL
> > Version: kdl-trunk
> > Platform: All
> > OS/Version: All
> > Status: NEW
> > Severity: enhancement
> > Priority: P3
> > Component: Kinematic Solvers
> > AssignedTo: orocos-dev [..] ...
> > ReportedBy: kiwi [dot] net [..] ...
> > Estimated Hours: 0.0
> >
> > [I've discussed this separately with Ruben, and hope that the following
> > description makes sense]
> >
>
> Thanks for the nice summary of problems described below! They are exactly
> the reason why I started to fight severely against class libraries for
> "solvers" of any kind, and the "information hiding behind standardized
> APIs" that goes naturally with it. Both are not scalable, and too
> restrictive.
>
> Instead, we are now developing a "function blocks on steroids" framework,
> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
> positioned somewhere between OO class libraries and RTT components,
> introducing "scheduling" and "composable Ports" as the major primitives to
> deal with the mentioned problems.
>
Could you elaborate a bit on how this framework would deal with the
specific problem Stephen describes?
Ruben
>
> Stay tuned!
>
> > A number of KDL solvers use underlying solvers or separate computations
> to do
> > part of their work (e.g. chainiksolverpos_nr uses an IK velocity solver
> > provided to it, while chainiksolvervel_wdls uses an SVD computation
> underneath
> > it), but fail to correctly propogate failure of any underlying
> computation.
> > There is also a question of what should be propogated if an underlying
> > computation fails. Should it be a) the raw return code from the
> underlying
> > computation, or b) a return code specific to this solver that simply
> indicates
> > that the underlying computation failed. The first approach means you
> have to
> > avoid duplicate error codes between the parent and any underlying
> > solver/computation (as one will mask the other), while the second
> approach
> > loses any information on the actual error that occured in the underlying
> > solver/computation. Both cases are particularly prevalent if user
> created (ie
> > non-KDL) solvers are used instead of KDL solvers.
> >
> > Example
> > {{{
> > KDL::Chain = some chain;
> > ChainFkSolverPos_recursive fksolver1(chain);
> > ChainIkSolverVel_pinv iksolvervel(chain);
> > ChainIkSolverPos_NR iksolverpos(chain,fksolver,iksolvervel);
> > ...
> > int rc = iksolverpos->CartToJnt(...);
> > }}}
> > If the velocity solver iksolvervel, which is used by iksolverpos in the
> > CartToJnt() call fails, then how do we find out what actually happened in
> > iksolvervel? Was it a convergence error? Was it a singularity? etc.
> >
> > Currently iksolverpos in the above case will return -3 and any error
> code from
> > iksolvervel is lost. Why would we care? Well with certain solvers,
> failure to
> > converge may result in different behaviour from hitting a singularity
> (e.g. you
> > may continue moving with a degraded result in one case, but not the
> other).
> >
> > If you modify my patch for #1043 to return the "rc" error code from the
> IK
> > velocity solver, then you're assuming that any set of error codes from
> any
> > given IK velocity solver (as given to the iksolverpos in it's
> constructor) are
> > disjoint from the error codes of the IK position solver. This isn't
> scalable to
> > larger systems.
> >
> > Now in the example cod eabove the user has access to both iksolvervel and
> > iksolverpos, and so if iksolverpos returned an error code indicating
> that the
> > given IK velocity solver failed, then the caller could query the
> iksolvervel
> > object directly to determine its last error code (presuming it was
> modified to
> > store the last error code ala errno). If all solvers had the same error
> > behaviour then arbitrary hierarchies of solvers could be used, and each
> solver
> > need only store its last error code, and be able to inform the user when
> a
> > particular underlying solver failed (and so the user would have to query
> the
> > underlying solver directly to determine how it actually failed). This
> decouples
> > the parent solver from having to know anything about the error codes of
> the
> > underlying, child solvers.
> >
> > Note that cases like chainiksolvervel_wdls, which use an SVD computation
> > underneath, will have to either store the SVD result separately, provide
> some
> > way to map all the SVD error codes into the error codes of the WDLS
> solver, or
> > the SVD computation should be wrapped like a solver with it's own last
> error
> > code made available.
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Bug 1044] New: Broken error propogation logic within solvers
On Oct 8, 2013 7:55 PM, "Ruben Smits" <ruben [dot] smits [..] ...> wrote:
>
> Hi Herman,
>
>
> On Tue, Oct 8, 2013 at 7:22 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> On Tue, 8 Oct 2013, S Roderick wrote:
>>
>> > http://bugs.orocos.org/show_bug.cgi?id=1044
>> >
>> > Summary: Broken error propogation logic within solvers
>> > Product: KDL
>> > Version: kdl-trunk
>> > Platform: All
>> > OS/Version: All
>> > Status: NEW
>> > Severity: enhancement
>> > Priority: P3
>> > Component: Kinematic Solvers
>> > AssignedTo: orocos-dev [..] ...
>> > ReportedBy: kiwi [dot] net [..] ...
>> > Estimated Hours: 0.0
>> >
>> > [I've discussed this separately with Ruben, and hope that the following
>> > description makes sense]
>> >
>>
>> Thanks for the nice summary of problems described below! They are exactly
>> the reason why I started to fight severely against class libraries for
>> "solvers" of any kind, and the "information hiding behind standardized
>> APIs" that goes naturally with it. Both are not scalable, and too
>> restrictive.
>>
>> Instead, we are now developing a "function blocks on steroids" framework,
>> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
>> positioned somewhere between OO class libraries and RTT components,
>> introducing "scheduling" and "composable Ports" as the major primitives
to
>> deal with the mentioned problems.
>
>
> Could you elaborate a bit on how this framework would deal with the
specific problem Stephen describes?
+1
I am interested in this too.
/Sagar
> Ruben
>
>>
>>
>> Stay tuned!
>>
>> > A number of KDL solvers use underlying solvers or separate
computations to do
>> > part of their work (e.g. chainiksolverpos_nr uses an IK velocity solver
>> > provided to it, while chainiksolvervel_wdls uses an SVD computation
underneath
>> > it), but fail to correctly propogate failure of any underlying
computation.
>> > There is also a question of what should be propogated if an underlying
>> > computation fails. Should it be a) the raw return code from the
underlying
>> > computation, or b) a return code specific to this solver that simply
indicates
>> > that the underlying computation failed. The first approach means you
have to
>> > avoid duplicate error codes between the parent and any underlying
>> > solver/computation (as one will mask the other), while the second
approach
>> > loses any information on the actual error that occured in the
underlying
>> > solver/computation. Both cases are particularly prevalent if user
created (ie
>> > non-KDL) solvers are used instead of KDL solvers.
>> >
>> > Example
>> > {{{
>> > KDL::Chain = some chain;
>> > ChainFkSolverPos_recursive fksolver1(chain);
>> > ChainIkSolverVel_pinv iksolvervel(chain);
>> > ChainIkSolverPos_NR iksolverpos(chain,fksolver,iksolvervel);
>> > ...
>> > int rc = iksolverpos->CartToJnt(...);
>> > }}}
>> > If the velocity solver iksolvervel, which is used by iksolverpos in the
>> > CartToJnt() call fails, then how do we find out what actually happened
in
>> > iksolvervel? Was it a convergence error? Was it a singularity? etc.
>> >
>> > Currently iksolverpos in the above case will return -3 and any error
code from
>> > iksolvervel is lost. Why would we care? Well with certain solvers,
failure to
>> > converge may result in different behaviour from hitting a singularity
(e.g. you
>> > may continue moving with a degraded result in one case, but not the
other).
>> >
>> > If you modify my patch for #1043 to return the "rc" error code from
the IK
>> > velocity solver, then you're assuming that any set of error codes from
any
>> > given IK velocity solver (as given to the iksolverpos in it's
constructor) are
>> > disjoint from the error codes of the IK position solver. This isn't
scalable to
>> > larger systems.
>> >
>> > Now in the example cod eabove the user has access to both iksolvervel
and
>> > iksolverpos, and so if iksolverpos returned an error code indicating
that the
>> > given IK velocity solver failed, then the caller could query the
iksolvervel
>> > object directly to determine its last error code (presuming it was
modified to
>> > store the last error code ala errno). If all solvers had the same error
>> > behaviour then arbitrary hierarchies of solvers could be used, and
each solver
>> > need only store its last error code, and be able to inform the user
when a
>> > particular underlying solver failed (and so the user would have to
query the
>> > underlying solver directly to determine how it actually failed). This
decouples
>> > the parent solver from having to know anything about the error codes
of the
>> > underlying, child solvers.
>> >
>> > Note that cases like chainiksolvervel_wdls, which use an SVD
computation
>> > underneath, will have to either store the SVD result separately,
provide some
>> > way to map all the SVD error codes into the error codes of the WDLS
solver, or
>> > the SVD computation should be wrapped like a solver with it's own last
error
>> > code made available.
>>
>> Herman
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
>
>
> --
> Ruben Smits, CTO
> +32 479 511 786
> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
> www.intermodalics.eu
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Bug 1044] New: Broken error propogation logic within solvers
On Tue, 8 Oct 2013, Sagar Behere wrote:
[...]
> >> Thanks for the nice summary of problems described below! They are exactly
> >> the reason why I started to fight severely against class libraries for
> >> "solvers" of any kind, and the "information hiding behind standardized
> >> APIs" that goes naturally with it. Both are not scalable, and too
> >> restrictive.
> >>
> >> Instead, we are now developing a "function blocks on steroids" framework,
> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
> >> positioned somewhere between OO class libraries and RTT components,
> >> introducing "scheduling" and "composable Ports" as the major primitives to
> >> deal with the mentioned problems.
> >
> >
> > Could you elaborate a bit on how this framework would deal with the specific problem Stephen
> describes?
>
> +1
>
> I am interested in this too.
A software application consists of the integration of many, many functional
pieces of code, each with its own "monitoring" information. The
traditional API-based approach has problems with letting _all_ the
monitoring information be accessible in the whole application, _because_
one wants to communicate all that information through the method call
signature. This does not scale, as is proven by many, many use cases, KDL
being one of them. The "functional components approach", on the other hand,
allows an _application_ to create "ports" and connect them to _any_ piece of
information that is relevant for the _application_. (While the API-based
approach let the _API designer_ decide about what to have visible through
the API and what not.) In order to allow the design of such flexible
application architectures, it is very wise to foresee a "scheduler"
activity that calls the right functionalities in the right way and under
the right conditions. (This includes calling the right _port communication_
functionalities, as well as the right "information forgetting/storage"
functionalities.)
_All_ the successful systems I have ever seen, including the human, allow
even the highest levels of abstraction in the system (e.g., the CEO in a
company) know about low-level errors immediately and fully, when it is
relevant (in the CEO's case: when there is a leak in a pump in the
Fukushima reactor enclosure, the CEO should be able to have direct access
to this information (just by 'switching' the right communication "port",
without that information having to be passed through layers and layers of
"lower level" APIs).
If you ever use this design pattern, please give credits to Markus!!!!
> /Sagar
Herman
[Bug 1044] New: Broken error propogation logic within solvers
On 10/09/2013 08:32 AM, Herman Bruyninckx wrote:
> The
> traditional API-based approach has problems with letting _all_ the
> monitoring information be accessible in the whole application, _because_
> one wants to communicate all that information through the method call
> signature.
Eh. Not since modern programming languages got there. You know, more
than 20 years ago. Sell your 'component-functional-block-oriented'
approach more because of the schedulability / control than monitoring.
Pure monitoring (i.e. status, internal monitoring measures) are usually
passed through dedicated method calls (since they don't have to
interrupt the control flow). This obviously hits the problem of
interpretation: if solver X has a given reporting structure and Y
another, you don't get a 'common' monitoring capability, and inheritance
can be used to provide common generic monitoring information without
losing the more detailed one.
Errors are passed through exceptions, which is allows for error
classification, inheritance and enrichment. The inheritance here, again,
allows for generic code to interpret part of the errors it can interpret
without loss of information.
[Bug 1044] New: Broken error propogation logic within solvers
On Wed, 9 Oct 2013, Sylvain Joyeux wrote:
> On 10/09/2013 08:32 AM, Herman Bruyninckx wrote:
>> The
>> traditional API-based approach has problems with letting _all_ the
>> monitoring information be accessible in the whole application, _because_
>> one wants to communicate all that information through the method call
>> signature.
> Eh. Not since modern programming languages got there. You know, more
> than 20 years ago. Sell your 'component-functional-block-oriented'
> approach more because of the schedulability / control than monitoring.
Agreed! The monitoring problem is indeed rather caused by a lack in the
education, not the technology.
> Pure monitoring (i.e. status, internal monitoring measures) are usually
> passed through dedicated method calls (since they don't have to
> interrupt the control flow). This obviously hits the problem of
> interpretation: if solver X has a given reporting structure and Y
> another, you don't get a 'common' monitoring capability, and inheritance
> can be used to provide common generic monitoring information without
> losing the more detailed one.
>
> Errors are passed through exceptions, which is allows for error
> classification, inheritance and enrichment. The inheritance here, again,
> allows for generic code to interpret part of the errors it can interpret
> without loss of information.
Herman
[Bug 1044] New: Broken error propogation logic within solvers
On 10/09/2013 03:40 PM, Herman Bruyninckx wrote:
> Agreed! The monitoring problem is indeed rather caused by a lack in the
> education, not the technology.
And you can't fix it with technology. Components such as RTT do allow
for extended monitoring, but most people are still log()<<"BLA"<<endlog().
>
[Bug 1044] New: Broken error propogation logic within solvers
On Wed, 9 Oct 2013, Sylvain Joyeux wrote:
> On 10/09/2013 03:40 PM, Herman Bruyninckx wrote:
>> Agreed! The monitoring problem is indeed rather caused by a lack in the
>> education, not the technology.
> And you can't fix it with technology. Components such as RTT do allow
> for extended monitoring, but most people are still log()<<"BLA"<<endlog().
Agreed, again!
So, I think that a set of first class tutorials would be something that
the Orocos project could profit from most: not the tutorials that we have
already, about the features of the technology, but tutorials about how to
use these features in the best way...
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
Herman
[Bug 1044] New: Broken error propogation logic within solvers
2013/10/10 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Wed, 9 Oct 2013, Sylvain Joyeux wrote:
>
> > On 10/09/2013 03:40 PM, Herman Bruyninckx wrote:
> >> Agreed! The monitoring problem is indeed rather caused by a lack in the
> >> education, not the technology.
> > And you can't fix it with technology. Components such as RTT do allow
> > for extended monitoring, but most people are still
> log()<<"BLA"<<endlog().
>
> Agreed, again!
>
> So, I think that a set of first class tutorials would be something that
> the Orocos project could profit from most: not the tutorials that we have
> already, about the features of the technology, but tutorials about how to
> use these features in the best way...
>
+1 !!
>
> > Sylvain Joyeux (Dr.Ing.)
> > Senior Researcher
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Bug 1044] New: Broken error propogation logic within solvers
On Oct 9, 2013, at 02:32 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 8 Oct 2013, Sagar Behere wrote:
>
> [...]
>>>> Thanks for the nice summary of problems described below! They are exactly
>>>> the reason why I started to fight severely against class libraries for
>>>> "solvers" of any kind, and the "information hiding behind standardized
>>>> APIs" that goes naturally with it. Both are not scalable, and too
>>>> restrictive.
>>>>
>>>> Instead, we are now developing a "function blocks on steroids" framework,
>>>> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
>>>> positioned somewhere between OO class libraries and RTT components,
>>>> introducing "scheduling" and "composable Ports" as the major primitives to
>>>> deal with the mentioned problems.
>>>
>>>
>>> Could you elaborate a bit on how this framework would deal with the specific problem Stephen
>> describes?
>>
>> +1
>>
>> I am interested in this too.
>
> A software application consists of the integration of many, many functional
> pieces of code, each with its own "monitoring" information. The
> traditional API-based approach has problems with letting _all_ the
> monitoring information be accessible in the whole application, _because_
> one wants to communicate all that information through the method call
> signature. This does not scale, as is proven by many, many use cases, KDL
> being one of them. The "functional components approach", on the other hand,
> allows an _application_ to create "ports" and connect them to _any_ piece of
> information that is relevant for the _application_. (While the API-based
> approach let the _API designer_ decide about what to have visible through
> the API and what not.) In order to allow the design of such flexible
> application architectures, it is very wise to foresee a "scheduler"
> activity that calls the right functionalities in the right way and under
> the right conditions. (This includes calling the right _port communication_
> functionalities, as well as the right "information forgetting/storage"
> functionalities.)
>
> _All_ the successful systems I have ever seen, including the human, allow
> even the highest levels of abstraction in the system (e.g., the CEO in a
> company) know about low-level errors immediately and fully, when it is
> relevant (in the CEO's case: when there is a leak in a pump in the
> Fukushima reactor enclosure, the CEO should be able to have direct access
> to this information (just by 'switching' the right communication "port",
> without that information having to be passed through layers and layers of
> "lower level" APIs).
>
> If you ever use this design pattern, please give credits to Markus!!!!
This sounds like a good idea Herman, but can you provide a concrete example of this potential new approach. Some of what you're talking about sounds like VTK's data pipeline approach, though perhaps with more active "scheduling" and "control".
In all reality, we're not interested in some future potential approach. We need a fix, now, for the problems with the current API. When this future approach is available we'd love to review it, but until then ...
S
[Bug 1044] New: Broken error propogation logic within solvers
On Wed, 9 Oct 2013, S Roderick wrote:
> On Oct 9, 2013, at 02:32 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>
>> On Tue, 8 Oct 2013, Sagar Behere wrote:
>>
>> [...]
>>>>> Thanks for the nice summary of problems described below! They are exactly
>>>>> the reason why I started to fight severely against class libraries for
>>>>> "solvers" of any kind, and the "information hiding behind standardized
>>>>> APIs" that goes naturally with it. Both are not scalable, and too
>>>>> restrictive.
>>>>>
>>>>> Instead, we are now developing a "function blocks on steroids" framework,
>>>>> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
>>>>> positioned somewhere between OO class libraries and RTT components,
>>>>> introducing "scheduling" and "composable Ports" as the major primitives to
>>>>> deal with the mentioned problems.
>>>>
>>>>
>>>> Could you elaborate a bit on how this framework would deal with the specific problem Stephen
>>> describes?
>>>
>>> +1
>>>
>>> I am interested in this too.
>>
>> A software application consists of the integration of many, many functional
>> pieces of code, each with its own "monitoring" information. The
>> traditional API-based approach has problems with letting _all_ the
>> monitoring information be accessible in the whole application, _because_
>> one wants to communicate all that information through the method call
>> signature. This does not scale, as is proven by many, many use cases, KDL
>> being one of them. The "functional components approach", on the other hand,
>> allows an _application_ to create "ports" and connect them to _any_ piece of
>> information that is relevant for the _application_. (While the API-based
>> approach let the _API designer_ decide about what to have visible through
>> the API and what not.) In order to allow the design of such flexible
>> application architectures, it is very wise to foresee a "scheduler"
>> activity that calls the right functionalities in the right way and under
>> the right conditions. (This includes calling the right _port communication_
>> functionalities, as well as the right "information forgetting/storage"
>> functionalities.)
>>
>> _All_ the successful systems I have ever seen, including the human, allow
>> even the highest levels of abstraction in the system (e.g., the CEO in a
>> company) know about low-level errors immediately and fully, when it is
>> relevant (in the CEO's case: when there is a leak in a pump in the
>> Fukushima reactor enclosure, the CEO should be able to have direct access
>> to this information (just by 'switching' the right communication "port",
>> without that information having to be passed through layers and layers of
>> "lower level" APIs).
>>
>> If you ever use this design pattern, please give credits to Markus!!!!
>
> This sounds like a good idea Herman, but can you provide a concrete example of this potential new approach. Some of what you're talking about sounds like VTK's data pipeline approach, though perhaps with more active "scheduling" and "control".
>
That's indeed it! Not more (so rather simple to understand conceptually)
but also not less (hence, capable of dealing with the "curse of API-ality"
problem that was the origin of this thread).
> In all reality, we're not interested in some future potential approach.
> We need a fix, now, for the problems with the current API. When this
> future approach is available we'd love to review it, but until then ...
Sure...
> S
Herman
[Bug 1044] New: Broken error propogation logic within solvers
Hi Herman,
On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 8 Oct 2013, Sagar Behere wrote:
>
> [...]
>
> >> Thanks for the nice summary of problems described below! They are
>> exactly
>> >> the reason why I started to fight severely against class libraries for
>> >> "solvers" of any kind, and the "information hiding behind standardized
>> >> APIs" that goes naturally with it. Both are not scalable, and too
>> >> restrictive.
>> >>
>> >> Instead, we are now developing a "function blocks on steroids"
>> framework,
>> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
>> >> positioned somewhere between OO class libraries and RTT components,
>> >> introducing "scheduling" and "composable Ports" as the major
>> primitives to
>> >> deal with the mentioned problems.
>> >
>> >
>> > Could you elaborate a bit on how this framework would deal with the
>> specific problem Stephen
>> describes?
>>
>> +1
>>
>> I am interested in this too.
>>
>
> A software application consists of the integration of many, many functional
> pieces of code, each with its own "monitoring" information. The
> traditional API-based approach has problems with letting _all_ the
> monitoring information be accessible in the whole application, _because_
> one wants to communicate all that information through the method call
> signature. This does not scale, as is proven by many, many use cases, KDL
> being one of them. The "functional components approach", on the other hand,
> allows an _application_ to create "ports" and connect them to _any_ piece
> of
> information that is relevant for the _application_. (While the API-based
> approach let the _API designer_ decide about what to have visible through
> the API and what not.) In order to allow the design of such flexible
> application architectures, it is very wise to foresee a "scheduler"
> activity that calls the right functionalities in the right way and under
> the right conditions. (This includes calling the right _port communication_
> functionalities, as well as the right "information forgetting/storage"
> functionalities.)
>
> _All_ the successful systems I have ever seen, including the human, allow
> even the highest levels of abstraction in the system (e.g., the CEO in a
> company) know about low-level errors immediately and fully, when it is
> relevant (in the CEO's case: when there is a leak in a pump in the
> Fukushima reactor enclosure, the CEO should be able to have direct access
> to this information (just by 'switching' the right communication "port",
> without that information having to be passed through layers and layers of
> "lower level" APIs).
>
(I hope you realize that this is a bad example. Sadly, in most companies
your example is far from the truth.)
I think this is exactly what we have in mind. Instead of propagating the
errors upstream through the API calls (being CartToJnt or similar), we
would like to add an error "port" to the solvers. So if a top level solver
would report "an" error, the application can contact all low-level solvers
error "ports" to see at which level the error occurred and what happened at
each respective level instead of having to serialize and deserialize error
codes through the API calls.
> If you ever use this design pattern, please give credits to Markus!!!!
>
It's hard to give credit if you have nothing to refer to ;)
Ruben
>
> /Sagar
>>
>
> Herman
>
[Bug 1044] New: Broken error propogation logic within solvers
On Oct 9, 2013, at 02:43 , Ruben Smits <ruben [dot] smits [..] ...> wrote:
> Hi Herman,
>
>
> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 8 Oct 2013, Sagar Behere wrote:
>
> [...]
>
> >> Thanks for the nice summary of problems described below! They are exactly
> >> the reason why I started to fight severely against class libraries for
> >> "solvers" of any kind, and the "information hiding behind standardized
> >> APIs" that goes naturally with it. Both are not scalable, and too
> >> restrictive.
> >>
> >> Instead, we are now developing a "function blocks on steroids" framework,
> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
> >> positioned somewhere between OO class libraries and RTT components,
> >> introducing "scheduling" and "composable Ports" as the major primitives to
> >> deal with the mentioned problems.
> >
> >
> > Could you elaborate a bit on how this framework would deal with the specific problem Stephen
> describes?
>
> +1
>
> I am interested in this too.
>
> A software application consists of the integration of many, many functional
> pieces of code, each with its own "monitoring" information. The
> traditional API-based approach has problems with letting _all_ the
> monitoring information be accessible in the whole application, _because_
> one wants to communicate all that information through the method call
> signature. This does not scale, as is proven by many, many use cases, KDL
> being one of them. The "functional components approach", on the other hand,
> allows an _application_ to create "ports" and connect them to _any_ piece of
> information that is relevant for the _application_. (While the API-based
> approach let the _API designer_ decide about what to have visible through
> the API and what not.) In order to allow the design of such flexible
> application architectures, it is very wise to foresee a "scheduler"
> activity that calls the right functionalities in the right way and under
> the right conditions. (This includes calling the right _port communication_
> functionalities, as well as the right "information forgetting/storage"
> functionalities.)
>
> _All_ the successful systems I have ever seen, including the human, allow
> even the highest levels of abstraction in the system (e.g., the CEO in a
> company) know about low-level errors immediately and fully, when it is
> relevant (in the CEO's case: when there is a leak in a pump in the
> Fukushima reactor enclosure, the CEO should be able to have direct access
> to this information (just by 'switching' the right communication "port",
> without that information having to be passed through layers and layers of
> "lower level" APIs).
>
> (I hope you realize that this is a bad example. Sadly, in most companies your example is far from the truth.)
>
> I think this is exactly what we have in mind. Instead of propagating the errors upstream through the API calls (being CartToJnt or similar), we would like to add an error "port" to the solvers. So if a top level solver would report "an" error, the application can contact all low-level solvers error "ports" to see at which level the error occurred and what happened at each respective level instead of having to serialize and deserialize error codes through the API calls.
Our idea is very slightly different from this. All solvers should inherit from a Solver Interface class that provides simply the latest error number. If a lower level solver fails then it stores the error and its parent solver returns an error code indicating which lower level solver failed. Now the caller, having called the parent solver _but_ having access to both parent and the lower level solver (the application, at least in our use cases, has to have created both explicitly) realises that the parent failed due to a faliure in a particular lower level solver, and now the application can query that particular lower level solver to determine what happened.
For example
solverA = new someIKSolverVel()
solverB = new someIKSolverPos(solverA)
...
rc = solverB->CartToJnt(...)
if (rc == E_SOLVERB_IKSOLVERVEL_FAILED)
rc = solverA->lastErr()
... do something based on the failure in solver A
One could also argue for some standard error codes throughout KDL, e.g. E_NOT_CONVERGE, E_SINGULAR, E_INVALID_PARAM, ...
rather than each solver encoding -1, -2, -3, ..., itself, and sometimes in a different manner.
Lastly, we would also suggest adding "warnings" as well as "errors". Some of the solvers provide a degraded solution, in which case motion can still continue and the parent solver or caller should continue their work. This isn't an error. Perhaps say that 0 == no error, negative = error, and positive = warnings (and so can continue)?
HTH
S
[Bug 1044] New: Broken error propogation logic within solvers
On Wed, 9 Oct 2013, S Roderick wrote:
(Could the experienced and IT-savvy developers on this list please refrain
from using HTML posts... It makes proper/unambiguous/client-independent
indentation of replies impossible.)
> On Oct 9, 2013, at 02:43 , Ruben Smits <ruben [dot] smits [..] ...> wrote:
>
> Hi Herman,
>
> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 8 Oct 2013, Sagar Behere wrote:
>
> [...]
> >> Thanks for the nice summary of problems described below!
> They are exactly
> >> the reason why I started to fight severely against class
> libraries for
> >> "solvers" of any kind, and the "information hiding behind
> standardized
> >> APIs" that goes naturally with it. Both are not scalable,
> and too
> >> restrictive.
> >>
> >> Instead, we are now developing a "function blocks on
> steroids" framework,
> >> based on Markus Klotzbuecher's ideas and code. These
> "micro blocks" are
> >> positioned somewhere between OO class libraries and RTT
> components,
> >> introducing "scheduling" and "composable Ports" as the
> major primitives to
> >> deal with the mentioned problems.
> >
> >
> > Could you elaborate a bit on how this framework would deal
> with the specific problem Stephen
> describes?
>
> +1
>
> I am interested in this too.
>
>
> A software application consists of the integration of many, many functional
> pieces of code, each with its own "monitoring" information. The
> traditional API-based approach has problems with letting _all_ the
> monitoring information be accessible in the whole application, _because_
> one wants to communicate all that information through the method call
> signature. This does not scale, as is proven by many, many use cases, KDL
> being one of them. The "functional components approach", on the other hand,
> allows an _application_ to create "ports" and connect them to _any_ piece of
> information that is relevant for the _application_. (While the API-based
> approach let the _API designer_ decide about what to have visible through
> the API and what not.) In order to allow the design of such flexible
> application architectures, it is very wise to foresee a "scheduler"
> activity that calls the right functionalities in the right way and under
> the right conditions. (This includes calling the right _port communication_
> functionalities, as well as the right "information forgetting/storage"
> functionalities.)
>
> _All_ the successful systems I have ever seen, including the human, allow
> even the highest levels of abstraction in the system (e.g., the CEO in a
> company) know about low-level errors immediately and fully, when it is
> relevant (in the CEO's case: when there is a leak in a pump in the
> Fukushima reactor enclosure, the CEO should be able to have direct access
> to this information (just by 'switching' the right communication "port",
> without that information having to be passed through layers and layers of
> "lower level" APIs).
>
>
> (I hope you realize that this is a bad example. Sadly, in most companies your example is
> far from the truth.)
>
> I think this is exactly what we have in mind. Instead of propagating the errors upstream
> through the API calls (being CartToJnt or similar), we would like to add an error "port"
> to the solvers. So if a top level solver would report "an" error, the application can
> contact all low-level solvers error "ports" to see at which level the error occurred and
> what happened at each respective level instead of having to serialize and deserialize
> error codes through the API calls.
>
>
> Our idea is very slightly different from this. All solvers should inherit from a Solver
> Interface class that provides simply the latest error number. If a lower level solver fails then
> it stores the error and its parent solver returns an error code indicating which lower level
> solver failed. Now the caller, having called the parent solver _but_ having access to both
> parent and the lower level solver (the application, at least in our use cases, has to have
> created both explicitly) realises that the parent failed due to a faliure in a particular lower
> level solver, and now the application can query that particular lower level solver to determine
> what happened.
Way too complex! And too much coupling: "components" have to have too much
information about each other; in our pattern, only _one single_
"component", the application, has to know about the exact interaction
capabilities of all other components. In addition, the "error number" is
only the last possible resort for proper functioning of a complex system:
much more important are the "continuous progress QoS" monitoring data that
interacting components should exchange with each other. And adding these to
your design suggestion makes the coupling ever more complex.
In addition bis, relying on a "query interaction" policy to find out what
went wrong is running behind the facts, which should be _avoided_ in the
first place. (This ambition was, by the way, _the_ main reasong for use to
include QoS monitoring "ports" in all our designs.)
> For example
>
> solverA = new someIKSolverVel()
> solverB = new someIKSolverPos(solverA)
> ...rc = solverB->CartToJnt(...)
> if (rc == E_SOLVERB_IKSOLVERVEL_FAILED)
> rc = solverA->lastErr()
> ... do something based on the failure in solver A
>
> One could also argue for some standard error codes throughout KDL, e.g. E_NOT_CONVERGE,
> E_SINGULAR, E_INVALID_PARAM, ...
> rather than each solver encoding -1, -2, -3, ..., itself, and sometimes in a different manner.
Standardization is _mandatory_ for these things to succeed! (Irrespective
of which architecure is being used, yours or ours.) But standardization is
something open source projects have proven to be very bad at.
> Lastly, we would also suggest adding "warnings" as well as "errors". Some of the solvers provide
> a degraded solution, in which case motion can still continue and the parent solver or caller
> should continue their work. This isn't an error. Perhaps say that 0 == no error, negative =
> error, and positive = warnings (and so can continue)?
The "QoS monitor ports" solves all the problems with the same interaction,
since it provides a _continuous_ parameter, instead of discrete "error
return codes".
> HTH
> S
Herman
[Bug 1044] New: Broken error propogation logic within solvers
On Oct 9, 2013, at 07:05 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> On Wed, 9 Oct 2013, S Roderick wrote:
>
> (Could the experienced and IT-savvy developers on this list please refrain
> from using HTML posts... It makes proper/unambiguous/client-independent
> indentation of replies impossible.)
>
>> On Oct 9, 2013, at 02:43 , Ruben Smits <ruben [dot] smits [..] ...> wrote:
>>
>> Hi Herman,
>>
>> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Tue, 8 Oct 2013, Sagar Behere wrote:
>>
>> [...]
>> >> Thanks for the nice summary of problems described below!
>> They are exactly
>> >> the reason why I started to fight severely against class
>> libraries for
>> >> "solvers" of any kind, and the "information hiding behind
>> standardized
>> >> APIs" that goes naturally with it. Both are not scalable,
>> and too
>> >> restrictive.
>> >>
>> >> Instead, we are now developing a "function blocks on
>> steroids" framework,
>> >> based on Markus Klotzbuecher's ideas and code. These
>> "micro blocks" are
>> >> positioned somewhere between OO class libraries and RTT
>> components,
>> >> introducing "scheduling" and "composable Ports" as the
>> major primitives to
>> >> deal with the mentioned problems.
>> >
>> >
>> > Could you elaborate a bit on how this framework would deal
>> with the specific problem Stephen
>> describes?
>>
>> +1
>>
>> I am interested in this too.
>> A software application consists of the integration of many, many functional
>> pieces of code, each with its own "monitoring" information. The
>> traditional API-based approach has problems with letting _all_ the
>> monitoring information be accessible in the whole application, _because_
>> one wants to communicate all that information through the method call
>> signature. This does not scale, as is proven by many, many use cases, KDL
>> being one of them. The "functional components approach", on the other hand,
>> allows an _application_ to create "ports" and connect them to _any_ piece of
>> information that is relevant for the _application_. (While the API-based
>> approach let the _API designer_ decide about what to have visible through
>> the API and what not.) In order to allow the design of such flexible
>> application architectures, it is very wise to foresee a "scheduler"
>> activity that calls the right functionalities in the right way and under
>> the right conditions. (This includes calling the right _port communication_
>> functionalities, as well as the right "information forgetting/storage"
>> functionalities.)
>> _All_ the successful systems I have ever seen, including the human, allow
>> even the highest levels of abstraction in the system (e.g., the CEO in a
>> company) know about low-level errors immediately and fully, when it is
>> relevant (in the CEO's case: when there is a leak in a pump in the
>> Fukushima reactor enclosure, the CEO should be able to have direct access
>> to this information (just by 'switching' the right communication "port",
>> without that information having to be passed through layers and layers of
>> "lower level" APIs).
>> (I hope you realize that this is a bad example. Sadly, in most companies your example is
>> far from the truth.)
>> I think this is exactly what we have in mind. Instead of propagating the errors upstream
>> through the API calls (being CartToJnt or similar), we would like to add an error "port"
>> to the solvers. So if a top level solver would report "an" error, the application can
>> contact all low-level solvers error "ports" to see at which level the error occurred and
>> what happened at each respective level instead of having to serialize and deserialize
>> error codes through the API calls.
>> Our idea is very slightly different from this. All solvers should inherit from a Solver
>> Interface class that provides simply the latest error number. If a lower level solver fails then
>> it stores the error and its parent solver returns an error code indicating which lower level
>> solver failed. Now the caller, having called the parent solver _but_ having access to both
>> parent and the lower level solver (the application, at least in our use cases, has to have
>> created both explicitly) realises that the parent failed due to a faliure in a particular lower
>> level solver, and now the application can query that particular lower level solver to determine
>> what happened.
>
> Way too complex! And too much coupling: "components" have to have too much
> information about each other; in our pattern, only _one single_
> "component", the application, has to know about the exact interaction
> capabilities of all other components. In addition, the "error number" is
> only the last possible resort for proper functioning of a complex system:
> much more important are the "continuous progress QoS" monitoring data that
> interacting components should exchange with each other. And adding these to
> your design suggestion makes the coupling ever more complex.
> In addition bis, relying on a "query interaction" policy to find out what
> went wrong is running behind the facts, which should be _avoided_ in the
> first place. (This ambition was, by the way, _the_ main reasong for use to
> include QoS monitoring "ports" in all our designs.)
Sounds great, but do you have a working implementation? We do, and are happy to provide it to the community. I think that you're focused on long term improvements, which is great. But as I wrote, we need a fix now and are happy to patch the current approach to keep things going until your solution is in place.
S
[Bug 1044] New: Broken error propogation logic within solvers
On Wed, 9 Oct 2013, S Roderick wrote:
>
> On Oct 9, 2013, at 07:05 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>
>> On Wed, 9 Oct 2013, S Roderick wrote:
>>
>> (Could the experienced and IT-savvy developers on this list please refrain
>> from using HTML posts... It makes proper/unambiguous/client-independent
>> indentation of replies impossible.)
>>
>>> On Oct 9, 2013, at 02:43 , Ruben Smits <ruben [dot] smits [..] ...> wrote:
>>>
>>> Hi Herman,
>>>
>>> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx
>>> <Herman [dot] Bruyninckx [..] ...> wrote:
>>> On Tue, 8 Oct 2013, Sagar Behere wrote:
>>>
>>> [...]
>>> >> Thanks for the nice summary of problems described below!
>>> They are exactly
>>> >> the reason why I started to fight severely against class
>>> libraries for
>>> >> "solvers" of any kind, and the "information hiding behind
>>> standardized
>>> >> APIs" that goes naturally with it. Both are not scalable,
>>> and too
>>> >> restrictive.
>>> >>
>>> >> Instead, we are now developing a "function blocks on
>>> steroids" framework,
>>> >> based on Markus Klotzbuecher's ideas and code. These
>>> "micro blocks" are
>>> >> positioned somewhere between OO class libraries and RTT
>>> components,
>>> >> introducing "scheduling" and "composable Ports" as the
>>> major primitives to
>>> >> deal with the mentioned problems.
>>> >
>>> >
>>> > Could you elaborate a bit on how this framework would deal
>>> with the specific problem Stephen
>>> describes?
>>>
>>> +1
>>>
>>> I am interested in this too.
>>> A software application consists of the integration of many, many functional
>>> pieces of code, each with its own "monitoring" information. The
>>> traditional API-based approach has problems with letting _all_ the
>>> monitoring information be accessible in the whole application, _because_
>>> one wants to communicate all that information through the method call
>>> signature. This does not scale, as is proven by many, many use cases, KDL
>>> being one of them. The "functional components approach", on the other hand,
>>> allows an _application_ to create "ports" and connect them to _any_ piece of
>>> information that is relevant for the _application_. (While the API-based
>>> approach let the _API designer_ decide about what to have visible through
>>> the API and what not.) In order to allow the design of such flexible
>>> application architectures, it is very wise to foresee a "scheduler"
>>> activity that calls the right functionalities in the right way and under
>>> the right conditions. (This includes calling the right _port communication_
>>> functionalities, as well as the right "information forgetting/storage"
>>> functionalities.)
>>> _All_ the successful systems I have ever seen, including the human, allow
>>> even the highest levels of abstraction in the system (e.g., the CEO in a
>>> company) know about low-level errors immediately and fully, when it is
>>> relevant (in the CEO's case: when there is a leak in a pump in the
>>> Fukushima reactor enclosure, the CEO should be able to have direct access
>>> to this information (just by 'switching' the right communication "port",
>>> without that information having to be passed through layers and layers of
>>> "lower level" APIs).
>>> (I hope you realize that this is a bad example. Sadly, in most companies your example is
>>> far from the truth.)
>>> I think this is exactly what we have in mind. Instead of propagating the errors upstream
>>> through the API calls (being CartToJnt or similar), we would like to add an error "port"
>>> to the solvers. So if a top level solver would report "an" error, the application can
>>> contact all low-level solvers error "ports" to see at which level the error occurred and
>>> what happened at each respective level instead of having to serialize and deserialize
>>> error codes through the API calls.
>>> Our idea is very slightly different from this. All solvers should inherit from a Solver
>>> Interface class that provides simply the latest error number. If a lower level solver fails then
>>> it stores the error and its parent solver returns an error code indicating which lower level
>>> solver failed. Now the caller, having called the parent solver _but_ having access to both
>>> parent and the lower level solver (the application, at least in our use cases, has to have
>>> created both explicitly) realises that the parent failed due to a faliure in a particular lower
>>> level solver, and now the application can query that particular lower level solver to determine
>>> what happened.
>>
>> Way too complex! And too much coupling: "components" have to have too much
>> information about each other; in our pattern, only _one single_
>> "component", the application, has to know about the exact interaction
>> capabilities of all other components. In addition, the "error number" is
>> only the last possible resort for proper functioning of a complex system:
>> much more important are the "continuous progress QoS" monitoring data that
>> interacting components should exchange with each other. And adding these to
>> your design suggestion makes the coupling ever more complex.
>> In addition bis, relying on a "query interaction" policy to find out what
>> went wrong is running behind the facts, which should be _avoided_ in the
>> first place. (This ambition was, by the way, _the_ main reasong for use to
>> include QoS monitoring "ports" in all our designs.)
>
> Sounds great, but do you have a working implementation? We do, and are
> happy to provide it to the community. I think that you're focused on long
> term improvements, which is great. But as I wrote, we need a fix now and
> are happy to patch the current approach to keep things going until your
> solution is in place.
That's a deal I would take at any moment! :-) The ETA for our solution
depends on how fast Markus and Azamat can work... :-)
> S
Herman
[Bug 1044] New: Broken error propogation logic within solvers
On Mi, Okt 09, 2013 at 08:43:37 +0200, Ruben Smits wrote:
> Hi Herman,
>
> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>
> On Tue, 8 Oct 2013, Sagar Behere wrote:
>
> [...]
>
> >> Thanks for the nice summary of problems described below! They are exactly
> >> the reason why I started to fight severely against class libraries for
> >> "solvers" of any kind, and the "information hiding behind standardized
> >> APIs" that goes naturally with it. Both are not scalable, and too
> >> restrictive.
> >>
> >> Instead, we are now developing a "function blocks on steroids" framework,
> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
> >> positioned somewhere between OO class libraries and RTT components,
> >> introducing "scheduling" and "composable Ports" as the major primitives
> to
> >> deal with the mentioned problems.
> >
> >
> > Could you elaborate a bit on how this framework would deal with the
> specific problem Stephen
> describes?
>
> +1
>
> I am interested in this too.
>
> A software application consists of the integration of many, many functional
> pieces of code, each with its own "monitoring" information. The
> traditional API-based approach has problems with letting _all_ the
> monitoring information be accessible in the whole application, _because_
> one wants to communicate all that information through the method call
> signature. This does not scale, as is proven by many, many use cases, KDL
> being one of them. The "functional components approach", on the other hand,
> allows an _application_ to create "ports" and connect them to _any_ piece of
> information that is relevant for the _application_. (While the API-based
> approach let the _API designer_ decide about what to have visible through
> the API and what not.) In order to allow the design of such flexible
> application architectures, it is very wise to foresee a "scheduler"
> activity that calls the right functionalities in the right way and under
> the right conditions. (This includes calling the right _port communication_
> functionalities, as well as the right "information forgetting/storage"
> functionalities.)
>
> _All_ the successful systems I have ever seen, including the human, allow
> even the highest levels of abstraction in the system (e.g., the CEO in a
> company) know about low-level errors immediately and fully, when it is
> relevant (in the CEO's case: when there is a leak in a pump in the
> Fukushima reactor enclosure, the CEO should be able to have direct access
> to this information (just by 'switching' the right communication "port",
> without that information having to be passed through layers and layers of
> "lower level" APIs).
>
> (I hope you realize that this is a bad example. Sadly, in most companies your
> example is far from the truth.)
> I think this is exactly what we have in mind. Instead of propagating the errors
> upstream through the API calls (being CartToJnt or similar), we would like to
> add an error "port" to the solvers. So if a top level solver would report "an"
> error, the application can contact all low-level solvers error "ports" to see at
> which level the error occurred and what happened at each respective level
> instead of having to serialize and deserialize error codes through the API
> calls.
>
> If you ever use this design pattern, please give credits to Markus!!!!
>
> It's hard to give credit if you have nothing to refer to ;)
I quite certain I don't deserve credit for this... Function blocks
have been around for decades and I'm certain there are many engineers
out there applying this pattern without even noticing it as such.
But it _is_ the Right Thing (TM) to do!
Markus
[Bug 1044] New: Broken error propogation logic within solvers
On Wed, 9 Oct 2013, Markus Klotzbuecher wrote:
> On Mi, Okt 09, 2013 at 08:43:37 +0200, Ruben Smits wrote:
>> Hi Herman,
>>
>> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> On Tue, 8 Oct 2013, Sagar Behere wrote:
>>
>> [...]
>>
>> >> Thanks for the nice summary of problems described below! They are exactly
>> >> the reason why I started to fight severely against class libraries for
>> >> "solvers" of any kind, and the "information hiding behind standardized
>> >> APIs" that goes naturally with it. Both are not scalable, and too
>> >> restrictive.
>> >>
>> >> Instead, we are now developing a "function blocks on steroids" framework,
>> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
>> >> positioned somewhere between OO class libraries and RTT components,
>> >> introducing "scheduling" and "composable Ports" as the major primitives
>> to
>> >> deal with the mentioned problems.
>> >
>> >
>> > Could you elaborate a bit on how this framework would deal with the
>> specific problem Stephen
>> describes?
>>
>> +1
>>
>> I am interested in this too.
>>
>> A software application consists of the integration of many, many functional
>> pieces of code, each with its own "monitoring" information. The
>> traditional API-based approach has problems with letting _all_ the
>> monitoring information be accessible in the whole application, _because_
>> one wants to communicate all that information through the method call
>> signature. This does not scale, as is proven by many, many use cases, KDL
>> being one of them. The "functional components approach", on the other hand,
>> allows an _application_ to create "ports" and connect them to _any_ piece of
>> information that is relevant for the _application_. (While the API-based
>> approach let the _API designer_ decide about what to have visible through
>> the API and what not.) In order to allow the design of such flexible
>> application architectures, it is very wise to foresee a "scheduler"
>> activity that calls the right functionalities in the right way and under
>> the right conditions. (This includes calling the right _port communication_
>> functionalities, as well as the right "information forgetting/storage"
>> functionalities.)
>>
>> _All_ the successful systems I have ever seen, including the human, allow
>> even the highest levels of abstraction in the system (e.g., the CEO in a
>> company) know about low-level errors immediately and fully, when it is
>> relevant (in the CEO's case: when there is a leak in a pump in the
>> Fukushima reactor enclosure, the CEO should be able to have direct access
>> to this information (just by 'switching' the right communication "port",
>> without that information having to be passed through layers and layers of
>> "lower level" APIs).
>>
>> (I hope you realize that this is a bad example. Sadly, in most companies your
>> example is far from the truth.)
>> I think this is exactly what we have in mind. Instead of propagating the errors
>> upstream through the API calls (being CartToJnt or similar), we would like to
>> add an error "port" to the solvers. So if a top level solver would report "an"
>> error, the application can contact all low-level solvers error "ports" to see at
>> which level the error occurred and what happened at each respective level
>> instead of having to serialize and deserialize error codes through the API
>> calls.
>>
>> If you ever use this design pattern, please give credits to Markus!!!!
>>
>> It's hard to give credit if you have nothing to refer to ;)
>
> I quite certain I don't deserve credit for this... Function blocks
> have been around for decades and I'm certain there are many engineers
> out there applying this pattern without even noticing it as such.
>
> But it _is_ the Right Thing (TM) to do!
You _do_ deserver credits for (i) recognizing that there _is_ a pattern,
(ii) explaining the design forces behind it, and (iii) making a reference
implementation available!
The latter availability is, currently, not yet 100%, but that will change
as soon as our youBot demo is mature enough to prove that the
implementation does indeed conform to the pattern. :-)
> Markus
Herman
[Bug 1044] New: Broken error propogation logic within solvers
On Wed, 9 Oct 2013, Ruben Smits wrote:
> Hi Herman,
>
> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 8 Oct 2013, Sagar Behere wrote:
>
> [...]
> >> Thanks for the nice summary of problems described below! They are
> exactly
> >> the reason why I started to fight severely against class libraries
> for
> >> "solvers" of any kind, and the "information hiding behind
> standardized
> >> APIs" that goes naturally with it. Both are not scalable, and too
> >> restrictive.
> >>
> >> Instead, we are now developing a "function blocks on steroids"
> framework,
> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks"
> are
> >> positioned somewhere between OO class libraries and RTT components,
> >> introducing "scheduling" and "composable Ports" as the major
> primitives to
> >> deal with the mentioned problems.
> >
> >
> > Could you elaborate a bit on how this framework would deal with the
> specific problem Stephen
> describes?
>
> +1
>
> I am interested in this too.
>
>
> A software application consists of the integration of many, many functional
> pieces of code, each with its own "monitoring" information. The
> traditional API-based approach has problems with letting _all_ the
> monitoring information be accessible in the whole application, _because_
> one wants to communicate all that information through the method call
> signature. This does not scale, as is proven by many, many use cases, KDL
> being one of them. The "functional components approach", on the other hand,
> allows an _application_ to create "ports" and connect them to _any_ piece of
> information that is relevant for the _application_. (While the API-based
> approach let the _API designer_ decide about what to have visible through
> the API and what not.) In order to allow the design of such flexible
> application architectures, it is very wise to foresee a "scheduler"
> activity that calls the right functionalities in the right way and under
> the right conditions. (This includes calling the right _port communication_
> functionalities, as well as the right "information forgetting/storage"
> functionalities.)
>
> _All_ the successful systems I have ever seen, including the human, allow
> even the highest levels of abstraction in the system (e.g., the CEO in a
> company) know about low-level errors immediately and fully, when it is
> relevant (in the CEO's case: when there is a leak in a pump in the
> Fukushima reactor enclosure, the CEO should be able to have direct access
> to this information (just by 'switching' the right communication "port",
> without that information having to be passed through layers and layers of
> "lower level" APIs).
>
>
> (I hope you realize that this is a bad example. Sadly, in most companies your example is far
> from the truth.)
You refer to the "CEO example"? :-)
> I think this is exactly what we have in mind. Instead of propagating the errors upstream through
> the API calls (being CartToJnt or similar), we would like to add an error "port" to the solvers.
> So if a top level solver would report "an" error, the application can contact all low-level
> solvers error "ports" to see at which level the error occurred and what happened at each
> respective level instead of having to serialize and deserialize error codes through the API
> calls.
Yes! But current component frameworks (Orocos RTT, ROS,...) are too heavy
for this, and current function block frameworks (IEC 61499 etc.) are not
"port based" and "schedulable" enough. Hence, Markus' new development.
For the third time in my robotics software career, I found it heartbreaking
that we _had_ to develop a new framework, because nothing close to what we
want already exists. (Orocos RTT and rFSM were the previous examples.)
Of course, I am the first one to warn people about the "Not Invented Here"
syndrome (and the tremendous loss of development effort efficiency that
comes with it), so I am _very_ eager to be proven wrong: please point me to
a professionally designed SW framework that does already what we want... :-)
>
> If you ever use this design pattern, please give credits to Markus!!!!
> It's hard to give credit if you have nothing to refer to ;)
_That_ is not true, and by the way that is a very big problem in SW
engineering: developers seldom refer to the _ideas_ that are being their
software, and where these ideas come from. And this email thread is
publicly accessible, hence citable :-)
Compared to the "paper trail" of publishing research results, the "software
trail" is acting quite unethical in this context of giving credit to where
the good ideas come from, frankly speaking. But we are getting off-topic... :-)
> Ruben
Herman
[Bug 1044] New: Broken error propogation logic within solvers
Hi Herman,
On Wed, Oct 9, 2013 at 9:03 AM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
>
> On Wed, 9 Oct 2013, Ruben Smits wrote:
>
>> Hi Herman,
>>
>> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Tue, 8 Oct 2013, Sagar Behere wrote:
>>
>> [...]
>> >> Thanks for the nice summary of problems described below! They are
>> exactly
>> >> the reason why I started to fight severely against class libraries
>> for
>> >> "solvers" of any kind, and the "information hiding behind
>> standardized
>> >> APIs" that goes naturally with it. Both are not scalable, and too
>> >> restrictive.
>> >>
>> >> Instead, we are now developing a "function blocks on steroids"
>> framework,
>> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks"
>> are
>> >> positioned somewhere between OO class libraries and RTT components,
>> >> introducing "scheduling" and "composable Ports" as the major
>> primitives to
>> >> deal with the mentioned problems.
>> >
>> >
>> > Could you elaborate a bit on how this framework would deal with the
>> specific problem Stephen
>> describes?
>>
>> +1
>>
>> I am interested in this too.
>>
>>
>> A software application consists of the integration of many, many functional
>> pieces of code, each with its own "monitoring" information. The
>> traditional API-based approach has problems with letting _all_ the
>> monitoring information be accessible in the whole application, _because_
>> one wants to communicate all that information through the method call
>> signature. This does not scale, as is proven by many, many use cases, KDL
>> being one of them. The "functional components approach", on the other hand,
>> allows an _application_ to create "ports" and connect them to _any_ piece of
>> information that is relevant for the _application_. (While the API-based
>> approach let the _API designer_ decide about what to have visible through
>> the API and what not.) In order to allow the design of such flexible
>> application architectures, it is very wise to foresee a "scheduler"
>> activity that calls the right functionalities in the right way and under
>> the right conditions. (This includes calling the right _port communication_
>> functionalities, as well as the right "information forgetting/storage"
>> functionalities.)
>>
>> _All_ the successful systems I have ever seen, including the human, allow
>> even the highest levels of abstraction in the system (e.g., the CEO in a
>> company) know about low-level errors immediately and fully, when it is
>> relevant (in the CEO's case: when there is a leak in a pump in the
>> Fukushima reactor enclosure, the CEO should be able to have direct access
>> to this information (just by 'switching' the right communication "port",
>> without that information having to be passed through layers and layers of
>> "lower level" APIs).
>>
>>
>> (I hope you realize that this is a bad example. Sadly, in most companies your example is far
>> from the truth.)
>
>
> You refer to the "CEO example"? :-)
>
How could you guess ;)
>
>> I think this is exactly what we have in mind. Instead of propagating the errors upstream through
>> the API calls (being CartToJnt or similar), we would like to add an error "port" to the solvers.
>> So if a top level solver would report "an" error, the application can contact all low-level
>> solvers error "ports" to see at which level the error occurred and what happened at each
>> respective level instead of having to serialize and deserialize error codes through the API
>> calls.
>
>
> Yes! But current component frameworks (Orocos RTT, ROS,...) are too heavy
> for this, and current function block frameworks (IEC 61499 etc.) are not
> "port based" and "schedulable" enough. Hence, Markus' new development.
>
> For the third time in my robotics software career, I found it heartbreaking
> that we _had_ to develop a new framework, because nothing close to what we
> want already exists. (Orocos RTT and rFSM were the previous examples.)
> Of course, I am the first one to warn people about the "Not Invented Here"
> syndrome (and the tremendous loss of development effort efficiency that
> comes with it), so I am _very_ eager to be proven wrong: please point me to
> a professionally designed SW framework that does already what we want... :-)
>
>
>>
>> If you ever use this design pattern, please give credits to Markus!!!!
>
>
>> It's hard to give credit if you have nothing to refer to ;)
>
>
> _That_ is not true, and by the way that is a very big problem in SW
> engineering: developers seldom refer to the _ideas_ that are being their
> software, and where these ideas come from. And this email thread is
> publicly accessible, hence citable :-)
>
> Compared to the "paper trail" of publishing research results, the "software
> trail" is acting quite unethical in this context of giving credit to where
> the good ideas come from, frankly speaking. But we are getting off-topic... :-)
>
Since there was no reference to the software trail, I looked around
and found microblox: https://github.com/kmarkus/microblx . Is this
what you are referring too?
@Markus: Are you planning to keep the license GPLv3+?
Ruben
>> Ruben
>
>
> Herman
[Bug 1044] New: Broken error propogation logic within solvers
On Mi, Okt 16, 2013 at 09:53:19 +0200, Ruben Smits wrote:
> Hi Herman,
>
>
> On Wed, Oct 9, 2013 at 9:03 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
> >
> > On Wed, 9 Oct 2013, Ruben Smits wrote:
> >
> >> Hi Herman,
> >>
> >> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> >> On Tue, 8 Oct 2013, Sagar Behere wrote:
> >>
> >> [...]
> >> >> Thanks for the nice summary of problems described below! They are
> >> exactly
> >> >> the reason why I started to fight severely against class libraries
> >> for
> >> >> "solvers" of any kind, and the "information hiding behind
> >> standardized
> >> >> APIs" that goes naturally with it. Both are not scalable, and too
> >> >> restrictive.
> >> >>
> >> >> Instead, we are now developing a "function blocks on steroids"
> >> framework,
> >> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks"
> >> are
> >> >> positioned somewhere between OO class libraries and RTT components,
> >> >> introducing "scheduling" and "composable Ports" as the major
> >> primitives to
> >> >> deal with the mentioned problems.
> >> >
> >> >
> >> > Could you elaborate a bit on how this framework would deal with the
> >> specific problem Stephen
> >> describes?
> >>
> >> +1
> >>
> >> I am interested in this too.
> >>
> >>
> >> A software application consists of the integration of many, many functional
> >> pieces of code, each with its own "monitoring" information. The
> >> traditional API-based approach has problems with letting _all_ the
> >> monitoring information be accessible in the whole application, _because_
> >> one wants to communicate all that information through the method call
> >> signature. This does not scale, as is proven by many, many use cases, KDL
> >> being one of them. The "functional components approach", on the other hand,
> >> allows an _application_ to create "ports" and connect them to _any_ piece of
> >> information that is relevant for the _application_. (While the API-based
> >> approach let the _API designer_ decide about what to have visible through
> >> the API and what not.) In order to allow the design of such flexible
> >> application architectures, it is very wise to foresee a "scheduler"
> >> activity that calls the right functionalities in the right way and under
> >> the right conditions. (This includes calling the right _port communication_
> >> functionalities, as well as the right "information forgetting/storage"
> >> functionalities.)
> >>
> >> _All_ the successful systems I have ever seen, including the human, allow
> >> even the highest levels of abstraction in the system (e.g., the CEO in a
> >> company) know about low-level errors immediately and fully, when it is
> >> relevant (in the CEO's case: when there is a leak in a pump in the
> >> Fukushima reactor enclosure, the CEO should be able to have direct access
> >> to this information (just by 'switching' the right communication "port",
> >> without that information having to be passed through layers and layers of
> >> "lower level" APIs).
> >>
> >>
> >> (I hope you realize that this is a bad example. Sadly, in most companies your example is far
> >> from the truth.)
> >
> >
> > You refer to the "CEO example"? :-)
> >
>
> How could you guess ;)
>
> >
> >> I think this is exactly what we have in mind. Instead of propagating the errors upstream through
> >> the API calls (being CartToJnt or similar), we would like to add an error "port" to the solvers.
> >> So if a top level solver would report "an" error, the application can contact all low-level
> >> solvers error "ports" to see at which level the error occurred and what happened at each
> >> respective level instead of having to serialize and deserialize error codes through the API
> >> calls.
> >
> >
> > Yes! But current component frameworks (Orocos RTT, ROS,...) are too heavy
> > for this, and current function block frameworks (IEC 61499 etc.) are not
> > "port based" and "schedulable" enough. Hence, Markus' new development.
> >
> > For the third time in my robotics software career, I found it heartbreaking
> > that we _had_ to develop a new framework, because nothing close to what we
> > want already exists. (Orocos RTT and rFSM were the previous examples.)
> > Of course, I am the first one to warn people about the "Not Invented Here"
> > syndrome (and the tremendous loss of development effort efficiency that
> > comes with it), so I am _very_ eager to be proven wrong: please point me to
> > a professionally designed SW framework that does already what we want... :-)
> >
> >
> >>
> >> If you ever use this design pattern, please give credits to Markus!!!!
> >
> >
> >> It's hard to give credit if you have nothing to refer to ;)
> >
> >
> > _That_ is not true, and by the way that is a very big problem in SW
> > engineering: developers seldom refer to the _ideas_ that are being their
> > software, and where these ideas come from. And this email thread is
> > publicly accessible, hence citable :-)
> >
> > Compared to the "paper trail" of publishing research results, the "software
> > trail" is acting quite unethical in this context of giving credit to where
> > the good ideas come from, frankly speaking. But we are getting off-topic... :-)
> >
>
> Since there was no reference to the software trail, I looked around
> and found microblox: https://github.com/kmarkus/microblx . Is this
> what you are referring too?
Yes, but so far there's just the code...
> @Markus: Are you planning to keep the license GPLv3+?
I am open for suggestions, do you have a strong preference for v2? If
yes, why?
Markus