Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MPC #29

Draft
wants to merge 24 commits into
base: master
Choose a base branch
from
Draft

Add MPC #29

wants to merge 24 commits into from

Conversation

kjohnsen
Copy link
Contributor

No description provided.

i3ta and others added 6 commits May 12, 2024 13:12
The commit that the vcpkg submodule was linked to depended on a version of zlib that was downloaded from the zlib website that is outdated. This commit updates the vcpkg to the newest version, which gets zlib directly from the github repository.
Roughly implemented the example code for MPC controller, based on the example from cloctools/lqmpc.
- The code for the MpcController is partially implemented (only necessary methods have been added, getters and setters need to be added)
- Code still needs to be debugged (there are multiple memory leaks that need to be fixed)
Comment on lines 94 to 99
Matrix Px = arma::kron(Matrix(N_, N_, arma::fill::eye), Q_);
Matrix Pu1 = arma::kron(Matrix(M_, M_, arma::fill::eye), 2 * S_ + R);
Matrix Pu2 = arma::kron(Matrix(eye_offset(M)) + Matrix(eye_offset(M, 1)), -S_);
Matrix Pu3 = block_diag(Matrix((M_ - 1) * m_, (M_ - 1) * m_, arma::fill::zeros), -S_);
Matrix Pu = Pu1 + Pu2 + Pu3;
P_ = arma::trimatu(2 * block_diag(Px, Pu)); // Taking only the upper triangular part
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these sparse, like in the Python lqmpc? That P matrix gets pretty big, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They aren't sparse right now, but I think I should be able to make them sparse. Speaking of sparse matrices, is it okay if I define a type for sparse matrices in lds.h like the Matrix and Vector types?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I think it would be fine to define a sparse matrix type in lds.h


private:
/**
* @brief Set the matrix for the OSQP solver from an Armadillo matrix
Copy link
Contributor Author

@kjohnsen kjohnsen Jun 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doxygen comment (and for from_sparse and from_vec) is misleading; it sounds like it will directly set a matrix on the controller, but instead just does the conversion

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I will fix that!

*
* @return The identity matrix with an offset axis
*/
arma::SpMat<data_t> eye_offset(size_t n, int k = -1) {
Copy link
Contributor Author

@kjohnsen kjohnsen Jun 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it helps if its output is dense, but FYI arma has functions to help do this: https://arma.sourceforge.net/docs.html#diagmat, https://arma.sourceforge.net/docs.html#diag, https://arma.sourceforge.net/docs.html#diags_spdiags

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't see that! I think that will make it easier to do.

// Implement methods

template <typename System>
inline MpcController<System>::MpcController(const System& sys, Vector u_lb,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might as well put inline functions above in the class definition

const Vector& u0, const Matrix& xr) {
size_t n_sim = t_sim / sys_.dt(); // Number of points per simulation step

OSQPSolution* sol;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the optimization problem get reinitialized on every step? That will probably be a lot slower than if parts can be reused and just the state is updated

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think the problem does get reinitialized every step. I mostly was trying to stick to what the Python package had (except currently the fast update function is never called, which I haven't fixed yet because the slow update doesn't work correctly), but I can look more into how to keep some of the previous states to prevent reinitializing at every step.

Comment on lines 310 to 324
// Solver, settings, matrices
OSQPSolver* solver;
OSQPSettings* settings;
OSQPCscMatrix* A = from_matrix(Acon_);
OSQPCscMatrix* P = from_matrix(P_);
OSQPFloat* q = from_vec(q_arma.t());
OSQPFloat* lb = from_vec(lb_);
OSQPFloat* ub = from_vec(ub_);

// Set settings
settings = (OSQPSettings*)malloc(sizeof(OSQPSettings));
if (settings) {
osqp_set_default_settings(settings);
settings->verbose = false;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that this follow the example of Python lqmpc, where prob.setup() is called every step. But is there a way to keep the solver, settings, matrices, vectors, etc. around from one step to the next? I imagine this would help things go faster, and might help us keep memory leaks under control since pointers wouldn't be created on every step

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't see this comment before I responded to the previous one, but I think that is probably what I should be aiming for and I will try my best to reuse as many of the variables as possible.

throw std::runtime_error(error_message);
}

OSQPSolution* sol = std::move(solver->solution);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this recommended by OSQP? there aren't memory problems with osqp_cleanup later after moving the solution?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. I only did this because I was trying to avoid copying data over again and again, but now that I am looking at it it might cause memory leaks. Let me look into the code a little bit more and see what exactly is going on, and I will try to make sure that there are no memory problems between copying the OSQP solution and clean up and freeing up memory.


// Clean up
osqp_cleanup(solver);
if (q) free(q);
Copy link
Contributor Author

@kjohnsen kjohnsen Jun 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why free() instead of delete? (not saying delete is right; I'm not an expert on the finer points of memory management). Though these wouldn't be necessary if we reuse memory from step to step

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, free() is for freeing memory allocated with malloc, whereas delete is used for freeing memory allocated with new, but I will verify that to make sure I'm not doing anything wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The follow-up question then is why malloc instead of new?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't actually have a good reason for using either. I mostly just followed what the other controllers did and tried to align closely to that.

for (OSQPInt j = 0; j < mat->n; j++) {
for (OSQPInt i = 0; i < mat->m; i++) {
if (A(i, j) != 0) {
mat->i[n] = i;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some comments would be good here to be able to follow what's going on with i, x, p, n, etc.

mat->nzmax = A.n_nonzero;
mat->nz = -1; // -1 means the matrix is in CSC format (required for API)

mat->p = (OSQPInt*)malloc((mat->n + 1) * sizeof(OSQPInt));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, hard to see if there's a potential memory bug here when I don't know what p, i, x are

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will fix that. Those are variables associated with the OSQPCscMatrix type.

OSQPInt *p
column pointers (size n+1); col indices (size nzmax) starting from 0 for triplet format

OSQPInt *i
row indices, size nzmax starting from 0

OSQPFloat *x
numerical values, size nzmax

throw std::runtime_error(error_message);
}

arma::sp_mat::iterator it = A.begin();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing it goes over elements and j is the index of the element?

Copy link
Contributor Author

@kjohnsen kjohnsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, awesome job @i3ta! It's amazing how you put together so much technical stuff on the first draft with so little direction

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants