Planning very sensitive to vehicle vibrations, frequently fails.

[josh-wende]

Using Apollo 7.0:

When driving autonomously, the vehicle very frequently stops because a planning cycle fails due to the Piecewise Jerk Nonlinear Speed Optimizer determining that the QP problem is infeasible. I have determined that this happens when the vehicle shakes, presumably since the IMU velocity/acceleration values jump around during shaking. I can't figure out why I am having this issue now when I never did before, any insight into what might be causing this is greatly appreciated.

[qwetqwe]

Maybe current initial acceleration exceed the maximum acceleration because of vibrations, which leads to Ipopt solve failed

[zhanglonggao]

Hello! I have encounterd the same issue, have you sloved it ?

Using Apollo 7.0:

When driving autonomously, the vehicle very frequently stops because a planning cycle fails due to the Piecewise Jerk Nonlinear Speed Optimizer determining that the QP problem is infeasible. I have determined that this happens when the vehicle shakes, presumably since the IMU velocity/acceleration values jump around during shaking. I can't figure out why I am having this issue now when I never did before, any insight into what might be causing this is greatly appreciated.

[josh-wende]

I added some functions that specifically checked for infeasible starting conditions (either initial acceleration/velocity out of range, or the initial velocity plus acceleration combined with the maximum jerk not being enough to slow down without going over the max speed) and modifies the inputs to what can be feasible if so. It's a bit hacky, but it works. I found that just setting the initial acceleration to always be 0 for the solver made it a lot better too, without really affecting the behavior too much.

Hope this helps.

[zhanglonggao]

well, thanks for your reply. I'd like to try the second way first. May I ask how to set the initial acceleration to always be 0 ?

At 2024-03-30 01:42:59, "Josh Wende" @.***> wrote:

I added some functions that specifically checked for infeasible starting conditions (either initial acceleration/velocity out of range, or the initial velocity plus acceleration combined with the maximum jerk not being enough to slow down without going over the max speed) and modifies the inputs to what can be feasible if so. It's a bit hacky, but it works. I found that just setting the initial acceleration to always be 0 for the solver made it a lot better too, without really affecting the behavior too much.

Hope this helps.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[josh-wende]

I believe I just set s_ddot_init_ to 0.