A Message For ISI

I have read several interesting opinions and it has not been a waste for me. It is a fact that rf2 FFB us very good but it can improve I think. I would say that at low speeds or, in general, when the wheel reaction is the lowest there us room for improvement.
I made a trial the other day with the car in the garage. I turned the wheel just a little bit from its center position and released it. It would start oscillating at its natural frequency although i would not call it resonance since the amplification factor was really low with respect to the initial position. I will try with very different cars to see if the frewuency is related to the car or to the steering wheel. I would bet the frequency is device dependent. This would mean IMO that forcefeedback calculations are not taking into account correctly, or at all, who knows the device physical properties. (I threw the question yesterday but nobody answered it yet)
I will also tried to reduce amplified FFB which i think could have an effect either in natural frequency or in amplification factor. I'll let you know.
I will record it and upload it to youtube to better reflect what I have explained. Hopefully, someone can feedback if the frequency is the same for other wheels ir even if the problem disappears at all!

I will also try releasing the wheel in a straight to see how it behaves when a small turning is provided. I will put positive convergence in the front wheels for that, of course so that i can compare with the behaviour of a touring car. The reason the same as before. No action, no reaction, just FFB provoked by inertial forces acting on the wheel.

Enviado desde mi GT-I9505 usando Tapatalk 2

 

This is what David Tucker, an Iracing staffer had to say on the subject.

'Leo's idea is a good one, but it would require special support from the sim's to make it work. Actually Leos idea is not Leos, it is a traditional design in high end haptic systems (fancy FFB). It has its advantages and disadvantages. Its principle advantage is that you get rock solid stability, and the disadvantage is that you have to drive it very fast or you get a really notchy feel.

Internally we are working on a compromise solution that is about half way between Leos idea and the traditional FFB way. But right now it is playing second place to the new tires, so it is not going to make this build. But potentially it will give you that stability that Leo is looking for, while not requiring super fast update loops.

For those who don't know, here is Leos idea. In FFB land you have a sensor that measures the position of your wheel, then code in the sim uses that position to calculate a force that the FFB motors should apply to the wheel. This delayed feedback is unstable, because the force output is always behind the position of the wheel. Latency makes things worse, and the end result is that you are limited on how strong you can make the wheel and still keep it stable (not oscillating down the straights...).

Leos idea flips things over, so your wheel has a force sensor between the rim and motor and gives the sim the force level you are applying to the wheel. Then the sim uses that force to calculate where the wheel should end up and the wheel itself just uses a PID loop to bring the wheel rim to that position. If there is a large delay between force updates the wheel still holds its position, but you end up fighting with the motor and get a on/off/on/off feel. But that is still better than a runaway condition and it is the only reliable way to really make something feel solid. I should point out that underneath it all, in the PID loop, you still go back to an optical encoder and simple force commands. So this is more of an abstraction than anything. But that PID loop can run many times faster than our update rate so it runs much more stable than anything we could implement'

I asked if it would change the feel and he said:


No, not the overall feel, but it will improve the stability, and possibly reduce the latency just a bit. So you will be able to crank the force up as high as you want, or let go of your wheel in a spin, without worrying about wild runaway oscillations. The biggest advantage is that you will be able to support much stronger motors in your wheels without worrying that they will rip themselves to pieces. Our idea involves some high speed interpolation in the wheels firmware, so it should smooth things out a bit, without adding in any latency.

 

This explanation makes a much more sense if his idea concerns stability rather than feel. For sure stability is greatly reduced if the wheel receives only an output force signal. If the game were to send both a force and position target then surely stability could be very high. Position output would be tied to where the vehicles wheels are pointed and be used as a check in the case where driver lets go of the wheel in a turn or on the straight, the position signal would slow acceleration of the wheel or keep it from oscillating completely.

Thanks for clearing up my confusion

 

Steering wheel ffb is overrated for me! real-life drivers doesn't use the steering wheel to feel the car! they use G-forces and their body( proprioceptive inputs) to feel the car and they use the steering wheel only to drive the car!

 

If they applied PID concept for the position input lag or delay removal they would gey a much nicer result than trying to read the force which is mainly composed by the reaction from the car to the track. Since the main source of force feedback is the wheel to track reaction it is stupid in my opinion to force the system to get the force input from the steering wheel to calculate the force output on the steering wheel not realizing that FFB is a reaction force. Seems completely illogical for me. Lets see how the people from iracing get out of this one.

The inestability problem is not related to the position input but to a bad programming of the required output. I will try to demostrate it but I need some time...

To make you see that these guys are wrong think about the fact that the real PID working here in the input is our brain that tries to constantly correct steering calculating and correcting at the time the required force to get the wheels facing the position he wants. Trying to reproduce with standard PID concept the force reactions in our arms that are actually the PID force output correcting poition to get a predictable pattern seems it is going to have a real bad performance. Does it make sense?

Enviado desde mi GT-I9505 usando Tapatalk 2

 

If FFB runs at 400Hz in rF2, and the game knows where the wheel was before, how much force was being output (ok, lag will be an issue there), can you not get an indication of applied force by the current wheel position?

A driver's arms don't change input at 400Hz, right? So if you know you were, a few updates ago, pushing the wheel left at X force, and the wheel has moved Y, the driver is (recently) applying Z force. If you've just pushed the wheel with A force, and the driver will still be applying something close to Z force (because we're running at 400Hz, no way the driver's applied force can change all that much in 0.0075s [3 updates]), you can work out where things will be right now and modify the game's reaction or output force to suit.

Is this part of a normal FFB routine right now? I don't know how well it would work in practice, and presumably you'd have to tweak it to suit different controllers because of their own delays/inertia etc, but the whole oscillation thing seems like it could be reduced by 'seeing' that the driver isn't applying a force (or damping) to the wheel based on the fact you've given it a force and it's moved very quickly.

Or maybe I'm just totally on the wrong track. Or restating something already said. This all gets very confusing.


* Spaskis, it's quite difficult to follow your thinking sometimes because your sentences continue past the point of seeming to make sense or use words in a way that's difficult to put into context.

But things like this:

in a subject that can be difficult to think through, and difficult to comprehend exactly what others are trying to say, can inflame things a bit. It's always worth remembering you might be wrong for reasons you haven't seen yet, so maybe best not to talk about what's 'stupid' (even in your opinion) or talk like you know exactly how things are while others do not.

 

Especially when it is impossible to drive a real car and isolate all the other inputs and interactions with the driver. How can we know what 'just the wheel' actually feels like?

 

Yes lazza you are for sure correct, all forces that the wheel output must come from the game. And it is very confusing because that article makes no sense at all.

FFB is completely open loop. Just as steering forces in a real car are also open loop. Steering forces are related to how the driver turns the wheel but only in a reaction force way. So yes, basing FFB on applied forced input makes no sense as the game needs to see the applied rotation and rate to calculate the forces. For sure the only lack of feel comes from the simulation, assuming the wheel is of very good spec and can actually output what it is told to do.

As for stability, if the wheel does not have a position feedback from the wheel that is where it gets tricky. For instance when you hit a curb the wheel really needs to work based on position to try and get to where the wheel needs to be. Thats where is gets tricky and feel is really lost, and also where stability is lost. position target and force output are really required to get close to a stable system. With those 2 items, it can still be a challenge to gain stability especially in large gain motor control with PID running. Remember when you let go of the wheel and it needs to get back to a position, touque output on the wheel needs to be ZERO, thats why it oscillated when sitting in the pits of going down the straight.

 

If you can anticipate that it's going to happen, and use a known 'lag' value to extrapolate your current driver force vs wheel movement figures, you'd think it should be possible to avoid this oscillation. ISI should be pretty good at prediction and extrapolation because that must be an inherent part of the whole physics system especially with the suspension.

Maybe an extra in-game calibration step would be to have the user let go of the wheel, then set up an oscillation and vary the calculated lag until the wheel stops oscillating. With the physics and FFB running quickly and in a separate thread now you'd think there shouldn't be much variance while driving around the track (FPS shouldn't matter, basically).

But again, it's difficult (for me) to say how feasible this would be in reality; potentially the inherent lag between asking for a force to be applied, and that force actually being put into the wheel, vs the position input information, might rule this out working correctly. And if that's the case what I'm suggesting might already be used (or discounted) and the oscillation is just the best case scenario with current hardware.

 

I could be wrong or I could be right. For me, hearing others saying that Leo had a GOOD idea is as inflaming as me saying that it is stupid since we both are actually discrediting what the other is saying. I may use very direct wording which might seem offensive but I am referring to the idea itself. If I feel an idea is completely senseless I don't see the problem in saying it. I sometimes have stupid ideas and realize later about it which does not mean am stupid but that I just missed something quite obvious when looked from a correct perspective.

I have trying to provide ideas and facts to try to illustrate why tyring to calculate a reaction from action is conceptually incorrect.

Natureboy seems the only one to seem to understand my point and the example he provides of a wheel hitting a curb is an excellent example why reaction forces do not depend on action. When this situation happens, you should feel a sudden reaction which if the driver doesn't realize about it will surprise him and provoke a steering rotation effect.

Another example to try to show that the concept itself is incorrect.
Try to simulate a one dof system as a spring. Its reaction would solely depend on linear deformation of the spring. This is position input. Trying to say that spring force does not depend on that and that it can be achieved in an alternative way by measuring the force applied in the input is like a circular reference error in excel. If a spring could not be simulated in this way imagine a full car...

Force reactions always depend on given position actions and depending if you provide a bigger or smaller force it will make the system go one way or the other. Force input would make sense if the output obtained from it was position instead of force. But trying to implement a system whose PID system tries to give an accurate position beating the driver's PID in his brain is really difficult for not saying impossible. The FFB device PID would need to predict the driver input force which is governed by a complex system which tries to keep a car in a track at high speed and his actions are unpredictable since they are coming from an extremely complex input which is actually the output from the PID in his brain which, as any output from a PID system working at these frequency, would be really difficult to predict. PID systems are good for slow systems where the proportional differential and integral components can be properly accounted. The adjustments of the three constants affecting each of the components is done especifically for every system and depending on those, the PID will make a good or a bad correction. If what is to be corrected is complex they simply lose precision and their correcting effect is bad.

That would be position feedback and would be worse than FFB. It would also lack the principle of repeatability at a given position since the reactions will come from input which is not repeatable since it depends on the force applied.

Remember trying to accurately predict next position of a mechanical system is way easier than to predict next force from a comex system. The PID concept should work to remove the so called delay in the FFB system.

Enviado desde mi GT-I9505 usando Tapatalk 2

 

I suspect the update frequency is something you're overlooking. If you go back to older games there wasn't enough power to run things extremely quickly, like FFB updates.

Take your spring, for example. Let's imagine simulating a simple centreing force on a wheel, first at 20Hz. Wheel starts at centre (balanced, 0 output force) and we rotate it to the right.

Position input: User starts rotating wheel. After 0.0-0.05s the wheel position is sent to the PC, which calculates the resistance at that position and sends it back. It is then applied to the wheel as a force pushing left. User continues rotating wheel. 0.05s after the first update the wheel position is again sent to the PC, and a force returned. That all seems pretty straightforward - moving the wheel from centre felt ok with only the wheel's internal inertia at play, the force updates at 20Hz which quantizes things a bit but it's ok.

Force input: User starts pushing right on the wheel. After 0.0-0.05s the input force is sent to the PC, which calculates the spring's reaction to that force and the wheel's new position and sends it back. The wheel then rotates to that new position. This continues happening every 0.05s; think about it: you start pushing on the wheel and for an instant nothing happens. The wheel is basically solid. Then a split second later it moves, by which time your arms have probably started pushing less because you were trying to apply a measured (not full) force to something that wasn't moving. So then it moves quite rapidly to the calculated target position but you're now applying less force, partly because you were already reducing it and partly because the wheel itself has now moved from where it was when you started pushing it. So the PC receives a lower force, with the 'spring' itself also now starting to inhibit the movement, and the wheel moves quite a bit less than it did before. The sudden slowing presents your moving arms with an obstacle to their movement, which means the wheel now picks up an increased force (your arm inertia basically) and the calculated position now moves farther than the previous update. So you're ending up sort of oscillating around the average force you're looking to apply, which I'm sure would feel sort of weird. As you say Spaskis, the wheel (or PC) can't predict what your arms are going to do and so you end up a pretty unnatural situation - especially the extremely heavy resistance at the start on what should be an almost zero-inertia object.

I'd say position input takes the win there, right? Especially if the force-input wheel is able to move to its new position in less than 1/20th of a second - it would basically jump from position to position, with the input force turning into a horrible mess because you're trying to hold onto it. (realistically I'm sure a manufacturer wouldn't make it move more quickly than the expected updates; it wouldn't make any sense to)

I imagine this is what David Tucker was referring to:

Now, what if the same systems update at 400Hz, or even 1000Hz? I can't see anything but improvement for the position input system, since you just end up with more frequent updating of the wheel force. What about the force input system? Would you notice that increased initial resistance if it lasted 0.0025-0.001s?

If you have things running fast enough that you aren't left actually feeling the residual position, does the force input system end up being worse than position input? How?

 

You seem not to want to understand.
Your big conceptual error is when you say that you use the measured force to calculate reaction. Review third newtons law about action and reaction. You seem to have missed that chapter.

If spring reaction depends exclusively on deformation, that's it. Calculating it from any another different different variable would for sure give a different result which for sure would be wrong.

However, I desist. You insist on reading the force and blah blah blah. Good luck for those trying to square the circle.

Your delay argument reminds me about the story of Achiles being unable to catch the turtle.

Enviado desde mi GT-I9505 usando Tapatalk 2

 

Please this makes no sense. When you turn the wheel on a position basis you are applying a force against the motors, thats why they are there, to replicate the wheel reaction torque.

If you are given the only dynamic force pushed on a spring there is NO WAY that you can calculate the spring deflection without knowing the force-displacement history. Also, no matter how hard or how fast you push on a spring it is always going to give you a force/displacement back dependant on its own properties. Just like turning the wheel. Anyway, to measure the force exerted by a driver, a strain guage would need to be applied to the steering shaft, and guess what, this measured force would be largely proportional to the force output by the motors the only difference would occur when the steering wheel is changing rotational speed.

This topic is quite involved and complex but very simple on a system level, where wheels are rotated on a position basis and to do this the user must apply force dependant on what the wheels need to turn.

As a race engineer, I have had questions from drivers fathers about setup decisions and they are usually based on ideas that make no sense. It is completely commom that a persons understanding of an 800lb spring is that it provides 800lb force - that's it, no more or less. Then based on this amazing mechanical knowledge, they like to make comments about why your setup is not working and forget that their kid brakes too early, turns in too harshly, drags the brake way too long, ohh yea then gets back to throttle on/off 5 or 6 times too early.

Hehe, I see why so many people vent on this site, can be fun.

 

I do have a suspision relating to the physics of the game and overall weakness of the wheel. To me it seems when I get a bit out of shape, especially on bumpy sections of the track, it really helps to impart a very fake shaking of the wheel on my own. This usually helps to smooth things out and regain grip.

This, I have always thought was due to my wheel not being strong enough to actually relay those forces back to me and I was then - by being smooth - forcing the wheels to scrub over the bumps. I would love if the wheel could make this more authentic because it kills the experience to just shake the wheel and be my own replicator of FFB.

 

Hi all,

i see a huge discussion here about this topic and as most topics both parts are right and wrong. Let's face the fact are the current relation between wheel and ffb real? NO NO and NO. Does it help to gather information about the car since the lack of feedback from the body like in a real car ? YES ABSOLUTELY. So at the same time the unrealistic ffb helps to driver better so i agree to those who say that this ffb path should be left as it is and even improved but at the same time i guess it is time to move on to a big step that provide real feedback at cost of feeling body stuff into the wheel.
These days we have a lot of things (cheaper of expensive) that helps to get feedback not only from wheel but also from the body.
So for me it is time to start researching on how to increase input simulation and let the user to decide whether to use the old system or the new system.

I'll be honest, i lost almost all interest in racing game last 6 months because i feel that they all lack of something that previous games had (i feel that time has passed but racing games has not evolved as much as i imagined) and specially none of them are making a huge step forward against the concurrency. I mean under all point of view racing environment (no modern game have), still some old stuff from the past when talking about realism, etc...

 

My knowledge on software and simulation is zero, so this is just what i guess but calculating a reaction force based on non linear interaction with a friction surface and tonns of variables can´t work. Steering wheel reactions shouldn't and can't be based on input forces. The outcome must be generated by interaction of the tire and surface physically. The Steering input force by the driver is just a result of interaction from and varies under load and speed. How anybody will calculate the accurate reaction of a tire with diff loads or how will anybody know all the data to recalculate the reaction force just based on steering force from all the diff tires and cars in a specific situation ? Impossible and nonsense. And i'm not on tire deformation, pre load, unload, times, speeds, inertia etc.

 

This makes total sense. In Lazza's example the wheel was centered with no forces so the motor(s) would be idle. So when you first turn the wheel you are NOT applying force against a motor UNTIL the system refreshes with the updated position and at that time the motors will kick in and apply force. This is why it is critical to have a very high refresh rate as Lazza pointed out very clearly.

 

Agree there is room for improvements.

 

I have been putting some time into this and made a small example in excel.

I simulated the behaviour of a mass suspended to a weightless spring. At the other end ot the spring a displacement input was provided.
Afterwards I solved the differential equation for a constant velocity input which is one of the few cases that can be mathematically solved to get an exact solution to the equation. (When I have time I will simulate other inputs as sinusoidal ones).This case has a quite evident and intuitive solution besides...

After that I simulated the system with different time step sizes to see how it behaved.

For the simulation I extrapolated position and velocity from the previous step according to traditional kinematic rules. For the new acceleration calculation I used the differential equation considering the other as well. These provided nice results for small time steps but diverged resulting in the amplification of the oscillating component of the solution.

After comparing the magnitude of speed position and acceleration of exact and simulated results I show that the problem was caused due to the poor extrapolation of speed according to the formula v1=v0+a0(t1-t0). So, I decided to generate velocity as the result of the mean value from a1 and a0. Since no damping was present I didn't need v1 for a1 calculation. With this extrapolation method the results matched "perfectly" even if a big time step was used.

For this type of system it is clear with the resukts that actual FFB concept is proven perfectly accurate. I will introduce another mass in the system to make it more similar to a system and avoid instant accelerations in the input which are quite unreal. In that way I will also be able to compare how FFB vs PFB performs.

However what I would like to point out is that in terms of realistic force output I have found more problems in the internal system of a sim trying to reproduce reality due to the step timing that estimates next step based on actual one.

Does anyone know how this calculation of the "next step" is done? I would think in fast inputs and acceleration changes this could cause a bad simulation and hence a bad FFB. However it is clear from my results that the way to extrapolate next step could have an enormous impact. Hopefully, this field is not fully exploited and we could have a better sim and FFB without changing our hardware and software.

When I finish my "studies" I will share them. Right now it is difficult to understand the way I simulate things in excel without proper explanations.

Enviado desde mi GT-I9505 usando Tapatalk 2

 

From the practical testing point of view I will do some more tests apart from the ones that I commented regarding the vibration frequency when stopped in garage and behaviour in straight line.

I will make an object to include it in one track of my own so that I can put the car in that way that the wheels dont touch the ground. That way I will be able to test several things like how is the gyroscopic effect od the wheels when turning at high speed isolated from the track to the wheel force. I will use the clio since it is one of the few forward traction vehicles available.
I will also test at zero speed to see what happens when just simulating the steeringand the wheels and the masses and internal reactions associated to them. It would be great that any real racer could tell me what should happen in this situation without power steering. I am not sure about how much friction or damping should be expected. In other words, I am not sure if from one end position you can rapidly swerve and release the wheel so that it goes to the opposite end like it is seen in drifting. I would say it would stop first but I might be influenced by my experience with powersteering...


Enviado desde mi GT-I9505 usando Tapatalk 2