Re: [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
> <[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?

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