Re: [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
>> <[email protected]> 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
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev