Well actually, no, that's not what I was implying I was assuming a wheel that seeks and holds a static position. In my example I actually explicitly referenced a wheel that doesn't move at all until it receives a force from the user and then moves the wheel accordingly. My question really was whether this completely unrealistic behaviour would/could be masked to the extent of feeling natural if you updated the position frequently enough. I feel that basic 'broken' functionality is what Spaskis is envisioning, and Natureboy appears to be following the same thought process. And I briefly illustrated the fact that such a system would indeed be completely unworkable at a lower framerate. So on that level I appear to be in complete agreement. But again, the question is what happens when you update very frequently. I used Spaskis' own simple system in order to pose the question, and asked that question. Unfortunately rather than point out what would still be wrong with it he's just reverted to saying it's conceptually wrong. Well I can agree on a step-by-step basis it's illogical, the question is whether an extremely high update rate would reduce the oscillating error (as I described at low frequency) to the point where it will effectively feel 'good'. I'm not insisting on doing anything. I'm just asking some questions. I am familiar with Newton's laws, despite your suggestion I 'missed that chapter'. Natureboy at least tried to spell out what's wrong with what I was thinking rather than just dismiss it out of hand. Let me help: with a static wheel as in my example you have something that doesn't move despite applying a force to it, as I pointed out my example. If you take the route of applying the current system to the wheel as the basis of a force-input system (ie the wheel is centred, so the spring is centred, and at that position provides zero resistance, so you tell the wheel to provide zero resistance to movement) you end up with a wheel that moves completely freely - which makes it very difficult to apply a force, completely breaking force-input. (something Noel's overlooked above, although he was perhaps assuming a more complex implentation of force input) So if you want to simulate a system at low frequency or a system where mass isn't a feature, force-input doesn't work. That doesn't mean force-input is or isn't still broken if you update at high frequency or include inertia as a factor (note I'm not assuming force-input does work properly in either case, just in case you think I'm taking sides again). If, however, you are simulating a system that involves inertia (which any system surely should, since even a centred spring provides inertia) and can do it at high frequency, would force-input still be broken? You look at what's wrong with the system I described at 20Hz, providing very high, then low, then high, then low, ... resistance, and it's easy to imagine you would reduce those problems somewhat if you double the frequency to 40Hz. And again to 80Hz. And so on. If you ran it at 1GHz how would it behave? You can dismiss it because it's conceptually wrong, but I very much doubt you or I know how it would behave in practice. And you can talk about only measuring spring deflection in order to produce a correct result, but we aren't talking a perfect and instant system here. You're calculating spring force from deflection and feeding that back to the wheel, which means the resistance you feel on the wheel right now is based on the position of the wheel at some time in the past. Its position has to be read, sent to the PC, applied to the system, a resultant force sent back, and then that force generated by the motors. You can reduce the initial delay of the 2nd step (sending the position to the PC) by increasing the update rate, but you can't do anything about the rest. So how correct is what you're feeling, really? Again I don't know how it would go if you updated the wheel position at 1GHz, but we do know that at 400Hz the wheel still oscillates if you let go of it. How would a force-input system behave at 400Hz? One final point: Any system will have some error involved if you look closely enough. But if you're not analysing it on a frame-by-frame basis, feeling 'right' is all you need.
The steering torque is not analogous to that of a spring mass. The main component is due to trail, ie the centroid of force on the tire being offset from the steering axis (castor effect). There is also a good damping component due to both sliding friction and hysteresis in the tire. The only spring force would be due mainly to torque loading in the tire sidewall and to a much smaller extent, torsional loading in the tread and steering column. So when driving straight the wheel self centers due to castor effect. When stationary you can load to the wheel up on the tire sidewall and it will return from there. Any oscillations we see that are unnatural in the FFB system I believe to be related to overshoot, where the wheel is driven by its own motors past where it needs to be in the game, then the game tells it to go back by reversing the force direction, and it overshoots again and again. This is the expected result since the wheel is given a force signal from the game without also receiving a strict positional restraint or enough damping (in motor control) for when a driver is not holding onto the wheel. So, problems with the wheel happen when the game needs to dictate where the wheel is like when hitting a curb or when the driver lets go. Balance conditions where force output by the wheel need to be zero are also a small problem this is why many wheels have a weak feeling when driving straight.
Yes feeling good is all we need and with all the short comings FFB has from a real wheel it still feels very good. I think your update rate ideas are very correct, as you increase update rate it only feels better and the car also feels more connected to the road. Go from a g27 to a t500 and this is really what you will see, t500 feels and drives much better to me mainly because of its higher update rate. As far as trailing force errors due to update rate go, I think its also really ok. Remember in the real system there is much hysteresis, far more than 1/400s worth of delay. Tires are also in a very dynamic state during turn in where the slip angle is changing, so even simulating this is in the game not very accurate anyway. There is a lot of fidelity lost in the system but increasing update rate so far also wont help as the relatively cheap wheels will not have the response they need anyway.
Yeah, I know a sprung mass (or just a spring without a mass) is a very simple and irrelevant (for our purposes) model, but it's what Spaskis brought up when talking about force input being conceptually wrong which is why I stuck with it Yep, if you could look at where the wheel is right now and apply a force to it right now you could avoid this oscillation. Given that a delay between input and output is inevitable, you could reduce/eliminate the oscillation by giving the wheel a target position as you say ("strict positional restraint"). It seems to me you could probably do this whether you were using position or force input, providing the wheel obviously supports that sort of parameter?
I just think the force input thing for a steered wheel makes no sense. Obviously as it is you turn the wheel using a force and that movement is encoded as a positional change. But we know that we are effectively turning the wheel through an angle and we arrive at that angle based on where the car goes. When you get oversteer, the amount of countersteer applied really has nothing to do with how the wheel force feels. In a motorcycle you do turn by a force basis. It is more a push on the handle bar to get the bike to lean in and turn, actual rotation of the bars is very small and reaction or the bike is largely related to how you exert force on the bars. In a car the reaction is largely based on whet the steered angle of the wheels is and its such a system that the vehicle nor the wheels care about how much force was exerted to get there, just that it was. "Yep, if you could look at where the wheel is right now and apply a force to it right now you could avoid this oscillation. Given that a delay between input and output is inevitable, you could reduce/eliminate the oscillation by giving the wheel a target position as you say ("strict positional restraint"). It seems to me you could probably do this whether you were using position or force input, providing the wheel obviously supports that sort of parameter? " The bad oscillations don't happen when you hold the wheel beacuse you are strong enough to hold it wherever you want. But, this is a problem really over bumps and curbs. Watch an onboard video of an F2000 or such, look at all the roughness in the wheel. Some of these are corrections but most are due to bumps pushing the wheels and rotating them. You need to allow these rotations to occur or you just loose grip (understerr or snap OS). This is the problem I have in game, when you are on bumpy sections the FFB does not add these large wheel rotations back to me bacause its too weak. If I just shake the wheel on some protions of the track rather than holding smooth, I get extra grip and that ruins the realism.
Interesting It's difficult to follow some of what Leo says, but he probably raised a valid point there. Your grip on the wheel can have a much bigger influence on what the whole system does than it would in real life, because the wheel can't provide as much force as the system itself should generate. Of course we probably don't want/need wheels that can break people's wrists, either! But I suppose that's where his whole 'force input' is coming from - if you make a wheel that is able to go where you dictate, despite (a reasonable amount of) user force trying to hold it steady, you obviously remove the ability for the user to turn the wheel and provide a position input. In that situation you need a way to determine what the user is trying to do, so measuring the force applied to what is effectively a static/solid wheel is probably the only method. It's difficult to evaluate without doing it in practice though, and I'm not convinced it would work well. I'm just also not convinced it wouldn't
Yes it is difficult to understand. I don't know anything about timings and steps on FFB systems, hence nothing about controller for. From a logical POV, yes timings should be very important but i can't imagine the ffb is driven by steps instead of parallel signal processing. As it depends to much on the car, it wouldn't make much sense to know a single opinion by a driver, unless he knows more than a handfull cars. In relating to rapidly swerve and release the wheel from one end position to the next like drift driver do, i don't understand the coherence with self centering on stand and i'm sure you know it can't be the same and i just missunderstood something. As for the force position control others are talking about, i can't understand how anybody will control this. It is not that there was a rail the wheels are on and just the deflection of the tire was the steering direction change which may could be logged to know the range min and max the forces are acting in but still the forces wan't be linear, so the result of the simulation would be accurate as it is already and wan't change something to the better, just complicate things. I don't see a real way to ignore tire dynamics but simulate steering forces with in-output position control.
I could imagine this could be about the inner flank/edge ( dominant contact surface ) to be regulated at least better than over the patch area or center line of the tire. As i mean to know a wheel with camber tends running to the outside. The steering geometrie forces straight run and for this reason, a toe-in is selected in some passenger cars. After the caster this affects also the align forces and resistors and the only solution to master uncontrolled aftermath or oscillation I see in the subdivision of the inside flank/edge line in the longitudinal direction and their difference determines that springs up and aligning.
I have a message for ISI, it's to do with flickering lights and so on at long tracks , like spa 66 If you put clip planes to 0.50, 100000000 you wont get any flickering what so ever! Ty it out guys Cheers Gubba
Roard cars will have toe in at front because they have rubber bushings, they are very compliant and will end up having toe out once the bushings have taken some strain. As for contact patch, yes the centriod of force is behind the vertical center of the wheel for lateral accelerations, this is called pneumatic trail. Mechanical trail is the offset from center of the tire to where the steering axis meets the ground. Add these and you have total trail which accounts for the moment about the steering axis that you feel on the wheel.
Yes and because i already do not know how the software works, i have no idea of how the ffb could improve further. Sure, it's not easy.
May I ask why most of the people who answered this thread do not list what wheel they have in their system specs? Or even list any specs!!??
In my case because there is not a specific field for the wheel and in the example for system specs didn't appear any controller. I'll put it there.
Wow, this thread has turned in to a great collection of detailed info about Force Feedback and vehicle related physics. Thanks to all those that have contributed, i look forward to sitting down with a few cups of tea and try to learn more about these subjects =)
This thread is centred on FFB philosophy, rather than what specific wheels are doing. When you're discussing concepts and having disagreements with people, unfortunately there can very quickly be an elitist attitude of, "well I have this wheel and you only have that one, so you don't know what you're talking about." Of course if I had already listed my specs (including my wheel) I wouldn't remove it because I'd posted in here, but I certainly don't think it needs to be included now because it's not relevant to the discussion.
Also, perfect FFB and simulation accuracy to the point where useful setups could be derived from the sim are reserved for professional sims. What we have in rF2 is impressively good though and in many aspects gives a very real experience. I would drive rF2 over a street car on track any day, and for the price of a proper race car on track day I lean toward rF2 also.
How far can you throw a 1kg stone. Probably more than 20 meters but less than 50. It could be easy to calculate the velocity when it exits your hand and get an estimate of the average acceleration and hence, the average force applied to it. Considering that you can apply that force over that trajectory what would happen if the stone was only 10 grams? If you could apply that same force over that same distance to it, the amount of energy provided would be the same since W=F*d. Converting that into kinetic energy it would increase speed ten times since it depends on the square of speed. It is not difficult to calculate that without considering aerodynamics it would take ten times longer to fall and would get hundred times further than the 1kg stone, somewhere between 2 and 5 km. Nice shot!! The reason why all the above doesn't make any sense is because: - Principle of action and reaction. When to bodies interact, the forces acting are opposite. You cannot talk of applying a certain force when moving a certain body if that that force is not compatible with that body moving at that speed. In the case above your body cannot provide the same force at a much higher velocity since a greater power would be involved. The force applied would be the consequence of the stone accelerating at a certain rate which is what normal FFB does using position input and introducing it into the simulation to calculate not only FFB but car reaction itself as well. If FFB has errors IMO physics will have those same errors. PFB is just impossible from my understanding and I am assuming, from the last paragraph of Leo's paper, that FFB devices do not calculate their own inertia to compensate the output force from the sim which would be the same for all wheels in the market. He also comments about problems with communications with software companies. As I said I woukd appreciate the Point of View from the physics responsible in isi for rf2, to give his opinion and comment about Leo's idea. We have talked too much already. Enviado desde mi GT-I9505 usando Tapatalk 2
I really don't know who you're talking to here. I continued your simple example and showed what it would do at low frequency with both position input and force input, and questioned whether force input would behave better at higher frequencies. If you really think physics principles make it a complete impossibility then surely you can clearly and concisely explain why in the context of that simple situation. At the moment it looks like you're not even bothering to think about it because you want the user to move the wheel before anything else happens. And yes, current (consumer) FFB devices wouldn't do a good job even if force input is feasible. That's got nothing to do with the question of whether it's something that could happen in the future.
I still don't get how anybody will controle output with input to a friction and flex based softbody with various non linear resistance, reaction outputs. I'm with SPASKIS on this because the idea is useless.
