System constraints

Replaces stateConstraint method logic with a list of constraint objects for each DrakeSystem.  These can handled more elegantly (preserving the structure of the constraints, and avoiding function handles) by the optimization classes.  

Taking another crack at finishing and merging this (just had a rough time bringing it back in line w/ master).  

I think the case for caching kinsol is weaker here, since many of the use cases are all operating on just a single state.  But I do agree with you that it could be generalized in the future.

If we open it up, then we would somehow have to guarantee that the derived classes manage the parent class properties correctly.  My preference would be to leave it sealed until we get to the case where we actually need the derived class?

On Oct 5, 2014, at 7:18 PM, Hongkai Dai <notifications@github.com> wrote:

> In systems/@DrakeSystem/DrakeSystem.m:
> 
> > +      obj.num_xcon_eq = obj.num_xcon_eq - sum(obj.state_constraints{id}.lb == obj.state_constraints{id}.ub);
> > +      obj.num_xcon_ineq = obj.num_xcon_ineq - sum(obj.state_constraints{id}.lb ~= obj.state_constraints{id}.ub);
> > +      obj.state_constraints{id} = con;
> > +      obj.state_constraint_xind{id} = xind;
> > +      obj.num_xcon_eq = obj.num_xcon_eq + sum(con.lb == con.ub);
> > +      obj.num_xcon_ineq = obj.num_xcon_ineq + sum(con.lb ~= con.ub);
> > +    end
> > +    
> > +    function displayStateConstraints(obj)
> > +      for i=1:length(obj.state_constraints)
> > +        disp(obj.state_constraints{i});
> > +      end
> > +    end
> > +  end
> > +
> > +  methods (Sealed)
> I am not sure if we should seal these methods. The state constraints in DrakeSystem do not accept any 'data_ind', like the cached kinsol. I think we could overide these methods in the derived class, so that they can accept data_ind as a function input argument.
> 
> —
> Reply to this email directly or view it on GitHub.
>