Closed sinashm closed 5 years ago
Are you imposing these constraints using the penalty method? If so, the constraint violation can be controlled via the constraint tolerance. If you're using regular constraints, there shouldn't be any constraint violation. I'll have a look.
@sinashm How small is the constraint violation? Can you also share the exit status of the algorithm (whether it has converged, norm of FPR, number of iterations, etc)?
I am using: bounds= og.constraints.Rectangle(umin,umax) The constraint violation is quit small -5e-11 however the sign is messing with further parts
It is safe to take a projection on the solution you're getting. The guarantees that you have is that the solution you will get has an FPR of adequately small norm. This does not mean that the solution will be feasibly, but the infeasibility is controlled by the tolerance.
In the algorithm there are two iterates: u
and u_bar
(see below). Both converge to the solution, but u_bar
is always feasible. Our implementation returns u
(which might be slightly infeasible), instead of u_bar
.
Perhaps it makes better sense to return u_bar
instead of u
. I wouldn't like to return both - this would confuse the users.
I added the following line in method solve
in panoc_optimizer.rs
and all unit tests pass:
// copy u_half_step into u
u.copy_from_slice(&self.panoc_engine.cache.u_half_step);
I need to create a test to make sure everything works. Thanks a lot for reporting this.
I defined the bounds on decision variable 0 to 30, however, in some cases, the solver returns a very small negative value.
on Ubuntu 16.04 with rustc 1.35.0
I am using binder of generated code in ROS, for regenerating the code, you need rosbag of the data.