... because? Where does the idea break down? If you're that convinced it must be easy to pinpoint, right?
Because its in the post above and already quested before, nobody can explain easly how to controle tire outputs.
I think I've missed something. I was talking earlier about a simple centred spring, so the user has to initiate the force which in turn provides a new wheel position back from the system. Let's look at the opposite situation. You're driving along, wheel's straight or not, doesn't really matter. Things are quite static. Then you hit another car, or a kerb, or a solid object, with one of your tyres. So your system says, after calculating the geometry etc, that the steering wheel will be pushed to the left with X force. I think we can all agree that right now the game calculates this force, does some scaling as needed for the current controller, and the controller generates that force to the left. This is easy, it pushes, we react either immediately or more likely with a bit of delay, that moves the wheel a bit, the system recalculates. All good. With Leo's idea he's saying force in -> position out. So when the system calculates the X force due to external influences, I think what's breaking down for you speed1 is that you need to try and work out a new position for the wheel. I'm taking a guess here because you didn't really spell it out. It seems you could come up with a rudimentary calculation that just converts the force to a position offset from the current one, though really you could always bring it all back so it's relative to centre. There exists a condition where the wheel is sitting at centre and has no forces acting on it; all the differences between the current condition and that neutral one are added together and you end up with a final position. So then obviously if you're left of that the wheel will move to the right, and vice versa. Again it's the speed that matters. If your wheel moves very quickly but this new position is only set slowly (10-20Hz) it'll get there, by force, before the next update. This would feel terrible and completely butcher any sort of force you might want to read back in to feed to the system. If, instead, the system is updating at say 1000Hz and then the wheel itself, after receiving a new target position, moves step by step toward it (multiple times per system update) while also reading in the current force the user is applying, then every 0.001s the game will receive the current user force and be able to apply that to its calculations. So you hit that huge kerb or whatever, the wheel ultimately wants to move 90° left because of the forces being put into the system, but very quickly the force being applied by the user (first just because of their grip and arm weight, and then due to their reaction) is also applied to the system and the wheel movement will be reduced (you're calculating the balance between the whole geometry and the forces acting on the tyre, and the force being applied to the steering wheel). Again, this all happens very quickly. I'm just asking the question: why wouldn't this work? "Because it doesn't make sense" doesn't work for me - I'm describing how it seems it might work, so what's wrong with it?
Let's think.... now there is still the issue of a friction based body i see, not just the flexibility of the tire influenced by load, drag, temp etc. I'm not getting how to controle the friction state accurat to the deflection in-outputs of the flex boady to generate accurate resistance and force in time. There will be a offset varying non linear between the forces generated on the surface/patch and tire body itself.
Don't know. It is not just about mechanical and kinematics positioning, it's about a dynamic body (flexing tire) in contact with a static friction surface generating non linear forces. Don't get how to position the wheel accuratly with the right forces in time.
I find it is extremely interesting and I think it's good to worry but for whom, who wants to know ? I might be really don't want pointless, to teach or to learn. The factor time is too precious and my honest opinion is the idea of the Lord is useless.
The reason why position output vs force input wouldn't work (always IMO) is because the system requires position input as well for determining the behaviour of the car. When it is stated that the system would calculate position with repect ot the input force it confuses me. In the spring example I gave, it was quite obvious that the elastic reaction force would depend on the deformation and that's it. Trying to read force when that force depends on deformation is not possible. You cannot apply a contact force if the reaction of the system is not compatible with that force. The stone example tried to make it more evident that the concept of applying a force without considering the resistive forces (due to acceleration, deformation...) is not possible because that force must be in agreement with the position vs time. I am sorry that I cannot explain it better or figure out more examples to make it evident. I repeat: In the example of the spring I could demonstrate that simulated and theoretical FFB would match. For a given position input there was a determinate reaction force. You just cannot ignore wheel position since the wheel is where it is and that's a fact. Calculating next position wouldn't make any sense since if forces are calculated in the right way the wheel would behave accordingly and there ia no need to calculate it. Just let it happen and it will go where it should. Enviado desde mi GT-I9505 usando Tapatalk 2
Spaskis, using force input doesn't mean you don't know where the wheel is; you're setting that yourself. The user applies a force to it and you make/let it move according to your system. You're saying let someone move the spring and then make it generate a force; I'm saying the spring starts in a known position (centre) so when the user applies a force I can calculate how the spring will move. There doesn't appear to be all that much of a difference at the user's end.
You cannot apply a force to a theoretical weightless spring. You induce a movement and the springs returns a force proportional to its deformation. You cannot calculate movement from force when something has no mass, but for sure you can simulate it and you would need FFB based on position input. Is like trying to apply a force on nothing. Just doesnt make sense. If there is no such a reaction there cannot be such action. I think that you dont understand that force is a reaction between two bodies and not something that you can decide what to apply. Enviado desde mi GT-I9505 usando Tapatalk 2
I know! I know! So you work out the wheel has to move to infinity, right? Because your static wheel has picked up a force of whatever from the user. So you start moving at a maximum defined speed toward your movement limit. Then a small fraction of a second later you still have a force being applied by the user, plus some spring deflection, and you calculate a new position based on them. Remembering also a real spring isn't frictionless, so not having a mass attached to it doesn't make it move completely freely. Surely you can see if you did this at extreme rates (I did mention 1GHz earlier!) it might start to feel correct, because even the 'pause' at the start where you start pushing on a wheel that won't move will become so short you won't notice it. I don't know what sort of rate you'd need to cross from 'obviously fake' to 'feels pretty much right'.
I think that the real problem that happens when trying to provide a "realistic FFB" resides in the definition of realistic FFB itself. What is realistic forcefeedback? A) when I turn the wheel I want to feel the same reaction as what a real driver would in the real car. B) when I release the wheel I want that the wheel behaves as in a real car would do if I did so. I will analyze both in terms of SIMULATION. In the first case the main wheel positioning input is the driver since he controls the wheel and has sufficient control of it to provide a determinate position input that drives the simulation. The second one is an inertial system where the mass of the FFB device wheel mass drives the input according to the accelerations provided by FFB. This is completely different in terms of simulation. The first one can be easily handled by actual systems. The second one requires a very precise simulation of OUR FFB DEVICE WHEEL to be able to compensate its inertial effects and introduce a compensation to behave as something that they are not. This could be called a position output but it would not be based on any type if force input sensing but on a correct simulation of the real wheel to be able to calculate the required force to provide the movement that the simulated wheel would have, to a real wheel with different mass and elastoc properties. This is in line with several ideas that Leo suggests but IMO he misses to get to see what should be done to correct it. To put an analogy is like when solving the differential equation of a typical mass, spring and damper system. When no external forces are applied the system behaves according its natural frequency. However when an external input is provided, the system behaves radically different and the solution of the equation greatly depends on this input with a smaller component of the natural movement which is always part of the solution since it equals to zero in the differential equation and can always be added to any particular solution of the forced movement differential equation and is used to calculate the different constants that affect each of the components of the "general solution" of the equation to match initial conditions. Simulation is an important part of my job since I am the R&D responsible for process improvement in a 1500 people company in case somebody cares. Enviado desde mi GT-I9505 usando Tapatalk 2
Sorry, but: it is not about GHz. It is something conceptual. Enviado desde mi GT-I9505 usando Tapatalk 2
So you can't or won't point out what's wrong with my example because you don't agree with the concept? Problem is, as Leo said, you can completely change the nature of the physical wheel by how tight you hold it. The state isn't binary; you're not either holding it or not, you're either not holding it or holding it with an unknown tension (maybe the wrong word, but I hope you get what I mean). Even if you only consider those two states, how do you know when to switch from one to the other? You can't do your calculations and say "ok, the wheel will be pushing with this much force" then next update say "right, the output force is now this, but the user has let go so I'll recalculate in order to take into account the inertial properties of the controller". With position input it's up to the user to provide a force that interacts with the force the controller is generating to arrive at an input position; with Leo's idea you're measuring that user force and making it part of your calculations to arrive at an output position. The same thing is happening, but you're moving the interaction into the system so you don't need to worry about working out if they're holding on - what they're doing is already part of the calculation. Another very long sentence that loses focus, so I've bolded what I think is the important bit. To me it sounds like your external input is a force, which you're struggling to calculate because you're trying to derive it from position. I have no such position and have no experience in simulation. If that means you'd prefer to ignore my suggestions feel free. But I'd have thought with all that expertise you'd be able to actually show why force input doesn't work in an application of your own simple example.
1: What? Steering ratio and steering wheel size are chosen so that the driver can control the vehicle, the driver must be the dominant force in the system. 2: First sentence, thats exactly how it is in a real car, you turn the wheel against whatever force you need to to get at your desired location. Leo's idea huh??? There you would basically need to precalculate all the desired reactions so that when you turn the wheel it is able to reproduce a realistic reaction and arrive at the right position. It makes more sense to try and ride a tricycle to mars. A STEERING WHEEL IS CONNECTED TO STEERED WHEELS BY MECHANICAL LINKAGE, (EXCLUDING COMPLIANCE) ONE THING IS TRUE ABOUT THIS SYSTEM: FOR 'X' DEGREES WHEEL INPUT, STEERED WHEELS MOVE BY 'Y' DEGREES - IT'S A DIRECT RELATIONSHIP. As for force there is no unique force that corresponds to any unique position and no change in force that directly corresponds no a new position. For however many reasons you can think of that whould impact how the wheel feels, each one is another reason why force input does not work.
No one is suggesting you can position the tyres by the force on the wheel - you're misunderstanding the concept. And please don't type in caps, I can read just fine without them thanks. Spaskis was talking about 2 distinct situations, where you first have the user moving the wheel, second is where the user isn't holding the wheel. To avoid oscillation in the second situation it would make sense to know/learn the behaviour of the wheel itself, because in doing so you can modify your output to reduce/eliminate the oscillation. So the bit you've quoted there is me saying that if the user is only lightly gripping the wheel it will behave differently to a given force than it would if you were strangling it. With force feedback the wheel is pushing you, and you push it. Yes, you're aiming for a particular position, but you have to apply a force to get to that position, right? So Leo's idea is just about moving that force into the system - you still apply a force to get to a position, but rather than giving you the direct output force and then reading the position you achieve with/despite it, it puts the wheel in a position as determined by the system and then reads your force to then interact with the system. It's exactly the same process that happens now but part of it is moved into the system. So the steering wheel position, which as you say is directly linked to the wheels, is still arrived at by combining what the system is doing with the force you're applying. Your wheel position isn't up in the air - it's determined by the system. In other words the steering wheel position is directly linked to the steered wheels. Any clearer?
I have the feeling you and the lord is forgetting about the surface and a car with 2 axles in motion. How you will know the right position and force for the steering wheel output while moving. The tire would generate nothing if it wasn't in contact with a friction surface where it rolls on but friction as load is not all time the same. Another problem is your constantly changing spring center ( steering start ). I guess the result was a never ending calculation because there is no end as long as the car rolls, like start - no end - start again - no end again - because start again to calculate up from the current start position to another open end.
Can you explain to me the following? - You say you will measure force. Are you thinking on a fast response extensiometric gauge (sorry if it is not translated Ok)? - Where would you put it in the wheel? I ask because the wheel has a mass that needs to be accelerated so any where you put it you will not measure the real reaction between your hands and the wheel. Consider please the effect of the inertias of the wheel moving before you answer. -How will you prevent wheel inertias to provide forces to the the force input detector causing an unreal force since the mass properties of the real wheel are different from the simulated ones? - Explain me the formula to be used when you say that you will calculate position based on the measured force. I already told you that this was not possible in a system where you push/pull a spring attached to a mass. If your system cannot simulate this simple case imagine a real car... - why would you calculate new position if after providing the FFB, the wheel will go to the correct place any way? Doesn't really sound strange to calculate something that WILL happen since you will not be able to control next position it will be in a different position when FFB gets calculated? Remember that you need time to communicate between PC and wheel and that position input is (or should at least in my opinion) being provided at a much higher frequency than FFB output. Please dont ask me again to explain why IMO opinion you are wrong. I already did before but you just don't understand me and that's it. I speak technically and you just say that you do things without explaining how, as when you say that you will calculate new position. Can you make a simulation about that with any example you want and compare it to the real solution as I did with my stupid spring mass system? Can you tell me some references about your knowlwdge in physics mathematics and simulation? I already did it. NOT TO SHOW OFF but to give more support to the fact that I know what I am talking about. Thanks for answering your questions now. I already have tried to explain my point several times with several examples. Enviado desde mi GT-I9505 usando Tapatalk 2
Stay cool I believe you want the same thing The best possible FFB solution ? I really enjoy this discussion (so much interesting information and ideas)
