Re: [Bug 1044] New: Broken error propogation logic within solvers

Hi Herman,


On Wed, Oct 9, 2013 at 9:03 AM, Herman Bruyninckx
<[email protected]> wrote:
>
> On Wed, 9 Oct 2013, 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.)
>
>
> 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




-- 
Ruben Smits, CTO
+32 479 511 786
Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
www.intermodalics.eu
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev