Closed wxmerkt closed 3 years ago
Agreed. Variable type return values are long overdue.
I'm hoping for a lightweight flexible solution that the solvers can populate with different data as required. Maybe based on maps of boost::any and python dictionaries in the wrapper. Possibly with a default conversion to an Eigen::MatrixXd/numpy.array of the state trajectory.
I'd be happy to go with a struct
that can be retrieved manually from the solver, i.e., that isn't the solution
returned. Otherwise your suggestion sounds great, but is part of a larger overhaul.
We've manually exposed the required quantities from the individual solvers. While a better solution with variable type returns would be nice, it's not a priority.
FeedbackMotionSolver
only returns the control trajectory as a solution, while the gains remain transient in that instance of the solver.FeedbackMotionSolver
. DDP/iLQG only have K/k and L/l respectively. iLQR has extra gains.We need a mechanism to store and load a full policy with solution and gains. Perhaps that requires a data struct (u, K, k, x_ref). Let's have a discussion what's best to proceed. At the bare minimum, we need to be able to access K, k, and x_ref.