cleanup trajectory optimization examples (now everything uses the new interface)

to be included in drake v 0.9.7
I disagree, but am obviously on the fence about the change, too.  MPC is a serious use case -- one that for instance we're trying out for grasping control on atlas -- and saving the expense of creating the unused xtraj is useful.  It definitely would be annoying to change now, but will be even harder later.

What do others think?

- Russ


> On Oct 12, 2014, at 9:27 PM, Michael Posa <notifications@github.com> wrote:
> 
> In solvers/trajectoryOptimization/DirectTrajectoryOptimization.m:
> 
> > @@ -151,7 +151,16 @@
> >        end
> >      end
> >  
> > -    function [xtraj,utraj,z,F,info] = solveTraj(obj,t_init,traj_init)
> > +    function obj = addTrajectoryDisplayFunction(obj,display_fun)
> > +      % add a dispay function that gets called on every iteration of the
> > +      % algorithm
> > +      % @param display_fun a function handle of the form displayFun(t,x,u)
> > +      %       where t is a 1-by-N, x is n-by-N and u is m-by-N
> > +      
> > +      obj = addDisplayFunction(obj,@(z) display_fun(z(obj.h_inds),z(obj.x_inds),z(obj.u_inds)));
> > +    end
> > +    
> > +    function [utraj,xtraj,z,F,info,infeasible_constraint_name] = solveTraj(obj,t_init,traj_init)
> What's the reasoning behind swapping xtraj and utraj? This is one of those changes that will prove incredibly annoying for some time, as various branches and example code (for instance, the code we just handed out to the class) will have to be brought into line. In my mind, there's no win to be had, since neither way is more intuitive for users.
> 
> I saw the commit message, and while it's true that you might want utraj and not xtraj, this nearly never happens in practice and doesn't seem like it's important enough to warrant this change.
> 
> —
> Reply to this email directly or view it on GitHub.