I noticed in the second stage of LP solving, if the solver failed to find a solution, the jerk will be doubled and try to solve again. In some cases, the jerk will be increased to a very large value to get a success. This would likely happen when the adjacent two pieces uses different feedrates.
Then I increased the window size from 5 to 10, it was found we no longer need to increase the jerk anymore.
So maybe it is better if we temporary increase the look ahead window size when LP solver failed instead of violating the constraints.
Thanks for sharing this very interesting observation, Yakunix.
I’m not at all happy with the actual workaround of increasing the jerk bound in case of LP solver failure !
If CLP fails to find a solution this means that CLP thinks that the problem is infeasible.
But this should never happen in theory for our special type of LP problem.
Why ?
v0 and at0 are herited from the previous window where he succeeded to find a solution where zero speed and zero acceleration was imposed at the end of the window.
The window shift adds a new curve piece at the end.
Even if this new curve piece is very short and/or has very high curvature, the problem should always stay feasible. The last piece in the new window can be travelled at very low speed if necessary.
Maybe some numerical issues (roundoff errors) ?
I believe it would be helpful analyzing more in depth the situation where CLP fails in the second stage.
By the way, when running complex G codes, we observed that there are also very rare cases where CLP fails in the first stage !!
I recommend to analyze the v0 and at0 values heritated from the previous window.
Maybe they are slightly too high and the new problem becomes infeasible because of a constraint violation right at the beginning ???
Maybe a better idea :
Instead of a constant vmax in the first piece inside the window, a vmax ramp.
Starting at the original value of vmax, and linearly (w.r.t u) decreasing to e.g.
0.999vmax.
This makes sure that the heritated value of v0 is at most 0.999vmax.
A similar reasoning for amax.
But first at all we must be sure that the heritated values are the root cause of the problem
I believe we tried “linprog” (Matlab optimization toolbox) instead of CLP, and I believe the result was the same.
It seems not to be a problem related to the LP solver.
What I did not yet try (it’s a little bit of work …) :
Try to solve the problematic window with the original non-convex jerk constraint.
This could be done using casadi and the standard IPOPT solver.
The simplest tool is https://github.com/meco-group/optispline
In the actual implementation the jerk constraints are approximated in a conservative manner with the sqrt(q^{\star}) term from the previous solution at the first stage.
Maybe this is too conservative ?
That’s why solving the original non-convex problem - just for debugging purposes - might be an idea in order to find the root cause.
If the sqrt(q*) is too conservative, say, 10^6, the jerk constraint should be easily satisfied. But in fact, the jerk sometimes should be increased by several hundreds of times to get a solution in the second stage, meaning at some point on the curve, the sqrt(q*) should be larger?
I didn’t have the experience of solving the non-convex problem, if it can return the solution within 100ms, maybe it is also acceptable?
The idea is not to switch to nonconvex problems because they are generally hard to solve and solver lack reliability.
The idea was to see (offline) if the problem of infeasibility disappears if solving the original problem with the true jerk constraint.
But it might be a better idea to inspect q*(u) !
Why the hell the approach with the two LP stages often works fine, and suddenly gives an infeasible LP problem. There must be a fundamental difference.
possible, but a lot of work which only serves to a better understanding of the problem.
I think it would take me 3…5 days of work to get work the nonconvex problem using the modelling language casadi (which I know quite well). An initial guess for nonconvex problem is absolutely necessary. q1* might serve as an initial guess.
I’m quite busy these days, end of the semester, exams, not sure if I will find the time to do this …
