Open mpowelson opened 4 years ago
@mpowelson Is this what is remaining for completing trajopt_ifopt where it has the same functionality as trajopt?
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.
I'm going to start chipping away at this, starting with #192
Other possible performance improvements.
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
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.
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.