I've been thinking a bit about the tankslapper issues in GPB that occur regardless of how well a bike's physics data is tuned.
When the bike is kept at maximum acceleration with barely any weight on the front, the virtual rider continues to try to correct the steering angle (back to 0), resulting in a tankslapper.
In reality, riders loosen up on the handlebar under acceleration, so that the front wheel is allowed to stay slightly misaligned until it catches traction again by itself.
https://www.youtube.com/watch?v=lX_1cK5Q9tQ&t=28
This "controlled misalignment" under acceleration is not possible in GPB at the moment because the virtual rider is obssessed with getting back to the "correct" steering angle.
So my question to PiBoSo is if it is possible to implement a little subroutine that goes something like this:
if fork travel < X & steering angle > Y, set VR steering forces to 0
The parameters X and Y (Y being the critical one) would be defined in the bike CFG.I suspect that this will also improve powerslides because once the bike starts sliding, it will be steered purely by the rear wheel (throttle) without any interfering forces.
I agree. Piboso has to do something about it.
Having just looked at the video.... I remember reading somewhere that the tyre majick formula simulation only kicks in at approx 70MPH if I'm not mistaken? Up till that speed the tyres do not actual simulate unless Piboso has added a simulation to fill that speed gap(0-70mph); could this also have something to do with or be related to the reaction we see in your video Vin?
nah
i reached 70mph at the 5 second mark.
Quote from: Hawk on November 22, 2017, 08:38:09 PM
Having just looked at the video.... I remember reading somewhere that the tyre majick formula simulation only kicks in at approx 70MPH if I'm not mistaken? Up till that speed the tyres do not actual simulate unless Piboso has added a simulation to fill that speed gap(0-70mph);
Can't remember reading anything like this (neither here in forum nor in books). Sounds very strange to me.
@Vin: it's not that simple, I doubt it would work.
Quote from: HornetMaX on November 23, 2017, 10:55:18 PM@Vin: it's not that simple, I doubt it would work.
What makes you think that?
Quote from: vini97 on November 23, 2017, 11:14:23 PM
Quote from: HornetMaX on November 23, 2017, 10:55:18 PM@Vin: it's not that simple, I doubt it would work.
What makes you think that?
Because taming an unstable mode of a non-linear system is tricky stuff on which people have written millions of research pages.
If it was as easy as adding some sort of deadzone ...
It's not even sure the tankslapper is actually made worse by the virtual rider. Tankslappers do happen on real bikes, with no virtual rider: when they happen, there's little the (real) rider can do except letting it calm down by itself (hopefully).
So you suspect that the tankslappers are caused by the bike itself instead of the virtual rider. If that is the case, then of course the situation is much more complicated.
But we don't know whether or not that is the case. There is only one way to find out and that is taking the virtual rider out of the equation in those critical situations.
And regardless of whether it will fix the problem or not, fact is that in reality, (good) riders don't steer the bike with the handlebar under heavy acceleration, so the virtual rider should not either.
Anyway, here is why I think the virtual rider is in fact the sole cause:
1 Tankslappers seem much less common when using Direct Steer, in fact I have yet to see a single one.
2 A misaligned front wheel by itself does not create tankslappers in GP Bikes as long as there is no abrupt weight transfer to it, which is realistic. I have no replay to demonstrate that but I can assure you that in those rare situations where the VR keeps the wheel misaligned for a bit, it always skipped for a meters and smoothly realigned itself upon coming into contact with the track again.
3 If you get the timing for the lean input absolutely perfect (at direct lean 100%), so that the virtual rider is exerting close to zero steering forces (because bike lean = input/target lean), you can avoid the tankslappers.
I have to agree with everything Vin is stating here. I also suspect the VR to be the main cause. If one watches a replay of normal riding (no tankslappers) in GPB from the front wheel/suspension cam, it can be seen that even on very smooth tracks the VR often makes many hasty and abrupt steering corrections, whereas if you watch real life footage, the front wheel is always being turned very very smooth. So in general I think it is safe to say that the VR in GPB is always "overshooting" in his reactions. Whereas in real life, keeping the front wheel rather constant and only applying slow and smooth changes in most cases levels out most disturbances to the front.
Speaking of that. I have always wonderes what the reaction time of the VR is. My assumption would be that it is 0.0s which obviously would be unrealistic. Maybe it would already help if the VR would have a human-like reaction time. That might help levelling out the disturbances with the suspension and the VR might not be overshooting. That a input-less bike is rather stable can always be seen if the rider is ejected and the bike goes on and on and on in GPB ; ) that might be a good indicator of how the bike would behave if the VR was taken out of the equation.
Quote from: vini97 on November 23, 2017, 11:47:49 PM
2 A misaligned front wheel by itself does not create tankslappers in GP Bikes as long as there is no abrupt weight transfer to it, which is realistic. I have no replay to demonstrate that but I can assure you that in those rare situations where the VR keeps the wheel misaligned for a bit, it always skipped for a meters and smoothly realigned itself upon coming into contact with the track again.
True. I spent a lot of time with the Supermoto in MXB lately and there it can be seen that if you wheely slightly the misaligned front works pretty realistically and does not cause any disturbances to the front. It might be connected to the stability helper in MXB though?
Quote from: vini97 on November 23, 2017, 11:47:49 PM
1 Tankslappers seem much less common when using Direct Steer, in fact I have yet to see a single one.
2 A misaligned front wheel by itself does not create tankslappers in GP Bikes as long as there is no abrupt weight transfer to it, which is realistic. I have no replay to demonstrate that but I can assure you that in those rare situations where the VR keeps the wheel misaligned for a bit, it always skipped for a meters and smoothly realigned itself upon coming into contact with the track again.
3 If you get the timing for the lean input absolutely perfect (at direct lean 100%), so that the virtual rider is exerting close to zero steering forces (because bike lean = input/target lean), you can avoid the tankslappers.
It could also be that with direct steer one is not pushing as hard as without.
Quote from: Stout Johnson on November 28, 2017, 08:26:21 AM
I have always wonderes what the reaction time of the VR is. My assumption would be that it is 0.0s which obviously would be unrealistic. Maybe it would already help if the VR would have a human-like reaction time. That might help levelling out the disturbances with the suspension and the VR might not be overshooting.
I remember in the past asking PiBoSo if the basic PID in the VR has some sort of roll off implemented (can't see this in the parameters) as that could indeed help.
Notice that it may not be as simple as "just put a lowpass" and also that it's not granted it would help with tankslappers (but may help in cases where the VR is over-correcting too quickly, like when you lose the front and the VR locks the steering trying to catch up, making things worse).
One point however (vin's point #3): assuming some filtering could make it impossible to have a tankslapper, even if you yank your joypad to pickup the bike too quickly on too much throttle, would that be good for GPB ?
Quote from: HornetMaX on November 28, 2017, 09:04:03 AMQuote from: Stout Johnson on November 28, 2017, 08:26:21 AM
I have always wonderes what the reaction time of the VR is. My assumption would be that it is 0.0s which obviously would be unrealistic. Maybe it would already help if the VR would have a human-like reaction time. That might help levelling out the disturbances with the suspension and the VR might not be overshooting.
I remember in the past asking PiBoSo if the basic PID in the VR has some sort of roll off implemented (can't see this in the parameters) as that could indeed help.
Notice that it may not be as simple as "just put a lowpass" and also that it's not granted it would help with tankslappers (but may help in cases where the VR is over-correcting too quickly, like when you lose the front and the VR locks the steering trying to catch up, making things worse).
Maybe that would also help with the issue but IMO this is a much more complicated and intruding way of fixing the problem because it changes how the VR behaves in general.
The two conditions that I have specified would ensure that the VR only behaves differently in the situation of heavy acceleration with the front wheel starting to "loose alignment". In this situation every normal rider would stop putting pressure on the handlebar and let the bike do its thing. This is exactly what the VR should do. No roll-off, filtering or any kind of advanced modification to the VR code, simply 100% deactivation until the front catches traction again.
If this does not improve the issue,
then you can start getting into more advanced modifications to the VR.
Quote from: HornetMaX on November 28, 2017, 09:04:03 AMOne point however (vin's point #3): assuming some filtering could make it impossible to have a tankslapper, even if you yank your joypad to pickup the bike too quickly on too much throttle, would that be good for GPB ?
It will most likely not make it impossible because if you put too much weight on the front wheel while it's misaligned, you will still crash. You will still have to be smooth on the throttle to achieve steady acceleration.
And even if tankslappers (or more specifically: too aggressive steering inputs leading to a crash) became imposible, it would still be better than the status-quo. Currently, the smoother you are on the throttle, the more prone you are to crashing / getting a tankslapper which is absolutely stupid.
Quote from: vini97 on November 28, 2017, 10:26:52 AM
Quote from: HornetMaX on November 28, 2017, 09:04:03 AMQuote from: Stout Johnson on November 28, 2017, 08:26:21 AM
I have always wonderes what the reaction time of the VR is. My assumption would be that it is 0.0s which obviously would be unrealistic. Maybe it would already help if the VR would have a human-like reaction time. That might help levelling out the disturbances with the suspension and the VR might not be overshooting.
I remember in the past asking PiBoSo if the basic PID in the VR has some sort of roll off implemented (can't see this in the parameters) as that could indeed help.
Notice that it may not be as simple as "just put a lowpass" and also that it's not granted it would help with tankslappers (but may help in cases where the VR is over-correcting too quickly, like when you lose the front and the VR locks the steering trying to catch up, making things worse).
Maybe that would also help with the issue but IMO this is a much more complicated and intruding way of fixing the problem because it changes how the VR behaves in general.
The two conditions that I have specified would ensure that the VR only behaves differently in the situation of heavy acceleration with the front wheel starting to "loose alignment". In this situation every normal rider would stop putting pressure on the handlebar and let the bike do its thing. This is exactly what the VR should do. No roll-off, filtering or any kind of advanced modification to the VR code, simply 100% deactivation until the front catches traction again.
If this does not improve the issue, then you can start getting into more advanced modifications to the VR.
We have two different ways of seeing the problem. You only see a problem with the tankslapper, I see a general behaviour by the VR which might cause the tankslappers in the extreme but also causes the otherwise unrealistic front wheel behaviour I described.
Quote from: Stout Johnson on November 28, 2017, 08:26:21 AM
If one watches a replay of normal riding (no tankslappers) in GPB from the front wheel/suspension cam, it can be seen that even on very smooth tracks the VR often makes many hasty and abrupt steering corrections, whereas if you watch real life footage, the front wheel is always being turned very very smooth. So in general I think it is safe to say that the VR in GPB is always "overshooting" in his reactions. Whereas in real life, keeping the front wheel rather constant and only applying slow and smooth changes in most cases levels out most disturbances to the front.
Consequently I think it would be preferable to tune the VR to more realistic behaviour in general and by that most likely also eliminate the tankslappers caused by the VR, as compared to adding code which would then solve a problem which otherwise would not exist anymore.
Quote from: Stout Johnson on November 28, 2017, 11:28:52 AMWe have two different ways of seeing the problem. You only see a problem with the tankslapper, I see a general behaviour by the VR which might cause the tankslappers in the extreme but also causes the otherwise unrealistic front wheel behaviour I described.
Then please create a seperate thread with video examples of what you mean specifically.
I think you will agree with me that tankslappers (and powerslides) are by far the most unrealistic part of the VR (or GPB in general) at the moment. More importantly though, there might be an easy fix to this.
Quote from: Stout Johnson on November 28, 2017, 11:28:52 AMConsequently I think it would be preferable to tune the VR to more realistic behaviour in general and by that most likely also eliminate the tankslappers caused by the VR, as compared to adding code which would then solve a problem which otherwise would not exist anymore.
My proposal would be one (very big) step towards a more realistic VR in general. Of course there is always more to be tweaked here and there but that has much lower priority.
These more in-depth modifications will also yield much less reward for the work time invested by PiBoSo.
Quote from: vini97 on November 28, 2017, 11:45:02 AM
I think you will agree with me that tankslappers (and powerslides) are by far the most unrealistic part of the VR (or GPB in general) at the moment. More importantly though, there might be an easy fix to this.
Totally agree, the known understeering problem is on that list too.
Quote from: vini97 on November 28, 2017, 11:45:02 AM
My proposal would be one (very big) step towards a more realistic VR in general. Of course there is always more to be tweaked here and there but that has much lower priority.
These more in-depth modifications will also yield much less reward for the work time invested by PiBoSo.
I totally agree. I think you have misunderstood my proposal (or I have not been clear enough). My proposal was to add a more realistic reaction time and some sort of filtering to make reactions more smooth. Would have been very easy to implement too. ; )
Anyhow, would love to hear Piboso's take on your propsal here. Would be nice if he would allow some of his thoughts to transpire.
Quote from: Stout Johnson on November 28, 2017, 12:45:44 PMI think you have misunderstood my proposal (or I have not been clear enough). My proposal was to add a more realistic reaction time and some sort of filtering to make reactions more smooth. Would have been very easy to implement too. ; )
I understand and it should be done
eventually.
I'm just not sure longer reaction times would help with the tankslapper issue. And introducing a filter that's always active might result in us having to relearn how to control the bike. So then you have to think about what a good compromise would be, etc. so not so straightforward. Plus I think lowering the Direct Lean value is already doing what you propose (filtering steering inputs and taming the VR forces in general).
My point is that they should not only be tamed or filtered but removed completely for those critical situations where tankslappers can occur because that is what real (pro) riders do aswell (regardless of the Direct Lean setting).
https://www.youtube.com/v/Pord6ka0MSs
The wobbles seem to be related in part by the aw.
Every time the front wheel tries to get off the ground the aw acts by cutting the throttle and when the wheel returns to the ground the throttle is opened again creating a resonance that gas open / cut producing a wobble.
EM low with less power makes it harder to lift the front wheel so the aw almost does not act and the resonance is not created.
That is why the less powerful bikes don't have wobbles.
With AW at 0 it is unlikely to find wobbles. The question is that most people prefer that the AW does the work. Currently the ECU in Gp Bikes is very rudimentary and sometimes problematic. I hope that Piboso has a solution.
That's definitely not the case, Manu.
The frequency of those wobbles is far too high to be caused by the AW (which has a pretty low sampling rate).
If you have good throttle control and don't use AW, you can keep the bike consistently much closer to maximum acceleration. That way you are much more prone to tankslappers. With AW you cannot keep the front hovering above/on the ground for long because it abruptly cuts a lot of power.
Both in my and in Ryanoh4's vid, AW and TC is set to 0. But the Direct Lean value of 100% may be a contributing factor, which is not surprising since it means more aggressive virtual rider (steering forces).
Not saying you're wrong and Manu right, but :
Quote from: vini97 on December 05, 2017, 02:25:33 PM
The frequency of those wobbles is far too high to be caused by the AW (which has a pretty low sampling rate).
How do you know that ? And low compared to what ?
Give the MotoGP bikes full throttle with AW and listen to the engine. The frequency of "throttle change" is much lower than the frequency at which the handlebar oscillates during tankslappers.
But regardless, that discussion belongs here (http://forum.piboso.com/index.php?topic=5512.0). AW/TC being deactivated in both videos means that it's irrelevant to this discussion right here.
Quote from: vini97 on December 05, 2017, 03:10:48 PM
Give the MotoGP bikes full throttle with AW and listen to the engine. The frequency of "throttle change" is much lower than the frequency at which the handlebar oscillates during tankslappers.
But regardless, that discussion belongs here (http://forum.piboso.com/index.php?topic=5512.0). AW/TC being deactivated in both videos means that it's irrelevant to this discussion right here.
Hmm, I will have a look. As far as I can remember the two freqs were not so different.
It's a pity we can't see this in the telemetry (we can easily see the tankslapper freq but not the throttle cutting due to the AW, we only have the rider's throttle pos).
in the debug mode you can see the right green bar corresponding to the throttle.
Quote from: HornetMaX on December 05, 2017, 04:40:11 PM
Quote from: vini97 on December 05, 2017, 03:10:48 PM
Give the MotoGP bikes full throttle with AW and listen to the engine. The frequency of "throttle change" is much lower than the frequency at which the handlebar oscillates during tankslappers.
But regardless, that discussion belongs here (http://forum.piboso.com/index.php?topic=5512.0). AW/TC being deactivated in both videos means that it's irrelevant to this discussion right here.
Hmm, I will have a look. As far as I can remember the two freqs were not so different.
It's a pity we can't see this in the telemetry (we can easily see the tankslapper freq but not the throttle cutting due to the AW, we only have the rider's throttle pos).
Hmmm did a (too) quick try. Manu's Honda motogp on victoria, TC at zero, AW at 3 (direct lean 100%), default setup.
1. I seem to have no tankslappers (but may need to try more / push more).
2. When AW kicks in, the ON-OFF freq is surely faster than the freq of a tankslapper so at least in principle, the AW could make things worse (mind, it's not a proof it does).
Any track/bike combo that makes tankslappers very obvious for you?
I want to dig this thread up because while tankslappers have been greatly improved (albeit partially due to better bike data tuning), there is still something fundamentally off about the virtual rider in my eyes.
More specifcally, the constant presence of a steering force that keeps the front centered even when it makes zero sense (coming out of corners with no weight on the front).
I still believe that this is the reason you have to use unrealistic throttle inputs to maintain a stable powerslide and it may also be related to the bad low speed stability.
The reason I think this is because smooth rear wheel steering is certainly possible and I use it in every corner to some degree in order to tighten up the exit but if you want to maintain a powerslide with a significantly greater steering angle, you have to agressively upset the bike with the throttle because the virtual rider is working against the slide, trying to get the front wheel in-line again.
Quote from: Vini on November 22, 2017, 05:50:45 PMIn reality, riders loosen up on the handlebar under acceleration, so that the front wheel is allowed to stay slightly misaligned until it catches traction again by itself.
https://www.youtube.com/watch?v=lX_1cK5Q9tQ&t=28 (https://www.youtube.com/watch?v=lX_1cK5Q9tQ&t=28)
This "controlled misalignment" under acceleration is not possible in GPB at the moment because the virtual rider is obssessed with getting back to the "correct" steering angle.
So my question to PiBoSo is if it is possible to implement a little subroutine that goes something like this:
if fork travel < X & steering angle > Y, set VR steering forces to 0
The parameters X and Y (Y being the critical one) would be defined in the bike CFG.
I think this relatively simple subroutine would be a worth a try in a future release.
Bump
BUMP
maybe one day
Quote from: Vini on January 08, 2021, 10:03:35 AMmaybe one day
Insert 'its been 84 years meme' here
[edit] I should had read Vini's post more carefully as he's talking about the powerslide. I could only see the "fixing tankslappers" part in the thread title and threw me off. sorry [/edit]
Quote from: Vini on April 19, 2019, 12:08:00 PMI think this relatively simple subroutine would be a worth a try in a future release.
Just my 2 cents. I think this is an oversimplified approach that is bound to cause more problems in the long run, and perhaps this is why it hasn't received any attention by Piboso.
My approach would be to first let the virtual rider know when a vibrational mode of the bike is excited in the first place and then have him take extra action until it decays sufficiently. (like letting go of the handlebars completely lol)
If we want to get technical, I would use the steering angle values in a short time interval to detect if there is a prominent sinus component in the range of 5-10Hz where wobble frequently occurs. This can be achieved with a fourier series of the sequence of steering angle values, and reading the magnitude of the coefficient in the respective frequency bin. This would indicate directly how strong the vibration is.
I suppose the physics engine runs at least at 60Hz, so this should be doable.
This subroutine would act as a last resort when all other virtual rider control loops have failed.
Of course, those control loops also need to be finetuned further to avoid tankslappers developing in the first place but that doesn't seem to be a straightforward task.
My main concern here is actually powerslide and wheelie behaviour because what the virtual rider is doing in these situatios is so obviously wrong. Corner exits are one of the only places where there is an obvious visual mismatch between GPB and reality (front wheel always staying in-line).
Alternatively, if this subroutine cannot easily/smoothly be integrated into the current virtual rider code, you could introduce a "temporary virtual rider deactivation button" as a debug option to at least allow modders to analyze handling issues better.