RussTedrake
commented
9 years ago The code in NonlinearProgram/snopt should be very penetrable. You can see the options there. And the online snopt documentation is easy to find and helpful.
If you see info>13 coming out of snopt, it probably means something is wrong with your problem formulation. For instance, you might be providing derivatives that don't match your function. I would look hard for a bug like that first.
On Jul 11, 2015, at 10:46 PM, aespielberg notifications@github.com wrote:
Hi all,
I have a simple Acrobot plant model, and have been performing trajectory optimization on it, and I've been comparing the effect of L1 vs. L2 optimization on an objective. My objective is on parameters, which I've made part of my optimization method. I want to penalize varying the parameters too much, and for that, I'm comparing L1 and L2 regularization.
Right now I am dealing with only one cost function, a final cost, which looks like this:
function [f, df] = parameter_regularizer(obj, T, x, params) param_values = obj.robot.getParams(); w = obj.regularizer_weight; f = w_norm(double(param_values) - params, 1); df = [0, zeros(length(x), 1)', w_sign(params - double(param_values))']; end What I've noticed is that L1 minimization takes MUUUUUCH longer than L2 minimization: we are talking ~300 seconds vs. ~6 seconds. and does not fully satisfy the constraints. Even though one of my coordinates was constrainted to be 0 <= constraint_val <= 0; I found that the constraint_val was something like 0.008, where I know the standard slack is usually much much smaller. I also watched the constrained value jump around wildly, from being nearly satisfied to suddenly jumping to something like 42. I also noticed the following printout in my run:
Warning: 41 current point cannot be improved
In NonlinearProgram/mapSolverInfo (line 1544) In NonlinearProgram/snopt (line 1420) In NonlinearProgram/solve (line 973) In DirectTrajectoryOptimization/solveTraj (line 188) In KinematicDirtranTest/solveTraj (line 90) In AcrobotPlantTest/swingUpTrajectoryKinematic (line 212) In runSwingUpKinematicTest (line 6) I know L1 minimization problems are harder than L2 minimization problems because of the fact that it's nonsmooth, and also the fact that the second derivative is basically zero everywhere - which means certain optimization methods don't have a lot of information to go off of. However, I honestly didn't expect just adding this objective function, which has only 6 dimensions, would cause the compute time to balloon so much - and I didn't expect it to be so different from having an L2 objective or a nonexistent objective, both of which have nearly trivial compute time (~6s).
Long-story short: Does SNOPT and the Drake interface to snopt have ways of improving optimization time?
a) Are there tools tailored to L1 minimization problems in particular, or known settings that work well for them? b) Where can I see documentation on what options I can control in SNOPT optimization calls? c) Precisely what algorithm does SNOPT use? I noticed that there's some stochasticity sometimes between runs - where does this nondeterminism come from? Is there a way to select between different optimization algorithms (e.g. gradient descent, trust-region, etc.)? d) Does this result make sense, that the trajectory optimization would have so much trouble with this objective?
-Andy S.
— Reply to this email directly or view it on GitHub.
hongkai-dai
jrebula
aespielberg
Hi all,
I have a simple Acrobot plant model, and have been performing trajectory optimization on it, and I've been comparing the effect of L1 vs. L2 optimization on an objective. My objective is on parameters, which I've made part of my optimization method. I want to penalize varying the parameters too much, and for that, I'm comparing L1 and L2 regularization.
Right now I am dealing with only one cost function, a final cost, which looks like this:
What I've noticed is that L1 minimization takes MUUUUUCH longer than L2 minimization: we are talking ~300 seconds vs. ~6 seconds. and does not fully satisfy the constraints. Even though one of my coordinates was constrainted to be 0 <= constraint_val <= 0; I found that the constraint_val was something like 0.008, where I know the standard slack is usually much much smaller. I also watched the constrained value jump around wildly, from being nearly satisfied to suddenly jumping to something like 42. I also noticed the following printout in my run:
I know L1 minimization problems are harder than L2 minimization problems because of the fact that it's nonsmooth, and also the fact that the second derivative is basically zero everywhere - which means certain optimization methods don't have a lot of information to go off of. However, I honestly didn't expect just adding this objective function, which has only 6 dimensions, would cause the compute time to balloon so much - and I didn't expect it to be so different from having an L2 objective or a nonexistent objective, both of which have nearly trivial compute time (~6s).
Long-story short: Does SNOPT and the Drake interface to snopt have ways of improving optimization time?
a) Are there tools tailored to L1 minimization problems in particular, or known settings that work well for them? b) Where can I see documentation on what options I can control in SNOPT optimization calls? c) Precisely what algorithm does SNOPT use? I noticed that there's some stochasticity sometimes between runs - where does this nondeterminism come from? Is there a way to select between different optimization algorithms (e.g. gradient descent, trust-region, etc.)? d) Does this result make sense, that the trajectory optimization would have so much trouble with this objective?
-Andy S.