Detecting bad inputs or outputs

[hungpham2511]

Is your feature request related to a problem? Please describe.

It's undesirable, especially in production, that the algorithm fails silently or produces garbage instead of throwing or returning error. We want to have a feature for checking the path and the time-parametrization quality and setting a relevant "quality" flag.

Possible problem:

• Trajectory has very large duration, zero velocity;
• Input trajectory is very noisy;
• Gridpoint is too sparsed, can't reliably solve the issue.

Question to consider

• When should this check be performed? One possible place is at the return code of the computre_paramerization function.

[hungpham2511]

Large output duration This usually happens when the input trajectory has very small derivatives in all dofs. This leads to very large path velocities (~1e6 or more) creating numerical issues.

There are two ways this can be improved:

• Improve the input trajectory, ensure that the trajectory does not contain all-zero points. Unfortunately, the popular linear_shortcut procedure (implemented in openrave) will produce trajectories with zero initial and end derivatives. Now, in this case, probably the best option is to fit another spline on top of the original trajectory while ensuring that the two trajectories are not far away.
• Implement a form of scaling in the solver wrapper. A version of this strategy implemented here: https://github.com/hungpham2511/toppra/blob/ba9328cd2f4e0ecb1eb71bba5c98fab78a8b4be6/toppra/solverwrapper/hot_qpoases_solverwrapper.py#L206

[github-actions[bot]]

Stale issue message