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

Hi Herman,


On Tue, Oct 8, 2013 at 7:22 PM, Herman Bruyninckx <
[email protected]> wrote:

> 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.
>

Could you elaborate a bit on how this framework would deal with the
specific problem Stephen describes?

Ruben


>
> 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
>



-- 
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