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

Hello,

Even though not much active in the Orocos community, here are my two cents
on this topic.

2013/10/8 Herman Bruyninckx <[email protected]>

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

I clearly agree that solvers should be used as components more than in a
classical API way. That clearly allows for more flexibility and less
undesired entanglement between the specific problem to be solved and the
general solver used to solve it.


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

Even though I contributed to the writing of this solver
(chainiksolvervel_wdls), which at that time was probably providing the most
tunable and general way to compute an analytical solution to the inverse
velocity kinematics problem, I am now convinced that this is not the way to
go. People should definitely switch to solvers (at the velocity kinematics
or dynamics level) which allow to formulate the control problem using only
forward models and allowing to express inequality constraints in a
"natural" way.


>
> Herman
>

Vincent

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