You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. Some other Chevy Volt drivers and I were discussing the tuning of the vision turn controller to avoid excessive unnecessary braking, and I had some thoughts on how to improve the logic:
Currently, it's using the max predicted lateral acceleration from any of the upcoming path curvatures as the variable that limits your speed right now.
Two things:
it uses your current speed to estimate future lateral acceleration. This is fine unless you're accelerating or decelerating, in which case your future lateral acceleration will be greater/lesser than estimated. I could make it consider the distance at which the maximum lateral acceleration will take place, then use your current acceleration to estimate what your velocity will be by the time you get to the max curvature point. This will prevent it from slowing down to and maintaining the limited speed when the max curvature point is still 50m away, but rather arrive at the necessary speed at the necessary time.
if the max predicted acceleration is only predicted to occur for a split second, or for the entirety of the planned path, it makes no difference in terms of how the controller responds. You will slow to the speed necessary for the max curvature even if it's just a short corner that a human would blow through using the extra space in the lane rather than slowing down. Instead of using the max predicted acceleration at face value, we could use a path integrated max acceleration instead. So high lateral acceleration over a short length will not result in heavy braking, but sustained high lateral acceleration will.
I thought about implementing (2) in my fork, testing, and submitting a PR. (1) sounds like the concept is mostly correct, but missing something to keep the predicted deceleration from precluding the controller's deceleration response. Thought I'd see what you though of these ideas before attempting anything.
The text was updated successfully, but these errors were encountered:
Hi. Some other Chevy Volt drivers and I were discussing the tuning of the vision turn controller to avoid excessive unnecessary braking, and I had some thoughts on how to improve the logic:
Currently, it's using the max predicted lateral acceleration from any of the upcoming path curvatures as the variable that limits your speed right now.
Two things:
it uses your current speed to estimate future lateral acceleration. This is fine unless you're accelerating or decelerating, in which case your future lateral acceleration will be greater/lesser than estimated. I could make it consider the distance at which the maximum lateral acceleration will take place, then use your current acceleration to estimate what your velocity will be by the time you get to the max curvature point. This will prevent it from slowing down to and maintaining the limited speed when the max curvature point is still 50m away, but rather arrive at the necessary speed at the necessary time.
if the max predicted acceleration is only predicted to occur for a split second, or for the entirety of the planned path, it makes no difference in terms of how the controller responds. You will slow to the speed necessary for the max curvature even if it's just a short corner that a human would blow through using the extra space in the lane rather than slowing down. Instead of using the max predicted acceleration at face value, we could use a path integrated max acceleration instead. So high lateral acceleration over a short length will not result in heavy braking, but sustained high lateral acceleration will.
I thought about implementing (2) in my fork, testing, and submitting a PR. (1) sounds like the concept is mostly correct, but missing something to keep the predicted deceleration from precluding the controller's deceleration response. Thought I'd see what you though of these ideas before attempting anything.
The text was updated successfully, but these errors were encountered: