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

On Oct 8, 2013 7:55 PM, "Ruben Smits" <[email protected]> wrote:
>
> 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?

+1

I am interested in this too.

/Sagar

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

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