Openpilot: a_acc_sol ,v_acc_sol in the file "planner",frequency and time looks uncontrolled

[gucasbrg]

a_acc_sol = self.a_acc_start + (DT_PLAN / LON_MPC_STEP) * (self.a_acc - self.a_acc_start)
v_acc_sol = self.v_acc_start + DT_PLAN * (a_acc_sol + self.a_acc_start) / 2.0

1、why don't use actural vEgo,aEgo replace a_acc_start v_acc_start
2、Will the error increase over time?
3、In the while loop, I don't see the control of the DT_Plan time, will the time gap affect it?

[luovang]

This question is confusing me too!
~
self.mpc1.set_cur_state(self.v_acc_start, self.a_acc_start)
self.mpc2.set_cur_state(self.v_acc_start, self.a_acc_start)
~
in longitudianl mpc process, it use [v_acc_start, a_acc_start] as current state.
why don't use actural vEgo,aEgo.
what will happen if the cumulative error is increasing by the v_acc_start ?

[rbiasini]

@gucasbrg , an equivalent discussion was brought up for lateral mpc in https://github.com/commaai/openpilot/pull/700 (a lot of comments... but you might get the point).

to your points:
1- in MPC, unless you have a perfect vehicle model, you really can't set the initial state as the actual vehicle state each time. Imagine your actuators have a time delay that you don't consider in the MPC model: what will happen? that you would keep feeding back zero acceleration, hence the car will never decelerate. Makes sense?
2- the low level control (PID/LQR/INDI, depending on the car) is the one responsible in keeping the error low. If the error keeps increasing, then it's because the actuators are maxed out already, or are unresponsive.
3-let me think about it.