Skip to content

Navigation Menu

Sign in
Sign up

Solver warm start #1229

PepMS started this conversation in Ideas
Mar 14, 2024 · 2 comments · 1 reply
Discussion options

I am using Crocddyl solvers to run MPC controllers. One common case within the MPC use is to use the previous iteration solution as a warm start for the current call to solve(). In Crocoddyl's solvers, I can only see one signature of the solve method, which requires passing a vector with the initial state and control trajectories. This method immediately copies the warm start trajectories via the setCandidate() function.

I think it would be interesting to overload the solve method so that init_xs and init_us are not required and that the directly starts iterating with the values contained within xs_ and us_.

I couldn't find this feature, but I am willing to implement it. If this issue could be tackled with the current API, I would appreciate a little guidance! Thank you!

You must be logged in to vote

Replies: 2 comments 1 reply

Comment options

When having hybrid events, it is always convenient to update the warm start. For instance, it is better to shift the previous solution. However, we could agree on an API to accommodate our requirements.

Could you elaborate on an API proposal that potentially doesn't break actual code? Writing a Python pseudo-code would be helpful.

I have some ideas but prefer to hear from you first. Thanks!

You must be logged in to vote
0 replies
Comment options

Hi, sorry for the delay.

I was thinking about overloading the solve function with a method that does not consider the init_xs and init_us. In this case, the method would skip the setCandidate function and start solving using the values in xs_ and us_. Of course we should add some safety checks on xs_ and us_. The method would look like this:

virtual bool solve(const std::size_t maxiter, const bool is_feasible,
 const double init_reg) 
{
// I skip the setCandidate
if (std::isnan(init_reg)) {
 preg_ = reg_min_;
 dreg_ = reg_min_;
 } else {
 preg_ = init_reg;
 dreg_ = init_reg;
 }
// ... the rest of the current solve method
}

Then, the current version of the method would use the one defined above as:

solve(const std::vector<Eigen::VectorXd>& init_xs,
 const std::vector<Eigen::VectorXd>& init_us,
 const std::size_t maxiter = 100, const bool is_feasible,
 const double init_reg)
{
 setCandidate(init_xs, init_us, is_feasible);
 
 solve(maxiter, is_feasible, init_reg);
}

The only problem I see with this approach is that right now, all parameters in the solve method are defaulted, and I think the compiler cannot resolve the overloading.

You must be logged in to vote
1 reply
Comment options

It will break the current API as we already define the former case, but not as you expect. We could consider breaking it but needs a consensus.

Does someone else want to provide his/her thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Ideas
Labels
None yet
2 participants

AltStyle によって変換されたページ (->オリジナル) /