updates resolveConstraints to the new optimization classes, and updates inspector to use resolveConstraints effectively

also made inspector a little nicer in general (handles window resizing, shows variable values, etc)
ended up implementing user gradients for the stateConstraints method in RBM to speed things up.
now we can play with systems with four-bar linkages at interactive rates using the inspector, and it behaves pretty nicely.

yes.  that logic was totally bizarre.  i've fixed it.  thanks.

On Aug 12, 2014, at 9:50 AM, Andres Valenzuela <notifications@github.com> wrote:

> In systems/@DrakeSystem/DrakeSystem.m:
> 
> > +      
> > +      x0 = .01*randn(obj.num_xd+obj.num_xc,1);
> > +      if getNumStateConstraints(obj)>0
> > +        attempts=0;
> > +        success=false;
> > +        tries = 0;
> > +        while (~success)
> > +          try
> > +            [x0,success] = resolveConstraints(obj,x0);
> > +          catch ex
> > +            if strcmp(ex.identifier,'Drake:DrakeSystem:FailedToResolveConstraints');
> > +              attempts = attempts+1;
> > +              if (attempts>=10)
> > +                error('Drake:Manipulator:FailedToResolveConstraints','Failed to resolve state constraints on initial conditions after 10 tries');
> > +              else
> > +                x0 = randn(obj.num_xd+obj.num_xc,1);
> Should this line just be
> 
> success = false;
> since we assign a new random x0 on line 66?
> 
> —
> Reply to this email directly or view it on GitHub.
>