AddL2NormCost is a footgun

[AlexandreAmice]

Is your feature request related to a problem? Please describe. Despite the warning attached to the docs, I have seen several people mistakenly assume that AddL2NormCost will add a convex cost and then not realize that Drake will attempt to solve the program using a generic non-linear solver.

From an optimization standpoint, I cannot think of a time when the 2-norm squared is not an equally good substitute to the 2-norm.

Describe the solution you'd like Deprecated AddL2NormCost and replace it with AddL2NormSquaredCost which would simply be a wrapper to the currently implemented AddL2NormCostUsingConicConstraint.

@RussTedrake for discussion based on experience teaching Underactuated and Manipulation @hongkai-dai for thoughts.

[EricCousineau-TRI]

Per Platform checklist, assigning Hongkai.

[RussTedrake]

Quick thoughts:

• We already have Add2NormSquaredCost.
• The L2 norm is very different than L2 norm squared if you are adding multiple costs together. For instance in GCS, the L2 norm squared leads to paths that are sometimes surprising and unintuitive (because the optimizer is rewarded for taking many small steps over one larger one).

So I definitely disagree with

From an optimization standpoint, I cannot think of a time when the 2-norm squared is not an equally good substitute to the 2-norm.

but I agree that it can be a misleading interface for users.

When I used it in KinematicTrajectoryOptimization, I did this

  /** Adds a cost on an upper bound on length of the path, ∫₀ᵀ |q̇(t)|₂ dt, by
  summing the distance between the path control points. If `use_conic_constraint
  = false`, then costs are added via MathematicalProgram::AddL2NormCost;
  otherwise they are added via
  MathematicalProgram::AddL2NormCostUsingConicConstraint. */
  void AddPathLengthCost(double weight = 1.0,
                         bool use_conic_constraint = false);

would having a single entry point with the argument help to force people to think about the consequences?

[AlexandreAmice]

Perhaps we could simply add an optional argument AddL2NormCost(A, b,vars, as_convex=False)? If the as_convex argument gets passed, then we call Add2NormSquaredCost instead.

There is also a TODO in the code to make the convex solvers directly accept the L2 norm cost.

[RussTedrake]

That was almost my proposal. But definitely don't add the squared cost if someone asked for the 2norm cost.

[hongkai-dai]

I am working on a sequence of PRs, to support L2NormCost natively as convex costs in different solvers (SCS, Clarabel, Gurobi, Mosek). This would take a while to add this feature.

[hongkai-dai]

Now that the commonly-used convex solvers (Clarabel, SCS, Gurobi and Mosek) all support L2NormCost. I will close this issue.