Numerical Stability of Seidel Solver

[EdsterG]

I've posted the code to reproduce the bug here: https://gist.github.com/EdsterG/6046289ed1f9ae0a738afd3c09eaa156

When running the given code snippet, I get the following error: The 0-th controllable set is empty. This path is not parametrizable.

The following changes fix the problem: changing the solver, removing the first way-point, removing the last way-point. This seems to be an issue with numerical stability in Seidel.

[pbeeson]

I just ran your code snippet without any changes and it converged fine. I'm using toppra/master with no changes. I'm running Ubuntu 26.04 64-bit. python 2.7

I even added plotting and it all looks ok, except that the accelerations run away at the very end, but I fixed that by adding bc_type='clamped'to the compute_trajectory() call.

[pbeeson]

Additionally, your gp (gridpoints) aren't guaranteed to be unique.
gp = np.unique(gp) fixes that

[EdsterG]

Ah, ws wasn't precise enough. I've updated the snippet with new ws values and left the old ones as ws_prev. Even though np.allclose(ws, ws_prev) is True, the solver fails with the new values.

[pbeeson]

@EdsterG If you replace the gp = np.linspace(0, 1, len(waypoints) * 2 + 1 with either 1) gp= [0,1] or 2) gp = np.linspace(0, 1, len(waypoints) * 3, it works. So 1) it works with only the precision ws points, 2) it works with the ws points and more grid points--making the grid more/less dense affects the runtime. I'm wondering if this isn't related to (or the same underlying problem as) my Issue #13. Sometimes, TOPPRA fails to solve for my in the exact same way, and my solution was to change the points themselves, but changing the gridpoints seems functionally similar to me.

[hungpham2511]

I think there is a bug somewhere in the Seidel solver, currently, I am working on that.

You guys can try 'qpoases' or 'hotqpoases' solvers instead. These are standard QP solvers and supposedly more robust. They are a bit slower though.

[hungpham2511]

Turn out a constant I use for checking constraint satisfaction is way too tight (1e-20). Change it to (1e-10) and @EdsterG gist is now working.

The fix is in the lastest commit e3d9d0eb89b90557c37c4968d16df1f2af542fca

Please note that you need to recompile the Cython source file (by running python setup.py develop) after pulling the lastest commit.

[pbeeson]

Hung, Good news is that the looping version of my toppra client (that kept doubling the density until a solution was found) is no longer looping because its solving the first time every time with the latest commit. I hope this fixes Edster's problem too.

[EdsterG]

Thank you, this issue seems to be resolved.