Hyundai Palisade: lateral torque custom ff

[twilsonco]

Custom linear torque FF for Palisade.

Cuts feedforward error nearly in half, and includes a strong (compared to Sonata) boost to feedforward at low speed:

MAE old 0.53, new 0.3174
STD old 0.6782, new 0.3753

Fit from 5.5 hours of driving data: 1.2 million samples filtered down to 744 points with constant curvature rate, no saturation, and no driver torque.

describe(steer_offsets) = DescribeResult(nobs=1213141, minmax=(-3.0503900051116943, 1.6359049081802368), mean=-0.1226486928619221, variance=0.16492718483460828, skewness=-0.23682112474727382, kurtosis=3.0906149405683188)

Samples: 180289

Regularized samples: 744

speed: DescribeResult(nobs=744, minmax=(3.6590705661773684, 30.800244040408376), mean=15.921536737956117, variance=45.683681725591875, skewness=0.4682955341866623, kurtosis=-0.4515943186297138)
angle: DescribeResult(nobs=744, minmax=(-2.908146740549286, 2.4051321122045923), mean=0.0018987360222742315, variance=0.37588366700911163, skewness=-0.9345003933395339, kurtosis=4.381400715378035)
steer: DescribeResult(nobs=744, minmax=(-5.348275855163049, 4.007272715713039), mean=-0.050323769924293285, variance=1.0980807038637221, skewness=-0.7713880877588846, kurtosis=4.474236103512917)

lat_accel 0.00-0.20:338, lat_accel 0.21-0.41:147, lat_accel 0.43-0.63:94, lat_accel 0.64-0.84:48, lat_accel 0.86-1.06:26
lat_accel 1.07-1.27:23, lat_accel 1.29-1.49:11, lat_accel 1.50-1.70:5, lat_accel 1.71-1.91:5, lat_accel 1.93-2.13:4
lat_accel 2.14-2.34:0, lat_accel 2.36-2.56:8, lat_accel 2.57-2.77:2, lat_accel 2.79-2.99:1, lat_accel 3.00-3.20:0

mph 08-13:32, mph 13-18:60, mph 18-23:74, mph 23-28:82, mph 28-33:80
mph 33-38:128, mph 38-43:111, mph 43-48:38, mph 48-53:27, mph 53-58:11
mph 58-63:52, mph 63-68:40, mph 68-73:9, mph 73-78:0, mph 78-83:0
mph 83-88:0, mph 88-93:0, 

[gregjhogan]

I have previously done some analysis on this and wasn't happy enough with my results to submit a PR. For simple feed forward functions like this the thing that bothered me the most was that it sometimes predicts the need for a decent amount of torque in the wrong direction when the road has enough roll. I tried to model some more complicated things using roll, but at the time I stopped because there used to be a roll bias issue in older openpilot logs which probably isn't the case any longer. I was also missing some unknown factor that seemed significant which may have been friction.

Here was my best simple linear feed forward:

motor_torque_predicted = angle * (0.018 * velocity)

(I found motor torque output is usually 4.25x larger than the LKAS request value)

Here was my best roll compensating feed forward:

motor_torque_predicted = max(min((-a + (r * 9.81)) / 2.7, 1), -1) * 384 / 128 * 4.25

a = lateral accel, r = roll
2.7 = max lateral accel for the vehicle
384 / 128 = 3 = max torque request allowed in Nm
4.25 = request multiplier to get motor torque output
(remove / 128 * 4.25 for torque request from openpilot, request range is -384 to 384 currently)

Here is an example segment comparing the old PID controller feed forward, my above angle based feed forward, and my above roll feed forward:

Here are some numbers from 10k segments I ran it on:

predict 0
mean abs err: 3.9269496762992686

pid ff
motor_torque_predicted = angle * (velocity**2) * 0.00005 * 4.25
mean abs err: 2.8546331208258655 0.27306602932685076%

angle ff
motor_torque_predicted = angle * (0.018 * velocity)
mean abs err: 1.1238583343493609 0.7138088269548497%

lat accel ff
motor_torque_predicted = max(min((-lat_accel + (roll * 9.81)) / 2.5, 1), -1) * 384 / 128 * 4.25
mean abs err: 0.9948188822354284 0.7466687978612094%

I like to compare numbers to what the MAE is when predicting zero which tells us what % of the error you are correcting. I also found it was easy to make straight driving better at the expense of making cornering worse, and you surely have far more samples going straight compared to turning, so I would suggest bucketing data by speed, roll, and lateral acceleration to get a good understanding of where you are improving things or making things worse.

[gregjhogan]

Here is a significant effect I feel like I never accounted for well - this is turning into and then out of a single fairly tight corner. Notice the huge range of torque for the same angle! (blue line that the label is obscured is desired angle)

I believe the speed was fairly constant here and so it seems the range of torque is fairly constant across all angles. I can't remember for sure, but I think the size of the range decreased as speed increased. It made me think I needed to add a factor based on whether you are increasing or decreasing the angle and current speed, or something. (e.g. for the above image, motor torque output needs an extra 2.5 Nm when increasing the angle and -2.5 Nm when decreasing the angle)

[twilsonco]

Very cool!

I notice one big difference in the form of the feedforward is yours is directly proportional to lat acceleration and speed, where this FF is directly proportional to lat acceleration and inversely proportional to speed.

For your second plot, are you filtering out points with non-zero steer rate and curvature rate?

I think conceptually, the question you want feedforward to answer is "how much torque to hold a constant angle" (maybe also at constant speed, but that seems less important). This fit process is based on that question.

Re binning, thanks. Binning is used here, otherwise the near-zero angle data swamps the fit.

[twilsonco]

@Swish865 on Discord is testing Palisade and reporting some major concerns. There were some other learning pains in the fit process due to differences in torque units between GM and Hyundai. Other testers please wait until I update.

[gregjhogan]

I did all this before the torque controller existed, and I don't think I filtered anything out in the second plot (note the decent number of brown 0 deg/s dots) it was just a short section of a single segment entering and exiting a single corner.

[gregjhogan]

I just realized my "lat accel ff" above is what the torque controller currently uses and you are taking that value adjusting it further based on speed. I would not expect speed alone to be significant in accounting for remaining error, however I didn't do much analysis on low speed driving.

[twilsonco]

Yeah, this is just what shows in the data, consisting of such filtered points. Seems to have a huge speed dependence, with 3-4X the feedforward at very slow speeds, that smoothly transitions to very close to the value determined for the torque controller at higher speeds.

[sshane]

For this and https://github.com/commaai/openpilot/pull/25511 @nuwandavek does the low speed factor in latcontrol_torque account for this?

[nuwandavek]

For this and #25511 @nuwandavek does the low speed factor in latcontrol_torque account for this?

Yeah, this should ideally be resolved. There may be some issues with low speed control (exacerbated by low speed model issues), but that will be fixed more generally and not per platform.

[sshane]

Closing for reasons above. I would plot your data again with the torque controller compensations, so you get the full picture.

[twilsonco]

That's fine. Note however that low-speed factor only affects the error term in the torque controller, so I don't see how it could possibly have a comparable effect to a steeper feedforward. "Friction" also adds a constant amount to the feedforward based on error, so these are conceptually non-overlapping.