A Modern C++20 Implementation of OSQP Wrapper

[houchen-li]

Hello everyone! I am an software engineer who serves at an autonomous driving vehicle company of China.

In the past 6 months, I was asked to do lots of convex-optimizing-based trajectory plannings. The solver wrappers which I dealt with at that company were just horrible!!! Memory leaks and out-of-bound exceptions happened every where and all the time! Thus I decided to implement a modernized, user-friendly OSQP C++ wrapper.

As far as I knew, there were 2 osqp cpp wrapper existing on GitHub-- and . But they do come with some known issues:

1. Neither of these two provides the support of adding soft constraints;
2. The interfaces of these two libraries are not user-friendly;
3. They don't have ability to dynamically manage the memory storage.

---

In the end, I found the solutions to above three issues and completed my version of OSQP C++ wrapper. The source code of my library can be found at . This repository uses C++20 standard, but it can be downgraded to C++11 with very little jobs to do. I think this implementation can be applied to broader area of industry, not only be limited in autonomous driving vehicles.

I am wondering if my implementation would be admitted by the official development team of OSQP. Since this is my first public open-source project, you may find some bad implementations in it. But at least this repository provides an third option of OSQP C++ wrapper (from my opinion).

I hope to hear you all like my contribution to the community!

[traversaro]

Hello @houchen-li, first of all, thanks a lot for open sourcing https://github.com/houchen-li/modern-osqp-cpp, it seems quite interesting! Full disclosure, I work on osqp-eigen repo, so I am also interested on your feedback on osqp-eigen.

As far as I knew, there were 2 osqp cpp wrapper existing on GitHub--google/osqp-cpp and robotology/osqp-eigen. But they do come with some known issues:

• Neither of these two provides the support of adding soft constraints;

I am not sure to understand what you mean by "soft constraints". To which functionality of osqp (or modern-osqp-cpp) are you referring to? I searched both repo for "soft constraints" but I could not find anything.

• The interfaces of these two libraries are not user-friendly;

Can you make an example of the aspects that are not user-friendly in osqp-eigen and instead are user friendly in modern-osqp-cpp ? Looking into the API, I guess you mean you have functions like addQuadCostTerm or addConstrainTerm that permit to build a complex cost function step by step, instead of directly setting the full cost and constraints full matrix and vectors, as I guess both osqp and osqp-eigen . This is quite interesting, that kind of make the library something more than a pure osqp wrapper (indeed, in my institution typically we have those functionalities on libraries that are built on top of osqp-eigen). Could it make sense to highlight that difference, for example in your README?

• They don't have ability to dynamically manage the memory storage.

Can you make an example of this? If I am not wrong, in osqp-eigen we support Eigen::Ref that coupled with Eigen::Map should permit you to do that, but perhaps I did not fully get your point.

In the past 6 months, I was asked to do lots of convex-optimizing-based trajectory plannings. The solver wrappers which I dealt with at that company were just horrible!!! Memory leaks and out-of-bound exceptions happened every where and all the time! Thus I decided to implement a modernized, user-friendly OSQP C++ wrapper.

Just to understand, are those wrappers based on osqp-eigen. In that case, if you have any hints on the kind of memory leaks or out-of-bound exceptions you were experiencing, it would be really helpful if you could open an issue in the osqp-eigen repo, thanks!

[houchen-li]

Thank you very much for diving into my source codes! It is my pleasure to hear that you are interested in this project.

---

Let me answer your questions one by one:

I am not sure to understand what you mean by "soft constraints". To which functionality of osqp (or modern-osqp-cpp) are you referring to? I searched both repo for "soft constraints" but I could not find anything.

As it is known to all, OSQP accepts quadratic cost function as input. The shape of 1D-quadratic function is presented in the following figure:

But in industry practice, we may need to pass a shape of this function：

You can imagine that this cost function would only provide repulsion as $x$ increases large than threshold $a$. Unlike hard constraints, this kind of cost function does not forbid variables from going beyond the threshold. But it can have a similar effect to restrict variables comparing to hard constraints. The soft constraint feature is supported by addClampCostTerm in my repository.

---

Can you make an example of the aspects that are not user-friendly in osqp-eigen and instead are user friendly in modern-osqp-cpp ? Looking into the API, I guess you mean you have functions like addQuadCostTerm or addConstrainTerm that permit to build a complex cost function step by step, instead of directly setting the full cost and constraints full matrix and vectors, as I guess both osqp and osqp-eigen . This is quite interesting, that kind of make the library something more than a pure osqp wrapper (indeed, in my institution typically we have those functionalities on libraries that are built on top of osqp-eigen). Could it make sense to highlight that difference, for example in your README?

You pointed it out quite clearly! The API addQuadCostTerm, addConstrainTerm, addLinCostTerm, addClampCostTerm is what I exactly meant user-friendly. And you are right, those stuffs are somethings more than a pure OSQP wrapper should does. But I still presume someone may need it. I apologize for not submitting documentation to my repository at this moment! I really run out of time now! But I will try to complete all the documentation in the following one or two months.

---

Can you make an example of this? If I am not wrong, in osqp-eigen we support Eigen::Ref that coupled with Eigen::Map should permit you to do that, but perhaps I did not fully get your point.

In addClampCostTerm, both objective matrix and constrain matrix require resizing! I put the relevant source code here:

[[using gnu: always_inline, hot]]
    auto addClampCostTerm(
        std::unordered_map<Index, Scalar> constrain_vec, Scalar offset, Scalar linear_coeff,
        Scalar quadratic_coeff = 0.0
    ) noexcept -> void {
        objective_matrix_.resize(num_vars_ + 1, num_vars_ + 1);
        objective_matrix_.updateCoeff(num_vars_, num_vars_, quadratic_coeff * 2.0);
        objective_vector_.push_back(linear_coeff);
        constrain_matrix_.resize(num_cons_ + 2, num_vars_ + 1);
        constrain_matrix_.updateRow(num_cons_, {{num_vars_, 1.0}});
        lower_bounds_.push_back(0.0);
        upper_bounds_.push_back(std::numeric_limits<Scalar>::max());
        constrain_vec.emplace(num_vars_, -1.0);
        constrain_matrix_.updateRow(num_cons_ + 1, constrain_vec);
        lower_bounds_.push_back(std::numeric_limits<Scalar>::lowest());
        upper_bounds_.push_back(offset);
        num_vars_ += 1;
        num_cons_ += 2;
        return;
    }

In the early stage trial, I do consider of using Eigen::SparseMatrix. Then the conservativeResize of Eigen::SparseMatrix is called here. However, it proved that conservativeResize has some memory bugs which may lead to stack collapse. As a consequence of that, I implemented my own SparseMatrix from STL containers to handle the matrix storage and matrix size expansion.

---

Just to understand, are those wrappers based on osqp-eigen. In that case, if you have any hints on the kind of memory leaks or out-of-bound exceptions you were experiencing, it would be really helpful if you could open an issue in the osqp-eigen repo, thanks!

Don't be worried! The OSQP wrapper which my company are working on is neither google/osqp-cpp nor robotology/osqp-eigen. They implemented their own trashes! Let us just forget about that brain-blow-up stuff!!!

[traversaro]

Thanks for the explanation. Given that, probably it may be useful to point out to this features behind just a OSQP wrapper in the documentation of the library, whenever you have time to work on this!

However, it proved that conservativeResize has some memory bugs which may lead to stack collapse.

This is quite interesting. Do you have any pointer or way to reproduce these problems?

[goulart-paul]

It seems to me that your goal here is a more of a general modelling type package rather than wrapper for OSQP as such. If you had such a package then you could presumably use it as a wrapper around other solvers as well.

In other words it seems that you are trying to play a role similar to CVXPY or similar (see list under "Modelling frameworks" here). Maybe also this project is relevant, though it targets control problems specifically.

[houchen-li]

I was struggling with my new job last week. I finally got some time to reply to you!

This is quite interesting. Do you have any pointer or way to reproduce these problems?

The stack issue of Eigen::SparseMatrix::conservativeResize() was first found on Eigen 3.4.0 of Arch Linux. However, one of my friends told me that he once worked with this interface on Eigen 3.3.7 of Ubuntu 20.04 and didn't see the same issue before.

[imciner2]

Neither of these two provides the support of adding soft constraints;

OSQP itself doesn't support soft constraints natively in the algorithm (yet...), so any wrappers that would support that are implementing it in their wrapper structure. I am working on an idea for how to support soft constraints natively in the projection operator, but it probably won't be available for a bit.

They don't have ability to dynamically manage the memory storage.

Managing which parts of the memory? We have actually been adding some memory storage wrappers in the OSQP test suite to wrap the OSQP objects inside std::unique_ptr objects with the appropriate deleters to call our free routines (https://github.com/osqp/osqp/blob/master/tests/osqp_api.h) to make our test system cleaner, and I have been considering adding those to the main OSQP headers behind appropriate compiler guards so they are only active when C++ supporting std::unique_ptr is detected.

But the general idea is that since OSQP is a C library, the user is still responsible for the vast majority of the memory management instead of the library.