Interesting discussion on "sliding the rear"

[HornetMaX]

[WARNING: the stuff below will be pretty technical]

Hi all,

on the MXB forum I had an interesting discussion about the difficulty in "sliding the rear" (see it here).

First thing, look at this video:

https://www.youtube.com/v/0t7RiKMUsDc

Q1: Do we all agree that as the rear "slides out", the rider countersteers (turn the bars right, as this is a left turn) in order to keep the rear slide under control ?
To me it's clear (and it's what I can read on bike physics books) but on the MXB forums others were saying that to keep the rear slide out under control one has to stand up the bike (which would require to turn the bars left). To me doing that would just send you high side.

Next, Piboso put this comment in the discussion:

The virtual rider tries to calculate if the bike is under or over-steering. In case of under-steer, it steers more, the opposite in case of over-steer.

I asked to clarify the above (still pending his reply): I need to know how he defines exactly "over/under steer" and "steer more", but I'm fairly sure to know what he's referring to exactly.

If all that is true, then there's something that looks very suspect: if the virtual rider always try to have a neutral behavior (neither over nor under steer), then it is not true that the "steer" input in GPB (and MXB) dictates the target lean angle. It sort of dictates the trajectory's turning radius. And that can be very different.

The more I think about it the more I tend to think that the difficulty of "sliding the rear" in GPB and MXB do come from the way the virtual rider tries to handle the over/under steering.

If this is confirmed it could explain quite a while:

• it could explain why it's hard to slide & countersteer to control it: the virtual rider just can't do that while at the same time trying to zero-out the over/understeer.
• it could explain why we lose the front: if the bike starts to understeer (go wide) the virtual rider try to steer more (kinematically, i.e. turn the bars more left for a left turn), increasing the chances of sliding and losing the front.

If the input was really on the target lean angle, when the rear starts to slide out in a left turn, you could push your steering stick more to the left to lean more: this would eventually push the bars right, realising the countersteering we're looking for in order to control the slide.

Q2: Anybody with any thoughts on that ? Am I completely rambling ?

The relevant math is all in chapter 4 of the Cosslater "Motorcycle Dynamics" book.

MaX.

[teeds]

Max, Are you thinking that Pibosos version of Under and Over steer differ form the common meaning of those terms?

[tseklias]

its like we continue a conversation we had a while ago Max. about separating the axis of bike lean and steering bar steer. i had the feeling that the virtual rider somehow interferes with the overall effect maybe in a way to be managable to ride easier but not realistic.
imo this two axis has to be separated or at least have an option to choose whether you want them combined(with help) or not.
im suspecting this happens with a much higher number of axis in gpb eg: as i previously said you can gradually brake up to 100% while in full lean and not lose the front. what i mean to say is that it may be realistic comparing to other games but still it needs to act like a hardcore simulation to the one riding and not as a visual simulation to the one watching.
i can understand how gpb works in a much deeper level that i show but i cant explain what i suspected cause i find it hard to start talk about "philosophy" in a foreign language(like a caveman trying to express the word love).
also speaking about your discussion here, its right in all points. but i disagree in the countersteer discuss you had. yes technically the bike will countersteer as otherwise you will highside as you said but i disagree that "You" countersteer. the bike's front wheel will point the orbit your following but i disagree that youll countersteer. i think a amateur rider will even hardly feel it.

[TFC]

I asked the same question at the bottom of page 8.. keeping an eye out for a response. If it is the case then maybe there is a possibility of giving us (in mxb & gpb) a setting to disable, maybe a 0 - 100% like the direct lean input.

[tseklias]

I asked the same question at the bottom of page 8.. keeping an eye out for a response. If it is the case then maybe there is a possibility of giving us (in mxb & gpb) a setting to disable, maybe a 0 - 100% like the direct lean input.

thats exactly what i was later thinking. yeah i agree with you a option to choose from a percent will be the best solution as it is now with direct lean it can be with direct steer.
if this whole idea is abandoned(even depending on there is no compatible controller yet) it will be a terrible mistake in my opinion. gpb then will be more close to an arcade than a sim(not to mention what more this "door" can open)

[HornetMaX]

Max, Are you thinking that Pibosos version of Under and Over steer differ form the common meaning of those terms?

I think that what we informally call under/oversteer does not necessarily match the formal definition of it.

The formal definition I know of is the following: steering ratio = effective steering angle over kinematic steering angle = kinematic trajectory radius of curvature over effective  trajectory radius of curvature.

If I ask 10 competent riders over here what is under/oversteering, none of them will come up with something that matches the formal definition, even if they surely grasp the overall meaning of over/understeering.

To think about potential shortcomings of that I need to know exactly how over/understeer are defined in the virtual rider.

I asked the same question at the bottom of page 8.. keeping an eye out for a response. If it is the case then maybe there is a possibility of giving us (in mxb & gpb) a setting to disable, maybe a 0 - 100% like the direct lean input.

Yeah I've seen your post, I think we're saying the same thing . I just need to be sure what Piboso means by under/oversteer and "steer more".

its like we continue a conversation we had a while ago Max. about separating the axis of bike lean and steering bar steer.

But I've already replied on that (my opinion, of course): you can't have independent inputs for lean and steering as the two are not independent in real life. On a real bike you don't have a "lean input". It doesn't make sense.

EDIT: and re-reading all the above, I doubt TheFatController was replying to your suggestion (he was replying to my post, most likely).

MaX.

[tseklias]

But I've already replied on that (my opinion, of course): you can't have independent inputs for lean and steering as the two are not independent in real life. On a real bike you don't have a "lean input". It doesn't make sense.

yes indeed and if i remember clearly we agreed on that(we didnt agree on the way brakes work). so anyway beyond the capacity of the controller the simulation must have an option to enable/disable or better set a value. right? on the physics part youve mentioned i think all the community(at least so far) but you havent told us your opinion about the game though what should be changed.

[HornetMaX]

yes indeed and if i remember clearly we agreed on that(we didnt agree on the way brakes work). so anyway beyond the capacity of the controller the simulation must have an option to enable/disable or better set a value. right?

An option to en/disable what ?!

on the physics part youve mentioned i think all the community(at least so far) but you havent told us your opinion about the game though what should be changed.

I only tried extensively the 990 default bike, and I have mixed feelings. Low speed cornering wobble and high speed weave are still there. Issues on banked corners are still there.
Overall I find beta6 less enjoyable than beta4, but I somehow feel it has a big potential and I like to trust piboso when he says the default bikes need some re-tuning of some params (virtual rider).

MaX.

[BOBR6 84]

From the video above..

I would say once the rear tyre breaks traction and steps out, with lean angle and crazy speed, the bike is already in the perfect counter steering position.

So then you carry the momentum with throttle control, body position, pressure on the footpegs, which all has an influence to the forces on the handlebars.. Wether you realize that part or not.. If you know exactly how to control the bike in that situation, you are more than likely a pro lol.

It all works hand in hand..

Get the bike upright as early as possible to use the momentum and fire it out the corner..

Iv had plenty of big slides on sweeping bends but to say I was in control would be a lie,.. Lol

[BOBR6 84]

How stoner slid the bike was something special though.. Just perfect!

Ask that guy.. 

[HornetMaX]

OK, back to our discussion.

I had a closer look ... let's take this situation (MX pic but that doesn't matter):



Turn is left, rear slides out (to the right), riders countersteer (to the right).

As far as I can see, I have two equally valid definitions of over/under-steering:

• Steering ratio = effective steering angle divided by kinematic steering angle
• Steering ratio = kinematic radius of curvature divided by (effective) radius of curvature (both taken at the rear contact patch)

For small angles (steering angle, front sideslip angle and rear sideslip angle) the two are essentially identical. But for large angles they are not.
In any case, when the steering ratio is > 1 we have over-steering, when < 1 under-steering and when = 1 a neutral behaviour.

Let's take the 1st definition as it is easier to work with: in essence, you have:

• neutral behaviour if rear sideslip = front sideslip
• over-steering if rear sideslip > front sideslip
• under-steering if rear sideslip < front sideslip

In our situation (pic above) the bikes are over-steering then: the front sideslip is somewhere close to zero while the rear is positive and surely bigger.
So to get in this situation you have to allow some over-steering.

I'm tempted to conclude that if the GPB/MXB virtual rider tries to always stay close to a neutral behaviour, then that's why we can't slide in a controlled manner as we should.

It's a bit of a stretch as the 1st definition should be less applicable in case of large (kinematic) steering angles and sideslips. But just a bit, I think the whole reasoning holds for large angles too.

MaX.

[BOBR6 84]

So in beta3/4 when the rear slid out, the virtual rider was trying too hard to save it.. Causing the bike to spring back the opposite way, resulting in a crash.

Pretty good in beta 6c.. But the virtual rider is still not neutral enough..

Extremely un-technical lol but is that sort of what you are saying?

[tseklias]

OK, back to our discussion.... large angles too.

MaX.

i read about 4-5 times i cant understand what your saying either your using the wrong words or like bobr6 im not a technical guy too .
what i think of it is this:
1.under a certain speed eg 40-50kmh you must be able to lean and also be able to steer with the handle bars(not big moves but you still can-the lighter the bike the more angle you can steer)
2.over 50kmh you wont be able to steer the handle bars as they become more and more "heavy"
3.you should be able somehow to set how much the rider will interfere on hes own with all these moves(this is better be expressed in multiple values and not just simply on/off)

we dont know if in the future a controller comes out that has both lean and handle bar steer(not to mention force feedback on both) imo the game as a sim MUST have the option to choose this. i think its the most critical aspect in the whole gpb game thats why i keep coming back on this discussion and may be considered boring.

if things remain the same even if fixed somehow by piboso and the virtual rider reacts the best way and everyone's happy, it will be STRICTLY visual.

[BOBR6 84]

This has fried my brain..

Travelling along at a steady pace, into a left turn, counter steer, (bars right will tip bike in) away you go..

Same again but fast.. Counter steer, tip in.. Rear steps out, sliding..

I think there is a few steps here.. Counter steer to tip in, then counter steer again (more like opposite lock on a car) to catch/control the slide, then steer into the corner..

If you slide the rear on exit (rear wheel steer) I guess you will be steering, not counter steering, until you straighten the bike up again..

??

Very sorry if all that is complete jibberish..

[Stout Johnson]

Interesting discussion. I was about to bring up that topic back with beta4 when I was trying to do controlled power-slides at Brno, but I thought it we had other problems to solve first. Now that the topic is on the table, I might as well join the discussion 

Do we all agree that as the rear "slides out", the rider countersteers (turn the bars right, as this is a left turn) in order to keep the rear slide under control ?

Yes. If the rider did not countersteer, the power surplus which caused the rear sideslip to be greater than the front sideslip would just send the bike turn towards the inside of the corner very quickly and the rear washing out. By countersteering the right amount, the rear slide surplus is countered and results in a steady-state* (in dependance on the rear slip surplus and the steering angle). If the rider does not counter-steer enough, the bike is prone to uncontrollable oversteering and finally the rear washing out. If the rider happens to countersteer too much, the bike would have a tendency to 'stand up' (and if the rear gets too much grip to get into a high-sider, especially when suddenly releasing throttle as this will let the rear tire grip suddenly).

To me it's clear (and it's what I can read on bike physics books) but on the MXB forums others were saying that to keep the rear slide out under control one has to stand up the bike (which would require to turn the bars left). To me doing that would just send you high side.

I think that those who were claiming to have the bike to "stand up", were real life racers and they were in all likelihood referring to the fact, that a powerslide can be much more easily controlled at relative low lean angles. But the overall mechanics should be as stated by you.

The virtual rider tries to calculate if the bike is under or over-steering. In case of under-steer, it steers more, the opposite in case of over-steer.

For over-steering this would read "In case of over-steer, it steers less". As a rider steers left in a left corner in a neutral state (no over-steering) and assumed the bike behaviour would change to over-steering the rider would have to counter-steer (to the right) --> which would be equivalent to steering 'less' (to the left)  -  albeit most riders would describe it as counter-steering to the right).

So, technically the behaviour of the virtual rider is correct. The problem imo, derives from the following:
In real life the rider anticipates the correct amount of counter-steer as soon as he pulls the throttle into a rear-slip > front slip state. As this anticipation is not easy, it has to be learnt over time by the rider, trying to learn controlled slides. So basically, the bike would be held into an instant steady state while in a powerslide by the anticipated counter-steers of the (experienced) rider. If the rider uses more throttle or lean angle while power-steering, he would sub-consciously know how to adjust the counter-steer in order to stay in steady-state (at least expert professional riders). So there would be instant (anticipated) rider adjustments.

But from my studies of powerslide replays in GPB, the virtual rider seems to be always a tad bit too slow (talking probably about hundreds of a second here), as if reacting instead of anticipating. So basically...
1) At the beginning of the powerslide the rider does not countersteer enough, which makes the bike point towards the inside of the corner too much and therefore being in danger of losing the rear
2) In order to counter that, I have learned that I have to reduce the throttle after having initiated the powerslide - otherwise I will lose the rear (as the virtual rider does not countersteer enough -- see 1) for explanation)
3) The reduction of throttle (see 2)) makes the bike stand up or in other terms makes less counter-steering necessary 
4) the reduced steering angle also seems to be applied a bit too late by the virtual rider, which makes the bike have too much counter-steer for a split-second

--> in effect the bike kind of 'osciallates' out of the powerslide
--> the problem of 2) - reduction of throttle applied cannot really be avoided because otherwise you will end up sliding to your butt most of the time
The problem imo lays in the 'reaction time of the virtual rider'; in real life the rider has learned the correlation between 'throttle applied' and 'appropriate counter steering needed' and sub-consciously applies appropriate counter-steering almost instantaneously which makes the bike reach a steady-state powerslide.
(As humans are error-prone, even if highly trained, the relations of 'throttle applied' and 'appropriate counter steering needed' can be musjudged by the riders irl - which can be seen in the the numerous crashes and highsiders of hobby-racers and even pro-racers )

• Imo, there needs to be some sort of anticipation of the virtual rider, meaning there should be a reaction time of ~0s for some cases. From what Piboso stated on the VR-behaviour it seems like the VR always reacts, maybe Piboso calculated some delay/reaction time?
• 
  In order to make the VR not super-humanly perfect, the amount of counter-steer (in dependance on rear sideslip / front sideslip) should have a randomly calculated margin of error. The reaction time on the other hand should always be ~0s as this should represent anticipation of a controlled powerslide by the VR (I assume that the VR should represent a professional motorcycle racer).

* (On a sidenote: Not entirely sure about this, but imo the counter-steer into a steady-state (like in the Stoner Video) would result in a situation where |rear sideslip| = |front sideslip|, but we would still call it 'over-steering', which would contradict your definition MaX. But again, it is also a steady-state - so it is some sort of neutral behaviour, which would be in sync with your definition. )