Closed EdsterG closed 6 years ago
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.
Additionally, your gp (gridpoints) aren't guaranteed to be unique.
gp = np.unique(gp)
fixes that
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.
@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.
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.
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.
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.
Thank you, this issue seems to be resolved.
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.