[Discussion] On PID controller changes for starting ego vehicle on downward slopes.

[danielsanchezaran]

Greetings, I would like to discuss possible solutions to the issue presented here: autowarefoundation/autoware.universe#5391

In resume:

1. Autoware seems to have a problem when the vehicle is trying to start on a downwards slope: The vehicle won't move.
2. This problem is most likely caused by an overshoot on the slope compensation.
3. In said cases, the integrative part of the PID should increase the acceleration command to compensate the overshoot, but it doesn't.

Regarding point 3), the current implementation of the PID controller does NOT accumulate error when the vehicle speed is low. So, the PID controller becomes a PD controller for low speeds (decided by the 'current_vel_threshold_pid_integration' parameter).

This is an intentional design decision (described here) Quote:

"Also, the integral term is not accumulated when the vehicle is stopped. This is to prevent unintended accumulation of the integral term in cases such as Autoware assumes that the vehicle is engaged, but an external system has locked the vehicle to start."

Possible solutions:

1. Take out the velocity restriction:
   But I believe that, by tuning the I effort parameters:
   max_i_effort
   min_i_effort
   The maximum acceleration caused by the I controller can be tuned to be comfortable & safe, even when the error integration is saturated. So, the velocity limit is actually not necessary. I have made a Draft PR with this solution.

Pros:

1. Easy to implement, no major changes in code.
2. Only 2 parameters would need to be re-tuned.
   Cons:
3. Tuning the max_effort_i and min_effort_i to accommodate for comfortable vehicle takeoff (going from STOPPED state to DRIVING) might affect the vehicle behavior negatively in normal DRIVING state (i.e if min_i_effort magnitude is decreased, the I controller will saturate early in situations where the error accumulates fast which might cause slower braking).

2. Introduce two new parameters:

max_i_takeoff_effort
min_i_takeoff_effort

In this case we can use these 2 parameters to implement an anti wind up for the I controller: this approach is often referred to as integral clamping or saturation. These values would only be used when the ego vehicle speed is less than ''current_vel_threshold_pid_integration' and the vehicle is taking off (going from STOPPED state to DRIVING).

Pros:

1. More customization on the vehicle response.
2. No effect on normal driving scenarios where the vehicle is already moving.
   Cons:
3. Increases complexity of the system.
4. Might be hard to tune the two parameters.
5. More parameters to consider.
6. When the vehicle is braking, and its speed reaches "current_vel_threshold_pid_integration", the I controller output might be diminished if
   m_error_integral > min_i_takeoff_effort / ki (The error gets clamped and the I output changes suddenly). I believe that, in practice, this is not a real issue if current_vel_threshold_pid_integration is low in magnitude.
   I would like to hear your comments/suggestions, if any.
   @takayuki5168 @TakaHoribe @zulfaqar-azmi-t4 @VRichardJP @brkay54 @mehmetdogru

[danielsanchezaran]

One comment that might be useful when testing changes related to this issue on the simulator. From @takayuki5168 :
enable_road_slope_simulation set to false by default.
https://github.com/autowarefoundation/autoware.universe/blob/ce0f11ab2f688f69a89c1[…]rc/simple_planning_simulator/simple_planning_simulator_core.cpp
To simulate the road slope, we have to enable this by adding a parameter set to true in the vehicle_description file. The following is the example of the vehicle_description of the J6 vehicle.
https://github.com/tier4/j6_gen1_description/blob/2a14311ccbdc7a764f2cf1a9534a6b7cc8704616/j6_gen1_description/config/simulator_model.param.yaml#L9