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