updating resolveConstraints to use new optimization classes
Fixed bug in RigidBodyTorsionalSpring where spring torque was only applied to the child body (and not the parent).
Merge branch 'drake-origin/master'
implemented window resizing and value displays in inspector to make it a little more usable
Merge branch 'more_optimization' of https://github.com/RussTedrake/drake into inspector
inspector uses new resolveConstraints program (with an added constraint for the current slider, as was originally intended)
getActuatedJoints should output column vector, not a row vector.  fixed state dim logic in inspector
added quadratic objective (to not move the other joints).  it's not fast, but it finally behaves as expected
implemented derivatives of the stateConstraints method to avoid taylorVars
fixed some obvious bugs in unilateralConstraint gradients to make the new resolveConstraints work.  can't believe we didn't hit those before
Fixes infeasibility when robot starts with toes pointing together
Merge pull request #284 from rdeits/fix-footstep-infeas

Fixes infeasibility when robot starts with toes pointing together
Update RigidBodyTorsionalSpring.m

Not applying force to the parent if it is the world (body 0)
Fix variability in footstep plans based on world pose of the bot

The problem was that as the robot and the goal were moved farther from the origin, a larger constant term was added to the objective (since the objective involves quadratic terms in the goal pose). This would ordinarily not be a problem, but the MIP solver terminates when the optimality gap is less than a certain /fraction/ of the best objective, so as the objective got larger (by a constant factor), the solutions became less optimal. Correctly accounting for this constant (by setting objcon in gurobi) fixes the problem.
added viewpoint logic that rick requested
handle single state dim case
handle the zero actuator case more gracefully
Merge pull request #270 from mposa/master

RigidBodyTorsionalSpring bug fix
Merge pull request #285 from rdeits/fix-world-pose-dependence

Fix variability in footstep plans based on world pose of the bot
only do gradient computation when necessary