Can't you test the non-mex vs mex constraints without calling inverseKin?

- Russ


> On May 29, 2014, at 7:15 AM, Andres Valenzuela <notifications@github.com> wrote:
> 
> In systems/plants/constraint/AllBodiesClosestDistanceConstraint.m:
> 
> > @@ -18,6 +18,9 @@
> >      end
> >      
> >     function [c,dc] = evalValidTime(obj,kinsol)
> > +      % Re-run doKinematics to update the cpp RBM if there is one. This
> > +      % lets us compare results with the cpp constraint class.
> > +      kinsol = doKinematics(obj.robot,kinsol.q);
> The problem is that in inverseKin and testKinCnst we assume that non-mexed constraints => non-mexed dynamics. So if inverseKin is called with with ikoptions.use_mex = false, it not only omits the creation of C++ constraint objects, it also calls doKinematics with mex set to false. This leaves us with no way to compare the non-mex AllBodiesClosestDistanceConstraint against the mex one, as calling collisionDetect with a non-mex kinsol yields a different number of collision pairs than calling it with a mexed one.
> 
> Perhaps a better solution would be to split the use_mex flag in inverseKin into separate use_mex_dynamics and use_mex_constraints flags?
> 
> —
> Reply to this email directly or view it on GitHub.