Fix lane centering with single lane line

[Gernby]

This is to fix the new lane centering issue that was introduced by changes to the 0.6 MPC. The new MPC logic does improve OP performance with single lane lines IF the lane is wide. However, if the lane is not wider than the US Interstate Highway standard, then the values below will cause the MPC to steer the vehicle too far away from the 1 visible lane line. This fix will prevent that by using a more conservative default width, which will draw the vehicle closer to the 1 visible lane line.

[rbiasini]

The Interstate Highway standards for the U.S. Interstate Highway System use a 12-foot (3.7 m) standard lane width, while narrower lanes are used on lower classification roads. In Europe, laws and road widths vary by country; the minimum widths of lanes are generally between 2.5 to 3.25 meters (8.2 to 10.7 ft).

So yeah, I think assuming slightly smaller lane lines by default will help for the average case and also for the case you described.

[zorrobyte]

@rbiasini this commit seems to make my vehicle ride much too closely to a single lane line. Additionally, lane width is set when both lane lines are detected, right? So if I was in a curve where both lines weren't solid throughout (such as the right one dropped out), the "center" would then immediately revert to the single lane line calculation (this PR)

Then, if the right lane line, or whatever, was picked up again, center would immediately be set to the actual center. This can cause the recent undesired behavior of my vehicle jerking around in corners and often crossing the center line.

https://discordapp.com/channels/469524606043160576/574796986822295569/602316109701447701

^^ this may not be immediately related to this issue, but crossing the center line where I'd front end oncoming traffic forced me to investigate.

Jerking around, crossing the center line:
5e7462b4437e3372|2019-07-21--01-16-12--23
5e7462b4437e3372|2019-07-21--01-06-21--1
5e7462b4437e3372|2019-07-21--00-47-12--7

Reverting this PR:
5e7462b4437e3372|2019-07-22--00-29-18--3 (uploading)

Community feedback:
https://discordapp.com/channels/469524606043160576/524327905937850394/602649713321312258
https://discordapp.com/channels/469524606043160576/524327905937850394/600337881021546517

In fact, I can't remember hardly any experiences that OP didn't turn enough pre-PR. If anything, I want to be further from the center line in curves, so I don't sideswipe oncoming traffic.

Hondas don't have nearly as much torque as Toyota, and I'm driving a Prius. Maybe the additional desired angle is needed on Hondas to make up for this.

[zorrobyte]

You know what would be cool @Gernby @pd0wm @geohot ? If OP took the actual, calculated lane width when both lines were detected, and setup more of slow decay moving average back to a single lane line estimation; kind of like how ParamsLearner works with slow angle offset, with higher v_ego increasing the learning rate (possibly), or gating the "learners" to a range of v_egos. This way there isn't sudden center changes dependent on if both lane lines are detected, or not - smoothing out lateral performance in changing road conditions.

Lane widths are rather regionally based, and some sort of slow decay, moving average learner that is persistent would resolve the need for hard coded, manually tuned values. Indiana people usually drive on Indiana roads, which follow lane width construction best practices (for their region), Californians, Europeans, etc.

[ErichMoraga]

Slow decay sounds good. Let me know when you're done coding that ;-)

[Gernby]

@zorrobyte It seems that the issue you're describing is due to the existing "decay" rate being too high. The current decay rate will cause lane width to transition back to the speed_lane_width in about 1 second after a lane line disappears. If the coefficient in the highlighted line below was changed to 0.01, the rate would be about 5 seconds.

[zorrobyte]

That makes sense @Gernby 0.05*20hz = 1 sec.

I'll test this fix and report my findings (I've set mine to 10sec)

[Gernby]

I think that the coefficient 2 lines down should be reduced by the same factor, or it may create weird behaviors

[zorrobyte]

I just realized that my ret.steerActuatorDelay was set to 0.8 and not 0.08 as I expected.
I'm going to have to invalidate all of my comments and start testing over again. FML.

[ErichMoraga]

Damn, and I thought Comma's stock value of 0.5 was high...

[jasonhamilton]

I think this was a good PR by @Gernby and I've modified my setup to use even smaller values than the PR (I set speed_lane_width to 2.8). I live in an area with small lanes (Los Angeles), which is probably not the norm, and when one lane line is not detected well stock OP (devel) tends to pull into the other lane.

Basically, if your lane width is overestimated by the speed_lane_width variable your vehicle will have the effect of moving away from the high-probability lane line, which makes little sense IMO. It seems safer to have the default setup hug the one visible lane line vs potentially move into the other lane.

[zorrobyte]

@jasonhamilton see #755

[jasonhamilton]

@zorrobyte Thanks! That code looks promising!