Trajopt_ifopt TODO list

[mpowelson]

• Collision - Add other collision evaluators (See Add other collision evaluators to trajopt_ifopt #193)
• Collision Callback - Collision is the only one that is missing (See Add collision callback to trajopt_sqp #192)
• Print debug info - trajopt_sco prints a bunch of debugging information that developers have become accustomed to. Some of this has been added to trajopt_sqp, but some like the cost associated with individual convex costs, will require some work to implement
• Add Hessian to IFOPT
• Look into adding caching to functions like Problem::EvaluateCostFunction
• Add coeff support to constraints.
  • Collision Constraint
  • Cartesian Position Constraint
  • Inverse Kinematics Constraint
  • Joint Position Constraint
  • Joint Velocity Constraint
  • Joint Acceleration Constraint
  • Joint Jerk Constraint
• Joint Acceleration ( Add JointAccellConstraint and JointJerkConstraint #275 )
• Joint Jerk (Add JointAccellConstraint and JointJerkConstraint #275 )

[Levi-Armstrong]

@mpowelson Is this what is remaining for completing trajopt_ifopt where it has the same functionality as trajopt?

[mpowelson]

Big things I can think of are #192 and #193. Smaller issues, we are missing the dynamic cartesian constraint as well as joint acceleration. There are probably other things that will come up where you can semantically do the same thing but it looks a little different in the optimization (e.g. the old trajopt start_fixed flag), but I think the other collision evaluators are really the main thing that is missing before it will work for the majority of cases.

Of course time parameterization is also something that will need to be reworked.

[colin-lewis-19]

I'm going to start chipping away at this, starting with #192

[mpowelson]

Other possible performance improvements.

• Test out other linear solvers. OSQP supports MKL Parsido. "MKL Pardiso is an efficient multi-threaded linear system solver that works well for large scale problems part of the Intel Math Kernel Library"
• IFOPT problems don't change size, so we could use OSQP code generation to generate a problem once and solve it repeatedly. I'm not sure if this is supposed to be faster or is just for deploying the QP solver in an external codebase

[simonschmeisser]

Maybe I'm missing something obvious, but what's the difference between ifopt and sco? When would I use one or the other? Or is ifopt a successor to sco? If you provide me with some hints I can add a few lines to the readme

[mpowelson]

Yes, trajopt_ifopt + trajopt_optimizers was intended as a successor to trajopt + trajopt_sco. It was intended to make the creation of the problem and the solver used more separate so we could more easily add other optimizers. Currently trajopt_ifopt is not recommended. We've used it for some examples, but there are still a few things to be worked out. However, there are some applications like this online planning example which aren't really possible with the way the old trajopt was structured.

[rjoomen]

I think the joint velocity, acceleration and jerk constraint coefficients are done, right? I also tested the MKL Pardiso solver as backend for OSQP and that works (albeit slower than QDLDL in my case), so that box can be checked as well.