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

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]

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.

-- 
Configure bugmail: http://bugs.orocos.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev