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

On Oct 9, 2013, at 02:43 , Ruben Smits <[email protected]> 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.

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

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev